Skip to main content

🚀 Architecture DevOps : Refonte CI/CD et Gestion de Configuration

Auteur : Administrateur Homelab
Date de révision : Avril 2026


1. Le Changement de Paradigme : Pourquoi cette refonte ?

Historiquement, notre cluster Kubernetes (via Tekton) gérait l'intégralité de la chaîne logicielle : de la fabrication des images Docker jusqu'à l'exécution de scripts Ansible via des Pods éphémères pour mettre à jour des serveurs. Cela créait plusieurs problèmes :

  • Surcharge de K8s : CrĂ©ation de Pods, PVC, et gestion de secrets lourds juste pour lancer un apt-get update ou un rsync.
  • Manque de visibilitĂ© : Les logs d'exĂ©cution Ansible Ă©taient perdus dès la destruction du Pod Tekton.
  • Mauvaise gestion du temps : Les tâches planifiĂ©es (Cron) saturaient l'API Kubernetes.

La Solution : La séparation des responsabilités (Séparation CI / CD).

  • 🏗️ Tekton (CI - Continuous Integration) : Son rĂ´le strict est dĂ©sormais de "fabriquer". Il Ă©coute Git, clone le code, compile, et pousse des artefacts (ex: images Docker via Kaniko).
  • ⚙️ AWX (CD - Continuous Deployment / Configuration) : Son rĂ´le est de "dĂ©ployer et configurer". Il dĂ©tient les clĂ©s SSH, se connecte aux machines (Proxmox, Synology, HA) et applique les Playbooks Ansible.

2. L'Organisation Ansible : Le "Clean Code"

Pour supporter cette architecture, l'inventaire monolithique a été découpé selon les meilleures pratiques (DRY - Don't Repeat Yourself) en exploitant la pyramide de préséance d'Ansible.

La pyramide de préséance (Du plus faible au plus fort) :

  1. Defaults des Rôles (Niveau 1) : roles/mon_role/defaults/main.yml. Ex: allow_reboot: false. C'est la sécurité par défaut.
  2. Variables de Groupes (Niveau 2) : group_vars/*.yml. Ex: ansible_user: root pour tout le monde, écrasé par ansible_user: nancre dans group_vars/vm.yml.
  3. Variables d'Hôtes (Niveau 3) : host_vars/nom_host.yml. Ex: Port SSH 22022 spécifique au NAS Synology.
  4. Variables AWX (Niveau 4 - God Mode) : Paramètres passés via l'interface AWX (Extra Vars) lors d'un lancement manuel pour écraser toute autre règle.

Structure de l'Inventaire (Aperçu)


all:
  children:
    proxmox_hypervisors:
      hosts:
        proxmox-server:
          ansible_host: 10.151.151.249
        proxmox-ms:
          ansible_host: 10.151.151.239
    # ... Les variables spécifiques sont désormais dans group_vars/ et host_vars/
    

3. Les Workflows Clés : Comment on fait ?

A. La Synchronisation Événementielle (Ex: Homer)

Logique : Quand un fichier de configuration change sur Git, Tekton s'en aperçoit, mais délègue le déploiement à AWX.

  • Git : Push sur infra/kubernetes/homer/config/.
  • Tekton : Le Trigger s'active. La Task appelle la commande gĂ©nĂ©rique trigger-awx-job avec l'ID du Job Template.
  • AWX : RĂ©ceptionne l'API call, lance le Playbook sync_homer_ha.yml, et se connecte en SSH au Home Assistant (port 22) avec son Machine Credential chiffrĂ© pour copier les fichiers dans /addon_configs/.

B. Les Tâches Planifiées (Ex: Maintenance OS & Docker Prune)

Logique : On supprime les CronJobs de Kubernetes. Le Scheduler natif d'AWX prend le relais.

  • AWX (Job Template) : Pointage sur maintenance_update_os.yml ou maintenance_docker_prune.yml.
  • Schedules : PlanifiĂ©s nativement via l'UI AWX (ex: Tous les dimanches Ă  23h00). Attention au bug d'interface d'AWX liĂ© au fuseau horaire (UTC vs Europe/Paris) : il faut dĂ©finir l'heure de dĂ©part (DTSTART) et laisser l'heure de la règle (RRULE) vide, ou passer par un appel API curl en cas de blocage.
  • Robuste (Multi-NĹ“uds) : Le rĂ´le de mise Ă  jour dĂ©tecte dynamiquement sur quel hyperviseur tourne une VM (grâce Ă  la variable pve_node) pour exĂ©cuter les commandes d'API de secours (ex: qm reset) en ciblant le bon hĂ´te Proxmox ou Synology.

C. La Fabrication pure (Ex: code-server)

Logique : Reste 100% dans Kubernetes, car c'est du "Build" (CI).

  • Git : CrĂ©ation et Push d'un Tag (ex: v2.8).
  • Tekton :
    1. Utilise custom-git-clone pour récupérer le Dockerfile avec les clés SSH.
    2. Utilise la Task kaniko pour compiler l'image dans un Pod (utilise les ressources K8s, sans daemon Docker).
    3. Pousse l'image vers la registry privée Harbor : docker-registry.numericare.fr/private/code-server:v2.8.

4. Bilan et Bénéfices

  • 📉 Baisse de la charge K8s : Moins de pods Ă©phĂ©mères, moins de montages de PVC inutiles.
  • đź”’ SĂ©curitĂ© renforcĂ©e : Les clĂ©s SSH et les accès NAS/Proxmox sont chiffrĂ©s et gĂ©rĂ©s par le gestionnaire d'identifiants d'AWX, plus dans des ConfigMaps/Secrets K8s Ă©parpillĂ©s.
  • 📊 ObservabilitĂ© : Chaque exĂ©cution Ansible a dĂ©sormais une interface visuelle, un historique, et un rapport d'erreurs dĂ©taillĂ© dans AWX.