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 : module finalisation & routes. Transformer le sujet "Terraform : module finalisation & routes" en ressources OpenStack versionnées: instance, variables, réseau, groupes de sécurité et exposition contrôlée.
La vidéo de référence
Vidéo: https://www.youtube.com/watch?v=NXW9MQG09ok
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 95-terraform-instance-v2-part2.
Objectif précis de l épisode
Transformer le sujet "Terraform : module finalisation & routes" en ressources OpenStack versionnées: instance, variables, réseau, groupes de sécurité et exposition contrôlée.
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 : module finalisation & routes: 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, kubernetes.
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 : module finalisation & routes.
Ce que la vidéo cherche à modifier
- définir ou ajuster les ressources Terraform du chapitre
- lier les variables Terraform aux paramètres OpenStack attendus
- préparer les règles réseau nécessaires à l administration et aux services
- prévoir le nettoyage des routes OpenStack lors du destroy
- éviter de conserver des routes mortes dans le routeur
- Kubernetes: instance module improvements – part2
Indices extraits des slides
- Kubernetes: instance module improvements – part2
- Change openstack_networking_floatingip_v2 pool usage with datasource
- pool = var.instance_network_external_name
- subnet_ids = data.openstack_networking_subnet_ids_v2.ext_subnets[0].ids
- pool = data.openstack_networking_network_v2.network[count.index].name
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.
- kubernetes: Kubernetes orchestre des conteneurs sur un cluster: pods, deployments, services, CNI, kubeadm, Helm et intégration avec Terraform/Consul/monitoring.
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 : module finalisation & routes 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.
- Valider les objets Kubernetes créés et leur intégration avec le réseau et le monitoring.
Approfondissement spécifique
Pour Terraform : module finalisation & routes, le point central est la traduction entre variables Terraform et objets OpenStack. Le code ne décrit pas seulement une machine: il fixe aussi l image, le flavor, le réseau, les groupes de sécurité et éventuellement l IP publique qui rend l instance joignable.
Le bon niveau de lecture consiste à suivre le chemin variable -> ressource Terraform -> objet OpenStack -> test réseau. Si une instance existe mais reste injoignable, le problème est souvent dans l IP flottante, la route, le security group ou le réseau attaché.
La partie routes/destroy est spécifique parce qu elle traite le cycle de vie inverse: supprimer proprement ce que le cluster ou Terraform a ajouté dans OpenStack. Une route oubliée peut laisser une infrastructure incohérente même après destruction des ressources Kubernetes.
Exemple de code ou configuration du dépôt
Les exemples complets sont dans les répertoires du chapitre listés plus bas.
Chemin de diagnostic recommandé
- relire le plan Terraform avant application
- vérifier l instance, son réseau et son IP côté OpenStack
- contrôler que les groupes de sécurité exposent uniquement les ports nécessaires
- vérifier la table de routage OpenStack après suppression
- confirmer que le playbook de nettoyage est appelé au bon moment
- 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: 95-terraform-instance-v2-part2
- Répertoire support: 95-terraform-instance-v2-part2/code/ansible
- Répertoire support: 95-terraform-instance-v2-part2/code/terraform
Pièges fréquents
- ouvrir SSH ou HTTP trop largement
- confondre IP privée, IP flottante et réseau interne
- modifier le state Terraform sans comprendre les impacts
- laisser des routes vers des réseaux Kubernetes supprimés
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.
- Kubernetes 003 – architecture pour revoir les composants du control plane.
Pour continuer, lire Infra A à Z 097 – Kubernetes : fix et mise en place de consul sync catalog.
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 96 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.