Docker este o jucărie sau nu? Sau este încă adevărat?

Bună ziua tuturor!

Chiar vreau să trec direct la subiect, dar ar fi mai corect să spun puțin despre povestea mea:

Intrare

Sunt un programator cu experiență în dezvoltarea aplicațiilor frontend cu o singură pagină, scala/java și nodejs pe server.

Pentru o perioadă destul de lungă (cu siguranță câțiva sau trei ani), am fost de părere că Docker este mana din cer și, în general, un instrument foarte tare și absolut fiecare dezvoltator ar trebui să îl poată folosi. Și din aceasta rezultă că fiecare dezvoltator ar trebui să aibă Docker instalat pe mașina locală. Ce zici de parerea mea, uita-te prin posturile vacante care sunt postate pe aceeasi hh. Fiecare secundă conține o mențiune despre docker, iar dacă îl deții, acesta va fi avantajul tău competitiv 😉

Pe drumul meu, am întâlnit mulți oameni, cu atitudinile lor diferite față de Docker și ecosistemul său. Unii au spus că acesta este un lucru convenabil care garantează funcționalitatea multiplatformă. Cei doi nu au înțeles de ce ar trebui să ruleze în containere și ce profit ar avea din asta, celui de-al treilea nu i-a păsat deloc și nu s-a deranjat (doar au scris codul și au plecat acasă - îi invidiez, prin cale :)

Motive de utilizare

De ce am folosit docker? Probabil din urmatoarele motive:

• lansarea bazei de date, 99% dintre aplicații le folosesc
• lansarea nginx pentru distribuția frontend și proxy către backend
• puteți împacheta aplicația într-o imagine docker, în acest fel aplicația mea va funcționa oriunde există docker, problema distribuției este rezolvată imediat
• Descoperirea serviciului din cutie, puteți crea microservicii, fiecare container (conectat la o rețea comună) poate ajunge cu ușurință la altul printr-un alias, foarte convenabil
• Este distractiv să creezi un container și să te „juci” în el.

Ce NU îmi place întotdeauna la docker:

• Pentru ca aplicația mea să funcționeze, am nevoie de Docker în sine pe server. De ce am nevoie de acest lucru dacă aplicațiile mele rulează pe jre sau nodejs și mediul pentru ele este deja pe server?
• dacă vreau să rulez imaginea mea (privată) construită local pe un server la distanță, atunci am nevoie de propriul depozit docker, am nevoie ca registry să funcționeze undeva și trebuie să configurez și https, deoarece docker cli funcționează doar peste https. La naiba... există opțiuni, desigur, pentru a salva imaginea local prin intermediul docker save și trimiteți imaginea prin scp... Dar sunt multe mișcări ale corpului. Și, în plus, arată ca o soluție de „cârjă” până când apare propriul tău depozit
• docker-compose. Este necesar doar pentru rularea containerelor. Asta e tot. Nu poate face nimic altceva. Docker-compose are o grămadă de versiuni ale fișierelor sale, propria sa sintaxă. Oricât de declarativ ar fi, nu vreau să citesc documentația lor. Nu voi avea nevoie de el în altă parte.
• când lucrează în echipă, majoritatea oamenilor scriu un fișier Dockerfile foarte strâmb, nu înțeleg cum este stocat în cache, adaugă tot ce au nevoie și nu au nevoie la imagine, moștenesc din imagini care nu sunt în Dockerhub sau într-un depozit privat, creează unele docker-compose fișiere cu baze de date și nimic nu persistă. În același timp, dezvoltatorii declară cu mândrie că Docker este cool, totul funcționează local pentru ei, iar HR important scrie în postul vacant: „Folosim Docker și avem nevoie de un candidat cu o astfel de experiență de lucru.”
• Sunt constant bântuit de gânduri despre ridicarea totul în Docker: postgresql, kafka, redis. Este păcat că nu totul funcționează în containere, nu totul este ușor de configurat și rulat. Acest lucru este susținut de dezvoltatori terți și nu de vânzătorii înșiși. Și, apropo, apare imediat întrebarea: vânzătorii nu își fac griji să își mențină produsele în Docker, de ce este asta, poate știu ei ceva?
• Întotdeauna apare întrebarea cu privire la persistența datelor containerului. și apoi te gândești, ar trebui să montez directorul gazdă sau să creez un volum docker sau să fac un container de date care este acum deprecated? Dacă montez un director, atunci trebuie să mă asigur că uid-ul și gid-ul utilizatorului din container se potrivesc cu id-ul utilizatorului care a lansat containerul, altfel fișierele create de container vor fi create cu drepturi root. Daca folosesc volume atunci datele vor fi pur și simplu create în unele /usr/* si va fi aceeasi poveste cu uid si gid ca in primul caz. Dacă lansați o componentă terță parte, trebuie să citiți documentația și să căutați răspunsul la întrebarea: „în ce directoare container scrie componenta fișiere?”

Întotdeauna nu mi-a plăcut faptul că a trebuit să mă chinuiesc cu Docker prea mult timp în stadiul inițial: Mi-am dat seama cum să lansez containere, din ce imagini să lansez, am creat Makefile-uri care conțineau alias-uri pentru comenzile Docker lungi. Am urât docker-compose pentru că nu am vrut să învăț un alt instrument în ecosistemul docker. ȘI docker-compose up M-a deranjat, mai ales dacă s-au mai întâlnit acolo build construcții, mai degrabă decât imagini deja asamblate. Tot ce îmi doream cu adevărat era să fac un produs eficient și rapid. Dar nu mi-am putut da seama cum să folosesc docker.

Vă prezentăm Ansible

Recent (acum trei luni), am lucrat cu o echipă DevOps, aproape fiecare membru al căruia a avut o atitudine negativă față de Docker. Pentru motive:

• docker reguli iptables (deși îl puteți dezactiva în daemon.json)
• Docker are erori și nu îl vom rula în producție
• dacă demonul docker se blochează, atunci toate containerele cu infrastructură se blochează în consecință
• nu este nevoie de docker
• de ce docker dacă există Ansible și mașini virtuale

La același loc de muncă, am făcut cunoștință cu un alt instrument - Ansible. Am auzit despre asta o dată, dar nu am încercat să-mi scriu propriile cărți de joc. Și acum am început să-mi scriu sarcinile și apoi viziunea mi s-a schimbat complet! Pentru că mi-am dat seama: Ansible are module pentru rularea acelorași containere docker, build-uri de imagini, rețele etc., iar containerele pot fi rulate nu numai local, ci și pe servere la distanță! Încântarea mea nu a cunoscut limite - am găsit un instrument NORMAL și mi-am aruncat fișierele Makefile și docker-compose, au fost înlocuite cu sarcini yaml. Codul a fost redus prin utilizarea unor constructe precum loop, when, Etc

Docker pentru rularea componentelor terțe, cum ar fi bazele de date

Recent m-am familiarizat cu tunelurile ssh. S-a dovedit că este foarte ușor să „redirecționați” portul unui server la distanță către un port local. Serverul la distanță poate fi fie o mașină în cloud, fie o mașină virtuală care rulează în VirtualBox. Dacă eu sau colegul meu avem nevoie de o bază de date (sau de o altă componentă terță parte), pur și simplu putem porni serverul cu această componentă și îl putem opri atunci când serverul nu este necesar. Redirecționarea portului oferă același efect ca o bază de date care rulează într-un container docker.

Această comandă trimite portul meu local către un server la distanță care rulează postgresql:

ssh -L 9000:localhost:5432 [e-mail protejat]

Utilizarea unui server la distanță rezolvă problema cu dezvoltarea echipei. Un astfel de server poate fi folosit de mai mulți dezvoltatori simultan; nu trebuie să poată configura postgresql, să înțeleagă Docker și alte complexități. Pe un server la distanță, puteți instala aceeași bază de date în Docker, dacă este dificil să instalați o anumită versiune. Tot ce au nevoie dezvoltatorii este să ofere acces ssh!

Am citit recent că tunelurile SSH sunt o funcționalitate limitată a unui VPN obișnuit! Puteți pur și simplu să instalați OpenVPN sau alte implementări VPN, să configurați infrastructura și să o oferiți dezvoltatorilor pentru utilizare. Este atât de tare!

Din fericire, AWS, GoogleCloud și alții vă oferă un an de utilizare gratuită, așa că folosiți-le! Sunt ieftine dacă le oprești când nu sunt folosite. Mereu m-am întrebat de ce aș avea nevoie de un server la distanță precum gcloud, se pare că le-am găsit.

Ca mașină virtuală locală, puteți utiliza același Alpine, care este utilizat în mod activ în containerele docker. Ei bine, sau alte distribuții ușoare pentru a face mașina să pornească mai rapid.

Concluzie: puteți și ar trebui să rulați baze de date și alte bunuri de infrastructură pe servere la distanță sau în virtualbox. Nu am nevoie de docker pentru aceste scopuri.

Câteva despre imaginile docker și despre distribuție

Am scris deja статью în care am vrut să transmit că utilizarea imaginilor docker nu oferă nicio garanție. Imaginile Docker sunt necesare numai pentru a crea un container Docker. Dacă faceți upgrade la o imagine Docker, atunci faceți upgrade pentru a utiliza containere Docker și le veți folosi numai.

Ați văzut undeva unde dezvoltatorii de software își port produsele doar într-o imagine docker?
Rezultatul majorității produselor sunt fișiere binare pentru o anumită platformă; acestea sunt pur și simplu adăugate la imaginea docker, care este moștenită de la platforma dorită. Te-ai întrebat vreodată de ce există atât de multe imagini similare pe dockerhub? Introduceți nginx, de exemplu, veți vedea 100500 de imagini de la diferite persoane. Acești oameni nu au dezvoltat nginx în sine, au adăugat pur și simplu nginx oficial la imaginea lor docker și l-au asezonat cu propriile configurații pentru confortul lansării containerelor.

În general, îl puteți stoca pur și simplu în tgz, dacă cineva trebuie să îl ruleze în docker, atunci lăsați-l să adauge tgz la Dockerfile, să moștenească din mediul dorit și să creeze pachete suplimentare care nu schimbă aplicația în sine în tgz. Oricine va crea o imagine Docker va ști ce este tgz și ce are nevoie pentru a lucra. Așa folosesc docker aici

Concluzie: nu am nevoie de docker registry, voi folosi un fel de S3 sau doar stocare de fișiere, cum ar fi google drive/dropbox

Docker în CI

Toate companiile pentru care am lucrat sunt similare. De obicei sunt produse alimentare. Adică au o aplicație, o stivă de tehnologie (ei bine, poate câteva sau trei limbaje de programare).

Aceste companii folosesc docker pe serverele lor unde rulează procesul CI. Întrebare: De ce trebuie să construiți proiecte într-un container docker pe serverele dvs.? De ce să nu pregătiți un mediu pentru construcție, de exemplu, să scrieți un manual Ansible care va instala versiunile necesare de nodejs, php, jdk, copiați cheile ssh etc. pe serverul pe care va avea loc construcția?

Acum înțeleg că asta mă împușc în picior, pentru că docker nu aduce niciun profit cu izolarea lui. Probleme pe care le-am întâlnit cu CI în docker:

• din nou, aveți nevoie de o imagine Docker pentru a construi. trebuie să căutați o imagine sau să scrieți propriul fișier docker.
• 90% că trebuie să redirecționați niște chei ssh, date secrete pe care nu doriți să le scrieți în imaginea docker.
• containerul este creat și moare, toate cache-urile se pierd odată cu el. Următoarea versiune va descărca din nou toate dependențele proiectului, ceea ce consumă timp și este ineficient, iar timpul înseamnă bani.

Dezvoltatorii nu construiesc proiecte în containere docker (am fost cândva un astfel de fan, într-adevăr, îmi pare rău pentru mine în trecut xD). În java este posibil să aveți mai multe versiuni și să le schimbați cu o singură comandă la cea de care aveți nevoie acum. La fel este și în nodejs, există nvm.

Producție

Cred că docker este un instrument foarte puternic și flexibil, acesta este dezavantajul său (suna ciudat, da). Cu ajutorul său, companiile se pot agăța cu ușurință de el și îl pot folosi acolo unde este nevoie și nu este necesar. Dezvoltatorii își lansează containerele, unele dintre mediile lor, apoi totul trece fără probleme în CI și producție. Echipa DevOps scrie un fel de cod pentru a rula aceste containere.

Folosiți doar docker activat cel mai recent etapa din fluxul dvs. de lucru, nu-l trageți în proiect la început. Nu vă va rezolva problemele de afaceri. El va muta problemele doar la ALLT nivel și va oferi propriile soluții, veți face treabă dublă.

Când este nevoie de docker: Am ajuns la concluzia că docker este foarte bun la optimizarea unui anumit proces, dar nu la construirea funcționalității de bază

Dacă tot decideți să utilizați docker, atunci:

• fii extrem de atent
• nu forțați dezvoltatorii să folosească docker
• localizați utilizarea sa într-un singur loc, nu o răspândiți în toate depozitele Dockefile și docker-compose

PS:

• Recent am dat peste ambalator și spun că funcționează foarte bine cu Ansible și vă permite să unificați procesul de construire a imaginilor (inclusiv imaginea docker)
• tot despre docker, articol interesant

Vă mulțumesc că ați citit, vă doresc decizii transparente în treburile voastre și zile de lucru productive!

Sursa: www.habr.com