En algún momento, decidí escribir un artículo sobre la entrega en forma de contenedores Docker y paquetes deb, pero cuando comencé, de alguna manera me transporté a los lejanos días de las primeras computadoras personales e incluso calculadoras. En resumen, en lugar de una comparación seca entre Docker y deb, terminé con estas reflexiones sobre la evolución, que presento a su consideración.
Cualquier producto, sea cual sea, debe llegar de alguna manera a los servidores de producción, debe estar configurado y en funcionamiento. De esto tratará este artículo.
Reflexionaré en un contexto histórico, «lo que veo, de eso hablo», lo que vi cuando empecé a escribir código y lo que observo ahora, lo que usamos actualmente y por qué. El artículo no pretende ser una investigación completa, algunos aspectos están omitidos, es mi opinión personal sobre lo que fue y lo que es ahora.
Así que, en los viejos buenos tiempos... el método más temprano de entrega que conocí eran las cintas de casete. Tenía una computadora BK-0010.01...
La era de las calculadoras
No, hubo un momento aún más temprano, había otra calculadora y .
Así que, cuando tenía , el método para transferir el programa era una simple hoja de papel cuadriculado, donde estaba escrito el programa que, si era necesario, se introducía manualmente en la calculadora. Si querías jugar (sí, incluso en esa antigua calculadora había juegos) te sentabas y escribías el programa en la calculadora. Naturalmente, al apagar la calculadora, el programa se desvanecía en la nada. Además de los códigos escritos a mano en papel, los programas se publicaban en revistas como «Radio» y «Técnica de la Juventud», y también se imprimían en libros de la época.
La siguiente modificación fue la calculadora , que ya tenía alguna forma de almacenamiento no volátil de datos. Ahora ya no era necesario introducir manualmente el juego o programa, sino que, realizando algunos movimientos mágicos con los botones, se cargaba automáticamente.
El tamaño del programa más grande en la calculadora era de 105 pasos, mientras que la memoria permanente de la МК-52 era de 512 pasos.
Por cierto, si hay fanáticos de estas calculadoras que estén leyendo este artículo, durante la redacción del mismo encontré un emulador de calculadora para Android y programas para el mismo. ¡Hacia el pasado!
Una breve digresión sobre el MK-52 (de Wikipedia)
El MK-52 voló al espacio en la nave 'Soyuz TM-7'. Se suponía que se utilizaría para calcular la trayectoria de aterrizaje en caso de que fallara la computadora a bordo.
Desde 1988, el MK-52 con el módulo de expansión de memoria 'Electrónica-Astro' se suministraba a los barcos de la Armada como parte del conjunto de computación del navegador.
Las primeras computadoras personales
Regresamos a los tiempos . Está claro que también había más memoria, y ya no era factible ingresar el código desde un papel (aunque al principio lo hice de esa manera, porque no había otro medio disponible). El principal medio de almacenamiento y suministro de software eran los cassettes de audio para grabadoras.
El almacenamiento en cinta generalmente consistía en uno o dos archivos binarios, todo lo demás estaba contenido en su interior. La fiabilidad era muy baja, había que mantener de 2 a 3 copias del programa. El tiempo de carga tampoco era satisfactorio, los entusiastas experimentaban con diferentes codificaciones de frecuencia para superar estas deficiencias. En ese tiempo yo aún no me dedicaba al desarrollo profesional de software (sin contar algunos programas sencillos en BASIC), por lo que no puedo contarles los detalles de cómo estaba todo organizado internamente. El simple hecho de que en la computadora solo hubiera RAM definía en gran medida la simplicidad del esquema de almacenamiento de datos.
La aparición de soportes de información fiables y grandes
Más tarde surgen los disquetes, lo que simplifica el proceso de copia y aumenta la fiabilidad.
Pero la situación cambia radicalmente solo cuando aparecen grandes almacenamiento locales en forma de HDD.
Cambia fundamentalmente el tipo de suministro: aparecen programas instaladores que gestionan el proceso de configuración del sistema, así como la limpieza después de la desinstalación, ya que los programas no solo se leen en la memoria, sino que ya se copian en el almacenamiento local, del cual hay que saber y limpiar lo innecesario cuando sea necesario.
Paralelamente, aumenta la complejidad del software suministrado.
El número de archivos en el suministro aumenta de unos pocos a cientos y miles, y comienzan los conflictos de versiones de bibliotecas y otras alegrías cuando diferentes programas utilizan los mismos datos.
En esos tiempos, aún no conocía la existencia de Linux, vivía en el mundo de MS DOS y, más tarde, Windows, programando en Borland Pascal y Delphi, a veces echando un vistazo a C++. Para la entrega de productos en esos días, muchos usaban InstallShield , que resolvía con éxito todas las tareas planteadas de despliegue y configuración de software.
La era de Internet
Gradualmente, la complejidad de los sistemas de software ha aumentado, pasando de monolitos y aplicaciones de escritorio a sistemas distribuidos, clientes ligeros y microservicios. Ahora ya no se trata de configurar una sola aplicación, sino un conjunto de ellas, y hacerlo de tal manera que todas trabajen en conjunto.
La concepción cambió por completo, llegó Internet, comenzó la era de los servicios en la nube. Aunque todavía estaba en una fase inicial, como sitios web, nadie soñaba realmente con los servicios, pero este fue un momento crucial en la industria tanto del desarrollo como de la entrega de aplicaciones.
Para mí, este momento significó un cambio generacional en los desarrolladores (o quizás solo en mi entorno), y había una sensación de que todos los viejos y buenos métodos de entrega fueron olvidados de un día para otro y todo comenzó de nuevo: toda la entrega se empezó a hacer con scripts de rodillas y se llamó orgullosamente 'Continuous delivery'. En realidad, comenzó un período de descontrol, cuando lo antiguo fue olvidado y no se usó, y no había nada nuevo.
Recuerdo los tiempos en que en la empresa donde trabajaba (no mencionaré el nombre), en lugar de hacer la construcción a través de ant (maven aún no era popular o no existía), la gente simplemente compilaba el jar en el IDE y lo commitía tranquilamente en SVN. Por lo tanto, el despliegue consistía en sacar el archivo de SVN y copiarlo por SSH a la máquina adecuada. Así de simple y rudimentario.
Al mismo tiempo, la entrega de sitios simples en PHP se hacía de manera aún más primitiva, simplemente copiando el archivo corregido a través de FTP en la máquina objetivo. A veces, ni siquiera había tal cosa: se corregía el código en vivo en el servidor de producción, y era un lujo si había copias de seguridad en algún lugar.
Paquetes RPM y DEB
Por otro lado, con el desarrollo de Internet, los sistemas similares a UNIX han ganado cada vez más popularidad, especialmente en aquella época descubrí RedHat Linux 6, alrededor del año 2000. Naturalmente, también existían herramientas para la entrega de software; según la Wikipedia, RPM como gestor de paquetes principal apareció en 1995, en la versión RedHat Linux 2.0. Y desde entonces hasta nuestros días, el sistema se entrega en forma de paquetes RPM y ha existido y evolucionado con bastante éxito.
Las distribuciones de la familia Debian siguieron un camino similar y implementaron la entrega en forma de paquetes deb, lo cual también se mantiene hasta nuestros días.
Los gestores de paquetes permiten distribuir los propios productos de software, configurarlos durante la instalación, gestionar las dependencias entre diferentes paquetes, llevar a cabo la eliminación de productos y limpiar el exceso durante la desinstalación. Es decir, en su mayor parte, esto es todo lo que se necesita; por eso han perdurado durante varias décadas prácticamente sin cambios.
La nube añadió a los gestores de paquetes la instalación no solo desde medios físicos, sino también desde repositorios en la nube, pero el principio fundamental no ha cambiado mucho.
Cabe señalar que actualmente hay algunas tendencias hacia el abandono de deb y la transición a paquetes snap, pero hablaremos de eso más adelante.
Así que, esta nueva generación de desarrolladores en la nube, que no conocía ni DEB ni RPM, también ha crecido lentamente, adquiriendo experiencia, los productos se complicaban y se necesitaban métodos de distribución más razonables que FTP, pequeños scripts bash y similares, que eran un tanto improvisados.
Y aquí entra en escena Docker, una especie de mezcla de virtualización, separación de recursos y método de distribución. Ahora es moda, juvenil, pero ¿es necesario para todo? ¿Es una panacea?
Por mis observaciones, Docker a menudo se ofrece no como una elección razonable, sino simplemente porque, por un lado, se habla de ello en la comunidad, y aquellos que lo proponen solo lo conocen. Por otro lado, se habla poco de los antiguos y buenos sistemas de empaquetamiento; existen y hacen su trabajo de manera silenciosa y desapercibida. En tal situación, no queda mucho más que elegir; la elección es obvia: Docker.
Intentaré compartir la experiencia de cómo implementamos Docker y qué resultados obtuvimos.
Scripts personalizados
Originalmente, había scripts bash que desplegaban archivos jar en las máquinas correspondientes. Este proceso era gestionado por Jenkins. Esto funcionaba con éxito, dado que el archivo jar en sí mismo es una compilación que contiene clases, recursos e incluso configuraciones. Si se agrega todo al máximo, descomponerlo con un script no es lo más complicado que se necesita.
Sin embargo, los scripts tienen varias desventajas:
- Los scripts suelen escribirse a la ligera y son tan primitivos que solo contienen un escenario más afortunado. Esto se debe a que el desarrollador está interesado en una entrega rápida, mientras que un script adecuado requiere una cantidad considerable de recursos.
- Como consecuencia del punto anterior, los scripts no contienen procedimientos de desinstalación.
- No hay un procedimiento establecido de actualización.
- Al aparecer un nuevo producto, hay que escribir un nuevo script.
- No hay soporte para dependencias.
Por supuesto, se podría escribir un script sofisticado, pero, como mencioné antes, eso lleva tiempo de desarrollo, y, como se sabe, siempre falta tiempo.
Todo esto limita claramente el uso de este método de despliegue solo a sistemas muy simples. Ha llegado el momento de cambiar esto.
Docker
En algún momento, empezaron a llegar a nosotros recién graduados entusiastas con muchas ideas y soñando con Docker. ¡Muy bien, adelante! Tuvimos dos intentos. Ambos fallidos, digamos, debido a grandes ambiciones pero con poca experiencia real. ¿Era necesario apresurar y hacer todo a cualquier costo? Probablemente no; el equipo debe evolucionar hasta el nivel adecuado antes de poder utilizar las herramientas correspondientes. Además, al utilizar imágenes de Docker ya preparadas, a menudo nos encontramos con que la red no funcionaba correctamente (lo cual quizás estaba relacionado con la inmadurez de Docker mismo) o era complicado extender los contenedores ajenos.
¿Con qué inconvenientes nos encontramos?
- Problemas de red en modo bridge.
- Es incómodo ver los logs en el contenedor (si no están separados en el sistema de archivos de la máquina anfitriona).
- Ocasionalmente, un extraño bloqueo de ElasticSearch dentro del contenedor; no se ha podido establecer la causa, el contenedor es oficial.
- Es incómodo usar el shell dentro del contenedor; todo está muy limitado, no hay las herramientas habituales.
- El gran tamaño de los contenedores recolectados resulta costoso de almacenar
- Debido al gran tamaño de los contenedores, es difícil mantener múltiples versiones
- La construcción es más prolongada, a diferencia de otros métodos (scripts o paquetes deb)
Por otro lado, ¿qué hace que el servicio Spring en forma de archivo jar sea peor de implementar a través del mismo deb? ¿Es realmente necesaria la aislamiento de recursos? ¿Vale la pena renunciar a herramientas cómodas del sistema operativo al meter el servicio en un contenedor severamente recortado?
Como ha demostrado la práctica, en realidad esto no es necesario, un paquete deb es suficiente en el 90% de los casos.
¿Cuándo realmente el viejo y confiable deb no funciona y cuándo realmente necesitamos Docker?
Para nosotros, esto fue el despliegue de servicios en Python. Muchas bibliotecas necesarias para el aprendizaje automático y que faltan en la instalación estándar del sistema operativo (y las que estaban no eran de las versiones correctas), ajustes improvisados, necesidad de diferentes versiones para diferentes servicios que viven en la misma máquina host llevaron a que el único enfoque razonable para entregar esta mezcla compleja resultara ser Docker. El esfuerzo para crear un contenedor Docker resultó ser menor que la idea de empaquetar todo esto en paquetes deb separados con dependencias, de hecho, nadie en su sano juicio se habría atrevido a hacerlo.
El segundo momento donde se planea usar Docker es para el despliegue de servicios en la estrategia blue-green deploy. Pero aquí quiero obtener un aumento gradual de la complejidad: primero se construyen paquetes deb y luego a partir de ellos se crea el contenedor Docker.
Paquetes Snap
Volvamos a los paquetes Snap. Aparecieron oficialmente por primera vez en Ubuntu 16.04. A diferencia de los habituales paquetes deb y rpm, los snaps llevan consigo todas las dependencias. Por un lado, esto evita problemas de conflicto entre bibliotecas, pero por otro lado, resulta en un tamaño mucho mayor del paquete resultante. Además, esto puede influir en la seguridad del sistema: en el caso del envío de un snap, todas las modificaciones de las bibliotecas incluidas deben ser monitoreadas por el mismo desarrollador que crea el paquete. En general, no todo es tan claro y la felicidad general por su uso no se materializa. Sin embargo, sigue siendo una alternativa razonable, si Docker se utiliza solo como medio de empaquetado y no de virtualización.
En resumen, ahora utilizamos una combinación razonable de paquetes deb y contenedores de Docker, que quizás, en algunos casos, reemplazaremos por paquetes snap.
Solo los usuarios registrados pueden participar en la encuesta. , por favor.
¿Qué utilizas tú para la entrega?
Scripts personalizados
Copiamos manualmente por FTP
paquetes deb
paquetes rpm
paquetes snap
imágenes de Docker
Imágenes de máquinas virtuales
Clonamos el HDD por completo
puppet
ansible
Otro
Votaron 109 usuarios. 32 usuarios se abstuvieron.
Fuente: habr.com
