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

werf je naš open source GitOps CLI uslužni program za pravljenje i isporuku aplikacija u Kubernetes. IN izdanje v1.1 u kolektoru slika uvedena je nova funkcija: označavanje slika po sadržaju ili označavanje zasnovano na sadržaju. Do sada je tipična šema označavanja u werf-u uključivala označavanje Docker slika pomoću Git oznake, Git grane ili Git urezivanja. Ali sve ove sheme imaju nedostatke koji su potpuno riješeni novom strategijom označavanja. Detalji o tome i zašto je tako dobar nalaze se ispod.

Uvođenje skupa mikroservisa iz jednog Git spremišta

Često se javlja situacija kada je aplikacija podijeljena na više ili manje nezavisnih servisa. Izdanja ovih servisa mogu se odvijati nezavisno: jedan ili više servisa mogu biti pušteni u isto vrijeme, dok ostali moraju nastaviti raditi bez ikakvih promjena. Ali sa stanovišta skladištenja koda i upravljanja projektima, pogodnije je držati takve servise aplikacija u jednom spremištu.

Postoje situacije kada su usluge zaista neovisne i nisu povezane s jednom aplikacijom. U ovom slučaju, oni će se nalaziti u zasebnim projektima i njihovo objavljivanje će se odvijati kroz zasebne CI/CD procese u svakom od projekata.

Međutim, u stvarnosti, programeri često dijele jednu aplikaciju na nekoliko mikroservisa, ali kreiranje zasebnog spremišta i projekta za svaku... je očito pretjerano. O ovoj situaciji će se dalje raspravljati: nekoliko takvih mikroservisa nalazi se u jednom spremištu projekta i izdanja se dešavaju kroz jedan proces u CI/CD-u.

Označavanje Git granom i Git oznakom

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

Kada se kreira nova Git oznaka – na primjer, kada se objavi nova verzija – kreirat će se nova Docker oznaka 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

Ova nova imena slika se prosleđuju kroz Helm šablone u Kubernetes konfiguraciju. Prilikom pokretanja implementacije 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 tag), već samo Docker tag, to se događa višak ponovno pokretanje ove aplikacije i, shodno tome, moguća su neka zastoja. Iako nije bilo pravog razloga da se izvrši ovo ponovno pokretanje.

Kao rezultat toga, sa trenutnom šemom označavanja potrebno je ograditi nekoliko zasebnih Git spremišta i nastaje problem organiziranja uvođenja ovih nekoliko spremišta. Općenito, takva shema se ispostavlja preopterećenom i složenom. Bolje je kombinovati mnoge servise u jedno spremište i kreirati Docker oznake kako ne bi bilo nepotrebnih ponovnih pokretanja.

Označavanje pomoću Git urezivanja

werf takođe ima strategiju označavanja povezanu sa Git urezivanjem.

Git-commit je identifikator za sadržaj Git spremišta i ovisi o historiji uređivanja datoteka u Git spremištu, tako da se čini logičnim koristiti ga za označavanje slika u Docker registru.

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

• Moglo bi se kreirati prazan urezivanje koji ne mijenja nijednu datoteku, ali će se promijeniti Docker oznaka slike.
• Moglo bi se kreirati urezivanje spajanjem koje ne mijenja datoteke, ali će se promijeniti Docker oznaka slike.
• Moglo bi se napraviti urezivanje koje mijenja one datoteke u Gitu koje nisu uvezene u sliku, a Docker oznaka slike će se ponovo promijeniti.

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

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

Označavanje po imenu grane funkcionira sve dok se urezivanja na toj grani prikupljaju uzastopno hronološkim redom.

Ako u trenutnoj šemi korisnik započne obnavljanje starog urezivanja povezanog sa određenom granom, tada će werf ponovo napisati sliku koristeći odgovarajuću Docker oznaku s novoizgrađenom verzijom slike za staro urezivanje. Implementacije koje koriste ovu oznaku od sada nose rizik od povlačenja drugačije verzije slike prilikom ponovnog pokretanja podova, zbog čega će naša aplikacija izgubiti vezu sa CI sistemom i postati desinhronizovana.

Osim toga, uz uzastopna guranja u jednu granu sa kratkim vremenskim periodom između njih, staro urezivanje može biti prevedeno kasnije od novije: stara verzija slike će prepisati novu koristeći Git oznaku grane. Takvi problemi se mogu riješiti pomoću CI/CD sistema (na primjer, u GitLab CI cevovod potonjeg se pokreće za seriju urezivanja). Međutim, ne podržavaju svi sistemi ovo i mora postojati pouzdaniji način da se spriječi takav fundamentalni problem.

Šta je označavanje zasnovano na sadržaju?

Dakle, šta je označavanje zasnovano na sadržaju - označavanje slika po sadržaju.

Za kreiranje Docker oznaka ne koriste se Git primitivi (Git grana, Git oznaka...), već kontrolni zbroj povezan sa:

• sadržaj slike. ID oznaka slike odražava njen sadržaj. Prilikom izrade nove verzije, ovaj identifikator se neće promijeniti ako se datoteke na slici nisu promijenile;
• istorija stvaranja ove slike u Gitu. Slike povezane s različitim granama Git-a i različitom historijom izgradnje putem werf-a imat će različite ID oznake.

Takva identifikatorska oznaka je tzv potpis pozornice slike.

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

Konačna slika, koja se sastoji od ovih faza, označena je takozvanim potpisom skupa ovih faza - faze potpis, - koji je generalizirajući za sve faze slike.

Za svaku sliku iz konfiguracije werf.yaml u opštem slučaju, postojaće sopstveni potpis i, shodno tome, Docker oznaka.

Scenski potpis rješava sve ove probleme:

• Otporan na prazna Git urezivanja.
• Otporan na Git urezivanje koje mijenja datoteke koje nisu relevantne za sliku.
• Ne dovodi do problema prepravljanja trenutne verzije slike prilikom ponovnog pokretanja build-a za stare Git urezivanje grane.

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

Kako omogućiti i koristiti u werf

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

U CI sistemu, strategija označavanja je određena naredbom werf ci-env. Ranije je za njega definiran parametar werf ci-env --tagging-strategy=tag-or-branch. Sada, ako navedete werf ci-env --tagging-strategy=stages-signature ili ne navedite ovu opciju, werf će po defaultu koristiti strategiju označavanja stages-signature. Tim werf ci-env će automatski postaviti potrebne zastavice za naredbu werf build-and-publish (ili werf publish), tako da za ove naredbe nije potrebno 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 kreirati sljedeće slike:

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

to je 4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d je potpis faza slike backendi f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6 - potpis faza slike frontend.

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

Primjer konfiguracije u CI sistemu:

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:

• Imenik → Publikacija (objaviti);
• Rad sa CI/CD → Opće informacije → faze-potpis;
• Integracija sa GitLab CI/CD → .gitlab-ci.yml.

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, zadana vrijednost će biti stages-signature).
• Ako ste prethodno koristili opcije označavanja za Git urezivanje (WERF_TAG_GIT_COMMIT ili opciju werf publish --tag-git-commit COMMIT), a zatim se obavezno prebacite na strategiju označavanja faze-potpis.
• Bolje je odmah prebaciti nove projekte na novu šemu označavanja.
• Prilikom prelaska na werf 1.1, preporučljivo je prebaciti stare projekte na novu šemu označavanja, ali staru oznaka ili grana je još uvijek podržan.

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

• Otpor imena Docker oznake na prazna Git urezivanja.
• Otpornost imena Docker oznake na Git urezuje te mijenja datoteke koje su nerelevantne za sliku.
• Ne dovodi do problema prepravljanja trenutne verzije slike prilikom ponovnog pokretanja build-a za stare Git urezivanje za Git grane.

Iskoristi ga! I ne zaboravite nas posjetiti na GitHubda biste kreirali problem ili pronašli postojeći, dodajte plus, kreirajte PR ili jednostavno pogledajte razvoj projekta.

PS

Pročitajte i na našem blogu:

• «werf 1.1 izdanje: poboljšanja graditelja danas i planovi za budućnost»
• «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