Hei kaikki! Nimeni on Pavel Agaletsky. Työskentelen tiimijohtajana tiimissä, joka kehittää Lamoda-toimitusjärjestelmää. Vuonna 2018 puhuin HighLoad++ -konferenssissa, ja tänään haluan esittää kopioraportistani.

Aiheeni on omistettu yrityksemme kokemukselle järjestelmien ja palveluiden käyttöönotosta eri ympäristöissä. Alkaen esihistoriallisista ajoista, jolloin otimme kaikki järjestelmät käyttöön tavallisille virtuaalipalvelimille, päättyen asteittaiseen siirtymiseen Nomadista Kubernetesin käyttöönottoon. Kerron sinulle, miksi teimme sen ja mitä ongelmia meillä oli prosessissa.

Sovellusten käyttöönotto VM:ssä

Aloitetaan siitä, että 3 vuotta sitten kaikki yrityksen järjestelmät ja palvelut otettiin käyttöön tavallisille virtuaalipalvelimille. Teknisesti se oli organisoitu niin, että kaikki järjestelmiemme koodit tallennettiin ja koottiin automaattisilla kokoonpanotyökaluilla, jenkineillä. Ansiblen avulla se otettiin käyttöön versionhallintajärjestelmästämme virtuaalisille palvelimille. Lisäksi jokainen järjestelmämme, joka yrityksellämme oli, oli otettu käyttöön vähintään kahdelle palvelimelle: yksi niistä päähän, toinen hännän päälle. Nämä kaksi järjestelmää olivat täysin identtisiä toistensa kanssa kaikissa asetuksissaan, tehossaan, kokoonpanossaan jne. Ainoa ero niiden välillä oli, että pää sai käyttäjäliikennettä, kun taas häntä ei koskaan vastaanottanut käyttäjäliikennettä.

Miksi tämä tehtiin?

Kun otimme käyttöön sovelluksemme uusia julkaisuja, halusimme varmistaa saumattoman käyttöönoton, toisin sanoen ilman havaittavia seurauksia käyttäjille. Tämä saavutettiin, koska seuraava Ansiblea käyttävä käännetty julkaisu rullattiin loppuun asti. Siellä käyttöönotossa mukana olleet ihmiset saattoivat tarkistaa ja varmistaa, että kaikki oli kunnossa: kaikki mittarit, osat ja sovellukset toimivat; tarvittavat skriptit käynnistetään. Vasta kun he olivat vakuuttuneita, että kaikki oli kunnossa, liikenne vaihdettiin. Se alkoi mennä palvelimelle, joka oli aiemmin häntä. Ja se, joka oli aiemmin pää, jäi ilman käyttäjäliikennettä, vaikka siinä oli edelleen sovelluksemme edellinen versio.

Joten se oli saumaton käyttäjille. Koska kytkentä on välitön, koska se on yksinkertaisesti tasapainottimen vaihtamista. Voit helposti palata edelliseen versioon vaihtamalla tasapainottimen takaisin. Voisimme myös varmistaa, että sovellus oli tuotantokykyinen jo ennen kuin se sai käyttäjäliikennettä, mikä oli varsin kätevää.

Mitä etuja näimme kaikessa tässä?

1. Ensinnäkin se riittää se vain toimii. Kaikki ymmärtävät, kuinka tällainen käyttöönottojärjestelmä toimii, koska useimmat ihmiset ovat koskaan ottaneet käyttöön tavallisia virtuaalipalvelimia.
2. Tämä riittää luotettavasti, koska käyttöönottotekniikka on yksinkertainen, tuhansien yritysten testaama. Tällä tavalla otetaan käyttöön miljoonia palvelimia. On vaikea rikkoa jotain.
3. Ja vihdoin pääsimme atomikäytöt. Käyttöönotot, jotka tapahtuvat käyttäjille samanaikaisesti, ilman havaittavaa siirtymisvaihetta vanhan ja uuden version välillä.

Mutta näimme myös useita puutteita kaikessa tässä:

1. Tuotantoympäristön, kehitysympäristön lisäksi on muita ympäristöjä. Esimerkiksi qa ja esituotanto. Tuolloin meillä oli paljon palvelimia ja noin 60 palvelua. Tästä syystä se oli välttämätöntä ylläpidä kunkin palvelun uusin versio virtuaalikone. Lisäksi, jos haluat päivittää kirjastoja tai asentaa uusia riippuvuuksia, sinun on tehtävä tämä kaikissa ympäristöissä. Sinun piti myös synkronoida aika, jolloin aiot ottaa sovelluksesi seuraavan uuden version käyttöön, ajan kanssa, jolloin devops suorittaa tarvittavat ympäristöasetukset. Tässä tapauksessa on helppo joutua tilanteeseen, jossa ympäristömme on jossain määrin erilainen kaikissa ympäristöissä kerralla. Esimerkiksi laadunvarmistusympäristössä kirjastoista on joitain versioita ja tuotantoympäristössä erilaisia, mikä johtaa ongelmiin.
2. Vaikeus päivittää riippuvuuksia hakemuksesi. Se ei riipu sinusta, vaan toisesta joukkueesta. Nimittäin palvelimia ylläpitävältä devops-tiimiltä. Sinun on annettava heille sopiva tehtävä ja kuvaus siitä, mitä haluat tehdä.
3. Tuolloin halusimme myös jakaa käytössämme olevat suuret monoliitit erillisiksi pieniksi palveluiksi, koska ymmärsimme, että niitä tulee lisää ja lisää. Niitä oli tuolloin jo yli 100. Jokaista uutta palvelua varten oli tarpeen luoda erillinen uusi virtuaalikone, jota myös ylläpidettiin ja otettiin käyttöön. Lisäksi et tarvitse yhtä autoa, vaan vähintään kaksi. Kaikkeen tähän on lisätty laadunvarmistusympäristö. Tämä aiheuttaa ongelmia ja vaikeuttaa uusien järjestelmien rakentamista ja käyttöä. monimutkainen, kallis ja pitkä prosessi.

Siksi päätimme, että olisi kätevämpää siirtyä tavallisten virtuaalikoneiden käyttöönotosta sovelluksiemme käyttöönottoon telakointisäiliössä. Jos sinulla on telakka, tarvitset järjestelmän, joka voi ajaa sovellusta klusterissa, koska et voi vain nostaa konttia. Yleensä halutaan seurata kuinka monta konttia nostetaan niin, että ne nousevat automaattisesti. Tästä syystä meidän piti valita ohjausjärjestelmä.

Mietimme pitkään, kumman voisimme ottaa. Tosiasia on, että tuolloin tämä tavallisten virtuaalipalvelimien käyttöönottopino oli jonkin verran vanhentunut, koska niillä ei ollut uusimpia käyttöjärjestelmien versioita. Jossain vaiheessa oli jopa FreeBSD, jota ei ollut kovin kätevä tukea. Ymmärsimme, että meidän oli siirryttävä telakointiasemaan mahdollisimman nopeasti. Devoppimme tarkastelivat olemassa olevaa kokemustaan ​​erilaisista ratkaisuista ja valitsivat Nomadin kaltaisen järjestelmän.

Vaihda Nomadiin

Nomad on HashiCorpin tuote. Ne tunnetaan myös muista ratkaisuistaan:

"Konsuli" on työkalu palvelun löytämiseen.

"Terraformi" - Palvelinten hallintajärjestelmä, jonka avulla voit määrittää ne konfiguroinnilla, ns. infrastruktuuri-as-a-code.

"Vagrant" Voit ottaa virtuaalikoneita käyttöön paikallisesti tai pilvessä tiettyjen määritystiedostojen avulla.

Nomad vaikutti tuolloin melko yksinkertaiselta ratkaisulta, johon voitiin vaihtaa nopeasti koko infrastruktuuria muuttamatta. Lisäksi se on melko helppo oppia. Siksi valitsimme sen konttimme suodatusjärjestelmäksi.

Mitä tarvitset järjestelmän käyttöönottoon Nomadissa?

1. Ensinnäkin tarvitset telakkakuva hakemuksesi. Sinun täytyy rakentaa se ja sijoittaa se Docker-kuvavarastoon. Meidän tapauksessamme tämä on artefaktori - järjestelmä, jonka avulla voit työntää siihen erilaisia ​​​​erityyppisiä esineitä. Se voi tallentaa arkistoja, telakointikuvia, säveltäjä-PHP-paketteja, NPM-paketteja ja niin edelleen.
2. Myös vaaditaan asetustiedosto, joka kertoo Nomadille, mitä, missä ja missä määrin haluat ottaa käyttöön.

Kun puhumme Nomadista, se käyttää tietotiedostomuotonaan HCL-kieltä, joka tarkoittaa HashiCorp-määrityskieli. Tämä on Yamlin superjoukko, jonka avulla voit kuvata palveluasi Nomad-termeillä.

Sen avulla voit sanoa, kuinka monta säilöä haluat ottaa käyttöön, mistä kuvista eri parametrit välitetään niille käyttöönoton aikana. Siten syötät tämän tiedoston Nomadille ja se käynnistää kontit tuotantoon sen mukaisesti.

Meidän tapauksessamme ymmärsimme, että täysin identtisten HCL-tiedostojen kirjoittaminen jokaiselle palvelulle ei olisi kovin kätevää, koska palveluita on paljon ja joskus haluat päivittää niitä. On mahdollista, että yhtä palvelua ei oteta käyttöön yhdessä tapauksessa, vaan useissa eri tapauksissa. Esimerkiksi yhdessä tuotannossamme olevista järjestelmistämme on yli 100 tuotantoa. Ne toimivat samoista kuvista, mutta eroavat kokoonpanoasetuksista ja tiedostoista.

Siksi päätimme, että meidän olisi kätevää tallentaa kaikki määritystiedostomme käyttöönottoa varten yhteen yhteiseen arkistoon. Näin ne olivat näkyvissä: niitä oli helppo ylläpitää ja näimme, mitä järjestelmiä meillä oli. Tarvittaessa on myös helppo päivittää tai muuttaa jotain. Uuden järjestelmän lisääminen ei myöskään ole vaikeaa - sinun tarvitsee vain luoda asetustiedosto uuteen hakemistoon. Sen sisällä ovat seuraavat tiedostot: service.hcl, joka sisältää kuvauksen palvelustamme, ja joitain env-tiedostoja, joiden avulla voidaan määrittää juuri tämä tuotannossa käytössä oleva palvelu.

Joitakin järjestelmiämme ei kuitenkaan oteta käyttöön tuotannossa yhtenä kopiona, vaan useana kerralla. Siksi päätimme, että meidän olisi kätevää tallentaa konfiguraatioita ei niiden puhtaassa muodossa, vaan niiden mallimuodossa. Ja me valitsimme jinja 2. Tässä muodossa tallennamme sekä itse palvelun konfiguraatiot että siihen tarvittavat env-tiedostot.

Lisäksi olemme sijoittaneet arkistoon kaikille projekteille yhteisen käyttöönottoskriptin, jonka avulla voit käynnistää ja ottaa palvelusi käyttöön tuotantoon, haluttuun ympäristöön, haluttuun kohteeseen. Siinä tapauksessa, että muutimme HCL-kokoonpanomme malliksi, niin HCL-tiedosto, joka ennen oli tavallinen Nomad-asetus, alkoi tässä tapauksessa näyttää hieman erilaiselta.

Toisin sanoen korvasimme jotkin asetusten sijaintimuuttujat lisätyillä muuttujilla, jotka on otettu env-tiedostoista tai muista lähteistä. Lisäksi saimme mahdollisuuden kerätä HCL-tiedostoja dynaamisesti, eli voimme käyttää tavallisten muuttujien lisäysten lisäksi. Koska jinja tukee silmukoita ja ehtoja, voit luoda sinne myös määritystiedostoja, jotka muuttuvat sen mukaan, missä tarkalleen otat sovelluksesi käyttöön.

Haluat esimerkiksi ottaa palvelusi käyttöön esi- ja tuotantovaiheessa. Oletetaan, että esituotannossa et halua ajaa cron-skriptejä, vaan haluat vain nähdä palvelun erillisessä toimialueessa varmistaaksesi, että se toimii. Kaikille, jotka käyttävät palvelua, prosessi näyttää hyvin yksinkertaiselta ja läpinäkyvältä. Sinun tarvitsee vain suorittaa deploy.sh-tiedosto, määrittää, minkä palvelun haluat ottaa käyttöön ja mihin kohteeseen. Haluat esimerkiksi ottaa tietyn järjestelmän käyttöön Venäjälle, Valko-Venäjälle tai Kazakstanille. Voit tehdä tämän muuttamalla yhtä parametreista, ja sinulla on oikea asetustiedosto.

Kun Nomad-palvelu on jo otettu käyttöön klusteriisi, se näyttää tältä.

Ensinnäkin tarvitset jonkinlaisen tasapainottimen ulkopuolelle, joka vastaanottaa kaiken käyttäjäliikenteen. Se toimii yhteistyössä Consulin kanssa ja selvittää sieltä missä, missä solmussa, missä IP-osoitteessa tiettyä verkkotunnusta vastaava palvelu sijaitsee. Consulin palvelut tulevat itse Nomadilta. Koska nämä ovat saman yrityksen tuotteita, ne liittyvät melkoisesti toisiinsa. Voimme sanoa, että Nomad out of the box voi rekisteröidä kaikki siihen lanseeratut palvelut Consulissa.

Kun käyttöliittymäsi kuormantasaaja tietää, mihin palveluun lähettää liikennettä, se välittää sen asianmukaiseen säilöön tai useisiin konteihin, jotka vastaavat sovellustasi. Tietysti myös turvallisuutta kannattaa miettiä. Vaikka kaikki palvelut toimivat samoissa virtuaalikoneen säilöissä, tämä vaatii yleensä estämään vapaan pääsyn mistä tahansa palvelusta mihinkään muuhun. Saavutimme tämän segmentoinnilla. Jokainen palvelu lanseerattiin omassa virtuaaliverkossaan, jolle määrättiin reitityssäännöt ja säännöt muiden järjestelmien ja palvelujen sallimisesta/eestämisestä. Ne voisivat sijaita sekä tämän klusterin sisällä että sen ulkopuolella. Jos esimerkiksi haluat estää palvelua muodostamasta yhteyttä tiettyyn tietokantaan, tämä voidaan tehdä verkkotason segmentoinnilla. Eli et voi vahingossakaan muodostaa yhteyttä testiympäristöstä tuotantotietokantaasi.

Kuinka paljon siirtymä maksoi meille henkilöresurssien kannalta?

Koko yrityksen siirtyminen Nomadiin kesti noin 5-6 kuukautta. Liikkuimme palvelukohtaisesti, mutta melko nopealla tahdilla. Jokaisen tiimin oli luotava omat konttinsa palveluita varten.

Olemme omaksuneet sellaisen lähestymistavan, että jokainen tiimi vastaa itsenäisesti järjestelmiensä telakointikuvista. DevOps tarjoaa käyttöönoton edellyttämän yleisen infrastruktuurin, eli tuen itse klusterille, tuen CI-järjestelmälle ja niin edelleen. Ja tuolloin meillä oli yli 60 järjestelmää siirretty Nomadille, mikä oli noin 2 tuhatta konttia.

Devops vastaa kaiken käyttöönottoon ja palvelimiin liittyvästä yleisestä infrastruktuurista. Ja jokainen kehitystiimi puolestaan ​​on vastuussa konttien käyttöönotosta tietylle järjestelmälleen, koska se on se, joka tietää, mitä se yleensä tarvitsee tietyssä säiliössä.

Syitä Nomadin hylkäämiseen

Mitä etuja saimme siirtymällä käyttöön muun muassa Nomadilla ja dockerilla?

1. me tarjosi yhtäläiset ehdot kaikkiin ympäristöihin. Kehityksessä, laadunvarmistusympäristössä, esituotannossa, tuotannossa käytetään samoja konttikuvia samoilla riippuvuuksilla. Näin ollen sinulla ei ole käytännössä mitään mahdollisuutta, että se, mikä päätyy tuotantoon, ei ole sitä, mitä olet aiemmin testannut paikallisesti tai testiympäristössäsi.
2. Huomasimme myös, että se riittää helppo lisätä uusi palvelu. Käyttöönoton näkökulmasta kaikki uudet järjestelmät käynnistetään hyvin yksinkertaisesti. Mene vain arkistoon, joka tallentaa asetukset, lisää sinne toinen kokoonpano järjestelmällesi, ja olet valmis. Voit ottaa järjestelmäsi käyttöön tuotantoon ilman devopsin lisäponnistuksia.
3. kaikki asetustiedostot yhdessä yhteisessä arkistossa osoittautui tarkastettavaksi. Kun otimme järjestelmiämme käyttöön virtuaalipalvelimilla, käytimme Ansiblea, jonka konfiguraatiot olivat samassa arkistossa. Useimmille kehittäjille tämä oli kuitenkin hieman vaikeampaa työskennellä. Täällä palvelun käyttöönottoa varten lisättävien asetusten ja koodin määrä on pienentynyt paljon. Lisäksi devopsin on erittäin helppo korjata tai muuttaa se. Esimerkiksi siirtymävaiheessa Nomadin uuteen versioon he voivat päivittää joukkopäivityksiä kaikki samassa paikassa sijaitsevat käyttötiedostot.

Mutta kohtasimme myös useita haittoja:

Kävi ilmi, että me ei onnistunut saavuttamaan saumattomia käyttöönottoja Nomadin tapauksessa. Kun kontteja rullattiin eri olosuhteissa, se saattoi osoittautua käynnissä, ja Nomad piti sitä konttina, joka oli valmis vastaanottamaan liikennettä. Tämä tapahtui ennen kuin sen sisällä oleva sovellus ehti edes käynnistää. Tästä syystä järjestelmä alkoi tuottaa 500 virhettä lyhyen ajan, koska liikenne alkoi mennä konttiin, joka ei ollut vielä valmis ottamaan sitä vastaan.

Tapasimme joitain soiden varrella. Merkittävin vika on, että Nomad ei käsittele suurta klusteria kovin hyvin, jos sinulla on monia järjestelmiä ja kontteja. Kun haluat viedä jonkin Nomad-klusteriin kuuluvan palvelimen huoltoon, on melko suuri todennäköisyys, että klusteri ei tunnu kovin hyvältä ja hajoaa. Jotkut säiliöt voivat esimerkiksi pudota eikä nousta - tämä maksaa sinulle myöhemmin paljon, jos kaikki tuotantojärjestelmäsi sijaitsevat Nomadin hallinnoimassa klusterissa.

Joten päätimme miettiä, minne meidän pitäisi mennä seuraavaksi. Siinä vaiheessa tulimme paljon tietoisemmiksi siitä, mitä halusimme saavuttaa. Nimittäin: haluamme luotettavuutta, hieman enemmän toimintoja kuin Nomad tarjoaa, ja kypsemmän, vakaamman järjestelmän.

Tässä suhteessa valintamme osui Kubernetesiin suosituimpana alustana klusterien käynnistämiseen. Varsinkin kun otetaan huomioon, että konttiemme koko ja lukumäärä oli riittävän suuri. Tällaisiin tarkoituksiin Kubernetes näytti olevan sopivin järjestelmä, jota voimme tarkastella.

Siirtyminen Kubernetesiin

Kerron sinulle hieman Kubernetesin peruskonsepteista ja kuinka ne eroavat Nomadista.

Ensinnäkin Kubernetesin peruskonsepti on pod-konsepti. Palko on ryhmä yhdestä tai useammasta säiliöstä, jotka kulkevat aina yhdessä. Ja ne toimivat aina ikään kuin tiukasti yhdessä virtuaalikoneessa. Ne ovat käytettävissä toistensa IP 127.0.0.1 kautta eri porteissa.

Oletetaan, että sinulla on PHP-sovellus, joka koostuu nginx:stä ja php-fpm:stä - klassisesta järjestelmästä. Todennäköisesti haluat pitää sekä nginx- että php-fpm-säiliöt yhdessä koko ajan. Kubernetes antaa sinun saavuttaa tämän kuvaamalla niitä yhdeksi yhteiseksi podiksi. Juuri tätä emme voineet saada Nomadin kanssa.

Toinen käsite on käyttöönotto. Tosiasia on, että itse pod on ohimenevä asia; se alkaa ja katoaa. Haluatko tappaa ensin kaikki aiemmat säilösi ja käynnistää sen jälkeen uudet versiot kerralla vai haluatko ottaa ne käyttöön asteittain? Tämä on prosessi, josta käyttöönottokonsepti vastaa. Siinä kuvataan, kuinka otat podit käyttöön, kuinka paljon ja kuinka ne päivitetään.

Kolmas käsite on palvelu. Palvelusi on itse asiassa järjestelmäsi, joka vastaanottaa jonkin verran liikennettä ja välittää sen sitten yhteen tai useampaan palveluasi vastaavaan podiin. Toisin sanoen sen avulla voit sanoa, että kaikki saapuva liikenne sellaiseen ja sellaiseen palveluun tällä ja sellaisella nimellä on lähetettävä näihin tiettyihin koteloihin. Ja samalla se tarjoaa sinulle liikenteen tasapainotuksen. Toisin sanoen voit käynnistää sovelluksesi kaksi podia, ja kaikki saapuva liikenne tasapainotetaan tasaisesti tähän palveluun liittyvien podien välillä.

Ja neljäs peruskäsite on Sisääntulo. Tämä on palvelu, joka toimii Kubernetes-klusterissa. Se toimii ulkoisena kuormantasaajana, joka ottaa haltuunsa kaikki pyynnöt. Kubernetes API:n avulla Ingress voi määrittää, minne nämä pyynnöt tulee lähettää. Lisäksi hän tekee tämän erittäin joustavasti. Voit sanoa, että kaikki pyynnöt tälle isännälle ja sellaisille URL-osoitteille lähetetään tälle palvelulle. Ja nämä tälle isännälle ja toiseen URL-osoitteeseen tulevat pyynnöt lähetetään toiseen palveluun.

Siisteintä sovelluksen kehittäjän näkökulmasta on, että voit hallita kaikkea itse. Asettamalla Ingress-konfiguraation voit lähettää kaiken sellaiseen API:hen tulevan liikenteen erillisiin, esim. Go:lla kirjoitettuihin säilöihin. Mutta tämä liikenne, joka tulee samaan verkkotunnukseen, mutta eri URL-osoitteeseen, tulisi lähettää PHP:llä kirjoitettuihin säilöihin, joissa on paljon logiikkaa, mutta ne eivät ole kovin nopeita.

Jos vertaamme kaikkia näitä käsitteitä Nomadiin, voimme sanoa, että kolme ensimmäistä käsitettä ovat kaikki yhdessä Palvelu. Ja viimeinen käsite puuttuu itse Nomadista. Käytimme ulkoista tasapainotinta sellaisenaan: se voisi olla haproxy, nginx, nginx+ ja niin edelleen. Kuution tapauksessa sinun ei tarvitse esitellä tätä lisäkonseptia erikseen. Jos kuitenkin katsot Ingressiä sisäisesti, se on joko nginx, haproxy tai traefik, mutta tavallaan Kubernetesiin sisäänrakennettu.

Kaikki kuvailemani käsitteet ovat itse asiassa Kubernetes-klusterissa olevia resursseja. Niiden kuvaamiseen kuutiossa käytetään yaml-muotoa, joka on Nomadin tapauksessa luettavampi ja tutumpi kuin HCL-tiedostot. Mutta rakenteellisesti ne kuvaavat samaa asiaa esimerkiksi podin tapauksessa. He sanovat - haluan sijoittaa sinne sellaisia ​​​​ja sellaisia ​​​​tyynyjä, sellaisilla ja sellaisilla kuvilla, sellaisina ja sellaisina määrinä.

Lisäksi ymmärsimme, että emme halunneet luoda jokaista yksittäistä resurssia käsin: käyttöönotto, palvelut, sisääntulo jne. Sen sijaan halusimme kuvata jokaista järjestelmäämme Kubernetesin avulla käyttöönoton aikana, jotta meidän ei tarvitsisi luoda manuaalisesti kaikkia tarvittavia resurssiriippuvuuksia oikeassa järjestyksessä. Helm valittiin järjestelmäksi, joka mahdollisti tämän.

Peruskäsitteet Helmissä

Ruori on paketin hallinta Kubernetesille. Se on hyvin samankaltainen kuin ohjelmointikielten paketinhallintaohjelmat. Niiden avulla voit tallentaa palvelun, joka koostuu esimerkiksi nginx:n käyttöönotosta, käyttöönotto php-fpm:stä, Ingressin konfiguroinnista, configmapsista (tämä on entiteetti, jonka avulla voit asettaa env:n ja muita parametreja järjestelmällesi) ns. kutsutaan kaavioiksi. Samaan aikaan Helmi kulkee Kubernetesin päällä. Tämä ei siis ole mikään sivussa seisova järjestelmä, vaan vain yksi kuution sisällä käynnistetty palvelu. Voit olla vuorovaikutuksessa sen kanssa sen API:n kautta konsolikomennon kautta. Sen mukavuus ja kauneus on, että vaikka ruori rikkoutuisi tai poistaisit sen klusterista, palvelusi eivät katoa, koska ruori lähinnä vain käynnistää järjestelmän. Kubernetes itse vastaa sitten palvelujen toimivuudesta ja tilasta.

Tajusimme myös sen mallinnus, jonka jouduimme aiemmin tekemään itse ottamalla jinjaa asetuksiin, on yksi ruorin pääominaisuuksista. Kaikki järjestelmillesi luomasi konfiguraatiot on tallennettu ruoriin mallipohjina, jotka ovat vähän samanlaisia ​​kuin jinja, mutta itse asiassa Go-kielen mallipohjalla, jossa ruori on kirjoitettu, kuten Kubernetes.

Helm lisää meille muutaman käsitteen.

Kaavio - tämä on kuvaus palvelustasi. Muissa paketinhallinnassa sitä kutsutaan paketiksi, paketiksi tai vastaavaksi. Tässä sitä kutsutaan kaavioksi.

arvot ovat muuttujia, joita haluat käyttää konfiguraatioiden rakentamiseen malleista.

Vapauta. Joka kerta kun ruoria käyttämällä käyttöön otettu palvelu vastaanottaa julkaisun lisäversion. Helm muistaa, mikä palvelukonfiguraatio oli edellisessä julkaisussa, sitä edeltävässä julkaisussa ja niin edelleen. Siksi, jos haluat peruuttaa, suorita ruorisoittokomento osoittaen sen edelliseen julkaisuversioon. Vaikka vastaava kokoonpano arkistossasi ei olisi käytettävissä palautushetkellä, ruori muistaa silti, mikä se oli, ja palauttaa järjestelmän tilaan, jossa se oli edellisessä julkaisussa.

Jos käytämme ruoria, Kubernetesin tavalliset konfiguraatiot muuttuvat myös malleiksi, joissa on mahdollista käyttää muuttujia, funktioita ja soveltaa ehdollisia lausekkeita. Tällä tavalla voit kerätä palvelukokoonpanosi ympäristöstä riippuen.

Käytännössä päätimme tehdä asiat hieman eri tavalla kuin teimme Nomadin kanssa. Jos Nomadissa sekä käyttöönottokonfiguraatiot että n-muuttujat, jotka tarvittiin palvelumme käyttöön, oli tallennettu yhteen arkistoon, päätimme tässä jakaa ne kahteen erilliseen arkistoon. "Deploy"-arkisto tallentaa vain käyttöönoton edellyttämät n-muuttujat, ja "helm"-arkisto tallentaa konfiguraatiot tai kaaviot.

Mitä tämä antoi meille?

Huolimatta siitä, että emme tallenna itse asetustiedostoihin mitään todella arkaluontoista tietoa. Esimerkiksi tietokantojen salasanat. Ne on tallennettu salaisuuksiksi Kubernetesiin, mutta silti siellä on tiettyjä asioita, joihin emme halua antaa kaikkien pääsyä. Siksi pääsy "käyttöönotto"-tietovarastoon on rajoitetumpi, ja "ruori"-tietovarasto sisältää yksinkertaisesti kuvauksen palvelusta. Tästä syystä useammille ihmisille pääsee turvallisesti käsiksi.

Koska meillä ei ole vain tuotantoa vaan myös muita ympäristöjä, voimme tämän erottelun ansiosta käyttää ruorikaavioitamme uudelleen palvelujen käyttöönottamiseksi paitsi tuotantoon myös esimerkiksi laadunvarmistusympäristöön. Jopa ottaa ne käyttöön paikallisesti Minikube - Tämä on asia Kubernetesin paikalliseen pyörittämiseen.

Jokaisen arkiston sisällä jätimme jokaiselle palvelulle jaon erillisiin hakemistoihin. Toisin sanoen kunkin hakemiston sisällä on malleja, jotka liittyvät vastaavaan kaavioon ja kuvaavat resursseja, jotka on otettava käyttöön järjestelmämme suorittamiseksi. Jätimme vain env:t "käyttöön"-arkistoon. Tässä tapauksessa emme käyttäneet mallinnusta jinjalla, koska ruori itsessään tarjoaa mallin pois laatikosta - tämä on yksi sen päätehtävistä.

Jätimme käyttöön käyttöönottokomentosarjan - deploy.sh, joka yksinkertaistaa ja standardoi käynnistämisen ruorin avulla tapahtuvaa käyttöönottoa varten. Joten kaikille, jotka haluavat ottaa käyttöön, käyttöönottoliittymä näyttää täsmälleen samalta kuin Nomadin kautta käyttöön otettaessa. Sama deploy.sh, palvelusi nimi ja paikka, jossa haluat ottaa sen käyttöön. Tämä saa ruori käynnistymään sisäisesti. Se puolestaan ​​​​kerää konfiguraatiot malleista, lisää niihin tarvittavat arvotiedostot, ottaa ne käyttöön ja käynnistää ne Kubernetesiin.

Tulokset

Kubernetes-palvelu näyttää olevan monimutkaisempi kuin Nomad.

Täältä lähtevä liikenne tulee Ingressiin. Tämä on vain etuohjain, joka ottaa haltuunsa kaikki pyynnöt ja lähettää ne myöhemmin pyyntötietoja vastaaville palveluille. Se määrittää ne asetusten perusteella, jotka ovat osa sovelluksesi kuvausta ruorissa ja jotka kehittäjät asettavat itse. Palvelu lähettää pyyntöjä podeihinsa eli tiettyihin kontteihin tasapainottaen saapuvan liikenteen kaikkien tähän palveluun kuuluvien konttien välillä. Ja tietenkään meidän ei pidä unohtaa, että verkkotason turvallisuudesta ei pitäisi mennä minnekään. Siksi segmentointi toimii Kubernetes-klusterissa, joka perustuu taggaukseen. Kaikilla palveluilla on tietyt tunnisteet, joihin on liitetty palveluiden käyttöoikeudet tiettyihin ulkoisiin/sisäisiin resursseihin klusterin sisällä tai ulkopuolella.

Kun teimme muutoksen, huomasimme, että Kubernetesilla oli kaikki aiemmin käyttämämme Nomadin ominaisuudet ja lisätty myös paljon uutta. Sitä voidaan laajentaa lisäosien ja itse asiassa mukautettujen resurssityyppien avulla. Toisin sanoen sinulla on mahdollisuus ei vain käyttää jotain, joka tulee Kuberneteksen mukana heti, vaan myös luoda oma resurssi ja palvelu, joka lukee resurssi. Tämä antaa sinulle lisävaihtoehtoja järjestelmän laajentamiseen ilman, että sinun tarvitsee asentaa Kubernetes uudelleen ja ilman muutoksia.

Esimerkki tällaisesta käytöstä on Prometheus, joka toimii Kubernetes-klusterimme sisällä. Jotta se voisi alkaa kerätä mittareita tietystä palvelusta, meidän on lisättävä palvelun kuvaukseen ylimääräinen resurssityyppi, niin kutsuttu palvelumonitori. Prometheus alkaa automaattisesti kerätä mittareita uudesta järjestelmästä, koska se voi lukea mukautetun resurssityypin, kun se käynnistetään Kubernetesissa. Se on varsin kätevää.

Ensimmäinen käyttöönotto Kubernetesiin tapahtui maaliskuussa 2018. Ja tänä aikana meillä ei ole koskaan ollut mitään ongelmia sen kanssa. Se toimii melko vakaasti ilman merkittäviä bugeja. Lisäksi voimme laajentaa sitä edelleen. Nykyään meillä on tarpeeksi sen ominaisuuksia, ja pidämme todella Kubernetesin kehitysvauhdista. Tällä hetkellä Kubernetesissa on yli 3000 XNUMX konttia. Klusteri käsittää useita solmuja. Samalla se on huollettava, vakaa ja hyvin hallittavissa.

Lähde: will.com