🥇Izdanje werf 1.1: poboljšanja u kolektoru danas i planovi za budućnost

werf — naš GitOps CLI uslužni program otvorenog koda za izradu i isporuku aplikacija Kubernetes-u. Kao što je obećano, Izdanje v1.0 označio je početak dodavanja novih značajki Werfu i revizije njegovih tradicionalnih pristupa. Sada s ponosom najavljujemo izdanje v1.1, koje predstavlja veliki korak naprijed i temelj za budućnost. kolektor werf. Verzija je trenutno dostupna u kanal 1.1 svaki.

Jezgra ovog izdanja je nova arhitektura pohrane na razini stagea i optimizacije za oba alata za izradu (za Stapel i Dockerfile). Nova arhitektura pohrane omogućuje distribuirane izrade na više hostova i paralelne izrade na jednom hostu.

Optimizacije uključuju uklanjanje nepotrebnih izračuna tijekom izračuna potpisa faza i promjenu mehanizama izračuna kontrolnog zbroja datoteka u učinkovitije. Ova optimizacija smanjuje prosječno vrijeme izrade projekta pomoću werfa. To se također odnosi na suhe izrade kada sve faze postoje u predmemoriji. skladišta faza, sada su zaista brzi. U većini slučajeva, ponovno pokretanje izgradnje trajat će manje od 1 sekunde! To se odnosi i na postupke provjere faze tijekom izvršavanja naredbe. werf deploy и werf run.

Ovo izdanje također uvodi strategiju za označavanje slika prema sadržaju - označavanje na temelju sadržaja, koji je sada omogućen prema zadanim postavkama i jedini je preporučeni.

Pogledajmo pobliže ključne inovacije u werfu v1.1 i razgovarajmo o našim planovima za budućnost.

Što se promijenilo u werfu v1.1?

Novi format imenovanja pozornice i algoritam za odabir pozornice iz predmemorije

Novo pravilo generiranja naziva pozornice. Sada svaka izrada pozornice generira jedinstveni naziv pozornice koji se sastoji od dva dijela: potpisa (kao u v1.0) i jedinstvenog vremenskog identifikatora.

Na primjer, puni naziv slike pozornice mogao bi izgledati ovako:

werf-stages-storage/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835

...ili općenito:

werf-stages-storage/PROJECT:SIGNATURE-TIMESTAMP_MILLISEC

ovdje:

SIGNATURE — je potpis faze koji predstavlja identifikator sadržaja faze i ovisi o povijesti Git uređivanja koja su dovela do tog sadržaja;
TIMESTAMP_MILLISEC — je zajamčeni jedinstveni identifikator slike koji se generira prilikom izrade nove slike.

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

Werf izračunava potpis određene faze.
В skladišta faza Za određeni potpis može postojati više faza. Werf odabire sve faze koje odgovaraju potpisu.
Ako je trenutna faza povezana s Gitom (git-archive, korisnička faza s Git zakrpama): install, beforeSetup, setup; ili git-latest-patch), tada werf odabire samo one faze koje su povezane s commitom koji je predak trenutnog commita (za koji je pozvana izrada).
Od preostalih prikladnih faza odabire se jedna - najstarija prema datumu nastanka.

Stadij za različite Git grane može imati isti potpis. Međutim, werf će spriječiti dijeljenje predmemorije povezane s različitim granama između tih grana, čak i ako se potpisi podudaraju.

→ Dokumentacija.

Novi algoritam za stvaranje i spremanje faza u pohranu faza

Ako werf ne pronađe odgovarajuću fazu tijekom odabira faza iz predmemorije, tada se pokreće proces izgradnje nove faze.

Imajte na umu da više procesa (na jednom ili više hostova) mogu započeti izgradnju iste faze približno u isto vrijeme. Werf koristi optimistični algoritam zaključavanja. skladišta faza u trenutku spremanja svježe prikupljene slike u skladišta fazaDakle, kada je montaža nove pozornice spremna, werf brave skladišta faza i sprema novo prikupljenu sliku tamo samo ako tamo više nema prikladne slike (prema potpisu i drugim parametrima - pogledajte novi algoritam za odabir faza iz predmemorije).

Svježe izgrađena slika zajamčeno ima jedinstveni identifikator TIMESTAMP_MILLISEC (vidi novi format imenovanja pozornice)U slučaju ako u skladišta faza Ako se pronađe odgovarajuća slika, werf će odbaciti novoizgrađenu sliku i koristiti predmemoriranu sliku.

Drugim riječima, prvi proces koji dovrši izgradnju slike (najbrži) moći će je spremiti u pohranu faza (a zatim će se ta jedna slika koristiti za sve izgradnje). Sporiji proces izgradnje nikada neće blokirati brži proces u spremanju rezultata trenutne faze izgradnje i prelasku na sljedeću.

→ Dokumentacija.

Poboljšane performanse Dockerfile buildera

Trenutno, cjevovod faza za sliku izgrađenu iz Dockerfile-a sastoji se od jedne faze: dockerfilePrilikom izračuna potpisa izračunava se kontrolna suma datoteka. context, koji će se koristiti tijekom izgradnje. Prije ovog poboljšanja, werf je rekurzivno iterirao kroz sve datoteke i dobivao kontrolni zbroj zbrajanjem konteksta i načina rada svake datoteke. Počevši od verzije 1.1, werf može koristiti izračunate kontrolne zbrojeve pohranjene u Git repozitoriju.

Algoritam se temelji na git ls-treeAlgoritam uzima u obzir unose u .dockerignore i rekurzivno prolazi kroz stablo datoteka samo kada je to potrebno. Na taj način smo se odvojili od čitanja datotečnog sustava i ovisnosti algoritma o veličini context nije značajno.

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

Poboljšane performanse prilikom uvoza datoteka

U verzijama werf v1.1, rsync poslužitelj se koristi kada uvoz datoteka iz artefakata i slikaPrije se uvoz obavljao u dva koraka pomoću montiranja direktorija s glavnog sustava.

Produktivnost uvoza u macOS više nije ograničen Docker količinama, a uvozi se dovršavaju u isto vrijeme kao i u Linux и Windows.

Označavanje na temelju sadržaja

Werf v1.1 podržava tzv. označavanje sadržaja slika - označavanje na temelju sadržajaOznake rezultirajućih 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 Objavljene slike tzv. bit će označene scenski potpis Svaka slika je označena vlastitim potpisom faze, koji se izračunava prema istim pravilima kao i redovni potpis svake pojedine faze, ali služi kao opći identifikator za sliku.

Potpis pozornice slike ovisi o:

sadržaj ove slike;
povijest Gita s izmjenama koje su dovele do ovog sadržaja.

Git repozitorij uvijek sadrži stub commitove koji ne mijenjaju sadržaj slikovnih datoteka. Na primjer, commitove samo s komentarima, commitove za spajanje ili commitove koji mijenjaju Git datoteke koje se neće uvesti u sliku.

Korištenje označavanja temeljenog na sadržaju rješava problem nepotrebnih ponovnih pokretanja Kubernetes podova aplikacija zbog promjena naziva slike, čak i ako sadržaj slike ostane nepromijenjen. Usput, to je jedan od razloga zašto je pohranjivanje više mikroservisa za jednu aplikaciju u jednom Git repozitoriju teško.

Označavanje temeljeno na sadržaju također je pouzdanija metoda označavanja od označavanja Git grana jer sadržaj rezultirajućih slika ne ovisi o redoslijedu kojim se cjevovodi izvršavaju u CI sustavu za izgradnju više commitova iz iste grane.

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

→ DokumentacijaOva značajka bit će također tema zasebne publikacije. AŽURIRANO (3. travnja): Članak s detaljima Objavljeno.

Razine zapisivanja

Korisnik sada ima mogućnost kontrole izlaza, postavljanja razine zapisivanja i rada s informacijama o otklanjanju pogrešaka. Dodane su opcije. --log-quiet, --log-verbose, --log-debug.

Prema zadanim postavkama, izlaz sadrži minimalno informacija:

Prilikom korištenja detaljnog izlaza (--log-verbose) možete vidjeti kako werf funkcionira:

Detaljan zaključak (--log-debug), uz informacije o otklanjanju pogrešaka u werfu, sadrži i zapisnike korištenih biblioteka. Na primjer, možete vidjeti kako se odvijaju interakcije s Docker registrom i točno odrediti mjesta na kojima se troši značajno vrijeme:

Daljnji planovi

Upozorenje! Sljedeće značajke opisane su s napomenom v1.1 bit će dostupni u ovoj verziji, a mnogi od njih bit će dostupni uskoro. Ažuriranja će stizati putem automatskih ažuriranja. pri korištenju multiwerfaOve značajke ne utječu na stabilni dio funkcionalnosti v1.1 i njihova implementacija neće zahtijevati ručnu intervenciju korisnika u postojećim konfiguracijama.

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

Verzija: v1.1
Rok: ožujak
Izdanje

Cilj je da korisnik može koristiti prilagođenu implementaciju bez ograničenja prilikom korištenja werfa.

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

Zadano (knjižnica/registar)*,
AWS ECR,
Azurno*,
Docker Hub,
GCR*,
GitHub paketi,
GitLab registar*,
Luka*,
Obala.

Rješenja označena zvjezdicom trenutno su u potpunosti podržana od strane werfa. Ostala rješenja su podržana, ali s ograničenjima.

Mogu se identificirati dva glavna problema:

Neka rješenja ne podržavaju brisanje oznaka pomoću Docker Registry API-ja, što korisnicima onemogućuje korištenje automatskog čišćenja implementiranog u werfu. To se odnosi na AWS ECR, Docker Hub i GitHub pakete.
Neka rješenja ne podržavaju tzv. ugniježđene repozitorije (Docker Hub, GitHub Packages i Quay) ili ih uopće ne podržavaju, već ih korisnik mora ručno kreirati pomoću korisničkog sučelja ili API-ja (AWS ECR).

Planiramo riješiti ove i druge probleme koristeći izvorne API-je rješenja. Ovaj zadatak također uključuje pokrivanje cijelog Werf tijeka rada za svaki od njih testovima.

Sklapanje distribuiranih slika (↑)

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

Trenutno se werf v1.0 i v1.1 mogu koristiti samo na jednom namjenskom hostu za izradu slika i objavljivanje te implementaciju aplikacija na Kubernetes.

Kako bi se omogućio distribuirani rad werfa, kada se izgradnja i implementacija aplikacija u Kubernetesu izvodi na više proizvoljnih hostova i ti hostovi ne spremaju svoje stanje između izrada (privremeni pokretači), werf mora implementirati mogućnost korištenja Docker Registra kao pohrane stanja.

Prije, kada se projekt werf još zvao dapp, imao je ovu mogućnost. Međutim, naišli smo na niz problema koje je trebalo riješiti prilikom implementacije ove značajke u werf.

PrimijetitiOva značajka ne dopušta kolektoru pokretanje unutar Kubernetes podova, jer to zahtijeva uklanjanje ovisnosti o lokalnom Docker poslužitelju (Kubernetes pod nema pristup lokalnom Docker poslužitelju jer se sam proces izvodi u kontejneru, a werf ne podržava i neće podržavati mrežni pristup Docker poslužitelju). Podrška za pokretanje u Kubernetes bit će implementirana zasebno.

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

Verzija: v1.1
Rok: ožujak
Izdanje

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

Osim toga, to će omogućiti werfu da radi na kratkotrajnim 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 akcije za izgradnju/implementaciju aplikacije.

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

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

Glavni cilj je postići jednu, ujedinjenu konfiguraciju za implementaciju aplikacija i lokalno i u produkciji, bez složenih koraka, „odmah od kutije“.

werf također zahtijeva način rada koji omogućuje praktično uređivanje koda aplikacije i trenutne povratne informacije od pokrenute aplikacije za otklanjanje pogrešaka.

Novi algoritam čišćenja (NOVO)

Verzija: v1.1
Datumi: travanj
Izdanje

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

Također, trenutna verzija werfa (v1.0 i v1.1) koristi različite politike čišćenja za slike objavljene pomoću shema označavanja: Git grana, Git tag ili Git commit.

Razvijen je novi algoritam za čišćenje slika temeljen na povijesti Git commita, ujednačen za sve sheme označavanja:

Ne pohranite više od N1 slika povezanih s N2 najnovijih commitova za svaki git HEAD (grane i oznake).
Ne pohranite više od N1 slika faze povezanih s N2 najnovijih commitova za svaki git HEAD (grane i oznake).
Pohrani sve slike koje se koriste u bilo kojim resursima Kubernetes klastera (skeniraju se svi konteksti i imenski prostori konfiguracijskih datoteka Kube-a; ovo ponašanje može se ograničiti posebnim opcijama).
Pohrani sve slike korištene u manifestima konfiguracije resursa pohranjenima u Helm izdanjima.
Slika se može izbrisati ako nije povezana ni s jednim git HEAD-om (na primjer, zato što je sam odgovarajući HEAD izbrisan) i ne koristi se ni u jednom manifestu u Kubernetes klasteru ili u Helm izdanjima.

Paralelno građenje slike (↓)

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

Trenutna verzija werfa gradi 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 implementacije distribuiranih verzija, što će dodati veću horizontalnu skalabilnost i podršku za korištenje werfa s GitHub Actions. Paralelne verzije su sljedeći korak optimizacije, pružajući vertikalnu skalabilnost prilikom izgradnje jednog projekta.

Prijelaz na Helm 3 (↓)

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

Uključuje migraciju na novu bazu koda kormilo 3 i provjeren, praktičan način migracije postojećih instalacija.

*Napomena: Nadogradnja na Helm 3 neće dodati značajne mogućnosti werfu, jer su sve ključne značajke Helma 3 (trostrano spajanje i odsutnost kormila) već implementirane u werfu. Štoviše, werf ima dodatne značajke uz one naznačene. Međutim, ovaj prijelaz ostaje u našim planovima i bit će proveden.

Jsonnet za opis Kubernetes konfiguracije (↓)

Verzija: v1.2
Datumi: siječanj-veljača, travanj-svibanj

Werf će podržavati opise konfiguracije Kubernetesa u Jsonnet formatu. Werf će ostati kompatibilan s Helmom i nudit će izbor formata opisa.

Razlog je taj što mnogi smatraju da Go predlošci imaju visoku krivulju učenja, a razumljivost koda iza tih predložaka također pati.

Također se razmatra mogućnost implementacije drugih Kubernetes sustava za opis konfiguracije (na primjer, Kustomize).

Rad unutar Kubernetesa (↓)

Verzija: v1.2
Datumi: travanj-svibanj svibanj-lipanj

Cilj: omogućiti izgradnju slika i isporuku aplikacija pomoću Kubernetes runnera. To znači da se nove slike mogu graditi, objavljivati, čistiti i implementirati izravno iz Kubernetes podova.

Za implementaciju ove mogućnosti, prvo je potrebna mogućnost distribuiranog sastavljanja slika. (vidi gornju točku).

Također je potrebna podrška za način izgradnje bez Docker poslužitelja (tj. izgradnja slična Kaniku ili izgradnja u korisničkom prostoru).

Werf će podržavati izgradnju u Kubernetesu ne samo pomoću Dockerfilesa, već i pomoću njegovog Stapel graditelja s inkrementalnim ponovnim izgradnjama i Ansiblea.

Korak prema otvorenom razvoju

Volimo našu zajednicu (GitHub, Telegram) i želimo da sve više ljudi pomogne u poboljšanju Werfa, razumije smjer u kojem se krećemo i sudjeluje u razvoju.

Nedavno je odlučeno o prelasku na Ploče projekata na GitHubu Kako biste dobili uvid u tijek rada našeg tima, sada možete vidjeti naše neposredne planove i trenutni rad u sljedećim područjima:

Puno je posla obavljeno s problemima:

Nebitni su uklonjeni.
Postojeći su dovedeni u jedinstveni format, s dovoljnim brojem detalja i pojedinosti.
Dodani su novi problemi s idejama i prijedlozima.

Kako omogućiti verziju v1.1

Verzija je trenutno dostupna u kanal 1.1 svaki (u kanalima stabilan и Tvrdo kao kamen izdanja će se pojavljivati kako se stvari stabiliziraju, međutim ea Već je dovoljno stabilan za korištenje, jer je prošao kroz kanale. alfa и beta). Aktivirano putem multiwerfa na sljedeći način:

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

Zaključak

Nova arhitektura pohrane faza i optimizirani rad alata za izradu Stapel i Dockerfile otvaraju mogućnost implementacije distribuiranih i paralelnih izrada u werfu. Ove značajke uskoro će se pojaviti u istom izdanju v1.1 i bit će automatski dostupne putem mehanizma automatskog ažuriranja (za korisnike). multiwerf).

Ovo izdanje dodaje strategiju označavanja slika na temelju sadržaja - označavanje na temelju sadržaja, što je postala zadana strategija. Glavni dnevnik naredbi također je prerađen: werf build, werf publish, werf deploy, werf dismiss, werf cleanup.

Sljedeći značajan korak bit će dodavanje distribuiranih verzija. Od verzije 1.0, distribuirane verzije postale su veći prioritet od paralelnih verzija jer dodaju veću vrijednost werfu: vertikalno skaliranje alata za izradu i podrška za efemerne alate za izradu u raznim CI/CD sustavima, kao i mogućnost službene podrške za GitHub akcije. Stoga je vremenski okvir implementacije paralelnih verzija odgođen. Međutim, radimo na bržoj implementaciji obje značajke.

Pratite nas za još novosti! I ne zaboravite nas posjetiti na GitHubstvoriti problem, pronaći postojeći i glasati za njega, stvoriti PR ili jednostavno promatrati razvoj projekta.