🥇Označavanje temeljeno na sadržaju u werf kolektoru: zašto i kako radi?

werf je naš GitOps CLI uslužni program otvorenog koda za izradu i isporuku aplikacija u Kubernetes. U izdanje v1.1 uvedena je nova značajka u sakupljaču slika: označavanje slika prema sadržaju ili označavanje temeljeno na sadržaju. Do sada je tipična shema označavanja u werf-u uključivala označavanje Docker slika Git oznakom, Git granom ili Git commitom. Ali sve te sheme imaju nedostatke koji su potpuno riješeni novom strategijom označavanja. Detalji o njemu i zašto je tako dobar nalaze se ispod.

Uvođenje skupa mikroservisa iz jednog Git repozitorija

Često se događa situacija kada je aplikacija podijeljena na mnogo više ili manje neovisnih usluga. Izdanja ovih usluga mogu se dogoditi neovisno: jedna ili više usluga mogu biti puštene odjednom, dok ostale moraju nastaviti raditi bez ikakvih promjena. Ali sa stajališta pohrane koda i upravljanja projektima, prikladnije je držati takve aplikacijske usluge u jednom repozitoriju.

Postoje situacije kada su usluge doista neovisne i nisu povezane s jednom aplikacijom. U tom će slučaju biti smješteni u zasebnim projektima, a njihovo objavljivanje provodit će se kroz zasebne CI/CD procese u svakom od projekata.

Međutim, u stvarnosti, programeri često dijele jednu aplikaciju na nekoliko mikroservisa, ali stvaranje zasebnog repozitorija i projekta za svaki... jasno je pretjerano. To je situacija o kojoj će se dalje raspravljati: nekoliko takvih mikroservisa nalazi se u jednom repozitoriju projekta, a izdanja se događaju kroz jedan proces u CI/CD-u.

Označavanje po Git grani i Git tagu

Recimo da se koristi najčešća strategija označavanja - oznaka ili grana. Za Git grane, slike su označene imenom grane, za jednu granu u isto vrijeme postoji samo jedna objavljena slika s imenom te grane. Za Git oznake, slike su označene prema nazivu oznake.

Kada se stvori nova Git oznaka—na primjer, kada se objavi nova verzija—nova Docker oznaka bit će stvorena za sve slike projekta u Docker registru:

myregistry.org/myproject/frontend:v1.1.10
myregistry.org/myproject/myservice1:v1.1.10
myregistry.org/myproject/myservice2:v1.1.10
myregistry.org/myproject/myservice3:v1.1.10
myregistry.org/myproject/myservice4:v1.1.10
myregistry.org/myproject/myservice5:v1.1.10
myregistry.org/myproject/database:v1.1.10

Ovi novi nazivi slika prosljeđuju se kroz Helm predloške u Kubernetes konfiguraciju. Prilikom pokretanja postavljanja naredbom werf deploy polje se ažurira image u manifestima resursa Kubernetes i ponovnom pokretanju odgovarajućih resursa zbog promijenjenog naziva slike.

problem: u slučaju kada se zapravo sadržaj slike nije promijenio od prethodnog uvođenja (Git oznaka), već samo njena Docker oznaka, to se događa višak ponovnog pokretanja ove aplikacije i, shodno tome, mogući su zastoji. Iako nije bilo pravog razloga za izvođenje ovog ponovnog pokretanja.

Kao rezultat toga, s trenutnom shemom označavanja potrebno je ograditi nekoliko zasebnih Git repozitorija i javlja se problem organiziranja uvođenja tih nekoliko repozitorija. Općenito, takva shema ispada preopterećena i složena. Bolje je kombinirati mnoge usluge u jedno spremište i stvoriti Docker oznake kako ne bi bilo nepotrebnih ponovnih pokretanja.

Označavanje Git commitom

werf također ima strategiju označavanja povezanu s Git predajama.

Git-commit je identifikator za sadržaj Git repozitorija i ovisi o povijesti uređivanja datoteka u Git repozitoriju, pa se čini logičnim koristiti ga za označavanje slika u Docker registru.

Međutim, označavanje Git predanjem ima iste nedostatke kao označavanje Git granama ili Git oznakama:

Mogla bi se stvoriti prazna obveza koja ne mijenja nijednu datoteku, ali će se promijeniti Docker oznaka slike.
Mogla bi se stvoriti objava spajanja koja ne mijenja datoteke, ali će se promijeniti Docker oznaka slike.
Mogla bi se izvršiti obveza koja mijenja te datoteke u Gitu koje nisu uvezene u sliku, a Docker oznaka slike ponovno će se promijeniti.

Označavanje naziva Git grane ne odražava verziju slike

Postoji još jedan problem povezan sa strategijom označavanja za Git grane.

Označavanje prema nazivu grane radi sve dok se komitacije na toj grani prikupljaju uzastopno kronološkim redom.

Ako u trenutnoj shemi korisnik počne ponovno graditi stari obvezu povezanu s određenom granom, tada će werf prepisati sliku koristeći odgovarajuću Docker oznaku s novosagrađenom verzijom slike za staru obvezu. Implementacije koje od sada koriste ovu oznaku nose rizik povlačenja druge verzije slike prilikom ponovnog pokretanja modula, zbog čega će naša aplikacija izgubiti vezu s CI sustavom i postati desinkronizirana.

Osim toga, uz uzastopna guranja u jednu granu s kratkim vremenskim razmakom između njih, staro predavanje može se kompajlirati kasnije od novijeg: stara verzija slike prebrisat će novu pomoću Git oznake grane. Takvi se problemi mogu riješiti CI/CD sustavom (na primjer, u GitLab CI cjevovod potonjeg se pokreće za niz obveza). Međutim, ne podržavaju svi sustavi ovo i mora postojati pouzdaniji način za sprječavanje tako temeljnog problema.

Što je označavanje temeljeno na sadržaju?

Dakle, što je označavanje temeljeno na sadržaju – označavanje slika prema sadržaju.

Za izradu Docker oznaka ne koriste se Git primitive (Git grana, Git oznaka...), već kontrolni zbroj povezan s:

sadržaj slike. ID oznaka slike odražava njezin sadržaj. Prilikom izrade nove verzije, ovaj se identifikator neće promijeniti ako se datoteke na slici nisu promijenile;
povijest stvaranja ove slike u Gitu. Slike povezane s različitim granama Gita i različitom poviješću izrade putem werfa imat će različite ID oznake.

Takva identifikacijska oznaka je tzv slika scenski potpis.

Svaka slika sastoji se od niza faza: from, before-install, git-archive, install, imports-after-install, before-setup, ... git-latest-patch itd. Svaki stupanj ima identifikator koji odražava njegov sadržaj − scenski potpis (scenski potpis).

Konačna slika, koja se sastoji od ovih faza, označena je takozvanim potpisom skupa ovih faza - stupnjevi potpis, - što je općenito za sve faze slike.

Za svaku sliku iz konfiguracije werf.yaml u općem slučaju, postojat će vlastiti potpis i, sukladno tome, Docker oznaka.

Stage potpis rješava sve ove probleme:

Otporan na prazna Git komitiranja.
Otporan na Git komitove koji mijenjaju datoteke koje nisu relevantne za sliku.
Ne dovodi do problema revidiranja trenutne verzije slike prilikom ponovnog pokretanja nadogradnji za stare Git obveze grane.

Ovo je sada preporučena strategija označavanja i zadana je u werf-u za sve CI sustave.

Kako omogućiti i koristiti u werf

Naredba sada ima odgovarajuću opciju werf publish: --tag-by-stages-signature=true|false

U CI sustavu, strategija označavanja određena je naredbom werf ci-env. Prethodno je za njega definiran parametar werf ci-env --tagging-strategy=tag-or-branch. Sada, ako odredite werf ci-env --tagging-strategy=stages-signature ili ne navedite ovu opciju, werf će prema zadanim postavkama koristiti strategiju označavanja stages-signature. Tim werf ci-env automatski će postaviti potrebne oznake za naredbu werf build-and-publish (Ili werf publish), tako da za ove naredbe ne treba specificirati dodatne opcije.

Na primjer, naredba:

werf publish --stages-storage :local --images-repo registry.hello.com/web/core/system --tag-by-stages-signature

...može stvoriti sljedeće slike:

registry.hello.com/web/core/system/backend:4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d
registry.hello.com/web/core/system/frontend:f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6

Ovdje 4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d potpis je faza slike backendI f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6 - potpis faza slike frontend.

Kada koristite posebne funkcije werf_container_image и werf_container_env Nema potrebe mijenjati ništa u predlošcima Helm: ove će funkcije automatski generirati ispravne nazive slika.

Primjer konfiguracije u CI sustavu:

type multiwerf && source <(multiwerf use 1.1 beta)
type werf && source <(werf ci-env gitlab)
werf build-and-publish|deploy

Više informacija o konfiguraciji dostupno je u dokumentaciji:

Ukupno

Nova opcija werf publish --tag-by-stages-signature=true|false.
Nova vrijednost opcije werf ci-env --tagging-strategy=stages-signature|tag-or-branch (ako nije navedeno, zadano će biti stages-signature).
Ako ste prethodno koristili opcije označavanja za Git predaje (WERF_TAG_GIT_COMMIT ili opciju werf publish --tag-git-commit COMMIT), onda svakako prijeđite na strategiju označavanja faze-potpis.
Bolje je odmah prebaciti nove projekte na novu shemu označavanja.
Prilikom prelaska na werf 1.1, preporučljivo je prebaciti stare projekte na novu shemu označavanja, ali staru oznaka ili grana još uvijek je podržan.

Označavanje temeljeno na sadržaju rješava sve probleme obrađene u članku:

Otpor imena Docker oznake na prazna Git obvezivanja.
Otpornost naziva Docker oznake na Git obveze koje mijenjaju datoteke koje nisu relevantne za sliku.
Ne dovodi do problema revidiranja trenutne verzije slike prilikom ponovnog pokretanja nadogradnji za stare Git predaje za Git grane.

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

PS

Pročitajte i na našem blogu:

Izvor: www.habr.com

Označavanje temeljeno na sadržaju u werf builderu: zašto i kako radi?