Sisupõhine sildistamine werf-ehitajas: miks ja kuidas see töötab?

werf on meie avatud lähtekoodiga GitOps CLI utiliit rakenduste loomiseks ja Kubernetesesse tarnimiseks. IN väljalase v1.1 pildikogujas võeti kasutusele uus funktsioon: piltide märgistamine sisu järgi või sisupõhine märgistamine. Siiani hõlmas werfi tüüpiline märgistamisskeem Dockeri piltide märgistamist Git tag, Git filiaali või Git Commit abil. Kuid kõigil neil skeemidel on puudusi, mis on uue märgistamisstrateegiaga täielikult lahendatud. Üksikasjad selle ja selle kohta, miks see nii hea on, on allpool.

Mikroteenuste komplekti levitamine ühest Giti hoidlast

Sageli tekib olukord, kui rakendus on jagatud paljudeks enam-vähem sõltumatuteks teenusteks. Nende teenuste väljalaskmine võib toimuda iseseisvalt: korraga saab välja anda ühe või mitu teenust, ülejäänud peavad töötama ilma muudatusteta. Kuid koodi salvestamise ja projektihalduse seisukohalt on selliseid rakendusteenuseid mugavam hoida ühes hoidlas.

On olukordi, kus teenused on tõeliselt sõltumatud ega ole seotud ühe rakendusega. Sel juhul asuvad need eraldi projektides ja nende väljaandmine toimub igas projektis eraldi CI/CD protsesside kaudu.

Kuid tegelikkuses jagavad arendajad sageli ühe rakenduse mitmeks mikroteenuseks, kuid igaühe jaoks eraldi hoidla ja projekti loomine... on selge liialdus. Just seda olukorda arutatakse edasi: mitu sellist mikroteenust asuvad ühes projektihoidlas ja väljalasked toimuvad CI/CD-s ühe protsessi kaudu.

Märgistamine Giti filiaali ja Giti sildi järgi

Oletame, et kasutatakse kõige tavalisemat märgistamisstrateegiat – silt või haru. Giti filiaalide puhul märgistatakse pildid haru nimega, ühe haru jaoks on korraga avaldatud ainult üks pilt selle haru nime järgi. Giti siltide puhul märgistatakse pildid vastavalt sildi nimele.

Uue Giti sildi loomisel – näiteks uue versiooni väljalaskmisel – luuakse Dockeri registris kõigi projektipiltide jaoks uus Dockeri silt.

• 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

Need uued pildinimed edastatakse Helmi mallide kaudu Kubernetese konfiguratsiooni. Käsuga juurutamise alustamisel werf deploy välja uuendatakse image Kubernetese ressursi manifestides ja muudetud pildinime tõttu vastavate ressursside taaskäivitamine.

probleem: juhul, kui tegelikult pole pildi sisu pärast eelmist levitamist (Git-silt) muutunud, vaid ainult selle Dockeri silt, juhtub see üleliigne selle rakenduse taaskäivitamine ja sellest tulenevalt on võimalik mõni seisak. Kuigi tegelikult polnud põhjust seda restart teha.

Selle tulemusena on praeguse märgistamisskeemi puhul vaja mitut eraldiseisvat Giti hoidlat piirata ja probleem tekib nende mitme hoidla levitamise korraldamisel. Üldiselt osutub selline skeem ülekoormatud ja keeruliseks. Parem on ühendada paljud teenused ühte hoidlasse ja luua Dockeri sildid, et poleks tarbetuid taaskäivitusi.

Sildistamine Git Commitiga

werfil on ka Git commitsiga seotud sildistamisstrateegia.

Git-commit on Git-hoidla sisu identifikaator ja sõltub Git-hoidlas olevate failide redigeerimisajaloost, seega tundub loogiline kasutada seda Dockeri registris piltide märgistamiseks.

Git Commitiga märgistamisel on aga samad puudused kui Giti filiaalide või Giti siltide märgistamisel:

• Võiks luua tühja sissekande, mis ei muuda ühtegi faili, kuid pildi Dockeri silti muudetakse.
• Võib luua liitmiskohustuse, mis faile ei muuda, kuid pildi Dockeri silti muudetakse.
• Võib teha kohustuse, mis muudab Gitis neid faile, mida pildile ei impordita, ja pildi Dockeri silti muudetakse uuesti.

Giti filiaali nime märgistamine ei kajasta pildi versiooni

Giti filiaalide sildistamisstrateegiaga on seotud veel üks probleem.

Haru nime järgi märgistamine toimib seni, kuni selle haru kohustused kogutakse järjestikku kronoloogilises järjekorras.

Kui praeguses skeemis alustab kasutaja teatud haruga seotud vana commit ümberehitamist, siis werf kirjutab pildi ümber vastava Dockeri sildi abil koos uue versiooniga, mis on mõeldud vana commit jaoks. Nüüdsest seda silti kasutavatel juurutustel on oht, et podide taaskäivitamisel tõmmatakse pildist erinev versioon, mille tagajärjel meie rakendus kaotab ühenduse CI-süsteemiga ja muutub desünkroonituks.

Lisaks võib järjestikuste lükkamiste korral ühte harusse, mille vahel on lühike ajavahemik, vana commit hiljem kompileerida kui uuem: pildi vana versioon kirjutab Giti haru märgendi abil uue üle. Selliseid probleeme saab lahendada CI/CD süsteemiga (näiteks GitLab CI-s käivitatakse viimase konveier commitide seeria jaoks). Kuid mitte kõik süsteemid seda ei toeta ja sellise põhimõttelise probleemi vältimiseks peab olema usaldusväärsem viis.

Mis on sisupõhine märgistamine?

Niisiis, mis on sisupõhine sildistamine – piltide sildistamine sisu järgi.

Dockeri siltide loomiseks ei kasutata mitte Giti primitiive (Git haru, Git tag...), vaid kontrollsummat, mis on seotud:

• pildi sisu. Pildi ID-märgend kajastab selle sisu. Uue versiooni ehitamisel see identifikaator ei muutu, kui pildil olevad failid pole muutunud;
• selle pildi loomise ajalugu Gitis. Erinevate Giti filiaalide ja werfi kaudu erineva ehituse ajalooga seotud piltidel on erinevad ID-sildid.

Selline tunnusmärgis on nn pildi lavasignatuur.

Iga pilt koosneb mitmest etapist: from, before-install, git-archive, install, imports-after-install, before-setup, ... git-latest-patch jne. Igal etapil on identifikaator, mis kajastab selle sisu − lavasignatuur (lava signatuur).

Lõplik pilt, mis koosneb nendest etappidest, on märgistatud nende etappide komplekti nn signatuuriga - etappide allkiri, - mis on üldistav pildi kõikide etappide jaoks.

Iga pildi jaoks konfiguratsioonist werf.yaml Üldjuhul on oma allkiri ja vastavalt Dockeri silt.

Lavasignatuur lahendab kõik need probleemid:

• Vastupidav tühjadele Giti kohustustele.
• Gitile vastupidavad kohustused, mis muudavad failid, mis ei ole pildi jaoks asjakohased.
• See ei too kaasa pildi praeguse versiooni kapitaalremondi probleemi, kui taaskäivitatakse haru vanade Git-kohustuste jaoks.

See on nüüd soovitatav märgistamisstrateegia ja see on kõigi CI-süsteemide werf-i vaikeseade.

Kuidas werfis lubada ja kasutada

Nüüd on käsul vastav valik werf publish: --tag-by-stages-signature=true|false

CI-süsteemis määrab sildistamise strateegia käsuga werf ci-env. Varem oli selle jaoks parameeter määratletud werf ci-env --tagging-strategy=tag-or-branch. Kui nüüd täpsustate werf ci-env --tagging-strategy=stages-signature või ärge seda valikut määrake, kasutab werf vaikimisi sildistamisstrateegiat stages-signature. Meeskond werf ci-env määrab automaatselt käsu jaoks vajalikud lipud werf build-and-publish (Või werf publish), seega ei pea nende käskude jaoks lisavalikuid määrama.

Näiteks käsk:

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

...saab luua järgmisi pilte:

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

see on 4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d on kujutise etappide signatuur backendJa f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6 - pildietappide signatuur frontend.

Erifunktsioonide kasutamisel werf_container_image и werf_container_env Helmi mallides pole vaja midagi muuta: need funktsioonid genereerivad automaatselt õiged pildinimed.

Konfiguratsiooni näide CI-süsteemis:

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

Lisateavet konfiguratsiooni kohta leiate dokumentatsioonist:

• Kataloog → Väljaanne (avalda);
• Töö CI/CD-ga → Üldteave → etapid-signatuur;
• Integratsioon GitLab CI/CD-ga → .gitlab-ci.yml.

Kogusummas

• Uus variant werf publish --tag-by-stages-signature=true|false.
• Uus valiku väärtus werf ci-env --tagging-strategy=stages-signature|tag-or-branch (kui pole määratud, on vaikeseade stages-signature).
• Kui kasutasite varem Git'i kohustuste (WERF_TAG_GIT_COMMIT või variant werf publish --tag-git-commit COMMIT), siis lülituge kindlasti märgistamisstrateegiale etapid-signatuur.
• Parem on uued projektid koheselt uuele märgistusskeemile üle viia.
• Üleminekul werf 1.1-le on soovitatav vanad projektid uuele märgistusskeemile üle viia, kuid vanad silt või haru on endiselt toetatud.

Sisupõhine märgistamine lahendab kõik artiklis käsitletud probleemid:

• Dockeri sildi nime takistus tühjadele Giti kohustustele.
• Dockeri sildi nime vastupidavus Gitile, mis muudab pildi jaoks ebaolulisi faile.
• See ei too kaasa pildi praeguse versiooni kapitaalremondi probleemi, kui taaskäivitatakse Giti filiaalide jaoks mõeldud versioonid.

Kasuta seda! Ja ärge unustage meid külastada aadressil GitHubprobleemi loomiseks või olemasoleva leidmiseks, plussi lisamiseks, suhtekorralduse loomiseks või lihtsalt projekti arengu jälgimiseks.

PS

Loe ka meie blogist:

• «werf 1.1 väljalase: ehitaja tänased täiustused ja tulevikuplaanid»
• «Tutvustame werf 1.0 stabiilset: mis on GitOpsil sellega pistmist, olek ja plaanid»
• «werf - meie tööriist CI / CD jaoks Kubernetesis (ülevaade ja videoaruanne)";
• Märkuste sari werfi uuenduste kohta:
  • «Kolmesuunaline ühendamine werfiga: juurutamine Kubernetesesse koos Helmiga "steroididel"";
  • «werfi kasutamine keeruliste Helmi diagrammide väljarullimiseks";
  • «Monorepo ja multirepo tugi werfis ning mis on Dockeri registril sellega pistmist";
  • «Nüüd saate luua Dockeri pilte werf-is, kasutades tavalist Dockerfile'i'.

Allikas: www.habr.com