Infra de A à Z 101 – Helm: demo, automation vs. industrialization??!!

TL;DR

Cette série construit progressivement une infrastructure cloud complète sur Infomaniak Public Cloud. Dans cet épisode, le sujet précis est: Helm: demo, automation vs. industrialization??!!. Faire avancer la partie Kubernetes autour de "Helm: demo, automation vs. industrialization??!!": objets cluster, réseau, stockage, monitoring ou packaging selon l épisode.

La vidéo de référence

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

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 100-kubernetes-helm-instanciation.

Objectif précis de l épisode

Faire avancer la partie Kubernetes autour de "Helm: demo, automation vs. industrialization??!!": objets cluster, réseau, stockage, monitoring ou packaging selon l épisode.

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.

Helm: demo, automation vs. industrialization??!!: 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: openstack, consul, traefik, kubernetes, helm.

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 Helm: demo, automation vs. industrialization??!!.

Ce que la vidéo cherche à modifier

• modifier les manifests, charts ou playbooks liés au cluster
• vérifier l interaction entre Kubernetes et OpenStack
• garder un chemin de diagnostic kubectl clair
• Kubernetes: Helm instanciation
• Imagine you need to deploy from 1 to N nginx instances ?
• and you have a kubernetes cluster

Indices extraits des slides

• Kubernetes: Helm instanciation
• Imagine you need to deploy from 1 to N nginx instances ?
• and you have a kubernetes cluster
• Helm is your friend 😉
• a deployement

Notions et définitions des outils

• 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.
• consul: Consul apporte service discovery, DNS interne, health checks et catalogue de services. Il relie machines, proxy, monitoring et automatisation.
• traefik: Traefik est un reverse proxy dynamique. Il route HTTP/HTTPS vers des backends et peut se configurer via Consul ou annotations Kubernetes.
• kubernetes: Kubernetes orchestre des conteneurs sur un cluster: pods, deployments, services, CNI, kubeadm, Helm et intégration avec Terraform/Consul/monitoring.
• helm: Helm est le gestionnaire de packages de Kubernetes. Un chart regroupe templates, valeurs et dépendances; une release est une instance déployée de ce chart dans un cluster.

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 Helm: demo, automation vs. industrialization??!! 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.
• Valider les objets Kubernetes créés et leur intégration avec le réseau et le monitoring.

Approfondissement spécifique

Dans Helm: demo, automation vs. industrialization??!!, Kubernetes doit être relié au socle OpenStack et aux playbooks du dépôt. Le cluster n est pas isolé: réseau, routes, volumes, DNS et monitoring dépendent encore des choix faits autour de l infrastructure.

La lecture utile part des objets Kubernetes concernés, puis descend vers les events, les services, le CNI, les routes OpenStack ou les volumes Cinder selon le sujet de l épisode.

Exemple de code ou configuration du dépôt

apiVersion: apps/v1
kind: Deployment
metadata:
  name: mynginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: mynginx
  template:
    metadata:
      labels:
        app: mynginx
    spec:
      containers:
        - name: mynginx
          image: nginx:latest
          ports:
          - containerPort: 80
          volumeMounts:
            - name: html
              mountPath: "/usr/share/nginx/html/"
              readOnly: true
      volumes:
        - name: html
          configMap:
            name: mynginx

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é

• contrôler les pods, services et events
• vérifier les routes, CNI ou volumes si le sujet les touche
• tester la configuration depuis le cluster et depuis l extérieur
• 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: 100-kubernetes-helm-instanciation

• Commande repérée: helm create instancier
• Commande repérée: helm install t1 instancier/
• Commande repérée: helm install i1 instancier --values=values.yaml

Pièges fréquents

• diagnostiquer Kubernetes sans regarder les events
• oublier le lien avec réseau OpenStack
• déployer un chart sans maîtriser les values

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
• docs.infomaniak.cloud/network/networks
• docs.infomaniak.cloud/network/security_groups

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 102 – Helm & Fix : grafana et édition des routes avec ansible.

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 101 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.