Skip to Content
Getting StartedZrozumienie receptur

Zrozumienie receptur

BuildRecipe to znormalizowana specyfikacja, którą OpenFactory wysyła do potoku obrazów. Chat może pomóc w autorstwie, ale receptura, snapshoty źródeł, wygenerowane pliki i dowody testów definiują build.

Model mentalny

Kanoniczna receptura ma cztery główne warstwy:

  1. Tożsamość i cel: nazwa, opis, obraz bazowy i intencja sprzętowa.
  2. System operacyjny: funkcje, pakiety, usługi, użytkownicy, bezpieczeństwo, desktop, installer, załączniki i skrypty startowe pod os.
  3. Weryfikacja: jeden lub więcej scenariuszy z wbudowanymi testami i własnymi asercjami.
  4. Intencja dostawy: żądane miejsca publikacji i opcjonalne ustawienia dostawy.
{
  "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"]
}

Używaj snake_case. Nowe integracje nie powinny wysyłać legacy kształtów takich jak baseImage, top-level features ani startupScripts.

Trzy kontrole, trzy różne odpowiedzi

Walidacja schematu

Walidacja odpowiada na pytanie: „Czy rozpoznane dane mają akceptowalny kształt?” Nie dowodzi, że pakiety istnieją ani że zachowanie działa. Niektóre nieznane pola są ignorowane ze względu na kompatybilność, więc sukces walidacji może nadal pominąć ważne żądanie.

Zawsze porównuj zwróconą znormalizowaną recepturę z pierwotnym chatem i wymaganiami. Brak desktopu, aplikacji, installera, załącznika lub testu to wada receptury, nawet gdy walidacja zwraca valid.

Dowód buildu

Udany build odpowiada: „Czy potok wyprodukował artefakt?” Nie dowodzi, że każda zamierzona funkcja trafiła do obrazu. Sprawdź inwentarz pakietów, pochodzenie źródeł, ostrzeżenia i dowody z etapu buildu.

Weryfikacja gościa

Testy gościa odpowiadają na wąskie pytania runtime: czy VM wystartował, usługa jest aktywna, port nasłuchuje, plik ma oczekiwaną zawartość lub aplikacja się uruchomiła. Zaliczona asercja potwierdza tylko zachowanie, które faktycznie zaobserwowano.

Ustawienia bezpieczeństwa to intencja

Akceptowane wartości hardening_level to minimal, standard i strict, ale te etykiety nie są przenośnymi profilami zgodności. Generatory docelowe mogą je interpretować inaczej. Jeśli potrzebujesz benchmarku, wybierz dokładnie właściwy benchmark i zachowaj wyniki per control; nie wnioskuj zgodności z CIS z strict.

Podobnie disk_encryption, audit_logging, SELinux, fail2ban, Secure Boot, dm-verity i ustawienia installera wymagają pasujących testów artefaktu i runtime.

Chat i własność receptury

Gdy walidujesz lub edytujesz recepturę utworzoną w chacie, istniejąca rozmowa pozostaje częścią kontekstu autorstwa. Walidacja powinna dopracować bieżącą recepturę, a nie po cichu zastąpić ją generycznym domyślnym. Mimo to znormalizowana receptura to ostatni punkt kontrolny przed buildem.

Dla każdego istotnego wymagania:

  • znajdź odpowiednie znormalizowane pole;
  • potwierdź wartość i zakres docelowy;
  • dodaj asercję, gdy możliwy jest dowód runtime; oraz
  • zachowaj pracę tylko przy wdrożeniu jako wyraźne ostrzeżenie zamiast udawać, że nastąpiła podczas buildu obrazu.

Lista kontrolna przeglądu

  • Czy obraz bazowy i architektura są poprawne?
  • Czy wszystkie żądane funkcje desktopu i aplikacji są obecne?
  • Czy zewnętrzne źródła są przypięte i licencjonowane do zamierzonego użycia?
  • Czy w zapisanych polach receptury i skryptach nie ma sekretów?
  • Czy installer jest skonfigurowany i przetestowany na dysku jednorazowym, jeśli o to proszono?
  • Czy scenariusze testują rzeczywiste kryteria akceptacji?
  • Czy wymagania nieobsługiwane lub z czasu wdrożenia są wymienione?

Zobacz Schemat receptury dla referencji pól oraz Twój pierwszy build dla workflow buildu i pobierania.

Twój pierwszy buildPrzewodniki budowania