¿Docker es un juguete o no? ¿O sigue siendo cierto?

Hola a todos!

Tengo muchas ganas de ir directo al tema, pero sería más correcto contar un poco de mi historia:

Entrada

Soy un programador con experiencia en el desarrollo de aplicaciones frontend de una sola página, scala/java y nodejs en el servidor.

Durante bastante tiempo (definitivamente un par o tres años), opiné que Docker es maná del cielo y, en general, una herramienta genial que absolutamente todos los desarrolladores deberían poder utilizar. Y de esto se deduce que cada desarrollador debería tener Docker instalado en su máquina local. Y mi opinión, mira las vacantes que se publican en el mismo hh. Cada segundo contiene una mención a Docker y, si lo posees, esta será tu ventaja competitiva 😉

En el camino conocí a mucha gente, con sus diferentes actitudes hacia Docker y su ecosistema. Algunos dijeron que esto es algo conveniente que garantiza la funcionalidad multiplataforma. Los segundos no entendían por qué deberían funcionar en contenedores y qué ganancias obtendrían de ello, a los terceros no les importó en absoluto y no se molestaron (simplemente escribieron el código y se fueron a casa; los envidio, por cierto). forma :)

Razones de uso

¿Por qué utilicé la ventana acoplable? Probablemente por las siguientes razones:

• lanzamiento de base de datos, el 99% de las aplicaciones las utilizan
• Lanzamiento de nginx para distribución frontend y proxy al backend.
• puedes empaquetar la aplicación en una imagen de Docker, de esta manera mi aplicación funcionará dondequiera que exista Docker, el problema de distribución se resuelve de inmediato.
• descubrimiento de servicios listo para usar, puede crear microservicios, cada contenedor (conectado a una red común) puede llegar fácilmente a otro a través de un alias, muy conveniente
• Es divertido crear un contenedor y “jugar” en él.

Lo que siempre NO me gusta de Docker:

• Para que mi aplicación funcione, necesito Docker en el servidor. ¿Por qué necesito esto si mis aplicaciones se ejecutan en jre o nodejs y el entorno para ellas ya está en el servidor?
• Si quiero ejecutar mi imagen (privada) creada localmente en un servidor remoto, entonces necesito mi propio repositorio de Docker, necesito que el registro funcione en algún lugar y también necesito configurar https, porque Docker CLI solo funciona a través de https. Maldita sea... hay opciones, por supuesto, para guardar la imagen localmente a través de docker save y simplemente envía la imagen a través de scp... Pero eso son muchos movimientos corporales. Y además, parece una solución “muleta” hasta que aparece tu propio repositorio
• docker-compose. Sólo es necesario para ejecutar contenedores. Eso es todo. No puede hacer nada más. Docker-compose tiene un montón de versiones de sus archivos, su propia sintaxis. No importa cuán declarativo sea, no quiero leer su documentación. No lo necesitaré en ningún otro lugar.
• Cuando trabajan en equipo, la mayoría de las personas escriben un Dockerfile de manera muy torcida, no entienden cómo se almacena en caché, agregan todo lo que necesitan y no necesitan a la imagen, heredan de imágenes que no están en Dockerhub o en un repositorio privado, crean algunas docker-compose archivos con bases de datos y nada persiste. Al mismo tiempo, los desarrolladores declaran con orgullo que Docker es genial, que todo funciona localmente para ellos y RR.HH. escribe de manera importante en la vacante: "Usamos Docker y necesitamos un candidato con esa experiencia laboral".
• Constantemente me persiguen pensamientos sobre cómo crear todo en Docker: postgresql, kafka, redis. Es una pena que no todo funcione en contenedores, no todo es fácil de configurar y ejecutar. Esto cuenta con el respaldo de desarrolladores externos y no de los propios proveedores. Y, por cierto, inmediatamente surge la pregunta: los proveedores no se preocupan por mantener sus productos en Docker, ¿por qué? ¿Quizás sepan algo?
• Siempre surge la pregunta sobre la persistencia de los datos del contenedor. y luego piensas, ¿debería simplemente montar el directorio host o crear un volumen acoplable o crear un contenedor de datos que ahora es deprecated? Si monto un directorio, debo asegurarme de que el uid y el gid del usuario en el contenedor coincidan con la identificación del usuario que inició el contenedor; de lo contrario, los archivos creados por el contenedor se crearán con derechos de root. si uso volume entonces los datos simplemente se crearán en algún /usr/* y habrá la misma historia con uid y gid que en el primer caso. Si está ejecutando un componente de terceros, debe leer la documentación y buscar la respuesta a la pregunta: "¿en qué directorios de contenedores escribe archivos el componente?"

Siempre no me gustó el hecho de tener que jugar con Docker durante demasiado tiempo. en la etapa inicial: Descubrí cómo iniciar contenedores, desde qué imágenes iniciar, creé Makefiles que contenían alias para comandos largos de Docker. Odiaba Docker-Compose porque no quería aprender otra herramienta en el ecosistema de Docker. Y docker-compose up Me molestó, especialmente si todavía se encontraban allí. build construcciones, en lugar de imágenes ya ensambladas. Lo único que realmente quería era crear un producto de manera eficiente y rápida. Pero no pude entender cómo usar Docker.

Presentando Ansible

Recientemente (hace tres meses), trabajé con un equipo de DevOps, casi todos los miembros del cual tenían una actitud negativa hacia Docker. Por razones:

• Docker gobierna iptables (aunque puedes desactivarlo en daemon.json)
• Docker tiene errores y no lo ejecutaremos en producción.
• Si el demonio acoplable falla, todos los contenedores con infraestructura fallan en consecuencia
• no hay necesidad de ventana acoplable
• ¿Por qué Docker si hay Ansible y máquinas virtuales?

En el mismo trabajo, conocí otra herramienta: Ansible. Escuché sobre eso una vez, pero no intenté escribir mis propios libros de jugadas. ¡Y ahora comencé a escribir mis tareas y luego mi visión cambió por completo! Porque me di cuenta: Ansible tiene módulos para ejecutar los mismos contenedores acoplables, compilaciones de imágenes, redes, etc., y los contenedores se pueden ejecutar no solo localmente, ¡sino también en servidores remotos! Mi deleite no conoció límites: encontré una herramienta NORMAL y tiré mis archivos Makefile y Docker-compose, fueron reemplazados por tareas yaml. El código se redujo mediante el uso de construcciones como loop, when, etc.

Docker para ejecutar componentes de terceros, como bases de datos

Recientemente me familiaricé con los túneles ssh. Resultó que es muy fácil "reenviar" el puerto de un servidor remoto a un puerto local. El servidor remoto puede ser una máquina en la nube o una máquina virtual que se ejecuta en VirtualBox. Si mi colega o yo necesitamos una base de datos (o algún otro componente de terceros), simplemente podemos iniciar el servidor con este componente y apagarlo cuando el servidor no sea necesario. El reenvío de puertos produce el mismo efecto que una base de datos que se ejecuta en un contenedor acoplable.

Este comando reenvía mi puerto local a un servidor remoto que ejecuta postgresql:

ssh -L 9000: localhost: 5432 [email protected]

El uso de un servidor remoto resuelve el problema del desarrollo del equipo. Varios desarrolladores pueden utilizar un servidor de este tipo a la vez; no es necesario que puedan configurar PostgreSQL, comprender Docker y otras complejidades. En un servidor remoto, puede instalar la misma base de datos en Docker, si resulta difícil instalar una versión específica. ¡Todo lo que los desarrolladores necesitan es proporcionar acceso ssh!

¡Recientemente leí que los túneles SSH son una funcionalidad limitada de una VPN normal! Simplemente puede instalar OpenVPN u otras implementaciones de VPN, configurar la infraestructura y entregársela a los desarrolladores para que la utilicen. ¡Esto es genial!

Afortunadamente, AWS, GoogleCloud y otros te ofrecen un año de uso gratuito, ¡así que úsalos! Son baratos si los apagas cuando no están en uso. Siempre me pregunté por qué necesitaría un servidor remoto como gcloud, parece que los encontré.

Como máquina virtual local, puede utilizar el mismo Alpine, que se utiliza activamente en los contenedores Docker. Bueno, o algunas otras distribuciones ligeras para que la máquina arranque más rápido.

En pocas palabras: puede y debe ejecutar bases de datos y otras ventajas de infraestructura en servidores remotos o en virtualbox. No necesito Docker para estos propósitos.

Un poco sobre imágenes y distribución de Docker.

Ya escribi Artículo en el que quería transmitir que el uso de imágenes de Docker no ofrece ninguna garantía. Las imágenes de Docker solo son necesarias para crear un contenedor de Docker. Si está actualizando a una imagen de Docker, entonces está actualizando para usar contenedores de Docker y solo los usará.

¿Has visto algún lugar donde los desarrolladores de software portan sus productos solo en una imagen acoplable?
El resultado de la mayoría de los productos son archivos binarios para una plataforma específica; simplemente se agregan a la imagen de la ventana acoplable, que se hereda de la plataforma deseada. ¿Alguna vez te has preguntado por qué hay tantas imágenes similares en Dockerhub? Ingrese nginx por ejemplo, verá 100500 imágenes de diferentes personas. Estas personas no desarrollaron nginx en sí, simplemente agregaron nginx oficial a su imagen de Docker y lo aderezaron con sus propias configuraciones para la conveniencia de lanzar contenedores.

En general, puede simplemente almacenarlo en tgz, si alguien necesita ejecutarlo en la ventana acoplable, dejar que agregue tgz al Dockerfile, heredar del entorno deseado y crear bollos adicionales que no cambien la aplicación en sí en tgz. Cualquiera que cree una imagen de Docker sabrá qué es tgz y qué necesita para funcionar. Así es como uso Docker aquí

En pocas palabras: no necesito el registro de Docker, usaré algún tipo de S3 o simplemente almacenamiento de archivos como Google Drive/Dropbox.

Docker en CI

Todas las empresas para las que he trabajado son similares. Suelen ser comestibles. Es decir, tienen una aplicación, una pila de tecnología (bueno, tal vez un par o tres lenguajes de programación).

Estas empresas utilizan Docker en sus servidores donde se ejecuta el proceso de CI. Pregunta: ¿Por qué necesita crear proyectos en un contenedor acoplable en sus servidores? ¿Por qué no simplemente preparar un entorno para la compilación, por ejemplo, escribir un manual de Ansible que instalará las versiones necesarias de nodejs, php, jdk, copiará claves ssh, etc. en el servidor en el que se llevará a cabo la compilación?

Ahora entiendo que esto me está disparando en el pie, porque Docker no genera ningún beneficio con su aislamiento. Problemas que encontré con CI en Docker:

• Nuevamente necesitas una imagen de Docker para construir. debes buscar una imagen o escribir tu propio archivo acoplable.
• El 90% necesita reenviar algunas claves ssh, datos secretos que no desea escribir en la imagen de la ventana acoplable.
• el contenedor se crea y muere, todos los cachés se pierden junto con él. la próxima compilación volverá a descargar todas las dependencias del proyecto, lo que lleva mucho tiempo y es ineficaz, y el tiempo es dinero.

Los desarrolladores no crean proyectos en contenedores acoplables (una vez fui un gran fanático, de verdad, en el pasado lo siento por mí mismo xD). En java es posible tener varias versiones y cambiarlas con un comando a la que necesitas ahora. Es lo mismo en nodejs, existe nvm.

conclusión

Creo que Docker es una herramienta muy potente y flexible, ese es su inconveniente (suena raro, sí). Con su ayuda, las empresas pueden engancharse fácilmente a él y utilizarlo donde sea necesario y donde no sea necesario. Los desarrolladores lanzan sus contenedores, algunos de sus entornos, y luego todo fluye sin problemas hacia la CI y la producción. El equipo de DevOps está escribiendo algún tipo de código para ejecutar estos contenedores.

Use la ventana acoplable solo en el más reciente etapa de su flujo de trabajo, no la arrastre al proyecto al principio. No resolverá sus problemas comerciales. Él sólo moverá los problemas a OTRO nivel y ofrecerá sus propias soluciones, tú harás doble trabajo.

Cuando se necesita Docker: Llegué a la conclusión de que Docker es muy bueno para optimizar el proceso dado pero no para crear funciones básicas.

Si aún decides usar Docker, entonces:

• ten mucho cuidado
• no obligue a los desarrolladores a usar Docker
• localice su uso en un solo lugar, no lo distribuya en todos los repositorios de Dockefile y docker-compose

PS:

• Hace poco me encontré envasador y dicen que funciona muy bien con Ansible y permite unificar el proceso de creación de imágenes (incluida la imagen acoplable)
• también sobre Docker, artículo interesante.

¡Gracias por leer, te deseo decisiones transparentes en tus asuntos y jornadas laborales productivas!

Fuente: habr.com