Aller au contenu

ADR-0030 — Cible d'exécution : l'axe « serveur » est orthogonal au cercle et au couloir

Date : 2026-08-11 Catégorie : B (modèle de déploiement plateforme) Décideur : Lead architecte DYNORS — à valider CTO Statut : Proposée S'appuie sur : [[0016-nomenclature-environnements-int-rmoa]] (cercles), [[0017-couloir-lane-unite-execution-explicite]] (couloirs), [[0019-modele-sirrat-dimension-couloir]] (attributs de couloir) Sources : applications/sirrat/backend/.../port/DeploymentExecutor.java (champ target du contrat) ; .../service/DeploymentExecutionService.java (valeur "ref" codée en dur) ; .../model/Deployment.java ; dynors-ops/inventories/{staging,production}/hosts.yml

Contexte

La production DYNORS ne tiendra pas sur un serveur unique : plusieurs applications d'un même cercle devront tourner sur des machines distinctes. Or l'état du code suppose l'inverse, de manière implicite — donc jamais discutée.

Constats vérifiés :

  1. Le contrat d'agent prévoit une cible : DeploymentCommand(applicationId, componentId, environment, **target**, artifactRef, requestedBy, metadata). Mais DeploymentExecutionService y écrivait "ref" — c'est-à-dire le couloir. Le champ existait, on y mettait autre chose.
  2. Deployment portait environment, laneCode, appCode — aucun hôte. La question « la version 1.2.3 tourne sur quel serveur ? » était sans réponse.
  3. SirratProject.hosting et SirratLane.hosting existent, mais au sens ADR-0019 : qui héberge (dynors / client), pas sur quelle machine.
  4. Les inventaires ops ne déclarent qu'un hôte par cercle (vps-prod-01, vps-staging-01).
  5. sirrat_api_url: http://localhost:8085/sirrat/api dans les deux inventaires — SIRRAT est supposé co-localisé avec l'application déployée.

Confondre couloir et serveur n'était pas gênant tant que le cercle tenait sur une machine. Ça le devient dès qu'il s'étend.

Décision

  1. Trois axes distincts et indépendants :
Axe Question Porté par
Cercle (ADR-0016) à quel stade du cycle ? env_code
Couloir (ADR-0017) quelle unité d'exécution parallèle ? lane_code
Cible (cette ADR) sur quelle machine ? deployment_target

Un couloir n'implique pas un serveur, et un serveur n'implique pas un couloir.

  1. Une instance SIRRAT par cercle protégé, pas par serveur. L'instance de production pilote le cercle production, quel que soit le nombre de machines. Une instance par serveur ferait perdre ce qui justifie un plan de contrôle : la vue consolidée « quelle version tourne où », le karma par projet, l'état des gates.

  2. La cible est déclarée sur la stack (projet, cercle, couloir) — champ sirrat_environment_stack.deployment_target. Une valeur nulle signifie « cible par défaut du cercle » : le comportement mono-serveur actuel reste valide et par défaut.

  3. La cible retenue est tracée sur le déploiement — sirrat_deployments.target_host. Sans cela, l'audit ne peut pas répondre à où un déploiement a eu lieu.

  4. L'agent résout la cible, SIRRAT la désigne. SIRRAT ne connaît ni SSH, ni Docker, ni inventaire : il transmet une cible logique dans target. L'agent — enveloppe des playbooks Ansible — la traduit en --limit ou en groupe d'inventaire. Un agent central suffit : Ansible sait déjà atteindre N hôtes.

Conséquences

Positif : le multi-serveur devient déclaratif, sans changer le contrat d'agent (le champ existait) ; la traçabilité « quelle version, sur quelle machine » devient possible ; le choix d'un agent-enveloppe Ansible rend le multi-serveur presque gratuit — un agent par machine aurait exigé un déploiement, une rotation de secret et une résolution d'URL par cible.

Coût / risques : sirrat_api_url en localhost doit disparaître des inventaires dès que les applications se répartissent — un playbook exécuté sur un hôte ne trouvera plus SIRRAT en local. DeployAgentProperties n'a qu'une base-url unique : cela reste suffisant avec un agent central, mais bloquerait une topologie « un agent par machine ». Le référentiel des cibles (quel serveur existe, lequel est sain) reste hors SIRRAT : c'est l'inventaire ops.

Composants impactés : SirratEnvironmentStack (+ deployment_target), Deployment (+ target_host), DeploymentExecutionService (résolution du placement au lieu de "ref"), changeset 028-sirrat-deployment-target, inventaires dynors-ops, agent de déploiement, UI SIRRAT (afficher la cible dans le détail d'un déploiement).

Alternatives écartées

  • Une instance SIRRAT par serveur : perd la vue consolidée du cercle, multiplie les bases et les gates à réconcilier. Écartée.
  • La cible portée par le couloir : un couloir peut légitimement s'étendre sur plusieurs machines, et en production il n'y a qu'un couloir (ref) pour toutes les applications — insuffisant pour les distinguer. Écartée.
  • La cible portée par le projet : rend une application incapable d'avoir un placement différent selon le cercle. Écartée.

Reste à trancher

  • Réplication : une stack sur plusieurs cibles simultanées (aujourd'hui une seule). À traiter quand le besoin apparaîtra — le champ deviendrait une liste.
  • Santé des cibles : SIRRAT doit-il refuser un déploiement vers une cible déclarée hors service, ou laisser l'agent échouer ? Suppose une source de vérité sur l'état des machines.