Náš blog zahájíme publikacemi založenými na nejnovějších projevech našeho technického ředitele (Dmitrij Stolyarov). Všechny proběhly v roce 2016 na různých odborných akcích a byly věnovány tématu DevOps a Docker. Jedno video ze setkání Docker Moscow v kanceláři Badoo už máme Online. Nové budou doplněny články zprostředkovávajícími podstatu zpráv. Tak…
31. května na konferenci , konaném v rámci festivalu „Russian Internet Technologies“ (RIT++ 2016), byla sekce „Continuous Deployment and Deployment“ otevřena zprávou „Best Practices of Continuous Delivery with Docker“. Shrnul a systematizoval osvědčené postupy pro budování procesu nepřetržitého doručování (CD) pomocí Dockeru a dalších produktů s otevřeným zdrojovým kódem. S těmito řešeními pracujeme ve výrobě, což nám umožňuje opřít se o praktické zkušenosti.
Pokud máte možnost strávit hodinu , doporučujeme zhlédnout celý. Jinak níže je hlavní shrnutí v textové podobě.
Nepřetržité doručování s Dockerem
Pod Continuous Delivery rozumíme řetězci událostí, v jehož důsledku se kód aplikace z úložiště Git nejprve dostane do produkce a poté skončí v archivu. Vypadá to takto: Git → Build → Test → Release → Operate.
Většina zprávy je věnována fázi sestavení (sestavení aplikace) a krátce se dotkneme témat uvolnění a provozu. Budeme mluvit o problémech a vzorcích, které vám umožňují je řešit, přičemž konkrétní implementace těchto vzorů mohou být různé.
Proč je zde Docker vůbec potřeba? Ne nadarmo jsme se rozhodli mluvit o postupech nepřetržitého doručování v kontextu tohoto nástroje s otevřeným zdrojovým kódem. Přestože je celá zpráva věnována jeho použití, při zvažování hlavního vzoru zavádění aplikačního kódu je odhaleno mnoho důvodů.
Hlavní vzor zavádění
Takže když uvedeme nové verze aplikace, určitě se s tím potýkáme problém s prostojem, generované při přepínání produkčního serveru. Provoz ze staré verze aplikace na novou nelze přepnout okamžitě: nejprve se musíme ujistit, že nová verze je nejen úspěšně stažena, ale také „zahřátá“ (tj. zcela připravena obsluhovat požadavky).
Po nějakou dobu tedy budou obě verze aplikace (stará i nová) fungovat současně. Což automaticky vede k konflikt sdílených zdrojů: síť, souborový systém, IPC atd. S Dockerem je tento problém snadno vyřešen spuštěním různých verzí aplikace v samostatných kontejnerech, pro které je zaručena izolace zdrojů v rámci stejného hostitele (server/virtuální stroj). Samozřejmě, že se s některými triky obejdete úplně bez izolace, ale pokud existuje hotový a pohodlný nástroj, pak je důvod opačný - nezanedbávat ho.
Kontejnerizace poskytuje při nasazení mnoho dalších výhod. Jakákoli aplikace závisí na konkrétní verze (nebo rozsah verzí) tlumočník, dostupnost modulů/rozšíření atd. a také jejich verze. A to platí nejen pro bezprostředně spustitelné prostředí, ale i pro celé prostředí včetně systémový software a jeho verzi (až po použitou distribuci Linuxu). Vzhledem k tomu, že kontejnery obsahují nejen kód aplikace, ale také předinstalovaný systémový a aplikační software požadovaných verzí, můžete zapomenout na problémy se závislostmi.
Pojďme to shrnout hlavní zaváděcí vzor nové verze s ohledem na následující faktory:
- Nejprve běží stará verze aplikace v prvním kontejneru.
- Nová verze se poté vyvine a „zahřeje“ v druhém kontejneru. Je pozoruhodné, že tato nová verze sama o sobě může nést nejen aktualizovaný kód aplikace, ale také jakékoli její závislosti a také systémové komponenty (například novou verzi OpenSSL nebo celou distribuci).
- Když je nová verze plně připravena obsluhovat požadavky, provoz se přepne z prvního kontejneru na druhý.
- Starou verzi lze nyní zastavit.
Tento přístup nasazení různých verzí aplikace v samostatných kontejnerech poskytuje další pohodlí - rychlý návrat zpět na starou verzi (koneckonců stačí přepnout provoz na požadovaný kontejner).
Poslední první doporučení zní jako něco, co ani kapitán nemohl najít chybu: “[při organizaci průběžného doručování pomocí Docker] Použijte Docker [a pochopit, co to dává]" Pamatujte, že to není stříbrná kulka, která vyřeší každý problém, ale nástroj, který poskytuje skvělý základ.
Reprodukovatelnost
„Reprodukovatelností“ rozumíme zobecněný soubor problémů, se kterými se setkáváme při provozu aplikací. Mluvíme o takových případech:
- Scénáře zkontrolované oddělením kvality pro inscenaci musí být ve výrobě přesně reprodukovány.
- Aplikace jsou publikovány na serverech, které mohou přijímat balíčky z různých zrcadel úložišť (postupem času se aktualizují a s nimi i verze nainstalovaných aplikací).
- "Všechno mi funguje lokálně!" (...a vývojáři nesmějí do výroby.)
- Musíte něco zkontrolovat ve staré (archivované) verzi.
- ...
Jejich obecná podstata se scvrkává na skutečnost, že je nezbytná plná shoda používaných prostředí (a také absence lidského faktoru). Jak můžeme zaručit reprodukovatelnost? Vytvářejte obrázky Docker založené na kódu z Gitu, a následně je použít pro jakýkoli úkol: na testovacích webech, ve výrobě, na lokálních strojích programátorů... Zároveň je důležité minimalizovat akce, které se provádějí po sestavení obrázku: čím je to jednodušší, tím menší je pravděpodobnost chyb.
Infrastruktura je kód
Pokud nejsou požadavky na infrastrukturu (dostupnost serverového softwaru, jeho verze atd.) formalizovány a „naprogramovány“, může mít zavedení jakékoli aktualizace aplikace katastrofální následky. Například ve stagingu jste již přešli na PHP 7.0 a podle toho přepsali kód - pak jeho podoba v produkci s nějakým starým PHP (5.5) jistě někoho překvapí. Možná nezapomenete na zásadní změnu ve verzi tlumočníka, ale „ďábel je v detailech“: překvapením může být drobná aktualizace jakékoli závislosti.
Přístup k řešení tohoto problému je známý jako IaC (infrastruktura jako kód, „infrastruktura jako kód“) a zahrnuje ukládání požadavků na infrastrukturu spolu s kódem aplikace. Pomocí něj mohou vývojáři a specialisté DevOps pracovat se stejným úložištěm aplikací Git, ale na různých jeho částech. Z tohoto kódu je v Gitu vytvořen obraz Dockeru, ve kterém je aplikace nasazena s přihlédnutím ke všem specifikům infrastruktury. Jednoduše řečeno, skripty (pravidla) pro skládání obrázků by měly být ve stejném úložišti se zdrojovým kódem a sloučené dohromady.
V případě vícevrstvé aplikační architektury – například existuje nginx, který stojí před aplikací, která již běží uvnitř kontejneru Docker – musí být obrázky Dockeru vytvořeny z kódu v Gitu pro každou vrstvu. Pak bude první obrázek obsahovat aplikaci s interpretem a dalšími „blízkými“ závislostmi a druhý obrázek bude obsahovat upstream nginx.
Docker obrázky, komunikace s Git
Všechny obrázky Docker shromážděné z Gitu rozdělujeme do dvou kategorií: dočasné a uvolněné. Dočasné obrázky označené názvem větve v Gitu, mohou být přepsány dalším odevzdáním a jsou uvedeny pouze pro náhled (nikoli pro produkci). To je jejich klíčový rozdíl od verzí: nikdy nevíte, které konkrétní potvrzení je v nich.
Dává smysl shromažďovat do dočasných obrázků: hlavní větev (můžete ji automaticky převést na samostatný web, abyste neustále viděli aktuální verzi předlohy), větve s vydáními, větve konkrétních inovací.
Poté, co náhled dočasných obrázků přijde na potřebu překladu do produkce, vývojáři vložili určitou značku. Automaticky shromažďováno podle značky uvolnit obrázek (jeho tag odpovídá tagu z Gitu) a je zaveden do stagingu. Pokud je úspěšně ověřena oddělením kvality, jde do výroby.
dapp
Vše popsané (rollout, sestavení obrazu, následná údržba) lze implementovat samostatně pomocí Bash skriptů a dalších „improvizovaných“ nástrojů. Ale pokud to uděláte, pak v určitém okamžiku implementace povede k velké složitosti a špatné ovladatelnosti. Když jsme to pochopili, rozhodli jsme se vytvořit vlastní specializovaný nástroj Workflow pro vytváření CI/CD - dapp.
Jeho zdrojový kód je napsán v Ruby, open source a publikován na . Bohužel dokumentace je momentálně nejslabším místem nástroje, ale pracujeme na tom. A o dapp si budeme psát a mluvit víckrát, protože... Upřímně se nemůžeme dočkat, až se o jeho schopnosti podělíme s celou zainteresovanou komunitou, ale mezitím nám posílejte své problémy a požadavky na stahování a/nebo sledujte vývoj projektu na GitHubu.
Aktualizováno 13. srpna 2019: v současnosti projekt dapp přejmenován na , jeho kód byl kompletně přepsán v Go a jeho dokumentace byla výrazně vylepšena.
Kubernetes
Dalším hotovým Open Source nástrojem, který již získal významné uznání v profesionálním prostředí, je Kubernetes, cluster správy Docker. Téma jeho využití při provozu projektů postavených na Dockeru přesahuje rámec zprávy, a tak se prezentace omezuje na přehled některých zajímavých funkcí.
Pro zavedení nabízí Kubernetes:
- sonda připravenosti — kontrola připravenosti nové verze aplikace (pro přepnutí provozu na ni);
- rolující aktualizace - sekvenční aktualizace obrazu ve shluku kontejnerů (vypnutí, aktualizace, příprava na spuštění, přepínání provozu);
- synchronní aktualizace - aktualizace obrazu v clusteru s jiným přístupem: nejprve na polovině kontejnerů, poté na zbytku;
- canary releases – spuštění nového image na omezeném (malém) počtu kontejnerů pro sledování anomálií.
Vzhledem k tomu, že Continuous Delivery není pouze vydání nové verze, má Kubernetes řadu funkcí pro následnou údržbu infrastruktury: vestavěný monitoring a logování pro všechny kontejnery, automatické škálování atd. To vše již funguje a čeká jen na pořádné implementaci do vašich procesů.
Závěrečná doporučení
- Použijte Docker.
- Vytvářejte obrazy aplikací Docker pro všechny vaše potřeby.
- Dodržujte zásadu „Infrastruktura je kód“.
- Propojte Git s Dockerem.
- Regulujte pořadí zavádění.
- Použijte hotovou platformu (Kubernetes nebo jinou).
Videa a diapozitivy
Video z představení (cca hodina) (samotná reportáž začíná od 5. minuty - od této chvíle přehrajte kliknutím na odkaz).
Prezentace zprávy:
PS
Další zprávy k tématu na našem blogu:
- «» (Dmitry Stolyarov; 27. května 2019 na DevOpsConf);
- «» (Dmitry Stolyarov; 8. listopadu 2018 na HighLoad++);
- «» (Dmitry Stolyarov; 7. listopadu 2017 na HighLoad++);
- «» (Dmitry Stolyarov; 6. června 2017 na RootConf).
Zdroj: www.habr.com