Budowanie obrazów systemu operacyjnego
OpenFactory zamienia znormalizowany przepis w artefakt obrazu i, gdy to możliwe i żądane, uruchamia ten artefakt do weryfikacji. Dokładni builderzy i etapy zależą od rodziny obrazu bazowego i wdrożenia.
Co kontroluje przepis
| Obszar | Kanoniczna lokalizacja | Pytanie do przeglądu |
|---|---|---|
| Baza i intencja sprzętowa | base_image, hardware | Czy to właściwa dystrybucja, wydanie, architektura i minimalny profil? |
| Funkcje i pakiety | os.features, os.packages | Czy żądane możliwości są obecne i obsługiwane na tej bazie? |
| Usługi i konta | os.services, os.users | Czy konfiguracja i dostęp least-privilege są jawne? |
| Pulpit i branding | os.desktop_settings, os.branding | Czy wybrany pulpit obejmuje te ustawienia i zasoby? |
| Instalator i trwałość | os.installer, os.persistence | Czy wymagania install-to-disk i trwałości są naprawdę testowane? |
| Własna automatyzacja | os.startup_scripts, attachments, source packages | Czy wejścia są przypięte, ograniczone i bezpieczne do uruchomienia jako zadeklarowany użytkownik? |
| Weryfikacja | scenarios | Czy testy obserwują każdy istotny wynik, a nie tylko boot? |
Pełny kształt opisuje Recipe Schema.
Cykl życia builda
Publiczny strumień statusu może obejmować planowanie, konfigurację, pracę nad source package, generowanie obrazu, finalizację i testowanie. Te etapy nie muszą pojawiać się pod identycznymi nazwami dla każdego celu. Podążaj za identyfikatorem builda zwróconym przez żądanie startu i traktuj bieżący status backendu jako wiążący.
Trzymaj te wyniki oddzielnie:
validatedoznacza, że rozpoznany kształt przepisu został zaakceptowany;- terminalnie udany build oznacza, że artefakt został sfinalizowany;
- sukces testów oznacza, że wybrane assertions przeszły w swoim środowisku; oraz
- certyfikacja lub publikacja, gdy włączona, to późniejsza decyzja polityki.
Cichy postęp nie jest powodem do tworzenia duplikatu builda. Połącz się ponownie z konsolą builda lub endpointem statusu, używając tego samego identyfikatora builda. Gdy build kończy się terminal failed, zachowaj etap, błąd i logi przed ponowną próbą.
Zalecany workflow
- Napisz obserwowalne kryteria akceptacji.
- Wygeneruj lub edytuj przepis.
- Zwaliduj go i porównaj znormalizowany wynik z pełną rozmową.
- Sprawdź wywnioskowane funkcje, źródła zewnętrzne, ustawienia instalatora i scenariusze.
- Uruchom jeden build i śledź jego trwały identyfikator.
- Przejrzyj digest artefaktu, inwentarz pakietów, ostrzeżenia i dowody testów.
- Uruchom lub zainstaluj w jednorazowym środowisku dopasowanym do żądania.
- Promuj lub publikuj tylko przez właściwą approval gate.
Przewodniki tematyczne
| Temat | Zastosowanie |
|---|---|
| Base Images | Wybór obsługiwanej rodziny builda |
| Features | Zrozumienie zarejestrowanych modułów capability |
| Services | Deklarowanie konfiguracji usług |
| Custom Software | Przegląd wejść pakietów opartych o repozytorium |
| Users | Bezpieczne tworzenie kont lokalnych w obrazie |
| Desktop | Wybór i weryfikacja ustawień pulpitu |
| Startup Scripts | Pisanie ograniczonych jednostek first-boot |
Zacznij od najmniejszego użytecznego obrazu. Dodawaj funkcje dopiero po zrozumieniu zachowania i dowodów poprzedniego artefaktu.