Docker és una joguina o no? O encara és cert?

Hola a tots!

Tinc moltes ganes d'anar directament al tema, però seria més correcte explicar una mica la meva història:

Entrada

Sóc un programador amb experiència en el desenvolupament d'aplicacions de pàgina única, scala/java i nodejs al servidor.

Durant força temps (definitivament un parell o tres d'anys), vaig pensar que Docker és el mannà del cel i, en general, una eina molt interessant i absolutament tots els desenvolupadors haurien de poder utilitzar-lo. I d'això es dedueix que tots els desenvolupadors haurien de tenir Docker instal·lat a la seva màquina local. Què passa amb la meva opinió, mireu les vacants que es publiquen al mateix hh. Cada segon conté una menció a Docker, i si el teniu, aquest serà el vostre avantatge competitiu 😉

En el meu camí, vaig conèixer molta gent, amb les seves diferents actituds cap a Docker i el seu ecosistema. Alguns van dir que això és una cosa convenient que garanteix la funcionalitat multiplataforma. Els segons no entenien per què s'havien de córrer en contenidors i quin benefici en sortirien, al tercer no li va importar gens ni es va molestar (només van escriure el codi i se'n van anar a casa -els envejo, per la manera :)

Motius d'ús

Per què vaig utilitzar Docker? Probablement pels motius següents:

• llançament de la base de dades, el 99% de les aplicacions les utilitzen
• llançant nginx per a la distribució de front-end i el proxy al backend
• podeu empaquetar l'aplicació en una imatge docker, d'aquesta manera la meva aplicació funcionarà allà on hi hagi docker, el problema de distribució es resol immediatament
• descobriment de serveis des de la caixa, podeu crear microserveis, cada contenidor (connectat a una xarxa comuna) pot arribar fàcilment a un altre mitjançant un àlies, molt convenient
• És divertit crear un contenidor i "jugar"-hi.

El que sempre NO M'agrada de Docker:

• Perquè la meva aplicació funcioni, necessito Docker al servidor. Per què ho necessito si les meves aplicacions s'executen a jre o nodejs i l'entorn d'aquestes ja es troba al servidor?
• si vull executar la meva imatge (privada) construïda localment en un servidor remot, necessito el meu propi dipòsit docker, necessito que el registre funcioni en algun lloc i també necessito configurar https, perquè docker cli només funciona amb https. Oh carai... hi ha opcions, és clar, per desar la imatge localment via docker save i només envia la imatge via scp... Però això són molts moviments corporals. I, a més, sembla una solució de "muleta" fins que apareix el vostre propi dipòsit
• docker-compose. Només és necessari per fer funcionar contenidors. Això és tot. No pot fer res més. Docker-compose té un munt de versions dels seus fitxers, la seva pròpia sintaxi. Per molt que sigui declaratiu, no vull llegir la seva documentació. No el necessitaré enlloc més.
• Quan treballa en equip, la majoria de la gent escriu un Dockerfile de manera molt torcida, no entén com s'emmagatzema a la memòria cau, afegeix tot el que necessiten i no necessiten a la imatge, hereta d'imatges que no es troben a Dockerhub o un repositori privat, crea alguna cosa. docker-compose fitxers amb bases de dades i res persisteix. Al mateix temps, els desenvolupadors declaren amb orgull que Docker és fantàstic, que tot funciona localment per a ells i que HR escriu de manera important a la vacant: "Utilitzem Docker i necessitem un candidat amb aquesta experiència laboral".
• Em persegueixen constantment els pensaments sobre com plantejar-ho tot a Docker: postgresql, kafka, redis. És una llàstima que no tot funcioni en contenidors, no tot sigui fàcil de configurar i executar. Això és compatible amb desenvolupadors de tercers, i no pels propis venedors. I, per cert, de seguida sorgeix la pregunta: els venedors no es preocupen per mantenir els seus productes a Docker, per què això, potser saben alguna cosa?
• Sempre sorgeix la pregunta sobre la persistència de les dades dels contenidors. i llavors penses, hauria de muntar el directori amfitrió o crear un volum docker o fer un contenidor de dades que ara és deprecated? Si munto un directori, he d'assegurar-me que l'uid i el gid de l'usuari del contenidor coincideixen amb l'identificador de l'usuari que ha llançat el contenidor, en cas contrari, els fitxers creats pel contenidor es crearan amb drets d'arrel. Si faig servir volume llavors les dades es crearan simplement en alguns /usr/* i hi haurà la mateixa història amb uid i gid que en el primer cas. Si esteu llançant un component de tercers, heu de llegir la documentació i buscar la resposta a la pregunta: "en quins directoris de contenidors el component escriu fitxers?"

Sempre no m'ha agradat el fet que hagués de jugar amb Docker durant massa temps en la fase inicial: Vaig descobrir com llançar contenidors, des de quines imatges s'havia de llançar, vaig fer Makefiles que contenien àlies per a ordres llargues de Docker. Odiava docker-compose perquè no volia aprendre una altra eina a l'ecosistema docker. I docker-compose up Em va molestar, sobretot si encara es van trobar allà build construccions, més que imatges ja muntades. Tot el que realment volia era fer un producte de manera eficient i ràpida. Però no he pogut esbrinar com utilitzar Docker.

Presentació d'Ansible

Recentment (fa tres mesos), vaig treballar amb un equip de DevOps, gairebé tots els membres del qual tenien una actitud negativa cap a Docker. Per raons:

• docker regles iptables (tot i que podeu desactivar-lo a daemon.json)
• Docker té errors i no l'executarem en producció
• si el dimoni docker es bloqueja, tots els contenidors amb infraestructura es bloquegen en conseqüència
• sense necessitat de docker
• per què docker si hi ha Ansible i màquines virtuals

En el mateix treball, em vaig familiaritzar amb una altra eina: Ansible. En vaig sentir parlar una vegada, però no vaig intentar escriure els meus propis llibres de joc. I ara vaig començar a escriure les meves tasques i després la meva visió va canviar completament! Perquè em vaig adonar: Ansible té mòduls per executar els mateixos contenidors docker, compilacions d'imatges, xarxes, etc., i els contenidors es poden executar no només localment, sinó també en servidors remots! El meu plaer no tenia límits: vaig trobar una eina NORMAL i vaig llençar els meus fitxers Makefile i Docker-compose, es van substituir per tasques yaml. El codi es va reduir utilitzant construccions com loop, when, Etc

Docker per executar components de tercers, com ara bases de dades

Fa poc em vaig familiaritzar amb els túnels ssh. Va resultar que és molt fàcil "reenviar" el port d'un servidor remot a un port local. El servidor remot pot ser una màquina al núvol o una màquina virtual que s'executa a VirtualBox. Si el meu company o jo necessitem una base de dades (o algun altre component de tercers), simplement podem iniciar el servidor amb aquest component i apagar-lo quan el servidor no sigui necessari. El reenviament de ports dóna el mateix efecte que una base de dades que s'executa en un contenidor docker.

Aquesta ordre reenvia el meu port local a un servidor remot amb postgresql:

ssh -L 9000: localhost: 5432 [protegit per correu electrònic]

L'ús d'un servidor remot resol el problema del desenvolupament de l'equip. Aquest servidor pot ser utilitzat per diversos desenvolupadors alhora; no cal que puguin configurar postgresql, entendre Docker i altres complexitats. En un servidor remot, podeu instal·lar la mateixa base de dades al mateix Docker, si és difícil instal·lar una versió específica. Tot el que necessiten els desenvolupadors és proporcionar accés ssh!

Recentment he llegit que els túnels SSH són una funcionalitat limitada d'una VPN normal. Només podeu instal·lar OpenVPN o altres implementacions de VPN, configurar la infraestructura i donar-la als desenvolupadors perquè l'utilitzin. Això és genial!

Afortunadament, AWS, GoogleCloud i altres us ofereixen un any d'ús gratuït, així que feu-los servir! Són barats si els apagueu quan no els feu servir. Sempre em vaig preguntar per què necessitaria un servidor remot com gcloud, sembla que els vaig trobar.

Com a màquina virtual local, podeu utilitzar la mateixa Alpine, que s'utilitza activament als contenidors Docker. Bé, o algunes altres distribucions lleugeres per fer que la màquina arrenqui més ràpid.

Conclusió: podeu i heu d'executar bases de dades i altres avantatges d'infraestructura en servidors remots o en virtualbox. No necessito docker per a aquests propòsits.

Una mica sobre les imatges i la distribució de Docker

Ja vaig escriure un article en el qual volia transmetre que l'ús d'imatges docker no ofereix cap garantia. Les imatges Docker només són necessàries per crear un contenidor Docker. Si actualitzeu a una imatge Docker, s'està actualitzant per utilitzar contenidors Docker i només els utilitzareu.

Heu vist en algun lloc on els desenvolupadors de programari porten els seus productes només a una imatge de Docker?
El resultat de la majoria de productes són fitxers binaris per a una plataforma específica; simplement s'afegeixen a la imatge docker, que s'hereta de la plataforma desitjada. Us heu preguntat mai per què hi ha tantes imatges semblants a dockerhub? Introduïu nginx, per exemple, veureu 100500 imatges de diferents persones. Aquestes persones no van desenvolupar nginx en si, simplement van afegir nginx oficial a la seva imatge docker i l'han condimentat amb les seves pròpies configuracions per a la comoditat de llançar contenidors.

En general, simplement podeu emmagatzemar-lo a tgz, si algú l'ha d'executar a docker, deixeu-lo afegir tgz al Dockerfile, heretar de l'entorn desitjat i crear paquets addicionals que no canviïn l'aplicació mateixa a tgz. Qualsevol que creï una imatge Docker sabrà què és tgz i què necessita per treballar. Així és com faig servir Docker aquí

Conclusió: no necessito registre docker, faré servir algun tipus de S3 o només emmagatzematge de fitxers com Google Drive/dropbox

Docker a CI

Totes les empreses per a les quals he treballat són semblants. Normalment són de queviures. És a dir, tenen una aplicació, una pila de tecnologia (bé, potser un parell o tres de llenguatges de programació).

Aquestes empreses utilitzen Docker als seus servidors on s'executa el procés CI. Pregunta: Per què necessiteu crear projectes en un contenidor docker als vostres servidors? Per què no preparar un entorn per a la compilació, per exemple, escriure un llibre de jugades d'Ansible que instal·li les versions necessàries de nodejs, php, jdk, copieu les claus ssh, etc. al servidor en què es durà a terme la compilació?

Ara entenc que això m'està disparant al peu, perquè Docker no aporta cap benefici amb el seu aïllament. Problemes que he trobat amb CI a Docker:

• de nou, necessiteu una imatge Docker per construir. heu de buscar una imatge o escriure el vostre propi fitxer docker.
• 90% que necessiteu reenviar algunes claus ssh, dades secretes que no voleu escriure a la imatge de Docker.
• el contenidor es crea i mor, amb ell es perden totes les memòria cau. la propera compilació tornarà a descarregar totes les dependències del projecte, que requereix molt de temps i és ineficaç, i el temps és diners.

Els desenvolupadors no creen projectes en contenidors docker (una vegada vaig ser un fanàtic, realment, em sap greu xD). A java és possible tenir diverses versions i canviar-les amb una ordre a la que necessiteu ara. És el mateix a nodejs, hi ha nvm.

Sortida

Crec que Docker és una eina molt potent i flexible, aquest és el seu inconvenient (sona estrany, sí). Amb la seva ajuda, les empreses poden enganxar-s'hi fàcilment i utilitzar-lo on sigui necessari i no necessari. Els desenvolupadors llancen els seus contenidors, alguns dels seus entorns, després tot flueix sense problemes a CI i producció. L'equip de DevOps està escrivint algun tipus de codi per executar aquests contenidors.

Utilitzeu el Docker només activat el més recent etapa del vostre flux de treball, no l'arrossegueu al projecte al principi. No resoldrà els teus problemes empresarials. Només traslladarà els problemes a UN ALTRE nivell i oferirà les seves pròpies solucions, tu faràs doble feina.

Quan es necessita docker: Vaig arribar a la conclusió que Docker és molt bo per optimitzar un procés determinat, però no per crear funcionalitats bàsiques

Si encara decidiu utilitzar Docker, aleshores:

• tingueu molta cura
• No obligueu els desenvolupadors a utilitzar Docker
• localitzeu el seu ús en un sol lloc, no el difongueu a tots els dipòsits Dockefile i Docker-Compose

PS:

• Fa poc m'he trobat embalador i diuen que funciona molt bé amb Ansible i us permet unificar el procés de creació d'imatges (inclosa la imatge Docker)
• també sobre docker, article interessant

Gràcies per llegir-vos, us desitjo decisions transparents en els vostres assumptes i dies de treball productius!

Font: www.habr.com