Infra de A à Z 011 – Terraform – state distant sur gitlab

TL;DR

Cette série construit progressivement une infrastructure cloud complète sur Infomaniak Public Cloud. Dans cet épisode, le sujet précis est: Terraform – state distant sur gitlab. Traiter GitLab dans "Terraform – state distant sur gitlab": installation, registry, sauvegardes ou intégration avec le workflow infrastructure.

La vidéo de référence

Vidéo: https://www.youtube.com/watch?v=hc8Gdtauo5Q

Playlist complète: https://www.youtube.com/playlist?list=PLn6POgpklwWpehxly1wOT6eB2NvZX9A-X

Le dépôt support est disponible ici: https://gitlab.com/xavki/infrastructure-cloud-infomaniak. Le chapitre correspondant est 10-terraform-external-state.

Objectif précis de l épisode

Traiter GitLab dans "Terraform – state distant sur gitlab": installation, registry, sauvegardes ou intégration avec le workflow infrastructure.

Concrètement, cet épisode sert à passer d une intention formulée dans le titre à une modification vérifiable dans l infrastructure. Le dépôt donne les fichiers, la vidéo donne l ordre de manipulation, et la vérification doit confirmer que la brique fonctionne vraiment.

Terraform – state distant sur gitlab: c est quoi exactement ?

Dans une infrastructure cloud réelle, chaque épisode ajoute une brique: réseau, compute, sécurité, automatisation, découverte de services, observabilité, sauvegardes ou orchestration. Ici, les outils détectés sont: terraform, openstack, gitlab.

Dans cet épisode, il faut surtout regarder les éléments qui correspondent au titre: les ressources créées ou modifiées, les fichiers du chapitre, les services touchés et la preuve de fonctionnement. Les outils détectés donnent le contexte, mais le fil rouge reste Terraform – state distant sur gitlab.

Ce que la vidéo cherche à modifier

• configurer le backend distant
• centraliser le state Terraform
• séparer code versionné et état sensible
• configurer les services GitLab nécessaires
• préparer stockage, registry ou backups
• relier GitLab au reste de la plateforme

Indices extraits des slides

• Terraform – remote state with gitlab
• address = "https://gitlab.com/api/v4/projects/<id_projet_gitlab>/terraform/state/<state_name>&quot;
• lock_method = "POST"
• unlock_method = "DELETE"
• retry_wait_min = 5

Notions et définitions des outils

• terraform: Terraform décrit l infrastructure comme du code. Le provider OpenStack transforme des ressources HCL en objets cloud: réseaux, routeurs, instances, volumes, groupes de sécurité.
• openstack: OpenStack est la couche cloud IaaS: instances, réseaux, routeurs, IP flottantes, groupes de sécurité, volumes et images. Chez Infomaniak Public Cloud, il sert de socle programmable via GUI, CLI, Terraform et API.
• gitlab: GitLab apporte forge Git, CI/CD, registry, sauvegardes et workflows d équipe pour industrialiser le code infrastructure et applicatif.

Ces définitions sont volontairement pratiques: elles expliquent à quoi sert l outil dans la chaîne, pas seulement ce qu il est sur le papier.

Points clés à retenir pour cet épisode

• Comprendre le rôle de Terraform – state distant sur gitlab dans la progression globale de l infrastructure.
• Identifier la couche concernée: cloud, automatisation, réseau, service, observabilité ou orchestration.
• Relier les fichiers du dépôt au résultat attendu sur les machines ou dans le cloud.
• Séparer clairement la création des ressources cloud du paramétrage applicatif.

Approfondissement spécifique

Le state distant GitLab devient la source de vérité de Terraform. L épisode ne porte donc pas seulement sur une option de configuration: il déplace une donnée critique hors du poste local pour rendre le travail partageable et récupérable.

La vérification importante est de savoir où Terraform lit et écrit réellement son état après init. Un dépôt Git propre ne suffit pas: il faut confirmer que le backend distant répond, que les droits sont maîtrisés et que le state local n est plus la référence.

Pour Terraform – state distant sur gitlab, GitLab est une brique plateforme: accès web, Git, registry, stockage et sauvegardes doivent rester cohérents. Le titre indique quelle partie de GitLab est ajoutée ou durcie.

Sur une registry Docker, la vérification doit couvrir l URL externe, l exposition HTTP/HTTPS, l authentification et un push/pull réel. Pour les backups, la preuve minimale est de savoir où ils sont stockés et comment les restaurer.

Exemple de code ou configuration du dépôt

backend "http" {
    address = "https://gitlab.com/api/v4/projects/<id_projet_gitlab>/terraform/state/<state_name>"
    lock_address = "https://gitlab.com/api/v4/projects/<id_projet_gitlab>/terraform/state/<state_name>/lock"
    unlock_address = "https://gitlab.com/api/v4/projects/<id_projet_gitlab>/terraform/state/<state_name>/lock"
    lock_method = "POST"
    unlock_method = "DELETE"
    retry_wait_min = 5
  }

Cet extrait doit être lu comme un support pédagogique. Avant de l utiliser tel quel, vérifiez les variables, noms de réseau, plages CIDR, identifiants, secrets, régions, images et règles d exposition.

Chemin de diagnostic recommandé

• vérifier l initialisation du backend
• confirmer que le state n est plus uniquement local
• contrôler les droits GitLab associés
• tester accès web et clone Git
• vérifier la registry ou les backups si concernés
• contrôler les services GitLab côté machine
• Comparer l état attendu dans le dépôt et l état réel dans le cloud, la machine ou le cluster.
• Documenter la commande, l écran ou la métrique qui prouve que l étape est fonctionnelle.

Répertoires et commandes utiles

• Répertoire support: 10-terraform-external-state

Pièges fréquents

• commiter un state local
• perdre les credentials du backend
• lancer deux modifications concurrentes sans verrouillage clair
• oublier la sauvegarde GitLab
• mal exposer la registry
• négliger les volumes persistants

Liens utiles externes

• Dépôt Xavki infrastructure-cloud-infomaniak
• Playlist YouTube Infra de A à Z
• docs.infomaniak.cloud
• docs.infomaniak.cloud/getting_started/first_project
• docs.infomaniak.cloud/compute/instances
• docs.infomaniak.cloud/orchestration/terraform
• developer.hashicorp.com/terraform/docs
• registry.terraform.io/providers/terraform-provider-openstack/openstack/latest/docs

Liens internes conseillés

• Parcours Kubernetes pour relier la partie cluster et orchestration.
• Prometheus, Grafana et observabilité pour approfondir métriques et dashboards.

Pour continuer, lire Infra A à Z 012 – Ansible – introduction.

FAQ

Pourquoi utiliser Terraform et Ansible ensemble ?

Terraform est adapté à la création et au cycle de vie des ressources cloud. Ansible est adapté à la configuration des machines et services. Les mélanger sans frontière claire rend les changements difficiles à relire.

Pourquoi Infomaniak/OpenStack dans cette série ?

Infomaniak Public Cloud expose des concepts OpenStack standards: compute, réseau, volumes, security groups, object storage, identity et orchestration. Cela permet d apprendre des notions transférables tout en travaillant sur un fournisseur concret.

Que faut-il sécuriser en premier ?

Les accès: credentials cloud, state Terraform, SSH, VPN, dashboards, secrets Ansible, tokens GitLab, consoles d administration et ports exposés publiquement. Une infrastructure automatisée amplifie aussi les erreurs de sécurité.

Comment savoir si une étape est terminée ?

Chaque étape doit produire une preuve: une ressource visible, un service joignable, une métrique collectée, un backup restaurable, une requête qui répond ou un déploiement qui converge.

Conclusion

L épisode 11 s inscrit dans une progression complète: construire, automatiser, sécuriser, observer et exploiter une infrastructure cloud. Le dépôt Xavki donne les exemples concrets, la documentation Infomaniak/OpenStack donne le cadre fournisseur, et le deep dive permet de comprendre le rôle des outils au lieu de seulement rejouer des commandes.