CI / CD infrastructure Terraform : Les différentes façons de tester et déployer son infra

Introduction

• Le code de l’infrastructure est totalement séparé du code applicatif.
Il y a donc un ou plusieurs repos pour les composants applicatifs qui seront chargés de tester et release le code sous forme d’artefacts (image docker, binaire…) dans des registres et un repo dédié au code de l’infrastructure.

• Le code de l’infrastructure contient un dossier par environnement et plusieurs sous layer de code pour respecter les pratiques GitOps et Terraform comme l’exemple montré ci-dessous :

Les différents types de workflow Git de mise en production pour son infrastructure

Git Flow : master|main en branche de référence

Détail du workflow

Si push sur master :
- Pour chaque env/dossier :
    - Job (Plan) : Vérifie si y a des changements à apply
    - Job (Validate) : Valide que le code Terraform est fonctionnel
    - Job (Apply) : Apply les modifs si y a des changements à appliquer.
					 ^ Ce job aura un condition approval en fonction du nom de l'env

Si merge request :
- Pour chaque env :
    - Job (Plan) : Vérifie si y a des changements à appliquer
    - Job (Validate) : Valide que le code Terraform est fonctionnel

Avantages

• La branche master est la single source of truth, tout ce qui n’est pas sur master peut être considéré comme du drift d’infrastructure

• S’intègre très bien si l’équipe travaille en mode Github Flow

Inconvénients

• Peut générer des side-effects sur des environnements si des modifications ont été réalisées sur des modules communs à plusieurs envs et qu’il n’y a pas de validation manuelle appliquée sur cet env
Exemple : Staging et preproduction utilisent tous deux un module pour créer son socle réseau. Une modification sur le module réseau est réalisée Elle est poussée sur master Les envs staging et preproduction n’ayant pas de validation manuelle, alors les deux envs seront mis à jour automatiqument

• Prend beaucoup de temps pour tester des idées sur des environnements de sandbox par exemple

• Peut nécessiter l’utilisation d’un plan Github Entreprise si le repo est privé pour bénéficier des fonctionnalités de protection de branche. (Vous pouvez toujours contourner cette restriction avec cette action : https://github.com/marketplace/actions/manual-workflow-approval)

Workflow 2 : Une branche par environnement

Détail du workflow

Avantages

• Permet de tester de façon plus souple ses infrastructures sur les environnements de tests sans avoir à passer par des processus de review d’équipe qui peuvent être lourds pour mettre sur la branche principale le code

• S’intègre très bien si l’équipe travaille en mode Git Flow

Inconvénients

• Le code sur la branche de production, peut avoir du drift par rapport à l’état réel de l’infrastructure car la source de vérité de l’état de l’infra est la branche de l’environnement et non plus master

Les étapes à inclure dans ses pipelines / workflows

• Validate : Vérifie que le code Terraform est valide et fonctionnel avec des commandes tels que terraform validate

• Lint : Vérifie que le code Terraform est correctement formaté et respecte les bonnes pratiques de sécurité / disponibilité (Avec des linters comme tfsec, tflint, checkov, terraform fmt, terrascan, opa…)

• Cost Estimate : Réalise une analyse de coût de l’infrastructure et bloque ou non la pipeline en conséquence avec Infracost

• Plan : Lance un Terraform plan pour montrer les modifications qui seront apportées à l’infrastructure

• Approve : Attend une validation manuelle d’un ou plusieurs membre de l’équipe de façon conditionnelle selon l’environnement et le layer à déployer

• Deploy : Applique les modifications du plan sur l’infrastructure

Les différentes façons de réaliser des processus de validation

Terraform Cloud

Spacelift

Brainboard

Github Action Entreprise + 1 environment par layer + Deployment protection rules

name: Plan layers on PR

on:
  pull_request:
    types: [opened, reopened]

jobs:
  plan:
    name: Terraform Plan
    runs-on: ubuntu-latest
		strategy:
			fail-fast: false
		  matrix:
		    environment: [ 
		      {name: staging, region: eu-west-1},
		      {name: preprod, region: eu-west-1},
		      {name: prod, region: eu-west-1}
		    ]
		    layer: [
		      {name: 10-base, infra_conf_dir: 10_base},
		      {name: 20-eks-core-services, infra_conf_dir: 20_eks_core_services}
		    ]
		environment: ${{ matrix.environment.name }}-${{ matrix.layer.name }}
    steps:
      - name: Checkout repository
        uses: actions/checkout@v3
...

Github Action + 1 issue de validation par layer modifié + CODEOWNER

Workflow 1 : Trigger lors d'une création de PR
Workflow 2 : Trigger lors d'un commentaire sur une PR avec un certain label ou d'un merge sur master

Création d’une Github Apps dédié

Comparatif des principaux éléments à avoir en tête

Sécurité

Complexité d’utilisation et de mise en place

Prix

Conclusion

Annexe