Je Docker hračka alebo nie? Alebo je to stále pravda?

Ahoj všetci!

Naozaj chcem prejsť priamo k téme, ale správnejšie by bolo povedať niečo o mojom príbehu:

Vstup

Som programátor so skúsenosťami s vývojom frontend jednostránkových aplikácií, scala/java a nodejs na serveri.

Pomerne dlho (určite pár-tri roky) som zastával názor, že Docker je manna z neba a vo všeobecnosti veľmi cool nástroj a mal by ho vedieť používať úplne každý vývojár. A z toho vyplýva, že každý vývojár by mal mať nainštalovaný Docker na svojom lokálnom počítači. Čo môj názor, prezrite si voľné miesta, ktoré sú zverejnené na rovnakom hh. Každý druhý obsahuje zmienku o dockerovi a ak ho vlastníte, bude to vaša konkurenčná výhoda 😉

Na svojej ceste som stretol veľa ľudí s rôznymi postojmi k Dockeru a jeho ekosystému. Niektorí hovorili, že ide o pohodlnú vec, ktorá zaručuje funkčnosť naprieč platformami. Druhí nechápali, prečo by mali behať v kontajneroch a aký z toho bude mať zisk, tretiemu to bolo úplne jedno a netrápilo sa (len napísali kód a išli domov - závidím im, pri cesta :)

Dôvody použitia

Prečo som použil docker? Pravdepodobne z nasledujúcich dôvodov:

• spúšťanie databázy, využíva ich 99 % aplikácií
• spustenie nginx na frontendovú distribúciu a proxy na backend
• aplikáciu môžete zabaliť do obrazu dockera, takto bude moja aplikácia fungovať všade tam, kde existuje docker, problém s distribúciou je okamžite vyriešený
• objavenie služby hneď po vybalení, môžete vytvárať mikroslužby, každý kontajner (pripojený k spoločnej sieti) sa môže ľahko dostať k inému cez alias, veľmi pohodlné
• Je zábavné vytvoriť kontajner a „hrať sa“ v ňom.

Čo sa mi na dockerovi vždy nepáči:

• Aby moja aplikácia fungovala, potrebujem na serveri samotný Docker. Prečo to potrebujem, ak moje aplikácie bežia na jre alebo nodejs a prostredie pre ne je už na serveri?
• ak chcem spustiť svoj (súkromný) lokálne vytvorený obraz na vzdialenom serveri, potrebujem vlastné úložisko dockerov, potrebujem, aby niekde fungoval register a tiež musím nakonfigurovať https, pretože docker cli funguje iba cez https. Sakra... samozrejme existujú možnosti, ako uložiť obrázok lokálne cez docker save a stačí poslať obrázok cez scp... Ale to je veľa pohybov tela. A okrem toho to vyzerá ako „barličkové“ riešenie, kým sa neobjaví vaše vlastné úložisko
• docker-compose. Potrebný je len na prevádzku kontajnerov. To je všetko. Nič iné nedokáže. Docker-compose má veľa verzií svojich súborov, vlastnú syntax. Nech je to akokoľvek deklaratívne, nechce sa mi čítať ich dokumentáciu. Nikde inde ho nebudem potrebovať.
• pri práci v tíme väčšina ľudí píše súbor Dockerfile veľmi krivo, nerozumie, ako sa ukladá do vyrovnávacej pamäte, pridáva do obrázka všetko, čo potrebuje a nepotrebuje, dedí z obrázkov, ktoré nie sú v Dockerhube alebo súkromnom úložisku, vytvára docker-compose súbory s databázami a nič nezostane. Vývojári zároveň hrdo vyhlasujú, že Docker je cool, všetko im funguje lokálne a HR na voľné pracovné miesto dôležité píše: “Používame Docker a potrebujeme kandidáta s takými pracovnými skúsenosťami.”
• Neustále ma prenasledujú myšlienky o zvýšení všetkého v Docker: postgresql, kafka, redis. Je škoda, že nie všetko funguje v kontajneroch, nie všetko sa dá ľahko nakonfigurovať a spustiť. Podporujú to vývojári tretích strán a nie samotní predajcovia. A mimochodom, okamžite vyvstáva otázka: predajcovia sa nestarajú o údržbu svojich produktov v Dockeri, prečo je to tak, možno niečo vedia?
• Vždy vyvstáva otázka o perzistencii údajov kontajnera. a potom si pomyslíte, či by som mal len pripojiť hostiteľský adresár alebo vytvoriť zväzok ukotvenia alebo vytvoriť dátový kontajner, ktorý je teraz deprecated? Ak pripojím adresár, potom sa musím uistiť, že uid a gid používateľa v kontajneri sa zhodujú s id používateľa, ktorý kontajner spustil, inak sa súbory vytvorené kontajnerom vytvoria s právami root. Ak použijem volume potom sa údaje jednoducho vytvoria v niektorých /usr/* a bude tam rovnaký príbeh s uid a gid ako v prvom prípade. Ak spúšťate komponent tretej strany, musíte si prečítať dokumentáciu a hľadať odpoveď na otázku: „do ktorých adresárov kontajnera komponent zapisuje súbory?“

Vždy sa mi nepáčilo, že som sa musel príliš dlho motať s Dockerom v počiatočnom štádiu: Prišiel som na to, ako spustiť kontajnery, z akých obrázkov spustiť, vytvoril som Makefiles, ktoré obsahovali aliasy pre dlhé príkazy Docker. Nenávidel som docker-compose, pretože som sa nechcel učiť ďalší nástroj v ekosystéme dockerov. A docker-compose up Vadilo mi to, najmä ak sa tam ešte stretávali build konštrukcie, a nie už zostavené obrázky. Jediné, čo som naozaj chcel, bolo vyrobiť produkt efektívne a rýchlo. Ale nemohol som prísť na to, ako používať docker.

Predstavujeme Ansible

Nedávno (pred tromi mesiacmi) som spolupracoval s tímom DevOps, ktorého takmer každý člen mal negatívny postoj k Dockerovi. Z dôvodov:

• docker rules iptables (aj keď to môžete zakázať v daemon.json)
• docker je zabugovaný a nespustíme ho vo výrobe
• ak dôjde k zlyhaniu démona docker, potom sa zodpovedajúcim spôsobom zrútia všetky kontajnery s infraštruktúrou
• nie je potrebný docker
• prečo docker, ak existuje Ansible a virtuálne stroje

Pri tej istej práci som sa zoznámil s ďalším nástrojom - Ansible. Raz som o tom počul, ale nepokúšal som sa písať vlastné učebnice. A teraz som začal písať svoje úlohy a potom sa moja vízia úplne zmenila! Pretože som si uvedomil: Ansible má moduly na spustenie rovnakých kontajnerov dockerov, zostavení obrázkov, sietí atď., A kontajnery možno spustiť nielen lokálne, ale aj na vzdialených serveroch! Moja radosť nemala hraníc - našiel som NORMÁLNY nástroj a zahodil súbory Makefile a docker-compose, nahradili ich úlohy yaml. Kód bol zredukovaný použitím konštruktov ako loop, when, Atď

Docker na spúšťanie komponentov tretích strán, ako sú databázy

Nedávno som sa zoznámil so ssh tunelmi. Ukázalo sa, že je veľmi jednoduché „presmerovať“ port vzdialeného servera na lokálny port. Vzdialený server môže byť buď stroj v cloude, alebo virtuálny stroj spustený vo VirtualBoxe. Ak môj kolega alebo ja potrebujeme databázu (alebo nejaký iný komponent tretej strany), môžeme jednoducho spustiť server s týmto komponentom a vypnúť ho, keď server nie je potrebný. Presmerovanie portov má rovnaký účinok ako databáza spustená v kontajneri dokovacieho zariadenia.

Tento príkaz prepošle môj lokálny port na vzdialený server so systémom postgresql:

ssh -L 9000:localhost:5432 [chránené e-mailom]

Použitie vzdialeného servera rieši problém s tímovým vývojom. Takýto server môže využívať viacero vývojárov naraz, nemusia vedieť konfigurovať postgresql, rozumieť Dockeru a iným zložitostiam. Na vzdialenom serveri môžete nainštalovať rovnakú databázu do samotného Dockera, ak je ťažké nainštalovať konkrétnu verziu. Všetko, čo vývojári potrebujú, je poskytnúť ssh prístup!

Nedávno som čítal, že SSH tunely sú obmedzenou funkcionalitou bežnej VPN! Môžete jednoducho nainštalovať OpenVPN alebo iné implementácie VPN, nastaviť infraštruktúru a dať ju vývojárom na použitie. To je tak husté!

Našťastie, AWS, GoogleCloud a ďalšie vám poskytujú rok bezplatného používania, tak ich využite! Sú lacné, ak ich vypnete, keď sa nepoužívajú. Vždy som sa čudoval, prečo by som potreboval vzdialený server ako gcloud, zdá sa, že som ich našiel.

Ako lokálny virtuálny stroj môžete použiť rovnaký Alpine, ktorý sa aktívne používa v kontajneroch dokovacích staníc. No, alebo nejaké iné ľahké distribúcie, aby sa počítač rýchlejšie spúšťal.

Zrátané a podčiarknuté: môžete a mali by ste spúšťať databázy a ďalšie vymoženosti infraštruktúry na vzdialených serveroch alebo vo virtuálnom boxe. Na tieto účely nepotrebujem docker.

Trochu o obrázkoch a distribúcii dockerov

Už som písal статью v ktorej som chcel povedať, že používanie obrázkov dockerov neposkytuje žiadnu záruku. Obrázky ukotvenia sú potrebné iba na vytvorenie kontajnera ukotvenia. Ak inovujete na obrázok ukotvenia, potom inovujete na používanie kontajnerov ukotvenia a budete ich používať iba.

Videli ste niekde, kde vývojári softvéru portujú svoje produkty iba v dockerovom obrázku?
Výsledkom väčšiny produktov sú binárne súbory pre konkrétnu platformu, ktoré sa jednoducho pridajú do obrazu dockeru, ktorý sa zdedí z požadovanej platformy. Zamysleli ste sa niekedy nad tým, prečo je na dockerhube toľko podobných obrázkov? Zadajte napríklad nginx, uvidíte 100500 XNUMX obrázkov od rôznych ľudí. Títo ľudia nevyvinuli samotný nginx, jednoducho pridali oficiálny nginx do svojho dockerového obrazu a okorenili ho vlastnými konfiguráciami pre pohodlie spúšťania kontajnerov.

Vo všeobecnosti to môžete jednoducho uložiť do tgz, ak to niekto potrebuje spustiť v dockeri, nechajte ho pridať tgz do Dockerfile, zdediť z požadovaného prostredia a vytvoriť ďalšie buchty, ktoré nemenia samotnú aplikáciu v tgz. Každý, kto vytvorí docker image, bude vedieť, čo je tgz a čo potrebuje k práci. Takto používam docker tu

Zrátané a podčiarknuté: Nepotrebujem register dockerov, použijem nejaký druh S3 alebo len úložisko súborov, ako napríklad google drive/dropbox

Docker v CI

Všetky spoločnosti, v ktorých som pracoval, sú podobné. Zvyčajne sú to potraviny. To znamená, že majú jednu aplikáciu, jeden technologický zásobník (dobre, možno pár alebo tri programovacie jazyky).

Tieto spoločnosti používajú docker na svojich serveroch, kde beží proces CI. Otázka: Prečo potrebujete na svojich serveroch vytvárať projekty v kontajneri dokovacích staníc? Prečo jednoducho nepripraviť prostredie pre zostavenie, napríklad napísať Ansible playbook, ktorý na server, na ktorom bude zostavovanie prebiehať, nainštaluje potrebné verzie nodejs, php, jdk, skopíruje ssh kľúče atď.

Teraz už chápem, že si tým strieľam do vlastnej nohy, pretože docker svojou izoláciou neprináša žiaden zisk. Problémy, s ktorými som sa stretol s CI v docker:

• opäť potrebujete obrázok docker na vytvorenie. musíte hľadať obrázok alebo napísať svoj vlastný dockerfile.
• 90%, že potrebujete preposlať nejaké ssh kľúče, tajné údaje, ktoré nechcete zapisovať do obrazu dockeru.
• kontajner je vytvorený a zomrie, všetky vyrovnávacie pamäte sa stratia spolu s ním. ďalšia zostava znova stiahne všetky závislosti projektu, čo je časovo náročné a neefektívne a čas sú peniaze.

Developeri nestavajú projekty v docker kontajneroch (kedysi som bol taký fanúšik, naozaj ma to mrzí xD). V jave je možné mať niekoľko verzií a zmeniť ich jedným príkazom na ten, ktorý práve potrebujete. Rovnako je to aj v nodejs, tam je nvm.

Výkon

Verím, že docker je veľmi výkonný a flexibilný nástroj, to je jeho nevýhoda (znie to zvláštne, áno). S jeho pomocou sa naň môžu firmy jednoducho uchytiť a použiť ho tam, kde treba a nie. Vývojári spúšťajú svoje kontajnery, niektoré svoje prostredia, potom to všetko plynulo prechádza do CI a produkcie. Tím DevOps píše nejaký druh kódu na spustenie týchto kontajnerov.

Docker používajte iba na najnovšie fáze vo vašom pracovnom postupe, nevťahujte ju hneď na začiatku do projektu. Nevyrieši to vaše obchodné problémy. On len posunie problémy na INÝ level a ponúkne vlastné riešenia, vy budete robiť dvojitú prácu.

Keď je potrebný docker: Prišiel som na to, že docker je veľmi dobrý v optimalizácii daného procesu, ale nie v budovaní základnej funkcionality

Ak sa stále rozhodnete použiť docker, potom:

• buďte mimoriadne opatrní
• nenúťte vývojárov používať docker
• lokalizujte jeho použitie na jednom mieste, nerozširujte ho do všetkých repozitárov Dockefile a docker-compose

PS:

• Nedávno som narazil balič a hovoria, že to funguje veľmi dobre s Ansible a umožňuje vám zjednotiť proces vytvárania obrázkov (vrátane obrázkov dockerov)
• aj o dockerovi, zaujímavý článok

Ďakujem za prečítanie, prajem vám transparentné rozhodnutia vo vašich záležitostiach a produktívne pracovné dni!

Zdroj: hab.com