Betriebssystem-Images bauen
OpenFactory wandelt ein normalisiertes Rezept in ein Image-Artefakt und startet dieses bei Anfrage und Verfügbarkeit zur Verifikation. Die konkreten Builder und Stages variieren nach Base-Image-Familie und Deployment.
Was ein Rezept steuert
| Bereich | Kanonischer Ort | Review-Frage |
|---|---|---|
| Base und Hardware-Absicht | base_image, hardware | Stimmen Distribution, Release, Architektur und Mindestprofil? |
| Features und Pakete | os.features, os.packages | Sind angeforderte Fähigkeiten vorhanden und auf dieser Base unterstützt? |
| Dienste und Konten | os.services, os.users | Sind Konfiguration und Least-Privilege-Zugriff explizit? |
| Desktop und Branding | os.desktop_settings, os.branding | Gehört der gewählte Desktop diese Einstellungen und Assets? |
| Installer und Persistenz | os.installer, os.persistence | Sind Install-to-Disk und Persistenz-Anforderungen wirklich getestet? |
| Eigene Automatisierung | os.startup_scripts, attachments, source packages | Sind Inputs gepinnt, begrenzt und sicher als deklarierter User ausführbar? |
| Verifikation | scenarios | Beobachten Tests jedes wesentliche Ergebnis, nicht nur Boot? |
Siehe Rezept-Schema für die vollständige Form.
Build-Lebenszyklus
Der öffentliche Status-Stream kann Planning, Configuration, Source-Package-Arbeit, Image-Generierung, Finalisierung und Testing enthalten. Diese erscheinen nicht für jedes Ziel garantiert als identisch benannte Stages. Folgen Sie der Build-ID aus der Start-Anfrage und behandeln Sie den aktuellen Backend-Status als maßgeblich.
Halten Sie diese Ergebnisse getrennt:
validatedbedeutet, dass die erkannte Rezeptform akzeptiert wurde;- ein terminal erfolgreicher Build bedeutet, dass ein Artefakt finalisiert wurde;
- Test-Erfolg bedeutet, dass die ausgewählten Assertions in ihrer Umgebung bestanden;
- Zertifizierung oder Publikation, wo aktiviert, ist eine spätere Policy-Entscheidung.
Stiller Fortschritt ist kein Grund für einen doppelten Build. Verbinden Sie sich wieder mit Build-Konsole oder Status-Endpoint über dieselbe Build-ID. Wird der Build terminal failed, bewahren Sie Stage, Fehler und Logs vor einem Retry.
Empfohlener Workflow
- Beobachtbare Abnahmekriterien formulieren.
- Rezept erzeugen oder bearbeiten.
- Validieren und normalisiertes Ergebnis mit der gesamten Konversation vergleichen.
- Abgeleitete Features, externe Quellen, Installer-Einstellungen und Szenarien prüfen.
- Einen Build starten und dessen dauerhafte ID verfolgen.
- Artefakt-Digest, Paketinventar, Warnungen und Test-Nachweis prüfen.
- In einer zum Request passenden Wegwerf-Umgebung booten oder installieren.
- Nur über das zutreffende Approval-Gate promoten oder publizieren.
Themen-Guides
| Thema | Nutzen für |
|---|---|
| Base Images | Auswahl einer unterstützten Build-Familie |
| Features | Registrierte Capability-Module verstehen |
| Services | Dienstkonfiguration deklarieren |
| Custom Software | Repository-gestützte Paket-Inputs prüfen |
| Users | Image-lokale Konten sicher anlegen |
| Desktop | Desktop-Einstellungen wählen und verifizieren |
| Startup Scripts | Begrenzte First-Boot-Units authorn |
Starten Sie mit dem kleinsten nützlichen Image. Fügen Sie Features erst hinzu, wenn Verhalten und Nachweis des vorherigen Artefakts verstanden sind.