Le 20 juin 2023, Airbyte a annoncé qu’un provider Terraform pour Airbyte était disponible.

Si vous ne connaissez pas Airbyte, pas de panique. Il s’agit d’un outil open source qui facilite grandement l’ingestion de données depuis une/plusieurs source(s) vers une/plusieurs destination(s). La force d’Airbyte ? Après avoir sélectionné vos ressources parmi un catalogue de +350 éléments, il vous suffit juste de les configurer en remplissant un formulaire. Ensuite, Airbyte s’occupe pour vous des tâches complexes liées à l’ingestion des données. Je vous conseille cet article d’Amin BAZAZ si vous voulez en savoir plus sur Airbyte : Ingestion de données dans ma plateforme : Airbyte répond présent !

Le problème principal d’Airbyte est son manque d’industrialisation. En effet, il est difficile de pouvoir apporter des modifications sur plusieurs ressources sans devoir le faire manuellement. Pour régler cela, Airbyte avait implémenté Octavia CLI qui permettait de définir des ressources Airbyte-as-Code, mais le projet était difficile à utiliser et avait ses limites. Le tout nouveau provider Terraform est là pour remplacer Octavia et mettre fin à ce souci d’industrialisation !

Pour tester ce tout nouvel outil, nous allons l’utiliser pour récupérer les messages disponibles sur un workspace Slack et les pousser dans un Bucket S3 sur AWS.

Figure 1 : Architecture mise en place

Dans cet article, nous allons voir comment créer une source (Slack), une destination (Bucket S3) ainsi qu’une connexion à l’aide du provider Airbyte de Terraform.

Pré-requis

Si vous souhaitez reproduire ce qui est fait dans l’article, vous aurez besoin d’un compte AWS, de Docker/Rancher, d’Airbyte et de Terraform. J’utilise actuellement Terraform 1.5.7 et Rancher Desktop 1.10.0 pour mettre en place cette infrastructure.

Installer Terraform et Docker/Rancher

Il vous suffit de vous rendre sur les sites officiels et de télécharger les logiciels d’installation :

• Install Terraform
• Install Docker Engine (si vous préférez Docker)
• Install Rancher Desktop (si vous préférez Rancher)

Installer Airbyte

Pour installer Airbyte en local, il vous suffit de cloner le repo Github d’Airbyte et de lancer le script run-ab-platform.sh (uniquement lors de l’installation) :

# In your workstation terminal
git clone https://github.com/airbytehq/airbyte.git
cd airbyte
./run-ab-platform.sh

Par la suite, il vous suffira de lancer les images d’Airbyte à l’aide d’un simple docker-compose up (docker-compose stop pour les stopper).

Rendez-vous sur localhost:8000/ pour accéder à Airbyte. Par défaut, l’username est airbyte et le mot de passe est password. Ces paramètres peuvent être changés depuis le repo cloné.

Configuration de la source - Slack

Lors de la configuration de la source, nous allons devoir renseigner deux choses :

• le workspace ID du client Airbyte
• l’API Token de Slack pour récupérer les messages

N’oubliez pas de créer un fichier Terraform contenant le provider Airbyte (comme indiqué dans la documentation officielle).

Pour trouver le workspace_id, il vous suffit de regarder l’URL de votre client une fois que vous y êtes connecté :

Figure 2 : URL du client Airbyte

Le workspace_id est la valeur qui se trouve entre les champs workspaces et connections. Dans mon cas, la valeur du workspace_id est “6b05253c-9a9f-4888-af40-efd23c66f8b0”.

Quant à l’API Token de Slack, je vous renvoie vers la documentation d’Airbyte sur la source Slack. Vous allez devoir vous rendre sur la page d’applications Slack puis créer une application. Veillez à bien fournir les autorisations indiquées dans la documentation.

Ressource Terraform et comparaison avec Airbyte

Slack est notre source de données qui contient l’ensemble des messages que nous voulons récupérer. Pour illustrer la différence entre le provider Terraform et la GUI classique d’Airbyte, vous trouverez des captures d’écran des deux éléments pour chaque étape (source, destination, connexion).

Figure 3 : Source (Slack) sur la GUI d’Airbyte

Comme sur la GUI d’Airbyte, vous devez renseigner :

• le nom de la source
• l’API Token (que nous avons généré plus haut)
• la date de début de réplication

resource "airbyte_source_slack" "src_demo" {
  configuration = {
    channel_filter = [
      "support_technique",
      "dbt",
      "général",
      "events",
      "aléatoire"
    ]
    credentials = {
      source_slack_authentication_mechanism_api_token = {
        api_token    = "<token-api-à-renseigner>"
        option_title = "API Token Credentials"
      }
    }
    join_channels   = true
    lookback_window = 0
    source_type     = "slack"
    start_date      = "2023-01-01T00:00:00Z"
  }
  name         = "[Démo Article] Source de données - Slack"
  workspace_id = "<workspace-id-à-renseigner>"
}

Il est possible de choisir les canaux cibles contenant les messages à récupérer via le paramètre channel_filter (Channel name filter sur l’interface).

Attention, avec la version gratuite de Slack, vous ne pourrez récupérer que les messages qui datent de moins de 90 jours. Ainsi, la valeur attribuée à la variable start_date n’est pas prise en compte au-delà de 90 jours.

Déploiement de la source avec Terraform

Pour déployer la source avec Terraform :

terraform init
terraform plan --out plan.cache
terraform apply "plan.cache"

Figure 4: Source créée sur la GUI d’Airbyte

Et voilà ! Nous venons de créer notre première ressource avec le provider Airbyte de Terraform ! C’était facile, non ?

Passons maintenant à la ressource suivante : la destination.

Configuration de la destination - Bucket S3

Lors de la configuration de la destination, nous allons devoir renseigner trois choses :

• le workspace ID du client Airbyte
• une Access Key
• une Secret Key

Nous avons déjà vu comment retrouver son workspace_id lors de la configuration de la source. En ce qui concerne les deux Keys, je vous renvoie une nouvelle fois vers la documentation d’Airbyte, sur la destination S3 cette fois-ci. Il vous faudra créer un Bucket S3 pour accueillir les messages en provenance de Slack, un utilisateur IAM ayant les droits nécessaires pour accéder au Bucket et enfin une Access Key afin qu’Airbyte puisse profiter des privilèges accordés à cet utilisateur.

Airbyte synchronise les données dans le Bucket au sein d’un sous-dossier spécifique. Veillez à bien créer ce dossier (par la suite, on nommera ce dossier csv).

Ressource Terraform et comparaison avec Airbyte

Comme pour la source, les paramètres affichées sur la GUI d’Airbyte sont les mêmes sur Terraform :

Figure 5 : Destination (Bucket S3) sur la GUI d’Airbyte

Comme sur le GUI d’Airbyte, vous devez renseigner :

• le nom de la destination
• le nom du Bucket S3
• le path du Bucket S3 (“csv” si les données vont dans un dossier “csv” dans le Bucket S3)
• la région du Bucket S3
• le format de sortie

resource "airbyte_destination_s3" "dst_demo" {
  configuration = {
    access_key_id     = "<access-key-à-renseigner>"
    destination_type  = "s3"
    format = {
      destination_s3_output_format_csv_comma_separated_values = {
        flattening = "No flattening"
        format_type = "CSV"
      }
    }
    s3_bucket_name    = "demo-airbyte-dst"
    s3_bucket_path    = "csv"
    s3_bucket_region  = "eu-west-1"
    secret_access_key = "<secret-key-à-renseigner>"
  }
  name         = "[Démo Article] Destination - Bucket S3"
  workspace_id = "<workspace-id-à-renseigner>"
}

On renseigne également l’Access Key et la Secret Key générées précédemment afin d’accéder au Bucket S3 (qui n’est pas public par mesure de sécurité).

Déploiement de la destination avec Terraform

Pour déployer la destination avec Terraform :

terraform plan --out plan.cache
terraform apply "plan.cache"

Figure 6: Destination créée sur la GUI d’Airbyte

Notre destination est créée ! Dernière étape : la connexion.

Configuration de la connexion

Ressource Terraform et comparaison avec Airbyte

Pour faire fonctionner la réplication des données de Slack vers S3, il est nécessaire de créer une connexion entre les deux. Contrairement à la source et à la destination, pas besoin de configuration supplémentaire !

Figure 7 : Connexion sur la GUI d’Airbyte

Comme sur le GUI d’Airbyte, vous devez renseigner :

• le nom de la connexion
• le nom d’au moins un stream à synchroniser (channels_messages ici car on veut récupérer les messages contenus dans les canaux de Slack) et la méthode de synchronisation (Full refresh Overwrite ou Full refresh Append)

resource "airbyte_connection" "connection_demo_article" {
  destination_id       = airbyte_destination_s3.dst_demo.destination_id
  source_id            = airbyte_source_slack.src_demo.source_id
  name                 = "[Démo Article] Slack vers Bucket S3"
  namespace_definition = "source"
  configurations       = {
    streams = [
      {
        name = "channel_messages"
        sync_mode = "full_refresh_overwrite"
      }
    ]
  }


  schedule = {
    schedule_type = "manual"
  }
}

Il est possible de paramétrer à quelle fréquence Airbyte va récupérer les données : manuellement, CRON, toutes les X heures.

Déploiement de la connexion avec Terraform

Pour déployer la connexion avec Terraform :

terraform plan --out plan.cache
terraform apply "plan.cache"

Figure 8 : Connexion créée sur la GUI d’Airbyte

Tout est prêt ! Il ne suffit plus qu’à cliquer sur le bouton “Sync Now” pour lancer la réplication des données.

Figure 9 : Messages sur le Bucket S3 suite à la synchronisation

Tada ! Les messages se retrouvent sur le Bucket S3 !

Comparaison avec Octavia CLI

Octavia CLI est un sous-projet open source du projet Airbyte permettant d’écrire la configuration de source, destination et connexion as code via des fichiers YAML. Pour plus de détails, je vous renvoie vers l’article de Baptiste MANSIRE à ce sujet : Décrire vos ressources Airbyte as code avec Octavia CLI

Cela permet donc de faire des choses similaires au provider Terraform. Vous pouvez donc vous demander : “En quoi cet outil est différent ?”

Similarités :

• Manager les ressources Airbyte autrement qu’avec la GUI d’Airbyte
• Possibilité de revenir en arrière si une configuration est mauvaise
• Collaboration facile car configuration managée par du code
• CI/CD applicable sur les ressources Airbyte
• Réplication des ressources dans un autre environnement possible
• Création d’une multitude de ressources plus simple qu’avec l’interface

Différences :

• Possibilité de supprimer les ressources sur Terraform, pas sur Octavia
• Possibilité d’importer des ressources déjà déployées sur l’instance Airbyte avec Octavia, pas sur Terraform
• Configuration-as-Code sur Octavia, Infrastructure-as-Code avec Terraform

D’après Airbyte, Octavia est encore utilisable mais Terraform prendra la main d’ici la fin de l’année. Airbyte travaille actuellement sur l’import de l’ensemble des ressources de l’API et leur bon fonctionnement et espère terminer avant 2024.

Conclusion

Désormais, vous savez comment déployer vos ressources Airbyte sur Terraform !

Nous avons vu ensemble comment créer une source (Slack), une destination (Bucket S3) et un connecteur grâce au tout nouveau provider. Il vous suffit simplement de suivre la documentation pour déployer une source ou une destination différente. Les paramètres demandés pour créer une ressource sur Terraform sont les mêmes que sur la GUI d’Airbyte.

Si vous souhaitez déployer vos ressources avec du code à l’avenir, préférez cet outil plutôt qu’Octavia CLI : c’est Airbyte qui vous le dit !

Pour aller plus loin :

• Documentation du provider Terraform Airbyte : https://registry.terraform.io/providers/airbytehq/airbyte/latest/docs
• Documentation d’Airbyte : https://docs.airbyte.com/
• Repo Github d’Airbyte : https://github.com/airbytehq/airbyte
• Mon repo pour reproduire toute la manipulation : https://github.com/meyanoker/airbyte_tf_provider