Costruire immagini di sistema operativo
OpenFactory trasforma una ricetta normalizzata in un artefatto immagine e, se richiesto e disponibile, avvia quell’artefatto per la verifica. Builder e stage esatti variano per famiglia immagine base e deploy.
Cosa controlla una ricetta
| Area | Posizione canonica | Domanda di revisione |
|---|---|---|
| Base e intento hardware | base_image, hardware | Distribuzione, release, architettura e profilo minimo sono corretti? |
| Feature e pacchetti | os.features, os.packages | Le capacità richieste sono presenti e supportate su questa base? |
| Servizi e account | os.services, os.users | Configurazione e accesso least-privilege sono espliciti? |
| Desktop e branding | os.desktop_settings, os.branding | Il desktop selezionato possiede queste impostazioni e risorse? |
| Installer e persistenza | os.installer, os.persistence | Requisiti install-to-disk e persistenza sono testati davvero? |
| Automazione personalizzata | os.startup_scripts, allegati, pacchetti sorgente | Gli input sono pin, delimitati e sicuri da eseguire come utente dichiarato? |
| Verifica | scenarios | I test osservano ogni esito materiale e non solo il boot? |
Vedi Schema ricetta per la forma completa.
Ciclo di vita build
Lo stream di stato pubblico può includere planning, configuration, lavoro source-package, generazione immagine, finalizzazione e testing. Non è garantito che compaiano come stage con nome identico per ogni target. Segui l’ID build restituito dalla richiesta di avvio e tratta lo stato backend corrente come autoritativo.
Tieni separati questi esiti:
validatedsignifica che la forma ricetta riconosciuta è stata accettata;- una build terminale riuscita significa che un artefatto è stato finalizzato;
- successo test significa che le asserzioni selezionate sono passate nel loro ambiente; e
- certificazione o pubblicazione, se abilitate, è una decisione policy successiva.
Progresso silenzioso non è motivo per creare una build duplicata. Riconnettiti alla console build o all’endpoint stato con lo stesso ID build. Se la build diventa terminale failed, conserva stage, errore e log prima di riprovare.
Flusso consigliato
- Scrivi criteri di accettazione osservabili.
- Genera o modifica la ricetta.
- Validala e confronta il risultato normalizzato con l’intera conversazione.
- Ispeziona feature inferite, sorgenti esterne, impostazioni installer e scenari.
- Avvia una build e segui il suo ID durabile.
- Rivedi digest artefatto, inventario pacchetti, avvisi ed evidenze test.
- Avvia o installa in un ambiente usa e getta appropriato alla richiesta.
- Promuovi o pubblica solo tramite il gate di approvazione applicabile.
Guide per argomento
| Argomento | Usala per |
|---|---|
| Immagini base | Selezionare una famiglia build supportata |
| Feature | Capire i moduli capacità registrati |
| Servizi | Dichiarare configurazione servizio |
| Software personalizzato | Rivedere input pacchetto da repository |
| Utenti | Creare account locali all’immagine in sicurezza |
| Desktop | Scegliere e verificare impostazioni desktop |
| Script di avvio | Scrivere unit first-boot delimitate |
Inizia con l’immagine utile più piccola. Aggiungi feature solo dopo aver capito comportamento ed evidenze dell’artefatto precedente.