Kas ir atkārtojams būvējums?
Deterministiskā uzbūve vai reproducējamā uzbūve ir nedaudz atšķirīga, bet no šī raksta tos var saprast kā vienu un to pašu.
Reproducējamie būvējumi attiecas uzVairākas veidošanas procesa izpildes ar vienu un to pašu ievadi un būvēšanas vidi var radīt tieši tādus pašus rezultātus。 Šī tehnoloģija ir svarīga programmatūras izstrādei, izplatīšanai un drošības validācijai.
Būvējums ir reproducējams, ja tas nodrošina tieši tādu pašu izvadi neatkarīgi no tā, kad un kur tas tiek palaists. Neatkarīgi no tā, kurā datorā darbojaties, kādā diennakts laikā un kādiem ārējiem pakalpojumiem piekļūstat tīklā, reproducējamie būvējumi rada to pašu baitu izvadi. Tas ir lieliski piemērots gan izstrādei (jo reproducējamus būvējumus ir viegli koplietot dažādās izstrādātāju ierīcēs), gan ražošanai (jo ir viegli nodrošināt, ka reproducējamo būvējumu rezultāti nav manipulēti - vienkārši atkārtoti palaidiet būvējumu savā datorā un pārbaudiet, vai rezultāti ir konsekventi!). ir ļoti noderīgi.
Trīs atkārtojamo būvējumu pīlāri
1. pīlārs: atkārtojami būvējumi
Būvēšanas atkārtojamība attiecas uz to, kas notiek ar pašu būvēšanas mašīnu. Pieņemot, ka mūsu būvēšanas ievades ir pieejamas un nekas nemainās apkārtējā pasaulē, vai mūsu būvēšana rada tādu pašu izvadi, kad to atkārto?
Deterministisks uzstādīšanas plāns
Pirmā, vienkāršākā un acīmredzamākā prasība atkārtojamā būvē ir deterministisks atkarības uzstādīšanas plāns.
Lielākajā daļā valodu tas ir tikpat vienkārši kā atdot bloķētu failu. Mūsdienu būvēšanas rīki bieži ļauj projektiem izteikt tiešās atkarības prasības kā ierobežojumus un pēc tam atrisināt šos ierobežojumus, lai ģenerētu instalācijas plānu (instalējamo atkarību nosaukumu un versiju pāru sarakstu). Daudzi no šiem rīkiem ģenerē arī bloķēšanas failus sērijveida instalēšanas plāniem. Izstrādātāji var iesniegt šos bloķēšanas failus versiju kontrolei, lai turpmākajos būvējumos tiktu izmantoti tie paši atkarību nosaukumi un versijas.
Ņemiet vērā, ka mums ir nepieciešams arī deterministisks atkarības veidošanā (ne tikai versijas izvēlē), un deterministisks uzstādīšanas plāns neļauj mums to sasniegt!
Deterministiska konstrukcija
Kad mēs zinām, ko veidot, mūsu būvei pašai (ieskaitot mūsu pašu kodu un atkarības koda veidošanu) faktiski jābūt deterministiskai.
Tas var nebūt problēma projektiem bez kompilēšanas soļa! Piemēram, mezgla projekts ar visām atkarībām ir tīrs JavaScript, un, lai panāktu efektīvu determinismu, nav nepieciešams papildu darbs.
Projektiem, kas ietver kompilācijas vai tulkošanas (avota avota apkopošanas) darbības, determinisma nodrošināšana ir visgrūtākā reproducējamas būves veidošanas daļa. Kompilācijas process var netieši ieviest nedeterminismu vairākos veidos, tostarp:
- Turing-complete programmas veidošanas skripti var mainīt kompilēto izvadi pēc vēlēšanās.
- Pēcinstalēšanas skripti, kas balstās uz izpildāmu failu sistēmas uzmeklēšanu vai tīkla izsaukumiem.
- C saistīšana ar sistēmas instalētu pakotni, kur saistījumi dažādās sistēmās ar dažādām galvenēm var radīt dažādas izvades.
- Darbības, lai izveidotu failu, kas lasāms ārpus versiju kontroles.
- Veidojiet darbības, lai ģenerētu laika zīmogus, izmantojot sistēmas laiku.
- Darbības, lai izveidotu atkarības, kas nav izteiktas tīkla lejupielādes instalēšanas plānā (piemēram, lejupielādējiet NPM atkarību no GitHub kešatmiņā esošam binārajam būvējumam, kas ir saistīts ar C).
- Mainiet darbību, pamatojoties uz pašreiz iestatīto vides mainīgo, bet neiesniedziet būvējumu ar vides mainīgā konfigurāciju.
Ne visas šīs darbības obligāti rada nenoteiktību, ja tās ir pareizi iestatītas, taču pareiza būvēšanas procesa konfigurēšana var būt sarežģīta un sarežģīta. Piemēram, varat izlasīt šo emuāra ziņu par nenoteiktību Chromium būvējumos. Daudzas no šīm problēmām var mazināt, kontrolējot vietējo būvniecības vidi, ko mēs apspriedīsim nākamajā sadaļā.
2. pīlārs: nemainīga vide
Pat ar atkārtojamiem būvējumiem mums ir jāpārliecinās, ka būvēšanas ievades nemainās. Bieži vien tas nozīmē, ka mēs vēlamies pārliecināties, ka mēs veidojam nemainīgu mūsu apkārtnes momentuzņēmumu.
Nemainīga vietējā vide
Kā mēs apspriedām iepriekš, izplatīts būvēšanas nenoteiktības avots ir paļaušanās uz "atkarībām", kuras nav uztvertas veidošanas rīkā. Visbiežāk sastopamie piemēri ir C saistītās sistēmas bibliotēkas, taču būvējumu var ietekmēt arī citi lokālie vides faktori, piemēram, vides mainīgo iestatījumi un faili, kas neietilpst versiju kontroles tvērumā.
Vienkāršs veids, kā mazināt šo problēmu, ir palaist būvējumu zināmā, nemainīgā konteinerā. Piemēram, konteinera izpildlaiks, piemēram, Docker, palīdz nodrošināt, ka visi izmanto vienas un tās pašas sistēmas atkarības, tos pašus vides mainīgos un darbojas vienā failu sistēmā. Turklāt ir viegli pārbaudīt, vai konteinera saturs atbilst zināmam labam konteineram, un, ja nepieciešams, konteineru var viegli pilnībā noņemt no zināmā labā attēla un atjaunot.
Ņemiet vērā, ka mēs esam ļoti skaidri par zināmiem konteineriem vai zināmiem konteineru attēliem. Nepietiek tikai ar Dockerfile iesniegšanu! Kāpēc? Jo pats Dockerfile neapraksta pilnībā reproducējamu Docker attēlu veidošanas procesu, jo tie nedarbojas nemainīgā globālā vidē.
Nemainīga globālā vide
Veidošanas sistēmas bieži mijiedarbojas ar ārējiem pakalpojumiem, lai izpildītu tādus uzdevumus kā versiju izšķirtspēja un atkarību lejupielāde. Bet ārējie pakalpojumi bieži mainās.
Šodien palaižot apt install nodejs, jūs saņemsiet atšķirīgus rezultātus nekā pagājušajā gadā, un, iespējams, arī nākamgad iegūsiet atšķirīgus rezultātus. Tāpēc Dockerfiles paši nevar aprakstīt reproducējamus būvējumus - palaižot vienu un to pašu Dockerfile dažādos laika punktos, tiks iegūti dažādi būvēšanas rezultāti!
Vienkārša mazināšana šeit ir konfigurēt būvējumu, kad vien iespējams, norādot precīzu versiju (ideālā gadījumā arī precīzu satura jaucējkodu), lai nākotnes būvējumi izmantotu to pašu versiju kā pašreizējais būvējums. Bet ārējie pakalpojumi var arī negaidīti mainīt savu uzvedību - patiesi pesimistisks reproducējams būvējums darbojas iekšējā attēlā ar pēc iespējas vairāk tīkla resursu.
3. pīlārs: resursu pieejamība
Pieņemsim, ka mūsu uzbūve ir atkārtojama un pasaule zem mūsu kājām nemainās. Viss, kas mums tagad nepieciešams, ir piekļuve būvēšanas ieguldījumam. Tas šķiet vienkārši, vai ne? Nu......
Reģistrs dažreiz neizdodas
Lielākā daļa mezglu izstrādātāju ir piedzīvojuši vismaz vienu NPM pārtraukumu, kura laikā tiek traucēts būvēšanas konveijers bez kešatmiņas vai spoguļošanas NPM pakotnes. Daudzi mezglu izstrādātāji ir piedzīvojuši arī kreisā spilventiņa un viltotāju noņemšanu, kas ir nopietni sabojājusi NPM ekosistēmu un faktiski izraisījusi pārtraukumu.
Vienīgais uzticamais veids, kā mazināt šādus būvēšanas pārtraukumus, ir palaist savu pakotņu reģistra spoguli. Ja ārējie pakalpojumi nav pieejami, attēls var palikt tiešsaistē; Kad oficiālais reģistrs izdzēš veco paketi, spogulis var turpināt sniegt pakalpojumus. Tas pats princips attiecas uz citiem attālinātiem pakalpojumiem: ja vien jūs neizmantojat savu attēlu, būvēšanas cauruļvada pieejamība ir salīdzināma tikai ar tā pakalpojumu pieejamību.
Pakalpojuma attēla palaišanas izvēle vienmēr ir delikāts kompromiss. No vienas puses, tādiem reģistriem kā NPM ir īpašas inženieru un operāciju komandas, kurām ir zināšanas, lai šīs sistēmas uzturētu tiešsaistē. No otras puses, ir daudz vieglāk palaist nelielu attēlu nelielam atkarību kopumam, nekā palaist visus NPM attēlus. Jums jāpieņem spoguļojoši lēmumi, pamatojoties uz katra pakalpojuma specifiku, ņemot vērā vēsturisko ārējo pakalpojumu uzticamību un jūsu komandas būvniecības pieejamību un personāla vajadzības.
Piegādātāji nodrošina maksimālu pieejamību
Vienkāršs veids, kā nodrošināt maksimālu projekta atkarību pieejamību, ir pievienot tās piegādātājam. Lielākā daļa pakotņu pārvaldnieku atbalsta kaut kādu "pārdevēju" formu, kas nozīmē, ka tā vietā, lai paļautos uz lejupielādēm no ārējiem pakalpojumiem, mēs glabājam atkarības avota kodu versiju kontrolē, kas pastāv līdzās mūsu avota kodam. Piemēram, Node tas varētu izskatīties kā node_modules nodošana avota kontrolei.
Lai gan šis risinājums nav ideāls (atkarībā no tā, kā ir iestatīts jūsu piegādātājs un projekts, kas var radīt lielu slodzi jūsu versiju kontrolei), tas bieži vien ir vienkāršākais un vienkāršākais risinājums maksimālai pieejamībai.
Atsauce:
Hipersaites pieteikšanās ir redzama.
Hipersaites pieteikšanās ir redzama. |
Publicēts 2025-4-30 10:09:27
|
|
|
|
Saimnieks|
Publicēts 2025-4-30 10:10:23
|
