🥇Sisältöpohjainen taggaus werf-keräilijässä: miksi ja miten se toimii?

werf on avoimen lähdekoodin GitOps CLI -apuohjelma sovellusten rakentamiseen ja toimittamiseen Kubernetesille. SISÄÄN julkaisu v1.1 Kuvankerääjässä otettiin käyttöön uusi ominaisuus: kuvien merkitseminen sisällön mukaan tai sisältöön perustuva koodaus. Tähän asti tyypillinen werf-koodausjärjestelmä sisälsi Docker-kuvien merkitsemisen Git-tagilla, Git-haaralla tai Git-commitilla. Mutta kaikilla näillä järjestelmillä on haittoja, jotka uusi merkintästrategia ratkaisee kokonaan. Yksityiskohdat siitä ja miksi se on niin hyvä, ovat alla.

Mikropalveluiden ottaminen käyttöön yhdestä Git-tietovarastosta

Usein syntyy tilanne, kun sovellus jaetaan useaan enemmän tai vähemmän itsenäiseen palveluun. Näiden palveluiden julkaisut voivat tapahtua itsenäisesti: yksi tai useampi palvelu voidaan julkaista kerrallaan, kun taas muiden tulee jatkaa toimintaansa ilman muutoksia. Mutta koodin tallennuksen ja projektinhallinnan näkökulmasta on kätevämpää pitää tällaiset sovelluspalvelut yhdessä arkistossa.

On tilanteita, joissa palvelut ovat todella riippumattomia, eivätkä ne liity yhteen sovellukseen. Tällöin ne sijoitetaan erillisiin projekteihin ja niiden julkaisu tapahtuu kussakin hankkeessa erillisillä CI/CD-prosesseilla.

Todellisuudessa kehittäjät kuitenkin usein jakavat yhden sovelluksen useisiin mikropalveluihin, mutta jokaiselle erillisen arkiston ja projektin luominen... on selvää ylilyöntiä. Juuri tästä tilanteesta keskustellaan edelleen: useita tällaisia mikropalveluita sijaitsee yhdessä projektivarastossa ja julkaisut tapahtuvat yhden prosessin kautta CI/CD:ssä.

Koodaus Git-haaralla ja Git-tagilla

Oletetaan, että käytetään yleisintä merkintästrategiaa - tag-tai-oksa. Git-haaroissa kuvat on merkitty haaran nimellä, yhdelle haaralle kerrallaan on vain yksi julkaistu kuva kyseisen haaran nimellä. Git-tageissa kuvat merkitään tunnisteen nimen mukaan.

Kun uusi Git-tagi luodaan – esimerkiksi kun uusi versio julkaistaan – kaikille Docker-rekisterin projektikuville luodaan uusi Docker-tagi:

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

Nämä uudet kuvien nimet välitetään Helm-mallien kautta Kubernetes-kokoonpanoon. Kun käyttöönotto aloitetaan komennolla werf deploy kenttää päivitetään image Kubernetesin resurssiluetteloissa ja vastaavien resurssien uudelleenkäynnistäminen muuttuneen kuvan nimen vuoksi.

ongelma: jos kuvan sisältö ei itse asiassa ole muuttunut edellisen käyttöönoton jälkeen (Git-tunniste), vaan vain sen Docker-tunniste, tämä tapahtuu ylimäärä käynnistämällä tämän sovelluksen uudelleen ja vastaavasti jonkin verran seisokkeja on mahdollista. Vaikka ei ollut todellista syytä suorittaa tätä uudelleenkäynnistystä.

Tämän seurauksena nykyisellä merkintäjärjestelmällä on tarpeen rajata useita erillisiä Git-tietovarastoja, ja ongelma syntyy näiden useiden arkiston käyttöönoton järjestämisestä. Yleensä tällainen järjestelmä osoittautuu ylikuormitetuksi ja monimutkaiseksi. On parempi yhdistää useita palveluita yhdeksi arkistoon ja luoda Docker-tunnisteita, jotta turhaa uudelleenkäynnistystä ei tapahdu.

Taggaus Git commitin avulla

werfillä on myös merkintästrategia, joka liittyy Git-sitoumuksiin.

Git-commit on Git-arkiston sisällön tunniste ja riippuu Git-arkiston tiedostojen muokkaushistoriasta, joten vaikuttaa loogiselta käyttää sitä kuvien merkitsemiseen Docker-rekisterissä.

Git commitin merkitsemisellä on kuitenkin samat haitat kuin Git-haarojen tai Git-tagien merkitsemisellä:

Voidaan luoda tyhjä toimitus, joka ei muuta tiedostoja, mutta kuvan Docker-tunniste muuttuu.
Voidaan luoda yhdistämistoimitus, joka ei muuta tiedostoja, mutta kuvan Docker-tunniste muuttuu.
Voidaan tehdä sitoumus, joka muuttaa ne Gitissä olevat tiedostot, joita ei ole tuotu kuvaan, ja kuvan Docker-tunniste muutetaan uudelleen.

Git-haaran nimen merkitseminen ei vastaa kuvaversiota

Git-haarojen koodausstrategiaan liittyy toinen ongelma.

Haaran nimen merkitseminen toimii niin kauan kuin kyseisen haaran sitoumukset kerätään peräkkäin kronologisessa järjestyksessä.

Jos nykyisessä järjestelmässä käyttäjä alkaa rakentaa uudelleen tiettyyn haaraan liittyvää vanhaa toimitusta, werf kirjoittaa kuvan uudelleen käyttämällä vastaavaa Docker-tunnistetta ja kuvan uudella versiolla vanhaa toimitusta varten. Tätä tagia käyttävät käyttöönotot ovat tästä lähtien vaarassa vetää toisen version kuvasta käynnistettäessä podeja uudelleen, minkä seurauksena sovelluksemme menettää yhteyden CI-järjestelmään ja muuttuu epäsynkroniseksi.

Lisäksi peräkkäisillä työntöillä yhteen haaraan lyhyellä aikavälillä vanha vahvistus voidaan kääntää myöhemmin kuin uudempi: kuvan vanha versio korvaa uuden Git-haaratunnisteen avulla. Tällaiset ongelmat voidaan ratkaista CI/CD-järjestelmällä (esimerkiksi GitLab CI:ssä jälkimmäisen putki käynnistetään sarjaa sitoumuksia varten). Kaikki järjestelmät eivät kuitenkaan tue tätä, ja on oltava luotettavampi tapa estää tällainen perustavanlaatuinen ongelma.

Mitä on sisältöön perustuva taggaus?

Joten mitä on sisältöön perustuva taggaus - kuvien merkitseminen sisällön mukaan.

Docker-tunnisteiden luomiseen ei käytetä Git-primitiiviä (Git-haara, Git-tunniste...), vaan tarkistussumma, joka liittyy:

kuvan sisältö. Kuvatunnustunniste heijastaa sen sisältöä. Uutta versiota rakennettaessa tämä tunniste ei muutu, jos kuvan tiedostot eivät ole muuttuneet;
tämän kuvan luomisen historia Gitissä. Kuvissa, jotka liittyvät eri Git-haaroihin ja eri koontihistoriaan werfin kautta, on eri ID-tunnisteet.

Tällainen tunnistetunniste on ns kuvavaiheen allekirjoitus.

Jokainen kuva koostuu joukosta vaiheita: from, before-install, git-archive, install, imports-after-install, before-setup, ... git-latest-patch jne. Jokaisella vaiheella on tunniste, joka heijastaa sen sisältöä − vaiheen allekirjoitus (lava allekirjoitus).

Lopullinen kuva, joka koostuu näistä vaiheista, on merkitty näiden vaiheiden joukon ns. allekirjoituksella - vaiheiden allekirjoitus, - joka on yleistävä kuvan kaikille vaiheille.

Jokaiselle kokoonpanon kuvalle werf.yaml yleensä siinä on oma allekirjoitus ja vastaavasti Docker-tunniste.

Lavan allekirjoitus ratkaisee kaikki nämä ongelmat:

Kestää tyhjiä Git-sitoumuksia.
Resistant to Git -sitoumukset, jotka muuttavat tiedostoja, jotka eivät liity kuvaan.
Ei johda ongelmaan, joka liittyy kuvan nykyisen version tarkistamiseen, kun käännökset käynnistetään uudelleen haaran vanhoille Git-sitoumuksille.

Tämä on nyt suositeltu merkintästrategia, ja se on oletusarvo werf:ssä kaikissa CI-järjestelmissä.

Kuinka ottaa käyttöön ja käyttää werfissä

Komennossa on nyt vastaava vaihtoehto werf publish: --tag-by-stages-signature=true|false

CI-järjestelmässä merkintästrategia määritellään komennolla werf ci-env. Aiemmin parametri oli määritetty sille werf ci-env --tagging-strategy=tag-or-branch. Nyt jos täsmennät werf ci-env --tagging-strategy=stages-signature tai älä määritä tätä vaihtoehtoa, werf käyttää oletusarvoisesti merkintästrategiaa stages-signature. Tiimi werf ci-env asettaa automaattisesti tarvittavat liput komennolle werf build-and-publish (tai werf publish), joten näille komentoille ei tarvitse määrittää lisäasetuksia.

Esimerkiksi komento:

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

...voi luoda seuraavat kuvat:

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

Täällä 4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d on allekirjoitus kuvan vaiheista backendJa f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6 - kuvavaiheiden allekirjoitus frontend.

Käytettäessä erikoistoimintoja werf_container_image и werf_container_env Helm-malleissa ei tarvitse muuttaa mitään: nämä toiminnot luovat automaattisesti oikeat kuvien nimet.

Esimerkki konfiguraatiosta CI-järjestelmässä:

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

Lisätietoja konfiguroinnista on dokumentaatiossa:

Yhteensä

Uusi vaihtoehto werf publish --tag-by-stages-signature=true|false.
Uusi optioarvo werf ci-env --tagging-strategy=stages-signature|tag-or-branch (jos sitä ei ole määritetty, oletusarvo on stages-signature).
Jos käytit aiemmin merkintävaihtoehtoja Git-sitoumuksiin (WERF_TAG_GIT_COMMIT tai vaihtoehto werf publish --tag-git-commit COMMIT), vaihda sitten taggausstrategiaan vaiheet-allekirjoitus.
On parempi vaihtaa uudet projektit välittömästi uuteen merkintäjärjestelmään.
Siirrettäessä werf 1.1:een, on suositeltavaa vaihtaa vanhat projektit uuteen merkintäjärjestelmään, mutta vanha tag-tai-oksa on edelleen tuettu.

Sisältöpohjainen koodaus ratkaisee kaikki artikkelissa käsitellyt ongelmat:

Docker-tunnisteen nimen vastustus tyhjille Git-sitoumuksille.
Docker-tunnisteen nimen joustavuus Git-sitoumuksiin, jotka muuttavat kuvan kannalta epäolennaisia tiedostoja.
Ei johda ongelmaan, joka liittyy kuvan nykyisen version tarkistamiseen, kun käynnistetään uudelleen koontiversiot vanhoille Git-sitoumuksille Git-haareille.

Käytä sitä! Ja älä unohda vierailla osoitteessa GitHubluoda ongelma tai löytää olemassa oleva, lisätä plus, luoda PR tai yksinkertaisesti seurata projektin kehitystä.

PS.

Lue myös blogistamme:

Lähde: will.com

Sisältöpohjainen taggaus werf builderissä: miksi ja miten se toimii?