Aller au contenu

Provisioning Host HeyMoov

Objet

Ce document fixe la cible de provisioning des serveurs HeyMoov.

Il est la référence publiée pour le socle host. L'automation exécutable et versionnée vit dans heymoov-platform. Les repositories applicatifs peuvent documenter les contrats qu'ils consomment, mais ne doivent pas dupliquer les décisions de provisioning.

Périmètre

Ce document couvre :

  • la séparation entre provisioning host et bootstrap d'environnement ;
  • la chaîne cible OpenStack, Terraform, cloud-init et Ansible ;
  • les emplacements cibles des binaires plateforme ;
  • la répartition entre package manager, Ansible et scripts applicatifs.

Ce document ne couvre pas :

  • les secrets réels ;
  • les variables runtime propres à dev, staging ou prod ;
  • les détails applicatifs de chaque repository ;
  • les rôles Ansible finaux tant qu'ils ne sont pas créés ;
  • le détail des commandes opérateur, documenté dans les runbooks.

Décision Cible

La chaîne cible est :

  • Terraform/OpenStack : création des VMs, réseaux, volumes, security groups, floating IPs et metadata de base ;
  • cloud-init : mise en condition initiale de la VM, accès SSH, users de base, sudo, Python et prérequis minimaux pour Ansible ;
  • Ansible : installation idempotente du socle OS et des dépendances plateforme du host ;
  • heymoov-platform : provisioning bas niveau, puis bootstrap d'environnement sur un host conforme.

Les scripts d'environnement ne provisionnent pas le host. Ils partent d'un serveur déjà conforme.

Répartition Des Responsabilités

Package Manager OS

Le package manager installe et maintient le socle système :

  • PostgreSQL ;
  • Redis ;
  • Nginx ;
  • Certbot ;
  • Python ;
  • systemd et librairies système ;
  • paquets de sécurité et d'exploitation courants.

Ansible

Ansible installe et maintient les dépendances plateforme qui ne doivent pas dépendre d'un package distro imprécis :

  • Hydra ;
  • Mercure/Caddy custom ;
  • outils plateforme spécifiques ;
  • users, groupes, permissions et répertoires de socle ;
  • symlinks de version active ;
  • éventuels symlinks opérateur dans /usr/local/bin.

Ansible doit pinner les versions, vérifier les checksums et rester idempotent.

Repository Plateforme

heymoov-platform porte l'automation de plateforme :

  • le provisioning bas niveau à ajouter ;
  • le bootstrap qui installe ou vérifie les environnements sur un host déjà conforme.

Pour le bootstrap d'environnement, il porte déjà :

  • inventory et résolution de topologie ;
  • bootstraps d'environnement ;
  • templates nginx, env et systemd ;
  • webroots statiques ;
  • runners et environnements GitHub.

Repositories Applicatifs

Les repositories applicatifs gèrent :

  • le code applicatif ;
  • les migrations applicatives ;
  • les workflows applicatifs ;
  • les contrats et notes locales fortement couplés au code.

Emplacements Cibles

Les binaires plateforme installés hors package manager sont versionnés sous un préfixe unique :

/opt/heymoov-platform/
  bin/
    hydra -> ../hydra/current/hydra
    mercure -> ../mercure/current/mercure
  hydra/
    <version>/hydra
    current -> <version>
  mercure/
    <version>/mercure
    current -> <version>

Chemins stables consommés par les services et les scripts :

/opt/heymoov-platform/bin/hydra
/opt/heymoov-platform/bin/mercure

Règles :

  • chaque version est installée dans son propre répertoire ;
  • current est un symlink atomique vers la version active ;
  • /opt/heymoov-platform/bin expose le contrat runtime court et stable ;
  • les services systemd utilisent les chemins absolus ci-dessus ;
  • les scripts de bootstrap utilisent les chemins fournis par la topologie/provisioning, pas une découverte implicite via PATH ;
  • un symlink dans /usr/local/bin peut exister pour le confort opérateur, mais il ne constitue pas le contrat runtime.

Séparation Runtime

Les binaires plateforme sont partagés au niveau host. L'isolation par environnement porte sur :

  • les services systemd ;
  • les fichiers de configuration ;
  • les ports internes ;
  • les bases et stockages ;
  • les secrets ;
  • les clients OAuth2/OIDC ;
  • les webroots et uploads.

Exemple :

/opt/heymoov-platform/bin/hydra
/etc/heymoov/hydra-dev.env
/etc/heymoov/hydra-staging.env
/etc/systemd/system/heymoov-dev-hydra.service
/etc/systemd/system/heymoov-staging-hydra.service

Contrat Pour Les Bootstraps Applicatifs

Un bootstrap d'environnement peut supposer que le host fournit déjà :

  • gopher ;
  • devs ;
  • heymoov-deploy ;
  • /etc/heymoov ;
  • /usr/local/bin/heymoov-goose ;
  • /opt/heymoov-platform/bin/hydra ;
  • /opt/heymoov-platform/bin/mercure ;
  • PostgreSQL ;
  • Redis ;
  • Nginx ;
  • Certbot.

Un bootstrap d'environnement ne doit pas :

  • télécharger Hydra ;
  • télécharger Mercure ;
  • modifier la topologie OpenStack ;
  • installer le socle OS ;
  • dépendre d'un command -v hydra ou command -v mercure comme contrat principal.

État ls2i-staging

Au 2026-05-01, ls2i-staging est aligné sur le contrat plateforme cible :

  • Hydra est disponible sous /opt/heymoov-platform/hydra/26.2.0/hydra ;
  • Mercure est disponible sous /opt/heymoov-platform/mercure/0.23.2/mercure ;
  • /opt/heymoov-platform/hydra/current pointe vers 26.2.0 ;
  • /opt/heymoov-platform/mercure/current pointe vers 0.23.2 ;
  • /opt/heymoov-platform/bin/hydra pointe vers ../hydra/current/hydra ;
  • /opt/heymoov-platform/bin/mercure pointe vers ../mercure/current/mercure ;
  • les services heymoov-dev-hydra.service et heymoov-dev-mercure.service utilisent les chemins courts ;
  • /etc/heymoov conserve le bit de traversal nécessaire au process Mercure, les fichiers sensibles restant protégés par leurs modes fichiers.

Les anciens chemins /opt/hydra/bin/hydra et /opt/mercure/mercure existent encore pour rollback historique, mais ne constituent plus le contrat runtime cible.