Kaj je ponovljiva sestava?
Deterministična gradnja ali ponovljiva gradnja sta nekoliko drugačni, vendar ju lahko razumemo kot isto stvar iz tega članka.
Reproducibilne gradnje se nanašajo naVeč izvedb gradbenega procesa z istim vhodnim in gradbenim okoljem lahko ustvari popolnoma enake rezultate。 Ta tehnologija je pomembna za razvoj programske opreme, distribucijo in preverjanje varnosti.
Sestava je ponovljiva, če zagotavlja popolnoma enak izhod ne glede na to, kdaj in kje je zagnana. Ne glede na to, na katerem računalniku tečete, ob katerem času dneva in do katerih zunanjih storitev dostopate prek omrežja, ponovljive gradnje proizvedejo enak izhod bajt za bajtom. To je odlično tako za razvoj (ker so ponovljive različice enostavne za deljenje med različnimi razvijalskimi napravami) kot za produkcijo (ker je enostavno zagotoviti, da rezultati ponovljivih različic niso bili spremenjeni – preprosto ponovno zaženite različico na svojem računalniku in preverite, da so rezultati skladni!). so zelo uporabni.
Trije stebri ponovljivih zgradb
Steber 1: Ponovljive zgradbe
Ponovljivost gradnje se nanaša na to, kaj se zgodi s samim strojem za gradnjo. Če predpostavimo, da so naši vhodni podatki za gradnjo na voljo in se v svetu okoli nas nič ne spremeni, ali naša gradnja proizvede enak izhod, ko se ponovi?
Deterministični načrt namestitve
Prva, najpreprostejša in najbolj očitna zahteva pri ponovljivi gradnji je deterministični načrt namestitve odvisnosti.
V večini jezikov je to tako preprosto kot preverjanje zaklenjene datoteke. Sodobna gradbena orodja pogosto omogočajo projektom, da izrazijo neposredne zahteve po odvisnosti kot omejitve, nato pa te omejitve rešijo za generiranje načrta namestitve (seznam imen odvisnosti in parov različic za namestitev). Mnoga od teh orodij prav tako generirajo datoteke zaklepov za serijske namestitvene načrte. Razvijalci lahko te zaklepne datoteke pošljejo v nadzor različic, da bodo prihodnje različice uporabljale enaka imena odvisnosti in različice.
Upoštevajte, da potrebujemo deterministične tudi v sami gradnji odvisnosti (ne samo pri izbiri različic), deterministični načrt namestitve pa nam tega ne omogoča!
Deterministična konstrukcija
Ko vemo, kaj zgraditi, mora biti naša gradnja sama (vključno z našo kodo in gradnjo kode odvisnosti) dejansko deterministična.
To morda sploh ni problem za projekte brez koraka prevajanja! Na primer, Node projekt z vsemi odvisnostmi je čisti JavaScript in za dosego učinkovite determinističnosti ni potrebno dodatno delo.
Za projekte, ki vključujejo korake prevajanja ali prevajanja (prevajanje od izvora do vira), je zagotavljanje determinizma daleč najtežji del izdelave ponovljive gradnje. Postopek prevajanja lahko implicitno uvede nedeterminizem na več načinov, med drugim:
- Turing-popolni skripti za gradnjo programa lahko po želji spremenijo prevedeni izhod.
- Skripte po namestitvi, ki temeljijo na izvedljivih iskanjih datotečnega sistema ali omrežnih klicev.
- C vezava na sistemsko nameščen paket, kjer lahko vezave na različnih sistemih z različnimi glavami proizvedejo različne izhode.
- Koraki za izdelavo datoteke, ki bere izven nadzora različic.
- Naredite korake za generiranje časovnih žigov z uporabo sistemskega časa.
- Koraki za gradnjo odvisnosti, ki niso izražene v načrtu namestitve omrežnega prenosa (na primer prenos NPM odvisnosti z GitHuba za predpomnjeno binarno gradnjo, ki je omejena na C).
- Spremenite vedenje glede na trenutno nastavljeno okoljsko spremenljivko, vendar ne oddajajte gradnje z konfiguracijo okoljske spremenljivke.
Ne vsa ta vedenja nujno prinašajo negotovost, če so pravilno nastavljena, vendar je pravilna konfiguracija gradbenega procesa lahko zapletena in zahtevna. Na primer, lahko preberete ta blog zapis o negotovosti v Chromium različicah. Veliko teh težav je mogoče omiliti z nadzorom lokalnega gradbenega okolja, o katerem bomo govorili v naslednjem razdelku.
Steber 2: Nespremenljivo okolje
Tudi pri ponovljivih sestavah moramo poskrbeti, da se vhodni podatki za gradnjo ne spremenijo. Pogosto to pomeni, da želimo graditi na nespremenljivem posnetku našega okolja.
Nespremenljivo lokalno okolje
Kot smo že omenili, je pogost vir negotovosti gradnje zanašanje na "odvisnosti", ki jih orodje za gradnjo ne zaje. Najpogostejši primeri so sistemske knjižnice, omejene s C, vendar lahko na gradnjo vplivajo tudi drugi lokalni okoljski dejavniki, kot so nastavitve okoljskih spremenljivk in datoteke, ki niso pod nadzorom različic.
Enostaven način za omilitev te težave je, da gradnjo zaženete v znanem, nespremenljivem kontejnerju. Na primer, zagonsko okolje, kot je Docker, pomaga zagotoviti, da vsi uporabljajo enake sistemske odvisnosti, iste okoljske spremenljivke in tečejo na istem datotečnem sistemu. Poleg tega je enostavno preveriti, ali vsebina posode ustreza znani dobri gradbeni posodi, in če je potrebno, jo je mogoče popolnoma odstraniti iz slike znane dobre in ponovno ustvariti.
Upoštevajte, da smo zelo jasni glede znanih kontejnerjev ali znanih slik vsebnikov. Ni dovolj, da samo oddate Dockerfile! Zakaj? Ker sam Dockerfile ne opisuje popolnoma ponovljivega procesa gradnje za Docker slike, ker ne tečejo v nespremenljivem globalnem okolju.
Nespremenljivo globalno okolje
Gradbeni sistemi pogosto sodelujejo z zunanjimi storitvami za opravljanje nalog, kot so reševanje različic in prenos odvisnosti. A zunanje storitve se pogosto spreminjajo.
Če danes zaženeš namestitev montažnih nodejov, boš dobil drugačne rezultate kot lani, verjetno pa tudi prihodnje leto. Zato Dockerfile sami ne morejo opisati ponovljivih buildov – zagon istega Dockerfileja v različnih časovnih trenutkih bo dal različne izhodne rezultate!
Preprosta rešitev tukaj je, da se gradnja konfigurira, kadar je mogoče, pri čemer določite natančno različico (idealno tudi natančen hash vsebine), da bodo prihodnje različice uporabljale isto različico kot trenutna različica. A zunanje storitve lahko tudi nepričakovano spremenijo svoje vedenje – resnično pesimistična ponovljiva gradnja poganja notranjo sliko z čim več omrežnimi viri.
Steber 3: Razpoložljivost virov
Recimo, da je naša gradnja ponovljiva in se svet pod našimi nogami ne spremeni. Zdaj potrebujemo le še dostop do vhodnih podatkov za gradnjo. Zdi se preprosto, kajne? Dobro......
Register včasih odpove
Večina razvijalcev Node je doživela vsaj en izpad NPM, med katerim je bil gradbeni cevovod brez predpomnjenja ali zrcapljenja NPM paketov moten. Veliko razvijalcev Node je prav tako doživelo odstranitev leve ploščice in lažnih naprav, ki so močno poškodovale ekosistem NPM in dejansko pomenile izpad delovanja.
Edini zanesljiv način za omilitev takšnih napak v gradnji je, da zaženete lastno zrcalo registra paketov. Ko zunanje storitve niso na voljo, lahko slika ostane na spletu; Ko uradni register izbriše stari paket, lahko zrcalo še naprej nudi storitve. Enako načelo velja za druge oddaljene storitve: razen če zaženete svojo sliko, je razpoložljivost gradbenega cevovoda primerljiva le z razpoložljivostjo njegovih storitev.
Odločitev za vodenje podobe storitve je vedno občutljiva menjava. Po eni strani imajo registri, kot je NPM, namenske inženirske in operativne ekipe, ki imajo strokovno znanje za ohranjanje teh sistemov v pogonu. Po drugi strani pa je veliko lažje zagnati majhno sliko za majhen nabor odvisnosti kot zagnati vse NPM slike. Odločitve o zrcadlenju bi morali sprejemati na podlagi specifičnosti vsake storitve, ob upoštevanju zanesljivosti zgodovinskih zunanjih storitev ter razpoložljivosti gradnje in kadrovskih potreb vaše ekipe.
Dobavitelji zagotavljajo največjo razpoložljivost
Enostaven način, da zagotovite največjo razpoložljivost odvisnosti vašega projekta, je, da jih dodate svojemu dobavitelju. Večina upravljalnikov paketov podpira neko obliko "prodaje", kar pomeni, da namesto da bi se zanašali na prenose iz zunanjih storitev, shranjujemo izvorno kodo odvisnosti v nadzoru različic, ki sobiva z izvorno kodo. Na primer, v Node bi to lahko izgledalo kot prenos node_modules v nadzor izvorne kode.
Čeprav ta rešitev ni popolna (odvisno od tega, kako je vaš ponudnik in projekt nastavljen, kar lahko močno obremeni vaš nadzor različic), je pogosto najpreprostejša in najlažja rešitev za maksimalno razpoložljivost.
Referenčni:
Prijava do hiperpovezave je vidna.
Prijava do hiperpovezave je vidna. |
Objavljeno 30. 4. 2025 ob 10:09:27
|
|
|
|
Najemodajalec|
Objavljeno 30. 4. 2025 ob 10:10:23
|
