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

27. mai DevOpsConf 2019 peamise saali konverentsil, mis toimub festivali raames RIT++ 2019, konverentsi sektsioonis "Pidev tarne" esitati ettekannet "werf - meie tööriist CI/CD jaoks Kuberneteses". Ettekanne käsitleb neid probleeme ja väljakutseid, millega igaühel silmitsi seista tuleb, kui näiteks kasutatakse Kuberneteset, samuti nüansse, mis ei pruugi kohe silma paista. Potentsiaalsete lahenduste käsitlemisel näitame, kuidas see on ellu viidud avatud lähtekoodiga tööriist werf.

Alates ettekandest on meie utiliit (varem tuntud kui dapp) ületanud ajaloolise piiri 1000 tähte GitHubis — loodame, et kasvav kasutajate kogukond muudab paljude DevOps inseneride elu lihtsamaks.

Nii et, tutvustame ettekande videot (~47 minutit, oluliselt informatiivsem kui artikkel) ja selle põhisisu tekstivormis. Alustame!

Koodi kohaletoimetamine Kubernetesesse

Ettekanne ei käsitle enam werfi, vaid CI/CD-d Kuberneteses, eeldades, et meie tarkvara on pakitud Docker-konteineritesse (sellest rääkisin ma 2016. aasta ettekandes), ja K8s kasutatakse selle tootmisse viimisel (sellest - 2017. aastal).

Kuidas näeb välja kohaletoimetamine Kubernetesesse?

On Git-repos, kus on kood ja selle koostamiseks vajalikud juhised. Rakendus kogutakse Docker-pildiks ja avaldatakse Docker Registry's.
Samuti on samas repos juhised rakenduse kohaletoimetamiseks ja käitamiseks. Täienduse etapis saadetakse need juhised Kubernetesesse, mis saab vajalikku pilti registry'st ja käivitab selle.
Ja tavaliselt on olemas ka testid. Mõningaid teste saab käivitada pildi avaldamise ajal. Samuti saab (neid samu juhiseid kasutades) luua rakenduse koopia (eraldi K8s nimespaces või eraldi klastris) ja testida seal.
Lõpuks on vaja CI-süsteemi, mis saab sündmusi Git'ist (või nuppude vajutamisest) ja kutsub välja kõik määratud etapid: build, publish, deploy, test.

Siin on mitu olulist tähelepanekut:

Kuna meil on muutumatu infrastruktuur (immutable infrastructure), peab rakenduse pilt, mida kasutatakse kõigis etappides (staging, tootmine jne), olema üks. Selle kohta rääkisin ma põhjalikumalt koos näidistega siin.
Kuna me järgime lähenemist infrastruktuur kui kood (IaC), rakenduskood, juhised selle koostamiseks ja käitamiseks peavad olema just selles ühes repos. Selle kohta - vt samast ettekandest.
Kohaletoimetamise ahel (delivery) meie näeme seda tavaliselt nii: rakendus on kokku pandud, testitud ja välja antud (väljaandmise etapp) ja kõik — kohaletoimetamine on toimunud. Kuid tegelikult saab kasutaja selle, mis te välja andsite, ei sel hetkel, kui te selle tootmiseni toimetasite, ja millal ta sai sinna sisse logida ning see tootmine töötas. Seega arvan, et kohaletoimetamise ahel lõppeb ainult ekspluateerimise etapis (käitus), ja täpsemalt isegi siis, kui kood kõrvaldati tootmisest (asendades selle uuega).

Naaseme varem nimetatud kohaletoimetamise skeemi juurde Kuberneteses: selle lõid mitte ainult meie, vaid ka praktiliselt igaüke, kes selle probleemiga tegeleb. Selle mustrit nimetatakse praegu GitOps (selle termini ja selle taga olevate ideede kohta saab lugeda siin). Vaatame skeemi etappe.

Kogumise etapp

Tundub, et 2019. aastal ei ole midagi uut rääkida Docker-imaid kogumise kohta, kuna kõik oskavad kirjutada Dockerfile'e ja neid käivitada. docker build?.. Вот нюансы, на которые хотелось бы обратить внимание:

Pildi kaal on oluline, seega kasutage multi-stage, et jätta pildis alles ainult see, mis on tegelikult rakenduse toimimiseks vajalik.
Kihtide arvu tuleb minimeerida, ühendades mõtteliselt seotud KÄIVITA-käskluste jadad.
Kuid see toob kaasa probleeme silumisega, kuna tõrgete korral tuleb tuvastada täpselt see käsklus jadast, mis probleemi põhjustas.
Koostamise kiirus on oluline, sest soovime kiiresti muudatusi välja anda ja tulemust vaadata. Näiteks ei taha me igal rakenduse koostamisel sõltuvusi ümber koostada.
Sageli on ühest Git-repositooriumist vajalik palju pilte, mis saab lahendada Dockerfile'ide komplektiga (või ühes failis määratletud etappidega) ja Bash-skriptiga nende järjestikuseks koostamiseks.

See oli vaid jäämäe tipp, millega kõik silmitsi seisavad. Kuid olemas on ka teised probleemid, nimelt:

Sageli on selle koostamise etapis meil vaja midagi mäMountida (näiteks, salvestada apt-käskluse tulemused eraldi katalooge).
Me soovime Ansible asemel, et kirjutada shellis.
Me soovime koostada ilma Dockerita (miks meil on vaja lisavirtuaalmasinat, millele kõik selle jaoks seadistada, kui meil on juba Kubernetes klaster, kus saab konteinerit käivitada?).
Paralleelne kogu, mida võib tõlgendada erinevalt: erinevad käsklused Dockerfile'is (kui kasutatakse multi-stage'i), mitmed sama repo commit'id, mitmed Dockerfile'id.
Jaotatud koostamine: me tahame koguda midagi pod'ides, mis on "efemerid", kuna neil kaob cache, seega tuleb see kuhugile eraldi salvestada.
Lõpuks nimetasin soovide tippu automagiks: oleks ideaalne sisse logida hoidlasse, sisestada mingi käsk ja saada valmis pilt, mis on kokku pandud arusaamisega, kuidas ja mida õigesti teha. Siiski, isiklikult ei ole ma kindel, et kõiki nuansse saab nii ettenähtud.

Ja siin on projektid:

moby/buildkit — koostaja ettevõttelt Docker Inc (juba integreeritud aktuaalsetesse Docker'i versioonidesse), mis püüab lahendada kõik need probleemid;
kaniko — koostaja Google'ilt, mis võimaldab kokku panna ilma Dockerita;
Buildpacks.io — CNCF katse teha automagiat ja eelkõige huvitav lahendus rebase'i jaoks kihtide jaoks;
ja veel hulk teisi tööriistu, nagu buildah, genuinetools/img…

… ja vaadake, kui palju neil on tähti GitHubis. Seega, ühelt poolt, docker build on olemas ja nad võivad midagi teha, kuid tegelikult küsimus pole täielikult lahendatud — tõestuseks sellele on mitme alternatiivse koostaja parallelne arendamine, igaühel neist on oma osa probleemide lahendamiseks.

Koostamine werf'is

Nii jõudsime werf (varem kuulsast nagu dapp) — Open Source tööriist ettevõttelt "Flant", mille loomisega tegeleme juba palju aastaid. Kõik algas umbes 5 aastat tagasi Bash-skriptidest, mis optimeerisid Dockerfile'ide koostamist, ja viimased 3 aastat on käinud täiemahuline arendus ühe projekti raames oma Git repo'l. (esialgu Ruby's, aga siis ümber kirjutatud Go's, ja ühtlasi ümber nimetatud). Milliseid koostamise küsimusi on werf lahendanud?

Siniseks värvitud probleemid on juba rakendatud, paralleelne koostamine on tehtud ühe hosti raames, ja kollasega esile tõstetud küsimused plaanime lõpetada suve lõpuks.

Registreerimisse (publish) etapp

Sisse laaditud docker push… — mis võib olla keeruline, et laadida pilt registreerimisse? Ja siis tekib küsimus: „Millise sildi peaks pildile panema?” See tekib seetõttu, et meil on Gitflow (või strateegia Git'ist) ja Kubernetes, ning tööstus püüdleb selle poole, et Kuberneteses toimu meie Git'iga kooskõlas. Sest Git on meie ainus tõe allikas.

Mis selles keerulist on? Tagada korduv kasutatavust: Git commitist, kellel on olemuslikult muutumatu (muutumatuna), kuni Docker pildini, mida tuleb säilitada samana.

Meile on samuti oluline määratleda päritolu, kuna me tahame mõista, millisest commit'ist on kokku pandud rakendus, mis on käivitatud Kuberneteses (siis saame teha diff'e ja sarnaseid asju).

Sildistamise strateegiad

Esimene on lihtne git tag. Meil on registri pilt, mida on silti pandud nagu 1.0. Kubernetes'is on etapp ja tootmine, kuhu see pilt on välja veetud. Git'is teeme commit'e ja mingil hetkel paneme sildi 2.0. Kogume selle vastavalt repo juhistele ja paneme registrisse sildiga 2.0. Välja veame etapis ja, kui kõik on korras, siis tootmisse.

Selle lähenemise probleem on see, et me panime kõigepealt sildi ja alles siis testisime ja väljastasime. Miks? Esiteks, see on lihtsalt ebatavaline: me väljastame versiooni tarkvarast, mida me isegi ei ole kontrollinud (me ei saa teisiti, kuna testi tegemiseks tuleb silt panna). Teiseks, see tee ei ühildu Gitflow'ga.

Teine variant on git commit + tag. Master-haru on olemas silt 1.0; selle jaoks registris on pilt, mis on välja veetud tootmisse. Lisaks on Kubernetes'i klastris preview ja staging kontuurid. Edasi järgime Gitflow't: peaharu arendamiseks (develop) loome uusi funktsioone, millega tekib commit identifikaator #c1. Kogume selle ja avaldame registrisse, kasutades seda identifikaatorit (#c1). Sama identifikaatoriga väljastame preview'l. Sarnast teeme commit'idega #c2 ja #c3.

Kui oleme aru saanud, et funktsioone on piisavalt, hakkame kõike stabiliseerima. Git'is loome haru release_1.1 (põhjal #c3 API-s develop). Selle väljaande kogumist ei ole vaja, kuna see tehti eelmisel etapil. Seetõttu võime selle lihtsalt staging'ile välja anda. Parandame vead #c4 ja samamoodi väljastame staging'ile. Samal ajal käib paralleelselt arendus develop, kuhu perioodiliselt kantakse muudatusi release_1.1. Ühel hetkel saame kokku pandud ja staging'ile välja antud commit'i, millega oleme rahul (#c25).

Siis teeme merge'i (kiirelt edasiviimisega) väljalaske harust (release_1.1) masterisse. Paneme sellele commit'ile sildi uue versiooniga (1.1). Kuid see pilt on juba registris kokku pandud, seega, et seda uuesti kokku ei pandaks, lisame lihtsalt teise sildi juba olemasolevale pildile (nüüd on see registris silti #c25 ja 1.1). Pärast seda väljastame selle tootmisse.

On puudus, et staging'ile on välja veetud üks pilt (#c25), ja tootmisse on välja veetud justkui teine (1.1), kuid me teame, et „füüsiliselt” on see sama registreerimise pilt.

Kuid tegelik miinus on see, et merge commit'e ei toetata, tuleb teha kiire edasiviimine.

Saame edasi minna ja teha trikki… Vaadakem lihtsa Dockerfile 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 põhimõtte kohaselt, et võtame:

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

… ja võtame kontrollsumma (uuesti SHA256) sellisest failist. See on allkiri kõik, mis määratleb Docker-pildi sisu.

Tagasi skeemi juurde ja kasutame commit'ide asemel selliseid allkirju, s.t. märgistame pilte allkirjadega.

Nüüd, kui on vaja näiteks muutusi väljalaskest master'isse, saame teha tõelise merge commit'i: sellel on erinev identifikaator, kuid sama allkiri. Samasuguse identifikaatoriga viime pildi tootmisesse.

Puuduseks on see, et nüüd ei saa määrata, milline commit on tootmises — kontrollsummad töötavad ainult ühes suunas. See probleem lahendatakse täiendava metainfoki kihiga — räägin sellest hiljem.

Märgistamine werfis

Werfis oleme läinud veel kaugemale ja valmistasime ette jaotatud ehituse, mille vahemälu ei asu ühel masinal… Seega genereerime kahte tüüpi Docker-pilte, mida nimetame stage ja image.

Git-repositooriumis werf hoitakse spetsiifilisi juhiseid ehitamiseks, mis kirjeldavad erinevaid ehitusetappe (beforeInstall, install, beforeSetup, setup). Esimene stage-pilt luuakse allkirjaga, mis on määratletud esialgsete sammude kontrollsummana. Seejärel lisame lähtekoodi, uue stage-pildi jaoks arvutame selle kontrollsumma… Need toimingud korduvad kõigis etappides, mille tulemusena saame komplekti stage-piltidest. Seejärel loome lõpliku image-pildi, mis sisaldab ka selle päritolu metainfot. Ja just seda pilti me märgistame erinevate viisidega (detailid hiljem).

Laske, et pärast seda tekib uus commit, kus on muudetud ainult rakenduse koodi. Mis juhtub? Koodi muutuste jaoks luuakse patch, uue stage-image'i valmistamiseks. Selle allkiri määratakse vanade stage-image'i ja uue patši kontrollsummana. Sellest pildist vormitakse uus lõplik image.

Nii on stage-image'd - vahemälu, mida saab salvestada jaotatult, ja sellest loodud image'id laaditakse Docker Registry'sse.

Registry puhastamine

Räägime mitte kihtide eemaldamisest, mis on jäänud hõljuvaks pärast kustutatud silte - see on Docker Registry enda standardne funktsioon. Jutt on olukorrast, kus akumuleerub palju Docker-silte ja me mõistame, et osa neist pole meile enam vajalik, aga nad võtavad ruumi (ja/või me maksame selle eest).

Milliseid puhastamisstrateegiaid on?

Võib lihtsalt mitte midagi puhastada. Mõnikord on tõesti lihtsam maksta natuke üleliigse ruumi eest, kui harutada lahti tohutult sildistatud kimbu. Kuid see töötab ainult teatud hetkeni.
Täielik lähtestamine. Kui kustutada kõik pildid ja uuesti koostada ainult asjakohased CI-süsteemis, võib tekkida probleem. Kui tootmises konteiner taaskäivitub, laaditakse sellele uus pilt - selline, mida pole veel keegi testinud. See tapab mõtte immutable infrastructure'ist.
Blue-green. Kui üks registry hakkas üle koormama - laadime pildid teise. Sama probleem, mis eelmisel meetodil: millal saab seda registry't, mis hakkas üle koormama, puhastada?
Aja järgi. Kustutada kõik pildid, mis on vanemad kui 1 kuu? Aga kindlasti on olemas teenus, mis pole terve kuu uuendatud…
Käsitsi määrata, mida saab juba eemaldada.

Tõeliselt elujõulisi variante on kaks: mitte puhastada või kombinatsioon blue-green + käsitsi. Viimase puhul on juttu järgmistest asjadest: kui mõistate, et on aeg registrit puhastada, loote uue ja lisate kõik uued pildid sellesse, näiteks kuu aega. Ja kuu pärast vaatate, millised pod'id Kuberneteses ikka veel kasutavad vana registrit ja viite need ka uude registrisse.

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

Git head: kõik sildid, kõik harud — eeldades, et kõik, mis on Git'is silte saanud, peab olema ka piltides (kui ei, siis tuleb need Git'ist eemaldada);
kõik pod'id, mis on praegu Kubernetesesse tõmmatud;
vanad ReplicaSet'id (mis just hiljuti tõmmati), samuti plaanime skaneerida Helm-väljaandeid ja valida sealt viimased pildid.

... ja teeme sellest komplektist whitelist — nimekirja piltidest, mida me ei kustuta. Kõik muu puhastame, pärast mida leiame orvud stage-pildid ja kustutame need samuti.

Deploy'e etapp

Usaldusväärne deklaratiivsus

Esimene punkt, millele sooviksin tähelepanu juhtida deploy'e osas, on värskendatud ressursside konfiguratsiooni väljalatku minek, mis on kuulutatud deklaratiivselt. Originaalne YAML-dokument Kubernetes'i ressursside kirjelduseks erineb alati oluliselt tulemusest, mis tegelikult klastris töötab. Sest Kubernetes lisab konfiguratsiooni:

tuvastid;
teenuseteabe;
palju vaikimisi väärtusi;
osa praeguse staatuse kohta;
muudatused, mis on tehtud vastuvõtu veebirakenduse töö käigus;
erinevate kontrollere (ja planeerija) töö tulemused.

Seega, kui ilmub uus ressursi konfiguratsioon (uus), ei saa me lihtsalt olemasolevat, 'elavat' konfiguratsiooni (live) selle asemel kirjutada. Selleks peame me võrdlema uus eelnevalt rakendatud konfiguratsiooniga (last-applied) ja peame peale pressima live saadud patši.

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

On olemas ka 3-way merge, mille erinevus on see, et:

võrreldes last-applied ja uus, vaatame, mis on eemaldatud;
võrreldes uus ja live, vaatame, mis on lisatud või muudetud;
kumulatiivne patch kantakse live.

Me deployime 1000+ rakendust Helmiga, seega elame tegelikult 2-way merge'i režiimis. Sellega on aga mitmeid probleeme, mille oleme lahendanud oma plaastritega, mis aitavad Helm'il korralikult töötada.

Tegelik väljalaskmise seisund

Pärast seda, kui meie CI-süsteem on genereerinud uue konfiguratsiooni Kubernetes'ile järgmise sündmuse käigus, edastab see selle rakendamiseks (apply) klastrisse — Helm'i või kubectl applyabil. Edasi käib juba kirjeldatud N-way merge, millele Kubernetes API vastab CI-süsteemile heakskiiduga, ja see omakorda oma kasutajale.

Kuid on tohutu probleem: nimelt edukas rakendamine ei tähenda edukat väljalaskmist.. Kui Kubernetes mõistab, millised muutused tuleb rakendada, rakendab ta need — me ei tea veel, mis tulemusena välja tuleb. Näiteks võib esimeses etapis pod'ide uuendamine ja taaskäivitamine ühel pool õnnestuda, samas kui taustaprotsessis mitte, ja saame rakenduse käitamiseks erinevaid versioone.

Ette, et kõik õigesti teha, vajab see skeem täiendavat elementi — spetsiaalset jälgijat, mis saab Kubernetes API-lt teavet oleku kohta ja edastab selle edasiseks analüüsiks tegeliku olukorra kohta. Oleme loonud avatud lähtekoodiga teegid Go keeles — kubedog (vt selle teadaannet siin), — mis lahendab selle probleemi ja on integreeritud werf-iga.

Selle jälgija käitumist werf tasemel saab seadistada annotatsioonide abil, mis on määratud Deployments või StatefulSets. Peamine annotatsioon on fail-mode — mõistab järgmist väärtust:

IgnoreAndContinueDeployProcess — ignoreerime selle komponendi juurutamise probleeme ja jätkame juurutamist;
FailWholeDeployProcessImmediately — vea tekkimine selles komponendis peatab juurutamisprotsessi;
HopeUntilEndOfDeployProcess — loodame, et see komponent töötab juurutamise lõpuks.

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

Kui deployime esimest korda, ei pruugi andmebaas (MongoDB) veel valmis olla — Deployment'id kukuvad. Kuid võime oodata hetke, et see käivituks, ja deploy siiski õnnestub.

Werf-is on veel kaks annotatsiooni kubedogi jaoks:

failures-allowed-per-replica — lubatud kokkuvarisemiste arv iga koopia kohta;
show-logs-until — reguleerib hetke, kuni mille jooksul werf kuvab (stdout'is) logisid kõigist välja lastud pod'idest. Vaikimisi on see PodIsReady (et ignoreerida sõnumeid, mis tõenäoliselt ei ole meile vajalikud, kui pod hakkab liiklust saama), kuid lubatavad on ka väärtused ControllerIsReady ja EndOfDeploy.

Mida veel tahame juurutamiselt?

Peale juba kirjeldatud kahest punktist soovime:

näha logisid — ja ainult vajalikke, mitte kõikide teiste;
välja selgitada edusamme, sest kui töö "vaikselt" ripub mitu minutit, on oluline mõista, mis seal toimub;
omada automaatset tagasivõtmist juhtudel, kui midagi läheb valesti (ja seega on kriitiline teada juurutamise tegelikku staatust). Juurutamine peab olema atomaarne: kas see läheb lõpuni või kõik naaseb eelnevasse olekusse.

Summary

Meie ettevõttena on nende erinevate raamistikus etappide (build, publish, deploy) läbiviimiseks piisav CI-süsteem ja tööriist werf.

Kokkuvõtteks:

Werf-i abil oleme saavutanud palju DevOps-inseneride probleemide lahendamisel ning oleksime rõõmsad, kui laiem kogukond vähemalt prooviks seda tööriista praktikas. Häid tulemusi on koos saavutada lihtsam.