Docker — je igračka ili nije? Ili ipak jeste?

Zdravo svima!

Zelo bi rad takoj začel s temo, vendar bo pravilneje, da najprej malo povem o svoji zgodbi:

Uvod

Sem programer z izkušnjami pri razvoju frontend enostranskih aplikacij, Scala/Java in Node.js na strežniku.

Dolgo časa (že zagotovo dve do tri leta) sem imel mnenje, da je Docker božja milost in zelo kul orodje ter da se mora vsaka razvijalec znati z njim služiti. Od tod izhaja, da bi moral imeti vsak razvijalec Docker na svojem lokalnem računalniku. Pravzaprav, če pogledate zaposlitvene oglase, ki se objavljajo na istem hh, v vsakem drugem je omenjeno, da je Docker zaželen, in če ga obvladate — to bo vaša konkurenčna prednost 😉

Na svoji poti sem se srečal z mnogimi ljudmi, ki so imeli različne poglede na Docker in njegovo ekosistem. Nekateri so rekli, da je to uporabna stvar, ki zagotavlja večplatformsko delovanje. Drugi niso razumeli, zakaj bi se morali zagnati v kontejnere in kakšna je korist od tega, tretjim pa je bilo povsem vseeno in se niso obremenjevali (preprosto so pisali kodo in šli domov — moram reči, da jim zavidam 🙂)

Razlogi za uporabo

Zakaj sem uporabljal Docker? Verjetno iz naslednjih razlogov:

• zaženem bazo podatkov, 99% aplikacij jih uporablja
• zaženem Nginx za razdeljevanje frontend-a in posredovanje na backend
• aplikacijo lahko zapakirate v Docker sliko, tako bo moja aplikacija delovala povsod, kjer je Docker, problem distribucije je takoj rešen
• odkrivanje storitev iz škatle, lahko delam mikroservise, vsak kontejner (priključen skupni mreži) zlahka doseže drugega po aliasu, zelo priročno
• zanimivo je ustvariti kontejner in 'igrati' vanj.

Kar mi nikoli ni bilo všeč pri Dockerju:

• da moje aplikacije delujejo, potrebujejo sam Docker na strežniku. Zakaj bi to potreboval, če moje aplikacije delujejo na JRE ali Node.js in je okolje zanje že na voljo na strežniku?
• če želim zagnati svoj (privatni) lokalno sestavljen sliko na oddaljenem strežniku, potrebujem svoj Docker repozitorij, treba je, da nekje deluje registracija in še treba je nastaviti HTTPS, ker Docker CLI deluje samo preko HTTPS. O hudiče... obstajajo seveda možnosti, da sliko lokalno shranim preko docker save in jo preko SCP preprosto prenesem... Ampak to je toliko opravkov. Pa tudi izgleda kot 'štempiljanje' rešitev, dokler ne dobim svojega repozitorija.
• docker-composePotrebno je samo za pokretanje kontejnera. I to je sve. Više ništa ne može. Docker-compose ima gomilu verzija svojih fajlova, svoj sintaksu. Kakav god da je deklarativan, ne želim da čitam njihovu dokumentaciju. Više mi nije potrebna.
• kada radite u timu, većina ljudi piše Dockerfile veoma loše, ne razumeju kako se kešira, dodaju u sliku sve što treba i ne treba, nasleđuju slike koje nisu na dockerhub ili privatnom repozitorijumu, prave neke docker-compose fajlove sa bazama podataka i ništa ne peristentiraju. Pri tom, programeri ponosno izjavljuju da je docker sjajan, da im sve radi lokalno i HR važno piše u oglasima: 'Koristimo docker i potrebni su nam kandidati sa takvim iskustvom.'
• stalno se javljaju misli o pokretanju svega u dockeru: postgresql, kafka, redis. Šteta što ne radi sve u kontejnerima, nije sve lako konfigurisati i pokrenuti. To podržavaju spoljnji developeri, a ne sami vendori. I, mimo toga, odmah se postavlja pitanje, zašto se vendori ne brinu o održavanju svojih proizvoda u dockeru, možda oni nešto znaju?
• uvek se postavlja pitanje o peristentnosti podataka kontejnera. Ovde razmišljaš, da li da samo montažiraš direktorijum na hostu ili da napravim docker volume ili da napravim data container koji je sada deprecated? Если я монтирую директорию то мне нужно убедиться что uid и gid пользователя в контейнере соответствует id пользователя запустившего контейнер, иначе файлы созданные контейнером будут созданы с правами владельца root. Если использую volume tako će podaci jednostavno biti kreirani u nekom /usr/* i biće ista priča sa uid i gid kao i u prvom slučaju. Ako pokrećeš stranu komponentu, moraš se udubiti u dokumentaciju i potražiti odgovor na pitanje: 'u koje direktorijume kontejner komponenta upisuje fajlove?'

Uvek mi je smetalo što moram predugo da se zadrži sa docker-om u početnoj fazi: smišljao sam kako da pokrećem kontejnere, iz kojih slika da se pokreću, pravio Makefile koji je sadržavao alijase za duge docker komande. Nimalo nisam voleo docker-compose, jer nisam hteo da učim još jedan alat iz ekosistema dockera. A docker-compose up to me je nerviralo, posebno, ako su se tu još nalazile build konstrukcije, a ne već sastavljene slike. Sve što sam zaista želeo — je da jednostavno efikasno i brzo pravim proizvod. Ali nikako nisam mogao da razjasnim upotrebu dockera.

Upoznavao se sa Ansible-om

Nedavno (pre tri meseca), radio sam sa DevOps timom, gotovo svaki član kojem je negativno gledao na docker. Zbog razloga:

• Docker upravlja iptables (iako ga možete isključiti u daemon.json)
• Docker je problematičan i nećemo ga pokretati u produkciji
• Ako docker daemon padne, automatski padaju svi kontejneri infrastrukture
• Nema potrebe za dockerom
• Zašto koristiti docker kada postoje Ansible i virtuelne mašine

Na istom poslu upoznao sam još jedan alat — Ansible. Nekada sam čuo za njega, ali nisam se usudio da pišem svoje playbook-e. Sada sam počeo da pišem svoje zadatke i moje viđenje se konačno promenilo! Shvatio sam da Ansible ima module za pokretanje istih docker kontejnera, izgradnju slika, mreža i slično, pri čemu se kontejneri mogu pokretati ne samo lokalno, već i na udaljenim serverima! Moj oduševljenje nije imalo granica — pronašao sam ODLIČAN alat i bacio svoje Makefile i docker-compose fajlove, zamenjeni su yaml zadacima. Koder sam smanjio koristeći konstrukcije poput loop, when, itd.

Docker za pokretanje spoljnih komponenata kao što su baze podataka

Nedavno sam se upoznao sa ssh tunelima. Ispostavilo se da je veoma jednostavno 'projuriti' port udaljenog servera na lokalni port. Udaljeni server može biti mašina u oblaku ili virtuelna mašina pokrenuta u VirtualBox-u. Ako meni ili mom kolegi bude potrebna baza podataka (ili neka druga spoljna komponenta), možemo jednostavno pokrenuti server sa tom komponentom i ugasiti ga kada nam server više nije potreban. Prolazak portova daje isti efekat kao da je baza podataka pokrenuta u docker kontejneru.

Ova komanda propušta moj lokalni port na udaljeni server sa postgresql:

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

Korišćenje udaljenog servera rešava problem saradnje u timu. Tim serverom može koristiti više programera, ne moraju znati kako da podešavaju postgresql, snalaze se sa docker-om i ostalim komplikacijama. Na udaljenom serveru može se instalirati ista baza podataka u docker-u, ako je teško instalirati specifičnu verziju. Sve što će programerima biti potrebno — to je ssh pristup!

Nedavno sam pročitao da su SSH tuneli ograničena funkcionalnost običnog VPN-a! Možete jednostavno postaviti OpenVPN ili druge implementacije VPN-a, podesiti infrastrukturu i omogućiti je programerima. To je zaista sjajno!

Na srečo AWS, GoogleCloud in drugi nudijo leto dni brezplačnega uporabe, zato jih izkoristite! So poceni, če jih izklopite, ko jih ne uporabljate. Vedno sem se spraševal, v kakšne namene bi potreboval oddaljen strežnik, kot je gcloud, zdi se, da sem jih našel.

Kot virtualni stroj na lokalnem sistemu lahko uporabite isti Alpine, ki se aktivno uporablja v docker kontejnerjih. Ali pa kakšne druge lahke distribucije, da se stroj hitreje naloži.

Zaključek: zagon baz podatkov in drugih infrastrukturnih komponent je mogoče in potrebno na oddaljenih strežnikih ali v virtualboxu. Docker mi za te namene ni potreben.

Nekaj o docker slikah in distribuciji

Že sem pisal članak v kateri sem želel sporočiti, da uporaba docker slik ne zagotavlja nobene garancije. Docker slike so potrebne le za ustvarjanje docker kontejnerja. Če se zaklenete na docker sliko, to pomeni, da se zaklenete na uporabo docker kontejnerjev in boste samo s temi.

Ste kdaj videli, da bi razvijalci programske opreme portirali svoje izdelke samo v docker sliki?
Rezultat večine izdelkov so binarne datoteke za določeno platformo, ki se preprosto dodajo v docker sliko, ki izhaja iz želene platforme. Ste se kdaj vprašali, zakaj je na dockerhubu toliko podobnih slik? Vtipkajte na primer nginx, videli boste 100500 slik različnih ljudi. Ti ljudje niso razvili samega nginxa, preprosto so v svojo docker sliko dodali uradni nginx in obogatili ga s svojimi konfiguracijami za lažji zagon kontejnerjev.

Na splošno jih lahko shranite preprosto v tgz, če bo kdorkoli želel to zagnati v dockerju, naj v Dockerfile doda tgz, izhaja iz želenega okolja in ustvari dodatne komponente, ki ne spreminjajo samega aplikacije v tgz. Tisti, ki bo ustvarjal docker sliko, bo vedel, kaj je ta tgz in kaj potrebuje za delo. Tako jaz uporabljam docker. tukaj

Zaključek: ne potrebujem docker registry, uporabil bom kakšen S3 ali preprosto datotečno shrambo, kot sta google drive/dropbox.

Docker v CI

Vse podjetja, v katerih sem delal, so si podobna. Na splošno so produktna. Torej imajo eno aplikacijo, en tehnološki sklad (morda dva - tri programske jezike).

Te podjetja uporabljajo Docker na svojih strežnikih, kjer se izvaja proces CI. Vprašanje je — zakaj bi bilo treba projekte zbirati v Docker kontejnerju na svojih strežnikih? Zakaj enostavno ne pripraviti okolja za zbiranje, na primer napisati Ansible playbook, ki bo namestil potrebne različice Node.js, PHP, JDK, kopiral SSH ključe itd. na strežnik, kjer bo potekala zbirka?

Zdaj razumem, da si streljam v koleno, ker Docker ne prinaša nobene koristi s svojo izolacijo. Problemi s CI v Dockerju, s katerimi sem se srečal:

• spet potrebujem Docker sliko za zbiranje. Treba je poiskati sliko ali napisati svoj Dockerfile.
• 90 % je, da je treba nekako posredovati SSH ključe, tajne podatke, ki jih nočem zapisati v Docker sliko.
• Kontejner se ustvari in umre, vsi predpomnilniki se izgubijo z njim. Naslednja zbirka bo znova prenašala vse odvisnosti projekta, kar je dolgotrajno in neučinkovito, čas pa je denar.

Razvijalci ne zbirajo projektov v Docker kontejnerjih (kdaj sem bil sam tak oboževalec, res mi je žal za preteklost xD). V Javi je možnost imeti več različic in jih z enojno ukazom spremeniti na tisto, ki jo potrebujemo zdaj. Enako je v Node.js, obstaja nvm.

Izlaz

Menim, da je Docker zelo močno in fleksibilno orodje, kar je njegova slabost (zveni čudno, da). S pomočjo njega se podjetja zlahka 'prijemajo' zanj, uporabljajo ga, kjer je potrebno in kjer ni. Razvijalci zaženejo svoje kontejnerje, neko svoje okolje, nato to vse gladko preide v CI in produkcijo. DevOps ekipa piše neke vrste 'kolesa', da zažene te kontejnerje.

Uporabite Docker le na najbolj zadnji stopnji v vašem delovnem procesu, ne vnašajte ga v projekt na začetku. Ne bo rešil vaših poslovnih težav. Le premaknil bo težave na DRUGO raven in ponujal svoje rešitve, vi pa boste opravljali dvojno delo.

Kdaj je Docker potreben: prišel sem do misli, da je Docker zelo dober pri optimizaciji postavljenega procesa, vendar ne pri gradnji osnovne funkcionalnosti.

Če se vseeno odločite uporabiti Docker, potem:

• bodite izjemno previdni
• ne nalagajte uporabe Dockera razvijalcem
• lokalizirajte njegovo uporabo na enem mestu, ne razpršite po vseh repozitorijih Dockerfile in docker-compose.

PS:

• Pred kratkim sem naletel na packer Inštrukcija in pravijo, da zelo dobro deluje z Ansible in omogoča standardizacijo postopka ustvarjanja slik (vključno z docker sliko)
• Tudi o dockerju, zanimiv članek

Hvala, da ste prebrali, želim vam jasne rešitve v vašem delu in produktivne delovne dni!

Izvor: habr.com