Una vez decidí escribir un artículo sobre la entrega en forma de contenedores Docker y paquetes deb, pero cuando comencé, por alguna razón me llevaron a los tiempos lejanos de las primeras computadoras personales e incluso de las calculadoras. En general, en lugar de comparaciones secas entre Docker y Deb, obtuvimos estas ideas sobre el tema de la evolución, que presento para su consideración.
Cualquier producto, sea cual sea, debe llegar de alguna manera a los servidores del producto, debe configurarse y ejecutarse. De eso se tratará este artículo.
Pensaré en un contexto histórico, “lo que veo es sobre lo que canto”, lo que vi cuando comencé a escribir código y lo que observo ahora, lo que nosotros mismos estamos usando en este momento y por qué. El artículo no pretende ser un estudio completo, se omiten algunos puntos, esta es mi visión personal de lo que fue y lo que es ahora.
Entonces, en los viejos tiempos... el primer método de entrega que encontré fueron cintas de casete de grabadoras. Tenía una computadora BK-0010.01...
La era de las calculadoras
No, hubo un momento incluso anterior, también había una calculadora. и .
Entonces cuando tuve , entonces la forma de transferir el programa era una hoja de papel normal en una caja en la que estaba escrito el programa, que, si era necesario, ejecutarlo manualmente, se escribía en la calculadora. Si quieres jugar (sí, incluso esta calculadora antediluviana tenía juegos), te sientas e ingresas el programa en la calculadora. Naturalmente, cuando se apagó la calculadora, el programa desapareció en el olvido. Además de los códigos de calculadora escritos personalmente en papel, los programas se publicaron en las revistas "Radio" y "Tecnología para la juventud", y también en libros de la época.
La siguiente modificación fue una calculadora. , ya tiene cierta apariencia de almacenamiento de datos no volátil. Ahora no había que ingresar manualmente al juego o programa, sino que luego de realizar algunos pases mágicos con los botones, se cargaba solo.
El tamaño del programa más grande en la calculadora era de 105 pasos y el tamaño de la memoria permanente en el MK-52 era de 512 pasos.
Por cierto, si hay fanáticos de estas calculadoras que están leyendo este artículo, mientras escribía el artículo encontré tanto un emulador de calculadora para Android como programas para ello. ¡Adelante al pasado!
Una breve digresión sobre MK-52 (de Wikipedia)
MK-52 voló al espacio en la nave espacial Soyuz TM-7. Se suponía que se utilizaría para calcular la trayectoria de aterrizaje en caso de que fallara la computadora de a bordo.
Desde 52, el MK-1988 con la unidad de expansión de memoria Elektronika-Astro se suministra a los barcos de la Armada como parte de un kit informático de navegación.
Las primeras computadoras personales.
volvamos a los tiempos . Está claro que allí había más memoria y escribir el código desde una hoja de papel ya no era una opción (aunque al principio hice precisamente eso, porque simplemente no había otro medio). Los casetes de audio para grabadoras se están convirtiendo en el principal medio de almacenamiento y entrega de software.
El almacenamiento en un casete solía ser en forma de uno o dos archivos binarios, todo lo demás estaba contenido en su interior. La confiabilidad era muy baja, tuve que conservar 2 o 3 copias del programa. Los tiempos de carga también fueron decepcionantes y los entusiastas experimentaron con diferentes codificaciones de frecuencia para superar estas deficiencias. En ese momento, yo todavía no estaba involucrado en el desarrollo de software profesional (sin contar los programas simples en BASIC), por lo que, desafortunadamente, no les contaré en detalle cómo estaba todo dentro. El hecho mismo de que la computadora tuviera solo RAM en su mayor parte determinó la simplicidad del esquema de almacenamiento de datos.
La aparición de medios de almacenamiento grandes y fiables.
Más tarde, aparecieron los disquetes, se simplificó el proceso de copia y aumentó la confiabilidad.
Pero la situación cambia radicalmente sólo cuando aparecen almacenamientos locales suficientemente grandes en forma de discos duros.
El tipo de entrega está cambiando fundamentalmente: aparecen programas de instalación que gestionan el proceso de configuración del sistema, así como la limpieza después de la eliminación, ya que los programas no solo se leen en la memoria, sino que ya se copian en el almacenamiento local, desde donde es necesario Ser capaz de limpiar cosas innecesarias si es necesario.
Al mismo tiempo, aumenta la complejidad del software suministrado.
La cantidad de archivos en la entrega aumenta de unos pocos a cientos y miles, los conflictos entre las versiones de la biblioteca y otras alegrías comienzan cuando diferentes programas usan los mismos datos.
En aquel momento, la existencia de Linux aún no estaba abierta para mí; vivía en el mundo de MS DOS y, más tarde, de Windows, y escribía en Borland Pascal y Delphi, a veces mirando hacia C++. Mucha gente usaba InstallShield para entregar productos en aquel entonces. , que resolvió con bastante éxito todas las tareas asignadas de implementación y configuración del software.
era de internet
Poco a poco, la complejidad de los sistemas de software se vuelve aún más compleja: de las aplicaciones monolíticas y de escritorio se pasa a sistemas distribuidos, clientes ligeros y microservicios. Ahora necesita configurar no solo un programa, sino un conjunto de ellos, para que todos funcionen juntos.
El concepto cambió por completo, llegó Internet, llegó la era de los servicios en la nube. Hasta ahora, sólo en la fase inicial, en forma de sitios web, nadie ha soñado especialmente con servicios. pero fue un punto de inflexión tanto en el desarrollo como en la entrega de aplicaciones.
Por mi parte, noté que en ese momento hubo un cambio en las generaciones de desarrolladores (o fue solo en mi entorno), y tuve la sensación de que todos los viejos métodos de entrega se olvidaron en un momento y todo comenzó desde el mismo comienzo: toda la entrega comenzó a hacerse scripts de rodilla y con orgullo lo llamó “entrega continua”. De hecho, ha comenzado un período de caos, en el que lo viejo se olvida y no se utiliza, y lo nuevo simplemente no existe.
Recuerdo los momentos en que en nuestra empresa donde trabajaba entonces (no la nombraré), en lugar de construir a través de ant (maven aún no era popular o no existía en absoluto), la gente simplemente recolectaba frascos en el IDE y se dedicaba serenamente en SVN. En consecuencia, la implementación consistió en recuperar el archivo de SVN y copiarlo vía SSH a la máquina deseada. Es tan simple y torpe.
Al mismo tiempo, la entrega de sitios simples en PHP se realizó de una manera muy primitiva, simplemente copiando el archivo corregido vía FTP a la máquina de destino. A veces este no era el caso: el código se editaba en vivo en el servidor del producto y era especialmente elegante si había copias de seguridad en alguna parte.
Paquetes RPM y DEB
Por otro lado, con el desarrollo de Internet, los sistemas tipo UNIX comenzaron a ganar cada vez más popularidad, en particular, fue en ese momento que descubrí RedHat Linux 6, aproximadamente en el año 2000. Naturalmente, también existían ciertos medios para distribuir software; según Wikipedia, RPM como administrador de paquetes principal apareció ya en 1995, en la versión RedHat Linux 2.0. Y desde entonces y hasta el día de hoy, el sistema se ha entregado en forma de paquetes RPM y ha existido y desarrollado con bastante éxito.
Las distribuciones de la familia Debian siguieron un camino similar e implementaron la entrega en forma de paquetes deb, que no ha cambiado hasta el día de hoy.
Los administradores de paquetes le permiten entregar los productos de software, configurarlos durante el proceso de instalación, administrar dependencias entre diferentes paquetes, eliminar productos y limpiar elementos innecesarios durante el proceso de desinstalación. Aquellos. en su mayor parte, eso es todo lo que se necesita, razón por la cual duraron varias décadas prácticamente sin cambios.
La computación en la nube ha agregado la instalación a los administradores de paquetes no solo desde medios físicos, sino también desde repositorios en la nube, pero fundamentalmente poco ha cambiado.
Vale la pena señalar que actualmente hay algunos movimientos para alejarse de Deb y cambiar a paquetes Snap, pero hablaremos de eso más adelante.
Entonces, esta nueva generación de desarrolladores de la nube, que no conocían ni DEB ni RPM, también creció lentamente, ganó experiencia, los productos se volvieron más complejos y se necesitaban algunos métodos de entrega más razonables que FTP, scripts bash y manualidades estudiantiles similares.
Y aquí es donde Docker entra en escena, una especie de mezcla de virtualización, delimitación de recursos y método de entrega. Está de moda y es juvenil ahora, pero ¿es necesario para todo? ¿Es esto una panacea?
Según mis observaciones, muy a menudo se propone Docker no como una opción razonable, sino simplemente porque, por un lado, se habla de él en la comunidad y quienes lo proponen solo lo saben. Por otro lado, la mayoría guarda silencio sobre los viejos y buenos sistemas de embalaje: existen y hacen su trabajo de forma silenciosa y desapercibida. En tal situación, realmente no hay otra opción; la elección es obvia: Docker.
Intentaré compartir mi experiencia sobre cómo implementamos Docker y qué sucedió como resultado.
Guiones escritos por uno mismo
Inicialmente, había scripts bash que implementaban archivos jar en las máquinas requeridas. Este proceso fue gestionado por Jenkins. Esto funcionó con éxito, ya que el archivo jar en sí ya es un ensamblaje que contiene clases, recursos e incluso configuración. Si pones todo al máximo, expandirlo a un script no es lo más difícil que necesitas.
Pero los guiones tienen varias desventajas:
- Los guiones generalmente se escriben apresuradamente y, por lo tanto, son tan primitivos que contienen solo un escenario en el mejor de los casos. Esto se ve facilitado por el hecho de que el desarrollador está interesado en una entrega rápida y un script normal requiere la inversión de una cantidad decente de recursos.
- Como consecuencia del punto anterior, los scripts no contienen procedimientos de desinstalación.
- ningún procedimiento de actualización establecido
- Cuando aparece un nuevo producto, es necesario escribir un nuevo guión.
- sin soporte de dependencia
Por supuesto, puedes escribir un guión sofisticado, pero, como escribí anteriormente, este es el tiempo de desarrollo, y no menos importante, y, como sabemos, siempre no hay tiempo suficiente.
Todo esto obviamente limita el ámbito de aplicación de este método de implementación sólo a los sistemas más simples. Ha llegado el momento de cambiar esto.
Docker
En algún momento, comenzaron a llegar a nosotros medios recién creados, hirviendo de ideas y entusiasmados con el acoplador. Bueno, bandera en mano, ¡hagámoslo! Hubo dos intentos. Ambos fracasaron, digamos, debido a grandes ambiciones, pero falta de experiencia real. ¿Era necesario forzarlo y acabarlo por cualquier medio posible? Es poco probable: el equipo debe evolucionar hasta el nivel requerido antes de poder utilizar las herramientas adecuadas. Además, al utilizar imágenes de Docker ya preparadas, a menudo nos topábamos con el hecho de que la red no funcionaba correctamente (lo que puede deberse a la humedad del propio Docker) o era difícil ampliar los contenedores de otras personas.
¿Qué inconvenientes encontramos?
- Problemas de red en modo puente
- Es inconveniente ver los registros en un contenedor (si no se almacenan por separado en el sistema de archivos de la máquina host)
- ElasticSearch ocasionalmente se congela de manera extraña dentro del contenedor, el motivo no se ha determinado, el contenedor es oficial
- Es necesario utilizar un caparazón dentro del contenedor: todo está muy simplificado, no hay herramientas familiares.
- Gran tamaño de los contenedores recogidos: caro de almacenar
- Debido al gran tamaño de los contenedores, es difícil admitir múltiples versiones.
- Mayor tiempo de compilación, a diferencia de otros métodos (scripts o paquetes deb)
Por otro lado, ¿por qué es peor implementar un servicio Spring en forma de archivo jar a través del mismo deb? ¿Es realmente necesario el aislamiento de recursos? ¿Vale la pena perder herramientas convenientes del sistema operativo al meter un servicio en un contenedor muy reducido?
Como ha demostrado la práctica, en realidad esto no es necesario, el paquete DEB es suficiente en el 90% de los casos.
¿Cuándo falla el viejo Deb y cuándo realmente necesitamos Docker?
Para nosotros, esto fue implementar servicios en Python. Muchas bibliotecas necesarias para el aprendizaje automático y no incluidas en la distribución estándar del sistema operativo (y lo que había eran versiones incorrectas), hacks con configuraciones, la necesidad de diferentes versiones para diferentes servicios que vivían en el mismo sistema host llevaron a esto, que la única forma razonable de entregar esta mezcla nuclear era el portuario. La intensidad de mano de obra de ensamblar un contenedor acoplable resultó ser menor que la idea de empaquetarlo todo en paquetes deb separados con dependencias y, de hecho, nadie en su sano juicio se atrevería a hacerlo.
El segundo punto en el que planeamos utilizar Docker es implementar servicios utilizando el esquema de implementación azul-verde. Pero aquí quiero obtener un aumento gradual en la complejidad: primero, se crean los paquetes deb y luego se construye un contenedor acoplable a partir de ellos.
Paquetes instantáneos
Volvamos a los paquetes instantáneos. Aparecieron oficialmente por primera vez en Ubuntu 16.04. A diferencia de los paquetes deb y rpm habituales, snap incluye todas las dependencias. Por un lado, esto le permite evitar conflictos con la biblioteca; por otro lado, el paquete resultante es de mayor tamaño. Además, esto también puede afectar la seguridad del sistema: en el caso de la entrega rápida, todos los cambios en las bibliotecas incluidas deben ser supervisados por el desarrollador que crea el paquete. En general, no todo es tan sencillo y la felicidad universal no proviene de su uso. Pero, sin embargo, esta es una alternativa completamente razonable si el mismo Docker se usa solo como herramienta de empaquetado y no para virtualización.
Como resultado, ahora utilizamos paquetes deb y contenedores docker en una combinación razonable, que, quizás, en algunos casos reemplazaremos con paquetes snap.
Solo los usuarios registrados pueden participar en la encuesta. por favor
¿Qué usas para la entrega?
-
Guiones escritos por uno mismo
-
Copiar manualmente a FTP
-
paquetes deb
-
paquetes rpm
-
paquetes instantáneos
-
imágenes-docker
-
Imágenes de máquinas virtuales
-
Clonar todo el disco duro
-
marioneta
-
ansible
-
Otro
109 usuarios votaron. 32 usuarios se abstuvieron.
Fuente: habr.com