werf 1.1 izdanje: poboljšanja graditelja danas i planovi za budućnost

werf je naš open source GitOps CLI uslužni program za pravljenje i isporuku aplikacija u Kubernetes. Kao što je obećano, izdanje verzije v1.0 označio je početak dodavanja novih karakteristika werfu i revizije tradicionalnih pristupa. Sada sa zadovoljstvom predstavljamo izdanje v1.1, koje je veliki korak u razvoju i temelj za budućnost kolekcionar werf. Verzija je trenutno dostupna u kanal 1.1 ea.

Osnova izdanja je nova arhitektura scenskog skladištenja i optimizacija rada oba kolektora (za Stapel i Dockerfile). Nova arhitektura skladištenja otvara mogućnost implementacije distribuiranih sklopova sa više hostova i paralelnih sklopova na istom hostu.

Optimizacija rada uključuje oslobađanje od nepotrebnih proračuna u fazi izračunavanja potpisa faze i promjenu mehanizama za izračunavanje kontrolnih suma datoteka na efikasnije. Ova optimizacija smanjuje prosječno vrijeme izgradnje projekta koristeći werf. I neaktivne gradnje, kada sve faze postoje u kešu faze-skladištenje, sada su veoma brzi. U većini slučajeva, ponovno pokretanje gradnje će trajati manje od 1 sekunde! Ovo se odnosi i na procedure za provjeru faza u procesu rada timova. werf deploy и werf run.

Također u ovom izdanju pojavila se strategija za označavanje slika po sadržaju - označavanje zasnovano na sadržaju, koji je sada podrazumevano omogućen i jedini preporučen.

Pogledajmo pobliže ključne inovacije u werf v1.1, a ujedno vam reći o planovima za budućnost.

Šta se promijenilo u werf v1.1?

Novi format imenovanja faza i algoritam za odabir faza iz keša

Novo pravilo generisanja umetničkog imena. Sada svaka faza izgradnje generiše jedinstveno ime faze, koje se sastoji od 2 dela: potpisa (kao što je bio u v1.0) plus jedinstveni privremeni identifikator.

Na primjer, puni naziv slike pozornice može izgledati ovako:

werf-stages-storage/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835

...ili općenito:

werf-stages-storage/PROJECT:SIGNATURE-TIMESTAMP_MILLISEC

Ovde:

• SIGNATURE je potpis faze, koji predstavlja identifikator sadržaja pozornice i zavisi od istorije izmena u Gitu koje su dovele do ovog sadržaja;
• TIMESTAMP_MILLISEC je zajamčeni jedinstveni identifikator slike koji se generira u vrijeme kada se gradi nova slika.

Algoritam za odabir faza iz keša baziran je na provjeri odnosa Git urezivanja:

1. Werf izračunava potpis određene faze.
2. В faze-skladištenje Za dati potpis može biti nekoliko faza. Werf odabire sve faze koje odgovaraju potpisu.
3. Ako je trenutna faza povezana sa Gitom (git-arhiva, prilagođena faza sa Git zakrpama: install, beforeSetup, setup; ili git-latest-patch), tada werf odabire samo one faze koje su povezane sa urezivanjem koje je predak trenutnog urezivanja (za koje se poziva build).
4. Od preostalih odgovarajućih faza bira se jedna - najstarija po datumu stvaranja.

Faza za različite Git grane može imati isti potpis. Ali werf će spriječiti da se predmemorija povezana s različitim granama koristi između ovih grana, čak i ako se potpisi podudaraju.

→ Dokumentacija.

Novi algoritam za kreiranje i čuvanje faza u skladištu pozornice

Ako pri odabiru faza iz keša werf ne pronađe odgovarajuću fazu, tada se pokreće proces sastavljanja nove faze.

Imajte na umu da više procesa (na jednom ili više hostova) može početi graditi istu fazu približno u isto vrijeme. Werf koristi optimističan algoritam blokiranja faze-skladištenje u trenutku pohranjivanja svježe prikupljene slike faze-skladištenje. Na ovaj način, kada je nova faza izgradnje spremna, werf blokovi faze-skladištenje i tamo sprema svježe prikupljenu sliku samo ako odgovarajuća slika tamo više ne postoji (po potpisu i drugim parametrima - pogledajte novi algoritam za odabir faza iz keša).

Svježe sastavljena slika ima garanciju da ima jedinstveni identifikator TIMESTAMP_MILLISEC (pogledajte novi format imenovanja scene). U slučaju in faze-skladištenje odgovarajuća slika će biti pronađena, werf će odbaciti svježe kompajliranu sliku i koristiti sliku iz keša.

Drugim riječima: proces koji prvi završi izgradnju slike (najbrži) će dobiti pravo da je pohrani u fazama-skladištem (a onda će se ta jedna slika koristiti za sve gradnje). Spor proces izgradnje nikada neće blokirati brži proces od spremanja rezultata izgradnje u trenutnoj fazi i prelaska na sljedeću verziju.

→ Dokumentacija.

Poboljšane performanse Dockerfile buildera

U ovom trenutku, cijev faza za sliku izgrađenu iz Dockerfile-a sastoji se od jedne faze - dockerfile. Prilikom izračunavanja potpisa izračunava se kontrolni zbroj datoteka context, koji će se koristiti tokom montaže. Prije ovog poboljšanja, werf je rekurzivno prošao kroz sve datoteke i dobio kontrolnu sumu sumiranjem konteksta i načina rada svake datoteke. Počevši od v1.1, werf može koristiti izračunate kontrolne sume pohranjene u Git spremištu.

Algoritam se zasniva na git ls-tree. Algoritam uzima u obzir zapise u .dockerignore i prolazi kroz stablo datoteka rekurzivno samo kada je to potrebno. Tako smo se odvojili od čitanja sistema datoteka i zavisnosti algoritma od veličine context nije značajno.

Algoritam također provjerava datoteke koje se ne prate i, ako je potrebno, uzima ih u obzir u kontrolnoj sumi.

Poboljšane performanse prilikom uvoza datoteka

Verzije werf v1.1 koriste rsync server kada uvoz datoteka iz artefakata i slika. Ranije je uvoz rađen u dva koraka korištenjem montiranja direktorija sa glavnog sistema.

Performanse uvoza na macOS-u više nisu ograničene Docker volumenima, a uvozi se završavaju u istom vremenskom periodu kao Linux i Windows.

Označavanje zasnovano na sadržaju

Werf v1.1 podržava takozvano označavanje po sadržaju slike - označavanje zasnovano na sadržaju. Oznake rezultirajućih Docker slika zavise od sadržaja ovih slika.

Prilikom pokretanja naredbe werf publish --tags-by-stages-signature ili werf ci-env --tagging-strategy=stages-signature objavljene slike tzv scenski potpis slika. Svaka slika je označena sopstvenim potpisom faza ove slike, koji se izračunava prema istim pravilima kao i regularni potpis svake faze posebno, ali je opšti identifikator slike.

Potpis faza slike zavisi od:

1. sadržaj ove slike;
2. historije Git promjena koje su dovele do ovog sadržaja.

Git spremište uvijek ima lažna urezivanja koja ne mijenjaju sadržaj slikovnih datoteka. Na primjer, urezivanje samo sa komentarima ili spajanjem urezivanja, ili urezivanje koje mijenja one datoteke u Gitu koje neće biti uvezene u sliku.

Kada se koristi označavanje zasnovano na sadržaju, rješavaju se problemi nepotrebnog ponovnog pokretanja podova aplikacije u Kubernetesu zbog promjena u nazivu slike, čak i ako se sadržaj slike nije promijenio. Inače, ovo je jedan od razloga koji sprečava pohranjivanje mnogih mikroservisa jedne aplikacije u jedno Git spremište.

Takođe, označavanje zasnovano na sadržaju je pouzdaniji metod označavanja od označavanja na granama Git-a, jer sadržaj rezultujućih slika ne zavisi od redosleda kojim se cevovodi izvršavaju u CI sistemu za sklapanje višestrukih urezivanja iste grane.

važno: počevši od sada faze-potpis Je jedina preporučena strategija označavanja. Koristit će se po defaultu u naredbi werf ci-env (osim ako eksplicitno navedete drugačiju šemu označavanja).

→ Dokumentacija. Ovoj osobini će biti posvećena i posebna publikacija. UPDATED (3. april): Članak sa detaljima objavljeno.

Nivoi evidentiranja

Korisnik sada ima priliku kontrolirati izlaz, postaviti nivo evidentiranja i raditi sa informacijama za otklanjanje grešaka. Dodane su opcije --log-quiet, --log-verbose, --log-debug.

Po defaultu, izlaz sadrži minimalne informacije:

Kada koristite opširni izlaz (--log-verbose) možete vidjeti kako werf radi:

Detaljan izlaz (--log-debug), pored informacija o otklanjanju grešaka werf-a, sadrži i dnevnike korištenih biblioteka. Na primjer, možete vidjeti kako dolazi do interakcije s Docker registrom, kao i zabilježiti mjesta na kojima se provodi značajna količina vremena:

Daljnji planovi

Oprez Dolje opisane opcije su označene v1.1 će postati dostupni u ovoj verziji, mnoge od njih u bliskoj budućnosti. Ažuriranja će dolaziti putem automatskih ažuriranja kada koristite multiwerf. Ove karakteristike ne utiču na stabilan deo funkcija v1.1, njihov izgled neće zahtevati ručnu intervenciju korisnika u postojećim konfiguracijama.

Potpuna podrška za razne implementacije Docker Registry (NOVO)

• Verzija: v1.1
• Datumi: mart
• Problem

Cilj je da korisnik koristi prilagođenu implementaciju bez ograničenja kada koristi werf.

Trenutno smo identifikovali sledeći set rešenja za koje ćemo garantovati punu podršku:

• Zadano (biblioteka/registrator)*,
• AWS ECR
• azurno*,
• Docker Hub
• GCR*,
• GitHub paketi
• GitLab registar*,
• luka*,
• Quay.

Rešenja koja trenutno u potpunosti podržava werf označena su zvjezdicom. Za druge postoji podrška, ali sa ograničenjima.

Mogu se identifikovati dva glavna problema:

• Neka rješenja ne podržavaju uklanjanje oznaka korištenjem Docker Registry API-ja, sprječavajući korisnike da koriste werf-ovo automatsko čišćenje. Ovo važi za pakete AWS ECR, Docker Hub i GitHub.
• Neka rješenja ne podržavaju takozvana ugniježđena spremišta (Docker Hub, GitHub paketi i Quay) ili ih podržavaju, ali ih korisnik mora kreirati ručno koristeći UI ili API (AWS ECR).

Mi ćemo riješiti ove i druge probleme koristeći izvorne API-je rješenja. Ovaj zadatak također uključuje pokrivanje cijelog ciklusa werf operacija sa testovima za svaki od njih.

Izgradnja distribuirane slike (↑)

• Verzija: v1.2 v1.1 (prioritet za implementaciju ove funkcije je povećan)
• Termini: mart-april mart
• Problem

Trenutno se werf v1.0 i v1.1 mogu koristiti samo na jednom namenskom hostu za operacije izgradnje i objavljivanja slika i implementacije aplikacije u Kubernetes.

Da bi se otvorile mogućnosti distribuiranog rada werf-a, kada se izgradnja i implementacija aplikacija u Kubernetes-u pokrene na nekoliko proizvoljnih hostova i ti hostovi ne pohranjuju svoje stanje između build-ova (privremeni pokretači), werf je potreban za implementaciju mogućnosti korištenja Docker Registry kao skladište pozornice.

Ranije, kada se werf projekat još zvao dapp, imao je takvu priliku. Međutim, naišli smo na niz problema koje treba uzeti u obzir prilikom implementacije ove funkcionalnosti u werf.

primjedba. Ova funkcija ne zahtijeva od kolekcionara da radi unutar Kubernetes podova, jer Da biste to učinili, morate se riješiti ovisnosti o lokalnom Docker serveru (u Kubernetes pod-u nema pristupa lokalnom Docker serveru, jer se sam proces izvodi u kontejneru, a werf ne podržava i neće podržavati rad sa Docker serverom preko mreže). Podrška za pokretanje Kubernetesa će biti implementirana zasebno.

Zvanična podrška za GitHub Actions (NOVO)

• Verzija: v1.1
• Datumi: mart
• Problem

Uključuje werf dokumentaciju (odjeljke upućivanje и vodič), kao i zvanična GitHub akcija za rad sa werf-om.

Osim toga, omogućit će werfu da radi na efemernim trkačima.

Mehanika interakcije korisnika sa CI sistemom će se zasnivati ​​na postavljanju oznaka na zahtjeve za povlačenje za pokretanje određenih radnji za izgradnju/izvođenje aplikacije.

Lokalni razvoj i implementacija aplikacija sa werf-om (↓)

• Verzija: v1.1
• Termini: januar-februar april
• Problem

Glavni cilj je postizanje jedinstvene konfiguracije za implementaciju aplikacija kako lokalno tako i u proizvodnji, bez složenih radnji, iz kutije.

werf također mora imati način rada u kojem će biti zgodno urediti kod aplikacije i odmah primiti povratne informacije od pokrenute aplikacije za otklanjanje grešaka.

Novi algoritam čišćenja (NOVO)

• Verzija: v1.1
• Datumi: april
• Problem

U trenutnoj verziji werf v1.1 u proceduri cleanup Ne postoji odredba za čišćenje slika za šemu označavanja zasnovanu na sadržaju - ove slike će se akumulirati.

Također, trenutna verzija werfa (v1.0 i v1.1) koristi različite politike čišćenja za slike objavljene pod šemama označavanja: Git grana, Git oznaka ili Git urezivanje.

Izmišljen je novi algoritam za čišćenje slika zasnovan na istoriji urezivanja u Gitu, ujedinjen za sve šeme označavanja:

• Ne čuvajte više od N1 slika povezanih s N2 najnovijim urezivanjem za svaku git HEAD (grane i oznake).
• Čuvajte ne više od N1 scenskih slika povezanih sa N2 najnovijim urezima za svaku git HEAD (grane i oznake).
• Pohranite sve slike koje se koriste u bilo kojem resursu klastera Kubernetes (svi kube konteksti konfiguracijske datoteke i prostori imena se skeniraju; ovo ponašanje možete ograničiti posebnim opcijama).
• Pohranite sve slike koje se koriste u manifestima konfiguracije resursa spremljenim u Helm izdanjima.
• Slika se može izbrisati ako nije povezana ni sa jednom GLAVOM iz git-a (na primjer, jer je sama odgovarajuća GLAVA izbrisana) i ne koristi se ni u jednom manifestu u Kubernetes klasteru i u Helm izdanjima.

Izgradnja paralelne slike (↓)

• Verzija: v1.1
• Termini: januar-februar april*

Trenutna verzija werfa prikuplja slike i artefakte opisane u werf.yaml, sekvencijalno. Neophodno je paralelizirati proces sastavljanja nezavisnih faza slika i artefakata, kao i osigurati zgodan i informativan izlaz.

* Napomena: rok je pomjeren zbog povećanog prioriteta za implementaciju distribuiranog sklopa, što će dodati više mogućnosti horizontalnog skaliranja, kao i korištenje werf-a sa GitHub akcijama. Paralelno sastavljanje je sljedeći korak optimizacije, pružajući vertikalnu skalabilnost prilikom sklapanja jednog projekta.

Prijelaz na kormilo 3 (↓)

• Verzija: v1.2
• Datumi: februar-mart maj*

Uključuje migraciju na novu kodnu bazu Kormilo 3 i dokazan, praktičan način za migraciju postojećih instalacija.

* Napomena: prelazak na Helm 3 neće dodati značajne karakteristike werf-u, jer su sve ključne karakteristike Helm-a 3 (3-smjerno spajanje i bez tiller-a) već implementirane u werf-u. Štaviše, werf ima dodatne funkcije pored navedenih. Međutim, ova tranzicija ostaje u našim planovima i biće sprovedena.

Jsonnet za opisivanje Kubernetes konfiguracije (↓)

• Verzija: v1.2
• Termini: januar-februar april-maj

Werf će podržati opise konfiguracije za Kubernetes u Jsonnet formatu. U isto vrijeme, werf će ostati kompatibilan sa Helmom i postojat će izbor formata opisa.

Razlog je taj što Go šabloni, prema mnogim ljudima, imaju visoku ulaznu barijeru, a razumljivost koda ovih šablona takođe pati.

Razmatra se i mogućnost uvođenja drugih Kubernetes sistema opisa konfiguracije (na primjer, Kustomize).

Rad unutar Kubernetesa (↓)

• Verzija: v1.2
• Termini: april-maj-maj-jun

Cilj: Osigurajte da su slike napravljene i da se aplikacija isporučuje pomoću pokretača u Kubernetesu. One. Nove slike se mogu izgraditi, objaviti, očistiti i implementirati direktno iz Kubernetes podova.

Da biste implementirali ovu mogućnost, prvo morate biti u mogućnosti da napravite distribuirane slike (vidi tačku iznad).

Također zahtijeva podršku za radni način graditelja bez Docker servera (tj. Kaniko build ili build u korisničkom prostoru).

Werf će podržati izgradnju na Kubernetes-u ne samo pomoću Dockerfile-a, već i sa svojim Stapel builder-om s inkrementalnim obnavljanjem i Ansible-om.

Korak ka otvorenom razvoju

Volimo našu zajednicu (GitHub, telegram) i želimo da sve više ljudi pomogne da werf bude bolji, da razumije smjer u kojem se krećemo i učestvuje u razvoju.

Nedavno je odlučeno da se pređe na GitHub projektne ploče kako bismo otkrili radni proces našeg tima. Sada možete vidjeti trenutne planove, kao i tekuće radove u sljedećim oblastima:

• Dokumentacija i stranica;
• testiranje;
• Greške i loš UX;
• 1.1.

Dosta posla je obavljeno po pitanjima:

• Uklonjene nebitne.
• Postojeći su dovedeni u jedinstven format, sa dovoljnim brojem detalja i detalja.
• Dodani su novi brojevi sa idejama i prijedlozima.

Kako omogućiti verziju v1.1

Verzija je trenutno dostupna u kanal 1.1 ea (u kanalima stabilan и čvrst kao kamen Međutim, oslobađanja će se pojaviti kako dođe do stabilizacije ea sam je već dovoljno stabilan za upotrebu, jer prošao kroz kanale Alfa и beta). Aktivirano preko multiwerf na sljedeći način:

source $(multiwerf use 1.1 ea)
werf COMMAND ...

zaključak

Nova arhitektura za skladištenje pozornice i optimizacije graditelja za Stapel i Dockerfile graditelje otvaraju mogućnost implementacije distribuiranih i paralelnih nadgradnja u werf-u. Ove karakteristike će se uskoro pojaviti u istom izdanju v1.1 i postat će automatski dostupne putem mehanizma automatskog ažuriranja (za korisnike multiwerf).

U ovom izdanju dodata je strategija označavanja zasnovana na sadržaju slika - označavanje zasnovano na sadržaju, koja je postala standardna strategija. Glavni dnevnik komandi je također prerađen: werf build, werf publish, werf deploy, werf dismiss, werf cleanup.

Sljedeći značajan korak je dodavanje distribuiranih sklopova. Distribuirane gradnje postale su veći prioritet od paralelnih build-a od v1.0 jer dodaju više vrijednosti werf-u: vertikalno skaliranje graditelja i podrška za efemerne graditelje u različitim CI/CD sistemima, kao i mogućnost da se napravi zvanična podrška za GitHub Actions . Stoga su pomjereni rokovi implementacije za paralelne skupštine. Međutim, radimo na tome da obje mogućnosti implementiramo što je prije moguće.

Pratite vijesti! I ne zaboravite nas posjetiti na GitHubda kreirate problem, pronađite postojeći i dodajte plus, kreirajte PR ili jednostavno pogledajte razvoj projekta.

PS

Pročitajte i na našem blogu:

• «Predstavljamo werf 1.0 stabilan: kakve veze GitOps ima s tim, status i planovi»
• «werf - naš alat za CI/CD u Kubernetesu (pregled i video izvještaj)»;
• Niz napomena o inovacijama u werf-u:
  • «3-smjerno spajanje u werf: implementacija na Kubernetes sa Helmom "na steroidima"»;
  • «Korištenje werf-a za izvođenje složenih Helm grafikona»;
  • «Podrška za monorepo i multirepo u werf-u i kakve veze Docker Registry ima s tim»;
  • «Sada možete graditi Docker slike u werf-u koristeći običan Dockerfile".

izvor: www.habr.com