Skip to Content
Getting StartedReceptu izpratne

Receptu izpratne

BuildRecipe ir normalizēta specifikācija, ko OpenFactory nosūta image pipeline. Saruna var palīdzēt to sagatavot, taču buildu nosaka recepte, avotu momentuzņēmumi, ģenerētie faili un testu pierādījumi.

Domāšanas modelis

Kanoniskajai receptei ir četri galvenie slāņi:

  1. Identitāte un mērķis: nosaukums, apraksts, base image un aparatūras nolūks.
  2. Operētājsistēma: features, packages, services, users, security, desktop, installer, attachments un startup scripts zem os.
  3. Verifikācija: viens vai vairāki scenāriji ar iebūvētiem testiem un pielāgotiem assertions.
  4. Piegādes nolūks: pieprasītās publikācijas vietas un neobligāti piegādes iestatījumi.
{
  "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"]
}

Izmantojiet snake_case. Jaunām integrācijām nevajadzētu sūtīt mantotās formas, piemēram, baseImage, top-level features vai startupScripts.

Trīs pārbaudes, trīs atšķirīgas atbildes

Shēmas validācija

Validācija atbild: „Vai atpazītajiem datiem ir pieņemama forma?“ Tā ne pierāda, ka pakotnes pastāv vai uzvedība darbojas. Daži nezināmi lauki tiek ignorēti saderības dēļ, tāpēc veiksmīga validācija joprojām var izlaist svarīgu pieprasījumu.

Vienmēr salīdziniet atgriezto normalizēto recepti ar sākotnējo sarunu un prasībām. Trūkstošs desktop, application, installer, attachment vai tests ir receptes defekts, pat ja validācija rāda valid.

Build pierādījumi

Veiksmīgs build atbild: „Vai pipeline izveidoja artifact?“ Tas ne pierāda, ka katra paredzētā funkcija nonāca image. Pārbaudiet pakotņu inventāru, avota izcelsmi, brīdinājumus un build posma pierādījumus.

Guest verifikācija

Guest testi atbild šaurus runtime jautājumus: vai VM ielādējās, vai pakalpojums ir aktīvs, vai ports klausās, vai failam ir gaidāmais saturs, vai application palaistā. Nokārtots assertion atbalsta tikai uzvedību, ko faktiski novēroja.

Drošības iestatījumi ir nolūks

Pieņemtās hardening_level vērtības ir minimal, standard un strict, taču šīs etiķetes nav pārnēsājami compliance profili. Target ģeneratori var tās interpretēt atšķirīgi. Ja vajag benchmark, izvēlieties precīzi piemērojamo benchmark un saglabājiet rezultātus pa control; neseciniet CIS atbilstību no strict.

Tāpat disk_encryption, audit_logging, SELinux, fail2ban, Secure Boot, dm-verity un installer iestatījumiem vajag atbilstošus artifact un runtime testus.

Saruna un receptes īpašumtiesības

Kad validējat vai rediģējat sarunā izveidotu recepti, esošā saruna paliek authoring konteksta daļa. Validācijai jāprecizē pašreizējā recepte, nevis klusi jāaizstāj ar vispārīgu noklusējumu. Tomēr normalizētā recepte ir pēdējais checkpoint pirms build.

Katram būtiskam prasījumam:

  • atrodiet atbilstošo normalizēto lauku;
  • apstipriniet tā vērtību un mērķa scope;
  • pievienojiet assertion, kur iespējams runtime pierādījums; un
  • deployment-only darbu saglabājiet kā skaidru brīdinājumu, nevis izliekoties, ka tas notika image build laikā.

Pārskata kontrolsaraksts

  • Vai base image un arhitektūra ir pareiza?
  • Vai visas pieprasītās desktop un application funkcijas ir klāt?
  • Vai ārējie avoti ir piesaistīti un licencēti paredzētajam lietojumam?
  • Vai noslēpumi nav saglabātos recipe laukos un scriptos?
  • Vai installer ir konfigurēts un pārbaudīts uz vienreizlietojama diska, ja pieprasīts?
  • Vai scenāriji pārbauda faktiskos acceptance kritērijus?
  • Vai neatbalstītās vai deployment laika prasības ir skaidri norādītas?

Sk. Receptes shēma lauku atsaucei un Your First Build build un lejupielādes workflow.

Pirmais buildBuild ceļveži