Docker — je li to igračka ili nije? Ili ipak jest?

Pozdrav svima!

Jako bih želio odmah početi s temom, ali ispravnije će biti da malo pričam o svojoj priči:

Uvod

Ja sam programer s iskustvom u razvoju frontend aplikacija, scala/java i nodejs na serveru.

Dugo sam vjerovao (već sigurno par — tri godine) da je Docker dar s neba, jako dobar alat i da bi svaki programer trebao znati kako ga koristiti. Iz toga slijedi da bi svaki programer trebao imati Docker instaliran na svom lokalnom računalu. Što se tiče mog mišljenja, pogledajte ponude poslova na istom hh. U svakoj drugoj spominje se Docker i ako ga posjedujete — to će vam biti konkurentska prednost 😉

Na svom putu susreo sam mnoge ljude s različitim stavovima prema Dockera i njegovom ekosustavu. Neki su govorili da je to zgodna stvar koja jamči unakrsnu platformsku kompatibilnost. Drugi nisu razumjeli zašto bi trebali raditi unutar kontejnera i kakvu korist od toga, nekima je bilo svejedno i nisu se opterećivali (samo su pisali kod i odlazili kući — usput, zavidim im 🙂)

Razlozi za korištenje

Zašto sam ja koristio Docker? Vjerojatno zbog sljedećih razloga:

• pokretanje baze podataka, 99% aplikacija koristi njih
• pokretanje nginx-a za isporuku frontenda i proksiranje na backend
• može se pakirati aplikacija u Docker sliku, tako da će moja aplikacija raditi svugdje gdje postoji Docker, problem distribucije je odmah riješen
• otkrivanje servisa iz kutije, moguće je napraviti mikroservise, svaki kontejner (spojen na zajedničku mrežu) lako može doći do drugog po aliasu, jako zgodno
• zgodno je kreirati kontejner i "igrati se" u njemu.

Što mi se uvijek NIKADA nije svidjelo u Dockeru:

• za da bi moja aplikacija radila, potreban je sam Docker na serveru. A zašto mi to, ako moje aplikacije rade na jre ili nodejs i okruženje za njih već postoji na serveru?
• ako želim pokrenuti svoju (privatnu) lokalno sastavljenu sliku na udaljenom serveru, trebam vlastiti Docker repozitorij, treba da negdje bude registry i također treba postaviti https, budući da Docker CLI radi samo preko https. Oh, brate… postoje opcije, naravno, pohraniti sliku lokalno koristeći docker save i jednostavno prebaciti sliku preko scp… Ali to je toliko poteškoća. I osim toga, izgleda kao "prividno" rješenje, dok ne dobijem svoj repozitorij
• docker-composeOn je potreban samo za pokretanje kontejnera. I to je sve. Više ništa ne može. Docker-compose ima hrpu verzija svojih datoteka, svoju sintaksu. Bez obzira koliko deklarativan bio, ne želim čitati njihovu dokumentaciju. Nije mi više nigdje potrebna.
• u timskom radu, većina ljudi najčešće piše Dockerfile vrlo loše, ne razumiju kako se kešira, dodaju u sliku sve što treba i ne treba, nasljeđuju slike koje ne postoje na dockerhubu ili privatnom repozitoriju, stvaraju neke docker-compose datoteke s bazama podataka i ništa ne perzistiraju. Pri tome, programeri ponosno izjavljuju da je docker super, sve im radi lokalno, a HR važno piše u oglasima za posao: "Koristimo docker i trebamo kandidata s takvim radnim iskustvom"
• neprestano me proganjaju misli o podizanju svega i svačega u dockeru: postgresql, kafka, redis. Šteta što ne radi sve u kontejnerima, nije sve lako konfigurirati i pokrenuti. Podržavaju to strana razvijatelji, a ne sami dobavljači. I, usput, odmah se postavlja pitanje, dobavljači se ne brinu oko održavanja svojih proizvoda u dockeru, zašto, možda oni nešto znaju?
• uvijek se postavlja pitanje o perzistenciji podataka kontejnera. I tada razmišljaš, trebam li jednostavno montirati domaći direktorij ili stvoriti docker volume ili napraviti data container koji sad deprecated? Если я монтирую директорию то мне нужно убедиться что uid и gid пользователя в контейнере соответствует id пользователя запустившего контейнер, иначе файлы созданные контейнером будут созданы с правами владельца root. Если использую volume će jednostavno stvoriti podatke u nekoj /usr/* i imat će istu priču s uid i gid kao u prvom slučaju. Ako pokrećeš komponente treće strane, treba se pozabaviti dokumentacijom i tražiti odgovor na pitanje: "u koje direktorije kontejnera komponenta zapisuje datoteke?"

Oduvijek mi se nije sviđalo što predugo mučim s dockerom u početnoj fazi: smišljao sam kako pokretati kontejneri, iz kojih slika pokretati, pravio Makefile koji je sadržavao alias za duge docker naredbe. Nimalo nisam volio docker-compose, jer nisam htio učiti još jedan alat ekosustava dockera. I docker-compose up to me nerviralo, pogotovo ako je tu još bilo build konstrukcija, a ne već izgrađenih slika. Sve što sam stvarno želio — bilo je jednostavno raditi produktivno i brzo. Ali nikako nisam mogao rašaliti korištenje dockera.

Upoznavanje s Ansibleom

Nedavno (prije tri mjeseca), radio sam s DevOps timom, gotovo svaki član tima negativno se odnosio prema dockeru. Iz razloga:

• Docker upravlja iptables (iako to možete isključiti u daemon.json)
• Docker je problematičan i nećemo ga pokretati u produkciji
• Ako Docker daemon padne, tada padaju i svi kontejneri s infrastrukturom
• U Dockeru nema potrebe
• Zašto Docker kada postoje Ansible i virtualne mašine

Na toj istoj radnoj mjestu upoznao sam još jedan alat — Ansible. Nekad sam čuo za njega, ali nisam pokušavao pisati svoje playbookove. A sada sam počeo pisati svoje zadatke i tu se moja percepcija potpuno promijenila! Jer sam shvatio: Ansible ima module za pokretanje istih Docker kontejnera, gradnju slika, mreže itd., pritom se kontejneri mogu pokrenuti ne samo lokalno, već i na udaljenim serverima! Mojoj oduševljenju nije bilo kraja — pronašao sam NORMALAN alat i odbacio sam svoje Makefile i docker-compose datoteke, koje su zamijenjene yaml zadacima. Kod je smanjen zahvaljujući korištenju konstrukcija poput loop, when, itd.

Docker za pokretanje vanjskih komponenti poput baze podataka

Nedavno sam se upoznao s SSH tunelima. Ispostavilo se da je vrlo lako "progurati" port udaljenog servera na lokalni port. Udaljeni server može biti bilo koja mašina u oblaku ili virtualna mašina pokrenuta u VirtualBoxu. Ako meni ili mom kolegi treba baza podataka (ili neka druga vanjska komponenta), možemo jednostavno pokrenuti server s tom komponentom i ugasiti ga kada više nije potreban. Propuštanje portova daje isti učinak kao i baza podataka pokrenuta u Docker kontejneru.

Ova komanda propušta moj lokalni port na udaljeni server s PostgreSQL-om:

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

Korištenje udaljenog servera rješava problem razvoja u timu. Taj server mogu koristiti više programera istovremeno, ne moraju znati kako postaviti PostgreSQL, razumjeti Docker i ostale kompleksnosti. Na udaljenom serveru možete instalirati istu bazu podataka u Dockeru, čak i ako je instalacija specifične verzije teška. Sve što programerima treba 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, postaviti infrastrukturu i omogućiti je programerima. To je toliko super!

Srećom, AWS, GoogleCloud i drugi nude godišnje besplatno korišćenje, zato ih iskoristite! Ekstremno su jeftini ako ih isključite kada se ne koriste. Uvek sam se pitao u kojim bih okolnostima mogao da koristim udaljeni server kao gcloud, čini se da sam pronašao odgovor.

Kao virtualnu mašinu na lokalnom okruženju možete koristiti isti Alpine koji se aktivno koristi u docker kontejnerima. Ili neke druge lakše distribucije kako bi brže pokrenuli mašinu.

Zaključak: pokretanje baza podataka i drugih infrastrukturnih dodataka moguće je i potrebno na udaljenim serverima ili u virtualbox-u. Ne treba mi docker za te svrhe.

Malo o docker slikama i distribuciji

Već sam pisao članak u kojem sam hteo da prenesem da korišćenje docker slika ne pruža nikakvu garanciju. Docker slike su potrebne samo za kreiranje docker kontejnera. Ako se oslanjate na docker sliku, to znači da se oslanjate na korišćenje docker kontejnera i samo ćete raditi s njima.

Da li ste ikada videli da programeri softvera portuju svoje proizvode isključivo u docker slikama?
Rezultat većine proizvoda su binarni fajlovi za određenu platformu, koji se jednostavno dodaju u docker sliku koja nasleđuje potrebnu platformu. Da li ste se ikada zapitali zašto ima toliko sličnih slika na dockerhub-u? Ukucajte, na primer, nginx, videćete 100500 slika od različitih ljudi. Ti ljudi nisu razvijali sam nginx, oni su jednostavno dodali zvanični nginx u svoju docker sliku i obogatili je svojim konfiguracijama radi lakšeg pokretanja kontejnera.

U suštini, može se jednostavno čuvati u tgz, ako nekome zatreba pokretanje u dockeru, neka dodaju tgz u Dockerfile, nasleđuju iz potrebnog okruženja i kreiraju dodatne funkcionalnosti koje ne menjaju samo aplikaciju u tgz. Onaj ko bude kreirao docker sliku znaće šta je to tgz i šta mu je potrebno za rad. Tako ja koristim docker. ovdje

Zaključak: ne treba mi docker registry, iskoristiću neko S3 ili jednostavno skladište datoteka poput google drive-a/dropbox-a.

Docker u CI

Sve kompanije u kojima sam radio slične su jedna drugoj. Obično su to kompanije orijentisane na proizvod. To jest, imaju neku aplikaciju, jedan tehnološki stog (možda dva - tri programska jezika).

Te tvrtke koriste Docker na svojim poslužiteljima gdje se pokreće CI proces. Pitam se — zašto je potrebno graditi projekte unutar Docker kontejnera na vlastitim poslužiteljima? Zašto jednostavno ne pripremiti okruženje za gradnju, na primjer, napisati Ansible playbook koji će instalirati potrebne verzije nodejs, php, jdk, kopirati ssh ključeve i slično na poslužitelj gdje će se odvijati gradnja?

Sada shvaćam da si pucam u nogu, jer Docker ne donosi nikakvu korist sa svojom izolacijom. Problemi s CI u Dockeru s kojima sam se susreo:

• opet je potreban Docker image za gradnju. Treba tražiti image ili napisati svoj Dockerfile.
• 90% slučajeva treba proslijediti neke ssh ključeve, tajne podatke koje ne želim pisati u Docker image.
• kontejner se stvara i umire, svi cache-ovi se gube s njim. Sljedeća gradnja će ponovno preuzeti sve ovisnosti projekta, a to je sporo i neučinkovito, a vrijeme — novac.

Programeri ne grade projekte unutar Docker kontejnera (nekada sam bio veliki obožavatelj, žao mi je svog prošlog ja xD). U Javi postoji mogućnost imati više verzija i promijeniti ih jednim naredbom na onu koja je potrebna sada. U Node.js je isto, postoji nvm.

Izvještaj

Smati da je Docker vrlo moćan i fleksibilan alat, u tome je njegova mana (zvuči čudno, zar ne). Pomoću njega se tvrtke lako ‘navuku’ na njega, koriste ga gdje treba i gdje ne treba. Programeri pokreću svoje kontejnere, svoje okruženje, a to sve polako prelazi u CI, produkciju. DevOps tim piše neki bicikl kako bi pokrenuli te kontejnere.

Koristite Docker samo na najnovijem stupnju u vašem radnom procesu, ne uvlačite ga u projekt na početku. On neće riješiti vaše poslovne probleme. Samo će ih premjestiti na DRUGU razinu i nuditi svoja rješenja, a vi ćete raditi dvostruki posao.

Kada je Docker potreban: došao sam do zaključka da je Docker vrlo dobar u optimizaciji postavljenog procesa, ali ne u izgradnji osnovne funkcionalnosti.

Ako ste ipak odlučili koristiti Docker, tada:

• budite izuzetno oprezni
• ne namećite korištenje Dockera programerima
• lokalizirajte njegovo korištenje na jednom mjestu, ne širite ga po svim repozitorijima Dockerfile i docker-compose

PS:

• Nedavno sam naišao na packer i kažu da jako dobro radi s Ansibleom i omogućava unificiranje procesa izrade slika (uključujući docker image)
• također o dockera, zanimljiv članak

Hvala što ste pročitali, želim vam transparentna rješenja u vašim poslovima i produktivne radne dane!

Izvor: habr.com