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:
| Kategoria | Przykłady | Wymagany dowód |
|---|---|---|
| Desktop | desktop-kde, desktop-gnome-minimal, krita, kdenlive | typ sesji, zainstalowane pakiety, zachowanie launchera i prawdziwy desktop smoke test |
| Wiersz poleceń i development | git, curl, python, nodejs, rust | inwentarz pakietów/wersji i smoke testy executable |
| Infrastruktura | nginx, postgresql, redis, docker, ansible | konfiguracja usługi, stan enabled/running, porty i health na poziomie aplikacji |
| Security | firewall, audit-logging, security-hardening, apparmor | wygenerowana polityka, aktywny stan runtime, testy negatywne i udokumentowane wyjątki |
| Zorientowane na compliance | cis-benchmarks, gxp, disa-stig, nist-800-53 | dokładne źródło benchmark/control, zastosowanie, wyniki per control i ludzka disposition |
| Narzędzia AI | ollama, alpaca, aider, codex-cli | przypię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.featureswybiera zarejestrowane moduły buildu.os.packagesprosi natywny package manager o konkretne pakiety.os.servicesdostarcza 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
- Zacznij od najmniejszego zestawu wyrażającego żądane zachowanie.
- Zwaliduj recepturę i sprawdź znormalizowane wyjście pod kątem odrzuconych lub wywnioskowanych pól.
- Przejrzyj rozszerzony plan pakietów i hooków.
- Zbuduj raz i śledź trwały build ID.
- Uruchom assertions specyficzne dla feature w uruchomionym guest.
- Zapisz awarie i zamierzone wyjątki wprost.
- Dodaj kolejny feature dopiero gdy obecna linia bazowa jest zrozumiała.
Dla kanonicznego kształtu JSON zobacz Recipe Schema.