je naš odprtokodni pripomoček GitOps CLI za izdelavo in dostavo aplikacij v Kubernetes. Kot obljubljeno, je zaznamoval začetek dodajanja novih funkcij werfu in revidiranja tradicionalnih pristopov. Zdaj z veseljem predstavljamo izdajo v1.1, ki je velik korak v razvoju in temelj za prihodnost zbiralec werf. Različica je trenutno na voljo v .
Osnova izdaje je nova arhitektura odrskega shranjevanja in optimizacija dela obeh zbiralnikov (za Stapel in Dockerfile). Nova arhitektura shranjevanja odpira možnost izvajanja porazdeljenih sklopov iz več gostiteljev in vzporednih sklopov na istem gostitelju.
Optimizacija dela vključuje odpravo nepotrebnih izračunov na stopnji izračuna stopenjskih podpisov in spremembo mehanizmov za izračun kontrolnih vsot datotek na učinkovitejše. Ta optimizacija zmanjša povprečni čas gradnje projekta z uporabo werf. In nedejavne gradnje, ko so vse stopnje v predpomnilniku stopnje-skladiščenje, so zdaj res hitri. V večini primerov bo ponovni zagon gradnje trajal manj kot 1 sekundo! To velja tudi za postopke preverjanja faz v procesu dela timov. werf deploy и werf run.
Tudi v tej izdaji se je pojavila strategija za označevanje slik po vsebini - označevanje na podlagi vsebine, ki je zdaj privzeto omogočen in edini priporočen.
Oglejmo si podrobneje ključne novosti v werf v1.1 in vam hkrati povemo o načrtih za prihodnost.
Kaj se je spremenilo v werf v1.1?
Nova oblika poimenovanja stopenj in algoritem za izbiro stopenj iz predpomnilnika
Novo pravilo za ustvarjanje umetniških imen. Zdaj vsaka stopnja gradnje ustvari edinstveno ime stopnje, ki je sestavljeno iz dveh delov: podpisa (kot je bilo v v2) in edinstvenega začasnega identifikatorja.
Na primer, celotno ime odrske slike je lahko videti takole:
werf-stages-storage/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835
... ali na splošno:
werf-stages-storage/PROJECT:SIGNATURE-TIMESTAMP_MILLISEC
Tukaj:
-
SIGNATUREje podpis stopnje, ki predstavlja identifikator vsebine stopnje in je odvisen od zgodovine urejanj v Gitu, ki so privedle do te vsebine; -
TIMESTAMP_MILLISECje zajamčen enolični identifikator slike, ki se ustvari v času, ko se zgradi nova slika.
Algoritem za izbiranje stopenj iz predpomnilnika temelji na preverjanju razmerja med povezavami Git:
- Werf izračuna podpis določene stopnje.
- В stopnje-skladiščenje Za določen podpis je lahko več stopenj. Werf izbere vse stopnje, ki ustrezajo podpisu.
- Če je trenutna stopnja povezana z Git (git-arhiv, stopnja po meri s popravki Git:
install,beforeSetup,setup; ali git-latest-patch), potem werf izbere samo tiste stopnje, ki so povezane z objavo, ki je prednik trenutne objave (za katero se kliče gradnja). - Od preostalih ustreznih stopenj je izbrana ena - najstarejša po datumu nastanka.
Stopnja za različne veje Git ima lahko enak podpis. Toda werf bo preprečil uporabo predpomnilnika, povezanega z različnimi vejami, med temi vejami, tudi če se podpisi ujemajo.
.
Nov algoritem za ustvarjanje in shranjevanje stopenj v shrambo stopenj
Če pri izbiri stopenj iz predpomnilnika werf ne najde ustrezne stopnje, se sproži postopek sestavljanja nove stopnje.
Upoštevajte, da lahko več procesov (na enem ali več gostiteljih) začne graditi isto stopnjo ob približno istem času. Werf uporablja optimističen algoritem blokiranja stopnje-skladiščenje v trenutku shranjevanja sveže zbrane slike v stopnje-skladiščenje. Na ta način, ko je nova stopnja pripravljena, werf blokira stopnje-skladiščenje in shrani sveže zbrano sliko tja le, če primerna slika tam ne obstaja več (po podpisu in drugih parametrih - glejte nov algoritem za izbiro stopenj iz predpomnilnika).
Sveže sestavljena slika ima zagotovljen edinstven identifikator TIMESTAMP_MILLISEC (glejte novo obliko poimenovanja stopnje). V primeru, da v stopnje-skladiščenje bo najdena ustrezna slika, bo werf zavrgel sveže prevedeno sliko in uporabil sliko iz predpomnilnika.
Z drugimi besedami: prvi proces, ki konča gradnjo slike (najhitrejši), bo dobil pravico do shranjevanja le-te v postopno shranjevanje (in potem bo ta ena sama slika uporabljena za vse gradnje). Počasen postopek gradnje ne bo nikoli preprečil hitrejšemu procesu pri shranjevanju rezultatov gradnje trenutne stopnje in prehodu na naslednjo gradnjo.
.
Izboljšana zmogljivost graditelja Dockerfile
Trenutno je niz stopenj za sliko, zgrajeno iz datoteke Dockerfile, sestavljen iz ene stopnje – dockerfile. Pri izračunu podpisa se izračuna kontrolna vsota datotek context, ki bo uporabljen med montažo. Pred to izboljšavo je werf rekurzivno pregledal vse datoteke in pridobil kontrolno vsoto s seštevanjem konteksta in načina vsake datoteke. Od različice 1.1 lahko werf uporablja izračunane kontrolne vsote, shranjene v repozitoriju Git.
Algoritem temelji na . Algoritem upošteva zapise v .dockerignore in rekurzivno prečka drevo datotek le, kadar je to potrebno. Tako smo se ločili od branja datotečnega sistema in odvisnosti algoritma od velikosti context ni pomembno.
Algoritem preveri tudi nesledene datoteke in jih po potrebi upošteva v kontrolni vsoti.
Izboljšana zmogljivost pri uvažanju datotek
Različice werf v1.1 uporabljajo strežnik rsync, ko . Prej je bil uvoz izveden v dveh korakih z uporabo vpetja imenika iz gostiteljskega sistema.
Učinkovitost uvoza v sistemu macOS ni več omejena z nosilci Dockerja, uvozi pa so končani v enakem času kot Linux in Windows.
Označevanje na podlagi vsebine
Werf v1.1 podpira tako imenovano označevanje po vsebini slike - označevanje na podlagi vsebine. Oznake nastalih slik Docker so odvisne od vsebine teh slik.
Pri izvajanju ukaza werf publish --tags-by-stages-signature ali werf ci-env --tagging-strategy=stages-signature objavili slike t.i odrski podpis slika. Vsaka slika je označena s svojim lastnim podpisom stopenj te slike, ki se izračuna po enakih pravilih kot običajni podpis vsake stopnje posebej, vendar je splošni identifikator slike.
Podpis stopenj slike je odvisen od:
- vsebino te slike;
- zgodovine sprememb Git, ki so privedle do te vsebine.
Repozitorij Git ima vedno navidezne objave, ki ne spremenijo vsebine slikovnih datotek. Na primer, objave samo s komentarji ali združitvene objave ali objave, ki spremenijo tiste datoteke v Gitu, ki ne bodo uvožene v sliko.
Pri uporabi označevanja na podlagi vsebine so težave z nepotrebnimi ponovnimi zagoni podov aplikacij v Kubernetesu zaradi sprememb v imenu slike odpravljene, tudi če se vsebina slike ni spremenila. Mimogrede, to je eden od razlogov, ki preprečuje shranjevanje številnih mikrostoritev ene aplikacije v enem samem repozitoriju Git.
Poleg tega je označevanje na podlagi vsebine zanesljivejša metoda označevanja kot označevanje na vejah Git, ker vsebina nastalih slik ni odvisna od vrstnega reda, v katerem se izvajajo cevovodi v sistemu CI za sestavljanje več potrditev iste veje.
Pomembno je,: od zdaj naprej stopnje-podpis - Je edina priporočena strategija označevanja. Privzeto bo uporabljen v ukazu werf ci-env (razen če izrecno določite drugačno shemo označevanja).
. Tej funkciji bo posvečena tudi posebna publikacija. POSODOBLJENO (3. april): Članek s podrobnostmi .
Stopnje beleženja
Uporabnik ima zdaj možnost nadzora izhoda, nastavitve ravni beleženja in dela z informacijami o odpravljanju napak. Možnosti dodane --log-quiet, --log-verbose, --log-debug.
Izhod privzeto vsebuje minimalne informacije:
Pri uporabi besednega izpisa (--log-verbose) lahko vidite, kako deluje werf:
Podroben izpis (--log-debug), poleg informacij o odpravljanju napak werf vsebuje tudi dnevnike uporabljenih knjižnic. Na primer, lahko vidite, kako poteka interakcija z registrom Docker Registry, in zabeležite tudi mesta, kjer se porabi precej časa:
Nadaljnji načrti
Opozorilo! Spodaj opisane možnosti so označene v1.1 bodo na voljo v tej različici, mnogi od njih v bližnji prihodnosti. Posodobitve bodo prišle prek samodejnih posodobitev . Te funkcije ne vplivajo na stabilni del funkcij v1.1; njihov videz ne bo zahteval ročnega posega uporabnika v obstoječe konfiguracije.
Popolna podpora za različne izvedbe Docker Registry (NOVO)
- Različica: v1.1
- Datumi: marec
Cilj je, da uporabnik pri uporabi werf uporablja izvedbo po meri brez omejitev.
Trenutno smo identificirali naslednji niz rešitev, za katere bomo zagotovili popolno podporo:
- Privzeto (knjižnica/register)*,
- AWS ECR
- azurno*,
- Docker Hub
- GCR*,
- Paketi GitHub
- Register GitLab*,
- Pristanišče*,
- Quay.
Rešitve, ki jih trenutno v celoti podpira werf, so označene z zvezdico. Za druge obstaja podpora, vendar z omejitvami.
Ugotoviti je mogoče dve glavni težavi:
- Nekatere rešitve ne podpirajo odstranjevanja oznak z API-jem Docker Registry, kar uporabnikom preprečuje uporabo samodejnega čiščenja werf. To velja za pakete AWS ECR, Docker Hub in GitHub.
- Nekatere rešitve ne podpirajo tako imenovanih ugnezdenih repozitorijev (Docker Hub, GitHub Packages in Quay) ali pa jih podpirajo, ampak jih mora uporabnik ustvariti ročno z uporabniškim vmesnikom ali API-jem (AWS ECR).
Te in druge težave bomo rešili z uporabo izvornih API-jev rešitev. Ta naloga vključuje tudi pokrivanje celotnega cikla delovanja werf s testi za vsakega od njih.
Gradnja porazdeljene slike (↑)
- Različica: v1.2 v1.1 (prioriteta za implementacijo te funkcije je bila povečana)
- Termini: marec-april marec
Trenutno je mogoče werf v1.0 in v1.1 uporabljati samo na enem namenskem gostitelju za operacije gradnje in objave slik ter uvajanje aplikacije v Kubernetes.
Da bi odprli možnosti porazdeljenega dela werfa, ko se gradnja in uvedba aplikacij v Kubernetesu zaženeta na več poljubnih gostiteljih in ti gostitelji ne shranijo svojega stanja med gradnjami (začasnimi izvajalci), je werf potreben za implementacijo možnosti uporabe Docker Registry kot odrska trgovina.
Prej, ko se je projekt werf še imenoval dapp, je imel takšno priložnost. Vendar smo naleteli na številne težave, ki jih je treba upoštevati pri implementaciji te funkcionalnosti v werf.
Obvestilo. Ta funkcija ne zahteva, da zbiralnik deluje znotraj podov Kubernetes, ker Če želite to narediti, se morate znebiti odvisnosti od lokalnega strežnika Docker (v Kubernetes pod ni dostopa do lokalnega strežnika Docker, ker se sam proces izvaja v vsebniku, werf pa ne podpira in ne bo podpiral delo s strežnikom Docker prek omrežja). Podpora za izvajanje Kubernetesa bo implementirana ločeno.
Uradna podpora za GitHub Actions (NOVO)
- Različica: v1.1
- Datumi: marec
Vključuje dokumentacijo werf (razdelki reference и vodi), kot tudi uradni GitHub Action za delo z werf.
Poleg tega bo werfu omogočil, da deluje na efemernih tekačih.
Mehanika interakcije uporabnika s sistemom CI bo temeljila na postavljanju oznak na zahteve po vleki za sprožitev določenih dejanj za izgradnjo/uvajanje aplikacije.
Lokalni razvoj in uvajanje aplikacij z werf (↓)
- Različica: v1.1
- Termini: januar-februar april
Glavni cilj je doseči enotno poenoteno konfiguracijo za uvajanje aplikacij tako lokalno kot v produkciji, brez zapletenih dejanj, takoj po namestitvi.
werf mora imeti tudi način delovanja, v katerem bo priročno urejati kodo aplikacije in takoj prejemati povratne informacije od delujoče aplikacije za odpravljanje napak.
Nov algoritem čiščenja (NOVO)
- Različica: v1.1
- Datumi: april
V trenutni različici werf v1.1 v postopku cleanup Za shemo označevanja na podlagi vsebine ni predvideno čiščenje slik – te slike se bodo kopičile.
Prav tako trenutna različica werf (v1.0 in v1.1) uporablja različne pravilnike o čiščenju za slike, objavljene v shemah označevanja: Git veja, Git tag ali Git commit.
Izumljen je bil nov algoritem za čiščenje slik, ki temelji na zgodovini objav v Gitu, poenoten za vse sheme označevanja:
- Za vsako git HEAD (veje in oznake) ne hranite več kot N1 slik, povezanih z N2 najnovejših potrditev.
- Za vsako git HEAD (veje in oznake) ne shranjujte več kot N1 stopenjskih slik, povezanih z najnovejšimi odobritvami N2.
- Shranite vse slike, ki se uporabljajo v katerem koli viru gruče Kubernetes (pregledani so vsi konteksti kube konfiguracijske datoteke in imenski prostori; to vedenje lahko omejite s posebnimi možnostmi).
- Shranite vse slike, ki se uporabljajo v manifestih konfiguracije virov, shranjenih v izdajah Helm.
- Sliko je mogoče izbrisati, če ni povezana z nobeno GLAVO iz gita (na primer, ker je bila sama ustrezna GLAVA izbrisana) in ni uporabljena v nobenem manifestu v gruči Kubernetes in v izdajah Helm.
Vzporedna izdelava slike (↓)
- Različica: v1.1
- Datumi: januar-februar april*
Trenutna različica werf zbira slike in artefakte, opisane v werf.yaml, zaporedno. Potrebno je vzporediti proces sestavljanja neodvisnih faz slik in artefaktov ter zagotoviti priročen in informativen izhod.
* Opomba: rok je bil premaknjen zaradi povečane prioritete za implementacijo porazdeljenega sestavljanja, ki bo dodalo več zmožnosti vodoravnega skaliranja, kot tudi uporabo werf z dejanji GitHub. Vzporedno sestavljanje je naslednji korak optimizacije, ki zagotavlja vertikalno razširljivost pri sestavljanju enega projekta.
Prehod na Helm 3 (↓)
- Različica: v1.2
- Datumi: februar-marec maj*
Vključuje selitev na novo kodno zbirko in preverjen, priročen način za selitev obstoječih naprav.
* Opomba: prehod na Helm 3 ne bo dodal bistvenih funkcij v werf, ker so vse ključne funkcije Helm 3 (3-smerno spajanje in brez krmiljenja) že implementirane v werf. Poleg tega ima werf poleg navedenih. Vendar ta prehod ostaja v naših načrtih in bo izveden.
Jsonnet za opis konfiguracije Kubernetes (↓)
- Različica: v1.2
- Datumi: januar-februar april-maj
Werf bo podpiral opise konfiguracije za Kubernetes v formatu Jsonnet. Hkrati bo werf ostal združljiv s Helmom in možnost izbire formata opisa.
Razlog je v tem, da imajo predloge Go po mnenju mnogih ljudi visoko vstopno oviro, trpi pa tudi razumljivost kode teh predlog.
Razmišlja se tudi o možnosti uvedbe drugih sistemov za opis konfiguracije Kubernetes (na primer Kustomize).
Delo znotraj Kubernetesa (↓)
- Različica: v1.2
- Termini: april-maj maj-junij
Cilj: zagotoviti, da so slike izdelane in da je aplikacija dostavljena z uporabo tekačev v Kubernetesu. Tisti. Nove slike je mogoče zgraditi, objaviti, očistiti in razmestiti neposredno iz podov Kubernetes.
Za implementacijo te zmožnosti morate najprej znati zgraditi porazdeljene slike (glej točko zgoraj).
Prav tako zahteva podporo za način delovanja graditelja brez strežnika Docker (tj. Kaniko podobna zgradba ali zgradba v uporabniškem prostoru).
Werf bo podpiral gradnjo na Kubernetes ne samo z Dockerfile, ampak tudi s svojim graditeljem Stapel s postopnimi vnovičnimi izgradnjami in Ansible.
Korak k odprtemu razvoju
Radi imamo našo skupnost (, ) in želimo si, da bi vedno več ljudi pomagalo izboljšati werf, razumeli smer, v katero se premikamo, in sodelovali pri razvoju.
Pred kratkim je bilo odločeno preiti na da bi razkrili delovni proces naše ekipe. Zdaj si lahko ogledate bližnje načrte, pa tudi trenutno delo na naslednjih področjih:
- ;
- ;
- ;
- .
Veliko dela je bilo opravljenega z vprašanji:
- Odstranjene nepomembne.
- Obstoječe so prenesene v enoten format z zadostnim številom podrobnosti in podrobnosti.
- Dodane so bile nove težave z idejami in predlogi.
Kako omogočiti različico v1.1
Različica je trenutno na voljo v (v kanalih stabilna и trdno kot skala izdaje pa se bodo pojavile, ko pride do stabilizacije ea sama že dovolj stabilna za uporabo, saj šel skozi kanale alfa и beta). Aktivirano na naslednji način:
source $(multiwerf use 1.1 ea)
werf COMMAND ...Zaključek
Nova arhitektura shranjevanja stopenj in optimizacije graditelja za graditelje Stapel in Dockerfile odpirajo možnost izvajanja porazdeljenih in vzporednih gradenj v werf. Te funkcije se bodo kmalu pojavile v isti izdaji v1.1 in bodo samodejno na voljo prek mehanizma samodejnega posodabljanja (za uporabnike ).
V tej izdaji je bila dodana strategija označevanja, ki temelji na slikovni vsebini – označevanje na podlagi vsebine, ki je postala privzeta strategija. Preoblikovan je bil tudi glavni dnevnik ukazov: werf build, werf publish, werf deploy, werf dismiss, werf cleanup.
Naslednji pomemben korak je dodajanje porazdeljenih sklopov. Porazdeljene gradnje so postale višja prioriteta kot vzporedne gradnje od različice 1.0, ker dodajajo večjo vrednost werf-u: navpično skaliranje graditeljev in podpora za kratkotrajne graditelje v različnih sistemih CI/CD, pa tudi možnost uradne podpore za GitHub Actions . Zato so bili roki za izvedbo vzporednih skupščin premaknjeni. Vendar si prizadevamo za čimprejšnjo implementacijo obeh možnosti.
Spremljajte novice! In ne pozabite nas obiskati na ustvariti težavo, poiskati obstoječo in dodati plus, ustvariti PR ali preprosto opazovati razvoj projekta.
PS
Preberite tudi na našem blogu:
- «»
- «»;
- Niz opomb o novostih v werf:
- «»;
- «»;
- «»;
- «".
Vir: www.habr.com