Terraform et GitLab
Chez Astrakhan lorsqu’on parle d’Infrastructure as Code, nous sommes convaincus que le GitOps est la pratique incontournable à adopter consistant à considérer Git comme la seule et unique source de vérité de l’état souhaité du système complet. Il s’agit alors d’appliquer à l’infrastructure la même rigueur que l’on connait dans le monde du développement applicatif pour mieux construire, collaborer et délivrer l’infrastructure en traçant l’ensemble des modifications.
Il existe différents outils permettant de décrire son infrastructure as code pour l’automatiser comme Pulumi, Troposphere, AWS CloudFormation ou AWS Cloud Development Kit (CDK) ou encore Terraform. Dans la suite de ce post, nous nous intéresserons à ce dernier et plus particulièrement nous vous proposons dans cet article une intégration de Terraform avec GitLab et l’externalisation de la configuration propre à Terraform pour ne conserver dans votre repository que ce qui concerne votre infrastructure cible.
Intégration de Terraform avec GitLab
Nous vous conseillons la lecture des excellents posts en anglais de Brad Downey (GitLab) concernant ce sujet :
• Why collaboration technology is critical for GitOps
• How infrastructure teams use GitLab and Terraform for GitOps
• How to deploy to any cloud using GitLab for GitOps
Au travers de ces articles, Brad Downey propose ce template terraform, qui a largement inspiré nos travaux.
La pipeline Terraform y est découpée en 4 stages, correspondant aux quatre grandes actions Terraform :
• validate : contrôle du code de l’infrastructure
• plan : construit un plan des opérations à mener pour aligner l’état système avec sa description « as code »
• apply : applique le plan construit lors du précédent stage
• destroy : supprime le système et toutes ses ressources
Factoriser le code concernant la configuration Terraform
Lorsque nous parlons de la configuration Terraform, il s’agit en fait du « backend » Terraform et du provider « Cloud » dont la configuration apparaît dans chacun de vos projets Terraform. Pour éviter d’avoir à redéfinir ces configurations pour chaque projet, nous proposons ici de les positionner en tant que variables GitLab CI/CD. Dans l’exemple d’organisation de projet suivantes,
• le code propre au « backend Terraform » est configuré au niveau du sous-groupe GitLab « cloud »
• le code propre au provider « Cloud au niveau » est configuré au niveau des sous-groupes aws, azure ou gcp correspondant à votre provider
Labs
Pour configurer l’accès à GCP, ajouter les variables suivantes:
• TF_VAR_gcp_project = ID de votre projet GCP
• GOOGLE_CLOUD_KEYFILE_JSON = fichier JSON correspondant à un service account GCP avec les droits suffisant pour construire l’infrastructure
Dans le présent exemple, nous utilisons également GitLab en tant que « backend Terrform ». C’est pourquoi il est nécessaire d’ajouter un access-token GitLab.
• GITLAB_TOKEN = personnal access token avec les droits owner sur le projet
A présent pour mettre en œuvre la solution partagée, suivez les instructions suivantes :
• Ajouter au sous-group cloud une variable GitLab CI/CD de type « File » nommée « TFCD_BACKEND » avec le contenu suivant :
• Par exemple pour Google Cloud Platform, ajouter au sous-groupe gcp une variable GitLab CI/CD de type « File » nommée « TFCD_PROVIDER » avec le contenu suivant :
Dans la chaîne de CI, il reste enfin à déverser ces deux variables en tant que fichier de code Terraform avant exécution des commandes Terraform. L’ajout des deux lignes suivantes en before_script des jobs Terraform permet effectivement d’écrire le contenu des deux variables dans des fichiers provider.tf et backend.tf.
Pour cette dernière étape, vous pouvez réutiliser la pipeline Astrakhan fournie dans ce projet.
