este utilitarul nostru open source GitOps CLI pentru construirea și livrarea de aplicații către Kubernetes. Cum a promis, a marcat începutul adăugării de noi caracteristici la werf și al revizuirii abordărilor tradiționale. Acum suntem încântați să prezentăm versiunea 1.1, care este un pas mare în dezvoltare și o bază pentru viitor colector werf. Versiunea este disponibilă în prezent în .
Baza lansării este noua arhitectură a stocării scenei și optimizarea muncii ambilor colecționari (pentru Stapel și Dockerfile). Noua arhitectură de stocare deschide posibilitatea implementării de ansambluri distribuite de la mai multe gazde și ansambluri paralele pe aceeași gazdă.
Optimizarea muncii include eliminarea calculelor inutile în etapa de calcul a semnăturilor de etapă și schimbarea mecanismelor de calcul a sumelor de verificare a fișierelor cu altele mai eficiente. Această optimizare reduce timpul mediu de construire a proiectelor folosind werf. Și build-urile inactive, când toate etapele există în cache etape-depozitare, sunt acum foarte rapide. În cele mai multe cazuri, repornirea build-ului va dura mai puțin de 1 secundă! Acest lucru se aplică și procedurilor de verificare a etapelor procesului de lucru al echipelor. werf deploy и werf run.
Tot în această ediție a apărut o strategie de etichetare a imaginilor după conținut - etichetarea bazată pe conținut, care este acum activat implicit și singurul recomandat.
Să aruncăm o privire mai atentă la inovațiile cheie din werf v1.1 și, în același timp, să vă spunem despre planurile de viitor.
Ce s-a schimbat în werf v1.1?
Nou format de denumire a etapelor și algoritm pentru selectarea etapelor din cache
Noua regulă de generare a numelor de scenă. Acum, fiecare construcție de etapă generează un nume de etapă unic, care constă din 2 părți: o semnătură (cum era în v1.0) plus un identificator temporar unic.
De exemplu, numele complet al imaginii de scenă ar putea arăta astfel:
werf-stages-storage/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835
...sau in general:
werf-stages-storage/PROJECT:SIGNATURE-TIMESTAMP_MILLISEC
aici:
-
SIGNATUREeste o semnătură de etapă, care reprezintă identificatorul conținutului etapei și depinde de istoricul editărilor din Git care au condus la acest conținut; -
TIMESTAMP_MILLISECeste un identificator de imagine unic garantat care este generat în momentul în care este construită o nouă imagine.
Algoritmul pentru selectarea etapelor din cache se bazează pe verificarea relației dintre commit-urile Git:
- Werf calculează semnătura unei anumite etape.
- В etape-depozitare Pot exista mai multe etape pentru o anumită semnătură. Werf selectează toate etapele care se potrivesc cu semnătura.
- Dacă etapa curentă este conectată la Git (git-archive, etapa personalizată cu corecții Git:
install,beforeSetup,setup; sau git-latest-patch), apoi werf selectează numai acele etape care sunt asociate cu un commit care este un strămoș al commit-ului curent (pentru care este apelat build-ul). - Dintre etapele adecvate rămase, este selectată una - cea mai veche după data creării.
O etapă pentru diferite ramuri Git poate avea aceeași semnătură. Dar werf va împiedica cache-ul asociat cu diferite ramuri să fie folosit între aceste ramuri, chiar dacă semnăturile se potrivesc.
.
Algoritm nou pentru crearea și salvarea etapelor în stocarea etapei
Dacă, la selectarea etapelor din cache, werf nu găsește o etapă potrivită, atunci se inițiază procesul de asamblare a unei noi etape.
Rețineți că procesele multiple (pe una sau mai multe gazde) pot începe construirea aceleiași etape aproximativ în același timp. Werf folosește un algoritm de blocare optimist etape-depozitare în momentul salvării imaginii proaspăt colectate în etape-depozitare. În acest fel, când noua construcție a etapei este gata, werf se blochează etape-depozitare și salvează acolo o imagine proaspăt colectată numai dacă o imagine adecvată nu mai există acolo (prin semnătură și alți parametri - vezi noul algoritm pentru selectarea etapelor din cache).
O imagine proaspăt asamblată are garantat un identificator unic prin TIMESTAMP_MILLISEC (vezi noul format de denumire a scenei). În cazul în care etape-depozitare se va găsi o imagine potrivită, werf va elimina imaginea proaspăt compilată și va folosi imaginea din cache.
Cu alte cuvinte: primul proces pentru a termina construirea imaginii (cel mai rapid) va obține dreptul de a o stoca în etape-stocare (și apoi această singură imagine va fi folosită pentru toate build-urile). Un proces de construire lent nu va bloca niciodată un proces mai rapid de la salvarea rezultatelor construcției din etapa curentă și de la trecerea la următoarea construcție.
.
Performanță îmbunătățită a constructorului Dockerfile
În prezent, conducta de etape pentru o imagine construită dintr-un Dockerfile constă dintr-o etapă - dockerfile. La calcularea semnăturii, se calculează suma de control a fișierelor context, care va fi folosit în timpul asamblarii. Înainte de această îmbunătățire, werf a parcurs recursiv toate fișierele și a obținut o sumă de verificare prin însumarea contextului și modului fiecărui fișier. Începând cu v1.1, werf poate folosi sume de control calculate stocate într-un depozit Git.
Algoritmul se bazează pe . Algoritmul ia în considerare înregistrările în .dockerignore și traversează arborele de fișiere recursiv numai atunci când este necesar. Astfel, am decuplat de citirea sistemului de fișiere și dependența algoritmului de dimensiunea context nu este semnificativă.
Algoritmul verifică și fișierele neurmărite și, dacă este necesar, le ia în considerare în suma de control.
Performanță îmbunătățită la importul fișierelor
Versiunile de werf v1.1 folosesc un server rsync atunci când . Anterior, importul se făcea în doi pași folosind o montare de director din sistemul gazdă.
Performanța de import pe macOS nu mai este limitată de volumele Docker, iar importurile se finalizează în același timp ca Linux și Windows.
Etichetare bazată pe conținut
Werf v1.1 acceptă așa-numita etichetare după conținutul imaginii - etichetarea bazată pe conținut. Etichetele imaginilor Docker rezultate depind de conținutul acestor imagini.
Când rulați comanda werf publish --tags-by-stages-signature sau werf ci-env --tagging-strategy=stages-signature imagini publicate ale așa-zisului semnătură de scenă imagine. Fiecare imagine este etichetată cu propria semnătură a etapelor acestei imagini, care este calculată conform acelorași reguli ca și semnătura obișnuită a fiecărei etape separat, dar este un identificator general al imaginii.
Semnătura etapelor imaginii depinde de:
- conținutul acestei imagini;
- istoriile modificărilor Git care au condus la acest conținut.
Un depozit Git are întotdeauna comenzi inactiv care nu modifică conținutul fișierelor imagine. De exemplu, se comite numai cu comentarii sau comite de îmbinare sau comite care modifică acele fișiere din Git care nu vor fi importate în imagine.
Când utilizați etichetarea bazată pe conținut, problemele repornirilor inutile ale podurilor de aplicație în Kubernetes din cauza modificărilor numelui imaginii sunt rezolvate, chiar dacă conținutul imaginii nu s-a schimbat. Apropo, acesta este unul dintre motivele care împiedică stocarea multor microservicii ale unei aplicații într-un singur depozit Git.
De asemenea, etichetarea bazată pe conținut este o metodă de etichetare mai fiabilă decât etichetarea pe ramurile Git, deoarece conținutul imaginilor rezultate nu depinde de ordinea în care conductele sunt executate în sistemul CI pentru asamblarea mai multor comit-uri ale aceleiași ramuri.
Este important: incepand de acum etape-semnătură - E singura strategie de etichetare recomandată. Va fi folosit implicit în comandă werf ci-env (cu excepția cazului în care specificați în mod explicit o schemă de etichetare diferită).
. O publicație separată va fi, de asemenea, dedicată acestei funcții. LA CURENT (3 aprilie): articol cu detalii .
Niveluri de înregistrare
Utilizatorul are acum oportunitatea de a controla ieșirea, de a seta nivelul de înregistrare și de a lucra cu informațiile de depanare. Opțiuni adăugate --log-quiet, --log-verbose, --log-debug.
În mod implicit, rezultatul conține informațiile minime:
Când utilizați o ieșire verbosă (--log-verbose) puteți vedea cum funcționează werf:
Ieșire detaliată (--log-debug), pe lângă informațiile de depanare werf, conține și jurnalele bibliotecilor utilizate. De exemplu, puteți vedea cum are loc interacțiunea cu Registrul Docker și, de asemenea, puteți înregistra locurile în care se petrece o cantitate semnificativă de timp:
Alte planuri
Atenție! Opțiunile descrise mai jos sunt marcate v1.1 vor deveni disponibile în această versiune, multe dintre ele în viitorul apropiat. Actualizările vor veni prin actualizări automate . Aceste caracteristici nu afectează partea stabilă a funcțiilor v1.1; aspectul lor nu va necesita intervenția manuală a utilizatorului în configurațiile existente.
Suport complet pentru diverse implementări Docker Registry (NOU)
- Versiune: v1.1
- Date: martie
Scopul este ca utilizatorul să folosească o implementare personalizată fără restricții atunci când folosește werf.
În prezent, am identificat următorul set de soluții pentru care vom garanta suport complet:
- Implicit (biblioteca/registru)*,
- AWS ECR
- Azur*,
- Docker Hub
- GCR*,
- Pachete GitHub
- Registrul GitLab*,
- Port*,
- Chei.
Soluțiile care sunt în prezent complet acceptate de werf sunt marcate cu un asterisc. Pentru alții există sprijin, dar cu limitări.
Pot fi identificate două probleme principale:
- Unele soluții nu acceptă eliminarea etichetelor folosind API-ul Docker Registry, împiedicând utilizatorii să folosească curățarea automată a werf. Acest lucru este valabil pentru pachetele AWS ECR, Docker Hub și GitHub.
- Unele soluții nu acceptă așa-numitele depozite imbricate (Docker Hub, GitHub Packages și Quay), dar utilizatorul trebuie să le creeze manual folosind UI sau API (AWS ECR).
Vom rezolva aceste și alte probleme folosind API-urile native ale soluțiilor. Această sarcină include, de asemenea, acoperirea întregului ciclu de funcționare a werf cu teste pentru fiecare dintre ele.
Crearea imaginii distribuite (↑)
- Versiunea: v1.2 v1.1 (prioritatea pentru implementarea acestei caracteristici a fost crescută)
- Date: martie-aprilie martie
În prezent, werf v1.0 și v1.1 pot fi folosite doar pe o singură gazdă dedicată pentru operațiuni de construire și publicare a imaginilor și de implementare a aplicației pe Kubernetes.
Pentru a deschide posibilitățile de lucru distribuit de werf, atunci când construirea și implementarea aplicațiilor în Kubernetes sunt lansate pe mai multe gazde arbitrare și aceste gazde nu își salvează starea între build-uri (runneri temporari), werf este necesar să implementeze capacitatea de a utiliza Registrul Docker ca magazin de scenă.
Anterior, când proiectul werf încă se numea dapp, avea o astfel de oportunitate. Cu toate acestea, am întâlnit o serie de probleme care trebuie luate în considerare atunci când implementăm această funcționalitate în werf.
Nota. Această caracteristică nu necesită ca colectorul să lucreze în interiorul podurilor Kubernetes, deoarece Pentru a face acest lucru, trebuie să scăpați de dependența de serverul Docker local (în podul Kubernetes nu există acces la serverul Docker local, deoarece procesul în sine rulează într-un container, iar werf nu acceptă și nu va accepta lucrează cu serverul Docker prin rețea). Suportul pentru rularea Kubernetes va fi implementat separat.
Asistență oficială pentru GitHub Actions (NOU)
- Versiune: v1.1
- Date: martie
Include documentația werf (secțiuni referință и ghida), precum și acțiunea oficială GitHub pentru lucrul cu werf.
În plus, va permite werf să lucreze pe alergători efemeri.
Mecanica interacțiunii utilizatorului cu sistemul CI se va baza pe plasarea etichetelor pe cererile de extragere pentru a iniția anumite acțiuni pentru a construi/dezvolta aplicația.
Dezvoltarea locală și implementarea aplicațiilor cu werf (↓)
- Versiune: v1.1
- Date: ianuarie-februarie aprilie
Scopul principal este realizarea unei singure configurații unificate pentru implementarea aplicațiilor atât la nivel local, cât și în producție, fără acțiuni complexe, din cutie.
De asemenea, werf trebuie să aibă un mod de operare în care va fi convenabil să editați codul aplicației și să primiți instantaneu feedback de la aplicația care rulează pentru depanare.
Algoritm nou de curățare (NOU)
- Versiune: v1.1
- Date: aprilie
În versiunea actuală a werf v1.1 în procedură cleanup Nu există nicio prevedere pentru curățarea imaginilor pentru schema de etichetare bazată pe conținut - aceste imagini se vor acumula.
De asemenea, versiunea actuală de werf (v1.0 și v1.1) utilizează diferite politici de curățare pentru imaginile publicate în scheme de etichetare: ramură Git, etichetă Git sau commit Git.
A fost inventat un nou algoritm de curățare a imaginilor bazat pe istoricul comitărilor în Git, unificat pentru toate schemele de etichetare:
- Păstrați nu mai mult de imagini N1 asociate cu cele mai recente comisioane N2 pentru fiecare git HEAD (ramuri și etichete).
- Stocați nu mai mult de imagini de scenă N1 asociate cu cele mai recente comisioane N2 pentru fiecare git HEAD (ramuri și etichete).
- Stocați toate imaginile care sunt utilizate în orice resurse de cluster Kubernetes (toate contextele kube ale fișierului de configurare și spațiile de nume sunt scanate; puteți limita acest comportament cu opțiuni speciale).
- Stocați toate imaginile care sunt utilizate în manifestele de configurare a resurselor salvate în versiunile Helm.
- O imagine poate fi ștearsă dacă nu este asociată cu niciun HEAD din git (de exemplu, deoarece HEAD-ul corespunzător a fost șters) și nu este utilizată în niciun manifest din clusterul Kubernetes și în versiunile Helm.
Construire imagini paralele (↓)
- Versiune: v1.1
- Date: ianuarie-februarie aprilie*
Versiunea actuală a werf colectează imaginile și artefactele descrise în werf.yaml, secvenţial. Este necesar să se paralelizeze procesul de asamblare a etapelor independente de imagini și artefacte, precum și să se ofere rezultate convenabile și informative.
* Notă: termenul limită a fost mutat din cauza priorității sporite pentru implementarea asamblarii distribuite, care va adăuga mai multe capacități de scalare orizontală, precum și utilizarea werf cu GitHub Actions. Asamblarea în paralel este următorul pas de optimizare, oferind scalabilitate verticală la asamblarea unui proiect.
Tranziție la cârma 3 (↓)
- Versiune: v1.2
- Date: februarie-martie mai*
Include migrarea la noua bază de cod și o modalitate dovedită și convenabilă de a migra instalațiile existente.
* Notă: trecerea la Helm 3 nu va adăuga caracteristici semnificative la werf, deoarece toate caracteristicile cheie ale Helm 3 (3-way-merge și fără tiller) sunt deja implementate în werf. Mai mult, werf are pe lângă cele indicate. Cu toate acestea, această tranziție rămâne în planurile noastre și va fi implementată.
Jsonnet pentru descrierea configurației Kubernetes (↓)
- Versiune: v1.2
- Date: ianuarie-februarie aprilie-mai
Werf va accepta descrieri de configurare pentru Kubernetes în format Jsonnet. În același timp, werf va rămâne compatibil cu Helm și va exista o alegere a formatului de descriere.
Motivul este că șabloanele Go, conform multor oameni, au o barieră mare de intrare, iar înțelegerea codului acestor șabloane are de asemenea de suferit.
Se are în vedere și posibilitatea introducerii altor sisteme de descriere a configurației Kubernetes (de exemplu, Kustomize).
Lucrul în Kubernetes (↓)
- Versiune: v1.2
- Date: aprilie-mai mai-iunie
Obiectiv: Asigurați-vă că imaginile sunt create și că aplicația este livrată folosind runneri în Kubernetes. Acestea. Imaginile noi pot fi create, publicate, curățate și implementate direct din podurile Kubernetes.
Pentru a implementa această capacitate, mai întâi trebuie să fiți capabil să construiți imagini distribuite (vezi punctul de mai sus).
De asemenea, necesită suport pentru modul de operare al constructorului fără un server Docker (adică o construcție asemănătoare Kaniko sau construirea în spațiul utilizator).
Werf va sprijini construirea pe Kubernetes nu numai cu Dockerfile, ci și cu generatorul său Stapel cu reconstrucții incrementale și Ansible.
Un pas spre dezvoltarea deschisă
Ne iubim comunitatea (, ) și dorim din ce în ce mai mulți oameni care să contribuie la îmbunătățirea werf, să înțeleagă direcția în care ne mișcăm și să participe la dezvoltare.
Destul de recent s-a decis trecerea la pentru a dezvălui procesul de lucru al echipei noastre. Acum puteți vedea planurile imediate, precum și activitatea curentă în următoarele domenii:
- ;
- ;
- ;
- .
S-a lucrat mult cu probleme:
- Eliminate cele irelevante.
- Cele existente sunt aduse într-un singur format, cu un număr suficient de detalii și detalii.
- Au fost adăugate noi probleme cu idei și sugestii.
Cum să activați versiunea v1.1
Versiunea este disponibilă în prezent în (în canale stabil и tare ca piatra eliberările vor apărea pe măsură ce are loc stabilizarea ea în sine este deja suficient de stabil pentru utilizare, deoarece a trecut prin canale alfa и beta). Activat in felul urmator:
source $(multiwerf use 1.1 ea)
werf COMMAND ...Concluzie
Noua arhitectură de stocare în etapă și optimizările constructorului pentru constructorii Stapel și Dockerfile deschid posibilitatea implementării de build-uri distribuite și paralele în werf. Aceste funcții vor apărea în curând în aceeași versiune v1.1 și vor deveni automat disponibile prin mecanismul de actualizare automată (pentru utilizatori ).
În această versiune, a fost adăugată o strategie de etichetare bazată pe conținutul imaginii - etichetarea bazată pe conținut, care a devenit strategia implicită. Jurnalul principal de comenzi a fost, de asemenea, reproiectat: werf build, werf publish, werf deploy, werf dismiss, werf cleanup.
Următorul pas semnificativ este adăugarea de ansambluri distribuite. Compilările distribuite au devenit o prioritate mai mare decât versiunile paralele începând cu v1.0, deoarece adaugă mai multă valoare werf: scalare verticală a constructorilor și suport pentru constructori efemeri în diferite sisteme CI/CD, precum și capacitatea de a face suport oficial pentru acțiunile GitHub. . Prin urmare, termenele de implementare pentru ansamblurile paralele au fost deplasate. Cu toate acestea, lucrăm pentru a implementa ambele posibilități cât mai curând posibil.
Urmăriți știrile! Și nu uitați să ne vizitați la pentru a crea o problemă, a găsi una existentă și a adăuga un plus, a crea un PR sau pur și simplu a urmări dezvoltarea proiectului.
PS
Citește și pe blogul nostru:
- «»
- «»;
- O serie de note despre inovațiile în werf:
- «»;
- «»;
- «»;
- «".
Sursa: www.habr.com