Bygning af operativsystemavbilder
OpenFactory omdanner en normaliseret opskrift til et image-artefakt og, når det er anmodet og tilgængeligt, starter det artefakt til verifikation. De konkrete builders og trin varierer efter base-image-familie og deployment.
Hvad en opskrift styrer
| Område | Kanonisk placering | Gennemgangsspørgsmål |
|---|---|---|
| Base og hardware-intention | base_image, hardware | Er det den rigtige distribution, release, arkitektur og minimumsprofil? |
| Features og pakker | os.features, os.packages | Er de ønskede kapaciteter til stede og understøttet på denne base? |
| Tjenester og konti | os.services, os.users | Er konfiguration og least-privilege-adgang eksplicit? |
| Desktop og branding | os.desktop_settings, os.branding | Ejers det valgte desktop disse indstillinger og assets? |
| Installer og persistens | os.installer, os.persistence | Er krav til install-to-disk og persistens faktisk testet? |
| Tilpasset automatisering | os.startup_scripts, attachments, source packages | Er inputs fastgjort, afgrænset og sikre at køre som den deklarerede bruger? |
| Verifikation | scenarios | Observerer tests hvert væsentligt udfald, ikke kun boot? |
Se Recipe Schema for den fulde form.
Build-livscyklus
Den offentlige statusstrøm kan omfatte planlægning, konfiguration, source-package-arbejde, image-generering, finalisering og test. Disse er ikke garanteret at optræde som identisk navngivne trin for hvert mål. Følg build-ID returneret af startanmodningen, og behandl backendens aktuelle status som autoritativ.
Hold disse udfald adskilt:
validatedbetyder, at den genkendte opskriftsform blev accepteret;- et terminalt vellykket build betyder, at et artefakt blev finaliseret;
- testsucces betyder, at de valgte assertions bestod i deres miljø; og
- certificering eller publicering, hvor aktiveret, er en senere policybeslutning.
Stille fremskridt er ikke grund til at oprette et duplikat-build. Genopret forbindelse til build-konsollen eller status-endpointet med samme build-ID. Hvis buildet bliver terminal failed, bevar trin, fejl og logs før du prøver igen.
Anbefalet workflow
- Skriv observerbare acceptkriterier.
- Generer eller rediger opskriften.
- Valider den, og sammenlign det normaliserede resultat med hele samtalen.
- Inspicer udledte features, eksterne kilder, installer-indstillinger og scenarios.
- Start ét build, og følg dets varige ID.
- Gennemgå artefakt-digest, pakkeinventar, advarsler og testbevis.
- Boot eller installer i et engangsmiljø, der passer til anmodningen.
- Promover eller publicer kun gennem den relevante approval gate.
Emneguider
| Emne | Brug til |
|---|---|
| Base Images | Vælge en understøttet build-familie |
| Features | Forstå registrerede capability-moduler |
| Services | Deklarere tjenestekonfiguration |
| Custom Software | Gennemgå repository-understøttede pakkeinputs |
| Users | Oprette image-lokale konti sikkert |
| Desktop | Vælge og verificere desktop-indstillinger |
| Startup Scripts | Skrive afgrænsede first-boot-enheder |
Start med det mindste nyttige image. Tilføj features først, når adfærd og bevis for det forrige artefakt er forstået.