🥇Je li Docker igračka ili nije? Ili je ipak istina?

Pozdrav!

Stvarno želim odmah prijeći na temu, ali bilo bi ispravnije reći nešto o svojoj priči:

Ulazak

Ja sam programer s iskustvom u razvoju frontend single page aplikacija, scala/java i nodejs na poslužitelju.

Dosta dugo (definitivno par-tri godine) sam bio mišljenja da je Docker mana s neba i općenito vrlo cool alat i apsolutno svaki programer bi ga trebao znati koristiti. A iz ovoga slijedi da bi svaki programer trebao imati instaliran Docker na svom lokalnom računalu. Što je s mojim mišljenjem, pogledajte natječaje koji su objavljeni na istom hh. U svakom drugom se spominje docker, a ako ga posjedujete, to će biti vaša konkurentska prednost 😉

Na svom sam putu susreo mnogo ljudi koji imaju različite stavove prema Dockeru i njegovom ekosustavu. Neki su rekli da je to zgodna stvar koja jamči funkcionalnost na više platformi. Drugima nije bilo jasno zašto bi trebali trčati u kontejnere i kakva bi zarada bila od toga, trećima je uopće bilo svejedno i nisu se zamarali (samo su napisali kod i otišli kući - usput im zavidim :)

Razlozi za korištenje

Zašto sam koristio docker? Vjerojatno iz sljedećih razloga:

pokretanje baze podataka, 99% aplikacija ih koristi
pokretanje nginxa za frontend distribuciju i proxy prema backendu
možete zapakirati aplikaciju u docker sliku, na ovaj način će moja aplikacija raditi gdje god postoji docker, problem distribucije je odmah riješen
otkrivanje usluge izvan okvira, možete kreirati mikroservise, svaki spremnik (povezan na zajedničku mrežu) može lako doći do drugog putem aliasa, vrlo zgodno
Zabavno je stvoriti spremnik i "igrati" se u njemu.

Ono što mi se uvijek NE SVIĐA kod dockera:

Kako bi moja aplikacija radila, potreban mi je sam Docker na poslužitelju. Zašto mi to treba ako se moje aplikacije pokreću na jre ili nodejs i okruženje za njih je već na poslužitelju?
ako želim pokrenuti svoju (privatnu) lokalno izgrađenu sliku na udaljenom poslužitelju, tada mi treba vlastito docker spremište, trebam da registar radi negdje i također moram konfigurirati https, jer docker cli radi samo preko https-a. O, dovraga... postoje opcije, naravno, za lokalno spremanje slike putem docker save i samo pošalji sliku putem scp-a... Ali to je puno pokreta tijela. Osim toga, izgleda kao "štaka" rješenje sve dok se ne pojavi vlastiti repozitorij
docker-compose. Potreban je samo za pokretanje kontejnera. To je sve. On ne može ništa drugo. Docker-compose ima hrpu verzija svojih datoteka, vlastitu sintaksu. Koliko god to deklarativno bilo, ne želim čitati njihovu dokumentaciju. Neće mi trebati nigdje drugdje.
kada rade u timu, većina ljudi piše Dockerfile vrlo krivo, ne razumiju kako se predmemorira, dodaju sve što trebaju i ne trebaju na sliku, nasljeđuju slike koje nisu u Dockerhubu ili privatnom repozitoriju, stvaraju neke docker-compose datoteke s bazama podataka i ništa ne postoji. Istovremeno, developeri ponosno izjavljuju da je Docker cool, sve im radi lokalno, a HR važno piše u natječaju: “Koristimo Docker i trebamo kandidata s takvim radnim iskustvom.”
Stalno me progone misli o podizanju svega u Dockeru: postgresql, kafka, redis. Šteta je što ne radi sve u kontejnerima, nije sve lako konfigurirati i pokrenuti. To podržavaju programeri trećih strana, a ne sami dobavljači. I usput, odmah se postavlja pitanje: dobavljači se ne brinu o održavanju svojih proizvoda u Dockeru, zašto je to tako, možda oni nešto znaju?
Uvijek se postavlja pitanje postojanosti podataka spremnika. i onda mislite, trebam li samo montirati host direktorij ili stvoriti docker volumen ili napraviti spremnik podataka koji je sada deprecated? Ako montiram direktorij, tada moram biti siguran da uid i gid korisnika u spremniku odgovaraju ID-u korisnika koji je pokrenuo spremnik, inače će datoteke koje je stvorio spremnik biti stvorene s root pravima. Ako koristim volume tada će se podaci jednostavno stvoriti u nekim /usr/* i bit će ista priča s uid i gid kao u prvom slučaju. Ako pokrećete komponentu treće strane, morate pročitati dokumentaciju i potražiti odgovor na pitanje: "u koje direktorije spremnika komponenta piše datoteke?"

Uvijek mi se nije sviđala činjenica da sam predugo morao petljati s Dockerom u početnoj fazi: Shvatio sam kako pokrenuti spremnike, iz kojih slika pokrenuti, napravio Makefileove koji sadrže pseudonime dugih Docker naredbi. Mrzio sam docker-compose jer nisam želio naučiti još jedan alat u docker ekosustavu. I docker-compose up Smetalo mi je, pogotovo ako su se još tamo sreli build konstrukcije, a ne već sastavljene slike. Sve što sam stvarno želio bilo je napraviti proizvod učinkovito i brzo. Ali nisam mogao shvatiti kako koristiti docker.

Predstavljamo Ansible

Nedavno (prije tri mjeseca) sam radio s DevOps timom čiji je gotovo svaki član imao negativan stav prema Dockeru. Iz razloga:

docker pravila iptables (iako ga možete onemogućiti u daemon.json)
docker ima pogreške i nećemo ga pokrenuti u produkciji
ako se docker demon sruši, svi spremnici s infrastrukturom se sruše u skladu s tim
nema potrebe za dockerom
zašto docker ako postoji Ansible i virtualni strojevi

Na istom poslu sam upoznao još jedan alat - Ansible. Jednom sam čuo za to, ali nisam pokušao napisati svoje knjige. A sada sam počela pisati svoje zadatke i tada mi se vizija potpuno promijenila! Zato što sam shvatio: Ansible ima module za pokretanje istih docker spremnika, građenja slika, mreža itd., a spremnici se mogu pokretati ne samo lokalno, već i na udaljenim poslužiteljima! Moje oduševljenje nije imalo granica - pronašao sam NORMALNI alat i bacio svoj Makefile i docker-compose datoteke, zamijenjene su yaml zadacima. Kod je smanjen upotrebom konstrukata poput loop, when, Itd

Docker za pokretanje komponenti trećih strana kao što su baze podataka

Nedavno sam se upoznao sa ssh tunelima. Pokazalo se da je vrlo lako "proslijediti" port udaljenog poslužitelja na lokalni port. Udaljeni poslužitelj može biti ili stroj u oblaku ili virtualni stroj koji radi u VirtualBoxu. Ako moj kolega ili ja trebamo bazu podataka (ili neku drugu komponentu treće strane), možemo jednostavno pokrenuti poslužitelj s ovom komponentom i isključiti ga kada poslužitelj nije potreban. Prosljeđivanje porta daje isti učinak kao baza podataka koja radi u docker spremniku.

Ova naredba prosljeđuje moj lokalni port na udaljeni poslužitelj koji pokreće postgresql:

ssh -L 9000: localhost: 5432 [e-pošta zaštićena]

Korištenje udaljenog poslužitelja rješava problem razvoja tima. Takav poslužitelj može koristiti nekoliko programera odjednom; oni ne moraju biti u stanju konfigurirati postgresql, razumjeti Docker i druge zamršenosti. Na udaljenom poslužitelju možete instalirati istu bazu podataka u samom Dockeru, ako je teško instalirati određenu verziju. Sve što programeri trebaju je omogućiti ssh pristup!

Nedavno sam pročitao da su SSH tuneli ograničena funkcionalnost običnog VPN-a! Možete jednostavno instalirati OpenVPN ili druge VPN implementacije, postaviti infrastrukturu i dati je programerima na korištenje. Ovo je tako cool!

Srećom, AWS, GoogleCloud i drugi daju vam godinu dana besplatnog korištenja, stoga ih koristite! Jeftini su ako ih isključite kada nisu u upotrebi. Uvijek sam se pitao zašto bi mi trebao udaljeni poslužitelj poput gclouda, čini se da sam ih našao.

Kao lokalni virtualni stroj možete koristiti isti Alpine, koji se aktivno koristi u docker kontejnerima. Pa, ili neke druge lagane distribucije kako bi se stroj brže pokrenuo.

Zaključak: možete i trebate pokretati baze podataka i druge infrastrukturne pogodnosti na udaljenim poslužiteljima ili u virtualboxu. Ne treba mi docker za ove svrhe.

Malo o docker slikama i distribuciji

Već sam napisao članak u kojem sam želio poručiti da korištenje docker slika ne daje nikakvo jamstvo. Docker slike potrebne su samo za stvaranje docker spremnika. Ako nadograđujete na docker sliku, tada nadograđujete na korištenje docker spremnika i koristit ćete samo njih.

Jeste li igdje vidjeli gdje programeri softvera prenose svoje proizvode samo u docker sliku?
Rezultat većine proizvoda su binarne datoteke za određenu platformu; one se jednostavno dodaju u docker sliku, koja je naslijeđena od željene platforme. Jeste li se ikada zapitali zašto ima toliko sličnih slika na dockerhub-u? Unesite nginx na primjer, vidjet ćete 100500 slika od različitih ljudi. Ti ljudi nisu razvili sam nginx, oni su jednostavno dodali službeni nginx svojoj docker slici i začinili je vlastitim konfiguracijama za praktičnost pokretanja spremnika.

Općenito, možete ga jednostavno pohraniti u tgz, ako netko treba to pokrenuti u dockeru, onda neka doda tgz u Dockerfile, naslijedi iz željenog okruženja i stvori dodatne kiflice koje ne mijenjaju samu aplikaciju u tgz-u. Svatko tko će kreirati docker sliku znat će što je tgz i što mu je potrebno za rad. Ovako ja koristim docker ovdje

Zaključak: ne trebam docker registar, koristit ću neku vrstu S3 ili samo pohranu datoteka poput google diska/dropboxa

Docker u CI

Sve tvrtke za koje sam radio su slične. Obično su trgovina mješovitom robom. To jest, imaju jednu aplikaciju, jedan tehnološki skup (dobro, možda nekoliko ili tri programska jezika).

Te tvrtke koriste docker na svojim poslužiteljima gdje se izvodi CI proces. Pitanje: Zašto trebate graditi projekte u docker spremniku na svojim poslužiteljima? Zašto jednostavno ne pripremite okruženje za izgradnju, na primjer, napišete Ansible playbook koji će instalirati potrebne verzije nodejs, php, jdk, kopirati ssh ključeve itd. na poslužitelj na kojem će se odvijati izgradnja?

Sad mi je jasno da sam sebi pucao u nogu jer docker svojom izolacijom ne donosi nikakvu zaradu. Problemi na koje sam naišao s CI-jem u dockeru:

ponovno vam je potrebna docker slika za izgradnju. trebate potražiti sliku ili napisati vlastitu docker datoteku.
90% da trebate proslijediti neke ssh ključeve, tajne podatke koje ne želite pisati na docker sliku.
spremnik je kreiran i umire, svi predmemorije se gube zajedno s njim. sljedeća verzija će ponovno preuzeti sve ovisnosti projekta, što je dugotrajno i neučinkovito, a vrijeme je novac.

Programeri ne grade projekte u docker kontejnerima (nekoć sam bio takav fan, stvarno, žalim sam sebe u prošlosti xD). U Javi je moguće imati više verzija i jednom ih naredbom promijeniti u onu koja vam je sada potrebna. Isto je i u nodejsu, postoji nvm.

Izlaz

Vjerujem da je docker vrlo moćan i fleksibilan alat, to mu je mana (zvuči čudno, da). Uz njegovu pomoć tvrtke se lako mogu navući na njega i koristiti ga gdje treba i ne treba. Razvojni programeri pokreću svoje spremnike, neka svoja okruženja, a zatim se sve glatko ulijeva u CI i proizvodnju. DevOps tim piše neku vrstu koda za pokretanje ovih spremnika.

Koristite docker samo na najnoviji fazi vašeg tijeka rada, nemojte ga uvlačiti u projekt na početku. To neće riješiti vaše poslovne probleme. On će samo premjestiti probleme na DRUGU razinu i ponuditi vlastita rješenja, vi ćete napraviti dupli posao.

Kada je potreban docker: Došao sam do zaključka da je docker vrlo dobar u optimiziranju određenog procesa, ali ne i u izgradnji osnovne funkcionalnosti

Ako ipak odlučite koristiti docker, tada:

biti krajnje oprezan
nemojte tjerati programere da koriste docker
lokalizirati njegovu upotrebu na jednom mjestu, nemojte je širiti po svim Dockefile i docker-compose repozitorijima

PS:

Nedavno sam naišao paker i kažu da vrlo dobro radi s Ansibleom i omogućuje vam da objedinite proces izgradnje slika (uključujući docker sliku)
također o dockeru, zanimljiv članak

Hvala vam na čitanju, želim vam transparentne odluke u vašim poslovima i produktivne radne dane!

Izvor: www.habr.com

Je li Docker igračka ili nije? Ili je ipak istina?