Je Docker hračka alebo nie? Alebo predsa len áno?

Ahojte všetci!

Veľmi by som chcel hneď začať s témou, ale správnejšie bude trochu porozprávať o mojej histórii:

Úvod

Som programátor s praxou v rozvoji frontend jednopage aplikácií, scala/java a nodejs na strane servera.

Dlho (už presne pár — tri roky) som sa držal názoru, že docker je nebeský dar a naozaj skvelý nástroj, a každý vývojár by mal vedieť, ako ho používať. A odtiaľ vyplýva, že každý vývojár by mal mať docker na svojej lokálnej mašine. Čo sa týka môjho názoru, prelistujte si inzeráty, ktoré sú zverejnené na hh. V každom druhom je zmienka o dockeri a ak ním disponujete — bude to vašou konkurenčnou výhodou 😉

Na svojej ceste som sa stretol s mnohými ľuďmi, s ich rôznymi postojmi k dockeru a k jeho ekosystému. Niektorí hovorili, že je to užitočná vec, garantujúca multiplatformovosť. Druhí nechápali, prečo by sa mali spúšťať v kontajneroch a aký z toho majú prospech, tretím to bolo úplne jedno a len písali kód a šli domov — mimochodom, závidím im 🙂

Dôvody používania

Prečo som používal docker? Asi z nasledujúcich dôvodov:

• spustenie databázy, 99% aplikácií ich používa
• spustenie nginx na poskytovanie frontend a smerovanie na backend
• možno zabaliť aplikáciu do docker obrazu, takže moja aplikácia bude fungovať všade, kde je docker, problém distribúcie je vyriešený okamžite
• service discovery z krabice, môžete vytvárať mikroslužby, každý kontajner (pripojený k spoločnej sieti) sa ľahko dostane k druhému cez alias, veľmi pohodlné
• je fajn vytvoriť kontajner a „pohrať sa“ v ňom.

Čo sa mi vždy NEpáčilo na dockeri:

• na to, aby moja aplikácia fungovala, potrebujem samotný docker na serveri. A na čo mi to je, ak moje aplikácie fungujú na jre alebo na nodejs a prostredie pre nich už je na serveri?
• ak chcem spustiť svoj (súkromný) lokálne zostavený obraz na vzdialenom serveri, potrebujem svoj docker repozitár, potrebujem, aby niekde fungoval registry a navyše musím nastaviť https, pretože docker cli funguje iba cez https. Och, sakra… sú možnosti, samozrejme, uložiť obraz lokálne cez docker save a cez scp jednoducho preniesť obraz... Ale to vyžaduje toľko pohybov. A navyše to vyzerá ako „obchodné“ riešenie, pokiaľ sa neobjaví vlastný repozitár.
• docker-composeJe potrebný len na spustenie kontajnerov. A to je všetko. Viac nič nemôže. Docker-compose má množstvo verzií svojich súborov, svoj syntax. Akýkoľvek bol deklaratívny, nechcem čítať ich dokumentáciu. Pre mňa už nebude potrebná nikde inde.
• pri práci v tíme väčšina ľudí píše Dockerfile veľmi zle, nerozumejú, ako to funguje s cache, pridávajú do obrazu všetko, čo potrebujú a nepotrebujú, dedia od obrazov, ktoré nie sú v dockerhub alebo súkromnom repozitári, vytvárajú akési docker-compose súbory s databázami a nič neperzistentujú. Pri tom vývojári hrdlo hlásia, že docker je skvelý, že im všetko funguje lokálne, a HR dôležite píše v inzerátoch: „Používame docker a potrebujeme kandidáta s takými skúsenosťami“.
• neustále sa obsesiou myšlienkami o spustení všetkého a všade v dockeri: postgresql, kafka, redis. Je škoda, že nie všetko funguje v kontajneroch, nie všetko sa ľahko konfiguruje a spúšťa. Podporujú to externí vývojári, a nie samotní dodávatelia. A mimochodom, okamžite sa vynára otázka, prečo sa dodávatelia nezaujímajú o support svojich produktov v dockeri, možno niečo vedia?
• vždy vyvstáva otázka o perzistencii údajov kontajnera. A tu myslíš, mám len pripojiť adresár hostiteľa alebo vytvoriť docker volume, alebo vytvoriť data container, ktorý teraz deprecated? Если я монтирую директорию то мне нужно убедиться что uid и gid пользователя в контейнере соответствует id пользователя запустившего контейнер, иначе файлы созданные контейнером будут созданы с правами владельца root. Если использую volume budú údaje jednoducho vytvorené v nejakom /usr/* a bude to rovnaký príbeh s uid a gid ako v prvom prípade. Ak spúšťaš externú súčasť, musíš sa pozrieť na dokumentáciu a hľadať odpoveď na otázku: „Do akých adresárov kontajner píše súbory?“

Vždy sa mi nepáčilo, že musím s dockerom tráviť príliš veľa času v počiatočnej fáze: vymýšľal som, ako spúšťať kontajnery, z akých obrazov sa zakladať, robil som Makefile, ktoré obsahovali aliasy k dlhým docker príkazom. Nenávidel som docker-compose, pretože som nechcel študovať ďalší nástroj ekosystému dockera. A docker-compose up ma to stresovalo, obzvlášť, ak tam ešte boli build konštrukcie, nie už zostavené obrazy. Všetko, čo som naozaj chcel, bolo jednoducho robiť produkt efektívne a rýchlo. Ale nemohol som si usporiadať používanie dockera.

Zoznámil som sa s Ansible

Nedávno (pred troma mesiacmi) som pracoval s DevOps tímom, takmer každý člen, ktorý mal voči dockeru negatívny postoj. Z dôvodov:

• Docker spravuje iptables (hoci to možno vypnúť v daemon.json)
• Docker je problematický a nebudeme ho spúšťať v produkcii
• ak Docker daemon zlyhá, tak zlyhajú aj všetky kontajnery s infraštruktúrou
• v Dockeri nie je potrebné
• načo je Docker, ak je tu Ansible a virtuálne stroje

Na tej istej práci som sa zoznámil s ďalším nástrojom — Ansible. Niekedy som o ňom počul, ale neskúšal som písať svoje playbooky. A teraz som začal písať svoje úlohy a moje videnie sa úplne zmenilo! Pretože som pochopil: Ansible má moduly na spúšťanie rovnakých Docker kontajnerov, zostavovanie obrazov, sietí a podobne, a kontajnery je možné spustiť nielen lokálne, ale aj na vzdialených serveroch! Mojej radosti nebolo konca — našiel som NORMÁLNY nástroj a zahodil svoje Makefile a docker-compose súbory, tie boli nahradené YAML úlohami. Kód bol zmenšený vďaka používaniu konštrukcií ako loop, when, atď.

Docker na spúšťanie externých komponentov ako databázy

Nedávno som sa zoznámil so SSH tunelmi. Ukázalo sa, že je veľmi jednoduché "preniesť" port vzdialeného servera na miestny port. Vzdialený server môže byť ako stroj v cloude, tak aj virtuálny stroj spustený v VirtualBoxe. Ak ja alebo môj kolega potrebujeme databázu (alebo nejaký iný externý komponent), stačí spustiť server s týmto komponentom a vypnúť ho, keď server nie je potrebný. Prenos portov poskytuje rovnaký efekt ako databáza spustená v Docker kontejnere.

Tento príkaz prenáša môj miestny port na vzdialený server s PostgreSQL:

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

Používanie vzdialeného servera rieši problém s vývojom v tíme. Tento server môžu používať súčasne viacerí vývojári, nemusia vedieť, ako nastaviť PostgreSQL, zaoberať sa Dockerom a inými zložitými vecami. Na vzdialenom serveri je možné nainštalovať tú istú databázu priamo v Dockeri, ak je ťažké nainštalovať špecifickú verziu. Všetko, čo budú potrebovať vývojári, je mať prístup cez SSH!

Nedávno som čítal, že SSH tunely sú obmedzené funkcie obyčajného VPN! Môžete jednoducho nastaviť OpenVPN alebo iné implementácie VPN, nastaviť infraštruktúru a poskytnúť ju vývojárom. Veď to je naozaj skvelé!

Našťastie, AWS, GoogleCloud a ďalšie poskytujú rok bezplatného používania, tak ich využite! Sú veľmi lacné, ak sa vypínajú, keď sa nepoužívajú. Vždy som sa zamýšľal, na čo by som potreboval vzdialený server typu gcloud, zdá sa, že som ich našiel.

Ako virtuálny stroj na lokálnom zariadení môžete použiť ten istý Alpine, ktorý sa aktívne používa v docker kontajneroch. Alebo nejaké iné odľahčené distribúcie, aby sa stroj rýchlejšie spúšťal.

Výsledok: spúšťať databázy a iné infraštruktúrne komponenty je možné a potrebné na vzdialených serveroch alebo vo VirtualBoxe. Na tieto účely nepotrebujem Docker.

Trochu o docker obrázkoch a distribúcii

Už som písal článok v ktorom som chcel povedať, že používanie docker obrázkov neposkytuje žiadne záruky. Docker obrázky sú potrebné len na vytvorenie docker kontajnerov. Ak sa spoliehate na docker obrázok, znamená to, že sa spoliehate na používanie docker kontajnerov a budete sa s nimi zaoberať len.

Videli ste niekedy, aby vývojári softvéru portovali svoje produkty len do docker obrázku?
Výsledok väčšiny produktov sú binárne súbory pre konkrétnu platformu, tie sa jednoducho pridávajú do docker obrázku, ktorý dedí z požadovanej platformy. Nezamýšľali ste, prečo je v DockerHubu toľko podobných obrázkov? Napríklad zadajte nginx, uvidíte 100500 obrázkov od rôznych ľudí. Títo ľudia nenavrhovali samotný nginx, len do svojho docker obrázku pridali oficiálny nginx a obohatili ho o svoje konfigurácie na pohodlnejšie spúšťanie kontajnerov.

Celkovo sa dá uchovávať jednoducho v tgz, ak by niekto potreboval spustiť toto v dockeri, tak nech do Dockerfile pridajú tgz, dedí sa z potrebného prostredia a vytvárajú sa ďalšie komponenty, ktoré nemenia samotnú aplikáciu v tgz. Ten, kto bude vytvárať docker obrázok, bude vedieť, čo je toto tgz a čo potrebuje na prácu. Takto používam Docker. tu

Záver: nepotrebujem docker registry, použijem nejaké S3 alebo jednoducho úložisko súborov typu Google Drive/Dropbox.

Docker v CI

Všetky spoločnosti, v ktorých som pracoval, si sú podobné. Zvyčajne ide o produktové spoločnosti. To znamená, že majú nejakú jednu aplikáciu, jeden technologický stack (možno pár — trojicu programovacích jazykov).

Tieto spoločnosti používajú docker na svojich serveroch, kde prebieha CI proces. Otázka — prečo je potrebné zostavovať projekty v docker kontejnere na vlastných serveroch? Prečo jednoducho nepripraviť prostredie pre zostavenie, napríklad napísať Ansible playbook, ktorý nainštaluje potrebné verzie nodejs, php, jdk, skopíruje ssh kľúče atď. na server, kde sa bude zostavovať?

Teraz chápem, že to je streľba do vlastnej nohy, pretože docker neprináša žiadne výhody zo svojej izolácie. Problémy s CI v dockeri, s ktorými som sa stretol:

• znova je potrebný docker obraz pre zostavenie. Je potrebné hľadať obraz alebo napísať svoj dockerfile.
• 90% že je potrebné preposlať nejaké ssh kľúče, tajné údaje, ktoré sa nechce písať do docker obrazu.
• kontejner sa vytvára a umiera, všetky keše sa s ním strácajú. Nasledujúce zostavenie bude musieť znova sťahovať všetky závislosti projektu, a to je dlhé a neefektívne, a čas sú peniaze.

Vývojári nezostavujú projekty v docker kontejnere (kedysi som bol takým fanúšikom, ale teraz sa cítim smiešne za seba v minulosti xD). V jave je možnosť mať niekoľko verzií a meniť ich jedným príkazom na tú, ktorá je aktuálne potrebná. V nodejs je to rovnaké, existuje nvm.

Záver

Myslím, že docker je veľmi mocný a flexibilný nástroj, v tom je jeho nevýhoda (znie to zvláštne, však?). Pomocou neho sa spoločnosti ľahko "závisia" na ňom, používajú ho tam, kde je to potrebné a nie je. Vývojári spúšťajú svoje kontajnery, svoje prostredie, potom to všetko hladko prechádza do CI, produkcie. DevOps tím píše nejaké bicykle, aby spustil tieto kontajnery.

Použite docker len na najnovšom štádiu vo vašom pracovnom procese, neprivádzajte ho do projektu na začiatku. Nevyrieši vaše biznis problémy. Iba presunie problémy na INÝ úroveň a bude ponúkať svoje možnosti riešenia, vy budete robiť dvojitú prácu.

Keď je docker potrebný: dospel som k názoru, že docker je veľmi dobrý v optimalizácii stanoveného procesu, ale nie v budovaní základnej funkčnosti.

Ak ste sa predsa len rozhodli použiť docker, tak:

• buďte maximálne opatrní
• nenúťte používateľom docker
• lokalizujte jeho používanie na jednom mieste, nešírte ho po všetkých repozitároch Dockefile a docker-compose.

PS:

• Nedávno som sa stretol s packer a tvrdia, že veľmi dobre pracuje s Ansible a umožňuje unifikovať proces vytvárania obrazov (vrátane docker image)
• tiež o dockeri, zaujímavý článok

Ďakujem, že ste dočítali, prajem vám transparentné riešenia vo vašich záležitostiach a produktívne pracovné dni!

Zdroj: habr.com