Tere kõigile! Minu nimi on Pavel Agaletski. Töösklen tiimijuhina meeskonnas, mis arendab Lamoda tarnesüsteemi. 2018. aastal esinesin HighLoad++ konverentsil ja täna tahan tutvustada oma ettekande transkriptsiooni.

Minu teema käsitleb meie ettevõtte kogemusi süsteemide ja teenuste juurutamisel erinevatesse keskkondadesse. Alustades meie eelajaloolistest aegadest, kui juurutame kõik süsteemid tavapärastesse virtuaalserveritesse, ja lõpetades järkjärgulise üleminekuga Nomadilt Kubernetesesse. Räägin, miks me seda tegime ja milliseid probleeme meil protsessis ette tuli.

Rakenduste juurutamine VM-is

Alustuseks olgu öeldud, et kolm aastat tagasi paigaldati kõik ettevõtte süsteemid ja teenused tavalistele virtuaalserveritele. Tehniliselt oli see korraldatud nii, et kogu meie süsteemide kood oli paigutatud ja kogutud automaatse kogumise vahendite abil, kasutades Jenkinsit. Ansible'i abil viidi see meie versioonihaldussüsteemist virtuaalserveritesse. Iga süsteem, mis oli meie ettevõttes, paigaldati vähemalt kahele serverile: üks neist oli head ja teine tail. Need kaks süsteemi olid omavahel täiesti identsed kõigi oma seadete, võimsuse, konfiguratsiooni ja muu osas. Nende vaheliseks erinevuseks oli ainult see, et head sai kasutajate liiklust, samas kui tail ei saanud kunagi kasutajate liiklust enda peale.

Miks see nii tehti?

Kui me juurutame uusi versioone meie rakendusest, soovisime tagada sujuva väljalaskmise, see tähendab ilma märgatavate tagajärgedeta kasutajatele. See saavutati selle kaudu, et järgmine komponeeritud versioon kasutades Ansible'i viidi välja tail. Seal said inimesed, kes tegelesid juurutamisega, kontrollida ja veenduda, et kõik on korras: kõik mõõdikud, jaotised ja rakendused töötavad; vajalikke skripte käivitavad. Alles pärast seda, kui nad veendusid, et kõik on korras, suunati liiklus. See hakkas minema sellele serverile, mis oli varem olnud tail. Ja see, mis oli olnud head, jäi kasutajaliikluse vabaks, samas kui seal oli endiselt meie rakenduse eelmine versioon.

Nii oli see kasutajatele sujuv. Kuna üleminek on kohene, kuna see on lihtsalt koormuse tasakaalustaja vahetamine. Väga lihtne on naasta eelnevale versioonile, lihtsalt vahetades koormuse tasakaalustaja tagasi. Samuti saime enne, kui kasutajaliiklus hakkab sinna jõudma, veenduda rakenduse võimes töötada tootmisjärgus, mis oli üsna mugav.

Milliseid eeliseid me kõik selles nägime?

1. Esimene ja kõige tähtsam on see, et see töötab piisavalt hästi. Lihtsalt toimib. Kuidas selline juurutamise skeem toimib, on kõigile selge, sest enamik inimesi on kunagi juurutanud tavalistel virtuaalserveritel.
2. See on piisavalt usaldusväärne, kuna juurutustehnoloogia on lihtne ja seda on testinud tuhanded ettevõtted. Miljonid serverid juurutatakse just nii. Midagi on keeruline katki teha.
3. Ja lõpuks, me saime aatomaarseid juurutamisi. Juurutamised toimuvad kasutajate jaoks korraga, ilma nähtava üleminemise etappita vana ja uue versiooni vahel.

Aga koos sellega nägime ka mõningaid puudusi:

1. Lisaks tootmiskeskkonnale ja arenduskeskkonnale, on ka teisi keskkondi, nagu qa ja eeltootmine. Sel hetkel oli meil palju servereid ja umbes 60 teenust. Seetõttu tuli iga teenuse jaoks toetada selle jaoks asjakohast versiooni. virtuaalmasin. Kui soovite raamatukogusid uuendada või uusi sõltuvusi installida, peate seda tegema kõigis keskkondades. Samuti tuleb sünkroniseerida aeg, millal plaanite kasutada uut versiooni oma rakendusest, aegaga, mil devops teeb vajalikud keskkonna seaded. Sellisel juhul on lihtne sattuda olukorda, kus keskkond erineb kohe kõigis järjestikustes keskkondades. Näiteks QA-keskkonnas on teised raamatukogade versioonid kui toodangus, mis toob kaasa probleeme.
2. Sõltuvuste uuendamise keerukus teie rakenduse. See ei sõltu teist, vaid teisest meeskonnast. Eelkõige devops meeskonnast, kes toetab servereid. Peate neile esitama vastava ülesande ja andma kirjelduse sellest, mida soovite teha.
3. Toll ajal soovisime ka jagada meie suured monoliidid eraldi väikesteks teenusteks, kuna mõistsime, et neid tuleb järjest juurde. Sel ajal oli meil neid juba üle 100. Iga uue teenuse jaoks tuli luua eraldi uus virtuaalmasin, mida tuli ka teenindada ja käivitada. Peale selle ei piisanud ühest masinast, vaid vähemalt kahest oli vajalik. Kõigile sellele lisandus QA-keskkond. See tekitab probleeme ja muudab uute süsteemide loomise ja käivitamise keerulisemaks, kulukamaks ja aeganõudvamaks. protsessiks.

Seetõttu otsustasime, et oleks mugavam üle minna tavaliste virtuaalmasinate juurutamiselt rakenduste juurutamisele Docker-konteineris. Dockeriga on vajalik süsteem, mis suudab rakendust klastris käivitada, kuna konteinerit ei saa lihtsalt üles tõsta. Tavaliselt soovite jälgida, kui palju konteinerit on üles tõstetud, et need tõuseksid automaatselt. Seetõttu tuli valida haldussüsteem.

Oleme pikka aega mõelnud, millist neist valida. Asi on selles, et toona oli meie tavalistele virtuaalserveritele mõeldud juurdepääsuhulk pisut vananenud, kuna seal olid mitte kõige värskema versioonidega operatsioonisüsteemid. Ühel hetkel oli seal isegi FreeBSD, mida oli üsna ebamugav hallata. Mõistsime, et peame kiiresti Dockerisse migreeruma. Meie DevOps vaatles oma olemasolevat kogemust erinevate lahendustega ja valis süsteemi nimega Nomad.

Üleminek Nomadile

Nomad on ettevõtte “HashiCorp” toode. Samuti on nad tuntud teiste oma lahenduste poolest:

«Consul» on teenuste avastamise tööriist.

«Terraform» on serverihalduse süsteem, mis võimaldab teil neid konfigureerida koodi kaudu, nn infrastructure-as-a-code.

«Vagrant» võimaldab teil lokaliseerida virtuaalmaju või pilves, kasutades teatud konfiguratsioonifailide seadeid.

Nomad näis sel hetkel olevat piisavalt lihtne lahendus, kuhu saab kiiresti üle minna ilma kogu infrastruktuuuri muutmata. Lisaks on selle kasutamine piisavalt lihtne. Seetõttu valisimegi selle meie konteineri filtreerimissüsteemiks.

Mida on vaja, et üldse oma süsteem Nomadis käivitada?

1. Esiteks on vajalik docker image teie rakenduse jaoks. See tuleb koostada ja paigutada docker'i pildihoidlasse. Meie puhul on see artifactory — süsteem, mis võimaldab erinevat tüüpi artefakte sinna üles laadida. See suudab hoida arhiive, docker'i pilte, PHP composer pakette, NPM pakette jne.
2. Samuti on vajalik konfigureerimisfaili, mis ütleb Nomadile, mida, kuhu ja millisest kogusest soovite käivitada.

Kui räägime Nomadist, siis kasutab see teavefaili formaadina HCL keelt, mis tähistab HashiCorp Configuration Language. See on Yaml'i ülekomplekteeritud versioon, mis võimaldab teil oma teenust Nomadi mõistes kirjeldada.

See võimaldab määrata, kui palju konteinerit soovite kasutusele võtta, millistest piltidest edastada neile erinevad parameetrid kasutuse võtmisel. Nii anda fail Nomad'ile, mis käivitab konteinerid vastavalt sellele tootmises.

Meie juhul mõistsime, et lihtsalt iga teenuse jaoks täiesti identsete HCL-failide kirjutamine ei ole eriti mugav, kuna teenuseid on palju ja neid on mõnikord soov uuendada. Juhtub, et üks teenus ei ole kasutusele võetud ühes eksemplaris, vaid mitmes erinevas. Näiteks on üks süsteem, mis meil tootmises on, üle 100 instantsi tootmises. Need käivituvad sama piltidest, kuid erinevad konfiguratsiooniseadete ja konfiguratsioonifailide poolest.

Seetõttu otsustasime, et on mugav hoida kõik meie rakenduseks vajalikud konfiguratsioonifailid ühes ühises hoidlas. Nii saavad need olema ülevaatlikud: neid on lihtne hallata ja näha, millised süsteemid meil olemas on. Kui on vajalik, on ka lihtne midagi uuendada või vahetada. Uue süsteemi lisamine on samuti vaevatu — piisab lihtsalt uue katalooge lisamisest koos konfiguratsioonifailiga. Selle sees asuvad failid: service.hcl, mis sisaldab meie teenuse kirjeldust, ning mõned env-failid, mis võimaldavad seda teenust, olles produtseeritud, seadistada.

Kuid mõned meie süsteemid on produtseeritud mitte ühes ekskemplaris, vaid mitmes korraga. Seetõttu otsustasime, et on mugav salvestada mitte puhtad konfiguratsioonid, vaid nende malliversioonid. Ja mallikeeleks valisime jinja 2. Selles formaadis hoitakse nii teenuse konfiguratsioone kui ka vajalikku env-failide komplekti.

Lisaks sellele oleme kõikide projektide jaoks ühisesse reposse paigaldanud skriptide juurutamise, mis võimaldab teie teenust käivitada ja juurutada tootmises, soovitud keskkonnas, soovitud sihtpunktis. Juhul, kui oleme oma HCL-konfiguratsiooni muutnud malliks, näeb see HCL-fail, mis varem oli tavaline Nomadi konfiguratsioon, nüüd veidi erinev välja.

See tähendab, et oleme asendanud mõned konfigureerimise muutuja kohad variatsioonidega, mis saadakse keskkonna failidest või teistest allikatest. Lisaks sellele oleme saanud võimaluse koguda HCL-faile dünaamiliselt, st võime rakendada mitte ainult tavalisi muutuja sisestusi. Kuna jinja toetab tsükleid ja tingimusi, saab sinna luua ka konfigureerimisfaile, mis muutuvad sõltuvalt sellest, kuhu täpselt oma rakendusi juurutate.

Näiteks, kui soovite oma teenust eeltootmisse ja tootmisse panna. Oletame, et eeltootmises ei soovi te käivitada cron-skripte, vaid lihtsalt näha teenust eraldi domeenil, et veenduda, et see töötab. Igaühe jaoks, kes teenust juurutab, tundub protsess väga lihtne ja läbipaistev. Piisab, kui käitada fail deploy.sh, näidata, millist teenust soovite juurutada ja millisesse sihtkohta. Näiteks, kui soovite juurutada mõnda süsteemi Venemaale, Valgevenesse või Kasahstani. Selleks piisab lihtsalt ühe parameetri muutmisest ja teil on õige konfiguratsioonifail valmis.

Kui teenus Nomad on teie klastris juba juurutatud, näeb see välja järgmine.

Esiteks vajate välist tasakaalustajat, mis võtab kogu kasutajaliikluse enda peale. See töötab koos Consuliga ja küsib temalt, kus, millisel sõlmel ja millise IP-aadressi on olemas konkreetne teenus, mis vastab sellele või teisele domeeninimele. Teenused Consulis ilmuvad otse Nomadist. Kuna need on sama ettevõtte tooted, on need omavahel hästi seotud. Võib öelda, et Nomad suudab vaikimisi registreerida kõik selle sees käivituvad teenused Consuli sees.

Kui teie väline tasakaalustaja teab, kuhu teenusesse liiklus suunata, suunab ta selle vastavasse konteinerisse või mitmesse konteinerisse, mis vastavad teie rakendusele. Loomulikult tuleb samal ajal mõelda ka turvalisusele. Isegi kui kõik teenused käivitatakse ühesugustes virtuaalmasinates konteinerites, on tavaliselt vajalik keelata vabaks juurdepääsuks ükskõik millisest teenusest ükskõik millisele teisele. Oleme seda saavutanud segmentimise kaudu. Iga teenus käivitati oma virtuaalses võrgus, kus olid määratud marsruutimise reeglid ja juurdepääsu lubamise/keelamise reeglid teistele süsteemidele ja teenustele. Need võisid asuda nii selle klastre sees kui ka väljaspool seda. Näiteks, kui soovite keelata teenusel teatud andmebaasi ühenduse loomise, saab seda teha segmenteerimise kaudu võrgu tasemel. See tähendab, et isegi ekslikult ei saa te testkeskkonnast teie tootmisandmebaasi juhuslikult ühenduda.

Kui palju maksma läks meespetsialistide ressursi ülemineku protsess?

Ettevaatuslikult kulus kogu ettevõtte üleminek Nomadi peale umbes 5–6 kuud. Üleminek toimus teenuse kaupa, kuid piisavalt kiirelt. Iga meeskond pidi looma oma teenuste jaoks oma konteinerid.

Meil on selline lähenemine, et iga meeskond vastutab oma süsteemide docker-piltide eest iseseisvalt. DevOps pakub üldiselt vajalikku infrastruktuuri, mis on vajalik juurutamiseks, sealhulgas klastritoe, CI-süsteemi toe jne. Ja tol ajal oli meil rohkem kui 60 süsteemi, mis olid Nomadi peale üle viidud, kokku oli umbes 2000 konteinerit.

DevOps vastutab kogu juurutamise ja serveritega seotud üldise infrastruktuuri eest. Iga arendustiim on vastutav oma konkreetse süsteemi konteinerite rakendamise eest, kuna just meeskond teab, mida tal konkreetses konteineris üldse vaja on.

Põhjused Nomadist loobumiseks

Millised eelised me saime, kui läksime üle Nomadi ja Dockeriga juurutamisele?

1. Meie tagasime ühtlased tingimused kõikides keskkondades. Arenduses, QA-keskkonnas, eessündmuses ja tootmisprotsessis kasutatakse samu konteineri pilte, samade sõltuvustega. Seega on teil peaaegu pole võimalust, et tootmisesse satub midagi, mida te ei ole varem lokaalselt või testkeskkonnas testinud.
2. Samuti oleme leidnud, et on piisavalt lihtne lisada uus teenus. Igasugused uued süsteemid käivituvad rakendamise vaatenurgast väga lihtsalt. Piisab minna seadistusi hoidvasse reposse, lisada sinna järgmine konfiguratsioon teie süsteemi jaoks, ja kõik on valmis. Saab teha teie süsteemi tootmisse ilma DevOps'i täiendava pingutuseta.
3. Kõik konfiguratsioonifailid ühes ühises reposes olid ülevaatavad. Hetkel, kui me rakendasime meie süsteeme koos virtuaalservereid, me kasutasime Ansible't, kus konfiguratsioonid olid samas hoidlas. Kuid enamik arendajatest leidis selle kasutamise natuke keeruliseks. Siin on konfiguratsioonide ja koodi maht, mida peate teenuse juurutamiseks lisama, oluliselt vähenenud. Lisaks on DevOps'il lihtne neid muuta või parandada. Näiteks versioonide vahetamisel, nagu uue versiooni puhul Nomad's, saavad nad massiliselt uuendada kõiki operatsioonifailide, mis asuvad samas kohas.

Aga me kohtasime ka mõningaid puudusi:

Selgus, et me ei suutnud saavutada sujuvat juurutamist Nomad'i puhul. Kui konteinerid käivitati erinevate tingimustega, võis juhtuda, et see käivitus ja Nomad nägi seda kui liiklusele vastuvõetavat konteinerit. See juhtus juba enne, kui rakendus selle sees jõudis käima minna. Selle tõttu hakkas süsteem lühikese aja jooksul andma 500. vigu, kuna liiklus hakkas minema konteinerisse, mis ei olnud veel valmis seda vastu võtma.

Me kohtasime mõningaid vea. Kõige olulisem probleem on see, et Nomad ei suuda hästi hallata suurt klastrit, eriti kui teil on palju süsteeme ja konteinerit. Kui soovite võtta hooldusse ühe serveri, mis kuulub Nomadi klastrisse, on piisavalt suur tõenäosus, et klaster ei tunne end hästi ja laguneb. Osad konteinerid võivad näiteks ebaõnnestuda ja mitte taastuda — see võib teid hiljem kalliks maksma minna, kui kõik teie tootmissüsteemid asuvad just Nomadi hallatavas klastris.

Seetõttu otsustasime mõelda, kuhu edasi minna. Sel hetkel olime palju paremini teadlikud sellest, mida soovime saavutada. Nimelt: soovime usaldusväärsust, veidi rohkem funktsioone, kui Nomad pakub, ja küpset, stabiilsemat süsteemi.

Selles osas langetati meie valik Kubernetes'e kasuks kui kõige populaarsema platvormi, et käitada klastreid. Eriti arvestades seda, et meie konteinerite suurus ja arv olid piisavalt suured. Selliste eesmärkide saavutamiseks tundus Kubernetes kõige sobivama süsteemina, mida me vaadates leidsime.

Üleminek Kubernetes'esse

Natuke räägin, millised on Kubernetes'i põhikontseptsioonid ja kuidas need erinevad Nomadist.

Esiteks on Kubernetes'i kõige põhilisem mõisted pod. Pod on rühm ühest või mitmest konteinerist, mis käivitatakse alati koos. Need töötavad nagu nad oleksid alati kindlal virtuaalmasinal. Nad on omavahel juurdepääsetavad aadressi 127.0.0.1 kaudu erinevatele portidele.

Oletame, et teil on PHP-rakendus, mis koosneb nginx'ist ja php-fpm'ist – klassikaline skeem. Tõenäoliselt soovite, et nginx ja php-fpm konteinerid oleksid alati koos. Kubernetes võimaldab seda saavutada, kirjeldades neid kui ühte yhteist pod'i. Seda me ei saanud Nomadi abil.

Teine mõisted on deployment. Asi on selles, et pod ise on efemeerne asi, see käivitub ja kaob. Kas soovite kõigepealt lõpetada kõik teie eelnevad konteinerid ja seejärel korraga käivitada uued versioonid või soovite neid järk-järgult kasutada – selle protsessi eest vastutab deployment mõisted. See kirjeldab, kuidas te oma pod'e juurutate, kui palju ning kuidas neid uuendada.

Kolmas mõisted on teenus. Teie teenus on sisuliselt teie süsteem, mis võtab vastu teatud liikluse ja suunab selle siis ühele või mitmele podile, mis vastavad teie teenusele. See tähendab, et saate määrata, et kogu sissetulev liiklus teatud nimega teenusele tuleb suunata just nendele podidele. Samuti tagab see teile liikluse tasakaalustamise. Seega võite käivitada kaks teie rakenduse podi, ning kogu sissetulev liiklus jaotatakse võrdselt nende teenusele kuuluvate podide vahel.

Ja neljas põhikontseptsioon — Ingress. See on teenus, mis käivitatakse Kubernetes'i klastris. See toimib välise koormuse tasakaalustajana, mis võtab endale kõik päringud. Kubernetes Ingress API abil saab määrata, kuhu need päringud suunata. Ta teeb seda väga paindlikult. Saate määrata, et kõik päringud sellest hostist ja sellisest URL-ist saadetakse sellele teenusele. Ja need päringud, mis tulevad sellele hostile ja teisele URL-ile, saadetakse teisele teenusele.

Arendaja jaoks on kõige ägedam asi see, et saate seda kõike iseseisvalt hallata. Kui seadistate Ingressi konfiguratsiooni, võite kogu liikluse, mis siseneb teatud API-le, suunata eraldi konteineritesse, mis on näiteks kirjutatud Go-s. Ja sellel samal domeenil liikluse suunamine teisele URL-ile võib viia konteineritesse, mis on kirjutatud PHP-s, kus on palju loogikat, kuid need ei ole eriti kiired.

Kui võrrelda neid mõisted Nomadiga, siis võib öelda, et esimesed kolm mõistet moodustavad koos ühe teenuse. Kuid viimane mõiste ei ole Nomadis olemas. Selle asemel kasutasime me välist tasakaalustajat: see võib olla haproxy, nginx, nginx+ ja nii edasi. Kubermetide puhul ei pea te seda täiendavat mõistet eraldi tutvustama. Siiski, kui vaadata Ingressi seest, siis on see kas nginx, haproxy või traefik, kuid nagu oleks see Kubernetesesse sisseehitatud.

Kõik minu kirjeldatud mõisted on tegelikult ressursid, mis eksisteerivad Kuberneteses klastris. Nende kirjeldamiseks kasutatakse YAML-formaati, mis on loetavam ja tuttavam kui HCL-failid Nomadi puhul. Kuid struktuurilt kirjeldavad nad näiteks podi sama asja. Nad ütlevad – soovin juurutada sellised podid sinna, selliste imidžidega, sellises koguses.

Lisaks sellele mõistsime, et me ei soovi käsitsi luua iga eraldi ressursi: juurutamisi, teenuseid, Ingressit ja muud. Selle asemel soovisime juurutamisel kirjeldada iga meie süsteemi, mis eksisteerib Kubernetes termini kohaselt, et ei peaks käsitsi uuesti looma kõiki vajalikke resursside sõltuvusi õiges järjekorras. Sellise süsteemi, mis võimaldas meil seda teha, valisime Helm.

Helmi põh mõisted

Helm on paketihaldur Kubernetesi jaoks. See sarnaneb väga pakettide halduritega programmeerimiskeeltes. Need võimaldavad teil salvestada teenuse, mis koosneb näiteks nginxi deploymentist, php-fpmi deploymentist, Ingressi konfiguratsioonist, configmapsist (see on entiteet, mis võimaldab teil määratleda keskkonna ja muid parameetreid teie süsteemis) nii nimetatud chartide kujul. Sellega seoses on Helm Kubernetesi peal.. See tähendab, et see ei ole mõni eraldi süsteem, vaid lihtsalt veel üks teenus, mis käivitub klastris. Te suhtlete temaga tema API kaudu käsureakäskude kaudu. Selle mugavus ja ilu seisneb selles, et isegi kui helm läheb katki või kustutate selle klastrist, ei kao teie teenused, kuna helm teenib põhimõtteliselt vaid süsteemi käivitamiseks. Tal on vastutus teenuste töökindluse ja seisundi eest edasi Kubernetes.

Samuti oleme mõistnud, et mallimine, mille tehti ise läbi jinja rakendamise meie konfiguratsioonides, on helm üks peamisi funktsioone. Kõik konfiguratsioonid, mida loote oma süsteemide jaoks, salvestatakse helm'is mallidena, mis on sarnased jinja'le, kuid tegelikult kasutavad Go keele mallimist, milles helm on kirjutatud, nagu ka Kubernetes.

Helm lisab meile veel mõningaid täiendavaid mõisted.

Chart — on teie teenuse kirjeldus. Teistes pakihaldurites kutsutakse seda paketiks, bundle'iks või millegiks sarnaseks. Siin nimetatakse seda chart'iks.

Values – need on muutujad, mida soovite kasutada oma konfiguratsioonide koostamiseks mallidest.

Release. Iga kord, kui teenus, mida haldab helm, saab inkrementaalse versiooni väljaandest. Helm mäletab, milline oli teenuse konfigureerimine eelmisel, üleelmisel väljaandel jne. Seetõttu, kui on vaja tagasi minna, piisab helm callback käsu täitmisest, osutades sellele eelnevale väljaande versioonile. I even if at the time of rollback the corresponding configuration in your repository is not available, helm still remembers what it was and will revert your system to the state it was in the previous release.

Juhul, kui kasutame helm'i, muutuvad tavalised Kubernetes'i konfgid ka mallideks, kus on võimalik kasutada muutujaid, funktsioone ja rakendada tingimuslikke operaatoreid. Nii saate oma teenuse konfigureerimist üles ehitada sõltuvalt keskkonnast.

Praktiliselt otsustasime toimida veidi teisiti kui Nomadi puhul. Kui Nomadis hoiti ühes repertuaaris nii deploymenti konfiguratsioone kui ka n-muutujaid, mis on vajalikud meie teenuse rakendamiseks, siis siin otsustasime need jagada kaheks eraldi repertuaariks. Repertuaaris "deploy" hoitakse ainult n-muutujaid, mis on vajalikud deploymentiks, ja repertuaaris "helm" hoitakse konfiguratsioone või chart'e.

Mida see meile andis?

Kuigi me ei hoia enda konfiguratsioonifailides tõeliselt tundlikke andmeid, näiteks andmebaasi paroole, mis on salvestatud Kuberneteses secrets'ina, on seal siiski eraldi asju, millele me ei soovi, et kõik pääseksid ligi. Seetõttu on juurdepääs repertuaarile "deploy" rohkem piiratud, samas kui repertuaar "helm" sisaldab lihtsalt teenuse kirjelduse. Sel põhjusel saab sellele anda ligipääsu turvaliselt laiemale ringile inimestele.

Kuna meil on mitte ainult tootmis-, vaid ka teised keskkonnad, saame sellise jaotuse tõttu taaskasutada meie helm-chart'e, et juurutada teenuseid mitte ainult tootmises, vaid ka näiteks QA-keskkonnas. Isegi nende lokaalset käivitamist silmas pidades, kasutades Minikube — see on selline tööriist, mis võimaldab käivitada Kubernetes'e kohapeal.

Iga repositooriumi sees oleme jätnud jagunemise eraldi kaustadesse iga teenuse jaoks. See tähendab, et iga kausta sees on malli, mis kuulub vastavasse chart'i ja kirjeldab neid ressursside, mille juurutamine on vajalik meie süsteemi käivitamiseks. Repositooriumis „deploy” oleme jätnud ainult keskkondade muutujad. Sellisel juhul ei kasutanud me templaatimist jinja abil, kuna helm pakub ise templaatimist välja pakkumisel – see on üks selle põhifunktsioone.

Oleme jätnud deployimiseks skripti – deploy.sh, mis lihtsustab ja standardiseerib helm'i kaudu käivitamise. Nii näeb deployimise liides välja täpselt sama, nagu see oli Nomad'i kaudu deployides. Sama deploy.sh, teie teenuse nimi ja koht, kuhu soovite selle paigutada. See toob kaasa helm'i käivitamise. See omakorda kogub seadistused mallidest, sisestab vajalikud value-failid ja seejärel viib need Kubernetesesse.

Järeldused

Kubernetes'i teenus tundub keerulisem kui Nomad.

Siin suunatakse väljaminev liiklus Ingressisse. See on just see eesmine kontroller, mis võtab vastu kõik päringud ja suunab need vastavatesse teenustesse, mis põhinevad päringu andmetel. Ta määrab need konfiguratsioonide alusel, mis on osa teie rakenduse kirjeldusest helm'is ja mille arendajad määravad ise. Teenus suunab päringud oma pod'idele, st konkreetsetele konteineritele, tasakaalustades sissetulevat liiklust kõikide nende konteinerite vahel, mis kuuluvad antud teenusele. Ja muidugi ei tohi unustada, et võrgu tasemel turvalisusest ei tohi kõrvale kalduda. Seetõttu on Kubernetes klasteris segmenteerimine, mis põhineb siltide määramisel. Kõigil teenustel on teatud sildid, millega on seotud teenuste juurdepääsu õigused erinevatele välistingimustes või sisetingimustes olevatele ressurssidele klastris.

Üleminekut tehes nägime, et Kubernetes omab kõiki Nomadi võimalusi, mida olime varem kasutanud, ja lisab palju uut. Seda saab laiendada läbi pluginade ning tegelikult ka kohandatud ressursitüüpide kaudu. See tähendab, et teil on võimalus mitte ainult kasutada seda, mis tuleb Kubernetesiga kaasa, vaid luua oma ressurss ja teenus, mis seda ressursi loeb. See pakub täiendavaid laiendamisvõimalusi teie süsteemi ilma Kubernetesit uuesti installimata ja ilma muudatusteta.

Ühe sellise kasutuse näide on Prometheus, mis töötab meie Kubernetes klastris. Et see hakkaks koguma mõõdikute teavet mõnest teenusest, peame teenuse kirjeldusele lisama täiendava ressursitüübi, nn teenuse monitori. Prometheus, olles käivitatud Kuberneteses ja osates lugeda kohandatud ressursitüüpe, hakkab automaatselt koguma mõõdikute teavet uue süsteemi kohta. See on piisavalt mugav.

Meie esimene Kubernetes'e deploy toimus märtsis 2018. Aja jooksul ei ole me sellega kunagi probleeme olnud. See töötab piisavalt stabiilselt, ilma oluliste tõrgeteta. Lisaks saame seda ka edasi laiendada. Täna piisab meile hetkel olemasolevatest võimalustest, ja meeldib väga, kui kiiresti Kubernetes areneb. Praegu on Kubernetes'is üle 3000 konteineri. Klaster hõlmab mitmeid Node'e. Samas on see hooldatav, stabiilne ja väga kontrollitav.

Allikas: habr.com