Náš blog začneme publikáciami založenými na najnovších prejavoch nášho technického riaditeľa (Dmitrij Stolyarov). Všetky sa konali v roku 2016 na rôznych odborných podujatiach a boli venované téme DevOps a Docker. Jedno video zo stretnutia Docker v Moskve v kancelárii Badoo už máme Online. Nové budú sprevádzané článkami sprostredkujúcimi podstatu správ. Takže…
31. mája na konferencii , ktorý sa konal v rámci festivalu „Ruské internetové technológie“ (RIT++ 2016), sekciu „Nepretržité nasadzovanie a nasadzovanie“ otvorila správa „Best Practices of Continuous Delivery with Docker“. Zhrnul a systematizoval najlepšie postupy pre budovanie procesu Continuous Delivery (CD) pomocou Docker a iných produktov s otvoreným zdrojovým kódom. S týmito riešeniami pracujeme vo výrobe, čo nám umožňuje oprieť sa o praktické skúsenosti.
Ak máte možnosť stráviť hodinu , odporúčame pozrieť si ho celý. V opačnom prípade nižšie je hlavné zhrnutie v textovej forme.
Nepretržité doručovanie s Dockerom
pod Nepretržité dodávanie rozumieme reťazci udalostí, v dôsledku ktorých sa kód aplikácie z úložiska Git najskôr dostane do produkcie a potom skončí v archíve. Vyzerá takto: Git → Zostaviť → Test → Uvoľniť → Prevádzkovať.
Väčšina správy je venovaná fáze budovania (montáž aplikácie) a témy uvoľnenia a prevádzky sa krátko dotknú. Povieme si o problémoch a vzorcoch, ktoré umožňujú ich riešenie, pričom konkrétne implementácie týchto vzorov môžu byť rôzne.
Prečo je tu Docker vôbec potrebný? Nie nadarmo sme sa rozhodli hovoriť o postupoch nepretržitého doručovania v kontexte tohto nástroja s otvoreným zdrojom. Hoci je celá správa venovaná jeho použitiu, pri zvažovaní hlavného vzoru zavádzania aplikačného kódu sa odhaľuje veľa dôvodov.
Hlavný vzor rolovania
Takže, keď uvedieme nové verzie aplikácie, určite sa s tým stretneme problém s prestojmi, generované pri prepínaní produkčného servera. Prevádzka zo starej verzie aplikácie na novú sa nedá prepnúť okamžite: najprv sa musíme uistiť, že nová verzia je nielen úspešne stiahnutá, ale aj „zahriata“ (t. j. úplne pripravená na obsluhu požiadaviek).
Po určitú dobu budú teda obe verzie aplikácie (stará aj nová) fungovať súčasne. Čo automaticky vedie k konflikt zdieľaných zdrojov: sieť, súborový systém, IPC atď. S Dockerom je tento problém jednoducho vyriešený spustením rôznych verzií aplikácie v samostatných kontajneroch, pre ktoré je zaručená izolácia zdrojov v rámci toho istého hostiteľa (server/virtuálny stroj). Samozrejme, s niektorými trikmi sa môžete zaobísť aj bez izolácie, ale ak existuje hotový a pohodlný nástroj, potom je tu opačný dôvod - nezanedbať ho.
Kontajnerizácia poskytuje pri nasadení mnoho ďalších výhod. Akákoľvek aplikácia závisí od konkrétna verzia (alebo rozsah verzií) tlmočník, dostupnosť modulov/rozšírení a pod., ako aj ich verzie. A to platí nielen pre bezprostredne spustiteľné prostredie, ale aj pre celé prostredie vrátane systémový softvér a jeho verziu (až po použitú distribúciu Linuxu). Vďaka tomu, že kontajnery obsahujú nielen kód aplikácie, ale aj predinštalovaný systémový a aplikačný softvér požadovaných verzií, môžete zabudnúť na problémy so závislosťami.
Zovšeobecnme hlavný vzor zavádzania nové verzie zohľadňujúce tieto faktory:
- Najprv sa stará verzia aplikácie spustí v prvom kontajneri.
- Nová verzia sa potom rozvinie a „zahreje“ v druhom kontajneri. Je pozoruhodné, že samotná táto nová verzia môže niesť nielen aktualizovaný kód aplikácie, ale aj akékoľvek jej závislosti, ako aj systémové komponenty (napríklad novú verziu OpenSSL alebo celú distribúciu).
- Keď je nová verzia plne pripravená na obsluhu požiadaviek, návštevnosť sa prepne z prvého kontajnera na druhý.
- Starú verziu je teraz možné zastaviť.
Tento prístup nasadzovania rôznych verzií aplikácie v samostatných kontajneroch poskytuje ďalšie pohodlie - rýchly návrat späť na starú verziu (napokon stačí prepnúť návštevnosť na požadovaný kontajner).
Posledné prvé odporúčanie znie ako niečo, na čom nemôže nájsť chybu ani kapitán: “[pri organizovaní nepretržitého doručovania pomocou Docker] Použite Docker [a pochopiť, čo to dáva]" Pamätajte, že to nie je strieborná guľka, ktorá vyrieši každý problém, ale nástroj, ktorý poskytuje úžasný základ.
Reprodukovateľnosť
Pod „reprodukovateľnosťou“ rozumieme zovšeobecnený súbor problémov, s ktorými sa stretávame pri prevádzke aplikácií. Hovoríme o takýchto prípadoch:
- Skriptá kontrolované oddelením kvality pre inscenáciu musia byť vo výrobe presne reprodukované.
- Aplikácie sú publikované na serveroch, ktoré môžu prijímať balíčky z rôznych zrkadiel úložiska (časom sa aktualizujú a s nimi aj verzie nainštalovaných aplikácií).
- “Všetko mi funguje lokálne!” (...a vývojári nemajú povolený vstup do produkcie.)
- Musíte niečo skontrolovať v starej (archivovanej) verzii.
- ...
Ich všeobecná podstata spočíva v tom, že je potrebný úplný súlad s použitým prostredím (ako aj absencia ľudského faktora). Ako môžeme zaručiť reprodukovateľnosť? Vytvorte obrázky Docker založené na kóde od Gitu a následne ich použiť na akúkoľvek úlohu: na testovacích miestach, vo výrobe, na lokálnych strojoch programátorov... Zároveň je dôležité minimalizovať akcie, ktoré sa vykonávajú po zostavenie obrazu: čím je to jednoduchšie, tým je menšia pravdepodobnosť chýb.
Infraštruktúra je kód
Ak požiadavky na infraštruktúru (dostupnosť serverového softvéru, jeho verzia atď.) nie sú formalizované a „naprogramované“, zavedenie akejkoľvek aktualizácie aplikácie môže mať katastrofálne následky. Napríklad v stagingu ste už prešli na PHP 7.0 a podľa toho prepísali kód - potom jeho vzhľad v produkcii s nejakým starým PHP (5.5) určite niekoho prekvapí. Možno nezabudnete na veľkú zmenu vo verzii tlmočníka, ale „diabol je v detailoch“: prekvapenie môže byť v menšej aktualizácii akejkoľvek závislosti.
Prístup k riešeniu tohto problému je známy ako IaC (infraštruktúra ako kód, „infraštruktúra ako kód“) a zahŕňa ukladanie požiadaviek na infraštruktúru spolu s kódom aplikácie. Pomocou neho môžu vývojári a špecialisti DevOps pracovať s rovnakým úložiskom aplikácií Git, ale na rôznych jeho častiach. Z tohto kódu sa v Gite vytvorí obraz Docker, v ktorom je aplikácia nasadená s prihliadnutím na všetky špecifiká infraštruktúry. Jednoducho povedané, skripty (pravidlá) na skladanie obrázkov by mali byť v rovnakom úložisku so zdrojovým kódom a zlúčené dohromady.
V prípade viacvrstvovej aplikačnej architektúry - napríklad existuje nginx, ktorý stojí pred aplikáciou, ktorá už beží v kontajneri Docker - obrázky Docker musia byť vytvorené z kódu v Git pre každú vrstvu. Potom bude prvý obrázok obsahovať aplikáciu s tlmočníkom a ďalšími „blízkymi“ závislosťami a druhý obrázok bude obsahovať upstream nginx.
Docker obrázky, komunikácia s Git
Všetky obrázky Docker zhromaždené z Git rozdeľujeme do dvoch kategórií: dočasné a uvoľnené. Dočasné obrázky označené názvom vetvy v Git, môžu byť prepísané nasledujúcim odovzdaním a sú spustené len na ukážku (nie na produkciu). Toto je ich kľúčový rozdiel od verzií: nikdy neviete, ktoré konkrétne odovzdanie je v nich.
Má zmysel zhromažďovať do dočasných obrázkov: hlavnú vetvu (môžete ju automaticky zaviesť na samostatnú stránku, aby ste neustále videli aktuálnu verziu predlohy), vetvy s vydaniami, vetvy konkrétnych inovácií.
Po ukážke dočasných obrázkov dôjde k potrebe prekladu do výroby, vývojári umiestnia určitú značku. Automaticky zhromažďované podľa značky uvoľniť obrázok (jeho tag zodpovedá tagu z Git) a je uvedený do fázy. Ak je úspešne overený oddelením kvality, ide do výroby.
Dapp
Všetko popísané (nasadenie, zostavenie obrazu, následná údržba) je možné implementovať samostatne pomocou Bash skriptov a iných „improvizovaných“ nástrojov. Ale ak to urobíte, potom implementácia v určitom bode povedie k veľkej zložitosti a zlej ovládateľnosti. Keď sme to pochopili, dospeli sme k vytvoreniu nášho vlastného špecializovaného nástroja Workflow na vytváranie CI/CD - Dapp.
Jeho zdrojový kód je napísaný v Ruby, open source a publikovaný na . Žiaľ, dokumentácia je momentálne najslabšou stránkou nástroja, no pracujeme na tom. A budeme písať a hovoriť o dapp viac ako raz, pretože... Úprimne sa nemôžeme dočkať, kým sa o jeho schopnosti podelíme s celou zainteresovanou komunitou, ale medzitým nám posielajte svoje problémy a požiadavky na stiahnutie a/alebo sledujte vývoj projektu na GitHub.
Aktualizované 13. augusta 2019: v súčasnosti projekt Dapp premenovaný na , jeho kód bol úplne prepísaný v Go a jeho dokumentácia bola výrazne vylepšená.
Kubernetes
Ďalším hotovým Open Source nástrojom, ktorý už získal významné uznanie v profesionálnom prostredí, je Kubernetes,klaster správy Docker. Téma jeho využitia pri prevádzke projektov postavených na Dockeri presahuje rámec správy, preto sa prezentácia obmedzuje na prehľad niektorých zaujímavostí.
Na zavedenie ponúka Kubernetes:
- sonda pripravenosti — kontrola pripravenosti novej verzie aplikácie (prepnutie prevádzky na ňu);
- rolling update - sekvenčná aktualizácia obrazu v zhluku kontajnerov (vypnutie, aktualizácia, príprava na spustenie, prepínanie prevádzky);
- synchrónna aktualizácia - aktualizácia obrazu v klastri s iným prístupom: najprv na polovici kontajnerov, potom na zvyšku;
- canary releases – spustenie nového obrazu na obmedzenom (malom) počte kontajnerov na sledovanie anomálií.
Keďže Continuous Delivery nie je len vydaním novej verzie, Kubernetes má množstvo možností pre následnú údržbu infraštruktúry: vstavaný monitoring a logovanie pre všetky kontajnery, automatické škálovanie atď. Toto všetko už funguje a čaká len na to správne implementáciu do vašich procesov.
Záverečné odporúčania
- Použite Docker.
- Vytvorte Docker obrázky aplikácií pre všetky vaše potreby.
- Dodržujte zásadu „Infraštruktúra je kód“.
- Prepojte Git s Dockerom.
- Regulujte poradie zavádzania.
- Použite hotovú platformu (Kubernetes alebo inú).
Videá a diapozitívy
Video z vystúpenia (asi hodinu) (samotná správa začína od 5. minúty - od tohto momentu môžete hrať kliknutím na odkaz).
Prezentácia správy:
PS
Ďalšie správy k téme na našom blogu:
- «» (Dmitrij Stolyarov; 27. mája 2019 na DevOpsConf);
- «» (Dmitrij Stolyarov; 8. novembra 2018 na HighLoad++);
- «» (Dmitrij Stolyarov; 7. novembra 2017 na HighLoad++);
- «» (Dmitrij Stolyarov; 6. júna 2017 na RootConf).
Zdroj: hab.com