BOOTSTRAP-CONTRACT-MODEL

Bootstrap-Vertragsmodell#

Zweck#

Ein Bootstrap Contract beschreibt einen reproduzierbaren, idempotenten und verifizierbaren Installations- oder Konfigurationsschritt.

Vertragsstruktur#

Identity#

• stabile StepId
• Name und Beschreibung
• zuständiger ⌘Building BlockEin Building Block ist ein abgegrenzter Baustein mit stabiler Verantwortung zur Realisierung von Capabilities.
• Version

Intent#

• gewünschter Zielzustand
• fachlicher oder technischer Grund
• referenzierte Requirements, Constraints und Quality Goals

Preconditions#

• benötigte Abhängigkeiten
• erforderliche Berechtigungen
• notwendige Konfiguration
• erwartete Storage Area

Plan#

• Istzustandsermittlung
• geplante Änderungen
• erwartete Auswirkungen
• Risiken
• Idempotenzbewertung

Execute#

• ausführende Operation
• erlaubte Änderungen
• Timeout
• Retry-Policy
• Secret-Handhabung

Verify#

• konkrete Postconditions
• verwendete Prüfmethode
• erwartete Werte
• Negativkriterien
• Severity bei Fehler

Evidence#

• Evidence-Typ
• Speicherort
• Lebensdauer
• Sensitivitätsklasse
• Prüfsumme oder Referenz

Rollback#

• automatische Rollback-Aktion
• Rollback-Verifikation
• Bedingungen, unter denen Rollback verboten ist
• manuelle Recovery-Anweisung

Report#

• Planergebnis
• tatsächlich ausgeführte Änderungen
• Verification Results
• Evidence-Referenzen
• offene Findings
• Entscheidung

Zustandsmodell#

planned
                → executing
                → executed
                → verifying
                → verified
                → accepted

Fehlerpfade:

planning-failed
                execution-failed
                verification-failed
                rollback-running
                rolled-back
                rollback-failed
                manual-recovery-required

Idempotenz#

Ein wiederholter Bootstrap-Lauf muss:

• bereits erfüllte Postconditions erkennen,
• unnötige Änderungen vermeiden,
• bestehende lokale Secrets nicht überschreiben,
• denselben Zielzustand erzeugen,
• Abweichungen sichtbar reporten.

Beziehungen#

• ◆Engineering-Prinzip – Materialisierung erfordert Verification und EvidenceTechnical documentation artifact. — specializes

Secret-Regel#

Secrets dürfen:

• aus geschützten lokalen Konfigurationen gelesen werden,
• über temporäre Dateien mit restriktiven Rechten an externe Werkzeuge übergeben werden.

Secrets dürfen nicht:

• im ⌘GitGit ist das verwendete Versionsverwaltungssystem für nachvollziehbare Änderungsgeschichte. liegen,
• in Prozesslisten erscheinen,
• in Reports oder Logs ausgegeben werden,
• in Upload-ZIPs gelangen.

Beispiel: MariaDB-Anwendungsbenutzer#

Intent:
                  Datenbank und Anwendungsbenutzer stehen bereit.

                Plan:
                  Prüfe Datenbank, Benutzer, Host, Rechte und Zeichensatz.

                Execute:
                  Lege fehlende Datenbank und Benutzer an; korrigiere Rechte.

                Verify:
                  Melde dich mit dem Anwendungsbenutzer an und führe SELECT 1 aus.
                  Prüfe Datenbankname, CURRENT_USER und Zeichensatz.

                Evidence:
                  anonymisiertes Verification Result, Zeitpunkt, DB-Version.

                Report:
                  erfolgreich nur, wenn der echte Anwendungslogin funktioniert.