Trabajé en diferentes empresas que usan microservicios. Y los pusieron en contenedores acoplables. Ahora estoy trabajando con un proyecto que, aunque es un monolito, aún es más conveniente ejecutarlo en un contenedor.
Por un lado, Docker es una herramienta muy versátil, se puede usar de manera fácil y efectiva para resolver una gran cantidad de tareas. Es comprensible y parece que todo es elemental. Pero, por otro lado, si no gasta su tiempo y recursos para "bombear" en su uso adecuado, es probable que complique demasiado las cosas simples. Y, por supuesto, supondrá que tiene razón, y Docker es una basura voluminosa mediocre que no es adecuada para resolver su tarea única.
Por lo general, en una empresa estándar, el proceso de trabajar en cualquier tarea se ve así:
- Git push se hace con nuestro compromiso
- Se activa un sistema, ya sea Jenkins, TeamCity, etc.
- Se inicia la canalización / trabajo, en el que se descargan bibliotecas de terceros, se compila el proyecto, se ejecutan pruebas
- Se crea una imagen acoplable con el proyecto ensamblado (ADD ..) y se inserta en el registro de acoplador remoto
- De alguna manera, en el servidor remoto, se realiza la extracción de la ventana acoplable (chef, títere, manualmente a través de Docker-compose) y se inicia el contenedor.
Intuitivamente, siempre sentí que todo era de alguna manera demasiado complicado. Este proceso se llama orgullosamente CI / CD, y estoy cansado de personas tan inteligentes que no tienen dudas de que esta es la forma más fácil.
Para el usuario final, se ve así: al presionar al repositorio git, lo que estaba en el commit se desarrolla en algún lugar.
Lo que NO me gusta de este enfoque.
- La única forma de implementar el sistema en un servidor remoto es realizar los 5 pasos.
- En el paso 3, es posible que necesite claves de acceso a bibliotecas privadas. El proceso puede ser largo si el almacenamiento en caché de las bibliotecas descargadas previamente no está configurado.
- Debe preparar el Dockerfile, decidir sobre la imagen (DE ...), decidir cómo etiquetaremos la imagen y necesitará acceso al repositorio en el que empujaremos la imagen.
- Necesita su propio repositorio, configure https. Después de todo, el cliente de Docker solo funciona en https.
El cuarto párrafo, por supuesto, se hace una vez y quizás no debería agregarse.
Pero, ¿cuántas veces se menciona la palabra Docker en la etapa de lanzamiento?
Piénselo: ¿por qué estamos arrastrando todo este Docker antes de tiempo? Porque se cree que el contenedor es conveniente y “Bueno, todo estuvo bien, funciona. ¿Qué estás comenzando entonces?
Por lo tanto, para esas personas, puedo decir que los contenedores Docker no son una panacea y no el único entorno en el que se puede ejecutar su aplicación. Proyecto escrito en python, php, js, swift, scala / java, etc. se puede ejecutar en:
- máquina virtual remota
- en un host local sin virtualización ni contenedores de acopladores.
De repente :)
Imaginemos que estamos haciendo un servicio que se ejecutará en nodeJS.
El resultado de este proyecto (o como lo llamo el 'artefacto') será un conjunto de archivos js (el servicio en sí mismo) + node_modules (bibliotecas de terceros que se utilizan en el servicio).
Supongamos que nos aseguramos de que el servicio funciona y queremos ejecutarlo de forma remota para que nuestros evaluadores puedan probar su funcionalidad.
¿Qué le parece esta idea?
- Hacemos .tar.gz con nuestro proyecto y lo subimos a ... ¡repositorio remoto de artefactos! (Además, dichos repositorios se denominan "repositorio binario").
- Decimos la url por la que pueden descargar nuestro servicio y comenzar a probar.
Además, los probadores pueden iniciar el servicio localmente en casa, si lo tienen todo, o hacer un Dockerfile, en el que habrá una descarga de artefactos y simplemente iniciar el contenedor. Bueno o algo más.
Diré de inmediato si no desea que los evaluadores inicien los contenedores acoplables y, en general, "no es su trabajo" iniciarlos, luego use una herramienta que recopile imágenes tan pronto como aparezcan nuevos artefactos en el repositorio binario (use el gancho web, persiga periódicamente sobre la corona).
Ahora desde repositorios binarios hay:
Nexus es fácil de usar, tiene un montón de repositorios diferentes que puedes crear (npm, maven, raw, docker), así que lo uso.
Esta es una idea muy simple, ¿por qué no lo he leído en ningún lado? En Internet, no puede contar artículos "como en git push en algún lugar donde se implementa un contenedor en algún tipo de kubernetes". A partir de algoritmos tan complejos, el cabello se pone de punta.
El propósito de este artículo, es decir, no es necesario en un proceso ensamblar el proyecto y agregarlo a la imagen del acoplador.
¡Divide y gobierna!
Construya el proyecto, publique artefactos en un lugar descargable. (El registro Docker no es el único lugar donde puede almacenar su proyecto, elija rutas universales para entregar artefactos a los servidores).
Con una herramienta separada, entregue artefactos al servidor donde funcionará su proyecto.
Todo es muy simple, déle a los demás una opción: use docker, ejecute en kubernetes o use cualquier otra herramienta para ejecutar artefactos. No es necesario imponer el uso de la tecnología a pesar del hecho de que te parece muy conveniente y de moda.
¡Buena suerte en el lanzamiento de tus proyectos!