Implémenter une plateforme IaC avec Terraform, Ansible et GitLab

Pour créer une infrastructure dans plusieurs environnements différents tout en assurant une standardisation et un suivi efficace, il devient essentiel de fournir ces environnements de manière sécurisée. Pour ce faire, il est essentiel d’adopter une approche d’infrastructure immuable, où les environnements sont fournis sous forme de code.

L’objectif de cet article est de démontrer une approche possible pour atteindre cela en utilisant les structures de GitLab pour imposer des modèles et des normes, Terraform pour appliquer et maintenir les normes sur les serveurs, et Ansible pour la fourniture de logiciels et la configuration, en utilisant un modèle de rôles partagés across repositories. Pour gérer l’état des machines avec Terraform, nous utilisons MinIO, car il permet de mettre en œuvre cette implémentation sur site.

Conception de l’architecture

Étape 1

Le processus commence toujours par le soumission d’un problème standardisé, spécifiant le modèle de stack à utiliser, si des permissions de pare-feu sont nécessaires, et si c’est une nouvelle installation ou juste une mise à niveau de ressources.

Étape 2

L’opérateur examine le problème et commence le processus. Toutes les conversations et le temps passé sont enregistrés à l’intérieur du problème.

Étape 3

Un nouveau projet est initié dans GitLab, basé sur le modèle d’infrastructure qui sera créé. Ce projet est placé dans le groupe correspondant de GitLab, où il hérite des variables d’environnement nécessaires pour la création standardisée d’infrastructure.

Étape 4

Lorsque le projet est créé, vous devez seulement spécifier les IP pour l’infrastructure à provisionner dans l’environnement spécifié dans l’issue (KVM, VMware). Après la planification avec Terraform, les ressources requises sont créées, y compris l’ajout de labels si nécessaire, pour que Veeam puisse effectuer les backups basés sur les politiques de labels.upon completion, the state of the created infrastructure est stocké dans un bucket.

Étape 5

Le prochain pas implique l’exécution de tâches standard pour tous les serveurs, comme les identifier, mettre à jour les paquets, installer les utilitaires nécessaires et enregistrer l’hôte dans Zabbix pour la surveillance de base du système d’exploitation et du stack. En fonction du groupe de ressources, les clés d’accès appropriées sont affectées aux équipes responsables. Par exemple, les DBAs reçoivent des clés d’accès pour les serveurs de bases de données.

Étape 6

En fonction du modèle choisi, le processus d’installation et de configuration de l’ensemble du stack est effectué. De même, les utilisateurs sont créés et les identifiants sont enregistrés dans Vault lorsque nécessaire.

Étape 7

Avec l’application maintenant en cours d’exécution dans le nouvel environnement, une surveillance spécifique pour chaque stack peut être effectuée, enregistrant le nouveau serveur dans Consul. Ensuite, Prometheus identifie où il doit collecter les informations. Chaque stack possède son tableau de bord de surveillance déjà configuré, variant uniquement par le nom du projet créé.

Étape 8

La nouvelle infrastructure est livrée au demandeur. Dans le cas des bases de données, les identifiants sont fournis directement dans Vault.

Structure du projet

La structure de dossiers dans GitLab est organisée comme suit :

• /infrastructure/ : Le groupe principal, où les variables d’environnement globales et les valeurs par défaut devraient être stockées
• /infrastructure/gitlab-models : Des modèles de pipeline, où nous avons deux projets principaux
  • ansible-pipelines : Un projet consacré à la maintenance des stacks et de la composition des rôles.

• terraform-pipelines : Pipeline pour les modèles d’infrastructure disponibles, tels que vSphere, KVM, AWS, etc.

• /infrastructure/templates : Dans ce groupe, nous avons les projets de démarrage, qui seront utilisés pour créer les modèles de stack.

• /infrastructure/provision/ansible/roles : Dans ce projet, nous avons uniquement les rôles Ansible, ce qui nous permet de centraliser et de mettre à jour les rôles de manière isolée.
• /infrastructure/dependencies-iac : Ce référentiel contient les dépendances de la plateforme, telles que les Dockerfiles pour Terraform et Ansible, garantissant que les versions des outils et des bibliothèques nécessaires ne sont pas modifiées.
• /infrastructure/modules/ : Les modules créés pour Terraform sont stockés dans ce référentiel, et chaque projet a son dossier respectif.
• /infrastructure/on-premise/ : Dans ce groupe, les infrastructures créées sont maintenues et segmentées par environnement, centre de données, stack et projet. Sur l’image, nous pouvons voir la hiérarchie des groupes et sous-groupes jusqu’au projet final. À chacun de ces niveaux, nous pouvons écraser les valeurs des variables associées aux groupes.

Comment utiliser une plateforme

Pour simplifier l’utilisation de la plateforme, nous avons créé un référentiel appelé issues-ops, où nous proposons un modèle de ticket basé sur des besoins spécifiques. De cette manière, la demande d’infrastructure est enregistrée dès le départ.

Une fois l’issue créée, l’équipe DevSecOps peut commencer à configurer l’environnement. Pour ce faire, ils doivent simplement naviguer vers le groupe approprié, dans ce cas, infrastructure/on-premise/staging/dc1/loadbalancer/nginx, et créer un nouveau projet à partir d’un modèle. Ils devraient ensuite fournir le nom du projet à créer et assigner les variables nécessaires.

Dans chacun des modèles, le fichier .gitlab-ci.yml requis pour la création de l’environnement est déjà configuré. Dans le cas d’NGINX, il est mis en place dans ce format.

Dans ce dispositif, les modèles de création d’infrastructure et les modèles d’Ansible sont inclus, garantissant que les rôles par défaut sont déjà intégrés dans ces projets. De plus, nous fournissons des étapes pour étendre le modèle. Si des rôles supplémentaires doivent être installés, vous pouvez simplement ajouter le bloc correspondant, permettant une approche modulaire et bloc par bloc de configuration.

Dans l’image ci-dessous, nous voyons le pipeline qui a exécuté la création de l’environnement demandé. Vous remarquerez que authorized_keys et common ont été exécutés, même s’ils n’étaient pas explicitement déclarés dans le .gitlab-ci.yml. Cela est dû au fait que nous avons des rôles standards provenant du modèle d’Ansible importé, garantissant que les rôles par défaut sont appliqués à tous les projets.

Conclusion

La plateforme d’infrastructure a grandement contribué à la maintenance et à l’application de normes car elle exige qu’un modèle prédéfini soit planifié, testé, mis en œuvre et mis à disposition en tant que modèle avant qu’une nouvelle infrastructure ne puisse être créée. Ce processus assure que chaque fois que nous avons besoin de provisionner des ressources dans un environnement, nous établissons des normes uniformes, nous versionnons ces environnements et nous nous assurons qu’ils peuvent être reconstruits de manière fiable si nécessaire.

Un des principaux défis est de maintenir et valider les modèles à jour, en particulier lorsque les applications évoluent et que les versions des systèmes d’exploitation changent. Il est crucial de se rappeler que lors de l’utilisation de l’infrastructure comme code, toutes les modifications doivent être effectuées à travers celui-ci, assurant la versionnement de la configuration et l’immuabilité de l’environnement. Échouer à ce point pourrait provoquer la réinitialisation de l’environnement à son état défini, éventuellement écrasant les modifications manuelles.

Le modèle proposé dans cet article est polyvalent et applicable à des environnements à la fois locaux et multi-cloud, ce qui en fait une solution efficace pour les infrastructures hybrides.