Ce este o construcție repetabilă?
Construcția deterministă sau construcția reproductibilă sunt ușor diferite, dar pot fi înțelese ca fiind același lucru din acest articol.
Construcțiile reproductibile se referă laExecuțiile multiple ale procesului de build cu același input și același mediu de build pot produce exact aceleași rezultate。 Această tehnologie este importantă pentru dezvoltarea software, distribuția și validarea securității.
O construcție este reproductibilă dacă oferă exact aceeași ieșire, indiferent de când și unde este rulată. Indiferent pe ce calculator folosești, la ce oră din zi și la ce servicii externe accesezi prin rețea, build-urile reproductibile produc aceeași ieșire octet cu octet. Acest lucru este excelent atât pentru dezvoltare (deoarece versiunile reproductibile sunt ușor de împărtășit între diferite dispozitive de dezvoltare), cât și pentru producție (pentru că este ușor să te asiguri că rezultatele construcțiilor reproductibile nu au fost modificate – pur și simplu rulează build-ul pe propria ta mașină și verifică dacă rezultatele sunt consistente!). sunt foarte utile.
Cei trei piloni ai construcțiilor repetabile
Pilonul 1: Construcții repetabile
Repetabilitatea build-ului se referă la ce se întâmplă cu mașina de build în sine. Presupunând că intrările noastre de build sunt disponibile și nimic nu se schimbă în lumea din jurul nostru, build-ul nostru produce același rezultat când este repetat?
Plan de instalare determinist
Prima, cea mai simplă și cea mai evidentă cerință într-o construcție repetabilă este un plan determinist de instalare a dependenței.
În majoritatea limbilor, este la fel de simplu ca și cum ai verifica un fișier blocat. Instrumentele moderne de build permit adesea proiectelor să exprime cerințe directe de dependență ca constrângeri, apoi să rezolve aceste constrângeri pentru a genera un plan de instalare (o listă de nume de dependențe și perechi de versiuni de instalat). Multe dintre aceste unelte generează, de asemenea, fișiere de blocare pentru planuri de instalare serializate. Dezvoltatorii pot trimite aceste fișiere de blocare către controlul versiunilor, astfel încât versiunile viitoare să folosească aceleași nume de dependențe și versiuni.
Reține că avem nevoie și de construcția de dependență deterministă (nu doar de selecția versiunii), iar un plan de instalare determinist nu ne permite să realizăm acest lucru!
Construcție deterministă
Odată ce știm ce să construim, build-ul nostru în sine (inclusiv propriul nostru cod și construcția codului de dependență) trebuie să fie de fapt determinist.
Acest lucru poate să nu fie o problemă pentru proiecte fără un pas de compilare! De exemplu, un proiect Node cu toate dependențele este JavaScript pur și nu este necesară muncă suplimentară pentru a atinge deterministicitatea efectivă.
Pentru proiectele care includ pași de compilare sau traducere (compilare sursă-la-sursă), asigurarea determinismului este de departe cea mai dificilă parte a construirii unei construcții reproductibile. Procesul de compilare poate introduce implicit nondeterminismul în mai multe moduri, inclusiv:
- Scripturile de compilare a programelor Turing-complete pot schimba ieșirea compilată după bunul plac.
- Scripturi post-instalare care se bazează pe căutări executabile ale sistemului de fișiere sau apeluri de rețea.
- Legarea C către un pachet instalat de sistem, unde legăturile pe sisteme diferite cu headeri diferiți pot produce ieșiri diferite.
- Pași pentru a construi un fișier care se citește în afara controlului de versiuni.
- Construiește pași pentru a genera timestamp-uri folosind timpul de sistem.
- Pași pentru a construi dependențe care nu sunt exprimate în planul de instalare a descărcării rețelei (de exemplu, descărcarea unei dependențe NPM de pe GitHub pentru o construcție binară cached care este legată de C).
- Schimbă comportamentul în funcție de variabila de mediu setată în prezent, dar nu trimite o construcție cu configurația variabilei de mediu.
Nu toate aceste comportamente introduc neapărat incertitudine atunci când sunt configurate corect, dar configurarea corectă a procesului de construcție poate fi complexă și dificilă. De exemplu, poți citi această postare de blog despre incertitudinea în construcțiile Chromium. Multe dintre aceste probleme pot fi atenuate prin controlul mediului local de construcție, lucru despre care vom discuta în secțiunea următoare.
Pilonul 2: Mediul imuabil
Chiar și cu build-uri repetabile, trebuie să ne asigurăm că input-urile de build nu se schimbă. Adesea, asta înseamnă că vrem să ne asigurăm că construim pe o imagine imuabilă a mediului înconjurător.
Mediul local imuabil
Așa cum am discutat mai sus, o sursă comună de incertitudine a build-ului este dependența de "dependențe" care nu sunt capturate de instrumentul build. Cele mai comune exemple sunt bibliotecile de sistem C-bound, dar alți factori locali de mediu, cum ar fi setările variabilelor de mediu și fișierele care nu țin de controlul versiunilor, pot afecta de asemenea construcția.
O metodă simplă de a reduce această problemă este să rulezi build-ul într-un container cunoscut, imuabil. De exemplu, un runtime container precum Docker ajută la asigurarea faptului că toată lumea folosește aceleași dependențe de sistem, aceleași variabile de mediu și rulează pe același sistem de fișiere. În plus, este ușor de verificat dacă conținutul containerului corespunde unui container de construcție bine cunoscut, iar dacă este necesar, containerul poate fi scos complet din imaginea cunoscută și recreat.
Rețineți că suntem foarte clari în privința containerelor cunoscute sau a imaginilor containerelor cunoscute. Nu este suficient să trimiți doar un fișier Dockerfile! De ce? Pentru că Dockerfile-ul în sine nu descrie un proces de compilare complet reproductibil pentru imaginile Docker, deoarece acestea nu rulează într-un mediu global imuabil.
Mediul global imuabil
Sistemele de build interacționează adesea cu servicii externe pentru a finaliza sarcini precum rezolvarea versiunilor și descărcarea dependențelor. Dar serviciile externe se schimbă frecvent.
Rularea apt-install nodejs astăzi îți va da rezultate diferite față de anul trecut, iar probabil că anul viitor vei obține și rezultate diferite. De aceea Dockerfiles în sine nu poate descrie build-uri reproductibile – rularea aceluiași Dockerfile în momente diferite va produce ieșiri de build diferite!
Atenuarea simplă aici este să configurezi construcția ori de câte ori este posibil, specificând o versiune exactă (ideal și un hash exact de conținut) astfel încât versiunile viitoare să folosească aceeași versiune ca și cea curentă. Dar serviciile externe își pot schimba comportamentul neașteptat – o construcție cu adevărat pesimistă și reproductibilă rulează o imagine internă cu cât mai multe dintre resursele sale de rețea.
Pilonul 3: Disponibilitatea resurselor
Să zicem că construcția noastră este repetabilă și lumea de sub picioarele noastre nu se schimbă. Tot ce ne trebuie acum este acces la inputul de construcție. Pare simplu, nu-i așa? Bine......
Registrul uneori eșuează
Majoritatea dezvoltatorilor Node au experimentat cel puțin o întrerupere NPM, în timpul căreia pipeline-ul de build fără cache sau oglindere a pachetelor NPM este perturbat. Mulți dezvoltatori Node au experimentat, de asemenea, eliminări de left-pad și faker, care au afectat grav ecosistemul NPM și au echivalat efectiv cu o întrerupere.
Singura modalitate sigură de a reduce astfel de întreruperi de compilație este să rulezi propria oglindă a registrului de pachete. Când serviciile externe nu sunt disponibile, imaginea poate rămâne online; Când registrul oficial șterge pachetul vechi, oglinda poate continua să ofere servicii. Același principiu se aplică și altor servicii la distanță: dacă nu rulezi propria imagine, disponibilitatea unui pipeline de build este comparabilă doar cu disponibilitatea serviciilor sale.
Alegerea de a rula o imagine de serviciu este întotdeauna un compromis delicat. Pe de o parte, registrele precum NPM au echipe dedicate de inginerie și operațiuni, care au expertiza necesară pentru a menține aceste sisteme online. Pe de altă parte, este mult mai ușor să rulezi o imagine mică pentru un set restrâns de dependențe decât să rulezi toate imaginile NPM. Ar trebui să iei decizii în oglindire bazate pe specificul fiecărui serviciu, ținând cont de fiabilitatea serviciilor externe istorice și de disponibilitatea construcțiilor și nevoile de personal ale echipei tale.
Furnizorii asigură disponibilitate maximă
O modalitate simplă de a asigura disponibilitatea maximă a dependențelor proiectului este să le adaugi la furnizor. Majoritatea managerilor de pachete suportă o formă de "vendoring", ceea ce înseamnă că, în loc să ne bazăm pe descărcări din servicii externe, stocăm codul sursă al dependenței în controlul versiunilor, coexistând cu codul nostru sursă. De exemplu, în Node, acest lucru ar putea însemna că node_modules se angajează în controlul surselor.
Deși această soluție nu este perfectă (în funcție de cum este configurat furnizorul și proiectul, ceea ce poate pune multă presiune pe controlul versiunilor), este adesea cea mai simplă și ușoară soluție pentru disponibilitate maximă.
Referință:
Autentificarea cu hyperlink este vizibilă.
Autentificarea cu hyperlink este vizibilă. |
Postat la 30-04-2025 10:09:27
|
|
|
|
Proprietarul|
Postat la 2025-4-30 10:10:23
|
