Modul VII — Deployment & Integration

Deployment-Definitionen, Pläne, Anwendungen, Rollbacks, Stilllegungen, die Executor-Einrichtung und das Verdrahtungsprotokoll gehören zu Business. Community antwortet auf diese API-Routen mit 501 und blendet die Befehlsgruppe aus. Gespeicherte Definitionen, Revisionen, Verdrahtungen und Operationen bleiben in der Datenbank und in Wiederherstellungssicherungen erhalten. Die folgenden Abschnitte beschreiben das Business-Verhalten.

Modul VII ist das einzige Modul, das die Kundeninfrastruktur mutiert — jeder andere Teil des Produkts ist read-first. Es stellt Agenten und MCP-Server bereit, aktualisiert und stilllegt sie als deklarative, versionierte, reversible Operationen und deklariert die Konnektivität sowie die referenzierte Identität, die ein Agent nutzt, um eine Unternehmensressource zu erreichen. Da es handelt, ist seine Sicherheitslatte die höchste im Produkt, und die Live-Aktuierung wird hinter einer deny-closed Naht zurückgehalten, bis ein Operator sie explizit bereitstellt.

Planen und steuern, dann (vielleicht) anwenden

Der Lebenszyklus ist plan → apply → verify → retire und gleicht einen gewünschten Zustand gegen den realen ab. Die entscheidende Trennung ist deklarieren ≠ mutieren:

• Das Deklarieren des gewünschten Zustands — eine Definition erstellen, aktualisieren, zurückrollen (auch über die Manage-as-Code-Ressource olivares_deployment) — ist reine Control-Plane-Sache und berührt niemals die Infrastruktur.
• plan ist ein reiner Dry-run-Diff; verify prüft Drift und aktualisiert den Snapshot. Keines von beiden mutiert.
• apply und retire sind die einzigen mutierenden Operationen. Sie sind zweiphasig und deny-by-default: Phase eins berechnet den Diff und fordert eine an den Plan-Hash gebundene menschliche Freigabe an, ohne etwas zu verändern; Phase zwei schreitet nur fort, wenn die Freigabe approved ist und der Plan-Hash weiterhin übereinstimmt — jeder andere Zustand (pending, expired, rejected, kein Gate, veralteter Plan) wird abgelehnt und protokolliert. Eine erneute Spezifikation ändert den Hash und macht die Freigabe ungültig (Anti-TOCTOU).

Mutierendes apply/retire ist standardmäßig nicht live. Die Aktuierungsnaht (Executor) ist deny-closed: Ohne bereitgestellten Executor scheitern apply/retire/plan/verify fail-closed mit einem 503 — die Control Plane kann den gewünschten Zustand deklarieren, aber nicht mit der realen Infrastruktur abgleichen. Eine reale Engine (Tofu/Terraform, GitOps, Kubernetes, Docker, Nomad, Crossplane) plus eine kurzlebige, pro Operation attestierte Credential-Quelle werden nur bei Operator-Konfiguration eingebunden; ohne diese handelt das Modul niemals stillschweigend.

Einen Executor verbinden

Solange kein Administrator einen Executor verbindet, speichert Deploy Ihre Bereitstellungsdefinitionen und ändert keine Infrastruktur. So verbinden Sie einen:

1. Schreiben Sie eine JSON-Datei mit einem Block für jede Laufzeit, auf die Sie bereitstellen (docker, k8s, nomad, tofu, terraform, gitops oder crossplane), und einem credential-Block. Nur die Laufzeiten in der Datei werden verbunden. Für Docker auf demselben Host:

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

   Für jeden Vorgang liest Olivares ein kurzlebiges Token aus path_template: {env} ist die Umgebung der Definition und {mode} ist read (Plan, Prüfen) oder write (Anwenden, Außerbetriebnahme). Ein Werkzeug, das Sie bereits betreiben, etwa Vault Agent oder ein SPIFFE-Helfer, legt deren Verzeichnis an und schreibt und rotiert diese Dateien. Ohne Token wird jeder Vorgang abgelehnt. Für Docker muss der Dienstbenutzer olivares außerdem den Socket öffnen können; die Mitgliedschaft in der Gruppe docker gibt ihm Root-Zugriff auf diesen Host.

2. Verweisen Sie Olivares auf die Datei. Mit dem deb- oder rpm-Paket fügen Sie diese Zeile in /etc/olivares/olivares.env ein:

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

   Der Benutzer olivares muss die JSON-Datei lesen können, zum Beispiel mit Eigentümer root:olivares und Modus 0640.

3. Starten Sie Olivares mit sudo systemctl restart olivares neu. Kann die Datei nicht gelesen werden oder ist sie ungültig, startet Olivares nicht und sein Log nennt den Grund.

Die Deploy-Seite bietet dann Bereitstellung deklarieren als Hauptaktion an, und Plan und Anwenden erreichen die Laufzeit. Jedes Anwenden und jede Außerbetriebnahme wartet weiterhin auf eine Genehmigung.

Entitäten und der deklarierte Vertrag

Das Modul deklariert vier namespaced Entitäten plus das Kern-Deployment als angewandten Snapshot:

Entität	Rolle
definition	gewünschter Zustand — gewünschte vs. angewandte Version, Spec-Hash, Verknüpfung zum Kern-Deployment
revision	append-only, unveränderliche Spec-Historie — die reversible Quelle für Rollback
wiring	die erlaubte Konnektivität agent → resource, die es deklariert (der Vertrag, den Modul III gegenüberstellt)
operation	append-only Change-Management-Ledger — Version, Plan-Hash, wer freigegeben hat, Ergebnis

Die gewünschte Spec ist typisiert und aus dem Struct re-serialisiert (niemals ein Operator-JSON-Round-Trip): unbekannte Felder werden abgelehnt, ein Inline-Credential-Guard läuft, und eine Spec, die Credential-Material im Klartext trägt, wird bei der Deklaration abgelehnt. Credentials reisen nur per Referenz (<scheme>:<locator>, allow-listed Scheme) — eine Eigenschaft der Leitung, niemals ein gespeichertes Secret.

Was es auf dem Bus erzeugt (die PERMITTED-Seite von Modul III)

Modul VII schreibt niemals die Access Map; Modul III ist der einzige Schreiber ihrer Kanten. Bei einem committeten apply veröffentlicht das Modul für jede Wiring ein Policy-Grant-Event edge.observed (Source = policy), das nur Referenzen und den Modus trägt. Modul III gleicht es in die PERMITTED-Seite seines Permitted-vs-Observed-Diffs ab — sodass das, was dieses Modul deklariert, exakt das ist, was Modul III gegen seine Beobachtungen kontrastiert. Die Identität wird pro Agent über Governance gebunden: Eine feste, eindeutige Non-Human-Identität ergibt eine attributed-Kante; eine geteilte oder fehlende Identität wird als approximate gemeldet — gekennzeichnet, niemals vorgetäuscht.

Ehrliche Grenzen

• Live-Apply ist eine deny-closed Naht. Ohne bereitgestellten Executor liefern apply/retire (und plan/verify) einen klaren 503. Das Modul plant, steuert, versioniert und deklariert heute den gewünschten Zustand; es gleicht erst dann mit der realen Infrastruktur ab, wenn ein Operator einen Executor einbindet — niemals standardmäßig, niemals ein stillschweigender No-op.
• Freigabe und Attribution fallen ebenfalls sicher aus. Ohne das Freigabe-Gate wird jede Mutation verweigert; ohne den Identity-Binder ist die Attribution einer Wiring herabgestuft, nicht erfunden. Start() warnt einmal pro nicht verkabelter Naht, sodass ein kaputtes Deployment sichtbar ist.
• Das Stilllegen einer Wiring zieht ihre veröffentlichte PERMITTED-Kante nicht zurück. Das Kantenmodell hat kein Verb zum Zurückziehen; die Wiring wird als revoked markiert und Modul III gleicht die Veraltung ab. Deklariert, nicht versteckt.
• Die Backend-Tiefe variiert. Über die Aktuierungs-Backends hinweg sind manche Observe-Pfade flacher als andere (z. B. Health auf Oberflächenebene bei bestimmten Runtimes); diese werden als ehrliche Lücken vermerkt, niemals als erfundenes In-Sync gemeldet.

Verwandt

• Modulkatalog — die Trennung Govern/Observe vs. Actuate und die 503-Naht.
• Modul III — die Access Map — konsumiert die PERMITTED-Wiring, die dieses Modul deklariert.
• Referenz Event-Bus — das edge.observed-Event und seine Minimal-Data-Payload.
• Steuern und freigeben — der HITL-Freigabe-Flow hinter jeder Mutation.
• Ehrlichkeit & Grenzen — was heute aktuiert wird und was nicht.
• Architekturüberblick — wo Modul VII in der Management-Schicht sitzt.