Čo je to opakovateľná zostava?
Deterministická zostava alebo reprodukovateľná zostava sú trochu odlišné, ale z tohto článku ich možno chápať ako to isté.
Reprodukovateľné zostavy označujúViaceré spustenia procesu zostavovania s rovnakým vstupom a prostredím môžu priniesť úplne rovnaké výsledky。 Táto technológia je dôležitá pre vývoj softvéru, distribúciu a overovanie bezpečnosti.
Zostava je reprodukovateľná, ak poskytuje presne rovnaký výstup bez ohľadu na to, kedy a kde sa spustí. Nezáleží na tom, na ktorom počítači bežíte, v akú dennú dobu a aké externé služby cez sieť používate, reprodukovateľné zostavy produkujú rovnaký bajt po bajte výstupu. To je skvelé pre vývoj (pretože reprodukovateľné zostavenia sa ľahko zdieľajú medzi rôznymi vývojárskymi zariadeniami) aj pre produkciu (pretože je jednoduché zabezpečiť, že výsledky reprodukovateľných kompilácií neboli upravené – stačí znovu spustiť zostavenie na svojom počítači a skontrolovať, či sú výsledky konzistentné!). sú veľmi užitočné.
Tri piliere opakovateľných zostáv
Pilier 1: Opakovateľné buildy
Opakovateľnosť stavby sa týka toho, čo sa deje priamo so strojom na stavbu. Za predpokladu, že naše vstupy na zostavenie sú dostupné a nič sa vo svete okolo nás nemení, produkuje náš build rovnaký výstup pri opakovaní?
Deterministický plán inštalácie
Prvou, najjednoduchšou a najzrejmejšou požiadavkou v opakovateľnej zostave je deterministický plán inštalácie závislostí.
Vo väčšine jazykov je to také jednoduché, ako skontrolovať uzamknutý súbor. Moderné stavebné nástroje často umožňujú projektom vyjadriť priame požiadavky na závislosti ako obmedzenia a potom tieto obmedzenia vyriešiť na vytvorenie inštalačného plánu (zoznam mien závislostí a párov verzií na inštaláciu). Mnohé z týchto nástrojov tiež generujú zámkové súbory pre sériové inštalačné plány. Vývojári môžu tieto zámkové súbory odoslať na správu verzií, aby budúce zostavy používali rovnaké názvy závislostí a verzie.
Upozorňujeme, že deterministický prístup potrebujeme aj v samotnom builde závislostí (nielen pri výbere verzie), a deterministický plán inštalácie nám to neumožňuje!
Deterministická konštrukcia
Keď vieme, čo postaviť, samotná naša zostava (vrátane nášho vlastného kódu a zostavenia závislostného kódu) musí byť skutočne deterministická.
Toto nemusí byť problém pre projekty bez kroku kompilácie! Napríklad projekt Node so všetkými závislosťami je čistý JavaScript a na dosiahnutie efektívnej deterministity nie je potrebná žiadna ďalšia práca.
Pri projektoch, ktoré zahŕňajú kroky kompilácie alebo prekladu (kompilácia zdroj-zdroj) je zabezpečenie determinizmu jednoznačne najťažšou časťou tvorby reprodukovateľnej zostavy. Proces kompilácie môže implicitne zaviesť nedeterminizmus rôznymi spôsobmi, vrátane:
- Turing-kompletné skripty pre zostavovanie programov môžu podľa potreby meniť skompilovaný výstup.
- Post-inštalačné skripty, ktoré sa spoliehajú na vyhľadávanie spustiteľného súborového systému alebo sieťové volania.
- C viazanie na balík nainštalovaný systémom, kde viazania na rôznych systémoch s rôznymi hlavičkami môžu produkovať rôzne výstupy.
- Kroky na vytvorenie súboru, ktorý číta mimo režimu verzovania.
- Vytvárajte kroky na generovanie časových značiek pomocou systémového času.
- Kroky na vytvorenie závislostí, ktoré nie sú vyjadrené v pláne inštalácie sieťového sťahovania (napríklad stiahnuť NPM závislosť z GitHubu pre cacheovaný binárny build viazaný na C).
- Zmeňte správanie na základe aktuálne nastavenej premennej prostredia, ale neodosielajte zostavu s konfiguráciou premennej prostredia.
Nie všetky tieto správania nevyhnutne prinášajú neistotu, ak sú správne nastavené, ale správne nakonfigurovanie stavebného procesu môže byť zložité a náročné. Napríklad si môžete prečítať tento blogový príspevok o neistote v Chromium buildoch. Mnohé z týchto problémov je možné zmierniť kontrolou miestneho stavebného prostredia, o ktorom budeme hovoriť v ďalšej časti.
Pilier 2: Nemenné prostredie
Aj pri opakovateľných zostavách musíme zabezpečiť, aby sa vstupy pre zostavy nezmenili. Často to znamená, že chceme stavať na nemennej snímke nášho okolia.
Nemenné lokálne prostredie
Ako sme už spomenuli, bežným zdrojom neistoty zostavenia je spoliehanie sa na "závislosti", ktoré build nástroj nezachytáva. Najčastejšími príkladmi sú systémové knižnice viazané na C, ale aj iné lokálne environmentálne faktory, ako sú nastavenia premenných prostredia a súbory mimo rozsahu kontroly verzií, môžu ovplyvniť zostavenie.
Jednoduchý spôsob, ako tento problém zmierniť, je spustiť build v známom, nemennom kontajneri. Napríklad kontajnerový runtime ako Docker pomáha zabezpečiť, že všetci používajú rovnaké systémové závislosti, rovnaké environmentálne premenné a bežia na rovnakom súborovom systéme. Okrem toho je ľahké overiť, že obsah kontajnera zodpovedá známemu dobrému stavebnému kontajneru, a ak je to potrebné, kontajner je možné úplne odstrániť z obrazu známeho dobrého a znovu vytvoriť.
Upozorňujeme, že sme veľmi jasní ohľadom známych kontajnerov alebo známych obrazov kontajnerov. Nestačí len odoslať Dockerfile! Prečo? Pretože samotný Dockerfile nepopisuje plne reprodukovateľný build proces pre Docker obrázky, pretože nebežia v nemennom globálnom prostredí.
Nemenné globálne prostredie
Build systémy často komunikujú s externými službami na vykonávanie úloh ako riešenie verzií a sťahovanie závislostí. Ale externé služby sa často menia.
Spustenie inštalačných nodejov APT dnes ti prinesie iné výsledky ako minulý rok a pravdepodobne aj budúci rok bude mať iné výsledky. Preto samotné Dockerfile nedokážu opísať reprodukovateľné zostavenia – spustenie toho istého Dockerfile v rôznych časových momentoch spôsobí rôzne výstupy zostavy!
Jednoduchým riešením je nakonfigurovať zostavu kedykoľvek je to možné, špecifikovať presnú verziu (ideálne aj presný hash obsahu), aby budúce zostavy používali rovnakú verziu ako aktuálna verzia. Ale externé služby môžu tiež nečakane zmeniť svoje správanie – skutočne pesimistická reprodukovateľná zostava spustí interný obraz s čo najväčším počtom svojich sieťových zdrojov.
Pilier 3: Dostupnosť zdrojov
Povedzme, že naša stavba je opakovateľná a svet pod našimi nohami sa nemení. Teraz už potrebujeme len prístup k vstupu na zostavu. Zdá sa to jednoduché, však? Studňa......
Register niekedy zlyháva
Väčšina vývojárov Node zažila aspoň jeden výpadok NPM, počas ktorého bol narušený build pipeline bez cacheovania alebo zrkadlenia NPM balíkov. Mnohí vývojári Node tiež zažili odstránenie ľavého padu a fakerov, čo vážne poškodilo ekosystém NPM a v podstate predstavovalo výpadok prevádzky.
Jediný spoľahlivý spôsob, ako zmierniť takéto poruchy zostavenia, je spustiť vlastné zrkadlo v registri balíkov. Keď nie sú dostupné externé služby, obrázok môže zostať online; Keď oficiálny register vymaže starý balík, zrkadlo môže naďalej poskytovať služby. Rovnaký princíp platí aj pre iné vzdialené služby: pokiaľ nespustíte vlastný obraz, dostupnosť build pipeline je porovnateľná len s dostupnosťou jeho služieb.
Rozhodnutie prevádzkovať imidž služby je vždy citlivý kompromis. Na jednej strane majú registre ako NPM vyhradené inžinierske a prevádzkové tímy, ktoré majú odborné znalosti na udržanie týchto systémov online. Na druhej strane je oveľa jednoduchšie spustiť malý obraz pre malú sadu závislostí než spustiť všetky NPM obrazy. Mali by ste robiť zrkadlové rozhodnutia na základe špecifík každej služby, pričom beriete do úvahy spoľahlivosť historických externých služieb a potreby vášho tímu, dostupnosti a personálneho obsadenia.
Dodávatelia zabezpečujú maximálnu dostupnosť
Jednoduchý spôsob, ako zabezpečiť maximálnu dostupnosť závislostí vášho projektu, je pridať ich k vášmu dodávateľovi. Väčšina správcov balíkov podporuje nejakú formu "vendoringu", čo znamená, že namiesto spoliehania sa na sťahovanie z externých služieb ukladáme zdrojový kód závislostí vo verzionárskom správe, ktorý koexistuje s naším zdrojovým kódom. Napríklad v Node to môže vyzerať ako commitovanie node_modules do správy zdrojových kódov.
Aj keď toto riešenie nie je dokonalé (v závislosti od nastavenia dodávateľa a projektu, čo môže výrazne zaťažiť vašu správu verzií), často je to najjednoduchšie a najjednoduchšie riešenie pre maximálnu dostupnosť.
Referencia:
Prihlásenie na hypertextový odkaz je viditeľné.
Prihlásenie na hypertextový odkaz je viditeľné. |
Zverejnené 30.4.2025 10:09:27
|
|
|
|
Prenajímateľ|
Zverejnené 30.4.2025 10:10:23
|
