Skip to Content
Building OsFunkcje buildu

Funkcje buildu

Feature to nazwany moduł buildu. Wpis w rejestrze może deklarować pakiety dla jednej lub więcej rodzin dystrybucji i może też zawierać build hooks, aliasy, metadane capability oraz guest assertions.

Dodanie feature wyraża intencję. Samo w sobie nie dowodzi, że każdy pakiet był dostępny, każdy hook się wykonał albo że wynikowe zachowanie działa na obrazie docelowym. Walidacja receptury, zakończenie buildu i weryfikacja guest to osobne bramki.

Aktualny zestaw feature

Użyj feature selector lub feature-catalog API w wdrożonej wersji OpenFactory. To wyjście jest wiążące dla działającej wersji. Statyczne listy szybko się dezaktualizują, a niektóre wpisy rejestru są ukryte, bo wspierają wewnętrzne fixtures lub niekompletne integracje.

Przed wyborem feature sprawdź:

  • czy jest widoczny i włączony dla Twojego konta;
  • czy deklaruje pakiety dla rodziny dystrybucji receptury;
  • czy zewnętrzne źródła są przypięte i możliwe do pobrania;
  • czy ma assertions dowodzące potrzebnego zachowania; oraz
  • czy koliduje z innym żądanym modułem.

Reprezentatywne kategorie

Rejestr zawiera obecnie moduły w kategoriach takich jak:

KategoriaPrzykładyWymagany dowód
Desktopdesktop-kde, desktop-gnome-minimal, krita, kdenlivetyp sesji, zainstalowane pakiety, zachowanie launchera i prawdziwy desktop smoke test
Wiersz poleceń i developmentgit, curl, python, nodejs, rustinwentarz pakietów/wersji i smoke testy executable
Infrastrukturanginx, postgresql, redis, docker, ansiblekonfiguracja usługi, stan enabled/running, porty i health na poziomie aplikacji
Securityfirewall, audit-logging, security-hardening, apparmorwygenerowana polityka, aktywny stan runtime, testy negatywne i udokumentowane wyjątki
Zorientowane na compliancecis-benchmarks, gxp, disa-stig, nist-800-53dokładne źródło benchmark/control, zastosowanie, wyniki per control i ludzka disposition
Narzędzia AIollama, alpaca, aider, codex-cliprzypięta provenance source/package, granica pobierania modelu, test uruchomienia i wymagania zasobów

Przykłady nie tworzą macierzy kompatybilności. Nazwa feature może istnieć, gdy implementacja dla konkretnej dystrybucji pozostaje częściowa.

Feature, pakiet i usługa to różne rzeczy

  • os.features wybiera zarejestrowane moduły buildu.
  • os.packages prosi natywny package manager o konkretne pakiety.
  • os.services dostarcza nazwaną intencję włączenia i konfiguracji.

Na przykład:

{ "os": { "features": ["ssh", "firewall"], "packages": ["curl", "jq"], "services": [ { "name": "ssh", "enabled": true, "config": { "port": 22, "disable_password_auth": true } } ] } }

Poprawna konfiguracja usługi może nadal zawierać klucze, których generator nie konsumuje. Sprawdź znormalizowaną recepturę i przetestuj wygenerowanego guest.

Etykiety security i compliance

security-hardening instaluje i konfiguruje ogólną linię bazową hardeningu. Nie jest synonimem profilu CIS. hardening_level w recepturze to etykieta konfiguracji interpretowana przez generatory specyficzne dla celu; to nie certyfikacja ani uniwersalne mapowanie na CIS Level 1 lub Level 2.

Feature cis-benchmarks ma bardziej szczegółową ścieżkę remediacji Ubuntu 24.04 Level 1. Inne bazy nie dostają tej samej roli. Zobacz CIS benchmark evidence dla dokładnej granicy.

Podobnie włączenie feature nazwanego pod GxP, HIPAA, SOC 2, PCI DSS, NIST lub DISA nie ustanawia compliance organizacyjnego. Może dodać pakiety, konfigurację i testy wspierające dowód w osobno zarządzanej ocenie.

Bezpieczne łączenie feature

  1. Zacznij od najmniejszego zestawu wyrażającego żądane zachowanie.
  2. Zwaliduj recepturę i sprawdź znormalizowane wyjście pod kątem odrzuconych lub wywnioskowanych pól.
  3. Przejrzyj rozszerzony plan pakietów i hooków.
  4. Zbuduj raz i śledź trwały build ID.
  5. Uruchom assertions specyficzne dla feature w uruchomionym guest.
  6. Zapisz awarie i zamierzone wyjątki wprost.
  7. Dodaj kolejny feature dopiero gdy obecna linia bazowa jest zrozumiała.

Dla kanonicznego kształtu JSON zobacz Recipe Schema.