Skip to Content
Getting StartedReseptien ymmärtäminen

Reseptien ymmärtäminen

BuildRecipe on normalisoitu spesifikaatio, jonka OpenFactory lähettää image-pipelineen. Chat voi auttaa kirjoittamisessa, mutta resepti, lähde-snapshotit, generoidut tiedostot ja testitodisteet määrittävät buildin.

Mentaalinen malli

Kanonisella reseptillä on neljä pääkerrosta:

  1. Identiteetti ja kohde: nimi, kuvaus, base image ja laitteistotarkoitus.
  2. Käyttöjärjestelmä: ominaisuudet, paketit, palvelut, käyttäjät, turvallisuus, desktop, installer, liitteet ja startup-skriptit os-kentän alla.
  3. Varmennus: yksi tai useampi skenaario sisäänrakennetuilla testeillä ja mukautetuilla assertioilla.
  4. Toimitustarkoitus: pyydetyt julkaisukohteet ja valinnaiset toimitusasetukset.
{
  "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"]
}

Käytä snake_casea. Uudet integraatiot eivät saa lähettää legacy-muotoja kuten baseImage, top-level features tai startupScripts.

Kolme tarkistusta, kolme eri vastausta

Skeemavalidointi

Validointi vastaa kysymykseen: „Onko tunnistetulla datalla hyväksyttävä muoto?” Se ei todista pakettien olemassaoloa eikä toimivaa käyttäytymistä. Jotkin tuntemattomat kentät jätetään yhteensopivuuden vuoksi huomiotta, joten onnistunut validointi voi silti jättää pois tärkeän pyynnön.

Vertaa aina palautettua normalisoitua reseptiä alkuperäiseen chatiin ja vaatimuksiin. Puuttuva desktop, sovellus, installer, liite tai testi on reseptivirhe, vaikka validointi palauttaisi valid.

Build-todiste

Onnistunut build vastaa: „Tuottiko pipeline artefaktin?” Se ei todista, että jokainen tarkoitettu ominaisuus päätyi imageen. Tarkista pakettiluettelo, lähteen provenienssi, varoitukset ja build-vaiheen todiste.

Vierasvarmennus

Vierastestit vastaavat kapeisiin runtime-kysymyksiin: käynnistyikö VM, onko palvelu aktiivinen, kuunteleeko portti, onko tiedostossa odotettu sisältö tai käynnistyikö sovellus. Läpäisty assertion tukee vain käyttäytymistä, jota todella havaittiin.

Turva-asetukset ovat tarkoitus

Hyväksytyt hardening_level-arvot ovat minimal, standard ja strict, mutta nämä merkinnät eivät ole siirrettäviä compliance-profiileja. Kohdegeneraattorit voivat tulkita ne eri tavoin. Jos tarvitset benchmarkin, valitse tarkalleen soveltuva benchmark ja säilytä tulokset per control; älä päättele CIS-yhteensopivuutta strict-arvosta.

Samoin disk_encryption, audit_logging, SELinux, fail2ban, Secure Boot, dm-verity ja installer-asetukset vaativat vastaavat artefakti- ja runtime-testit.

Chat ja reseptin omistajuus

Kun validoit tai muokkaat chatissa kirjoitettua reseptiä, olemassa oleva keskustelu pysyy osana authoring-kontekstia. Validoinnin pitää hienosäätää nykyistä reseptiä, ei hiljaa korvata sitä geneerisellä oletuksella. Silti normalisoitu resepti on viimeinen tarkistuspiste ennen buildia.

Jokaiselle olennaiselle vaatimukselle:

  • etsi vastaava normalisoitu kenttä;
  • vahvista arvo ja kohdealue;
  • lisää assertion, jos runtime-todiste on mahdollinen; ja
  • säilytä vain deploymentiin kuuluva työ eksplisiittisenä varoituksena sen sijaan, että väittäisit sen tapahtuneen image-buildin aikana.

Tarkistuslista

  • Ovatko base image ja arkkitehtuuri oikein?
  • Ovatko kaikki pyydetyt desktop- ja sovellusominaisuudet mukana?
  • Onko ulkoiset lähteet kiinnitetty ja lisensoitu tarkoitettuun käyttöön?
  • Puuttuvatko salaisuudet tallennetuista reseptikentistä ja skripteistä?
  • Onko installer konfiguroitu ja testattu kertalevyllä, jos sitä pyydettiin?
  • Testaavatko skenaariot todelliset hyväksymiskriteerit?
  • Onko tukemattomat tai deployment-aikaiset vaatimukset mainittu?

Katso Reseptiskeema kenttäviitteeksi ja Ensimmäinen buildisi build- ja latausworkflowhun.

Ensimmäinen buildisiBuild-oppaat