Je Docker hračka, nebo ne? Nebo přece jen ano?

Ahoj všichni!

Oooch, opravdu bych chtěl okamžitě začít s tématem, ale bylo by správnější trochu se podělit o můj příběh:

Úvod

Jsem programátor se zkušenostmi v oblasti vývoje frontendových jednosložkových aplikací, scala/java a nodejs na serveru.

Dlouho (už určitě pár — tři roky) jsem měl názor, že docker je dar z nebes a vůbec velmi skvělý nástroj, který by měl umět používat každý vývojář. A z toho vyplývá, že by měl mít docker nainstalovaný na své lokální stroji. Co se týče mého názoru, prohlédněte si inzeráty na pracovních portálech, jako je hh. V každé druhé je zmínka o dockeru a pokud ho ovládáte — bude to vaší konkurenční výhodou 😉

Na své cestě jsem se setkal s mnoha lidmi, kteří měli různé názory na docker a na jeho ekosystém. Někteří říkali, že je to pohodlná věc, která zaručuje multiplatformnost. Jiní nechápali, proč by se měli spouštět v kontejnerech a jaká výhoda z toho vyplývá, třetím to bylo úplně jedno a jen psali kód a odcházeli domů — mimochodem, závidím jim 🙂

Důvody použití

Proč jsem používal docker? Možná z následujících důvodů:

• spouštění databází, 99 % aplikací je používá
• spouštění nginx pro poskytování frontend a pro proxy na backend
• mohu zabalit aplikaci do docker obrazu, tím pádem moje aplikace poběží všude, kde je docker, problém distribuce je okamžitě vyřešen
• service discovery out of the box, lze tvořit mikroslužby, každý kontejner (připojený k sdílené síti) se snadno dostane k jinému podle aliasu, velmi pohodlné
• je skvělé vytvořit kontejner a 'hrát si' v něm.

Co se mi na dockeru vždy NELÍBILO:

• aby moje aplikace fungovala, potřebují samotný docker na serveru. A proč bych to potřeboval, když moje aplikace běží na jre nebo nodejs a prostředí pro ně už na serveru existuje?
• pokud chci spustit svůj (privátní) lokálně sestavený obraz na vzdáleném serveru, potřebuji svůj docker repozitář, potřebuju, aby někde běžel registry, a také je potřeba nastavit https, protože docker cli funguje pouze přes https. Sakra… existují samozřejmě varianty, jak uložit obraz lokálně přes docker save a pomocí scp prostě přenést obraz… Ale to je tolik práce. A navíc to vypadá jako 'záplata', dokud nevznikne vlastní repozitář.
• docker-composeJe potřebný pouze pro spuštění kontejnerů. A to je vše. Nic víc nezvládne. Docker-compose má spoustu verzí svých souborů, svůj syntaktický styl. Ať je deklarativní, jak chce, nechci číst jejich dokumentaci. Nebude mi už nikde jinde potřebná.
• při práci v týmu většina lidí píše Dockerfile velmi nešikovně, nechápou, jak to je s kešováním, přidávají do obrazu vše, co by neměli, odvozují se od obrazů, které nejsou na dockerhub nebo v privátním repozitáři, vytvářejí nějaké docker-compose soubory s databázemi a nic neperzistují. Přitom vývojáři hrdě prohlašují, že docker je skvělý, všechno jim funguje lokálně a HR důležitě píše v inzerátech: „Používáme docker a potřebujeme kandidáta s takovými zkušenostmi“
• neustále mě pronásledují myšlenky na to, jak spustit v dockeru všechno: postgresql, kafka, redis. Je škoda, že ne všechno funguje v kontejnerech, ne všechno se snadno konfiguruje a spouští. To podporují externí vývojáři, ne samotní dodavatelé. A mimochodem hned vzniká otázka, dodavatelé se nezabývají udržováním svých produktů v dockeru, proč to asi je, možná něco vědí?
• vždy vyvstává otázka o perzistenci dat kontejneru. A tady přemýšlím, mám prostě přimontovat hostitelský adresář nebo vytvořit docker volume nebo udělat data kontejner, který nyní deprecated? Если я монтирую директорию то мне нужно убедиться что uid и gid пользователя в контейнере соответствует id пользователя запустившего контейнер, иначе файлы созданные контейнером будут созданы с правами владельца root. Если использую volume data budou vytvořena v nějakém /usr/* a bude to stejné jako v prvním případě s uid a gid. Pokud spouštíte externí komponent, musíte se ponořit do dokumentace a hledat odpověď na otázku: „do kterých adresářů kontejneru komponent zapisuje soubory?“

Vždy se mi nelíbilo, že musím s dockerem trávit příliš mnoho času v počáteční fázi: vymýšlel jsem, jak spouštět kontejnery, z jakých obrazů spouštět, dělal jsem Makefile, které obsahovaly aliasy pro dlouhé docker příkazy. Nesnášel jsem docker-compose, protože jsem nechtěl učit další nástroj ekosystému docker. A docker-compose up bylo to pro mě stresující, zejména pokud se tam objevily build konfigurační příkazy a ne již sestavené obrazy. Všechno, co jsem opravdu chtěl — bylo prostě efektivně a rychle vytvářet produkt. Ale nemohl jsem uhladit používání dockeru.

Seznámení s Ansible

Nedávno (před třemi měsíci) jsem pracoval s DevOps týmem, téměř každý účastník měl negativní názor na docker z těchto důvodů:

• docker ovládá iptables (i když to lze v daemon.json vypnout)
• Docker není nezbytný a nebudeme ho spouštět v produkci.
• Pokud dojde k pádu docker daemonu, spadnou i všechny kontejnery s infrastrukturou.
• V dockeru není potřeba.
• Proč docker, když máme Ansible a virtuální stroje?

Na té samé práci jsem se setkal s dalším nástrojem — Ansible. Kdysi jsem o něm slyšel, ale nikdy jsem nezkoušel psát své playbooky. A teď jsem začal psát své úkoly a moje vnímání se kompletně změnilo! Poznal jsem, že Ansible má moduly pro spouštění stejných docker kontejnerů, sestavení obrazů, sítí atd., a kontejnery lze spouštět nejen lokálně, ale i na vzdálených serverech! Mému nadšení nebylo konce — našel jsem NORMÁLNÍ nástroj a vyhodil své Makefile a docker-compose soubory, které byly nahrazeny yaml úkoly. Kód byl zmenšen díky použití konstrukcí typu loop, when, atd.

Docker pro spouštění externích komponentů, jako je databáze.

Nedávno jsem se seznámil se ssh tunely. Ukázalo se, že je velmi jednoduché „přehodit“ port vzdáleného serveru na lokální port. Vzdálený server může být jak stroj v cloudu, tak virtuální stroj spuštěný ve VirtualBoxu. Pokud já nebo můj kolega potřebujeme databázi (nebo nějakou jinou externí komponentu), můžeme jednoduše spustit server s touto komponentou a vypnout ho, když server není potřeba. Přesměrování portů má stejný efekt, jako databáze spuštěná v docker kontejneru.

Tento příkaz přesměrovává můj lokální port na vzdálený server s postgresql:

ssh -L 9000:localhost:5432 user@example.com

Použití vzdáleného serveru řeší problém s vývojem v týmu. Tento server mohou současně využívat několik vývojářů, nemusí znát nastavování postgresql, rozumět dockeru a dalším složitostem. Na vzdáleném serveru lze nainstalovat stejnou databázi přímo v dockeru, pokud je obtížné nainstalovat specifickou verzi. Všechno, co vývojáři budou potřebovat, je poskytnout ssh přístup!

Nedávno jsem četl, že SSH tunely jsou omezená funkčnost obyčejného VPN! Můžete jednoduše nastavit OpenVPN nebo jiné implementace VPN, nastavit infrastrukturu a poskytnout ji vývojářům. To je přece úžasné!

Naštěstí AWS, GoogleCloud a další poskytují rok bezplatného používání, tak je využijte! Jsou velmi levné, pokud je vypínáte, když nejsou potřeba. Vždy jsem přemýšlel, k čemu bych potřeboval vzdálený server typu gcloud, a zdá se, že jsem našel odpověď.

Jako virtuální stroj na místním prostředí lze použít stejný Alpine, který se aktivně používá v kontejnerech Docker. Nebo nějaké jiné odlehčené distribuce, aby se stroj rychleji spouštěl.

Výsledek: databáze a další infrastrukturní prvky lze a měly by běžet na vzdálených serverech nebo ve VirtualBoxu. Na tyto účely nepotřebuji Docker.

Něco málo o obrazech Docker a distribuci

Již jsem psal článek o tom, že používání obrazů Docker nenabízí žádnou záruku. Obrazy Docker jsou potřeba pouze k vytvoření kontejneru Docker. Pokud se spoléháte na obraz Docker, znamená to, že se spoléháte na používání kontejnerů Docker a budete s nimi jen pokračovat.

Viděli jste někde, že by vývojáři softwaru portovali své produkty pouze do obrazu Docker?
Výsledkem většiny produktů jsou binární soubory pro konkrétní platformu, které se jednoduše přidávají do obrazu Docker, jenž dědí od potřebné platformy. Nepřemýšleli jste, proč je v DockerHubu tolik podobných obrazů? Zadejte například nginx, uvidíte 100500 obrazů od různých lidí. Tito lidé nevyvíjeli samotný nginx, jen do svého obrazu Docker přidali oficiální nginx a doplnili svými konfiguracemi pro usnadnění spouštění kontejnerů.

Celkově lze uchovávat jednoduše v tgz, pokud někdo potřebuje spouštět to v Dockeru, může do Dockerfile přidat tgz, dědit od potřebného prostředí a vytvářet další funkce, které nemění samotnou aplikaci v tgz. Ten, kdo bude vytvářet obraz Docker, bude vědět, co to tgz je a co potřebuje k práci. Takto já používám Docker. tady

Výsledek: nepotřebuji registry Docker, využiji nějaké S3 nebo jen úložné místo jako Google Drive/Dropbox.

Docker v CI

Všechny firmy, ve kterých jsem pracoval, jsou si podobné. Obvykle se jedná o produktové firmy. To znamená, že mají nějakou aplikaci, jeden technologický stack (možná pár – tři programovací jazyky).

Tyto společnosti používají docker na svých serverech, kde probíhá proces CI. Otázka zní - proč sestavovat projekty v docker kontejneru na svých serverech? Proč prostě nepřipravit prostředí pro sestavení, například napsat Ansible playbook, který nainstaluje potřebné verze nodejs, php, jdk, zkopíruje ssh klíče atd. na server, kde probíhá sestavení?

Nyní si uvědomuji, že to je střelba do vlastních nohou, protože docker nepřináší žádný prospěch ze své izolace. Problémy s CI v dockeru, se kterými jsem se setkal:

• opět je potřeba docker image pro sestavení. Je třeba hledat image nebo napsat vlastní dockerfile.
• 90 % šance, že je potřeba propustit nějaké ssh klíče, tajné údaje, které se nechce psát do docker image.
• kontejner se vytváří a umírá, všechny mezipaměti se s ním ztrácejí. Příští sestavení bude muset znovu stahovat všechny závislosti projektu, což je dlouhé a neefektivní, a čas jsou peníze.

Vývojáři nesestavují projekty v docker kontejnerech (někdy jsem byl také takovým fanouškem, škoda mě v minulosti xD). V jave je možnost mít více verzí a změnit je jedním příkazem na tu, která je nyní potřeba. V nodejs je to stejné, je zde nvm.

Výstup

Domnívám se, že docker je velmi mocný a flexibilní nástroj, v tom je jeho nedostatek (znělo to divně, že?). Díky němu se společnosti snadno "odvykají", používají ho tam, kde je třeba a kde není. Vývojáři spouštějí své kontejnery, jakési své prostředí, a pak to vše hladce přechází do CI, produkce. DevOps tým píše nějaké bicykly, aby spustil tyto kontejnery.

Používejte docker pouze na posledním stupni ve vašem pracovním procesu, netahejte ho do projektu na začátku. Nevyřeší vaše obchodní problémy. Jen přesměruje problémy na JINOU úroveň a navrhne svá řešení, budete vykonávat dvojitou práci.

Kdy je docker potřeba: došel jsem k myšlence, že docker je velmi dobrý v optimalizaci stanoveného procesu, ale ne při budování základní funkcionality.

Pokud se přesto rozhodnete použit docker, pak:

• buďte extrémně opatrní
• nenuťte vývojáře používat docker
• lokalizujte jeho použití na jednom místě, nerozšiřujte ho na všechny repozitáře Dockefile a docker-compose.

PS:

• Nedávno jsem narazil na packer A říkají, že velmi dobře pracuje s Ansible a umožňuje unifikovat proces vytváření obrazů (včetně docker image).
• Také o dockeru, zajímavý článek.

Děkujeme, že jste dočetli, přeji vám průhledná řešení ve vašich záležitostech a produktivní pracovní dny!

Zdroj: habr.com