Expertise - Infrastructure as Code (IaC) : votre infrastructure décrite dans Git

Qu'est-ce que l'Infrastructure as Code ?

L'Infrastructure as Code (IaC) consiste à décrire votre infrastructure dans des fichiers texte rangés dans un dépôt Git : les serveurs, les réseaux, les bases de données, les droits d'accès, la configuration des machines. Un outil lit ces fichiers, puis crée ou modifie les ressources pour qu'elles leur correspondent.

Sans IaC, l'infrastructure se construit à la main, dans la console du fournisseur cloud ou en SSH sur les serveurs. Ça fonctionne au début, mais au bout de quelques mois, plus personne ne sait quelle option a été cochée sur quelle machine, ni pourquoi la recette ne se comporte pas comme la production. Pour savoir comment l'infrastructure est configurée, il faut aller voir, machine par machine.

Une fois l'infrastructure décrite en code, le dépôt dit ce qui doit tourner et les fichiers servent de documentation. Si quelqu'un modifie quand même une ressource à la main, un terraform plan montre l'écart. C'est une des briques de notre démarche DevOps.

Ce que ça change, concrètement

Recréer un environnement à l'identique

Une recette, une nouvelle région, un environnement temporaire pour tester une migration : tout part des mêmes fichiers, avec quelques paramètres qui changent. Comme la recette et la production sont construites à partir du même code, la recette ressemble vraiment à la production.

Relire un changement d'infrastructure comme du code

Ouvrir un port, agrandir une base de données, donner un accès à un nouveau service : chaque changement passe par une merge request. Un collègue la relit avant qu'elle soit appliquée, et la CI affiche ce qui va être créé, modifié ou supprimé. Une erreur se repère dans un diff de quelques lignes, avant d'arriver en production.

Savoir qui a changé quoi, et quand

L'historique Git garde chaque modification, avec son auteur, sa date et la raison donnée dans le message de commit. Si un service se comporte différemment depuis mardi, on regarde ce qui a été fusionné mardi.

Repartir après un incident

Si un environnement est perdu, ou s'il faut le reconstruire ailleurs, l'équipe n'a pas à se souvenir de la façon dont il avait été monté : elle rejoue le code. Les données se sauvegardent à part, mais tout ce qui les entoure se reconstruit à partir du dépôt, et un plan de reprise d'activité peut s'appuyer dessus.

Les outils, chacun à sa place

Chaque couche de l'infrastructure a son outil, et un projet en combine souvent plusieurs.

• Terraform pour le cloud : il crée les ressources chez le fournisseur, comme les réseaux, les machines virtuelles, les clusters Kubernetes managés, les bases de données ou les comptes de service.
• Ansible pour configurer des serveurs : sur les machines que vous gérez vous-même, Ansible installe les paquets, écrit les fichiers de configuration et démarre les services, de la même façon sur chaque serveur.
• Les manifests et les charts Helm pour Kubernetes : ce qui tourne dans le cluster (les applications, leur nombre de réplicas, leurs variables, leurs accès réseau) est décrit en YAML. Helm regroupe ces fichiers en charts, avec des valeurs différentes selon l'environnement.
• GitOps pour appliquer : un outil comme ArgoCD surveille le dépôt et aligne le cluster sur ce qui y est écrit. Personne n'a besoin de lancer une commande sur le cluster pour déployer.
• La CI/CD pour vérifier : à chaque merge request, la CI contrôle les fichiers et lance le plan Terraform, pour que la personne qui relit voie l'effet du changement avant de l'accepter.

Les secrets n'ont rien à faire dans ces fichiers. Ils restent dans Vault ou dans le gestionnaire de secrets du fournisseur cloud, et le code se contente d'y faire référence.

Le bon découpage dépend de votre infrastructure. Pour une application qui tourne sur deux serveurs, Terraform et Ansible suffisent souvent, sans Kubernetes ni ArgoCD. Une plateforme de plusieurs services sur Kubernetes utilise en général tous ces outils ensemble.

---

Ce que Naeka peut faire pour vous

Écrire l'IaC d'une infrastructure créée à la main

Votre infrastructure a été montée dans la console au fil des besoins, et plus personne n'ose y toucher ? Nous la décrivons en code sans la reconstruire : les ressources existantes sont importées dans Terraform, la configuration des serveurs est reprise dans Ansible, et nous vérifions que le code correspond exactement à ce qui tourne avant de faire passer le moindre changement par lui.

Reprendre une IaC existante

Vous avez déjà une IaC, écrite par une autre équipe ou par un ancien prestataire ? Nous la lisons, nous la comparons avec ce qui tourne vraiment, nous corrigeons les écarts, puis nous la faisons évoluer avec vous.

Sur Kazaplan, le logiciel de plan 3D du groupe Adeo, nous avons d'abord repris l'IaC existante, en Terraform et Ansible. Dans une seconde phase, nous avons migré cette IaC vers la plateforme Adeo.

Sur Google Cloud et OVH

Nous écrivons l'IaC de vos infrastructures sur Google Cloud et sur OVH, avec Terraform pour les ressources du fournisseur et Ansible pour la configuration des serveurs.

Les images Docker de vos applications

L'IaC décrit l'endroit où l'application tourne. L'application elle-même arrive sous la forme d'une image Docker, construite par la CI à partir d'un Dockerfile versionné avec le code. Nous écrivons ces Dockerfiles en même temps que l'IaC, pour que toute la chaîne, de l'image au cluster, soit décrite dans Git.

Votre infrastructure n'existe que dans une console ?

Contactez-nous. Nous commençons en général par faire l'inventaire de ce qui tourne et de ce qui est déjà décrit en code. Vous savez ensuite ce qu'il reste à écrire, et dans quel ordre.