je naša utilita GitOps CLI s otvoreným zdrojovým kódom na vytváranie a doručovanie aplikácií do Kubernetes. IN v zberači obrázkov bola zavedená nová funkcia: označovanie obrázkov podľa obsahu resp označovanie založené na obsahu. Doteraz typická schéma označovania vo werf zahŕňala označovanie obrázkov Docker tagom Git, vetvou Git alebo potvrdením Git. Všetky tieto schémy však majú nevýhody, ktoré úplne rieši nová stratégia značkovania. Podrobnosti o ňom a prečo je taký dobrý sú pod strihom.
Spustenie sady mikroslužieb z jedného úložiska Git
Často nastáva situácia, keď je aplikácia rozdelená do mnohých viac či menej nezávislých služieb. Uvoľnenia týchto služieb môžu nastať nezávisle: jedna alebo viac služieb môže byť uvoľnených naraz, zatiaľ čo ostatné musia naďalej fungovať bez akýchkoľvek zmien. Ale z hľadiska ukladania kódu a projektového manažmentu je pohodlnejšie uchovávať takéto aplikačné služby v jednom úložisku.
Existujú situácie, keď sú služby skutočne nezávislé a nie sú spojené s jedinou aplikáciou. V tomto prípade budú umiestnené v samostatných projektoch a ich uvoľnenie sa uskutoční prostredníctvom samostatných procesov CI/CD v každom projekte.
V skutočnosti však vývojári často rozdeľujú jedinú aplikáciu na niekoľko mikroslužieb, no vytvorenie samostatného úložiska a projektu pre každú... je jasná prehnanosť. Práve o tejto situácii sa bude diskutovať ďalej: niekoľko takýchto mikroslužieb sa nachádza v jedinom projektovom úložisku a vydania sa vyskytujú prostredníctvom jediného procesu v CI/CD.
Označovanie podľa vetvy Git a značky Git
Povedzme, že sa používa najbežnejšia stratégia označovania – tag-or-branch. Pre vetvy Git sú obrázky označené názvom pobočky, pre jednu vetvu je vždy zverejnený iba jeden obrázok podľa názvu tejto pobočky. V prípade značiek Git sú obrázky označené podľa názvu značky.
Po vytvorení novej značky Git – napríklad pri vydaní novej verzie – sa vytvorí nová značka Docker pre všetky obrázky projektov v registri Docker:
-
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
Tieto nové názvy obrázkov sa prenesú cez šablóny Helm do konfigurácie Kubernetes. Pri spustení nasadenia príkazom werf deploy pole sa aktualizuje image v manifestoch prostriedkov Kubernetes a reštartovanie zodpovedajúcich prostriedkov kvôli zmenenému názvu obrázka.
problém: v prípade, že sa v skutočnosti od predchádzajúceho zavedenia nezmenil obsah obrázka (značka Git), ale iba jeho značka Docker, stane sa to extra reštartovanie tejto aplikácie, a preto je možný určitý výpadok. Hoci na vykonanie tohto reštartu nebol skutočný dôvod.
Výsledkom je, že pri súčasnej schéme označovania je potrebné ohradiť niekoľko samostatných úložísk Git a vzniká problém s organizáciou zavádzania týchto niekoľkých úložísk. Vo všeobecnosti sa takáto schéma ukazuje ako preťažená a zložitá. Je lepšie kombinovať veľa služieb do jedného úložiska a vytvárať značky Docker, aby nedochádzalo k zbytočným reštartom.
Označovanie pomocou príkazu Git
werf má tiež stratégiu označovania spojenú s príkazmi Git.
Git-commit je identifikátor obsahu úložiska Git a závisí od histórie úprav súborov v úložisku Git, takže sa zdá logické použiť ho na označovanie obrázkov v registri Docker.
Tagovanie pomocou Git commit má však rovnaké nevýhody ako tagovanie vetvami Git alebo tagmi Git:
- Mohlo by sa vytvoriť prázdne odovzdanie, ktoré nezmení žiadne súbory, ale zmení sa značka Docker obrázka.
- Dalo by sa vytvoriť odovzdanie zlúčenia, ktoré nezmení súbory, ale zmení sa značka Docker obrázka.
- Mohlo by sa vytvoriť potvrdenie, ktoré zmení tie súbory v Git, ktoré nie sú importované do obrázka, a značka Docker obrázka sa znova zmení.
Označenie názvu pobočky Git neodráža verziu obrázka
So stratégiou značkovania pre pobočky Git súvisí ďalší problém.
Označovanie podľa názvu vetvy funguje, pokiaľ sa odovzdania na tejto vetve zhromažďujú postupne v chronologickom poradí.
Ak v aktuálnej schéme používateľ začne prestavovať staré odovzdanie spojené s určitou vetvou, potom werf prepíše obrázok pomocou zodpovedajúcej značky Docker s novovytvorenou verziou obrázka pre staré odovzdanie. Nasadenia, ktoré odteraz používajú túto značku, riskujú, že pri reštartovaní modulov stiahnu inú verziu obrázka, v dôsledku čoho naša aplikácia stratí spojenie so systémom CI a bude desynchronizovaná.
Okrem toho, pri postupných presunoch do jednej vetvy s krátkym časovým odstupom medzi nimi môže byť staré odovzdanie skompilované neskôr ako novšie: stará verzia obrazu prepíše novú pomocou značky vetvy Git. Takéto problémy možno vyriešiť systémom CI/CD (napríklad v GitLab CI sa spustí kanál CI pre sériu potvrdení). Nie všetky systémy to však podporujú a musí existovať spoľahlivejší spôsob, ako takýmto zásadným problémom predísť.
Čo je označovanie založené na obsahu?
Čo je teda označovanie založené na obsahu - označovanie obrázkov podľa obsahu.
Na vytvorenie značiek Docker sa nepoužívajú primitívy Git (vetva Git, značka Git...), ale kontrolný súčet spojený s:
- obsah obrázka. Identifikačná značka obrázka odráža jej obsah. Pri vytváraní novej verzie sa tento identifikátor nezmení, ak sa súbory na obrázku nezmenili;
- históriu vytvárania tohto obrázka v Git. Obrázky spojené s rôznymi vetvami Git a inou históriou zostavovania cez werf budú mať rôzne ID tagy.
Takýmto identifikačným štítkom je tzv podpis obrazovej scény.
Každý obrázok pozostáva z niekoľkých fáz: from, before-install, git-archive, install, imports-after-install, before-setup, ... git-latest-patch atď. Každá fáza má identifikátor, ktorý odráža jej obsah − javiskový podpis (javiskový podpis).
Konečný obrázok pozostávajúci z týchto fáz je označený takzvaným podpisom súboru týchto fáz - etapy podpisu, - čo je zovšeobecňovanie pre všetky fázy obrazu.
Pre každý obrázok z konfigurácie werf.yaml vo všeobecnom prípade bude mať svoj vlastný podpis a podľa toho aj značku Docker.
Podpis štádia rieši všetky tieto problémy:
- Odolné voči vyprázdneniu Git commitov.
- Resistant to Git zaväzuje, že mení súbory, ktoré nie sú relevantné pre obrázok.
- Nevedie k problému s prepracovaním aktuálnej verzie obrazu pri reštartovaní zostavení pre staré potvrdenia vetvy Git.
Toto je teraz odporúčaná stratégia označovania a je predvolená vo werf pre všetky systémy CI.
Ako povoliť a používať vo werf
Príkaz má teraz zodpovedajúcu možnosť werf publish: --tag-by-stages-signature=true|false
V systéme CI je stratégia označovania špecifikovaná príkazom werf ci-env. Predtým bol preň definovaný parameter werf ci-env --tagging-strategy=tag-or-branch. Teraz, ak špecifikujete werf ci-env --tagging-strategy=stages-signature alebo túto možnosť nešpecifikujte, werf štandardne použije stratégiu označovania stages-signature. Tím werf ci-env automaticky nastaví potrebné príznaky pre príkaz werf build-and-publish (Alebo werf publish), takže pre tieto príkazy nie je potrebné zadávať žiadne ďalšie možnosti.
Napríklad príkaz:
werf publish --stages-storage :local --images-repo registry.hello.com/web/core/system --tag-by-stages-signature...môže vytvárať nasledujúce obrázky:
-
registry.hello.com/web/core/system/backend:4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d -
registry.hello.com/web/core/system/frontend:f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6
Tu 4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d je podpisom fáz obrazu backendA f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6 - podpis fáz obrazu frontend.
Pri používaní špeciálnych funkcií werf_container_image и werf_container_env V šablónach Helm nie je potrebné nič meniť: tieto funkcie automaticky vygenerujú správne názvy obrázkov.
Príklad konfigurácie v systéme CI:
type multiwerf && source <(multiwerf use 1.1 beta)
type werf && source <(werf ci-env gitlab)
werf build-and-publish|deployViac informácií o konfigurácii nájdete v dokumentácii:
- ;
- ;
- .
Celkom
- Nová možnosť
werf publish --tag-by-stages-signature=true|false. - Nová hodnota opcie
werf ci-env --tagging-strategy=stages-signature|tag-or-branch(ak nie je zadané, predvolená hodnota budestages-signature). - Ak ste predtým používali možnosti označovania pre odovzdania Git (
WERF_TAG_GIT_COMMITalebo možnosťwerf publish --tag-git-commit COMMIT), potom nezabudnite prejsť na stratégiu označovania etapy-podpis. - Je lepšie okamžite prepnúť nové projekty na novú schému označovania.
- Pri prenose do werf 1.1 je vhodné prepnúť staré projekty na novú schému označovania, ale stará tag-or-branch je stále podporovaný.
Označovanie založené na obsahu rieši všetky problémy uvedené v článku:
- Odolnosť názvu značky Docker voči prázdnym potvrdeniam Git.
- Odolnosť názvu značky Docker pre Git zaväzuje zmeny súborov irelevantných pre obrázok.
- Nevedie k problému s prepracovaním aktuálnej verzie obrazu pri reštartovaní zostavení pre staré potvrdenia Git pre vetvy Git.
Použi to! A nezabudnite nás navštíviť na vytvoriť problém alebo nájsť existujúci, dať plus, vytvoriť PR alebo jednoducho sledovať vývoj projektu.
PS
Prečítajte si aj na našom blogu:
- «»
- «»
- «»;
- Séria poznámok o inováciách vo werf:
- «»;
- «»;
- «»;
- «".
Zdroj: hab.com