Razumevanje receptov
BuildRecipe je normalizirana specifikacija, ki jo OpenFactory pošlje v pipeline za image. Chat lahko pomaga pri avtorstvu, a build definirajo recept, posnetki virov, ustvarjene datoteke in dokazi testov.
Mentalni model
Kanonični recept ima štiri glavne plasti:
- Identiteta in cilj: ime, opis, base image in hardverski namen.
- Operacijski sistem: funkcije, paketi, storitve, uporabniki, varnost, desktop, installer, priloge in startup skripte pod
os. - Preverjanje: en ali več scenarijev z vgrajenimi testi in lastnimi assertion.
- Namen dostave: zahtevana mesta objave in neobvezne nastavitve dostave.
{
"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"]
}Uporabljajte snake_case. Nove integracije ne smejo pošiljati legacy oblik, kot so baseImage, top-level features ali startupScripts.
Tri preverjanja, tri različni odgovori
Validacija sheme
Validacija odgovori: „Ali imajo prepoznani podatki sprejemljivo obliko?” Ne dokazuje, da paketi obstajajo ali da delovanje deluje. Nekatera neznana polja se zaradi združljivosti prezrejo, zato lahko uspešna validacija še vedno izpusti pomembno zahtevo.
Vedno primerjajte vrnjeni normalizirani recept z izvirnim chatom in zahtevami. Manjkajoč desktop, aplikacija, installer, priloga ali test je napaka recepta, tudi če validacija vrne valid.
Dokaz iz builda
Uspešen build odgovori: „Ali je pipeline ustvaril artefakt?” Ne dokazuje, da je vsaka predvidena funkcija prišla v image. Preglejte inventar paketov, izvor virov, opozorila in dokaze iz faze builda.
Preverjanje gosta
Testi gosta odgovarjajo na ozka runtime vprašanja: ali se je VM zagnal, ali je storitev aktivna, ali port posluša, ali ima datoteka pričakovano vsebino ali se je aplikacija zagnala. Uspešna assertion podpira le obnašanje, ki ga je dejansko opazila.
Nastavitve varnosti so namen
Sprejete vrednosti hardening_level so minimal, standard in strict, a te oznake niso prenosljivi compliance profili. Ciljni generatorji jih lahko razlagajo drugače. Če potrebujete benchmark, izberite točno uporaben benchmark in obdržite rezultate po posameznih kontrolah; ne sklepajte skladnosti z CIS iz strict.
Enako disk_encryption, audit_logging, SELinux, fail2ban, Secure Boot, dm-verity in nastavitve installera zahtevajo ustrezne teste artefakta in runtime.
Chat in lastništvo recepta
Ko validirate ali urejate recept iz chata, obstoječi pogovor ostane del konteksta avtorstva. Validacija naj izboljša trenutni recept, ne pa ga tiho zamenjati z generično privzeto vrednostjo. Kljub temu je normalizirani recept zadnja kontrolna točka pred buildom.
Za vsako bistveno zahtevo:
- poiščite ustrezno normalizirano polje;
- potrdite njegovo vrednost in ciljni obseg;
- dodajte assertion, kjer je mogoč runtime dokaz; in
- delo samo ob namestitvi ohranite kot izrecno opozorilo, namesto da bi se pretvarjali, da se je zgodilo med buildom image.
Kontrolni seznam pregleda
- Ali sta base image in arhitektura pravilna?
- Ali so prisotne vse zahtevane funkcije desktopa in aplikacije?
- Ali so zunanji viri pripeti in licencirani za predvideni namen?
- Ali v shranjenih poljih recepta in skriptah ni skrivnosti?
- Ali je installer konfiguriran in preizkušen na enkratnem disku, če je bilo to zahtevano?
- Ali scenariji preizkušajo dejanska sprejemna merila?
- Ali so nepodprte ali deployment-time zahteve izrecno navedene?
Glejte Shema recepta za referenco polj in Vaš prvi build za workflow builda in prenosa.