Nos infrastructures peuvent être construites, déployées, répliquées grâce à ces API. Des outils dits d’Infrastructure as Code (IaC) comme AWS Cloud Formation, HashiCorp Terraform, ou encore Pulumi ont émergé pour simplifier la description de nos infrastructures ou nos services SaaS.
Terraform propose de décrire l’infrastructure désirée dans un format texte propriétaire nommé HCL (pour HashiCorp Configuration Langage) puis stocke l’état des ressources dans un fichier d’état une fois le code appliqué.
Nous stockons le code source d’infrastructure dans un dépôt Git. Nous pouvons alors historiser les changements, réaliser un audit sur les modifications et passer en revue le code avant de les appliquer.
Le workflow typique du développement de code d’infrastructure avec Terraform est le suivant :
Workflow simple pour appliquer les modifications d'infrastructure avec Terraform
Cela ressemble fort à l’approche GitOps proposée en 2017 par Weaveworks pour automatiser le déploiement d’applications sur un cluster Kubernetes. Néanmoins, la principale différence est la médiation automatique. Des outils tels que Flux ou ArgoCD sont en effet capables d’appliquer automatiquement les changements en fonction de ce qui est présent sur le dépôt Git.
Comment se rapprocher d’une approche GitOps tout en cloisonnant les changements apportés sur un environnement donné ?
L’outil en code ouvert Atlantis propose de planifier les modifications par le mécanisme de merge request et d’appliquer les modifications une fois la revue de code réalisée par l’équipe. Nous pouvons ainsi réduire les droits d’exécution des développeurs et seul Atlantis peut modifier l’infrastructure.
Dans la suite de cet article, nous décrirons le déploiement typique d’un serveur Atlantis puis nous proposerons un déploiement permettant de cloisonner les environnements.
Atlantis est un projet initialement développé en interne par la société Hootsuite pour unifier les workflows de gestion de leur infrastructure via Terraform. Ce projet a été offert au monde libre en 2017.
C’est un serveur web disponible sous forme d’un binaire ou d’une image Docker. Il peut être déployé aussi bien sur un serveur classique que sur un orchestrateur de conteneurs tel que Kubernetes.
Généralement, une seule instance d’Atlantis est suffisante et permet de déployer le code Terraform sur plusieurs environnements d’un projet.
Ce serveur est déployé dans une zone support qui est indépendante des différents environnements disponibles (traditionnellement un compte par environnement). Par exemple, si nous déployons un serveur sur un environnement AWS, l’infrastructure serait la suivante :
Déploiement typique avec un compte support / tooling
Afin de modifier l’infrastructure sur chacun des environnements cibles, il est nécessaire de donner des droits étendus au serveur Atlantis. Même si nous pouvons réduire au maximum les droits associés au serveur, cela reste un problème en cas d’intrusion.
Atlantis met à disposition une API Web qui permet d’exécuter des commandes Terraform une fois le dépôt Git cloné en local. Pour pouvoir interagir avec le gestionnaire de code source type GitHub ou GitLab, Il faut ajouter l’URL de ce webhook. Certains évènements comme la création d’une Merge / Pull Request (MR/PR) ou l’ajout de commentaires sur une MR / PR seront alors envoyés au serveur Atlantis.
Atlantis introduit le workflow de développement et de déploiement suivant :
Workflow typique pour appliquer les modifications d'infrastructure avec Atlantis
À noter que la configuration d’Atlantis se fait via le fichier atlantis.yaml qui doit être stocké à la racine du projet. Ce fichier permet d’indiquer quels sont les répertoires à prendre en compte et quels sont les workflows à appliquer.
Dans ce cadre, comment décrire l’infrastructure de plusieurs environnements sur un même dépôt Git ? Comment s’assurer que les modifications apportées sur un environnement de développement ne modifient pas l’environnement de production ?
Une solution possible est alors d’avoir une stratégie de branches (pour de plus amples détails, se référer à l’article #8 dans les références en fin d’article). Dans ma mission précédente, nous avions opté pour une stratégie de branches type “GitFlow”.
Dans ce modèle, deux branches sont utilisées. La branche principale conserve l’historique des versions et la branche de développement qui servira l’intégration de nouvelles fonctionnalités. Il est aussi conseillé de positionner des tags sur la branche principale pour identifier les versions livrées.
dépôt Git - Gitflow
Lors de l’introduction d’une fonctionnalité, une nouvelle branche est créée à partir de la branche de développement. Une fois la fonctionnalité implémentée, les modifications sont ensuite reportées sur la branche de développement.
Lorsque nous voulons livrer un ensemble de fonctionnalités, nous devons créer une branche spécifique pour la livraison depuis la branche de développement. Cette branche de livraison permettra entre autres de générer un fichier listant les changements (appelé communément Changelog). Une fois la livraison des fonctionnalités validée, nous pouvons la fusionner avec la branche développement puis avec la branche principale. Généralement, nous pouvons ajouter un tag identifiant le numéro de version au niveau de la branche principale.
Pour plus de détail sur ce workflow de développement, se référer aux articles #5 et #6 dans les références en fin d’article.
Nous pouvons modéliser notre stratégie de branches pour décrire notre code Terraform et surtout le déployer sur le bon environnement.
Ainsi, nous pouvons imaginer avoir une branche de développement qui permettra de déployer le code Terraform vers un environnement de staging ou de préproduction et avoir la branche principale qui permettra de déployer les modifications uniquement sur l’environnement de production.
Si nous avons besoin de rajouter ou de modifier des ressources en préproduction, nous créerons une branche fonctionnelle depuis la branche de développement. Quand les modifications seront validées, nous fusionnerons cette branche fonctionnelle avec la branche de développement pour déployer les changements sur l’environnement de préproduction.
Quand un ensemble de fonctionnalités est valide, nous pouvons le déployer en production en fusionnant la branche de développement avec la branche principale.
À l’aide d’Atlantis, nous pouvons décrire et automatiser ce workflow. Comment sécuriser et cloisonner les déploiements en fonction des environnements ?
À noter que dans la suite de cet article, nous déployons le serveur Atlantis sur une instance EC2 standard.
Une approche simple serait de déployer un serveur Atlantis par compte. Ainsi, chacune de ces instances aura uniquement les droits de modification sur l’infrastructure de son propre compte.
Dans notre gestionnaire de sources, nous devons les ajouter. Les évènements du gestionnaire de sources seront envoyés vers tous les serveurs Atlantis.
Chacun des serveurs Atlantis planifiera le code Terraform sur son environnement même s'il n’est pas concerné par ces changements. Grâce aux droits IAM associés à l’instance, uniquement l’instance concernée par les changements pourra planifier sur son environnement. Les autres instances seront en échec.
Cette première approche est insuffisante vu que le résultat des pipelines de CICD seront en échec et la MR / PR ne pourra pas être appliquée.
Atlantis se repose sur une configuration générale au niveau de l’instance (typiquement /etc/atlantis/repo.yaml sur une instance Debian) si le fichier de configuration au niveau du dépôt n’est pas présent. Cette configuration décrit le workflow à exécuter par défaut.
Atlantis propose aussi des hooks qui seront exécutés avant ou après avoir exécuté le workflow. De ce fait, il est possible de générer le fichier atlantis.yaml dans le repo local juste avant d’exécuter le workflow attendu sur notre projet grâce à un hook de type pré-workflow.
Nous pouvons avoir plusieurs fichiers de configuration (un par environnement) qui décrivent quels sont les répertoires à prendre en compte.
Par exemple, dans l’arborescence suivante, nous avons deux fichiers de configuration :
├── ...
├── atlantis_staging.yaml
├── atlantis_production.yaml
├── infra
│ ├── staging
│ │ ├── backend.tf
│ │ ├── input.tf
│ │ ├── locals.tf
│ │ ├── main.tf
│ │ └── provider.tf
│ ├── production
│ │ ├── backend.tf
│ │ ├── input.tf
│ │ ├── locals.tf
│ │ ├── main.tf
│ │ └── provider.tf
│ └── modules
│ └── network
│ │ ├── input.tf
│ │ ├── vpc.tf
│ │ ├── locals.tf
│ │ ├── main.tf
│ │ ├── outputs.tf
│ │ ├── security_group.tf
│ └── security
│ │ ├── input.tf
│ ├── iam_roles.tf
│ │ ├── locals.tf
│ │ ├── main.tf
│ │ ├── outputs.tf
├── ...
└── repo-config-generator.shAu niveau de chacun des serveurs, le fichier repo.yaml décrit comment générer un fichier de configuration atlantis.yaml au moment hook pré-workflow à l’aide du script Bash repo-config-generator.sh qui se trouve à la racine du projet :
repos:
- id: github.com/wescale/.*/
delete_source_branch_on_merge: true
apply_requirements:
- approved
- mergeable
- undiverged
- id: github.com/wescale/atlantis_demo
delete_source_branch_on_merge: true
apply_requirements:
- approved
- mergeable
- undiverged
pre_workflow_hooks:
- run: ./repo-config-generator.sh
Ce fichier Bash permet de le copier (un fichier correspond dans ce cas à la branche à déployer) comme suit :
#!/usr/bin/env bash
set -o errexit -o nounset -o pipefail
if [[ "$BASE_BRANCH_NAME" == "develop" ]]; then
cp "$DIR/atlantis_staging.yaml" "$DIR/atlantis.yaml"
elif [[ "$BASE_BRANCH_NAME" == "main" ]]; then
cp "$DIR/atlantis_production.yaml" "$DIR/atlantis.yaml"
else
cd $DIR
echo 'version: 3' >atlantis.yaml
echo 'automerge: false' >> atlantis.yaml
if [[ (-n "$CURRENT_PROJECT") ]]; then
[[ -d fake_dir ]] || mkdir fake_dir
echo 'projects:' >> atlantis.yaml
echo " - name: $CURRENT_PROJECT" >> atlantis.yaml
echo ' dir: fake_dir' >> atlantis.yaml
echo ' autoplan:' >> atlantis.yaml
echo ' when_modified: ["*.tf"]' >> atlantis.yaml
echo ' enabled: true' >> atlantis.yaml
touch fake_dir/main.tf
fi
fiAtlantis positionne certaines variables d’environnement comme BASE_BRANCH_NAME qui indique quelle est la branche sur laquelle la MR s’applique et DIR, le répertoire local du projet cloné.
Dans cette première version, nous copions le fichier de configuration correspondant à la branche en le nommant atlantis.yaml. Si la branche ne correspond pas à la branche develop ou main, dans ce cas, nous créons un répertoire vide ainsi qu’un fichier atlantis.yaml qui exécutera le workflow par défaut sur le répertoire vide.
Voici les deux fichiers de configuration qui sont disponibles à la racine du dépôt :
version: 3
automerge: true
projects:
- name: atlantis_demo
dir: infra/production
autoplan:
when_modified: [ "../modules/**/*.tf", "*.tf*" ]
enabled: trueLa génération du fichier Atlantis est faite avant l’exécution du workflow. Cependant, il reste encore un problème : chacune des instances verra les modifications sur le dépôt Git, mais essaiera d’exécuter le code Terraform même s'il n’est pas concerné par les changements.
Il faudrait alors pouvoir identifier l’environnement sur lequel est déployée l’instance Atlantis. La configuration sera prise en compte uniquement si l’Atlantis est concerné par les modifications sur son environnement.
Une solution simple est de copier le fichier repo-config-generator.sh dans le répertoire /etc/atlantis/ au niveau de la génération de l’image d’Atlantis. Ensuite, nous pouvons positionner l’environnement au démarrage de l’instance via les user data des instances EC2.
Ainsi le fichier de configuration repos.yaml devient :
repos:
- id: github.com/wescale/.*/
delete_source_branch_on_merge: true
apply_requirements:
- approved
- mergeable
- undiverged
- id: github.com/wescale/atlantis_demo
delete_source_branch_on_merge: true
apply_requirements:
- approved
- mergeable
- undiverged
pre_workflow_hooks:
- run: /etc/atlantis/repo-config-generator.shEt le fichier de génération de la configuration repo-config-generator.sh:
#!/usr/bin/env bash
set -o errexit -o nounset -o pipefail
CURRENT_ENV="@@ATLANTIS_INSTANCE_ENVIRONMENT@@"
if [[ "$CURRENT_ENV" == "staging" && "$BASE_BRANCH_NAME" == "develop" ]]; then
cp "$DIR/atlantis_staging.yaml" "$DIR/atlantis.yaml"
elif [["$CURRENT_ENV" == "prod" && "$BASE_BRANCH_NAME" == "main" ]]; then
cp "$DIR/atlantis_production.yaml" "$DIR/atlantis.yaml"
else
cd $DIR
echo 'version: 3' > atlantis.yaml
echo 'automerge: false' >> atlantis.yaml
if [[ (-n "$CURRENT_PROJECT") ]]; then
[[ -d fake_dir ]] || mkdir fake_dir
echo 'projects:' >> atlantis.yaml
echo " - name: $CURRENT_PROJECT" >> atlantis.yaml
echo ' dir: fake_dir' >> atlantis.yaml
echo ' autoplan:' >> atlantis.yaml
echo ' when_modified: ["*.tf"]' >> atlantis.yaml
echo ' enabled: true' >> atlantis.yaml
touch fake_dir/main.tf
fi
fiAu démarrage de l’instance, nous remplacerons la chaîne @@ATLANTIS_INSTANCE_ENVIRONMENT@@ par la valeur de l’environnement (production, preproduction etc...).
Grâce à cette variable d’environnement, le serveur Atlantis sera capable de savoir s'il est concerné par les modifications apportées par la Merge Request. S'il n’est pas concerné, il essaiera de planifier une commande sur un répertoire qui est vide.
Avec Atlantis, nous pouvons nous rapprocher du modèle GitOps pour gérer nos infrastructures avec Terraform. Malheureusement, Atlantis ne permet pas la réconciliation automatique comme le prône le manifeste de Weaveworks ”#4. Software agents to ensure correctness and alert on divergence.” (se référer au à l’article #7).
Grâce à Atlantis, nous sécurisons nos infrastructures en empêchant de modifier directement les ressources :
En utilisant une stratégie de branches adaptée telle que le GitFlow, nous pouvons tester de nouvelles fonctionnalités dans différents environnements avant de le déployer en production. Malheureusement, Atlantis ne prévoit pas par défaut d’être déployé sur plusieurs environnements en parallèle et réagir aux évènements uniquement sur certains critères. En générant le fichier de configuration à la volée, nous pouvons modifier ce comportement par défaut.
Site officiel du projet Atlantis
https://runatlantis.io
Atlantis, le Terraform collaboratif sur le blog wescale https://blog.wescale.fr/atlantis-le-terraform-collaboratif
Article medium expliquant le workflow de developpement avec Atlantis
https://medium.com/nerd-for-tech/terraforming-the-gitops-way-9417cf4abf58
Article medium expliquant comment déployer atlantis sur un cluster K8s
https://medium.com/nerd-for-tech/terraforming-the-gitops-way-9417cf4abf58https://medium.com/nerd-for-tech/terraforming-the-gitops-way-9417cf4abf58
Un article décrivant le modèle de gitflow
https://les-enovateurs.com/gitflow-workflow-git-incontournableprojets-de-qualite
Le modèle de branches gitflow présenté par Atlassian
https://www.atlassian.com/fr/git/tutorials/comparing-workflows/gitflow-workflow
Série d’articles sur le blog de weaveworks introduisant l’approche gitops
https://www.weave.works/blog/gitops-operations-by-pull-request
Comparaison de différentes stratégies de branches Git
https://www.flagship.io/git-branching-strategies/