Operētājsistēmas attēlu veidošana
OpenFactory normalizētu recepti pārvērš attēla artefaktā un, ja pieprasīts un pieejams, ielādē šo artefaktu verifikācijai. Konkrētie builderi un posmi atšķiras pēc bāzes attēla saimes un izvietojuma.
Ko recepte kontrolē
| Joma | Kanoniskā vieta | Pārskatīšanas jautājums |
|---|---|---|
| Bāze un aparatūras nolūks | base_image, hardware | Vai tā ir pareizā distribūcija, izlaidums, arhitektūra un minimālais profils? |
| Funkcijas un pakotnes | os.features, os.packages | Vai pieprasītās iespējas ir un tiek atbalstītas šajā bāzē? |
| Pakalpojumi un konti | os.services, os.users | Vai konfigurācija un mazākās privilēģijas piekļuve ir skaidri norādīta? |
| Darbvirsma un zīmols | os.desktop_settings, os.branding | Vai izvēlētā darbvirsma pārvalda šos iestatījumus un resursus? |
| Instalētājs un persistence | os.installer, os.persistence | Vai instalēšana diskā un persistences prasības patiešām ir pārbaudītas? |
| Pielāgota automatizācija | os.startup_scripts, attachments, source packages | Vai ievades ir piespraustas, ierobežotas un drošas palaist kā deklarētajam lietotājam? |
| Verifikācija | scenarios | Vai testi novēro katru būtisku rezultātu, ne tikai boot? |
Pilnu formu skatiet Receptes shēma.
Build dzīves cikls
Publiskais statusa straume var ietvert plānošanu, konfigurāciju, source-package darbu, attēla ģenerēšanu, finalizāciju un testēšanu. Nav garantijas, ka katram mērķim tie parādīsies ar identiskiem posmu nosaukumiem. Sekojiet build ID, ko atgriež start pieprasījums, un par autoritatīvu uzskatiet backend pašreizējo statusu.
Turiet šos rezultātus atsevišķi:
validatednozīmē, ka atpazītā receptes forma tika pieņemta;- veiksmīgs galīgais build nozīmē, ka artefakts tika finalizēts;
- veiksmīgs tests nozīmē, ka izvēlētās assertions iztur savā vidē; un
- sertificēšana vai publicēšana, ja iespējota, ir vēlāka politikas izvēle.
Klusa progress nav iemesls veidot otro build. Atkārtoti pieslēdzieties build konsolei vai status endpoint ar to pašu build ID. Ja build kļūst galīgi neveiksmīgs, saglabājiet posmu, kļūdu un logus pirms atkārtota mēģinājuma.
Ieteicamā plūsma
- Uzrakstiet novērojamus pieņemšanas kritērijus.
- Ģenerējiet vai rediģējiet recepti.
- Validējiet un salīdziniet normalizēto rezultātu ar visu sarunu.
- Pārbaudiet inferētās funkcijas, ārējos avotus, instalētāja iestatījumus un scenārijus.
- Sāciet vienu build un sekojiet tā ilgtermiņa ID.
- Pārskatiet artefakta digest, pakotņu inventāru, brīdinājumus un test pierādījumus.
- Boot vai instalējiet vienreizlietojamā vidē, kas atbilst pieprasījumam.
- Promocējiet vai publicējiet tikai caur attiecīgo apstiprinājuma vārtiem.
Tematu ceļveži
| Temats | Kam lietot |
|---|---|
| Bāzes attēli | Atbalstītas build saimes izvēle |
| Funkcijas | Reģistrētu spēju moduļu izpratne |
| Pakalpojumi | Pakalpojumu konfigurācijas deklarēšana |
| Pielāgota programmatūra | Repozitoriju balstītu pakotņu ievades pārskatīšana |
| Lietotāji | Droša kontu veidošana attēlā |
| Darbvirsma | Darbvirsmas iestatījumu izvēle un pārbaude |
| Startup Scripts | Ierobežotu first-boot unit autorēšana |
Sāciet ar mazāko noderīgo attēlu. Funkcijas pievienojiet tikai pēc tam, kad saprotat iepriekšējā artefakta uzvedību un pierādījumus.