🥇werf — meie tööriist CI/CD jaoks Kuberneteses (ülevaade ja ettekande video)

27. mai DevOpsConf 2019 peamiseks saalis, mis toimub festivali raames RIT++ 2019, sektsioonis „Jätkuv tarnimine“ kõlas ettekand „werf — meie tööriist CI/CD jaoks Kuberneteses“. Selles räägitakse nendest probleemidest ja väljakutsetest, millega igaühel on silmitsi seista Kubernetesesse juurutamisel, samuti nüanssidest, mis ei pruugi kohe silma torkata. Tutvustades võimalikke lahendusteid, näitame, kuidas see on rakendatud avatud lähtekoodiga tööriistis werf.

Alates meie ettekandest on meie utiliit (varem tuntud kui dapp) ületanud ajaloolise piiri 1000 tähte GitHubis — loodame, et kasvav kasutajaskond teeb elu lihtsamaks paljudele DevOps-inseneridele.

Nii et tutvustame ettekande video vaatamiseks (~47 minutit, palju informatiivsem kui artikkel) ja selle peamisi kokkuvõtteid tekstivormis. Alustame!

Koodi tarnimine Kubernetesesse

Ettekanne räägib enam mitte werf'ist, vaid CI/CD-st Kuberneteses, eeldades, et meie tarkvara on pakitud Docker-konteinernitesse (sellest rääkisin ma 2016. aasta ettekandes), ja K8s kasutatakse selle käitamiseks tootmises (sellest — 2017. aastal).

Kuidas näeb välja tarnimine Kubernetesesse?

On olemas Git-repositsioon koos koodiga ja juhistega selle kogumiseks. Rakendus kogutakse Docker-pildiks ja avaldatakse Docker Registry'sse.
Samas repositooriumis on juhised ka selle kohta, kuidas rakendust juurutada ja käivitada. Juhtimise etapis saadetakse need juhised Kubernetes'esse, mis toob vajaliku pildi registrist ja käivitab selle.
Lisaks on tavaliselt olemas testid. Mõningaid neist saab käivitada pildi avaldamise ajal. Samuti saab (sama juhiste abil) juurutada rakenduse koopia (erinevas K8s-nimruumis või eraldi klastris) ja käivitada seal testid.
Lõpuks on vajalik CI-süsteem, mis saab sündmusi Git'ist (või nupuvajutustest) ja kutsub välja kõik määratud etapid: build, publish, deploy, test.

Siin on mõned olulised märkused:

Kuna meil on muutumatu infrastruktuur (immutable infrastructure), peab rakenduse pilt, mida kasutatakse kõigis etappides (staging, production jne), olema ühesugune.. Üksikasjalikumalt sellest ja koos näidistega rääkisin ma siit.
Kuna me järgime lähenemist infrastruktuur kui kood (IaC), peab rakenduse kood, selle kogumise ja käivitamise juhised olema just ühes repositooriumis.. Rohkem teavet selle kohta — vt samast ettekandest..
Tootmise ahel (tootmine) näeme tavaliselt nii: rakendus on kokku pandud, testitud ja välja lastud (vabastamise etapp) ja kõik — tarnimine toimus. Kuid tegelikult saab kasutaja seda, mida te välja lasite, ei just siis, kui te selle tootmisprotsessi tarnisite ja kui ta pääses sellele juurde ja see tootmisprotsess töötas. Seetõttu arvan, et tootmise ahel lõpeb ainult tööetapis (töö), ja täpsemalt, isegi hetkel, kui kood eemaldati tootmisest (asendades selle uuega).

Naaseme ülaltoodud Kubernetes’e tarnimise skeemi juurde: seda ei ole välja mõelnud ainult meie, vaid ka sisuliselt igaüks, kes selle probleemiga tegeleb. Tegelikult nimetatakse seda mustrit nüüd GitOps (rohkem terminist ja ideedest, mis selle taga seisavad, saab lugeda siit)). Vaatame skeemi etappe.

Kogumise etapp

Tundub, et 2019. aastal võib rääkida Docker-piltide kogumisest, kui kõik oskavad kirjutada Dockerfile’e ja käivitada docker build?.. Вот нюансы, на которые хотелось бы обратить внимание:

Pildi suurus on oluline, seega kasutage multi-stage, et jätta pildile alles ainult tõeliselt vajalik rakenduse tööks.
Kihte tuleb minimeerida, ühendades RUN-käsku loogiliselt.
Kuid see toob kaasa probleeme silumiseks, kuna ehituse kokkuvarisemisel tuleb leida see õige käsk järjekorrast, mis probleemi põhjustas.
Kogumise kiirus on oluline, kuna soovime kiiresti muudatusi ellu viia ja nende tulemusi jälgida. Näiteks ei taha ma iga rakenduse kogumise korral keeltes esinevaid sõltuvusi uuesti koguda.
Sageli vajatakse ühest Git-repositooriumist palju pilte, mida saab lahendada Dockerfile’ide komplekti (või nimetatud etappidega ühes failis) ja Bash-skripti abil nende järjestikuseks kogumiseks.

See oli vaid jäämäe tipp, millega kõik silmitsi seisavad. Kuid on ka teisi probleeme, sealhulgas:

Sageli on meil ehitusetapis vaja midagi mountida (nt. apt käskluse tulemuse vahemälu salvestamiseks välisesse kataloogi).
Soovime Ansible ebaefektiivse shell'i asemel.
Soovime kogu ilma Dockerita (miks peaks olema täiendav virtuaalmasin, kuhu tuleb see kõik seadistada, kui meil on juba Kubernetes'i klaster, kus konteinerit jooksutada?).
Paralleelne koostamine, mida võib tõlgendada erinevalt: erinevad käsud Dockerfile’is (kui kasutatakse multi-stage), mitu commit'i ühes repozitoriumis, mitu Dockerfile'i.
Jaotatud ehitamine: soovime ehitada midagi pod’ides, mis on „efemiirilised”, kuna neil kaob vahemälu, seega — see tuleb kuskil eraldi salvestada.
Lõpuks, oma soovide tippu nimetasin automaagiks: oleks ideaalne siseneda repozitoriumi, sisestada mõni käsk ja saada valmis pilt, koostatud arusaamisega, kuidas ja mida õigesti teha. Kuigi ma isiklikult ei ole kindel, et kõik nüansid on võimalik ette näha.

Ja siin on projektid:

moby/buildkit — ehitaja Docker Inc.’ilt (juba integreeritud uusimatesse Docker'i versioonidesse), mis püüab lahendada kõiki neid probleeme;
kaniko — Google'i ehitaja, mis võimaldab ehitamist ilma Dockerita;
Buildpacks.io — CNCF katse teha automaagia ja eriti huvitav lahendus rebase'iga kihtide jaoks;
ja veel hunnik muid utiliite, nagu buildah, genuinetools/img…

… ja vaadake, kui palju neil on tähti GitHub'is. See tähendab, et ühelt poolt docker build on midagi olemas ja see võib midagi teha, kuid tegelikult küsimus ei ole lõpuni lahendatud — selle tõestuseks on alternatiivsete kogujate paralleelne areng, millest igaühel on oma osa probleemide lahendamisel.

Kogumine werfis

Nii jõudsime werf (varem kuulsa nagu dapp) — Open Source tööriist, mille on välja töötanud ettevõte „Flant”, millega oleme tegelenud juba aastaid. Kõik algas viis aastat tagasi Bash-skriptidega, mis optimeerisid Dockerfile’ide kogumist, ja viimased kolm aastat on toimunud täieõiguslik arendus ühe projekti raames oma Git-repositooriumiga. (esialgu Ruby’s, seejärel ümber kirjutatud Go’s, ja samal ajal ka ümber nimetatud). Millised kogumise küsimused on werfis lahendatud?

Sinisega rõhutatud probleemid on juba lahendatud, paralleelne kogumine on teostatud ühe hosti raames, ning kollaselt esile tõstetud küsimusi plaanime lõpule viia suve lõpuks.

Avaldamise staadium registry’s (publish)

Oleme kogunud docker push… — mis võib olla keerulist pildi üleslaadimises registry’s? Ja siis tekib küsimus: „Millise sildi peaks pildile panema?” See tekib sellest, et meil on Gitflow (või mõni muu Git strateegia) ja Kubernetes, ning tööstus püüdleb selle poole, et Kuberneteses toimuv järgiks seda, mis toimub Git’is. Lõppude lõpuks on Git meie ainus tõeallikas.

Mis selles nii keerulist on? Kordineeritavuse tagamine: alates Git'i commit'ist, mis on oma olemuselt muutumatu (muutumatu), kuni Docker'i pildini, mis peab jääma samaks.

Meile on samuti oluline tuvastada päritolu, sest me tahame mõista, millisest commit'ist on loodud rakendus, mis töötab Kuberneteses (siis saame teha diff'e ja sarnaseid asju).

Siltimistaktikad

Esimene — see on lihtne git tag. Meil on registry pildiga, mis on sildistatud kui 1.0. Kuberneteses on etapp ja tootmine, kuhu see pilt on välja tõmmatud. Git'is teeme commit'e ja mingil hetkel määrame sildi 2.0. Kogume selle vastavalt repole ja paigutame registry'sse sildiga 2.0. Rakendame etapis ja, kui kõik läheb hästi, siis tootmisse.

Selle lähenemisviisi probleem on see, et me määrasime esmalt sildi, ja alles siis testisime ja rakendasime. Miks? Esiteks on see lihtsalt ebaoluline: me väljastame versiooni tarkvarast, mida pole isegi kontrollitud (me ei saa teisiti, kuna kontrollimiseks on vajalik silt paigaldada). Teiseks, see tee ei sobi Gitflow'ga.

Teine variant — git commit + tag. Master harul on silt 1.0; tema jaoks registry's — pilt, mis on juurutatud tootmisesse. Lisaks on Kubernetes-klastris preview ja staging kontuurid. Jätkame Gitflow'd: arenduspeamises (develop) loome uusi funktsioone, mille tulemuseks on kohalik commit, mille identifikaator on #c1. Me kogume selle kokku ja avaldame registry'sse, kasutades seda identifikaatorit (#c1). Sellega sama identifikaatoriga viime läbi preview'e. Sarnasel viisil tegutseme commitidega #c2 ja #c3.

Kui oleme aru saanud, et funktsioon on piisav, hakkame kõike stabiliseerima. Git'is loome haru release_1.1 (baasil #c3 kohast develop). Selle versiooni kogumine ei ole vajalik, kuna see on tehtud eelneval etapil. Seetõttu saame lihtsalt selle staging'isse viia. Parandame vead #c4 ja viime sarnasel viisil staging'isse. Samal ajal käib arendus develop, kuhu vaheldumisi tuuakse muudatusi release_1.1. Mingil hetkel saame kokku pandud ja staging'isse viidud commit', millega oleme rahul (#c25).

Siis teeme merge (fast-forwardiga) versiooni haru (release_1.1) masterisse. Paneme selle commit'i külge uue versiooni sildi (1.1). Kuid see pilt on juba kogutud registry's, seega, et mitte uuesti seda koguda, lisame lihtsalt teise sildi olemasolevale pildile (nüüd on tal registry's sildid #c25 ja 1.1). Pärast seda lähetame selle tootmisse.

On puudus, et staging'is on laetud üks pilt (#c25), kuid tootmises on nagu teine (1.1), kuid me teame, et „füüsiliselt” on see sama pilt registrist.

Tegelikkuses on puuduseks see, et merge commit’de tugi puudub, peame tegema fast-forward.

Saame minna edasi ja teha triki… Vaatame lihtsa Dockerfile’i näidet:

FROM ruby:2.3 as assets
RUN mkdir -p /app
WORKDIR /app
COPY . ./
RUN gem install bundler && bundle install
RUN bundle exec rake assets:precompile
CMD bundle exec puma -C config/puma.rb

FROM nginx:alpine
COPY --from=assets /app/public /usr/share/nginx/www/public

Loome sellest faili sellise printsiibi alusel, et võtame:

SHA256 kasutatavate piltide identifikaatoritest (ruby:2.3 ja nginx:alpine), mis on nende sisu kontrollsummad;
kõik käsud (RUN, CMD jne);
SHA256 failidest, mis on lisatud.

… ja võtame uuesti kontrollsummana (SHA256) sellise faili. See allkiri kõigest, mis määrab Docker-pildi sisu.

Naaseme skeemi juurde ja kasutame selliste allkirjade asemel commit’e,st. märgistame pildid allkirjadega.

Nüüd, kui näiteks on tarvis ‘merge’ida muudatused väljaandest masterisse, saame teha tõelise merge commit'i: sellel on erinev identifikaator, kuid sama allkiri. Sama identifikaatoriga viime välja ka pildi tootmisse.

Puuduseks on see, et nüüd ei ole võimalik määrata, mis commit on tootmisse viidud — kontrollsummad toimivad ainult ühes suunas. See probleem lahendatakse täiendava metadata kihiga — räägin sellest lähemalt hiljem.

Märgistamine werf'is

werf'is oleme läinud veelgi kaugemale ning valmistume nendele, kes ei hoia oma cache'i ühel masinal, jaotatud ehitamiseks... Nii et meil on kahe tüüpi Docker'i pildid, mida nimetame etapi ja pilt.

Git'i hoidlas werf on säilitatud spetsiifilised juhised ehitamiseks, mis kirjeldavad erinevaid ehitusetappe (beforeInstall, install, beforeSetup, setup). Esimene stage- pildistame kogume signatuuriga, mis on määratletud kui esimeste sammude kontrollsummana. Seejärel lisame lähtekoodi, uue stage-pildi jaoks arvutame ka selle kontrollsummat… Need toimingud korratakse kõigi etappide jaoks, mille tulemuseks on set stage-pilte. Siis loome lõpliku image-pildi, mis sisaldab ka tema päritolu metaandmeid. Ja just seda pilti me märgistame erinevate viisidega (detailid hiljem).

Oletame, et pärast seda ilmub uus commit, kus on muudetud ainult rakenduse koodi. Mida juhtub? Koodi muudatuste jaoks luuakse patch, valmistatakse ette uus stage-pilt. Selle signatuur määratakse kui vana stage-pildi ja uue patši kontrollsumma. Sellest pildist kujundatakse uus lõplik image-pilt. Sarnane käitumine toimub ka teistel etappidel.

Seega, stage-pildid on cache, mida saab hoida hajutatult, ning neist loodud image-pildid laaditakse Docker Registry'sse.

Registry puhastamine

Jutt on siiski pigem nende Docker'i siltide eemaldamisest, mis on jäänud rippuma pärast eemaldatud silte — see on Docker Registry standardne funktsioon. Tõeliselt räägime olukorrast, kus koguneb palju Docker'i silte ja me mõistame, et osa neist pole enam vajalik, kuid nad võtavad ruumi (ja/või maksame selle eest).

Millised on puhastamise strateegiad?

Võib lihtsalt mitte midagi teha puhastada. Mõnikord on tõesti lihtsam veidi maksta liigse ruumi eest, kui proovida lahti harutada tohutut silti. Kuid see toimib ainult teatud hetkeni.
Täielik lähtestamine. Kui kustutada kõik pildid ja koostada ainult ajakohased CI-süsteemis, võib tekkida probleem. Kui tootmises konteiner käivitub, laaditakse sellele uus pilt — selline, mida pole keegi testinud. See hävitab immutable infrastructure idee.
Sinine-roheline. Kui üks registri hakkab üle voolama — laadige pildid teise. Sama probleem, mis eelmisel meetodil: millal on võimalik puhastada see registreerimine, mis hakkas üle voolama?
Aja järgi. Kustutada kõik pildid, mis on vanemad kui 1 kuu? Kuid kindlasti on teenus, mis ei ole kuus uuendatud...
Käsitsi määratle, mida võib juba eemaldada.

Tõeliselt toimivaid variante on kaks: mitte puhastada või kasutada blue-green kombinatsiooni koos käsitsi puhastamisega. Viimases juhul tähendab see järgmist: kui saad aru, et on aeg registrit puhastada, lood uue ja lisad kõik uued pildid sellesse, näiteks kuu aja jooksul. Ja kuu pärast vaatad, millised pod'id Kuberneteses kasutavad endiselt vana registrit ning kannad need ka uude registrisse üle.

Kuhu me jõudsime werf? Мы собираем:

Git head: kõik sildid, kõik harud — eeldades, et kõik, mis on Git'is sildistatud, on vajalik ka piltides (ja kui ei, siis tuleb need Git'is eemaldada);
kõik pod'id, mis on praegu Kuberneteses välja toimetatud;
vanad ReplicaSet'id (need, mis on hiljuti välja toimetatud), samuti plaanime skaneerida Helm'i väljalasked ja välja valida viimased pildid seal.

… ja teeme sellest komplektist whitelist'i — nimekiri piltidest, mida me ei eemalda. Kõik muu puhastame, pärast mida otsime üles orvud staatilised pildid ja eemaldame need ka.

Deploy-etapp

Usaldusväärne deklaratiivsuse tase

Esimene asi, millele tahaks tähelepanu pöörata deploos, on uue ressursik конфигураatia väljaandmine, mis on deklareeritud. Originaalne YAML-dokument Kubernetes-ressursside kirjeldamisega erineb alati oluliselt (tulemusest), mis tegelikult klastris töötab. Sest Kubernetes lisab konfiguratsioonile:

tuvastajad;
teenuste teavet;
mitmeid vaikeseade väärtusi;
osa praeguse oleku kohta;
muudatused, mis on tehtud admission webhooki töö käigus;
eraldi juhtide (ja planeerija) töö tulemuse.

Seetõttu, kui ilmub uus ressursi konfiguratsioon (uus), ei saa me lihtsalt võtta ja kirjutada selle üle praegust, "elavat" konfiguratsiooni (live). Selleks peame me võrreldama uus eelmise rakendatud konfiguratsiooniga (last-applied) ja rakendama live saadud patši.

Seda lähenemist nimetatakse 2-way merge. Seda kasutatakse näiteks Helm'is.

On ka 3-way merge, mis erineb selle poolest, et:

võrreldes last-applied ja uus, vaatame, mis on eemaldatud;
võrreldes uus ja live, vaatame, mis on lisatud või muudetud;
kumulatiivse patši rakendame live.

Deployime üle 1000 rakenduse Helmiga, nii et tegelikult elame 2-way merge'i kaudu. Kuid sellel on mitmeid probleeme, mille oleme lahendanud oma patch’idega, et aidata Helm'il normaalselt töötada.

Tõeline väljalaske staatus

Pärast seda, kui meie CI-süsteem on järjekordse sündmuse tõttu genereerinud uue konfiguratsiooni Kubernetes'e jaoks, edastab see selle rakendamiseks (rakenda) klastrisse — kasutades Helm'i või kubectl apply. Seejärel toimub juba kirjeldatud N-way merge, milles Kubernetes API kiidab heaks CI-süsteemi, ning see omakorda oma kasutaja.

Kuid probleem on suur: nimelt edukas rakendamine ei tähenda eduka väljalaskmist.Kui Kubernetes mõistab, milliseid muudatusi tuleb rakendada, siis rakendab selle — me ei tea veel, milline on lõpptulemus. Näiteks frontendis võib uuendus ja pod'ide taaskäivitamine õnnestuda, samas kui backendis see ei õnnestu ning saame rakenduse erinevad versioonid.

Õige tegemiseks on selles skeemis tarvis lisasilda — spetsiaalset jälgijat, mis saaks Kubernetes API-lt teavet staatuse kohta ja edastada selle edasiseks analüüsimiseks tegeliku seisundi osas. Oleme loonud Open Source'i teegi Go-s — kubedog (vt selle teadaanne siit), — mis lahendab selle probleemi ja on integreeritud werf-i.

Selle jälgija käitumist werf-i tasandil configureerimine toimub annotatsioonide abil, mis paigutatakse Deployment'itele või StatefulSets'ile. Peamine annotatsioon on fail-mode — mõistab järgmisi väärtusi:

IgnoreAndContinueDeployProcess — ignoreerime selle komponendi väljalaskmisel esinevaid probleeme ja jätkame juurutamist;
FailWholeDeployProcessImmediately — selle komponendi viga peatab juurutamisprotsessi;
HopeUntilEndOfDeployProcess — loodame, et see komponent töötab juurutamise lõpuks.

Näiteks selline kombinatsioon ressurssidest ja annotatsiooni väärtustest fail-mode:

Kui juurutame esmakordselt, võib andmebaas (MongoDB) olla veel valmis — Deployment'id kukuvad. Kuid võime oodata aega, kuni see käivitub, ja juurutamine möödub siiski.

Werfil on veel kaks annotatsiooni kubedogi jaoks:

failures-allowed-per-replica — lubatud kukkumiste arv iga replikatsiooni kohta;
show-logs-until — reguleerib hetke, kuni werf näitab (stdout-is) logisid kõigilt juurutatavatelt pod'idelt. Vaikimisi on see PodIsReady (et ignoreerida teateid, mis meile tõenäoliselt ei ole vajalikud, kui pod'ile hakkab liiklus tulema), kuid lubatud on ka väärtused ControllerIsReady ja EndOfDeploy.

Mida veel soovime juurutamiselt?

Lisaks juba kirjeldatud kahele punktile soovime:

näha logisid — ning ainult vajalikke, mitte kõiki järjestikku;
jälgida edusamme, kuna kui töö „vaikselt“ seiskub minutiteks, on oluline mõista, mis seal toimub;
omada automaatset tagasipöördumist juhtumiteks, kui midagi läheb valesti (seetõttu on kriitiliselt oluline teada tõelist staatust). Käivitamine peab olema atomaarne: kas see toimub lõpuni või kõik naaseb eelnevasse olekusse.

Kokkuvõte

Meie ettevõttele on nende kõigi aspektide teostamiseks tarnimise eri etappides (build, publish, deploy) piisav CI-süsteem ja tööriist werf.

Kokkuvõtteks:

Tänu werfile oleme suutnud hästi edasi liikuda paljusid DevOps-inseneride probleeme lahendada ja oleme rõõmsad, kui laiem kogukond vähemalt proovib seda tööriista. Hea tulemuse saavutamine koos on lihtsam.