Skip to Content
Getting StartedRezepte verstehen

Rezepte verstehen

Ein BuildRecipe ist die normalisierte Spezifikation, die OpenFactory in die Image-Pipeline sendet. Chat kann beim Authoring helfen, aber Rezept, Source-Snapshots, generierte Dateien und Test-Nachweis definieren den Build.

Das Mentalmodell

Das kanonische Rezept hat vier Hauptschichten:

  1. Identität und Ziel: Name, Beschreibung, Base Image und Hardware-Absicht.
  2. Betriebssystem: Features, Pakete, Dienste, Benutzer, Sicherheit, Desktop, Installer, Anhänge und Startup-Skripte unter os.
  3. Verifikation: ein oder mehrere Szenarien mit eingebauten Tests und eigenen Assertions.
  4. Delivery-Absicht: angeforderte Publikationsziele und optionale Delivery-Einstellungen.
{
  "name": "debian-web-check",
  "display_name": "Debian Web Check",
  "description": "Small Debian image with explicit smoke tests.",
  "base_image": "debian-trixie",
  "hardware": {
    "platform": "pc",
    "architecture": "x86_64",
    "min_cpu_cores": 2,
    "min_memory_gb": 4,
    "min_storage_gb": 16,
    "nic_count": 1
  },
  "os": {
    "features": ["ssh"],
    "packages": ["curl"],
    "services": [
      {
        "name": "ssh",
        "enabled": true,
        "config": {"port": 22, "disable_password_auth": true}
      }
    ],
    "security": {
      "hardening_level": "standard",
      "audit_logging": true
    }
  },
  "scenarios": [
    {
      "id": "primary-smoke",
      "name": "Primary image smoke test",
      "enabled": true,
      "tests": ["boot", "login", "packages"]
    }
  ],
  "publish_to": ["local"]
}

Nutzen Sie snake_case. Neue Integrationen sollten keine Legacy-Formen wie baseImage, top-level features oder startupScripts senden.

Drei Prüfungen, drei verschiedene Antworten

Schema-Validierung

Validierung beantwortet: „Hat die erkannte Datenform eine akzeptable Gestalt?“ Sie beweist weder Paketexistenz noch funktionierendes Verhalten. Manche unbekannte Felder werden aus Kompatibilität ignoriert; Validierungserfolg kann trotzdem eine wichtige Anfrage weglassen.

Vergleichen Sie stets das zurückgegebene normalisierte Rezept mit ursprünglichem Chat und Anforderungen. Fehlender Desktop, Anwendung, Installer, Anhang oder Test ist ein Rezeptfehler, auch wenn die Validierung valid meldet.

Build-Nachweis

Ein erfolgreicher Build beantwortet: „Hat die Pipeline ein Artefakt erzeugt?“ Er beweist nicht, dass jedes beabsichtigte Feature im Image landete. Prüfen Sie Paketinventar, Source-Provenienz, Warnungen und Build-Stage-Nachweis.

Gast-Verifikation

Gast-Tests beantworten enge Laufzeitfragen: ob die VM bootete, ein Dienst aktiv ist, ein Port lauscht, eine Datei erwarteten Inhalt hat oder eine Anwendung startete. Eine bestandene Assertion stützt nur das tatsächlich beobachtete Verhalten.

Sicherheitseinstellungen sind Absicht

Die akzeptierten hardening_level-Werte sind minimal, standard und strict, aber diese Labels sind keine portablen Compliance-Profile. Target-Generatoren können sie unterschiedlich interpretieren. Brauchen Sie einen Benchmark, wählen Sie den exakt passenden Benchmark und behalten Sie Ergebnisse pro Control; leiten Sie keine CIS-Konformität aus strict ab.

Ebenso brauchen disk_encryption, audit_logging, SELinux, fail2ban, Secure Boot, dm-verity und Installer-Einstellungen passende Artefakt- und Laufzeit-Tests.

Chat und Rezept-Ownership

Wenn Sie ein chat-authorisiertes Rezept validieren oder bearbeiten, bleibt die bestehende Konversation Teil des Authoring-Kontexts. Validierung soll das aktuelle Rezept verfeinern, nicht still durch ein generisches Default ersetzen. Trotzdem ist das normalisierte Rezept der letzte Checkpoint vor dem Build.

Für jede wesentliche Anforderung:

  • finden Sie das entsprechende normalisierte Feld;
  • bestätigen Sie Wert und Zielscope;
  • fügen Sie eine Assertion hinzu, wo Laufzeitnachweis möglich ist; und
  • halten Sie deployment-only Arbeit als explizite Warnung fest, statt so zu tun, als sei sie beim Image-Build passiert.

Review-Checkliste

  • Stimmen Base Image und Architektur?
  • Sind alle angeforderten Desktop- und Anwendungs-Features vorhanden?
  • Sind externe Quellen gepinnt und für den Einsatz lizenziert?
  • Fehlen Geheimnisse in gespeicherten Rezeptfeldern und Skripten?
  • Ist der Installer konfiguriert und auf Wegwerf-Disk getestet, wenn angefordert?
  • Testen Szenarien die echten Abnahmekriterien?
  • Sind nicht unterstützte oder deployment-zeitliche Anforderungen genannt?

Siehe Rezept-Schema für die Feldreferenz und Ihr erster Build für Build- und Download-Workflow.

Ihr erster BuildBuild-Guides