Module VII — déploiement et intégration

Les définitions de déploiement, les plans, les apply, les rollbacks, les retraits, la configuration de l’exécuteur et le registre de câblage sont des fonctions Business. Community répond 501 sur ces routes API et masque le groupe de commandes. Les définitions, révisions, câblages et opérations enregistrés restent dans la base de données et dans les sauvegardes de reprise. Les sections ci-dessous décrivent le comportement Business.

Le module VII est le seul module qui mute l’infrastructure du client — toute autre partie du produit est read-first. Il provisionne, met à jour et retire des agents et des serveurs MCP sous forme d’opérations déclaratives, versionnées, réversibles, et déclare la connectivité et l’identité référencée qu’un agent utilise pour atteindre une ressource d’entreprise. Parce qu’il agit, son exigence de sécurité est la plus élevée du produit, et l’actionnement en direct est maintenu derrière une jonction deny-closed jusqu’à ce qu’un opérateur la provisionne explicitement.

Planifier et gouverner, puis (peut-être) appliquer

Le cycle de vie est plan → apply → verify → retire, réconciliant un état désiré avec l’état réel. La distinction qui compte est déclarer ≠ muter :

• Déclarer l’état désiré — créer, mettre à jour, faire un rollback d’une définition (également via la ressource manage-as-code olivares_deployment) — relève uniquement du control plane et ne touche jamais à l’infrastructure.
• plan est un diff dry-run pur ; verify vérifie la dérive et rafraîchit le snapshot. Aucun des deux ne mute.
• apply et retire sont les seules opérations mutantes. Elles sont en deux phases et deny-by-default : la phase un calcule le diff et demande une approbation humaine liée au hash du plan sans rien changer ; la phase deux ne se poursuit que si l’approbation est approved et que le hash du plan correspond toujours — tout autre état (pending, expired, rejected, pas de gate, plan obsolète) est refusé et enregistré. Re-spécifier des changements modifie le hash et invalide l’approbation (anti-TOCTOU).

L’apply/retire mutant n’est pas en direct par défaut. La jonction d’actionnement (Executor) est deny-closed : sans exécuteur provisionné, apply/retire/plan/verify échouent en fail closed avec un 503 — le control plane peut déclarer l’état désiré mais ne peut pas réconcilier avec l’infrastructure réelle. Un véritable moteur (Tofu/Terraform, GitOps, Kubernetes, Docker, Nomad, Crossplane) plus une source de credentials attestée, éphémère et par opération, ne se câblent que sur configuration de l’opérateur ; à défaut, le module n’agit jamais en silence.

Connecter un exécuteur

Tant qu’un administrateur n’a pas connecté d’exécuteur, Deploy conserve vos définitions de déploiement et ne modifie aucune infrastructure. Pour en connecter un :

1. Écrivez un fichier JSON avec un bloc pour chaque runtime sur lequel vous déployez (docker, k8s, nomad, tofu, terraform, gitops ou crossplane) et un bloc credential. Seuls les runtimes présents dans le fichier sont connectés. Pour Docker sur le même hôte :

   {
     "docker": { "socket_path": "/var/run/docker.sock" },
     "credential": {
       "kind": "file",
       "path_template": "/run/olivares/deploy/{env}-{mode}.token",
       "ttl_seconds": 900
     }
   }

   Pour chaque opération, Olivares lit un jeton de courte durée depuis path_template : {env} est l’environnement de la définition et {mode} vaut read (Planifier, Vérifier) ou write (Appliquer, Retirer). Un outil que vous exécutez déjà, comme Vault Agent ou un assistant SPIFFE, crée leur répertoire puis écrit et renouvelle ces fichiers. Sans jeton, chaque opération est refusée. Pour Docker, l’utilisateur de service olivares doit aussi pouvoir ouvrir le socket ; l’appartenance au groupe docker lui donne un accès root à cet hôte.

2. Indiquez le fichier à Olivares. Avec le paquet deb ou rpm, ajoutez cette ligne à /etc/olivares/olivares.env :

   OLIVARES_DEPLOY_EXECUTOR_CONFIG=/etc/olivares/deploy-executor.json

   L’utilisateur olivares doit pouvoir lire le fichier JSON, par exemple avec le propriétaire root:olivares et le mode 0640.

3. Redémarrez Olivares avec sudo systemctl restart olivares. Si le fichier est illisible ou invalide, Olivares ne démarre pas et son journal indique pourquoi.

La page Deploy propose alors Déclarer un déploiement comme action principale, et Planifier et Appliquer atteignent le runtime. Chaque Appliquer et Retirer attend toujours une approbation.

Entités et le contrat déclaré

Le module déclare quatre entités namespacées plus le Deployment du cœur comme snapshot appliqué :

Entité	Rôle
definition	état désiré — version désirée vs appliquée, hash de spec, lien vers le Deployment du cœur
revision	historique de spec append-only, immuable — la source réversible pour le rollback
wiring	la connectivité permise agent → resource qu’il déclare (le contrat que le module III met en regard)
operation	registre de change-management append-only — version, hash de plan, qui a approuvé, résultat

La spec désirée est typée et re-sérialisée à partir de la structure (jamais un aller-retour JSON de l’opérateur) : les champs inconnus sont rejetés, une garde anti-credential-inline s’exécute, et une spec portant du matériel de credential en clair est refusée à la déclaration. Les credentials voyagent par référence uniquement (<scheme>:<locator>, schéma sur allow-list) — une propriété du fil, jamais un secret stocké.

Ce qu’il produit sur le bus (le côté PERMITTED du module III)

Le module VII n’écrit jamais l’access map ; le module III est le seul rédacteur de ses arêtes. Lors d’un apply committé, pour chaque wiring le module publie un événement edge.observed de type policy-grant (Source = policy) ne portant que des références et le mode. Le module III le réconcilie dans le côté PERMITTED de son diff permitted-vs-observed — de sorte que ce que ce module déclare est exactement ce que le module III met en regard de ce qu’il observe. L’identité est liée par agent via la gouvernance : une identité non humaine ferme et unique produit une arête attributed ; une identité partagée ou absente est rapportée comme approximate — marquée, jamais falsifiée.

Limites honnêtes

• L’apply en direct est une jonction deny-closed. Sans exécuteur provisionné, apply/retire (et plan/verify) renvoient un 503 clair. Le module planifie, gouverne, versionne et déclare l’état désiré aujourd’hui ; il ne réconcilie avec l’infrastructure réelle qu’une fois qu’un opérateur a câblé un exécuteur — jamais par défaut, jamais un no-op silencieux.
• L’approbation et l’attribution échouent aussi en sécurité. Sans le gate d’approbation, chaque mutation est refusée ; sans le lieur d’identité, l’attribution d’un wiring est dégradée, pas fabriquée. Start() avertit une fois par jonction non câblée afin qu’un déploiement cassé soit visible.
• Retirer un wiring ne rétracte pas son arête PERMITTED publiée. Le modèle d’arête n’a pas de verbe de rétractation ; le wiring est marqué révoqué et le module III réconcilie l’obsolescence. Déclaré, pas caché.
• La profondeur des backends varie. Parmi les backends d’actionnement, certains chemins d’observation sont moins profonds que d’autres (p. ex. santé de surface sur certains runtimes) ; ce sont des lacunes honnêtement notées, jamais rapportées comme un in-sync fabriqué.

Liens connexes

• Catalogue des modules — la distinction Govern/Observe vs Actuate et la jonction 503.
• Module III — l’access map — consomme le wiring PERMITTED que ce module déclare.
• Référence du bus d’événements — l’événement edge.observed et sa charge utile minimal-data.
• Gouverner et approuver — le flux d’approbation HITL derrière chaque mutation.
• Honnêteté et limites — ce qui actionne aujourd’hui et ce qui ne le fait pas.
• Vue d’ensemble de l’architecture — où se situe le module VII dans la couche Management.