Izdanje werf 1.1: poboljšanja alata za izgradnju danas i planovi za budućnost

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

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

Optimizacija rada uključuje oslobađanje od nepotrebnih izračuna u fazi izračunavanja potpisa faze i promjenu mehanizama za izračunavanje kontrolnih zbrojeva datoteka na učinkovitije. Ova optimizacija smanjuje prosječno vrijeme izgradnje projekta pomoću werf-a. I idle builds, kada sve faze postoje u cacheu pozornice-skladištenje, sada su jako brzi. U većini slučajeva ponovno pokretanje izgradnje trajat će manje od 1 sekunde! To se također odnosi i na postupke provjere faza u procesu rada timova. werf deploy и werf run.

Također u ovom izdanju pojavila se strategija za označavanje slika prema sadržaju - označavanje temeljeno na sadržaju, koji je sada omogućen prema zadanim postavkama i jedini preporučeni.

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

Što se promijenilo u werf v1.1?

Novi format imenovanja faza i algoritam za odabir faza iz predmemorije

Novo pravilo za generiranje umjetničkog imena. Sada svaka izgradnja stupnja generira jedinstveni naziv stupnja, koji se sastoji od 2 dijela: potpis (kao što je bio u v1.0) plus jedinstveni privremeni identifikator.

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

werf-stages-storage/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835

...ili općenito:

werf-stages-storage/PROJECT:SIGNATURE-TIMESTAMP_MILLISEC

ovdje:

• SIGNATURE je signatura faze, koja predstavlja identifikator sadržaja faze i ovisi o povijesti uređivanja u Gitu koja su dovela do ovog sadržaja;
• TIMESTAMP_MILLISEC je zajamčeni jedinstveni identifikator slike koji se generira u trenutku izgradnje nove slike.

Algoritam za odabir faza iz predmemorije temelji se na provjeri odnosa Git obveza:

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

Faza za različite Git grane može imati isti potpis. Ali werf će spriječiti korištenje predmemorije povezane s različitim granama između ovih grana, čak i ako se potpisi podudaraju.

→ Dokumentacija.

Novi algoritam za kreiranje i spremanje pozornica u pohranu pozornica

Ako prilikom odabira stupnjeva iz predmemorije werf ne pronađe odgovarajući stupanj, tada se pokreće proces sastavljanja novog stupnja.

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

Zajamčeno je da će svježe sastavljena slika imati jedinstveni identifikator TIMESTAMP_MILLISEC (pogledajte novi format naziva faze). U slučaju da u pozornice-skladištenje odgovarajuća slika će se pronaći, werf će odbaciti svježe kompiliranu sliku i koristiti sliku iz predmemorije.

Drugim riječima: prvi proces koji završi izgradnju slike (onaj najbrži) dobit će pravo pohraniti je u fazama-pohranu (i tada će se ta jedna slika koristiti za sve izgradnje). Spor proces izgradnje nikada neće spriječiti brži proces da spremi rezultate izgradnje trenutne faze i prijeđe na sljedeću izgradnju.

→ Dokumentacija.

Poboljšana izvedba graditelja Dockerfilea

Trenutačno se niz faza za sliku izgrađenu iz Dockerfilea sastoji od jedne faze - dockerfile. Prilikom izračunavanja potpisa izračunava se kontrolni zbroj datoteka context, koji će se koristiti tijekom montaže. Prije ovog poboljšanja, werf je rekurzivno prošao kroz sve datoteke i dobio kontrolni zbroj zbrajanjem konteksta i načina svake datoteke. Počevši od v1.1, werf može koristiti izračunate kontrolne zbrojeve pohranjene u Git repozitoriju.

Algoritam se temelji na git ls-stablo. Algoritam uzima u obzir zapise u .dockerignore i rekurzivno prelazi stablo datoteke samo kada je to potrebno. Dakle, odvojili smo se od čitanja datotečnog sustava i ovisnosti algoritma o veličini context nije značajan.

Algoritam također provjerava nepraćene datoteke i, ako je potrebno, uzima ih u obzir u kontrolnom zbroju.

Poboljšana izvedba prilikom uvoza datoteka

Verzije werf v1.1 koriste rsync poslužitelj kada uvoz datoteka iz artefakata i slika. Prethodno se uvoz vršio u dva koraka pomoću montiranja direktorija iz glavnog sustava.

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

Označavanje temeljeno na sadržaju

Werf v1.1 podržava takozvano označavanje sadržajem slike - označavanje temeljeno na sadržaju. Oznake dobivenih Docker slika ovise o sadržaju tih slika.

Prilikom izvođenja naredbe werf publish --tags-by-stages-signature ili werf ci-env --tagging-strategy=stages-signature objavio slike tzv scenski potpis slika. Svaka slika je označena vlastitim potpisom faza ove slike, koji se izračunava prema istim pravilima kao i redoviti potpis svake faze zasebno, ali je opći identifikator slike.

Potpis faza slike ovisi o:

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

Git spremište uvijek ima lažne obveze koje ne mijenjaju sadržaj slikovnih datoteka. Na primjer, predaje samo s komentarima ili predaje spajanja, ili obveze koje mijenjaju one datoteke u Gitu koje neće biti uvezene u sliku.

Kada koristite označavanje temeljeno na sadržaju, rješavaju se problemi nepotrebnog ponovnog pokretanja podova aplikacija u Kubernetesu zbog promjena u nazivu slike, čak i ako se sadržaj slike nije promijenio. Usput, ovo je jedan od razloga koji sprječava pohranjivanje mnogih mikroservisa jedne aplikacije u jedno Git repozitorij.

Također, označavanje temeljeno na sadržaju pouzdanija je metoda označavanja od označavanja na Git granama, jer sadržaj rezultirajućih slika ne ovisi o redoslijedu kojim se cjevovodi izvode u CI sustavu za sastavljanje višestrukih obveza iste grane.

To je važno: počevši od sada faze-potpis - Je jedina preporučena strategija označavanja. Koristit će se prema zadanim postavkama u naredbi werf ci-env (osim ako izričito ne navedete drugu shemu označavanja).

→ Dokumentacija. Zasebna publikacija također će biti posvećena ovoj značajki. AŽURIRANA (3. travnja): Članak s detaljima Objavljeno.

Razine zapisivanja

Korisnik sada ima priliku kontrolirati izlaz, postaviti razinu zapisivanja i raditi s informacijama o otklanjanju pogrešaka. Dodane opcije --log-quiet, --log-verbose, --log-debug.

Prema zadanim postavkama, izlaz sadrži minimalne informacije:

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

Detaljan izlaz (--log-debug), uz informacije o werf debuggingu, također sadrži zapisnike korištenih biblioteka. Na primjer, možete vidjeti kako se odvija interakcija s Docker registrom i također zabilježiti mjesta na kojima se provodi značajna količina vremena:

Daljnji planovi

Upozorenje! Opcije opisane u nastavku su označene v1.1 postat će dostupni u ovoj verziji, mnogi od njih u bliskoj budućnosti. Ažuriranja će dolaziti putem automatskih ažuriranja kada koristite multiwerf. Ove značajke ne utječu na stabilni dio funkcija v1.1; njihov izgled neće zahtijevati ručnu intervenciju korisnika u postojećim konfiguracijama.

Puna podrška za razne implementacije Docker registra (NOVO)

• Verzija: v1.1
• Termini: ožujak
• Izdanje

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

Trenutno smo identificirali sljedeći skup rješenja za koje ćemo jamčiti punu podršku:

• Zadano (biblioteka/registar)*,
• AWS ECR
• Azurno*,
• Docker Hub
• GCR*,
• GitHub paketi
• GitLab registar*,
• Luka*,
• Quay.

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

Mogu se identificirati dva glavna problema:

• Neka rješenja ne podržavaju uklanjanje oznaka pomoću Docker Registry API-ja, sprječavajući korisnike da koriste werf-ovo automatsko čišćenje. Ovo vrijedi za pakete AWS ECR, Docker Hub i GitHub.
• Neka rješenja ne podržavaju takozvane ugniježđene repozitorije (Docker Hub, GitHub Packages i Quay) ili ih podržavaju, ali ih korisnik mora izraditi ručno koristeći UI ili API (AWS ECR).

Riješit ćemo ove i druge probleme koristeći izvorne API-je rješenja. Ovaj zadatak također uključuje pokrivanje cijelog ciklusa rada werf-a s testovima za svaki od njih.

Izrada distribuirane slike (↑)

• Verzija: v1.2 v1.1 (prioritet za implementaciju ove značajke je povećan)
• Termini: ožujak-travanj ožujak
• Izdanje

Trenutačno se werf v1.0 i v1.1 mogu koristiti samo na jednom namjenskom hostu za operacije izgradnje i objavljivanja slika i implementacije aplikacije na Kubernetes.

Kako bi se otvorile mogućnosti distribuiranog rada werfa, kada se izgradnja i implementacija aplikacija u Kubernetesu pokreću na nekoliko proizvoljnih hostova i ti hostovi ne spremaju svoje stanje između izvođenja (privremeni pokretači), werf je potreban za implementaciju mogućnosti korištenja Docker Registry kao pozornica trgovine.

Ranije, dok se projekt werf još zvao dapp, imao je takvu priliku. Međutim, naišli smo na brojne probleme koje treba uzeti u obzir prilikom implementacije ove funkcionalnosti u werf.

Primijetiti. Ova značajka ne zahtijeva da sakupljač radi unutar Kubernetes mahuna, jer Da biste to učinili, morate se riješiti ovisnosti o lokalnom Docker poslužitelju (u Kubernetes podu nema pristupa lokalnom Docker poslužitelju, jer se sam proces izvodi u spremniku, a werf ne podržava i neće podržavati rad s Docker poslužiteljem preko mreže). Podrška za pokretanje Kubernetesa bit će implementirana zasebno.

Službena podrška za GitHub Actions (NOVO)

• Verzija: v1.1
• Termini: ožujak
• Izdanje

Uključuje werf dokumentaciju (odjeljci upućivanje и voditi), kao i službenu GitHub akciju za rad s werf-om.

Osim toga, omogućit će werf-u da radi na efemernim trkačima.

Mehanika interakcije korisnika s CI sustavom temeljit će se na postavljanju oznaka na zahtjeve za povlačenjem kako bi se pokrenule određene radnje za izgradnju/uvođenje aplikacije.

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

• Verzija: v1.1
• Termini: siječanj-veljača travanj
• Izdanje

Glavni cilj je postići jedinstvenu unificiranu konfiguraciju za implementaciju aplikacija i lokalno i u produkciji, bez složenih radnji, izvan kutije.

werf također mora imati način rada u kojem će biti zgodno uređivati ​​kod aplikacije i trenutno primati povratne informacije od pokrenute aplikacije za otklanjanje pogrešaka.

Novi algoritam čišćenja (NOVO)

• Verzija: v1.1
• Termini: travanj
• Izdanje

U trenutnoj verziji werf v1.1 u postupku cleanup Ne postoji odredba za čišćenje slika za shemu označavanja temeljenu na sadržaju - te će se slike nakupljati.

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

Izmišljen je novi algoritam za čišćenje slika temeljen na povijesti predaja u Gitu, objedinjen za sve sheme označavanja:

• Ne čuvajte više od N1 slika povezanih s N2 najnovijih obveza za svaku git HEAD (grane i oznake).
• Pohranjujte ne više od N1 slika faze povezanih s N2 najnovijih obveza za svaki git HEAD (grane i oznake).
• Pohranite sve slike koje se koriste u bilo kojem resursu klastera Kubernetes (skeniraju se svi kube konteksti konfiguracijske datoteke i prostori imena; ovo ponašanje možete ograničiti posebnim opcijama).
• Pohranite sve slike koje se koriste u manifestima konfiguracije resursa spremljene u izdanjima Helma.
• Slika se može izbrisati ako nije povezana ni s jednim HEAD-om iz gita (na primjer, zato što je sam odgovarajući HEAD izbrisan) i ne koristi se ni u jednom manifestu u Kubernetes klasteru iu izdanjima Helma.

Paralelna izgradnja slike (↓)

• Verzija: v1.1
• Datumi: siječanj-veljača travanj*

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

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

Prijelaz na Helm 3 (↓)

• Verzija: v1.2
• Datumi: veljača-ožujak svibanj*

Uključuje migraciju na novu bazu kodova kormilo 3 i dokazan, prikladan način za migraciju postojećih instalacija.

* Napomena: prelazak na Helm 3 neće dodati značajne značajke werfu jer su sve ključne značajke Helma 3 (3-smjerno spajanje i bez upravljača) već implementirane u werf. Štoviše, werf ima dodatne mogućnosti pored navedenih. Međutim, ovaj prijelaz ostaje u našim planovima i bit će proveden.

Jsonnet za opisivanje konfiguracije Kubernetesa (↓)

• Verzija: v1.2
• Termini: siječanj-veljača travanj-svibanj

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

Razlog je taj što Go predlošci, prema mišljenju mnogih ljudi, imaju visoku ulaznu barijeru, a razumljivost koda ovih predložaka također trpi.

Razmatra se i mogućnost uvođenja drugih sustava za opis konfiguracije Kubernetes (primjerice, Kustomize).

Rad unutar Kubernetesa (↓)

• Verzija: v1.2
• Termini: travanj-svibanj svibanj-lipanj

Cilj: Osigurati da su slike izgrađene i da se aplikacija isporučuje pomoću pokretača u Kubernetesu. Oni. Nove slike mogu se graditi, objavljivati, čistiti i implementirati izravno iz Kubernetes podova.

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

Također zahtijeva podršku za način rada buildera bez Docker poslužitelja (tj. Kaniko-like build ili build in userspace).

Werf će podržati izgradnju na Kubernetesu ne samo s Dockerfileom, već i sa svojim Stapel builderom s inkrementalnim ponovnim izgradnjama i Ansibleom.

Korak prema otvorenom razvoju

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

Nedavno je odlučeno prijeći na GitHub projektne ploče kako bismo otkrili proces rada našeg tima. Sada možete vidjeti neposredne planove, kao i trenutni rad u sljedećim područjima:

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

Mnogo se radilo na problemima:

• Uklonili nebitne.
• Postojeći se dovode u jedinstven format, s dovoljnim brojem detalja i detalja.
• Dodani su novi problemi s idejama i prijedlozima.

Kako omogućiti verziju v1.1

Verzija je trenutno dostupna u kanal 1.1 ea (u kanalima stabilan и Tvrdo kao kamen međutim, izdanja će se pojaviti kako dođe do stabilizacije ea sama je već dovoljno stabilna za korištenje, jer prošao kroz kanale alfa и beta). Aktiviran putem multiwerfa na sljedeći način:

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

Zaključak

Nova arhitektura pohrane na pozornici i optimizacije graditelja za Stapel i Dockerfile graditelje otvaraju mogućnost implementacije distribuiranih i paralelnih nadogradnji u werf. Ove će se značajke uskoro pojaviti u istom izdanju v1.1 i postat će automatski dostupne kroz mehanizam automatskog ažuriranja (za korisnike multiwerf).

U ovom izdanju dodana je strategija označavanja temeljena na sadržaju slike - označavanje temeljeno na sadržaju, što je postalo zadana strategija. Dnevnik glavnih naredbi također je prerađen: werf build, werf publish, werf deploy, werf dismiss, werf cleanup.

Sljedeći značajan korak je dodavanje distribuiranih sklopova. Distribuirane nadogradnje postale su veći prioritet od paralelnih izgradnja od verzije 1.0 jer dodaju više vrijednosti werf-u: vertikalno skaliranje graditelja i podrška za efemerne graditelje u raznim CI/CD sustavima, kao i mogućnost izrade službene podrške za GitHub radnje . Stoga su pomaknuti rokovi provedbe za paralelne skupštine. Međutim, radimo na implementaciji obje mogućnosti što je prije moguće.

Pratite novosti! I ne zaboravite nas posjetiti na GitHubstvoriti problem, pronaći postojeći i dodati plus, napraviti PR ili jednostavno promatrati razvoj projekta.

PS

Pročitajte i na našem blogu:

• «Predstavljamo werf 1.0 stable: što GitOps ima s tim, status i planovi»
• «werf - naš alat za CI/CD u Kubernetesu (pregled i video izvješće)»;
• Niz bilješki o inovacijama u werf-u:
  • «Trosmjerno spajanje na werf: implementacija na Kubernetes s Helmom "na steroidima"»;
  • «Korištenje werf-a za izvođenje složenih Helmovih grafikona»;
  • «Podrška za monorepo i multirepo u werf-u i kakve veze s tim ima Docker Registry»;
  • «Sada možete graditi Docker slike u werf-u koristeći običnu Docker datoteku".

Izvor: www.habr.com