Minu nimi on Dmitri Sugrobov, olen Leroy Merlini arendaja. Selles artiklis räägin teile, miks Helmi vaja on, kuidas see Kubernetesega töötamist lihtsustab, mis on kolmandas versioonis muutunud ja kuidas seda kasutada tootmisrakenduste värskendamiseks ilma seisakuta.
Leroy Merlin on DIY jaemüügituru liider Venemaal ja Euroopas. Meie ettevõttel on üle saja arendaja, 33 000 ettevõttesisest töötajat ning tohutul hulgal inimesi, kes külastavad hüpermarketeid ja veebilehte. Nende kõigi õnnelikuks tegemiseks otsustasime järgida tööstusharu standardseid lähenemisviise. Mikroteenuste arhitektuuri abil uute rakenduste arendamine; kasutada konteinereid keskkonna isoleerimiseks ja nõuetekohase kohaletoimetamise tagamiseks; ja kasutage orkestreerimiseks Kubernetest. Orkestrite kasutamise hind odavneb kiiresti: turul kasvab tehnikat valdavate inseneride arv ning Kubernetese teenusena ilmuvad pakkujad.
Kõike, mida Kubernetes teeb, saab muidugi teha ka muul viisil, näiteks kattes skriptidega mõnda Jenkinsit ja docker-composit, aga milleks teha elu keeruliseks, kui on olemas valmis ja töökindel lahendus? Seetõttu tulimegi Kubernetesse ja oleme seda juba aasta aega tootmises kasutanud. Meil on praegu kakskümmend neli Kubernetese klastrit, millest vanim on üle aasta vana, umbes kahesaja kaunaga.
Suurte YAML-failide needus Kubernetesis
Mikroteenuse käivitamiseks Kubernetesis loome vähemalt viis YAML-faili: juurutamise, teenuse, sisenemise, konfiguratsioonikaardi, saladuste jaoks ja saadame need klastrisse. Järgmise rakenduse jaoks kirjutame sama paki lengi, kolmandaga kirjutame teise jne. Kui me korrutame dokumentide arvu keskkondade arvuga, saame juba sadu faile ja see ei võta veel arvesse dünaamilisi keskkondi.
Adam Reese, Helmi põhihooldaja, tutvustas kontseptsiooni "Arendustsükkel Kubernetesis", mis näeb välja selline:
Kopeeri YAML – kopeeri YAML-fail.
Kleepige YAML – kleepige see.
Fix Indents – taande parandamine.
Korda – korda uuesti.
Valik töötab, kuid peate YAML-faile mitu korda kopeerima. Selle tsükli muutmiseks leiutati Helm.
Mis on Helm
Esiteks Helm - paketihaldur, mis aitab teil leida ja installida vajalikke programme. Näiteks MongoDB installimiseks ei pea te minema ametlikule veebisaidile ja alla laadima binaarfaile, vaid käivitage käsk helm install stable/mongodb.
Teiseks, Helm - malli mootor, aitab faile parameetrites määrata. Naaskem Kubernetes YAML-failide olukorra juurde. Lihtsam on kirjutada sama YAML-fail, lisada sellele mõned kohahoidjad, millesse Helm väärtused asendab. See tähendab, et suure tellingute komplekti asemel on komplekt malle, millesse vajalikud väärtused õigel ajal asendatakse.
Kolmandaks, Helm - juurutamise kapten. Sellega saate rakendusi installida, tagasi võtta ja värskendada. Mõtleme välja, kuidas seda teha.
Kuidas kasutada Helmi oma rakenduste juurutamiseks
Installime Helmi kliendi teie arvutisse, järgides ametnikku juhiseid. Järgmisena loome YAML-failide komplekti. Konkreetsete väärtuste täpsustamise asemel jätame kohale kohahoidjad, mida Helm edaspidi infoga täidab. Selliste failide komplekti nimetatakse Helm diagrammiks. Selle saab Helmi konsoolikliendile saata kolmel viisil:
märkige mallidega kaust;
pakkige arhiiv .tar-i ja osutage sellele;
pane mall kaughoidlasse ja lisa Helmi kliendis hoidla link.
Teil on vaja ka väärtustega faili - Values.yaml. Sealt saadud andmed sisestatakse malli. Loome ka selle.
Helmi teisel versioonil on täiendav serverirakendus - Tiller. See ripub väljaspool Kubernetesi ja ootab Helmi kliendi päringuid ning kui seda kutsutakse, asendab see malli nõutavad väärtused ja saadab selle Kubernetesele.
Helm 3 on lihtsam: mallide serveris töötlemise asemel töödeldakse nüüd teavet täielikult Helmi kliendi poolel ja saadetakse otse Kubernetes API-sse. See lihtsustus parandab klastri turvalisust ja hõlbustab levitamisskeemi.
Kuidas see kõik töötab
Käivitage käsk helm install. Märgime rakenduse väljalaske nime ja anname tee väärtusele.yaml. Lõpus märgime hoidla, kus diagramm asub, ja diagrammi nime. Näites on need vastavalt "lmru" ja "bestchart".
Käsku saab täita ainult üks kord, selle asemel uuesti install vaja kasutada upgrade. Lihtsuse huvides saate kahe käsu asemel käsu käivitada upgrade lisavõtmega --install. Esmakordsel käivitamisel saadab Helm käsu versiooni installimiseks ja värskendab seda tulevikus.
Helmiga rakenduse uute versioonide juurutamise lõksud
Selles loos mängin ma publikuga mängu Kes tahab saada miljonäriks ja me mõtleme välja, kuidas saada Helm rakenduse versiooni värskendama. Vaata videot.
Helmi tööpõhimõtet õppides üllatas mind jooksvate rakenduste versioonide värskendamisel kummaline käitumine. Värskendasin rakenduse koodi, laadisin Dockeri registrisse uue pildi, saatsin juurutuskäsu – ja midagi ei juhtunud. Allpool on toodud mõned mitte täiesti edukad viisid rakenduste värskendamiseks. Igaüht neist üksikasjalikumalt uurides hakkate mõistma instrumendi sisemist struktuuri ja selle ebaselge käitumise põhjuseid.
1. meetod. Ärge muutke teavet pärast viimast käivitamist
Nagu öeldakse ametlikul kodulehel Helm: "Kubernetese diagrammid võivad olla suured ja keerulised, nii et Helm püüab mitte midagi liiga palju puudutada." Seetõttu, kui värskendate dockeri registris rakenduse kujutise uusimat versiooni ja käivitate käsu helm upgrade, siis ei juhtu midagi. Helm arvab, et midagi pole muutunud ja rakenduse värskendamiseks pole vaja Kubernetesile käsku saata.
Siin ja allpool kuvatakse uusim silt ainult näitena. Kui määrate selle sildi, laadib Kubernetes pildi dockeri registrist alla iga kord, olenemata parameetrist imagePullPolicy. Uusimate tootmisviiside kasutamine on ebasoovitav ja põhjustab kõrvaltoimeid.
2. meetod. Värskendage pildil LABEL
Nagu samas kirjas dokumentatsioon, "Helm värskendab rakendust ainult siis, kui see on pärast viimast väljalaset muutunud." Selle loogiline valik näib olevat LABEL-i värskendamine dokkeri pildil endal. Helm aga ei uuri rakenduste pilte ega tal aimugi nende muudatustest. Sellest lähtuvalt ei saa Helm pildil siltide värskendamisel neist teada ja Kubernetesile rakenduse värskendamise käsku ei saadeta.
3. meetod: kasutage võtit --force
Pöördume juhendite poole ja otsime üles vajalik võti. Võti on kõige mõttekam --force. Vaatamata ilmselgele nimele on käitumine oodatust erinev. Selle asemel, et sundida rakendust värskendama, on selle tegelik eesmärk taastada versioon, mis on olekuga FAILED. Kui te seda klahvi ei kasuta, peate käsud järjestikku täitma helm delete && helm install --replace. Selle asemel on soovitatav kasutada võtit --force, mis automatiseerib nende käskude järjestikuse täitmise. Lisateavet selles tõmba taotlus. Selleks, et käskida Helmil rakenduse versiooni uuendada, see võti kahjuks ei tööta.
4. meetod. Muutke silte otse Kubernetesis
Sildi värskendamine otse klastris käsuga kubectl edit - halb mõte. See toiming põhjustab teabe vastuolu töötava rakenduse ja algselt juurutamiseks saadetud rakenduse vahel. Helmi käitumine juurutamise ajal erineb sel juhul selle versioonist: Helm 2 ei tee midagi ja Helm 3 juurutab rakenduse uue versiooni. Et mõista, miks, peate mõistma, kuidas Helm töötab.
Kuidas Helm töötab?
Et teha kindlaks, kas rakendus on pärast viimast väljalaskmist muutunud, saab Helm kasutada järgmist:
töötab rakendus Kubernetesis;
uued väärtused.yaml ja praegune diagramm;
Helmi sisemise väljalaske teave.
Uudishimulikumatele: kus Helm väljaannete kohta siseteavet talletab?Käsu täites helm history, saame kogu teabe Helmi abil installitud versioonide kohta.
Samuti on üksikasjalik teave saadetud mallide ja väärtuste kohta. Saame seda taotleda:
Helmi teises versioonis asub see teave samas nimeruumis, kus Tiller töötab (vaikimisi kube-süsteem), ConfigMapis, mis on tähistatud sildiga "OWNER=TILLER":
Helmi kolmanda versiooni ilmumisel liikus teave saladustesse ja samasse nimeruumi, kus rakendus töötas. Tänu sellele sai võimalikuks mitme rakenduse samaaegne käivitamine erinevates nimeruumides sama väljalaske nimega. Teises versioonis oli tõsine peavalu, kui nimeruumid on isoleeritud, kuid võivad üksteist mõjutada.
Teine Helm, püüdes mõista, kas värskendust on vaja, kasutab ainult kahte teabeallikat: seda, mida talle praegu pakutakse, ja sisemist teavet väljaannete kohta, mis asub ConfigMapis.
Kolmas Helm kasutab kolmesuunalist liitmisstrateegiat: lisaks sellele teabele võtab see arvesse ka rakendust, mis praegu Kubernetesis töötab.
Sel põhjusel ei tee Helmi vana versioon midagi, kuna see ei võta klastris olevat rakendusteavet arvesse, kuid Helm 3 võtab muudatused vastu ja saadab uue rakenduse juurutamiseks.
5. meetod. Kasutage lülitit --recreate-pods
Võtmega --recreate-pods võtmega saate saavutada selle, mida algselt plaanisite --force. Konteinerid taaskäivituvad ja vastavalt reeglile imagePullPolicy: Alati uusima märgendi poliitika (selle kohta leiate lisateavet ülaltoodud joonealuses märkuses) laadib Kubernetes alla ja käivitab pildi uue versiooni. Seda ei tehta parimal viisil: juurutamise strateegiatüüpi arvesse võtmata lülitab see järsult välja kõik vanad rakenduse eksemplarid ja alustab uute käivitamist. Taaskäivitamise ajal süsteem ei tööta, kasutajad kannatavad.
Kubernetes endas oli sarnane probleem ka pikka aega. Ja nüüd, 4 aastat pärast avamist Teema, on probleem lahendatud ja alates Kubernetese versioonist 1.15 ilmub kaustade taaskäivitamise võimalus.
Helm lihtsalt lülitab kõik rakendused välja ja käivitab läheduses uued konteinerid. Te ei saa seda teha tootmises, et mitte põhjustada rakenduse seisakuid. Seda on vaja ainult arendusvajaduste jaoks ja seda saab teha ainult lavakeskkondades.
Kuidas värskendada rakenduse versiooni Helmi abil?
Muudame Helmile saadetud väärtusi. Tavaliselt on need väärtused, mis asendatakse pildisildi asemel. Viimase puhul, mida sageli kasutatakse ebaproduktiivsetes keskkondades, on muudetav teave annotatsioon, mis on Kubernetese enda jaoks kasutu ja Helmi jaoks toimib see signaalina rakenduse värskendamise vajadusest. Annotatsiooni väärtuse täitmise valikud:
Juhuslik väärtus standardfunktsiooni kasutamine - {{ randAlphaNum 6 }}.
Siin on hoiatus: pärast iga sellise muutujaga diagrammi kasutuselevõttu on märkuse väärtus kordumatu ja Helm eeldab, et seal on muudatusi. Selgub, et me taaskäivitame rakenduse alati, isegi kui me pole selle versiooni muutnud. See pole kriitiline, kuna seisakuid ei teki, kuid see on siiski ebameeldiv.
Kleepimisvool päev ja aeg - {{ .Release.Date }}.
Variant sarnaneb püsivalt kordumatu muutujaga juhuslikule väärtusele.
Õigem viis on kasutada kontrollsummad. See on pildi SHA või giti viimase sissekande SHA - {{ .Values.sha }}.
Need tuleb üle lugeda ja saata helistaja poole Helmi kliendile, näiteks Jenkinsis. Kui rakendus on muutunud, muutub ka kontrollsumma. Seetõttu värskendab Helm rakendust ainult vajaduse korral.
Võtame oma katsed kokku
Helm teeb muudatusi kõige vähem invasiivsel viisil, nii et mis tahes muudatused rakenduse kujutise tasemel Dockeri registris ei too kaasa värskendust: pärast käsu täitmist ei juhtu midagi.
võti --force kasutatakse probleemsete väljaannete taastamiseks ja seda ei seostata sundvärskendustega.
võti --recreate-pods uuendab jõuliselt rakendusi, kuid teeb seda vandaali viisil: lülitab järsult välja kõik konteinerid. Kasutajad kannatavad selle all; te ei tohiks seda tootmises teha.
Tehke käsuga otse Kubernetese klastris muudatused kubectl edit ära: me rikume järjepidevust ja käitumine erineb olenevalt Helmi versioonist.
Helmi uue versiooni ilmumisega on ilmnenud palju nüansse. Helmi hoidlas olevaid probleeme kirjeldatakse selges keeles, need aitavad teil üksikasju mõista.
Redigeeritava märkuse lisamine diagrammile muudab selle paindlikumaks. See võimaldab teil rakendust õigesti, ilma seisakuteta käivitada.
“Maailmarahu” mõte, mis töötab kõigis eluvaldkondades: lugege juhiseid enne kasutamist, mitte pärast. Ainult täieliku teabega on võimalik luua usaldusväärseid süsteeme ja teha kasutajaid õnnelikuks.