werf - työkalumme CI:lle / CD:lle Kubernetesissa (yleiskatsaus ja videoraportti)

27. toukokuuta DevOpsConf 2019 -konferenssin pääsalissa, osana festivaaleja RIT++ 2019, osana "Jatkuva toimitus" -osaa annettiin raportti "werf - työkalumme CI/CD:lle Kubernetesissa". Se puhuu niistä ongelmia ja haasteita, joita jokainen kohtaa ottaessaan käyttöön Kubernetesiin, sekä vivahteista, joita ei välttämättä heti huomaa. Analysoimme mahdollisia ratkaisuja, näytämme kuinka tämä toteutetaan avoimen lähdekoodin työkalussa werf.

Esityksen jälkeen apuohjelmamme (aiemmin dapp) on saavuttanut historiallisen virstanpylvään 1000 tähteä GitHubissa — Toivomme, että sen kasvava käyttäjäyhteisö helpottaa monien DevOps-insinöörien elämää.

Joten esittelemme video raportista (~47 minuuttia, paljon informatiivisempi kuin artikkeli) ja pääote siitä tekstimuodossa. Mennä!

Koodi toimitetaan Kubernetesille

Puhu ei enää koske werfiä, vaan Kubernetesin CI/CD:tä, mikä tarkoittaa, että ohjelmistomme on pakattu Docker-säiliöihin. (Keskustin tästä vuonna 2016 raportti), ja K8:aa käytetään sen suorittamiseen tuotannossa (Tästä lisää osoitteessa 2017 vuosi).

Miltä toimitus Kubernetesissa näyttää?

• Siellä on Git-arkisto, jossa on koodi ja ohjeet sen rakentamiseen. Sovellus on sisäänrakennettu Docker-kuvaan ja julkaistu Dockerin rekisterissä.
• Sama arkisto sisältää myös ohjeet sovelluksen käyttöönotosta ja suorittamisesta. Käyttöönottovaiheessa nämä ohjeet lähetetään Kubernetesille, joka vastaanottaa halutun kuvan rekisteristä ja käynnistää sen.
• Lisäksi on yleensä testejä. Jotkut näistä voidaan tehdä kuvia julkaistaessa. Voit myös (samoja ohjeita noudattaen) ottaa käyttöön kopion sovelluksesta (erilliseen K8s-nimiavaruuteen tai erilliseen klusteriin) ja suorittaa testejä siellä.
• Lopuksi tarvitset CI-järjestelmän, joka vastaanottaa tapahtumat Gitistä (tai painikkeen napsautukset) ja kutsuu kaikki määritetyt vaiheet: build, julkaise, ota käyttöön, testaa.

Tässä on muutama tärkeä huomautus:

1. Koska meillä on muuttumaton infrastruktuuri (muuttumaton infrastruktuuri), sovelluskuva, jota käytetään kaikissa vaiheissa (lavastaminen, tuotanto jne.), täytyy olla yksi. Puhuin tästä tarkemmin ja esimerkein. täällä.
2. Koska noudatamme infrastruktuuria koodilähestymistapana (IaC), sovelluskoodi, ohjeet sen kokoamiseen ja käynnistämiseen täsmälleen yhdessä arkistossa. Lisätietoja tästä on kohdassa sama raportti.
3. Toimitusketju (toimitus) näemme sen yleensä näin: sovellus koottiin, testattiin, vapautettiin (julkaisuvaihe) ja siinä kaikki - toimitus on tapahtunut. Mutta todellisuudessa käyttäjä saa sen, mitä julkaisit, ei sitten kun toimitit sen tuotantoon, ja kun hän pääsi sinne ja tämä tuotanto toimi. Joten uskon, että toimitusketju päättyy vasta käyttövaiheessa (juosta), tai tarkemmin sanottuna jopa sillä hetkellä, kun koodi poistettiin tuotannosta (korvaamalla se uudella).

Palataanpa yllä olevaan Kubernetesin toimitusjärjestelmään: sen keksimme paitsi me, vaan kirjaimellisesti kaikki, jotka käsittelivät tätä ongelmaa. Itse asiassa tätä mallia kutsutaan nyt nimellä GitOps (voit lukea lisää termistä ja sen takana olevista ideoista täällä). Katsotaanpa järjestelmän vaiheita.

Rakenna vaihe

Vaikuttaa siltä, ​​​​että voit puhua Docker-kuvien rakentamisesta vuonna 2019, kun kaikki osaavat kirjoittaa Docker-tiedostoja ja ajaa docker build?.. Tässä ovat vivahteet, joihin haluaisin kiinnittää huomiota:

1. Kuvan paino väliä, joten käytä monivaiheinenjättää kuvaan vain sovelluksen, joka on todella tarpeellinen toimintoa varten.
2. Kerrosten lukumäärä tulee minimoida yhdistämällä ketjuja RUN-käskyt merkityksen mukaan.
3. Tämä kuitenkin lisää ongelmia virheenkorjaus, koska kun kokoonpano kaatuu, sinun on löydettävä oikea komento ongelman aiheuttaneesta ketjusta.
4. Kokoonpanon nopeus tärkeä, koska haluamme ottaa muutokset käyttöön nopeasti ja nähdä tulokset. Et esimerkiksi halua rakentaa uudelleen riippuvuuksia kielikirjastoista joka kerta, kun rakennat sovelluksen.
5. Usein yhdestä tarvitsemastasi Git-arkistosta monia kuvia, joka voidaan ratkaista joukolla Docker-tiedostoja (tai nimettyjä vaiheita yhdessä tiedostossa) ja Bash-skriptillä niiden peräkkäisellä kokoonpanolla.

Tämä oli vain jäävuoren huippu, jonka kaikki kohtaavat. Mutta on muitakin ongelmia, erityisesti:

1. Usein kokoonpanovaiheessa tarvitsemme jotain kiinnitys (esimerkiksi välimuistiin komennon, kuten apt, tulos kolmannen osapuolen hakemistoon).
2. Me haluamme Ansible kuoreen kirjoittamisen sijaan.
3. Me haluamme rakentaa ilman Dockeria (miksi tarvitsemme ylimääräisen virtuaalikoneen, jossa meidän on määritettävä kaikki tätä varten, kun meillä on jo Kubernetes-klusteri, jossa voimme ajaa säiliöitä?).
4. Rinnakkaiskokoonpano, joka voidaan ymmärtää eri tavoin: eri komennot Docker-tiedostosta (jos käytetään monivaiheista), useita saman arkiston committeja, useita Docker-tiedostoja.
5. Hajautettu kokoonpano: Haluamme kerätä asioita koteloihin, jotka ovat "lyhyitä", koska niiden välimuisti katoaa, mikä tarkoittaa, että se on tallennettava jonnekin erikseen.
6. Lopuksi nimesin toiveiden huipun automaattinen: Olisi ihanteellista mennä arkistoon, kirjoittaa jokin komento ja saada valmis kuva, joka on koottu ymmärrykseen siitä, miten ja mitä tehdä oikein. En kuitenkaan ole varma, että kaikki vivahteet voidaan ennakoida tällä tavalla.

Ja tässä projektit:

• moby/buildkit — Docker Inc:n rakentaja (jo on integroitu Dockerin nykyisiin versioihin), joka yrittää ratkaista kaikki nämä ongelmat;
• kaniko - Googlen rakentaja, jonka avulla voit rakentaa ilman Dockeria;
• Buildpacks.io — CNCF:n yritys tehdä automaattista taikuutta ja erityisesti mielenkiintoista ratkaisua, jossa kerroksia voidaan käyttää uudelleen;
• ja joukko muita apuohjelmia, kuten rakennus, aidot työkalut/kuva...

...ja katso kuinka monta tähteä heillä on GitHubissa. Eli toisaalta docker build on olemassa ja voi tehdä jotain, mutta todellisuudessa ongelmaa ei ole täysin ratkaistu - Todisteena tästä on vaihtoehtoisten keräilijöiden rinnakkainen kehittäminen, joista jokainen ratkaisee osan ongelmista.

Asennus werfissä

Joten meidän täytyy werf (ent kuuluisa kuten dapp) — Flant-yhtiön avoimen lähdekoodin apuohjelma, jota olemme tehneet vuosia. Kaikki alkoi 5 vuotta sitten Bash-skripteistä, jotka optimoivat Dockerfiles-kokoonpanon, ja viimeiset 3 vuotta on tehty täysimittaista kehitystä yhden projektin puitteissa, jossa on oma Git-varasto. (ensin Rubyssa ja sitten kopioitu mennä, ja samalla nimetty uudelleen). Mitä kokoonpanoongelmia werf:ssä on ratkaistu?

Sinisillä varjostetut ongelmat on jo toteutettu, rinnakkaisrakennus tehtiin saman isännön sisällä ja keltaisella korostetut asiat on tarkoitus saada valmiiksi kesän loppuun mennessä.

Julkaisuvaihe rekisterissä (julkaisu)

Soitimme docker push... - mikä voi olla vaikeaa kuvan lataamisessa rekisteriin? Ja sitten herää kysymys: "Mikä tunniste minun pitäisi laittaa kuvaan?" Se syntyy siitä syystä, että meillä on Gitflow (tai muu Git-strategia) ja Kubernetes, ja teollisuus yrittää varmistaa, että se, mitä tapahtuu Kubernetesissa, seuraa sitä, mitä tapahtuu Gitissä. Loppujen lopuksi Git on ainoa totuuden lähdemme.

Mikä tässä on niin vaikeaa? Varmista toistettavuus: Gitissä tehdystä sitoumuksesta, joka on luonteeltaan muuttumaton (muuttumaton), Docker-kuvaksi, joka tulee säilyttää samana.

Se on myös meille tärkeää määrittää alkuperä, koska haluamme ymmärtää, mistä commitista Kubernetesissa toimiva sovellus on rakennettu (silloin voimme tehdä diffejä ja vastaavia).

Merkintästrategiat

Ensimmäinen on yksinkertainen git tag. Meillä on rekisteri, jossa on kuva, joka on merkitty nimellä 1.0. Kubernetes on näyttämö ja tuotanto, jonne tämä kuva ladataan. Gitissä teemme sitoumuksia ja jossain vaiheessa tagimme 2.0. Keräämme sen arkistosta saatujen ohjeiden mukaan ja asetamme sen tunnisteen kanssa rekisteriin 2.0. Viemme sen lavalle ja, jos kaikki on hyvin, sitten tuotantoon.

Tämän lähestymistavan ongelmana on, että laitoimme ensin tunnisteen ja vasta sitten testasimme ja julkaisimme sen. Miksi? Ensinnäkin se on yksinkertaisesti epäloogista: julkaisemme ohjelmistoversion, jota emme ole vielä edes testaaneet (emme voi tehdä toisin, koska tarkistamista varten meidän on laitettava tunniste). Toiseksi tämä polku ei ole yhteensopiva Gitflow: n kanssa.

Toinen vaihtoehto - git commit + tag. Päähaaralla on tunniste 1.0; sitä varten rekisterissä - tuotantoon otettu kuva. Lisäksi Kubernetes-klusterissa on esikatselu- ja lavastusääriviivat. Seuraavaksi seuraamme Gitflow:a: kehittämisen päähaarassa (develop) teemme uusia ominaisuuksia, jotka johtavat sitoutumiseen tunnisteen kanssa #c1. Keräämme sen ja julkaisemme sen rekisterissä tällä tunnisteella (#c1). Samalla tunnisteella siirrymme esikatseluun. Teemme samoin sitoumusten kanssa #c2 и #c3.

Kun tajusimme, että ominaisuuksia on tarpeeksi, alamme vakauttaa kaikkea. Luo haara Gitissä release_1.1 (pohjassa #c3 ja develop). Tätä julkaisua ei tarvitse kerätä, koska... tämä tehtiin edellisessä vaiheessa. Siksi voimme yksinkertaisesti viedä sen lavastukseen. Korjaamme vikoja #c4 ja samoin rullata lavalle. Samaan aikaan kehitystyö on käynnissä develop, josta muutokset otetaan ajoittain release_1.1. Jossain vaiheessa saamme kootun ja ladattavan lavastusta koskevan sitoumuksen, johon olemme tyytyväisiä (#c25).

Sitten yhdistämme (pikakelauksen kanssa) vapautushaaran (release_1.1) mestarissa. Laitoimme tagin uudella versiolla tähän sitoumukseen (1.1). Mutta tämä kuva on jo kerätty rekisteriin, joten jotta sitä ei kerätä uudelleen, lisäämme vain toisen tunnisteen olemassa olevaan kuvaan (nyt siinä on tunnisteet rekisterissä #c25 и 1.1). Sen jälkeen viemme sen tuotantoon.

Haittapuolena on, että vain yksi kuva ladataan lavastukseen (#c25), ja tuotannossa se on tavallaan erilainen (1.1), mutta tiedämme, että "fyysisesti" nämä ovat sama kuva rekisteristä.

Todellinen haittapuoli on, että yhdistämissitoumuksia ei tueta, sinun on tehtävä pikakelaus.

Voimme mennä pidemmälle ja tehdä tempun... Katsotaanpa esimerkkiä yksinkertaisesta Docker-tiedostosta:

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

Rakennetaan siitä tiedosto seuraavan periaatteen mukaisesti:

• SHA256 käytettyjen kuvien tunnisteista (ruby:2.3 и nginx:alpine), jotka ovat niiden sisällön tarkistussummia;
• kaikki joukkueet (RUN, CMD ja niin edelleen.);
• SHA256 lisätyistä tiedostoista.

... ja ota tarkistussumma (jälleen SHA256) tällaisesta tiedostosta. Tämä allekirjoitus kaikki, mikä määrittää Docker-kuvan sisällön.

Palataan kaavioon ja sitoumusten sijasta käytämme tällaisia ​​allekirjoituksia, eli merkitse kuvat allekirjoituksilla.

Nyt kun on tarpeen esimerkiksi yhdistää muutoksia julkaisusta masteriin, voimme tehdä todellisen yhdistämistoimituksen: sillä on eri tunniste, mutta sama allekirjoitus. Samalla tunnisteella viemme kuvan tuotantoon.

Haittapuolena on, että nyt ei ole mahdollista määrittää, millaista sitoutumista tuotantoon työnnettiin - tarkistussummat toimivat vain yhteen suuntaan. Tämä ongelma on ratkaistu lisäkerroksella, jossa on metatietoja - kerron sinulle lisää myöhemmin.

Merkintä werfissä

Werfissä menimme vielä pidemmälle ja valmistaudumme tekemään hajautetun koontiversion välimuistilla, jota ei ole tallennettu yhdelle koneelle... Joten, rakennamme kahdenlaisia ​​Docker-kuvia, kutsumme niitä vaihe и kuva.

werf Git -varasto tallentaa koontiversiokohtaiset ohjeet, jotka kuvaavat koontiversion eri vaiheita (ennen asennusta, asentaa, ennen asennusta, setup). Keräämme ensimmäisen vaiheen kuvan allekirjoituksella, joka määritellään ensimmäisten vaiheiden tarkistussummaksi. Sitten lisätään lähdekoodi, uudelle lavakuvalle lasketaan sen tarkistussumma... Nämä toiminnot toistetaan kaikille vaiheille, minkä seurauksena saamme sarjan lavakuvia. Sitten tehdään lopullinen kuva, joka sisältää myös metatiedot sen alkuperästä. Ja merkitsemme tämän kuvan eri tavoilla (yksityiskohdat myöhemmin).

Oletetaan, että tämän jälkeen ilmestyy uusi toimitus, jossa vain sovelluskoodi on muutettu. Mitä tapahtuu? Koodimuutoksia varten luodaan korjaustiedosto ja valmistetaan uusi vaihekuva. Sen allekirjoitus määritetään vanhan näyttämökuvan ja uuden paikan tarkistussummaksi. Tästä kuvasta muodostetaan uusi lopullinen kuva. Samanlainen käyttäytyminen tapahtuu muissa vaiheissa tapahtuvien muutosten yhteydessä.

Lavakuvat ovat siis välimuisti, joka voidaan tallentaa hajautetusti ja josta jo luodut kuvat ladataan Docker-rekisteriin.

Rekisterin puhdistaminen

Emme puhu sellaisten tasojen poistamisesta, jotka jäivät roikkumaan poistettujen tunnisteiden jälkeen - tämä on itse Docker-rekisterin vakioominaisuus. Puhumme tilanteesta, jossa Docker-tageja kertyy paljon ja ymmärrämme, että emme enää tarvitse niitä, mutta ne vievät tilaa (ja/tai maksamme siitä).

Mitkä ovat puhdistusstrategiat?

1. Et voi vain tehdä mitään älä siivoa. Joskus on todella helpompaa maksaa vähän ylimääräisestä tilasta kuin purkaa valtava tageja. Mutta tämä toimii vain tiettyyn pisteeseen asti.
2. Täysi nollaus. Jos poistat kaikki kuvat ja rakennat uudelleen vain nykyiset CI-järjestelmässä, saattaa ilmetä ongelma. Jos kontti käynnistetään uudelleen tuotannossa, sille ladataan uusi kuva - sellainen, jota kukaan ei ole vielä testannut. Tämä tappaa ajatuksen muuttumattomasta infrastruktuurista.
3. Sinivihreä. Yksi rekisteri alkoi täyttyä - lataamme kuvia toiseen. Sama ongelma kuin edellisessä menetelmässä: missä vaiheessa voit tyhjentää rekisterin, joka on alkanut vuotaa?
4. Ajan kanssa. Poistetaanko kaikki yli kuukauden vanhemmat kuvat? Mutta varmasti tulee palvelu, jota ei ole päivitetty kuukauteen...
5. käsin määrittää, mitä voidaan jo poistaa.

On olemassa kaksi todella käyttökelpoista vaihtoehtoa: älä puhdista tai sinivihreä + manuaalinen yhdistelmä. Jälkimmäisessä tapauksessa puhumme seuraavasta: kun ymmärrät, että on aika puhdistaa rekisteri, luot uuden ja lisäät siihen kaikki uudet kuvat esimerkiksi kuukauden aikana. Kuukauden kuluttua katso, mitkä Kubernetesin podit käyttävät edelleen vanhaa rekisteriä, ja siirrä myös ne uuteen rekisteriin.

Mihin olemme tulleet werf? Keräämme:

1. Git head: kaikki tagit, kaikki haarat, olettaen, että tarvitsemme kaiken, mikä on merkitty kuviin Gitissä (ja jos ei, niin se on poistettava itse Gitistä);
2. kaikki palot, jotka tällä hetkellä pumpataan Kubernetesiin;
3. vanhat ReplicaSets (mikä julkaistiin äskettäin), ja aiomme myös skannata Helm-julkaisut ja valita sieltä uusimmat kuvat.

... ja tee tästä sarjasta sallittujen luettelo - luettelo kuvista, joita emme poista. Puhdistamme kaiken muun, jonka jälkeen löydämme orpolavakuvat ja poistamme nekin.

Käyttöönottovaihe

Luotettavaa deklaratiivisuutta

Ensimmäinen kohta, johon haluan kiinnittää huomion käyttöönotossa, on päivitetyn resurssikokoonpanon käyttöönotto, joka on ilmoitettu deklaratiivisesti. Alkuperäinen Kubernetes-resursseja kuvaava YAML-dokumentti on aina hyvin erilainen kuin klusterissa todellisuudessa käynnissä oleva tulos. Koska Kubernetes lisää kokoonpanoon:

1. tunnisteet;
2. palvelutiedot;
3. monia oletusarvoja;
4. osa nykytilasta;
5. muutokset, jotka on tehty osana pääsyn webhookia;
6. eri ohjaimien (ja ajastimen) työn tulos.

Siksi, kun uusi resurssimääritys tulee näkyviin (uusi), emme voi vain ottaa ja korvata nykyistä "live" kokoonpanoa sillä (elää). Tätä varten meidän on verrattava uusi viimeksi käytetyllä kokoonpanolla (viimeksi käytetty) ja rullaa päälle elää saanut laastari.

Tätä lähestymistapaa kutsutaan 2-suuntainen yhdistäminen. Sitä käytetään esimerkiksi Helmissa.

Siellä on myös 3-suuntainen yhdistäminen, joka eroaa siitä, että:

• vertaamalla viimeksi käytetty и uusi, katsomme mitä poistettiin;
• vertaamalla uusi и elää, katsomme, mitä on lisätty tai muutettu;
• summattu laastari kiinnitetään elää.

Otamme käyttöön yli 1000 sovellusta Helmin kanssa, joten elämme itse asiassa kaksisuuntaisen yhdistämisen kanssa. Siinä on kuitenkin useita ongelmia, jotka olemme ratkaisseet korjaustiedostoillamme, jotka auttavat Helmiä toimimaan normaalisti.

Todellinen käyttöönottotila

Kun CI-järjestelmämme luo uuden konfiguraation Kubernetesille seuraavan tapahtuman perusteella, se lähettää sen käytettäväksi (Käytä) klusteriin - käyttämällä Helmiä tai kubectl apply. Seuraavaksi tapahtuu jo kuvattu N-suuntainen yhdistäminen, johon Kubernetes API vastaa hyväksyvästi CI-järjestelmälle ja sen käyttäjälle.

On kuitenkin suuri ongelma: loppujen lopuksi onnistunut sovellus ei tarkoita onnistunutta käyttöönottoa. Jos Kubernetes ymmärtää, mitä muutoksia on tehtävä, ja soveltaa niitä, emme vielä tiedä, mikä on tulos. Esimerkiksi podien päivittäminen ja uudelleenkäynnistys käyttöliittymässä voi onnistua, mutta ei backendissä, ja saamme eri versioita käynnissä olevista sovelluskuvista.

Jotta kaikki tehdään oikein, tämä järjestelmä vaatii lisälinkin - erityisen seurantalaitteen, joka vastaanottaa tilatiedot Kubernetes API:lta ja lähettää sen asioiden todellisen tilan analysoimiseksi edelleen. Loimme avoimen lähdekoodin kirjaston Gossa - kuutiokoira (katso sen tiedote täällä), joka ratkaisee tämän ongelman ja on sisäänrakennettu werfiin.

Tämän jäljittimen käyttäytyminen werf-tasolla määritetään merkintöjen avulla, jotka on sijoitettu käyttöönottoihin tai StatefulSetsiin. Päämerkintä - fail-mode - ymmärtää seuraavat merkitykset:

• IgnoreAndContinueDeployProcess — jätämme huomiotta tämän komponentin käyttöönoton ongelmat ja jatkamme käyttöönottoa.
• FailWholeDeployProcessImmediately — virhe tässä komponentissa pysäyttää käyttöönottoprosessin;
• HopeUntilEndOfDeployProcess — Toivomme, että tämä komponentti toimii käyttöönoton loppuun mennessä.

Esimerkiksi tämä resurssien ja huomautusarvojen yhdistelmä fail-mode:

Kun otamme käyttöön ensimmäisen kerran, tietokanta (MongoDB) ei ehkä ole vielä valmis – käyttöönotto epäonnistuu. Mutta voit odottaa hetken, jolloin se alkaa, ja käyttöönotto tapahtuu silti.

Kubedogille werfissä on kaksi muuta merkintää:

• failures-allowed-per-replica — kunkin jäljennöksen sallittujen pudotusten lukumäärä;
• show-logs-until — säätelee hetkeä, johon asti werf näyttää (vakiomuotoisena) tukit kaikista rullatuista paloista. Oletus on PodIsReady (jätä huomioimatta viestit, joita emme luultavasti halua, kun liikennettä alkaa tulla podille), mutta arvot ovat myös voimassa: ControllerIsReady и EndOfDeploy.

Mitä muuta haluamme käyttöönotolta?

Kahden jo kuvatun kohdan lisäksi haluaisimme:

• nähdä lokit - ja vain välttämättömät, eikä kaikkea peräkkäin;
• seurata edistyminen, koska jos työ roikkuu "hiljaisesti" useita minuutteja, on tärkeää ymmärtää, mitä siellä tapahtuu;
• иметь automaattinen palautus jos jokin meni pieleen (ja siksi on tärkeää tietää käyttöönoton todellinen tila). Käyttöönoton on oltava atomista: joko se menee loppuun asti tai kaikki palaa entiseen tilaan.

Tulokset

Meille yritykselle CI-järjestelmä ja apuohjelma riittävät kaikkien kuvattujen vivahteiden toteuttamiseen eri toimitusvaiheissa (koonti, julkaise, ota käyttöön) werf.

Johtopäätöksen sijaan:

Werfin avulla olemme edistyneet hyvin useiden DevOps-insinöörien ongelmien ratkaisemisessa ja olisimme iloisia, jos laajempi yhteisö edes kokeilisi tätä apuohjelmaa toiminnassa. Yhdessä on helpompi saavuttaa hyvä tulos.

Videot ja diat

Video esityksestä (~47 minuuttia):

Raportin esittely:

PS.

Muita raportteja Kubernetesista blogissamme:

• «Automaattinen skaalaus ja resurssien hallinta Kubernetesissa» (Dmitry Stolyarov; 27. huhtikuuta 2019 "lakossa");
• «Kubernetesin laajentaminen ja täydentäminen» (Andrey Polovov; 8. huhtikuuta 2019 Saint HighLoad++:ssa);
• «Tietokannat ja Kubernetes» (Dmitry Stolyarov; 8. marraskuuta 2018 HighLoad++:ssa);
• «Valvonta ja Kubernetes» (Dmitry Stolyarov; 28. toukokuuta 2018 RootConfissa);
• «CI/CD parhaat käytännöt Kubernetesin ja GitLabin kanssa» (Dmitry Stolyarov; 7. marraskuuta 2017 HighLoad++:ssa);
• «Kokemuksemme Kubernetesista pienissä projekteissa» (Dmitry Stolyarov; 6. kesäkuuta 2017 RootConfissa).

Lähde: will.com