Je Docker hračka nebo ne? Nebo je to stále pravda?

Ahoj všichni!

Opravdu chci přejít přímo k tématu, ale správnější by bylo říci něco o svém příběhu:

Vstup

Jsem programátor se zkušenostmi s vývojem frontend jednostránkových aplikací, scala/java a nodejs na serveru.

Poměrně dlouhou dobu (určitě pár nebo tři roky) jsem zastával názor, že Docker je mana z nebes a obecně velmi cool nástroj a měl by ho umět úplně každý vývojář. A z toho vyplývá, že každý vývojář by měl mít na svém lokálním stroji nainstalovaný Docker. Co můj názor, prohlédněte si volná místa, která jsou zveřejněna na stejném hh. Každý druhý obsahuje zmínku o dockeru a pokud jej vlastníte, bude to vaše konkurenční výhoda 😉

Na své cestě jsem potkal mnoho lidí s jejich odlišnými postoji k Dockeru a jeho ekosystému. Někteří říkali, že je to pohodlná věc, která zaručuje multiplatformní funkčnost. Ti druzí nechápali, proč by měli běhat v kontejnerech a jaký z toho bude mít zisk, třetímu to bylo úplně jedno a netrápili se (prostě napsali kód a šli domů - závidím jim. cesta :)

Důvody použití

Proč jsem použil docker? Pravděpodobně z následujících důvodů:

• spuštění databáze, využívá je 99 % aplikací
• spuštění nginx pro frontend distribuci a proxy na backend
• aplikaci můžete zabalit do obrazu dockeru, tímto způsobem bude moje aplikace fungovat všude, kde existuje docker, problém s distribucí je okamžitě vyřešen
• zjišťování služeb ihned po vybalení, můžete vytvářet mikroslužby, každý kontejner (připojený ke společné síti) může snadno dosáhnout jiného přes alias, velmi pohodlné
• Je zábavné vytvořit kontejner a „hrát si“ v něm.

Co se mi na dockeru vždy nelíbí:

• Aby moje aplikace fungovala, potřebuji na serveru samotný Docker. Proč to potřebuji, pokud moje aplikace běží na jre nebo nodejs a prostředí pro ně je již na serveru?
• pokud chci spustit svůj (soukromý) lokálně vytvořený obraz na vzdáleném serveru, pak potřebuji vlastní úložiště dockerů, potřebuji, aby někde fungoval registr a také musím nakonfigurovat https, protože docker cli funguje pouze přes https. Sakra... jsou samozřejmě možnosti, jak uložit obrázek lokálně přes docker save a stačí poslat obrázek přes scp... Ale tohle je hodně pohybů těla. A kromě toho to vypadá jako „berličkové“ řešení, dokud se neobjeví vaše vlastní úložiště
• docker-compose. Je potřeba pouze pro provoz kontejnerů. To je vše. Nic jiného neumí. Docker-compose má spoustu verzí svých souborů, svou vlastní syntaxi. Bez ohledu na to, jak je to deklarativní, nechci číst jejich dokumentaci. Nikde jinde to potřebovat nebudu.
• při práci v týmu většina lidí píše Dockerfile velmi křivě, nerozumí tomu, jak je ukládán do mezipaměti, přidávají do obrázku vše, co potřebují a nepotřebují, dědí z obrázků, které nejsou v Dockerhubu nebo soukromém úložišti, vytvářejí nějaké docker-compose soubory s databázemi a nic nepřetrvává. Vývojáři zároveň hrdě prohlašují, že Docker je cool, vše jim funguje lokálně a HR na volné místo důležité píše: “Používáme Docker a potřebujeme kandidáta s takovými pracovními zkušenostmi.”
• Neustále mě pronásledují myšlenky na zvýšení všeho v Dockeru: postgresql, kafka, redis. Škoda, že ne vše funguje v kontejnerech, ne vše jde jednoduše nakonfigurovat a spustit. To je podporováno vývojáři třetích stran, nikoli samotnými prodejci. A mimochodem, okamžitě vyvstává otázka: prodejci se nestarají o údržbu svých produktů v Dockeru, proč tomu tak je, možná něco vědí?
• Vždy vyvstává otázka perzistence dat kontejneru. a pak si myslíte, že bych měl jen připojit hostitelský adresář nebo vytvořit svazek dockeru nebo vytvořit datový kontejner, který je nyní deprecated? Pokud připojím adresář, musím se ujistit, že uid a gid uživatele v kontejneru odpovídá id uživatele, který kontejner spustil, jinak budou soubory vytvořené kontejnerem vytvořeny s právy root. Pokud použiji volume pak se data prostě v nějaké vytvoří /usr/* a bude tam stejný příběh s uid a gid jako v prvním případě. Pokud spouštíte komponentu třetí strany, musíte si přečíst dokumentaci a hledat odpověď na otázku: „do kterých adresářů kontejneru komponenta zapisuje soubory?“

Vždy se mi nelíbilo, že jsem se musel příliš dlouho šťourat s Dockerem v počáteční fázi: Přišel jsem na to, jak spouštět kontejnery, z jakých obrázků spouštět, udělal jsem Makefiles, které obsahovaly aliasy dlouhých příkazů Dockeru. Nenáviděl jsem docker-compose, protože jsem se nechtěl učit jiný nástroj v ekosystému dockerů. A docker-compose up Vadilo mi to, zvlášť když se tam ještě scházeli build konstrukce, spíše než již sestavené obrázky. Jediné, co jsem opravdu chtěl, bylo vyrobit produkt efektivně a rychle. Ale nemohl jsem přijít na to, jak používat docker.

Představujeme Ansible

Nedávno (před třemi měsíci) jsem spolupracoval s týmem DevOps, jehož téměř každý člen měl k Dockeru negativní vztah. Z důvodů:

• docker rules iptables (ačkoli to můžete zakázat v daemon.json)
• docker je zabugovaný a nespustíme ho ve výrobě
• pokud dojde k selhání démona dockeru, odpovídajícím způsobem se zhroutí všechny kontejnery s infrastrukturou
• není potřeba docker
• proč docker, když existuje Ansible a virtuální stroje

Při stejné práci jsem se seznámil s dalším nástrojem - Ansible. Slyšel jsem o tom jednou, ale nepokoušel jsem se psát vlastní učebnice. A teď jsem začal psát své úkoly a pak se moje vize úplně změnila! Protože jsem si uvědomil: Ansible má moduly pro spouštění stejných kontejnerů dockerů, sestavení obrázků, sítí atd. a kontejnery lze spouštět nejen lokálně, ale také na vzdálených serverech! Moje radost neznala mezí - našel jsem NORMÁLNÍ nástroj a zahodil soubory Makefile a docker-compose, byly nahrazeny úlohami yaml. Kód byl redukován pomocí konstruktů jako loop, when, Etc.

Docker pro spouštění komponent třetích stran, jako jsou databáze

Nedávno jsem se seznámil se ssh tunely. Ukázalo se, že je velmi snadné „předat“ port vzdáleného serveru na místní port. Vzdálený server může být buď stroj v cloudu, nebo virtuální stroj běžící ve VirtualBoxu. Pokud můj kolega nebo já potřebujeme databázi (nebo nějakou jinou komponentu třetí strany), můžeme jednoduše spustit server s touto komponentou a vypnout ji, když server není potřeba. Přesměrování portů má stejný účinek jako databáze běžící v kontejneru dockeru.

Tento příkaz předá můj místní port vzdálenému serveru se systémem postgresql:

ssh -L 9000:localhost:5432 [chráněno e-mailem]

Použití vzdáleného serveru řeší problém s vývojem týmu. Takový server může používat více vývojářů najednou, nemusí umět konfigurovat postgresql, rozumět Dockeru a dalším spletitostem. Na vzdáleném serveru můžete nainstalovat stejnou databázi v samotném Dockeru, pokud je obtížné nainstalovat konkrétní verzi. Vše, co vývojáři potřebují, je poskytnout ssh přístup!

Nedávno jsem četl, že SSH tunely jsou omezenou funkčností běžné VPN! Můžete jednoduše nainstalovat OpenVPN nebo jiné implementace VPN, nastavit infrastrukturu a dát ji vývojářům k použití. To je skvělé!

Naštěstí vám AWS, GoogleCloud a další poskytují rok bezplatného používání, tak je využijte! Jsou levné, pokud je vypnete, když se nepoužívají. Vždycky jsem si říkal, proč bych potřeboval vzdálený server jako gcloud, zdá se, že jsem je našel.

Jako místní virtuální stroj můžete použít stejný Alpine, který se aktivně používá v kontejnerech dockerů. No, nebo nějaké jiné odlehčené distribuce, aby se počítač rychleji spouštěl.

Sečteno a podtrženo: můžete a měli byste provozovat databáze a další infrastrukturní vymoženosti na vzdálených serverech nebo ve virtuálním boxu. Pro tyto účely nepotřebuji docker.

Něco málo o obrázcích a distribuci dockerů

už jsem psal Článek ve kterém jsem chtěl sdělit, že použití obrázků docker neposkytuje žádnou záruku. Obrázky dockeru jsou potřeba pouze k vytvoření kontejneru dockeru. Pokud upgradujete na image dockeru, pak upgradujete na použití kontejnerů dockeru a budete používat pouze je.

Viděli jste někde, kde vývojáři softwaru portují své produkty pouze v dockerovém obrazu?
Výsledkem většiny produktů jsou binární soubory pro konkrétní platformu, které jsou jednoduše přidány do obrazu dockeru, který je zděděn z požadované platformy. Přemýšleli jste někdy, proč je na dockerhubu tolik podobných obrázků? Zadejte například nginx, uvidíte 100500 XNUMX obrázků od různých lidí. Tito lidé nevyvinuli nginx samotný, jednoduše přidali oficiální nginx do svého dockerového obrazu a okořenili ho vlastními konfiguracemi pro pohodlí spouštění kontejnerů.

Obecně to můžete jednoduše uložit do tgz, pokud to někdo potřebuje spustit v dockeru, tak ať přidá tgz do Dockerfile, zdědí z požadovaného prostředí a vytvoří další buchty, které nemění samotnou aplikaci v tgz. Každý, kdo vytvoří docker image, bude vědět, co je tgz a co potřebuje k práci. Takto používám docker zde

Sečteno a podtrženo: Nepotřebuji registr dockerů, použiji nějaký druh S3 nebo jen úložiště souborů, jako je disk Google/dropbox

Docker v CI

Všechny společnosti, pro které jsem pracoval, jsou podobné. Obvykle jsou to potraviny. To znamená, že mají jednu aplikaci, jeden technologický zásobník (no, možná pár nebo tři programovací jazyky).

Tyto společnosti používají docker na svých serverech, kde běží proces CI. Otázka: Proč potřebujete na svých serverech vytvářet projekty v kontejneru dockeru? 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, na kterém bude sestavení probíhat?

Teď už chápu, že si tím střelím do nohy, protože docker svou izolací nepřináší žádný zisk. Problémy, se kterými jsem se setkal s CI v dockeru:

• opět k vytvoření potřebujete image dockeru. musíte hledat obrázek nebo napsat svůj vlastní dockerfile.
• 90 % že potřebujete přeposlat nějaké ssh klíče, tajná data, která nechcete zapisovat do obrazu dockeru.
• kontejner je vytvořen a zemře, všechny cache jsou ztraceny spolu s ním. další sestavení znovu stáhne všechny závislosti projektu, což je časově náročné a neefektivní a čas jsou peníze.

Vývojáři nestaví projekty v docker kontejnerech (kdysi jsem byl takový fanoušek, opravdu mě to v minulosti mrzelo xD). V Javě je možné mít několik verzí a změnit je jedním příkazem na tu, kterou právě potřebujete. V nodejs je to stejné, tam je nvm.

Výkon

Věřím, že docker je velmi výkonný a flexibilní nástroj, to je jeho nevýhoda (zní to divně, ano). S jeho pomocí se na něj mohou firmy snadno uchytit a použít ho tam, kde je potřeba i ne. Vývojáři spouštějí své kontejnery, některá svá prostředí, pak to vše plynule přechází do CI a produkce. Tým DevOps píše nějaký druh kódu pro spuštění těchto kontejnerů.

Používejte docker pouze na nejčerstvější fázi ve vašem pracovním postupu, nepřetahujte ji do projektu na začátku. Vaše obchodní problémy to nevyřeší. On pouze posune problémy do JINÉ úrovně a nabídne vlastní řešení, vy uděláte dvojí práci.

Když je potřeba docker: Došel jsem k závěru, že docker je velmi dobrý v optimalizaci daného procesu, ale ne v budování základní funkčnosti

Pokud se přesto rozhodnete použít 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 jej do všech repozitářů Dockefile a docker-compose

PS:

• Nedávno jsem narazil balení a říkají, že to funguje velmi dobře s Ansible a umožňuje vám sjednotit proces vytváření obrazů (včetně obrazu dockeru)
• také o dockeru, zajímavý článek

Děkuji za přečtení, přeji vám transparentní rozhodování ve vašich záležitostech a produktivní pracovní dny!

Zdroj: www.habr.com