Maiatzaren 27an DevOpsConf 2019 jardunaldiko areto nagusian, jaialdiaren baitan , “Etengabeko Bidalketa” atalaren barruan, “werf - Kubernetes-en CI/CDrako gure tresna” txosten bat eman zen. Horiei buruz hitz egiten du Kubernetes-en inplementatzean denek izaten dituzten arazoak eta erronkak, baita berehala nabarituko ez diren ñabardurei buruz ere. Irtenbide posibleak aztertuta, hau Kode Irekiko tresna batean nola inplementatzen den erakusten dugu .
Aurkezpenetik, gure erabilgarritasuna (lehen dapp izenez ezagutzen zena) mugarri historiko batera iritsi da 1000 izar GitHub-en — Espero dugu gero eta handiagoa den erabiltzaileen komunitatea DevOps ingeniari askori bizitza erraztuko diela.
Beraz, aurkez ditzagun (~ 47 minutu, artikulua baino askoz informazio gehiago) eta haren laburpen nagusia testu moduan. Joan!
Kubernetes-i kodea ematea
Hitzaldia ez da gehiago werf-i buruz izango, Kubernetes-en CI/CDari buruz baizik, gure softwarea Docker ontzietan ontziratuta dagoela esan nahi du. (Horri buruz hitz egin nuen ), eta K8ak erabiliko dira ekoizpenean exekutatzeko (honi buruz gehiago in ).
Nolakoa da entrega Kubernetes-en?
- Git biltegi bat dago eraikitzeko kodea eta argibideak dituena. Aplikazioa Docker irudi batean dago eta Docker Erregistroan argitaratzen da.
- Biltegi berean aplikazioa zabaldu eta exekutatzeko argibideak ere baditu. Inplementazio fasean, argibide hauek Kubernetesera bidaltzen dira, honek erregistrotik nahi den irudia jaso eta abiarazten du.
- Gainera, probak egon ohi dira. Horietako batzuk irudi bat argitaratzean egin daitezke. Era berean, (argibide berberak jarraituz) aplikazioaren kopia bat zabaldu dezakezu (K8s izen-espazio bereizi batean edo aparteko kluster batean) eta bertan probak exekutatu ditzakezu.
- Azkenik, Git-en gertaerak (edo botoien klikak) jasotzen dituen CI sistema bat behar duzu eta izendatutako fase guztiei dei egiten diena: eraiki, argitaratu, zabaldu, probatu.
Hemen ohar garrantzitsu batzuk daude:
- Azpiegitura aldaezina dugulako (azpiegitura aldaezina), fase guztietan erabiltzen den aplikazioaren irudia (eszenaratzea, ekoizpena, etab.), bat egon behar da. Honi buruz zehatzago eta adibideekin hitz egin nuen. .
- Azpiegitura kodearen ikuspegi gisa jarraitzen dugulako (IaC), aplikazioaren kodea, muntatzeko eta abiarazteko argibideak izan beharko luke zehazki biltegi batean. Honi buruzko informazio gehiagorako, ikus .
- Entrega-katea (entrega) normalean horrela ikusten dugu: aplikazioa muntatu, probatu, kaleratu zen (askatze fasea) eta kitto - entrega egin da. Baina, egia esan, erabiltzaileak zuk zabaldutakoa lortzen du, ez gero produkziora entregatu zenuenean, eta hara joan ahal izan zenean eta ekoizpen honek funtzionatu zuen. Beraz, entrega-katea amaitzen dela uste dut operazio fasean bakarrik (Korrika egin), edo zehatzago esanda, kodea ekoizpenetik kendu zen momentuan ere (berri batekin ordezkatuz).
Itzul gaitezen Kubernetes-en goiko entrega-eskemara: guk asmatu ez ezik, arazo honi aurre egin zioten guztiek ere asmatu zuten. Izan ere, eredu honi GitOps deitzen zaio orain (Terminoari eta horren atzean dauden ideiei buruz gehiago irakur dezakezu ). Ikus ditzagun eskemaren faseak.
Eraiki etapa
Badirudi 2019an Docker irudiak eraikitzeari buruz hitz egin dezakezula, denek dakitenean Dockerfiles idazten eta exekutatzen docker build?.. Hona hemen arreta jarri nahiko nituzkeen ñabardurak:
- Irudiaren pisua kontuak, beraz, erabili irudian funtzionamendurako benetan beharrezkoa den aplikazioa soilik uztea.
- Geruza kopurua kateak konbinatuz minimizatu behar dira
RUN-aginduak esanahiaren arabera. - Hala ere, horrek arazoak gehitzen ditu arazketa, muntaia huts egiten denean, arazoa sortu duen katearen komando egokia aurkitu behar duzulako.
- Muntatzeko abiadura garrantzitsua da aldaketak azkar zabaldu eta emaitzak ikusi nahi ditugulako. Esate baterako, ez dituzu hizkuntza-liburutegietako mendekotasunak berreraiki nahi aplikazio bat eraikitzen duzun bakoitzean.
- Askotan behar duzun Git biltegi batetik irudi asko, Dockerfiles multzo batek (edo fitxategi batean izendatutako etapak) eta Bash script baten bidez ebatzi daitezkeen muntaketa sekuentzialarekin.
Hau denek jasaten duten icebergaren punta besterik ez zen. Baina badira beste arazo batzuk, bereziki:
- Askotan muntaketa fasean zerbait behar dugu muntatu (adibidez, gorde apt bezalako komando baten emaitza hirugarrenen direktorio batean).
- Nahi dugu Ansible oskoletan idatzi beharrean.
- Nahi dugu Docker gabe eraiki (zergatik behar dugu makina birtual gehigarri bat, zeinetan dena konfiguratu behar dugun horretarako, dagoeneko edukiontziak exekutatu ditzakegun Kubernetes kluster bat dugunean?).
- Muntaketa paraleloa, modu ezberdinetan uler daitekeena: Dockerfile-ko komando desberdinak (etapa anitzekoa erabiltzen bada), biltegi bereko hainbat konpromezu, hainbat Dockerfile.
- Banatutako muntaia: "Efimeroak" diren gauzak leketan bildu nahi ditugulako haien cachea desagertzen da, hau da, nonbait bereizita gorde behar da.
- Azkenik, desioen gailurra izendatu nuen automagia: aproposa litzateke biltegira joatea, komandoren bat idatzi eta prest egindako irudi bat lortzea, nola eta zer egin behar den ondo ulertuta muntatuta. Hala ere, pertsonalki ez nago ziur ñabardura guztiak horrela aurreikus daitezkeenik.
Eta hona hemen proiektuak:
- — Docker Inc-eko eraikitzailea (dagoeneko Dockerren egungo bertsioetan integratua), arazo horiek guztiak konpontzen saiatzen ari dena;
- — Dockerrik gabe eraikitzeko aukera ematen duen Google-ren eraikitzailea;
- — CNCFren magia automatikoa egiteko saiakera eta, bereziki, geruzetarako birbasea duen irtenbide interesgarri bat;
- eta beste utilitate mordo bat, esaterako , ...
...eta begira zenbat izar dituzten GitHub-en. Hau da, alde batetik, docker build existitzen da eta zerbait egin dezake, baina errealitatean arazoa ez dago guztiz konponduta - Horren froga bilduma alternatiboen garapen paraleloa da, bakoitzak arazoen zatiren bat ebazten baitu.
Batzarra werfean
Beraz, lortu dugu (lehenago dapp bezala) — Flant konpainiaren kode irekiko utilitate bat, urte asko daramatzaguna egiten. Dena duela 5 urte hasi zen Bash script-ekin Dockerfiles-en muntaia optimizatuz, eta azken 3 urteotan garapen osoa egin da Git biltegi propioa duen proiektu baten esparruan. (lehenengo Ruby-n, eta gero to Go, eta aldi berean izena aldatu). Zein muntaia arazo konpontzen dira werf-en?
Urdinez itzalduta dauden arazoak jada ezarrita daude, eraikuntza paraleloa ostalari beraren barruan egin zen eta horiz nabarmendutako gaiak uda amaierarako amaitzea aurreikusten da.
Erregistroan argitaratzeko fasea (argitaratu)
Markatu genuen docker push... - zer izan daiteke zaila irudi bat erregistrora igotzeak? Eta orduan galdera sortzen da: "Zer etiketa jarri behar diot irudiari?" Daukagun arrazoiagatik sortzen da Gitflow (edo beste Git estrategia) eta Kubernetes, eta industria Kubernetesen gertatzen dena Git-en gertatzen dena jarraitzen duela ziurtatzen saiatzen ari da. Azken finean, Git da gure egia iturri bakarra.
Zer da horren zaila? Erreproduzigarritasuna bermatu: Git-eko konpromezu batetik, izaera aldaezina dena (aldaezina), Docker irudi batera, berdin mantendu behar dena.
Guretzat ere garrantzitsua da jatorria zehaztu, Kubernetesen exekutatzen ari den aplikazioa zein konprometitutik eraiki den ulertu nahi dugulako (gero desberdintasunak eta antzekoak egin ditzakegu).
Etiketatze-estrategiak
Lehenengoa sinplea da git etiketa. Erregistro bat dugu etiketatutako irudi batekin 1.0. Kubernetes-ek eszenatokia eta ekoizpena ditu, non irudi hau kargatzen den. Git-en konpromisoak egiten ditugu eta noizbait etiketatzen dugu 2.0. Biltegiko argibideen arabera biltzen dugu eta erregistroan jartzen dugu etiketarekin 2.0. Oholtzara zabaltzen dugu eta, dena ondo badago, ekoizpenera.
Ikuspegi honen arazoa da lehenengo etiketa jarri genuela, eta gero probatu eta zabaldu genuela. Zergatik? Lehenik eta behin, ilogikoa besterik ez da: oraindik probatu ere egin ez dugun softwarearen bertsio bat jaulkitzen ari gara (ezin dugu bestela egin, egiaztatzeko, etiketa bat jarri behar dugulako). Bigarrenik, bide hau ez da Gitflow-ekin bateragarria.
Bigarren aukera - git commit + etiketa. Adar nagusiak etiketa bat du 1.0; horretarako erregistroan - ekoizpenera zabaldutako irudi bat. Horrez gain, Kubernetes klusterrak aurrebista eta eszenatze ingerada ditu. Jarraian, Gitflow jarraituko dugu: garapenerako adar nagusian (develop) eginbide berriak egiten ditugu, identifikatzailearekin konpromisoa sortuz #c1. Identifikatzaile honen bidez biltzen dugu eta erregistroan argitaratzen dugu (#c1). Identifikatzaile berarekin aurrebistara zabalduko dugu. Gauza bera egiten dugu konpromisoekin #c2 и #c3.
Ezaugarri nahikoak daudela konturatu garenean, dena egonkortzen hasten gara. Sortu adar bat Git-en release_1.1 (oinarrian #c3 - develop). Ez dago argitalpen hau bildu beharrik, zeren... hau aurreko urratsean egin zen. Hori dela eta, eszenaratzera zabaldu dezakegu. Akatsak konpontzen ditugu #c4 eta era berean eszenaratzera zabaldu. Aldi berean, garapena abian da develop, non aldaketak aldian-aldian hartzen diren release_1.1. Noizbait, konpromezu bat konpilatu eta eszenaratzera igotzen dugu, eta pozik gaude (#c25).
Ondoren, batu egiten dugu (aurrera bizkor batekin) oharra adarra (release_1.1) maisuan. Konpromiso honetan bertsio berriarekin etiketa bat jarri dugu (1.1). Baina irudi hau dagoeneko erregistroan bilduta dago, beraz, berriro ez biltzeko, bigarren etiketa bat gehitzen diogu lehendik dagoen irudiari (orain etiketak ditu erregistroan. #c25 и 1.1). Horren ostean, ekoizpenera zabaltzen dugu.
Eragozpen bat dago eszenaratzera irudi bakarra kargatzen dela (#c25), eta ekoizpenean ezberdina da (1.1), baina badakigu "fisikoki" hauek erregistroko irudi bera direla.
Benetako desabantaila da ez dagoela bateratze-konpromisoetarako laguntzarik, aurrera egin behar duzula.
Harago joan gaitezke eta trikimailu bat egin... Ikus dezagun Dockerfile sinple baten adibide bat:
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/publicEraiki dezagun fitxategi bat bertatik printzipio honen arabera:
- SHA256 erabilitako irudien identifikatzaileetatik (
ruby:2.3иnginx:alpine), beren edukien kontrol-sumoak dira; - talde guztiak (
RUN,CMDeta abar.); - SHA256 gehitu ziren fitxategietatik.
... eta hartu checksum (berriro SHA256) fitxategi batetik. Hau sinadura Docker irudiaren edukia definitzen duen guztia.
Itzul gaitezen diagramara eta konpromisoen ordez horrelako sinadurak erabiliko ditugu, hau da. etiketatu irudiak sinadurarekin.
Orain, beharrezkoa denean, adibidez, bertsio batetik masterrerako aldaketak bateratzea, benetako merge commit bat egin dezakegu: beste identifikatzaile bat izango du, baina sinadura bera. Identifikatzaile berarekin irudia ekoizpenera zabalduko dugu.
Desabantaila da orain ezin izango dela zehaztu zer nolako konpromisoa bultzatu den ekoizpenera - checksumek norabide bakarrean funtzionatzen dute. Arazo hau metadatuak dituen geruza gehigarri batek konpontzen du - geroago esango dizut gehiago.
Etiketatzea werf-en
Werf-en haratago joan ginen eta makina batean gordetzen ez den cache batekin banatutako eraikuntza bat egiteko prestatzen ari gara... Beraz, bi Docker irudi mota eraikitzen ari gara, deitzen diegu. etapa и irudia.
Werf Git biltegiak eraikuntzaren fase desberdinak deskribatzen dituzten argibide espezifikoak gordetzen ditu (aurretikInstalatu, instalatzeko, konfiguratu aurretik, konfigurazioa). Lehenengo etapako irudia lehen urratsen checksum gisa definitutako sinadura batekin biltzen dugu. Gero iturburu-kodea gehitzen dugu, etapako irudi berrirako bere checksum kalkulatzen dugu... Eragiketa hauek etapa guztietan errepikatzen dira, eta horren ondorioz etapako irudi multzo bat lortzen dugu. Ondoren, azken irudia egiten dugu, jatorriari buruzko metadatuak ere baditu. Eta irudi hau modu ezberdinetan etiketatzen dugu (aurrerago xehetasunak).
Demagun honen ondoren konpromezu berri bat agertzen dela eta bertan aplikazioaren kodea bakarrik aldatu den. Zer gertatuko da? Kode aldaketetarako, adabaki bat sortuko da eta eszenatokiko irudi berri bat prestatuko da. Bere sinadura eszena-irudi zaharraren eta adabaki berriaren checksum gisa zehaztuko da. Irudi honetatik azken irudi berri bat osatuko da. Antzeko jokaera gertatuko da beste faseetako aldaketekin.
Horrela, etapako irudiak modu banatuan gorde daitezkeen cache bat dira, eta hortik dagoeneko sortutako irudiak Docker Erregistrora igotzen dira.
Erregistroa garbitzea
Ez gara ezabatu etiketen ondoren zintzilik geratu ziren geruzak ezabatzeaz ari - hau Docker Erregistroaren ezaugarri estandarra da. Docker etiketa asko pilatzen diren eta horietako batzuk jada behar ez ditugula ulertzen dugun egoeraz ari gara, baina lekua hartzen dutela (eta/edo guk ordaintzen dugu).
Zeintzuk dira garbiketa estrategiak?
- Ezin duzu ezer egin ez garbitu. Batzuetan, oso errazagoa da leku gehigarri bat ordaintzea etiketa nahasketa handi bat argitzea baino. Baina honek puntu jakin batera baino ez du funtzionatzen.
- Berrezarri osoa. Irudi guztiak ezabatzen badituzu eta CI sisteman oraingoak soilik berreraikitzen badituzu, arazo bat sor daiteke. Edukiontzia produkzioan berrabiarazten bada, irudi berri bat kargatuko da, oraindik inork probatu ez duena. Horrek azpiegitura aldaezinaren ideia hiltzen du.
- Urdin-berdea. Erregistro bat gainezka hasi zen - irudiak beste batera igotzen ditugu. Aurreko metodoaren arazo bera: zein momentutan garbitu dezakezu gainezka hasi den erregistroa?
- Denboraren arabera. Hilabete baino zaharragoak diren irudi guztiak ezabatu nahi dituzu? Baina, zalantzarik gabe, hilabete bat eguneratu gabe dagoen zerbitzu bat egongo da...
- eskuz zehaztu zer dagoeneko ezabatu daitekeen.
Bi aukera benetan bideragarriak daude: ez garbitu edo urdin-berdea + eskuz konbinatzea. Azken kasu honetan, honetaz ari gara: erregistroa garbitzeko garaia dela ulertzen duzunean, berri bat sortu eta irudi berri guztiak gehitzen dizkiozu, adibidez, hilabetean zehar. Eta hilabete igaro ondoren, ikusi Kubernetes-en zein pods-ek oraindik erregistro zaharra erabiltzen ari diren, eta transferitu horiek ere erregistro berrira.
Zertara heldu gara werf? biltzen dugu:
- Git burua: etiketa guztiak, adar guztiak - irudietan Git-en etiketatuta dagoen guztia behar dugula suposatuz (eta ez bada, Git-en bertan ezabatu beharko dugu);
- Gaur egun Kubernetesera ponpatzen diren lek guztiak;
- ReplicaSets zaharrak (duela gutxi kaleratu zena), eta Helm-en bertsioak eskaneatu eta bertan azken irudiak hautatzeko asmoa dugu.
... eta egin zerrenda zuri bat multzo honetatik - ezabatuko ez ditugun irudien zerrenda. Gainerako guztia garbitzen dugu, ondoren eszena-irudi umezurtzak aurkitzen ditugu eta horiek ere ezabatzen ditugu.
Inplementatu etapa
Adierazpen fidagarria
Inplementazioan arreta jarri nahi nukeen lehen puntua baliabideen konfigurazio eguneratua zabaltzea da, deklaratiboki deklaratua. Kubernetes baliabideak deskribatzen dituen YAML jatorrizko dokumentua klusterean benetan exekutatzen den emaitzatik oso desberdina da beti. Kubernetes-ek konfigurazioari gehitzen diolako:
- identifikatzaileak;
- zerbitzuaren informazioa;
- balio lehenetsi asko;
- egungo egoera duen atala;
- onarpen webhook-aren barruan egindako aldaketak;
- hainbat kontrolatzaileren (eta programatzailearen) lanaren emaitza.
Hori dela eta, baliabideen konfigurazio berri bat agertzen denean (berria), ezin dugu egungo konfigurazioa "zuzenekoa" hartu eta gainidatzi berarekin (bizi). Horretarako alderatu beharko dugu berria aplikatutako azken konfigurazioarekin (azken-aplikatua) eta jaurti bizi adabakia jaso.
Planteamendu honi deitzen zaio 2 norabideko batzea. Helm-en erabiltzen da, adibidez.
Badago ere 3 norabideko batzea, eta horrek ezberdintzen du:
- alderatuz azken-aplikatua и berria, ezabatu zenari begiratzen diogu;
- alderatuz berria и bizi, zer gehitu edo aldatu den ikusten dugu;
- batutako adabakia aplikatzen zaio bizi.
Helm-ekin 1000 aplikazio baino gehiago inplementatzen ditugu, beraz, bi norabideko uztarketarekin bizi gara. Hala ere, gure adabakiekin konpondu ditugun hainbat arazo ditu, Helm-i normaltasunez funtzionatzen laguntzen dutenak.
Benetako zabaltze-egoera
Gure CI sistemak hurrengo gertaeran oinarrituta Kubernetesentzako konfigurazio berri bat sortu ondoren, erabiltzeko transmititzen du (aplikatu) kluster batera - Helm edo erabiliz kubectl apply. Ondoren, lehendik deskribatutako N-bideen batzea gertatzen da, eta Kubernetes APIak onespentsu erantzuten dio CI sistemari, eta hori bere erabiltzaileari.
Hala ere, arazo handi bat dago: azken finean aplikazio arrakastatsuak ez du esan nahi inplementatze arrakastatsua. Kubernetes-ek ulertzen badu zer aldaketa aplikatu behar diren eta aplikatzen baditu, oraindik ez dakigu zein izango den emaitza. Adibidez, frontend-eko pods eguneratzea eta berrabiaraztea arrakastatsua izan daiteke, baina backend-ean ez, eta martxan dauden aplikazioen irudien bertsio desberdinak lortuko ditugu.
Dena behar bezala egiteko, eskema honek esteka gehigarri bat behar du: Kubernetes APIaren egoeraren informazioa jasoko duen jarraitzaile berezi bat eta gauzen benetako egoera aztertzeko transmitituko duena. Kode irekiko liburutegi bat sortu dugu Go-n - (ikusi bere iragarkia ), arazo hau konpontzen duena eta werf-ean eraikia.
Jarraitzaile honen portaera werf mailan inplementazioetan edo StatefulSets-etan jartzen diren oharpenen bidez konfiguratzen da. Oharpen nagusia - fail-mode - honako esanahi hauek ulertzen ditu:
-
IgnoreAndContinueDeployProcess— Osagai hau zabaltzeko arazoak baztertu eta zabaltzen jarraitzen dugu; -
FailWholeDeployProcessImmediately— osagai honen errore batek hedapen-prozesua geldiarazten du; -
HopeUntilEndOfDeployProcess— Osagai honek hedapenaren amaieran funtzionatuko duela espero dugu.
Adibidez, baliabideen eta oharpen balioen konbinazio hau fail-mode:
Lehen aldiz zabaltzen dugunean, baliteke datu-basea (MongoDB) oraindik prest ez egotea - Inplementazioak huts egingo du. Baina noiz arte itxaron dezakezu hura hasteko, eta hedapena oraindik ere gauzatuko da.
werf-en kubedog-erako beste bi oharpen daude:
-
failures-allowed-per-replica— erreplika bakoitzeko baimendutako erorketa kopurua; -
show-logs-until— werf-ek (stdout-en) erregistroak erakusten dituen unea arautzen du zabaldutako pod guztietako erregistroak. Lehenetsia daPodIsReady(ziurrenik nahi ez ditugun mezuak alde batera uzteko, trafikoa ontzira hasten denean), baina balioek ere balio dute:ControllerIsReadyиEndOfDeploy.
Zer gehiago nahi dugu hedapenetik?
Lehen azaldutako bi puntuez gain, nahi genuke:
- ikusteko erregistroak - eta beharrezkoak bakarrik, eta ez dena segidan;
- pista aurrerapena, lana hainbat minutuz “isil-isilik” zintzilikatzen bada, garrantzitsua da bertan gertatzen dena ulertzea;
- dute itzulera automatikoa zerbait gaizki joan bada (eta, beraz, funtsezkoa da hedapenaren benetako egoera ezagutzea). Inplementazioak atomikoa izan behar du: edo amaieraraino doa, edo dena aurreko egoerara itzultzen da.
Emaitzak
Guretzat enpresa gisa, deskribatutako ñabardura guztiak entrega-fase desberdinetan ezartzeko (eraiki, argitaratu, zabaldu), CI sistema eta erabilgarritasuna nahikoa dira. .
Ondorio baten ordez:
Werf-en laguntzaz, aurrerapen ona egin dugu DevOps ingeniarientzako arazo ugari konpontzen eta poztuko litzaiguke komunitate zabalak gutxienez erabilgarritasun hau ekintzan probatuko balu. Errazagoa izango da elkarrekin emaitza on bat lortzea.
Bideoak eta diapositibak
Emanaldiko bideoa (~47 minutu):
Txostenaren aurkezpena:
PS
Kubernetes-i buruzko beste erreportaje batzuk gure blogean:
- «» (Dmitry Stolyarov; 27ko apirilaren 2019an "Greba");
- «» (Andrey Polovov; 8ko apirilaren 2019a Saint HighLoad++-n);
- «» (Dmitry Stolyarov; 8ko azaroaren 2018a HighLoad++-n);
- «» (Dmitry Stolyarov; 28ko maiatzaren 2018an RootConf-en);
- «» (Dmitry Stolyarov; 7ko azaroaren 2017a HighLoad++-n);
- «» (Dmitry Stolyarov; 6ko ekainaren 2017an RootConf-en).
Iturria: www.habr.com