Docker je igračka ili nije? Ili je još uvijek?

Pozdrav svima!

Zaista želim da pređem direktno na temu, ali bi bilo ispravnije da ispričam nešto o svojoj priči:

ulazak

Ja sam programer sa iskustvom u razvoju frontend jednostraničkih aplikacija, scala/java i nodejs na serveru.

Prilično dugo vremena (definitivno par-tri godine) bio sam mišljenja da je Docker mana s neba i općenito vrlo kul alat i apsolutno svaki programer bi trebao biti u mogućnosti da ga koristi. A iz ovoga proizilazi da bi svaki programer trebao imati instaliran Docker na svojoj lokalnoj mašini. Što je sa mojim mišljenjem, pogledajte slobodna radna mjesta koja su objavljena na istom hh. Svaki drugi sadrži spominjanje dockera, a ako ga posjedujete, ovo će biti vaša konkurentska prednost 😉

Na svom putu sreo sam mnogo ljudi, sa njihovim različitim stavovima prema Dockeru i njegovom ekosistemu. Neki su rekli da je ovo zgodna stvar koja garantuje funkcionalnost na više platformi. Drugima nije bilo jasno zašto treba da trče u kontejnerima i kolika bi bila zarada od toga, trećima je bilo svejedno i nije im smetalo (samo su napisali kod i otišli kući - zavidim im, po način :)

Razlozi za upotrebu

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

• pokretanje baze podataka, 99% aplikacija ih koristi
• pokretanje nginxa za frontend distribuciju i proxy za backend
• 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 iz kutije, možete kreirati mikrousluge, svaki kontejner (povezan na zajedničku mrežu) može lako doći do drugog preko aliasa, vrlo zgodno
• Zabavno je kreirati kontejner i "igrati se" u njemu.

Ono što mi se uvijek NE sviđa kod dockera:

• Da bi moja aplikacija radila, potreban mi je sam Docker na serveru. Zašto mi je ovo potrebno ako moje aplikacije rade na jre ili nodejs i okruženje za njih je već na serveru?
• ako želim da pokrenem svoju (privatnu) lokalno izgrađenu sliku na udaljenom serveru, onda mi je potrebno vlastito docker spremište, potreban mi je registar da negdje radi i također moram konfigurirati https, jer docker cli radi samo preko https. O, dovraga... postoje opcije, naravno, za lokalno spremanje slike putem docker save i samo pošaljite sliku putem scp-a... Ali to je puno pokreta tijela. Osim toga, izgleda kao “štaka” rješenje dok se ne pojavi vaše vlastito spremište
• docker-compose. Potreban je samo za pokretanje kontejnera. To je sve. Ne može ništa drugo. Docker-compose ima gomilu verzija svojih fajlova, sopstvenu sintaksu. Koliko god da je deklarativno, ne želim da čitam njihovu dokumentaciju. Neće mi trebati nigde drugde.
• kada rade u timu, većina ljudi napiše Dockerfile vrlo krivo, ne razumije kako se kešira, dodaju sve što im treba i ne treba u sliku, nasljeđuju slike koje nisu u Dockerhub-u ili privatnom spremištu, kreiraju neke docker-compose datoteke sa bazama podataka i ništa ne ostaje. Istovremeno, programeri s ponosom izjavljuju da je Docker kul, sve radi lokalno za njih, a HR važno piše u oglasu: „Koristimo Docker i potreban nam je kandidat sa takvim radnim iskustvom."
• Stalno me proganjaju misli o podizanju svega u Dockeru: postgresql, kafka, redis. Šteta što ne funkcionira sve u kontejnerima, nije sve lako konfigurirati i pokrenuti. Ovo podržavaju programeri trećih strana, a ne sami dobavljači. I usput, odmah se postavlja pitanje: dobavljači ne brinu o održavanju svojih proizvoda u Dockeru, zašto je to tako, možda oni nešto znaju?
• Uvijek se postavlja pitanje o postojanosti podataka kontejnera. i onda pomislite, da li da montiram host direktorij ili da kreiram docker volumen ili da napravim spremnik podataka koji je sada deprecated? Ako montiram direktorij, onda moram biti siguran da se uid i gid korisnika u kontejneru poklapaju sa ID-om korisnika koji je pokrenuo kontejner, u suprotnom će datoteke kreirane od strane kontejnera biti kreirane s root pravima. Ako koristim volume onda će se podaci jednostavno kreirati u nekim /usr/* i bit će ista priča sa uid-om i gid-om 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 kontejnera komponenta piše datoteke?"

Uvek mi se nije sviđala činjenica da sam morao predugo da petljam sa Dockerom u početnoj fazi: Shvatio sam kako da pokrenem kontejnere, iz kojih slika da se pokrenem, napravio sam Makefile koji su sadržavali pseudonime dugih Docker komandi. Mrzeo sam docker-compose jer nisam želio da naučim još jedan alat u docker ekosistemu. I docker-compose up To mi je smetalo, pogotovo ako su se tamo još sreli build konstrukcije, a ne već sastavljene slike. Sve što sam zaista želio je jednostavno napraviti proizvod efikasno i brzo. Ali nisam mogao da shvatim kako da koristim docker.

Predstavljamo Ansible

Nedavno (prije tri mjeseca) radio sam sa DevOps timom, čiji je skoro svaki član imao negativan stav prema Dockeru. iz razloga:

• docker pravila iptables (iako ih možete onemogućiti u daemon.json)
• docker greši i nećemo ga pokrenuti u produkciji
• ako se docker demon sruši, svi kontejneri s infrastrukturom padaju u skladu s tim
• nema potrebe za dockerom
• zašto docker ako postoje Ansible i virtuelne mašine

Na istom poslu sam upoznao još jedan alat - Ansible. Jednom sam čuo za to, ali nisam pokušao da napišem sopstvene knjige. A sada sam počeo da pišem svoje zadatke i tada mi se vizija potpuno promenila! Zato što sam shvatio: Ansible ima module za pokretanje istih docker kontejnera, gradnje slika, mreža itd., a kontejneri se mogu pokretati ne samo lokalno, već i na udaljenim serverima! Moje oduševljenje nije imalo granica - pronašao sam NORMALNI alat i bacio svoje Makefile i docker-compose datoteke, zamijenjeni su yaml zadacima. Kod je smanjen korištenjem konstrukcija poput loop, when, Itd

Docker za pokretanje komponenti treće strane kao što su baze podataka

Nedavno sam se upoznao sa ssh tunelima. Pokazalo se da je vrlo lako "proslijediti" port udaljenog servera na lokalni port. Udaljeni server može biti ili mašina u oblaku ili virtuelna mašina koja radi u VirtualBox-u. Ako mom kolegi ili meni treba baza podataka (ili neka druga komponenta treće strane), možemo jednostavno pokrenuti server sa ovom komponentom i isključiti ga kada server nije potreban. Prosljeđivanje portova daje isti učinak kao baza podataka koja radi u docker kontejneru.

Ova naredba prosljeđuje moj lokalni port na udaljeni server na kojem radi postgresql:

ssh -L 9000:localhost:5432 [email zaštićen]

Korišćenje udaljenog servera rešava problem sa razvojem tima. Takav server može koristiti nekoliko programera odjednom; ne moraju biti u stanju konfigurirati postgresql, razumjeti Docker i druge zamršenosti. Na udaljenom serveru možete instalirati istu bazu podataka u samom Dockeru, ako je teško instalirati određenu verziju. Sve što je potrebno programerima 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 super!

Srećom, AWS, GoogleCloud i drugi vam daju godinu dana besplatnog korištenja, pa ih koristite! Jeftini su ako ih isključite kada se ne koriste. Uvijek sam se pitao zašto bi mi trebao udaljeni server kao što je gcloud, izgleda da sam ih našao.

Kao lokalnu virtuelnu mašinu, možete koristiti isti Alpine, koji se aktivno koristi u docker kontejnerima. Pa, ili neke druge lagane distribucije da bi se mašina brže pokrenula.

Zaključak: možete i trebate pokrenuti baze podataka i druge infrastrukturne dodatke na udaljenim serverima ili u virtualboxu. Ne treba mi docker za ove svrhe.

Malo o docker slikama i distribuciji

Već sam pisao članak u kojem sam želio poručiti da korištenje docker slika ne daje nikakvu garanciju. Docker slike su potrebne samo za kreiranje docker kontejnera. Ako nadograđujete na docker sliku, tada nadograđujete da koristite docker kontejnere 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. Ovi ljudi nisu sami razvili nginx, oni su jednostavno dodali službeni nginx svojoj docker slici i začinili je svojim vlastitim konfiguracijama radi praktičnosti pokretanja kontejnera.

Općenito, možete ga jednostavno pohraniti u tgz, ako neko treba da ga pokrene u dockeru, onda neka doda tgz u Dockerfile, naslijedi iz željenog okruženja i kreira dodatne buns koje ne mijenjaju samu aplikaciju u tgz. Svako ko bude kreirao docker imidž znaće šta je tgz i šta mu treba da radi. Ovako koristim docker ovdje

Zaključak: ne treba mi docker registar, koristit ću neku vrstu S3 ili samo pohranu datoteka kao što je google drive/dropbox

Docker u CI

Sve kompanije u kojima sam radio su slične. Obično su to namirnice. Odnosno, imaju jednu aplikaciju, jedan tehnološki stek (pa, možda nekoliko ili tri programska jezika).

Ove kompanije koriste docker na svojim serverima na kojima se pokreće CI proces. Pitanje: Zašto je potrebno da gradite projekte u docker kontejneru na vašim serverima? 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 server na kojem će se graditi?

Sad razumijem da je ovo pucanje sebi u nogu, jer docker svojom izolacijom ne donosi nikakav profit. Problemi na koje sam naišao sa CI u docker-u:

• opet vam je potrebna docker slika za izgradnju. trebate potražiti sliku ili napisati vlastiti dockerfile.
• 90% da trebate proslijediti neke ssh ključeve, tajne podatke koje ne želite upisati u docker sliku.
• Kontejner se kreira i umire, svi kešovi se gube zajedno sa njim. sljedeća verzija će ponovo preuzeti sve ovisnosti o projektu, što je dugotrajno i neefikasno, a vrijeme je novac.

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

zaključak

Vjerujem da je docker vrlo moćan i fleksibilan alat, to je njegov nedostatak (zvuči čudno, da). Uz njegovu pomoć, kompanije se lako mogu navući na njega i koristiti ga gdje je potrebno, a ne potrebno. Programeri pokreću svoje kontejnere, neke od svojih okruženja, a onda se sve to glatko ulijeva u CI i proizvodnju. DevOps tim piše neku vrstu koda za pokretanje ovih kontejnera.

Koristite samo docker uključen najnoviji fazi u vašem toku rada, nemojte je uvlačiti u projekat na početku. To neće riješiti vaše poslovne probleme. On će samo premjestiti probleme na DRUGI nivo i ponuditi svoja rješenja, a vi ćete raditi dvostruki posao.

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

Ako se ipak odlučite koristiti docker, tada:

• budite izuzetno oprezni
• ne prisiljavajte programere da koriste docker
• lokalizirajte njegovu upotrebu na jednom mjestu, nemojte ga širiti po svim Dockefile i docker-compose spremištima

PS:

• Nedavno sam naišao paker i kažu da radi vrlo dobro sa Ansible-om i omogućava vam da ujedinite 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