Vlastní software ze zdrojových repozitářů
Recepty OpenFactory mohou na podporovaných image builderech odkazovat na Git repozitář jako vstup vlastního balíčku. Jde o cestu citlivou na dodavatelský řetězec: repozitář, vyřešenou revizi, instrukce pro balení, závislosti buildu a vzniklý balíček je třeba zkontrolovat.
Podpora závisí na cíli. Buildy zdrojových balíčků někteří buildery odmítají, včetně současných cest Raspberry Pi a Proxmox. Dostupnost ověřte v normalizovaném receptu a plánu buildu dřív, než slíbíte, že balíček vznikne.
Tvar receptu
Záznamy vlastních balíčků jsou pod os.custom_packages:
{
"os": {
"custom_packages": [
{
"name": "my-agent",
"git_url": "https://github.com/example/my-agent.git",
"branch": "release-1.x"
}
]
}
}Schéma přijímá název větve, ne neměnné pole commit. U kontrolovaného vydání zaznamenejte přesný commit, který build vyřeší, a zahrňte ho do uchované provenance. Samotná pohyblivá větev není reprodukovatelný vstup.
Připravte repozitář
Současná cesta balíčku očekává nativní metadata balení odpovídající cíli. Typické příklady jsou adresář Debian debian/ nebo RPM spec. Konkrétní chování buildera a podporované verze cíle se mohou měnit, proto ověřte minimální balíček v nasazeném prostředí místo spoléhání na statickou tabulku kompatibility.
U balení Debian zkontrolujte alespoň:
debian/controlkvůli identitě source/binary a závislostem;debian/changelogkvůli verzi balíčku;debian/rulesa další spustitelné maintainer skripty;- instalační manifesty a jednotky systemd; a
- licencování a svazkovaný materiál třetích stran.
U balení RPM zkontrolujte zdroje ve spec, požadavky buildu, scriptlety, seznam souborů a metadata licence.
Nikdy nepředpokládejte, že vlastnictví repozitáře dělá jeho build skripty bezpečnými. Buildy balíčků spouštějí nedůvěryhodný zdroj a logiku balení uvnitř izolační hranice build infrastruktury.
Další ovládání balíčků
Nativní balíčky
Použijte os.packages pro balíčky, které už dodává zvolená distribuce nebo explicitně nakonfigurované repozitář:
{
"os": {
"packages": ["curl", "jq"]
}
}Přepsání balíčků
os.package_overrides může deklarovat záměr add, remove nebo replace:
{
"os": {
"package_overrides": [
{"name": "nano", "action": "replace", "replacement": "neovim"},
{"name": "telnet", "action": "remove"}
]
}
}Přepsání nedokazuje, že řešení závislostí ho respektovalo. Ověřte konečný inventář balíčků a aserce absence/presence.
Další repozitáře
os.extra_repos je pokročilý vstup. Nepřidávejte nepodpsané HTTP repozitáře jako ve starších příkladech. Schválená integrace repozitáře vyžaduje transport HTTPS, připnutý podpisový klíč, vynucení podpisu, metadata release odpovídající správci balíčků a zdokumentované vlastnictví a politiku aktualizací. Pokud je současný builder nedokáže reprezentovat, repozitář nepoužívejte.
Důkazy pro akceptaci
U každého vlastního balíčku uchovejte:
- URL repozitáře a vyřešený commit;
- kontrolu zdroje a deklarované licence;
- prostředí buildu a snapshot závislostí;
- logy buildu a výsledný název/verzi/architekturu balíčku;
- digest balíčku a důkaz podpisu repozitáře, kde to platí;
- konečný inventář obrazu s nainstalovaným balíčkem;
- smoke testy služby nebo spustitelného souboru; a
- chování při odstranění a upgradu.
Úspěšná fáze zdrojového balíčku nestačí. Build obrazu může balíček později nespotřebovat a nainstalovaný balíček může být stále nepoužitelný.
Řešení problémů
- Metadata balení odmítnuta: ověřte nativní balíček lokálně se stejným release distribuce a architekturou.
- Chybí závislost buildu: používejte závislosti z schválených repozitářů pro daný cíl; v maintainer skriptu tiše nestahujte libovolné binárky.
- Balíček v obrazu chybí: porovnejte vyprodukovaný název binárního balíčku s normalizovaným požadavkem instalace a konečným inventářem.
- Verze se nezměnila: aktualizujte nativní metadata verze a potvrďte, že byl vyřešen nový source commit.
- Služba selhala: prohlédněte její unit, runtime závislosti, oprávnění a logy hosta; před rebuildem přidejte aserci na úrovni chování.