Navrhuji přečíst si přepis zprávy Alexandra Sigacheva z Inventos „Proces vývoje a testování s Docker + Gitlab CI“
Ti, kteří teprve začínají implementovat vývojový a testovací proces založený na Docker + Gitlab CI, si často kladou základní otázky. kde začít? Jak organizovat? Jak testovat?
Tato zpráva je dobrá, protože strukturovaným způsobem hovoří o procesu vývoje a testování pomocí Docker a Gitlab CI. Samotná zpráva je z roku 2017. Myslím, že z této zprávy se můžete dozvědět základy, metodiku, nápad, zkušenosti s používáním.
Koho to zajímá, prosím pod kočku.
Jmenuji se Alexander Sigachev. Pracuji pro Inventos. Řeknu vám o svých zkušenostech s používáním Dockeru a o tom, jak jej postupně implementujeme na projektech ve firmě.
Téma prezentace: Vývojový proces pomocí Docker a Gitlab CI.
Toto je moje druhá přednáška o Dockeru. V době první zprávy jsme Docker ve vývoji používali pouze na vývojářských strojích. Počet zaměstnanců, kteří používali Docker, byl asi 2-3 lidé. Postupně se sbíraly zkušenosti a posunuli jsme se zase o kousek dál. Odkaz na náš .
Co bude v této zprávě? Podělíme se o zkušenosti o tom, jaké hrábě jsme nasbírali, jaké problémy jsme vyřešili. Ne všude to bylo krásné, ale dalo se jít dál.
Naším mottem je: ukotvit vše, co nám přijde pod ruku.
Jaké problémy řešíme?
Pokud je ve společnosti několik týmů, je programátor sdíleným zdrojem. Existují fáze, kdy je programátor vytažen z jednoho projektu a přidělen na nějakou dobu jinému projektu.
Aby programátor rychle pochopil, potřebuje co nejdříve stáhnout zdrojový kód projektu a spustit prostředí, což mu umožní posunout dále řešení problémů tohoto projektu.
Obvykle, pokud začínáte od nuly, pak je v projektu málo dokumentace. Informace o nastavení jsou dostupné pouze pro staromilce. Zaměstnanci si své pracoviště zřídí sami během jednoho až dvou dnů. Abychom to urychlili, použili jsme Docker.
Dalším důvodem je standardizace nastavení ve Vývoji. Podle mých zkušeností se iniciativy vždy chopí vývojáři. V každém pátém případě se zadá vlastní doména, například vasya.dev. Vedle něj sedí jeho soused Petya, jehož doménou je petya.dev. Vyvíjejí webovou stránku nebo nějakou součást systému pomocí tohoto názvu domény.
Když se systém rozroste a tyto názvy domén se začnou dostávat do konfigurací, dojde ke konfliktu vývojového prostředí a cesta k webu se přepíše.
Totéž se děje s nastavením databáze. Někdo si s bezpečností hlavu neláme a pracuje s prázdným heslem roota. Ve fázi instalace MySQL někoho požádal o heslo a ukázalo se, že heslo je 123. Často se stává, že konfigurace databáze se neustále mění v závislosti na komitu vývojáře. Někdo opravil, někdo neopravil konfiguraci. Byly tam triky, když jsme vytáhli nějakou testovací konfiguraci .gitignore a každý vývojář musel nainstalovat databázi. To ztěžovalo začátek. Je nutné mimo jiné pamatovat na databázi. Databáze musí být inicializována, musí být zadáno heslo, musí být zaregistrován uživatel, musí být vytvořena tabulka a tak dále.
Dalším problémem jsou různé verze knihoven. Často se stává, že vývojář pracuje s různými projekty. Existuje projekt Legacy, který začal před pěti lety (od roku 2017 – pozn. red.). V době uvedení na trh jsme začínali s MySQL 5.5. Existují i moderní projekty, kde se snažíme implementovat modernější verze MySQL, například 5.7 nebo starší (v roce 2017 – pozn. red.)
Každý, kdo pracuje s MySQL, ví, že tyto knihovny s sebou přinášejí závislosti. Je spíše problematické provozovat 2 základny dohromady. Přinejmenším u starých klientů je problematické se připojit k nové databázi. To zase vytváří několik problémů.
Dalším problémem je, když vývojář pracuje na místním počítači, používá místní zdroje, místní soubory, místní RAM. Veškerá interakce při vývoji řešení problémů probíhá v rámci toho, že funguje na jednom stroji. Příkladem je situace, kdy máme backend servery v Production 3 a vývojář ukládá soubory do kořenového adresáře a odtud nginx bere soubory, aby odpověděl na požadavek. Když se takový kód dostane do produkce, ukáže se, že soubor je přítomen na jednom ze 3 serverů.
Směr mikroslužeb se nyní vyvíjí. Když rozdělíme naše velké aplikace na nějaké malé komponenty, které se vzájemně ovlivňují. To vám umožní vybrat technologie pro konkrétní zásobník úkolů. Umožňuje také sdílet práci a povinnosti mezi vývojáři.
Frondend-developer, vyvíjející na JS, nemá téměř žádný vliv na Backend. Backendový vývojář zase vyvíjí, v našem případě Ruby on Rails a do Frondendu nezasahuje. Interakce se provádí pomocí API.
Jako bonus jsme s pomocí Dockeru mohli recyklovat zdroje na Stagingu. Každý projekt vzhledem ke svým specifikům vyžadoval určitá nastavení. Fyzicky bylo nutné vyčlenit buď virtuální server a nakonfigurovat je samostatně, nebo sdílet nějaké variabilní prostředí a projekty se mohly v závislosti na verzi knihoven vzájemně ovlivňovat.
Nástroje. Co používáme?
- Samotný Docker. Dockerfile popisuje závislosti jedné aplikace.
- Docker-compose je balíček, který spojuje několik našich aplikací Docker.
- K ukládání zdrojového kódu používáme GitLab.
- Pro systémovou integraci používáme GitLab-CI.
Zpráva se skládá ze dvou částí.
První část bude hovořit o tom, jak se Docker spouštěl na strojích vývojářů.
Druhá část bude hovořit o tom, jak komunikovat s GitLabem, jak spouštíme testy a jak zavádíme Staging.
Docker je technologie, která umožňuje (za použití deklarativního přístupu) popsat potřebné komponenty. Toto je příklad Dockerfile. Zde prohlašujeme, že dědíme z oficiálního obrazu Ruby:2.3.0 Docker. Obsahuje nainstalovanou verzi Ruby 2.3. Nainstalujeme potřebné knihovny sestavení a NodeJS. Popisujeme, že vytváříme adresář /app. Nastavte adresář aplikace jako pracovní adresář. Do tohoto adresáře umístíme požadovaný minimální Gemfile a Gemfile.lock. Poté vytvoříme projekty, které nainstalují tento obraz závislosti. Označujeme, že kontejner bude připraven naslouchat na externím portu 3000. Posledním příkazem je příkaz, který přímo spouští naši aplikaci. Pokud provedeme příkaz start projektu, aplikace se pokusí spustit a spustit zadaný příkaz.
Toto je minimální příklad souboru docker-compose. V tomto případě ukážeme, že mezi dvěma kontejnery existuje spojení. To je přímo do databázové služby a webové služby. Naše webové aplikace ve většině případů vyžadují nějaký druh databáze jako backend pro ukládání dat. Protože používáme MySQL, příklad je s MySQL - ale nic nám nebrání použít nějakou jinou databázi (PostgreSQL, Redis).
Přebíráme z oficiálního zdroje z centra Docker obraz MySQL 5.7.14 beze změn. Shromažďujeme obrázek, který je zodpovědný za naši webovou aplikaci, z aktuálního adresáře. Při prvním spuštění nám shromáždí obrázek. Poté spustí příkaz, který zde provádíme. Pokud se vrátíme zpět, uvidíme, že byl definován příkaz ke spuštění přes Puma. Puma je služba napsaná v Ruby. Ve druhém případě přepíšeme. Tento příkaz může být libovolný v závislosti na našich potřebách nebo úkolech.
Také popisujeme, že potřebujeme přesměrovat port na našem vývojářském hostitelském počítači z 3000 na 3000 na kontejnerovém portu. To se děje automaticky pomocí iptables a jeho mechanismu, který je přímo zabudován v Dockeru.
Vývojář může také jako dříve přistupovat k jakékoli dostupné IP adrese, například 127.0.0.1 je místní nebo externí IP adresa počítače.
Poslední řádek říká, že webový kontejner závisí na db kontejneru. Když zavoláme start webového kontejneru, docker-compose za nás nejprve spustí databázi. Již při startu databáze (ve skutečnosti po spuštění kontejneru! To nezaručuje připravenost databáze) spustí aplikaci, náš backend.
Tím se zabrání chybám, když databáze není vyvolána, a šetří zdroje, když zastavíme databázový kontejner, čímž se uvolní zdroje pro další projekty.
Co nám dává použití dockerizace databáze na projektu. Opravujeme verzi MySQL pro všechny vývojáře. Tím se zabrání některým chybám, které se mohou vyskytnout, když se verze liší, když se změní syntaxe, konfigurace, výchozí nastavení. To vám umožní zadat společný název hostitele pro databázi, přihlašovací jméno a heslo. Odcházíme od zoo jmen a konfliktů v konfiguračních souborech, které jsme měli dříve.
Máme možnost použít optimálnější konfiguraci pro Vývojové prostředí, která se bude lišit od výchozího. MySQL je ve výchozím nastavení nakonfigurováno pro slabé stroje a jeho výkon po vybalení je velmi špatný.
Docker umožňuje používat Python, Ruby, NodeJS, PHP interpret požadované verze. Zbavíme se nutnosti používat nějaký správce verzí. Dříve Ruby používal balíček rpm, který vám umožňoval měnit verzi v závislosti na projektu. Umožňuje také díky kontejneru Docker plynule migrovat kód a verzovat jej spolu se závislostmi. Nemáme problém porozumět verzi interpretru i kódu. Chcete-li aktualizovat verzi, spusťte starý kontejner a zvedněte nový kontejner. Pokud se něco pokazilo, můžeme spustit nový kontejner, zvednout starý kontejner.
Po vytvoření image budou kontejnery ve vývoji i ve výrobě stejné. To platí zejména pro velké instalace.
Na frontendu používáme JavaScipt a NodeJS.
Nyní máme poslední projekt na ReacJS. Vývojář spustil vše v kontejneru a vyvíjel pomocí hot-reload.
Dále je spuštěna úloha sestavení JavaScipt a kód zkompilovaný do statiky je dán prostřednictvím prostředků pro úsporu nginx.
Zde jsem uvedl schéma našeho posledního projektu.
Jaké úkoly byly vyřešeny? Měli jsme potřebu vybudovat systém, se kterým budou mobilní zařízení komunikovat. Přijímají data. Jednou z možností je posílat na toto zařízení push notifikace.
Co jsme pro to udělali?
Do aplikace jsme rozdělili komponenty jako: admin část na JS, backend, který funguje přes REST rozhraní pod Ruby on Rails. Backend spolupracuje s databází. Vygenerovaný výsledek je předán klientovi. Administrační panel spolupracuje s backendem a databází prostřednictvím rozhraní REST.
Měli jsme také potřebu posílat push notifikace. Předtím jsme měli projekt, který implementoval mechanismus, který je zodpovědný za doručování oznámení na mobilní platformy.
Vyvinuli jsme následující schéma: operátor z prohlížeče komunikuje s admin panelem, admin panel komunikuje s backendem, úkolem je zasílat Push notifikace.
Push oznámení interagují s jinou komponentou, která je implementována v NodeJS.
Fronty jsou sestaveny a poté jsou odesílána upozornění podle jejich mechanismu.
Jsou zde nakresleny dvě databáze. V tuto chvíli s pomocí Dockeru využíváme 2 nezávislé databáze, které spolu nijak nesouvisí. Kromě toho mají společnou virtuální síť a fyzická data jsou uložena v různých adresářích na počítači vývojáře.
To samé, ale v číslech. Zde je důležité opětovné použití kódu.
Pokud jsme dříve hovořili o opětovném použití kódu ve formě knihoven, pak v tomto příkladu je naše služba, která reaguje na oznámení Push, znovu použita jako kompletní server. Poskytuje API. A náš nový vývoj s tím již interaguje.
V té době jsme používali verzi 4 NodeJS. Nyní (v roce 2017 – pozn. red.) v posledním vývoji používáme verzi 7 NodeJS. V nových komponentách není problém zapojit nové verze knihoven.
V případě potřeby můžete refaktorovat a zvýšit verzi NodeJS ze služby oznámení Push.
A pokud dokážeme zachovat kompatibilitu API, pak bude možné jej nahradit jinými projekty, které byly dříve používány.
Co potřebujete k přidání Dockeru? Do našeho úložiště přidáme Dockerfile, který popisuje potřebné závislosti. V tomto příkladu jsou komponenty rozděleny logicky. Toto je minimální sada backendového vývojáře.
Při vytváření nového projektu vytvoříme Dockerfile, popíšeme požadovaný ekosystém (Python, Ruby, NodeJS). V docker-compose popisuje potřebnou závislost - databázi. Popisujeme, že potřebujeme databázi takové a takové verze, ukládat data tam a tam.
Pro statickou obsluhu používáme samostatný třetí kontejner s nginx. Je možné nahrát obrázky. Backend je vkládá do předem připraveného svazku, který je navíc namontován v kontejneru s nginx, který dodává statiku.
Pro uložení konfigurace nginx, mysql jsme přidali složku Docker, do které ukládáme potřebné konfigurace. Když vývojář udělá git klon úložiště na svém počítači, má již připravený projekt pro místní vývoj. Není pochyb o tom, jaký port nebo jaká nastavení použít.
Dále máme několik komponent: admin, inform-API, push notifikace.
Abychom to všechno mohli spustit, vytvořili jsme další úložiště, které jsme nazvali dockerized-app. V současné době používáme několik úložišť před každou komponentou. Jen se logicky liší – v GitLabu to vypadá jako složka, ale na vývojářském stroji jako složka pro konkrétní projekt. O úroveň níže jsou komponenty, které budou kombinovány.
Toto je příklad pouze obsahu dockerizované aplikace. Přinášíme sem i adresář Docker, ve kterém vyplňujeme konfigurace potřebné pro interakce všech komponent. Existuje soubor README.md, který stručně popisuje, jak projekt spustit.
Zde jsme použili dva soubory docker-compose. To se provádí proto, aby bylo možné běhat po krocích. Když vývojář pracuje s jádrem, nepotřebuje push notifikace, jednoduše spustí soubor docker-compose a podle toho se zdroj uloží.
Pokud je potřeba integrovat s oznámeními push, spustí se docker-compose.yaml a docker-compose-push.yaml.
Protože docker-compose.yaml a docker-compose-push.yaml jsou ve složce, automaticky se vytvoří jedna virtuální síť.
Popis komponentů. Toto je pokročilejší soubor, který je zodpovědný za kolekci komponent. Co je zde pozoruhodné? Zde představujeme komponentu balancer.
Toto je hotový obraz Dockeru, který spouští nginx a aplikaci, která naslouchá na soketu Docker. Dynamické, když se kontejnery zapínají a vypínají, generuje konfiguraci nginx. Distribuujeme manipulaci s komponentami podle doménových jmen třetí úrovně.
Pro vývojové prostředí používáme doménu .dev - api.informer.dev. Aplikace s doménou .dev jsou dostupné na lokálním počítači vývojáře.
Dále jsou konfigurace přeneseny do každého projektu a všechny projekty jsou spuštěny společně ve stejnou dobu.
Graficky se ukazuje, že klientem je náš prohlížeč nebo nějaký nástroj, pomocí kterého děláme požadavky na balancer.
Nástroj pro vyrovnávání názvů domén určuje, který kontejner kontaktovat.
Může to být nginx, který dává adminovi JS. Může to být nginx, který poskytuje API, nebo statické soubory, které jsou poskytovány nginx ve formě nahrání obrázků.
Diagram ukazuje, že kontejnery jsou propojeny virtuální sítí a skryty za proxy.
Na vývojářském počítači můžete přistupovat ke kontejneru se znalostí IP, ale v zásadě to nepoužíváme. Přímý přístup prakticky není potřeba.
Na jaký příklad se podívat při dockerizaci vaší aplikace? Podle mého názoru je dobrým příkladem oficiální obrázek dockeru pro MySQL.
Je to docela náročné. Existuje mnoho verzí. Jeho funkčnost však umožňuje pokrýt mnoho potřeb, které mohou nastat v procesu dalšího vývoje. Pokud strávíte čas a zjistíte, jak to všechno souvisí, pak si myslím, že nebudete mít se seberealizací žádné problémy.
Hub.docker.com obvykle obsahuje odkazy na github.com, který obsahuje přímo nezpracovaná data, ze kterých si můžete obrázek sami sestavit.
Dále se v tomto úložišti nachází skript docker-endpoint.sh, který zodpovídá za počáteční inicializaci a další zpracování spouštění aplikace.
V tomto příkladu je také možnost konfigurace pomocí proměnných prostředí. Definováním proměnné prostředí při spuštění jednoho kontejneru nebo prostřednictvím docker-compose můžeme říci, že potřebujeme nastavit prázdné heslo pro docker pro root na MySQL nebo cokoli chceme.
Existuje možnost vytvoření náhodného hesla. Říkáme, že potřebujeme uživatele, potřebujeme uživateli nastavit heslo a potřebujeme vytvořit databázi.
V našich projektech jsme mírně sjednotili Dockerfile, který je zodpovědný za inicializaci. Tam jsme to upravili podle našich potřeb, aby to bylo jen rozšíření uživatelských práv, která aplikace používá. To nám později umožnilo jednoduše vytvořit databázi z aplikační konzole. Aplikace Ruby mají příkaz pro vytváření, úpravu a mazání databází.
Toto je příklad toho, jak vypadá konkrétní verze MySQL na github.com. Můžete otevřít soubor Dockerfile a podívat se, jak tam instalace probíhá.
docker-endpoint.sh je skript zodpovědný za vstupní bod. Během počáteční inicializace jsou vyžadovány některé přípravné kroky a všechny tyto akce se provádějí pouze v inicializačním skriptu.
Přejděme k druhé části.
Pro uložení zdrojových kódů jsme přešli na gitlab. Jedná se o poměrně výkonný systém, který má vizuální rozhraní.
Jednou ze součástí Gitlabu je Gitlab CI. Umožňuje popsat sekvenci příkazů, které budou později použity k organizaci systému doručování kódu nebo ke spuštění automatického testování.
Gitlab CI 2 talk - reportáž z klubu Ruby Russia - poměrně podrobná a snad vás zaujme.
Nyní se podíváme na to, co je potřeba k aktivaci Gitlab CI. Abychom mohli spustit Gitlab CI, stačí vložit soubor .gitlab-ci.yml do kořenového adresáře projektu.
Zde popisujeme, že chceme provést sekvenci stavů jako test, nasazení.
Spouštíme skripty, které přímo volají docker-compose k sestavení naší aplikace. Toto je pouze příklad backendu.
Dále říkáme, že je nutné spustit migrace pro změnu databáze a spuštění testů.
Pokud jsou skripty provedeny správně a nevrátí chybový kód, systém postoupí do druhé fáze nasazení.
Fáze nasazení je aktuálně implementována pro staging. Neorganizovali jsme restart bez výpadků.
Všechny nádoby násilně uhasíme a poté všechny nádoby sesbírané v první fázi během testování opět zvedneme.
Spouštíme pro aktuální proměnnou prostředí migrace databáze, které napsali vývojáři.
Je zde poznámka, že to platí pouze pro hlavní větev.
Při změně ostatních větví se neprovádí.
Je možné organizovat rollouty podle poboček.
Abychom to mohli dále uspořádat, musíme nainstalovat Gitlab Runner.
Tento nástroj je napsán v Golangu. Jde o jeden soubor, jak je běžné ve světě Golang, který nevyžaduje žádné závislosti.
Při spuštění zaregistrujeme Gitlab Runner.
Klíč získáme ve webovém rozhraní Gitlabu.
Poté na příkazovém řádku zavoláme inicializační příkaz.
Interaktivně nastavit Gitlab Runner (Shell, Docker, VirtualBox, SSH)
Kód na Gitlab Runner se spustí při každém odevzdání v závislosti na nastavení .gitlab-ci.yml.
Jak to vypadá vizuálně v Gitlabu ve webovém rozhraní. Po připojení GItlab CI máme příznak, který ukazuje aktuální stav sestavení.
Vidíme, že před 4 minutami bylo provedeno potvrzení, které prošlo všemi testy a nezpůsobilo žádné problémy.
Můžeme se blíže podívat na buildy. Zde vidíme, že dva státy již prošly. Stav testování a stav nasazení ve fázi.
Pokud klikneme na konkrétní sestavení, pak bude konzolový výstup příkazů, které byly v procesu spuštěny podle .gitlab-ci.yml.
Takto vypadá naše produktová historie. Vidíme, že tam byly úspěšné pokusy. Po odeslání testů se nepostoupí k dalšímu kroku a pracovní kód se neaktualizuje.
Jaké úkoly jsme řešili na stagingu, když jsme implementovali docker? Náš systém se skládá z komponent a my jsme museli restartovat, pouze část komponent, které byly aktualizovány v úložišti, a ne celý systém.
Abychom to udělali, museli jsme vše rozbít do samostatných složek.
Poté, co jsme to udělali, jsme měli problém s tím, že Docker-compose vytváří vlastní síťový prostor pro každého tatínka a nevidí sousedovy komponenty.
Abychom to obešli, vytvořili jsme síť v Dockeru ručně. V Docker-compose bylo napsáno, že pro tento projekt používáte takovou síť.
Každý komponent, který začíná touto sítí, tedy vidí komponenty v jiných částech systému.
Dalším problémem je rozdělení stagingu na více projektů.
Protože aby to vše vypadalo krásně a co nejblíže výrobě, je dobré použít port 80 nebo 443, který se používá všude na WEBu.
Jak jsme to vyřešili? Všem velkým projektům jsme přiřadili jednoho Gitlab Runner.
Gitlab vám umožňuje spouštět několik distribuovaných Gitlab Runnerů, které jednoduše převezmou všechny úkoly střídavě chaotickým způsobem a spustí je.
Abychom neměli dům, omezili jsme skupinu našich projektů na jeden Gitlab Runner, který si bez problémů poradí s našimi objemy.
Přesunuli jsme nginx-proxy do samostatného spouštěcího skriptu a přidali jsme mřížky pro všechny projekty v něm.
Náš projekt má jednu mřížku a balancer má několik mřížek podle názvů projektů. Může proxy dále podle doménových jmen.
Naše požadavky přicházejí přes doménu na portu 80 a jsou vyřešeny do skupiny kontejnerů, která obsluhuje tuto doménu.
Jaké další problémy byly? To je to, co všechny kontejnery ve výchozím nastavení běží jako root. Toto je root, který se nerovná kořenovému hostiteli systému.
Pokud však zadáte kontejner, bude to root a soubor, který v tomto kontejneru vytvoříme, získá práva root.
Pokud vývojář vstoupil do kontejneru a provedl tam nějaké příkazy, které generují soubory, pak kontejner opustil, pak má ve svém pracovním adresáři soubor, ke kterému nemá přístup.
Jak se to dá vyřešit? Můžete přidat uživatele, kteří budou v kontejneru.
Jaké problémy nastaly, když jsme uživatele přidali?
Při vytváření uživatele často nemáme stejné ID skupiny (UID) a ID uživatele (GID).
K vyřešení tohoto problému v kontejneru používáme uživatele s ID 1000.
V našem případě se to shodovalo se skutečností, že téměř všichni vývojáři používají OS Ubuntu. A na Ubuntu má první uživatel ID 1000.
Máme plány?
Přečtěte si dokumentaci k Dockeru. Projekt se aktivně vyvíjí, dokumentace se mění. Data, která byla přijata před dvěma nebo třemi měsíci, jsou již pomalu zastaralá.
Některé z problémů, které jsme řešili, jsou dost možná již vyřešeny standardními prostředky.
Takže už chci jít dál a jít přímo k orchestraci.
Jedním z příkladů je vestavěný mechanismus Dockeru nazvaný Docker Swarm, který vychází z krabice. Chci spustit něco ve výrobě založené na technologii Docker Swarm.
Díky tření kontejnerů je práce s kládami nepohodlná. Nyní jsou protokoly izolovány. Jsou rozptýleny po kontejnerech. Jedním z úkolů je pohodlný přístup k protokolům přes webové rozhraní.
Zdroj: www.habr.com