Aloitamme blogimme julkaisuilla, jotka perustuvat teknisen johtajamme viimeisimpiin puheisiin (Dmitry Stolyarov). Kaikki ne tapahtuivat vuonna 2016 erilaisissa ammattitapahtumissa ja olivat omistettu DevOps- ja Docker-aiheelle. Meillä on jo yksi video Docker Moskovan tapaamisesta Badoon toimistossa verkossa. Uusiin liitetään artikkeleita, joissa kerrotaan raporttien olemuksesta. Niin…
konferenssissa 31. toukokuuta , joka pidettiin osana "Russian Internet Technologies" (RIT++ 2016) -festivaalin "Continuous Deployment and Deployment" -osio avattiin raportilla "Best Practices of Continuous Delivery with Docker". Se tiivisti ja systematisoi parhaat käytännöt jatkuvan toimitusprosessin (CD) rakentamiseen Dockerin ja muiden avoimen lähdekoodin tuotteiden avulla. Työskentelemme näiden ratkaisujen kanssa tuotannossa, joten voimme luottaa käytännön kokemukseen.
Jos sinulla on mahdollisuus viettää tunti , suosittelemme katsomaan sen kokonaan. Muussa tapauksessa alla on päätiivistelmä tekstimuodossa.
Jatkuva toimitus Dockerin kanssa
alapuolella Jatkuva Toimitus ymmärrämme tapahtumaketjun, jonka seurauksena Git-arkiston sovelluskoodi tulee ensin tuotantoon ja päätyy sitten arkistoon. Se näyttää tältä: Git → Build → Test → Release → Operate.
Suurin osa raportista on omistettu rakennusvaiheelle (sovelluksen kokoonpano), ja julkaisu- ja toiminta-aiheita käsitellään lyhyesti. Puhumme ongelmista ja kaavoista, joiden avulla voit ratkaista ne, ja näiden mallien erityiset toteutukset voivat olla erilaisia.
Miksi Dockeria täällä ylipäätään tarvitaan? Ei ole turhaa, että päätimme puhua jatkuvan toimituksen käytännöistä tämän avoimen lähdekoodin työkalun yhteydessä. Vaikka koko raportti on omistettu sen käytölle, monia syitä paljastetaan, kun tarkastellaan sovelluskoodin käyttöönoton päämallia.
Päärullauskuvio
Joten kun otamme käyttöön uusia versioita sovelluksesta, kohtaamme varmasti seisokkiongelma, joka syntyy tuotantopalvelimen vaihdon aikana. Liikennettä sovelluksen vanhasta versiosta uuteen ei voi vaihtaa hetkessä: ensin on varmistettava, että uusi versio ei ole vain onnistuneesti ladattu, vaan myös "lämmitetty" (eli täysin valmis palvelemaan pyyntöjä).
Siten jonkin aikaa molemmat sovelluksen versiot (vanha ja uusi) toimivat samanaikaisesti. Mikä automaattisesti johtaa jaettujen resurssien ristiriita: verkko, tiedostojärjestelmä, IPC jne. Dockerin avulla tämä ongelma on helppo ratkaista ajamalla sovelluksen eri versioita erillisissä säilöissä, joiden resurssien eristäminen on taattu samassa isännässä (palvelin/virtuaalikone). Tietysti voit pärjätä joillakin temppuilla ilman eristystä, mutta jos on valmis ja kätevä työkalu, on päinvastainen syy - ei laiminlyödä sitä.
Säiliöinti tarjoaa monia muita etuja käyttöönoton yhteydessä. Mikä tahansa sovellus riippuu tietty versio (tai versiovalikoima) tulkki, moduulien/laajennusten jne. saatavuus sekä niiden versiot. Ja tämä ei koske vain välitöntä suoritettavaa ympäristöä, vaan myös koko ympäristöä, mukaan lukien järjestelmäohjelmisto ja sen versio (käytettävään Linux-jakeluun asti). Koska säilöissä ei ole vain sovelluskoodia, vaan myös esiasennettuja järjestelmä- ja sovellusohjelmistoja vaadituista versioista, voit unohtaa riippuvuuksiin liittyvät ongelmat.
me yleistää tärkein levityskuvio uudet versiot ottaen huomioon seuraavat tekijät:
- Aluksi sovelluksen vanha versio toimii ensimmäisessä säilössä.
- Uusi versio rullataan sitten ulos ja "lämmitetään" toisessa astiassa. On huomionarvoista, että tämä uusi versio itsessään saattaa sisältää päivitetyn sovelluskoodin lisäksi mitä tahansa sen riippuvuuksia sekä järjestelmäkomponentteja (esimerkiksi OpenSSL:n uusi versio tai koko jakelu).
- Kun uusi versio on täysin valmis palvelemaan pyyntöjä, liikenne siirtyy ensimmäisestä säilöstä toiseen.
- Vanha versio voidaan nyt pysäyttää.
Tämä lähestymistapa, jossa sovelluksen eri versioita otetaan käyttöön erillisissä säilöissä, tarjoaa toisen mukavuuden - nopea palautus vanhaan versioon (loppujen lopuksi riittää, kun siirrät liikenteen haluttuun säilöön).
Viimeinen ensimmäinen suositus kuulostaa sellaiselta, josta kapteenikaan ei voinut löytää vikaa: "[kun järjestät jatkuvan toimituksen Dockerin kanssa] Käytä Dockeria [ja ymmärrä mitä se antaa]" Muista, että tämä ei ole hopealuodi, joka ratkaisee kaikki ongelmat, vaan työkalu, joka tarjoaa upean perustan.
Toistettavuus
"Toistettavuudella" tarkoitamme yleistä joukkoa ongelmia, joita kohdataan sovellusten käytössä. Puhumme tällaisista tapauksista:
- Laatuosaston lavastusta varten tarkistamat skriptit on toistettava tarkasti tuotannossa.
- Sovellukset julkaistaan palvelimilla, jotka voivat vastaanottaa paketteja eri arkiston peileistä (ajan myötä ne päivitetään ja niiden mukana asennettujen sovellusten versiot).
- “Paikallisesti kaikki toimii minulle!” (...ja kehittäjät eivät pääse tuotantoon.)
- Sinun on tarkistettava jotain vanhasta (arkistoidusta) versiosta.
- ...
Niiden yleinen olemus tiivistyy siihen tosiasiaan, että käytettävien ympäristöjen täydellinen noudattaminen (sekä inhimillisen tekijän puuttuminen) on välttämätöntä. Kuinka voimme taata uusittavuuden? Tee Docker-kuvia Gitin koodin perusteella ja käyttää niitä sitten mihin tahansa tehtävään: testipaikoilla, tuotannossa, ohjelmoijien paikallisilla koneilla... Samalla on tärkeää minimoida suoritettavat toiminnot jälkeen kuvan kokoaminen: mitä yksinkertaisempi se on, sitä vähemmän todennäköistä on virheitä.
Infrastruktuuri on koodia
Jos infrastruktuurivaatimuksia (palvelinohjelmiston saatavuus, sen versio jne.) ei ole virallistettu ja "ohjelmoitu", minkä tahansa sovelluspäivityksen käyttöönotto voi johtaa tuhoisiin seurauksiin. Esimerkiksi lavastuksessa olet jo vaihtanut PHP 7.0:aan ja kirjoittanut koodin sen mukaisesti uudelleen - silloin sen ilmestyminen tuotantoon jollain vanhalla PHP:llä (5.5) yllättää varmasti jonkun. Et ehkä unohda suurta muutosta tulkkiversiossa, mutta "paholainen on yksityiskohdissa": yllätys voi olla minkä tahansa riippuvuuden pieni päivitys.
Lähestymistapa tämän ongelman ratkaisemiseksi tunnetaan nimellä IaC (infrastruktuuri koodina, infrastruktuuri koodina) ja sisältää infrastruktuurivaatimusten tallentamisen sovelluskoodin kanssa. Sen avulla kehittäjät ja DevOps-asiantuntijat voivat työskennellä saman Git-sovellusvaraston kanssa, mutta sen eri osissa. Tästä koodista luodaan Gitissä Docker-kuva, jossa sovellus otetaan käyttöön ottaen huomioon kaikki infrastruktuurin erityispiirteet. Yksinkertaisesti sanottuna kuvien kokoamisen komentosarjojen (sääntöjen) tulisi olla samassa arkistossa lähdekoodin kanssa ja yhdistettyinä.
Jos kyseessä on monikerroksinen sovellusarkkitehtuuri - esimerkiksi on nginx, joka seisoo Docker-säilön sisällä jo käynnissä olevan sovelluksen edessä - Docker-kuvat on luotava Git-koodista jokaiselle tasolle. Sitten ensimmäinen kuva sisältää sovelluksen, jossa on tulkki ja muut "läheiset" riippuvuudet, ja toinen kuva sisältää ylävirran nginx.
Docker-kuvat, viestintä Gitin kanssa
Jaamme kaikki Gitistä kerätyt Docker-kuvat kahteen luokkaan: väliaikaisiin ja julkaisuun. Väliaikaisia kuvia on merkitty Gitin haaran nimellä, ne voidaan korvata seuraavalla toimituksella, ja ne otetaan käyttöön vain esikatselua varten (ei tuotantoa varten). Tämä on niiden keskeinen ero julkaisuihin: et koskaan tiedä, mikä tietty sitoumus niissä on.
On järkevää kerätä väliaikaisiin kuviin: päähaara (voit automaattisesti levittää sen erilliselle sivustolle nähdäksesi jatkuvasti nykyisen master-version), julkaisuja sisältävät haarat, tiettyjen innovaatioiden haarat.
Kun tilapäisten kuvien esikatselu tulee tarpeeseen kääntää tuotantoon, kehittäjät laittavat tietyn tunnisteen. Kerää automaattisesti tunnisteen mukaan vapauttaa kuva (sen tagi vastaa Gitin tagia) ja se otetaan käyttöön lavastusta varten. Jos laatuosasto varmistaa sen onnistuneesti, se siirtyy tuotantoon.
DAPP
Kaikki kuvattu (käyttöönotto, kuvan kokoonpano, myöhempi ylläpito) voidaan toteuttaa itsenäisesti Bash-skriptien ja muiden "improvisoitujen" työkalujen avulla. Mutta jos teet tämän, toteutus johtaa jossain vaiheessa suureen monimutkaisuuteen ja huonoon ohjattavuuteen. Ymmärsimme tämän, ja päädyimme luomaan oman erikoistuneen Workflow-apuohjelman CI/CD:n rakentamiseen - DAPP.
Sen lähdekoodi on kirjoitettu Rubylla, avoimella lähdekoodilla ja julkaistu osoitteessa . Valitettavasti dokumentointi on tällä hetkellä työkalun heikoin kohta, mutta työskentelemme sen eteen. Ja kirjoitamme ja puhumme dappista useammin kuin kerran, koska... Emme malta odottaa, että pääsemme jakamaan sen ominaisuudet koko kiinnostuneen yhteisön kanssa, mutta sillä välin lähetä ongelmasi ja tee pyyntöjä ja/tai seuraa projektin kehitystä GitHubissa.
Päivitetty 13. elokuuta 2019: tällä hetkellä projekti DAPP nimetty uudelleen , sen koodi on kirjoitettu kokonaan uudelleen Gossa, ja sen dokumentaatiota on parannettu merkittävästi.
Kubernetes
Toinen valmis avoimen lähdekoodin työkalu, joka on jo saanut merkittävää tunnustusta ammatillisessa ympäristössä, on KubernetesDocker-hallintaklusteri. Aihe sen käytöstä Dockeriin rakennettujen projektien toiminnassa ei kuulu raportin piiriin, joten esitys rajoittuu yhteenvetoon mielenkiintoisista ominaisuuksista.
Käyttöönottoa varten Kubernetes tarjoaa:
- Readiness Probe — sovelluksen uuden version valmiuden tarkistaminen (liikenteen siirtämiseksi siihen);
- jatkuva päivitys - peräkkäinen kuvapäivitys konttiklusterissa (sammutus, päivitys, valmistelu käynnistykseen, liikenteen vaihtaminen);
- synkroninen päivitys - kuvan päivittäminen klusterissa eri lähestymistavalla: ensin puolet säilöistä, sitten loput;
- kanarian julkaisut - uuden kuvan käynnistäminen rajoitetulle (pienelle) määrälle säiliöitä poikkeavuuksien seuraamiseksi.
Koska Continuous Delivery ei ole vain uuden version julkaisu, Kubernetesilla on useita ominaisuuksia myöhempään infrastruktuurin ylläpitoon: sisäänrakennettu valvonta ja kirjaus kaikille säilöille, automaattinen skaalaus jne. Kaikki tämä toimii jo ja odottaa vain asianmukaista käyttöönottoa prosesseissasi.
Lopulliset suositukset
- Käytä Dockeria.
- Luo Docker-kuvia sovelluksista kaikkiin tarpeisiisi.
- Noudata periaatetta "Infrastruktuuri on koodia".
- Linkitä Git Dockeriin.
- Säädä käyttöönottojärjestystä.
- Käytä valmista alustaa (Kubernetes tai jokin muu).
Videot ja diat
Video esityksestä (noin tunti) (itse raportti alkaa 5. minuutista - seuraa linkkiä pelataksesi tästä hetkestä).
Raportin esittely:
PS.
Muita aiheeseen liittyviä raportteja blogissamme:
- «» (Dmitry Stolyarov; 27. toukokuuta 2019 DevOpsConfissa);
- «» (Dmitry Stolyarov; 8. marraskuuta 2018 HighLoad++:ssa);
- «» (Dmitry Stolyarov; 7. marraskuuta 2017 HighLoad++:ssa);
- «» (Dmitry Stolyarov; 6. kesäkuuta 2017 RootConfissa).
Lähde: will.com