Docker é un xoguete ou non? Ou aínda é certo?

Ola a todos!

Quero moito entrar directamente ao tema, pero sería máis correcto contar un pouco sobre a miña historia:

Entrada

Son un programador con experiencia no desenvolvemento de aplicacións frontend dunha soa páxina, scala/java e nodejs no servidor.

Durante bastante tempo (definitivamente un par ou tres anos), estiven da opinión de que Docker é maná do ceo e, en xeral, unha ferramenta moi xenial e absolutamente todos os desenvolvedores deberían poder usalo. E disto dedúcese que todos os desenvolvedores deberían ter instalado Docker na súa máquina local. E a miña opinión, mira as vacantes que se publican no mesmo hh. Cada segundo contén unha mención de docker, e se o posúes, esta será a túa vantaxe competitiva 😉

No meu camiño, coñecín moitas persoas, coas súas diferentes actitudes cara a Docker e o seu ecosistema. Algúns dixeron que isto é algo cómodo que garante a funcionalidade multiplataforma. Os segundos non entendían por que debían correr en contenedores e que beneficio sacaría, ao terceiro non lle importaba nada e non se molestaba (só escribiron o código e foron para a casa -envexoos, polo camiño :)

Motivos de uso

Por que usei docker? Probablemente polas seguintes razóns:

• inicio de base de datos, o 99% das aplicacións utilízaas
• lanzamento de nginx para a distribución frontend e proxy para o backend
• pode empaquetar a aplicación nunha imaxe docker, deste xeito a miña aplicación funcionará onde exista docker, o problema de distribución resólvese inmediatamente
• descubrimento de servizos fóra da caixa, pode crear microservizos, cada contedor (conectado a unha rede común) pode chegar facilmente a outro a través dun alias, moi cómodo
• É divertido crear un recipiente e "xogar" nel.

O que sempre NON me gusta de Docker:

• Para que a miña aplicación funcione, necesito o propio Docker no servidor. Por que necesito isto se as miñas aplicacións se executan en jre ou nodejs e o ambiente para elas xa está no servidor?
• se quero executar a miña imaxe (privada) construída localmente nun servidor remoto, entón necesito o meu propio repositorio docker, necesito que o rexistro funcione nalgún lugar e tamén teño que configurar https, porque docker cli só funciona sobre https. Caramba... hai opcións, por suposto, para gardar a imaxe localmente vía docker save e só envía a imaxe a través de scp... Pero iso son moitos movementos corporais. E ademais, parece unha solución de "muleta" ata que aparece o teu propio repositorio
• docker-compose. Só é necesario para executar contedores. Iso é todo. Non pode facer outra cousa. Docker-compose ten unha morea de versións dos seus ficheiros, a súa propia sintaxe. Por moi declarativo que sexa, non quero ler a súa documentación. Non o necesitarei en ningún outro lugar.
• cando traballa en equipo, a maioría da xente escribe un Dockerfile de forma moi torcida, non entende como se almacena en caché, engade todo o que necesita e non precisa á imaxe, herda de imaxes que non están en Dockerhub ou nun repositorio privado, crea algunhas docker-compose ficheiros con bases de datos e nada persiste. Ao mesmo tempo, os desenvolvedores declaran con orgullo que Docker é xenial, que todo funciona localmente para eles e RH escribe de xeito importante na vacante: "Usamos Docker e necesitamos un candidato con tal experiencia laboral".
• Estou constantemente perseguido por pensamentos sobre aumentar todo en Docker: postgresql, kafka, redis. É unha mágoa que non todo funcione en contedores, nin todo sexa fácil de configurar e executar. Isto é compatible con desenvolvedores de terceiros, e non polos propios provedores. E por certo, inmediatamente xorde a pregunta: os provedores non se preocupan por manter os seus produtos en Docker, por que isto, quizais saben algo?
• Sempre xorde a pregunta sobre a persistencia dos datos do contedor. e entón pensas, debería montar o directorio host ou crear un volume docker ou facer un contedor de datos que agora está deprecated? Se monto un directorio, entón teño que asegurarme de que o uid e o gid do usuario no contedor coincidan co id do usuario que iniciou o contenedor, se non, os ficheiros creados polo contedor crearanse con dereitos de root. Se uso volume entón simplemente crearanse os datos nalgúns /usr/* e haberá a mesma historia con uid e gid que no primeiro caso. Se está a lanzar un compoñente de terceiros, cómpre ler a documentación e buscar a resposta á pregunta: "en que directorios de contedores escribe ficheiros o compoñente?"

Sempre non me gustou o feito de ter que xogar con Docker durante moito tempo na fase inicial: descubrín como lanzar contedores, desde que imaxes lanzar, fixen Makefiles que contiñan alias para comandos longos de Docker. Odiaba docker-compose porque non quería aprender outra ferramenta no ecosistema docker. E docker-compose up Molestábame, sobre todo se aínda se atopaban alí build construcións, en lugar de imaxes xa ensambladas. Todo o que realmente quería era facer un produto de forma eficiente e rápida. Pero non puiden descubrir como usar o docker.

Presentación de Ansible

Recentemente (hai tres meses), traballei cun equipo de DevOps, case todos os membros do cal tiñan unha actitude negativa cara a Docker. Por razóns:

• docker rexe iptables (aínda que pode desactivalo en daemon.json)
• docker ten erros e non o executaremos en produción
• se o docker daemon falla, todos os contedores con infraestrutura fallan en consecuencia
• sen necesidade de docker
• por que docker se hai Ansible e máquinas virtuais

No mesmo traballo, coñecín outra ferramenta: Ansible. Oín falar diso unha vez, pero non tentei escribir os meus propios libros de xogo. E agora comecei a escribir as miñas tarefas e entón a miña visión cambiou por completo! Porque me decatei: Ansible ten módulos para executar os mesmos contedores docker, compilacións de imaxes, redes, etc., e os contedores pódense executar non só localmente, senón tamén en servidores remotos. A miña delicia non tiña límites: atopei unha ferramenta NORMAL e tirei os meus ficheiros Makefile e Docker-compose, substituíronse por tarefas yaml. O código reduciuse usando construcións como loop, when, Etc

Docker para executar compoñentes de terceiros como bases de datos

Recentemente coñecín os túneles ssh. Resultou que é moi sinxelo "reenviar" o porto dun servidor remoto a un porto local. O servidor remoto pode ser unha máquina na nube ou unha máquina virtual que se executa en VirtualBox. Se o meu colega ou eu necesitamos unha base de datos (ou algún outro compoñente de terceiros), simplemente podemos iniciar o servidor con este compoñente e desactivalo cando o servidor non sexa necesario. O reenvío de portos dá o mesmo efecto que unha base de datos que se executa nun contedor docker.

Este comando reenvía o meu porto local a un servidor remoto que executa postgresql:

ssh -L 9000:localhost:5432 [protexido por correo electrónico]

Usar un servidor remoto resolve o problema co desenvolvemento do equipo. Un servidor deste tipo pode ser usado por varios desenvolvedores á vez; non precisan ser capaces de configurar postgresql, comprender Docker e outras complejidades. Nun servidor remoto, pode instalar a mesma base de datos no propio Docker, se é difícil instalar unha versión específica. Todo o que necesitan os desenvolvedores é proporcionar acceso ssh!

Hai pouco lin que os túneles SSH son unha funcionalidade limitada dunha VPN normal. Pode simplemente instalar OpenVPN ou outras implementacións de VPN, configurar a infraestrutura e darlla aos desenvolvedores para que o usen. Isto é moi chulo!

Afortunadamente, AWS, GoogleCloud e outros danche un ano de uso gratuíto, así que úsaos. Son baratos se os apagas cando non os utilizas. Sempre me preguntei por que necesitaría un servidor remoto como gcloud, parece que os atopei.

Como máquina virtual local, podes usar o mesmo Alpine, que se usa activamente nos contedores docker. Ben, ou algunhas outras distribucións lixeiras para facer que a máquina arranque máis rápido.

Conclusión: podes e deberías executar bases de datos e outras vantaxes de infraestrutura en servidores remotos ou en virtualbox. Non necesito docker para estes propósitos.

Un pouco sobre as imaxes de docker e a distribución

Xa escribín un artigo no que quería transmitir que o uso de imaxes docker non proporciona ningunha garantía. As imaxes Docker só son necesarias para crear un contedor docker. Se está a actualizar a unha imaxe docker, entón está a actualizar para utilizar contedores docker e só os utilizará.

Viches algún lugar onde os desenvolvedores de software transporten os seus produtos só nunha imaxe docker?
O resultado da maioría dos produtos son ficheiros binarios para unha plataforma específica; simplemente engádense á imaxe docker, que se herda da plataforma desexada. Algunha vez te preguntas por que hai tantas imaxes similares en dockerhub? Introduce nginx, por exemplo, verás 100500 imaxes de diferentes persoas. Estas persoas non desenvolveron nginx en si, simplemente engadiron nginx oficial á súa imaxe docker e aderezárono coas súas propias configuracións para facilitar o lanzamento de contedores.

En xeral, pode simplemente gardalo en tgz, se alguén precisa executalo en docker, entón déixalle engadir tgz ao Dockerfile, herdar do ambiente desexado e crear bollos adicionais que non cambien a propia aplicación en tgz. Calquera persoa que cree unha imaxe docker saberá o que é tgz e o que precisa para traballar. Así uso o docker aquí

Conclusión: non necesito o rexistro docker, usarei algún tipo de S3 ou só almacenamento de ficheiros como google drive/dropbox

Docker en CI

Todas as empresas nas que traballei son similares. Normalmente son de supermercado. É dicir, teñen unha aplicación, unha pila de tecnoloxía (ben, quizais un par ou tres linguaxes de programación).

Estas empresas usan docker nos seus servidores onde se executa o proceso CI. Pregunta: Por que necesitas construír proxectos nun contedor docker nos teus servidores? Por que non simplemente preparar un ambiente para a compilación, por exemplo, escribir un manual de xogos de Ansible que instalará as versións necesarias de nodejs, php, jdk, copiará as claves ssh, etc. no servidor no que se realizará a compilación?

Agora entendo que isto me está pegando no pé, porque docker non trae ningún beneficio co seu illamento. Problemas que atopei con CI en docker:

• de novo necesitas unha imaxe docker para construír. necesitas buscar unha imaxe ou escribir o teu propio dockerfile.
• 90% que precisa reenviar algunhas claves ssh, datos secretos que non quere escribir na imaxe docker.
• o recipiente créase e morre, todos os cachés pérdense xunto con el. a seguinte compilación volverá descargar todas as dependencias do proxecto, o que leva moito tempo e é ineficaz, e o tempo é diñeiro.

Os desenvolvedores non constrúen proxectos en contedores docker (unha vez fun tan fan, realmente, sinto pena por min mesmo no pasado xD). En java é posible ter varias versións e cambialas cun comando ao que necesites agora. É o mesmo en nodejs, hai nvm.

Saída

Creo que o docker é unha ferramenta moi poderosa e flexible, este é o seu inconveniente (soa raro, si). Coa súa axuda, as empresas poden engancharse facilmente a el e usalo onde sexa necesario e non necesario. Os desenvolvedores lanzan os seus contedores, algúns dos seus ambientes, e despois todo flúe sen problemas á CI e á produción. O equipo de DevOps está escribindo algún tipo de código para executar estes contedores.

Use o docker só activado o máis recente no seu fluxo de traballo, non o arrastre ao proxecto ao principio. Non resolverá os seus problemas comerciais. El só moverá os problemas a OUTRO nivel e ofrecerá as súas propias solucións, faredes un dobre traballo.

Cando o docker é necesario: Cheguei á conclusión de que o docker é moi bo para optimizar o proceso dado pero non para construír a funcionalidade básica

Se aínda decides usar docker, entón:

• ter moito coidado
• non obrigue aos desenvolvedores a usar docker
• Localice o seu uso nun só lugar, non o estenda por todos os repositorios Dockefile e Docker-compose

PS:

• Recentemente atopeime empaquetador e din que funciona moi ben con Ansible e permite unificar o proceso de construción de imaxes (incluída a imaxe docker)
• tamén sobre docker, artigo interesante

Grazas por ler, deséxoche decisións transparentes nos teus asuntos e días laborais produtivos!

Fonte: www.habr.com