Skip to Content
Getting StartedÎnțelegerea rețetelor

Înțelegerea rețetelor

BuildRecipe este specificația normalizată pe care OpenFactory o trimite în pipeline-ul de image. Chat-ul poate ajuta la redactare, dar build-ul îl definesc rețeta, snapshot-urile surselor, fișierele generate și dovezile testelor.

Model mental

Rețeta canonică are patru straturi principale:

  1. Identitate și țintă: nume, descriere, base image și intenție hardware.
  2. Sistem de operare: funcții, pachete, servicii, utilizatori, securitate, desktop, installer, atașamente și scripturi startup sub os.
  3. Verificare: unul sau mai multe scenarii cu teste integrate și assertion personalizate.
  4. Intenție de livrare: destinații de publicare cerute și setări opționale de livrare.
{
  "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"]
}

Folosiți snake_case. Integrările noi nu ar trebui să trimită forme legacy precum baseImage, features la nivel superior sau startupScripts.

Trei verificări, trei răspunsuri diferite

Validarea schemei

Validarea răspunde: „Datele recunoscute au o formă acceptabilă?” Nu dovedește că pachetele există sau că comportamentul funcționează. Unele câmpuri necunoscute sunt ignorate pentru compatibilitate, deci un succes la validare poate totuși omite o cerere importantă.

Comparați mereu rețeta normalizată returnată cu chat-ul original și cerințele. Lipsa desktop-ului, aplicației, installer-ului, atașamentului sau testului este un defect al rețetei chiar dacă validarea spune valid.

Dovada build-ului

Un build reușit răspunde: „Pipeline-ul a produs un artefact?” Nu dovedește că fiecare funcție intenționată a ajuns în image. Inspectați inventarul pachetelor, proveniența surselor, avertismentele și dovezile din faza de build.

Verificarea oaspetelui

Testele oaspete răspund la întrebări runtime înguste: dacă VM-ul a pornit, un serviciu este activ, un port ascultă, un fișier are conținutul așteptat sau o aplicație s-a lansat. O assertion trecută susține doar comportamentul pe care l-a observat efectiv.

Setările de securitate exprimă intenție

Valorile acceptate pentru hardening_level sunt minimal, standard și strict, dar aceste etichete nu sunt profile de conformitate portabile. Generatorii țintă le pot interpreta diferit. Dacă aveți nevoie de un benchmark, selectați benchmark-ul exact aplicabil și păstrați rezultatele pe control; nu deduceți conformitatea CIS din strict.

La fel, disk_encryption, audit_logging, SELinux, fail2ban, Secure Boot, dm-verity și setările installer-ului necesită teste potrivite de artefact și runtime.

Chat și proprietatea rețetei

Când validați sau editați o rețetă redactată în chat, conversația existentă rămâne parte din contextul de redactare. Validarea ar trebui să rafineze rețeta curentă, nu să o înlocuiască în tăcere cu un implicit generic. Totuși, rețeta normalizată este ultimul punct de control înainte de build.

Pentru fiecare cerință materială:

  • găsiți câmpul normalizat corespunzător;
  • confirmați valoarea și domeniul țintă;
  • adăugați o assertion unde dovada runtime este posibilă; și
  • păstrați munca doar la deploy ca avertisment explicit, nu ca și cum s-ar fi întâmplat în timpul build-ului de image.

Listă de verificare la revizuire

  • Sunt corecte base image și arhitectura?
  • Sunt prezente toate funcțiile desktop și aplicație cerute?
  • Sursele externe sunt fixate și licențiate pentru utilizarea intenționată?
  • Lipsesc secretele din câmpurile rețetei salvate și scripturi?
  • Installer-ul este configurat și testat pe un disc de unică folosință dacă s-a cerut?
  • Scenariile testează criteriile reale de acceptare?
  • Cerințele neacceptate sau de la momentul deploy-ului sunt menționate explicit?

Consultați Schema rețetei pentru referința câmpurilor și Primul build pentru fluxul de build și descărcare.

Primul buildGhiduri de build