La evolución de la cadena de suministro, o reflexiones sobre Docker, deb, jar y más



Un día, decidí escribir un artículo sobre la entrega de los paquetes Docker y Deb en forma de contenedores, pero cuando comencé, por alguna razón sufrí en los días lejanos de las primeras computadoras personales e incluso calculadoras. En general, en lugar de comparaciones secas de docker y deb, estos son los pensamientos sobre la evolución, que presento a su corte.

Cualquier producto, sea lo que sea, debe llegar de alguna manera a los servidores del producto, debe configurarse y lanzarse. Este artículo será sobre esto.

Reflexionaré en el contexto histórico, "lo que veo, lo que canto", lo que vi cuando comencé a escribir código y lo que estoy observando ahora, lo que nosotros mismos usamos en este momento y por qué. El artículo no pretende ser un estudio completo, faltan algunos puntos, esta es mi opinión personal de lo que fue y lo que es ahora.

Entonces, en los viejos tiempos ... el primer método de entrega que encontré fue con casetes de cinta. Tenía una computadora BK-0010.01 ...

La edad de las calculadoras


No, hubo un punto anterior, también hubo una calculadora MK-61 y MK-52 .

Entonces, cuando tenía MK-61 , la forma de transferir el programa era usar un trozo de papel normal en una caja en la que se grabó el programa, que, si era necesario, se escribió manualmente en la calculadora. Si quieres jugar (sí, incluso había juegos en esta calculadora antediluviana), siéntate e ingresa el programa en la calculadora. Naturalmente, cuando se apagó la calculadora, el programa quedó en el olvido. Además de los códigos de calculadora escritos personalmente en papel, los programas se publicaron en las revistas Radio and Technique of Youth, así como en libros de esa época.

La siguiente modificación fue la calculadora MK-52 , ya parecía un tipo de almacenamiento de datos no volátil. Ahora el juego o programa no tenía que ser manejado manualmente, pero, después de hacer algunos pases mágicos con botones, se cargó solo.

El volumen del programa m√°s grande en la calculadora fue de 105 pasos, y el tama√Īo de la memoria permanente en el MK-52 fue de 512 pasos.

Por cierto, si hay fanáticos de estas calculadoras que están leyendo este artículo, en el proceso de escribir el artículo, encontré un emulador de calculadora para Android y un programa para él. ¡Adelante al pasado!


Una peque√Īa digresi√≥n sobre MK-52 (de Wikipedia)

MK-52 voló al espacio en la nave espacial Soyuz TM-7. Se suponía que debía usarse para calcular la trayectoria de aterrizaje en caso de que la computadora a bordo falle.

El MK-52 con la unidad de expansión de memoria "Electronics-Astro" desde 1988 se suministró a los barcos de la Armada como parte de un kit de computación de navegación.


Las primeras computadoras personales



Volvamos a los tiempos de BK-0010 . Está claro que había más memoria allí, y ya no era una opción para manejar el código de una hoja de papel (aunque al principio lo hice, porque simplemente no había otro medio). Los principales medios de almacenamiento y entrega de software son casetes de audio para grabadoras.



El almacenamiento en un cassette generalmente tenía la forma de uno o dos archivos binarios, todo lo demás estaba contenido dentro. La fiabilidad era muy baja, tuve que guardar 2-3 copias del programa. El tiempo de carga tampoco fue feliz, los entusiastas experimentaron con diferentes codificaciones de frecuencia para superar estas deficiencias. En ese momento, yo todavía no había participado en el desarrollo de software profesional (aparte de los programas básicos simples), por lo tanto, desafortunadamente, no le diré en detalle cómo se organizó todo dentro. El hecho de tener solo RAM en la computadora en su mayor parte determinó la simplicidad del esquema de almacenamiento de datos.

La aparición de medios de almacenamiento confiables y grandes


M√°s tarde, aparecen los disquetes, el proceso de copia se simplifica y la confiabilidad est√° creciendo.
Pero la situación cambia dramáticamente solo cuando aparecen almacenamientos locales suficientemente grandes en forma de HDD.

El tipo de entrega cambia fundamentalmente: aparecen los instaladores que controlan 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 el cual debe poder borrar e innecesario si es necesario.

Al mismo tiempo, aumenta la complejidad del software suministrado.
El n√ļmero de archivos en la entrega aumenta de unidades a cientos y miles, los conflictos de versiones de biblioteca y otras alegr√≠as comienzan cuando diferentes programas usan los mismos datos.

En aquellos d√≠as, la existencia de Linux a√ļn no estaba abierta para m√≠, viv√≠a en el mundo de MS DOS y, m√°s tarde, en Windows, y escrib√≠a en Borland Pascal y Delphi, a veces mirando hacia C ++. Para suministrar productos en esos d√≠as, muchos utilizaron InstallShield ru.wikipedia.org/wiki/InstallShield , que resolvi√≥ con bastante √©xito todas las tareas de implementaci√≥n y configuraci√≥n de software.



Era de internet


Gradualmente, la complejidad de los sistemas de software se vuelve a√ļn m√°s complicada, desde un monolito y aplicaciones de escritorio hay una transici√≥n a sistemas distribuidos, clientes ligeros y microservicios. Ahora necesita configurar no solo un programa, sino su conjunto, y para que sean amigos todos juntos.

El concepto ha cambiado por completo, ha llegado Internet, ha llegado la era de los servicios en la nube. Hasta ahora, solo se interpreta en la etapa inicial, en forma de sitios, nadie so√Īaba especialmente con los servicios. pero este fue un punto de inflexi√≥n en la industria tanto del desarrollo como de la entrega real de aplicaciones.

Por mi parte, noté que en este momento hubo un cambio en las generaciones de desarrolladores (o solo en mi entorno), y tuve la sensación de que todos los buenos métodos de entrega antiguos se olvidaron en un momento y todo comenzó desde el principio: comenzaron a hacer la entrega completa con guiones hasta la rodilla y orgullosamente lo llamaron "Entrega continua". De hecho, comenzó un período de caos, cuando lo viejo se olvida y no se usa, pero simplemente no hay nada nuevo.

Recuerdo los momentos en que en nuestra empresa, donde trabajaba en ese momento (no llamaré), en lugar de construir a través de hormigas (Maven no era popular todavía o no lo era en absoluto), las personas simplemente recolectaban jar en IDE y se comprometían él en svn. En consecuencia, la implementación consistía en obtener el archivo de SVN y copiarlo a través de SSH en la máquina deseada. Tan simple y torpe.

Al mismo tiempo, la entrega de sitios simples a PHP se hizo bastante primitiva simplemente copiando el archivo corregido a través de FTP a la máquina de destino. A veces no existía tal cosa: 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 similares a UNIX comenzaron a ganar m√°s y m√°s popularidad, en particular, fue en ese momento que descubr√≠ RedHat Linux 6 por m√≠ mismo, alrededor del a√Īo 2000. Naturalmente, hab√≠a ciertas herramientas para la entrega de software all√≠, seg√ļn Wikipedia, RPM como el administrador principal de paquetes apareci√≥ ya en 1995, en la versi√≥n de RedHat Linux 2.0. Y desde entonces hasta ahora, el sistema se ha entregado en forma de paquetes RPM y existe y se desarrolla con bastante √©xito.

Las distribuciones de la familia Debian siguieron un camino similar e implementaron la entrega en forma de paquetes deb, que también se ha modificado hasta el día de hoy.

Los administradores de paquetes le permiten entregar los productos de software ellos mismos, configurarlos durante el proceso de instalaci√≥n, administrar dependencias entre diferentes paquetes, eliminar productos y limpiar el exceso durante la desinstalaci√≥n. Es decir en su mayor parte, esto es todo lo que se necesita, por lo que duraron varias d√©cadas con poco o ning√ļn cambio.

Se agregaron nubes a la instalación de los administradores de paquetes no solo desde medios físicos, sino también desde repositorios en la nube, sino que básicamente, poco ha cambiado.

Vale la pena se√Īalar que en la actualidad hay algunos escalofr√≠os para evitar deb y cambiar a paquetes instant√°neos, pero m√°s sobre eso m√°s adelante.

Entonces, esta nueva generación de desarrolladores en la nube, que no conocía DEB ni RPM, también creció lentamente, ganó experiencia, los productos se volvieron más complicados y se necesitaban métodos de entrega más razonables que FTP, scripts de bash y trabajos similares de estudiantes.
Y aqu√≠ Docker entra en escena, una especie de mezcla de virtualizaci√≥n, asignaci√≥n de recursos y m√©todos de entrega. Ahora est√° de moda, juventud, pero ¬Ņse necesita para todo? ¬ŅEs una panacea?

Seg√ļn mis observaciones, muy a menudo se ofrece Docker no como una opci√≥n razonable, sino simplemente porque, por un lado, se habla en la comunidad, y aquellos que lo ofrecen solo lo saben. Por otro lado, en su mayor parte guardan silencio sobre los viejos y buenos sistemas de embalaje: son y son, est√°n haciendo su trabajo de manera silenciosa e imperceptible. En tal situaci√≥n, no hay otra opci√≥n, la opci√≥n es obvia, Docker.

Trataré de compartir mi experiencia sobre cómo implementamos Docker y lo que sucedió como resultado.


Escrituras autoescritas


Inicialmente, había scripts de bash que implementaban archivos jar en las máquinas necesarias. Gestionó este proceso por Jenkins. Esto funcionó con éxito, ya que el archivo jar ya es un ensamblaje que contiene clases, recursos e incluso configuración. Si pone todo al máximo, luego amplíelo con un script, esto no es lo más difícil que necesita

Pero los guiones tienen varios inconvenientes:

  • los scripts generalmente se escriben con prisa y, por lo tanto, son tan primitivos que contienen solo uno de los scripts m√°s exitosos. Esto se ve facilitado por el hecho de que el desarrollador est√° interesado en una entrega r√°pida, y un script normal requiere una cantidad decente de recursos.
  • Como consecuencia del p√°rrafo anterior, los scripts no contienen el procedimiento de desinstalaci√≥n
  • sin procedimiento de actualizaci√≥n establecido
  • cuando aparece un nuevo producto, debe escribir un nuevo script
  • sin soporte de dependencia

Por supuesto, puedes escribir un script elegante, pero, como escrib√≠ anteriormente, este es el tiempo de desarrollo, y no el m√°s peque√Īo, pero, como sabes, siempre no hay suficiente tiempo.

Obviamente, todo esto limita el alcance de este método de implementación a los sistemas más simples. Ha llegado el momento de cambiar esto.


Docker


En alg√ļn momento, los medios reci√©n horneados comenzaron a llegar a nosotros, llenos de ideas y delirando con un estibador. Bueno, la bandera en la mano, ¬°hazlo! Hubo dos intentos. Ambos fracasaron, digamos que s√≠, debido a las grandes ambiciones, pero a la falta de experiencia real. ¬ŅEra necesario forzar y terminar de alguna manera? Es poco probable: el equipo debe crecer evolutivamente al nivel deseado antes de poder usar las herramientas adecuadas. Adem√°s de eso, al usar im√°genes listas para usar de la ventana acoplable, a menudo nos encontramos con el hecho de que la red funcionaba incorrectamente all√≠ (que, tal vez, tambi√©n estaba conectada con la humedad de la ventana acoplable) o que era dif√≠cil expandir los contenedores de otras personas.

¬ŅQu√© inconvenientes hemos encontrado?

  • Problemas de red en modo puente
  • Es inconveniente mirar los registros en el contenedor (si no se llevan por separado al sistema de archivos de la m√°quina host)
  • Peri√≥dicamente extra√Īo ElasticSearch se cuelga dentro del contenedor, la raz√≥n no se ha establecido, el contenedor es oficial
  • Es inc√≥modo usar la carcasa dentro del contenedor: todo est√° muy recortado, no hay herramientas familiares
  • Grandes contenedores para recolectar - costosos de almacenar
  • Debido al gran tama√Īo de los contenedores, es dif√≠cil admitir m√ļltiples versiones
  • Compilaci√≥n m√°s larga, a diferencia de otros m√©todos (scripts o paquetes deb)

Por otro lado, ¬Ņes peor implementar un servicio Spring en forma de archivo jar a trav√©s de la misma deb? ¬ŅEs realmente necesario el aislamiento de los recursos? ¬ŅVale la pena perder las herramientas convenientes del sistema operativo, llenando el servicio en un contenedor muy recortado?

Como la pr√°ctica ha demostrado, en realidad esto no es necesario, un paquete deb es suficiente en el 90% de los casos.

¬ŅCu√°ndo sigue fallando el viejo deb y cu√°ndo realmente necesitamos un acoplador?

Para nosotros, esta fue una implementaci√≥n de servicios en Python. Se necesitaban muchas bibliotecas para el aprendizaje autom√°tico y no estaban disponibles en la entrega est√°ndar del sistema operativo (y las versiones incorrectas), hacks con configuraciones, la necesidad de diferentes versiones para diferentes servicios que viven en el mismo sistema host condujo a que la √ļnica forma razonable de suministrar esta mezcla nuclear era acoplable. La complejidad de ensamblar el contenedor acoplable result√≥ ser menor que la idea de empaquetarlo todo en paquetes de Deb separados con dependencias, y nadie en su sano juicio lo habr√≠a tomado.

El segundo punto donde planea usar Docker es para implementar servicios utilizando el esquema de implementación azul-verde. Pero aquí quiero obtener un aumento gradual de la complejidad: primero, se recopilan los paquetes deb, y luego se ensambla un contenedor acoplable a partir de ellos.


Paquetes Snap


Volver a los paquetes de complemento. Primero aparecieron oficialmente en Ubuntu 16.04. A diferencia de los paquetes deb habituales y los paquetes rpm, snap transporta todas las dependencias. Por un lado, esto evita el conflicto de las bibliotecas, por otro lado, significa tama√Īos m√°s significativos del paquete resultante. Adem√°s, lo mismo puede afectar la seguridad del sistema: en el caso de la entrega r√°pida, todos los cambios en las bibliotecas incluidas deben ser monitoreados por el desarrollador que crea el paquete. En general, no todo es tan simple y la felicidad general de su uso no llega. Pero, sin embargo, esta es una alternativa bastante razonable, si el mismo Docker se usa solo como un medio de empaquetado, y no como virtualizaci√≥n.


Como resultado, ahora usamos los paquetes deb y los contenedores docker en una combinación razonable, que, quizás, en algunos casos, reemplazaremos con paquetes snap.

Source: https://habr.com/ru/post/444102/


All Articles