Slack dévoile une approche proactive et moderne dans la gestion de son infrastructure Terraform. L’entreprise a adopté des stratégies avancées. Le déploiement des changements fusionnés dans les fichiers d’état est désormais automatisé via des pipelines Jenkins, offrant une gestion plus efficiente. Une évolution pour l’entreprise qui a commencé avec Terraform 0.11.
À ses débuts, Slack se limitait à l’utilisation d’un seul compte AWS. Il avait deux fichiers d’état distinct, l’un pour les services globaux et l’autre par région (CloudFront/IAM). Les configurations étaient pareilles pour les environnements de développement et de production.
Avec l’expansion de l’infrastructure, des comptes dédiés ont été créés pour les prestations et les équipes. Slack a instauré des pipelines Jenkins pour mettre en œuvre le déploiement des modifications intégrées dans les fichiers d’état. L’infrastructure de Slack se compose de plusieurs AWS, de NS1, de DigitalOcean, de GCP et de NS1. La gestion est assurée par Terraform, un outil que les personnels techniques ont revisité pour son déploiement.
L’outil Terraform Smart Planner
Autrefois, l’infrastructure, des fichiers d’état, du code Terraform étaient gérés par l’équipe Ops. À présent, c’est plutôt une équipe Cloud Foundations qui prend en charge la gestion de la plateforme. Lors de cette transition, il est conseillé d’intégrer des solutions de portage salarial pour être plus flexible.
À partir de maintenant, un pipeline se met en marche à chaque modification fusionnée dans le référentiel Terraform. Les modules modifiés sont encapsulés. Ils sont transmis en tant que nouvelle version vers le compartiment S3. avec un fichier versions.json renfermant les antécédents du module. L’outil tf-module-viewer en fait partie.
Slack a développé ses pipelines en utilisant le plug-in Jenkins Job DSL et une bibliothèque interne. L’équipe a la possibilité d’intégrer un pipeline dans un pipeline présent ou de créer une nouvelle.
L’étape de planification doit précéder celle de l’apply dans les pipelines. Cela nécessite préalablement la fusion des changements sur la branche principale du repo Terraform. Le risque qu’une modification indésirable puisse entraver le pipeline existe alors. C’est là que Terraform Smart Planner entre en jeu. Il identifie et effectue une opération de planification sur les fichiers d’état concernés pour chaque modification. L’outil intègre ensuite le résultat dans la demande de fusion.
Incorporer l’output dans la demande de fusion permet aux examinateurs de visualiser les ressources impactées par une modification. Cela facilite également la détection de tout fichier d’état indirectement touché.
Slack avait commencé avec Terraform 0.11
Auparavant, Slack était compatible avec une seule version de Terraform, le 0.11. L’entreprise a uploadé ses fichiers d’état en 2019, afin de les rendre conformes à la version 0.12.
Entre les deux versions, des ajustements syntaxiques ont été effectués. Cela implique une procédure qui s’est étendue sur un trois mois. Il aurait été d’ailleurs judicieux de se tourner vers le portage salarial pour rendre ces ajustements plus flexibles.
Ainsi, un wrapper a été produit pour examiner le fichier version.tf, puis choisir le binaire Terraform selon le cas.
Slack demeura fidèle à Terraform 0.12 pendant près de deux années. Il prit ensuite la décision de migrer vers la version 0.13. Simultanément, l’entreprise entreprit l’amélioration du fournisseur AWS.
Il est devenu possible d’inclure plusieurs versions d’un même fournisseur (provider) dans le répertoire des plugins avec Terraform 0.13+. Cette fonctionnalité a simplifié la mise à jour simultanée du fournisseur AWS et du binaire Terraform.
Slack a supprimé les épinglages de versions après avoir actualisé tous les fichiers d’état vers les versions les plus récentes des fournisseurs.
En interne, un outil a été créé pour superviser les mises à jour de Terraform. Au début, c’était un script Bash qui était prévu, mais Slack l’a ultérieurement remplacé par un binaire Golang.
Les bibliothèques terraform-exec, gohcl et hclsyntax ont simplifié certaines tâches :
- L’accomplissement d’opérations de plan ;
- L’analyse de la configuration ;
- L’intégration d’éléments dans des organisations de données Go.
Les fichiers d’état et les modules sont regroupés dans un seul référentiel. Slack fait usage du fichier CODEOWNERS pour attribuer les révisions aux équipes responsables.
Initialement, un chemin relatif était employé pour les modules. Cela présentait l’avantage de simplifier les tests. Il constituait également un inconvénient en raison du risque de perturber d’autres fichiers d’état employant le module similaire.
