¿Hay alguna desventaja de usar un paquete deb como si fuera un contenedor para implementar una aplicación?

Actualmente, mi equipo está intentando decidir si debemos implementar nuestra aplicación Nodejs como un paquete deb en lugar de intentar ejecutarla en un contenedor como Docker.

Tengo esta idea al leer este blog aquí, que presenta algunos buenos argumentos para usar un paquete deb para una aplicación python preexistente. El punto principal de este blog que nos atrae es el tema del mantenimiento del ecosistema Docker (uso compartido de puertos, permisos, alojamiento de imágenes de Docker, etc.)

Parece que los "paquetes de dep como los contenedores originales" tienen mucho sentido para los servicios pequeños donde no hay preocupación de conflictos de puertos y donde todas las dependencias se mantienen dentro de un entorno virtual.

Sin embargo, mi instinto me dice que si los paquetes deb encajan bien, sería más común y Docker se anunciaría como una solución más específica del idioma. ¿Hay alguna desventaja de usar algo como los paquetes deb para implementar nuestros servicios, en lugar de usar un sistema completo como Docker?

Primero, aunque Docker se ve y se usa a veces como un sistema de empaquetado ad hoc , en realidad resuelve un problema totalmente diferente: Docker se trata de ejecutar programas. El sistema Docker permite describir servicios, que se pueden escalar a voluntad y controlar enjambres de contenedores. Los paquetes Debian son para instalar programas y pueden manejar dependencias entre versiones de software. Estibador ciertamente no califica como un sistema de empaque descendente: cada "paquete" solo puede tener una dependencia, el sistema no tiene una opción de "construcción recursiva" y no admite restricciones de versión complejas.

Una posible respuesta sería que, si está dispuesto a escribir un paquete Debian para su aplicación, también puede usar Docker para implementar su aplicación. Esto se puede lograr con un script de configuración apt_setup.shque se vería como

apt-key add - <<EOF
-----BEGIN PGP PUBLIC KEY BLOCK-----
<YOUR RELEASE OFFICER PGP KEY GOES HERE>
EOF

cat >> /etc/apt/sources.list <<EOF
deb https://my.organisation.org/repo debian-jessie main
apt-get update -y
apt-get upgrade -y
EOF

y a lo Dockerfilelargo de las líneas de

ADD apt_setup.sh /root
RUN sh -ex /root/apt_setup.sh && rm /root/apt_setup.sh
RUN apt-get install -y my-node-js-package

(En su situación específica, apt_setup.shsería más complicado, agregando los repositorios del origen de nodos y algunos paquetes auxiliares como apt-transport-https ).

Por lo tanto, es realmente posible usar paquetes Debian y Docker simultáneamente, sin embargo ...

Mi instinto [...] me dice que si los paquetes deb fueran una buena opción, sería más común

Este es un problema correcto que nos lleva a preguntarnos por qué Docker demuestra ser popular como un sistema de empaquetado ad hoc , mientras que no está destinado a serlo. (Véase más arriba.)

El sistema de empaque "oficial" de una distribución dada es solo una posibilidad, entre muchas otras, de instalar software en algún entorno informático. Hay muchas otras fuentes disponibles, como administradores de paquetes específicos de la comunidad, como npm u opam, árboles de puertos como pkgsrc y distribución de código fuente simple. Desde esta perspectiva, es fácil entender el éxito de Docker como un sistema de empaquetado ad hoc :

• Las especificaciones de Docker están muy cerca de un script de shell y de cualquier fuente de la que provenga, instalamos software usando el shell.

• Docker tiene un servicio "incorporado" (de pago) para alojar los artefactos que produce, el Docker Hub .

¿Cuáles son las ventajas de los paquetes de Debian sobre las imágenes de Docker como un sistema de paquetes? El control estricto sobre las dependencias en la instalación. (La posibilidad de actualizar y degradar también existe, pero no tiene importancia práctica si estamos implementando el patrón de servidor inmutable ). Esto lleva a

Conclusión

Si solo tiene un único producto implementado en una única versión (lo cual es típico para SaaS), sus necesidades de administración de versiones son muy simples y usar Docker como administrador de paquetes ad hoc no debería tener inconvenientes. Tan pronto como trabaje con varias versiones de un solo producto o varios productos, la complejidad del problema de restricciones de versión que necesita resolver aumenta y necesita una herramienta adecuada para esto, que pueden ser paquetes Debian o algún sistema de administración de configuración si está software de mezcla de diferentes orígenes.

Sí, hay inconvenientes.

Con un paquete .deb no podrá tener dos versiones de la misma aplicación en el mismo host. Tendrá que confiar en los paquetes de distribución disponibles, si su aplicación se basa en nodejs, por ejemplo, o se quedará con la versión de distribución o tendrá que instalar la suya.

Ahora, cuando desee alojar múltiples aplicaciones en el mismo host, se encontrará con un muro muy rápidamente cuando dependan de lo mismo (conservemos nodejs aquí) en dos versiones diferentes.

El objetivo principal de Docker es aislar cada aplicación del sistema de alojamiento y otras aplicaciones en el mismo host. hay dos razones para hacer este aislamiento: 1. para evitar comprometer la aplicación para poder hacerse cargo del host o impactar en otra aplicación 2. para darle a la aplicación sus dependencias exactas y evitar que se vea afectada por una actualización del sistema u otra aplicación dependencia.

Un paquete Debian (o RedHat) para instalar aplicaciones ha sido una buena práctica cuando se hace correctamente. Los paquetes se utilizan con el fin de implementar aplicaciones que se cambian con poca frecuencia. Los paquetes de Debian implican algunos gastos generales, como la gestión de versiones, la gestión de dependencias, los scripts previos y posteriores a la instalación, etc.

En muchos casos, la actualización de una versión anterior a una nueva requiere la escritura cuidadosa de los scripts, la atención a los detalles en la versión, etc. Debido a que mutar el estado existente es difícil. Sería mucho más fácil reemplazar el estado actual por un estado nuevo, sin mutar nada.

Una vez que decida reemplazar completamente su configuración o dependencias o aplicación en cada implementación porque es más fácil y menos propenso a errores. La mayoría de las organizaciones (solían) cambiar a una máquina virtual completamente nueva o una instancia de la nube. Lo que significa que la instalación del paquete se realizaría en un servidor "limpio", y la mutación de los archivos y la configuración en el servidor ya no es un problema.

Los desarrolladores que crearon paquetes y no entendieron la falacia y la complejidad de las mutaciones sufrieron muchas dificultades como resultado.

Reemplazar máquinas virtuales es subóptimo cuando todo lo que necesita es reemplazar una aplicación, razón por la cual se introdujeron contenedores livianos como respuesta. Con Docker (u otro LWC) puede reemplazar la base de usuarios, incluidas todas las dependencias, sin reemplazar el servidor en sí. También puede alojar varias versiones de la misma aplicación, con diferentes dependencias, en el mismo servidor y solo cambiar el tráfico de red entrante en la actualización. Además de volver a cambiar el tráfico de red en retroceso (azul-verde), algo que fue notablemente difícil en el caso de administrar implementaciones a través de paquetes.

Los contenedores presentan una forma de agrupar todo el código de la aplicación, las dependencias y la configuración en una imagen. Esta imagen tiene múltiples propiedades que la hacen mucho mejor que los paquetes tradicionales del sistema operativo. Por ejemplo, tiene etiquetas que permiten el control de versiones, pero también tiene capas, que permiten ahorrar espacio. Permite una manera fácil de enviar estas imágenes a servidores y entornos de desarrollo mediante el uso de un registro. Y estas imágenes se pueden ejecutar como contenedores en cualquier entorno y cualquier servidor, casi de manera idéntica. Esto incluye la computadora portátil del desarrollador, así como el entorno de producción. Una vez más, algo que era mucho más difícil de hacer con máquinas virtuales y / o con versiones del software basadas en paquetes. Tener la misma imagen probada en la computadora portátil del desarrollador y mantener los mismos bits y bytes en la producción elimina muchas "

Hablando específicamente sobre la pieza de empaquetado de imágenes de Docker, no sobre el tiempo de ejecución del contenedor, hay algunos bits menores. Lo más importante es que una imagen de Docker se parece más a un chroot, lo que significa que no puede depender accidentalmente del estado del sistema compartido, ya que todos los archivos en uso deben incluirse explícitamente en la imagen, mientras que un paquete del sistema puede recoger enlaces dinámicos que usted no esperar o de lo contrario estar más entrelazado con otros paquetes. Esto puede surgir con complejas dependencias de C que se cargan sin su conocimiento, por ejemplo OpenSSL. Además, el uso de paquetes deb no desduplica los bits compartidos en el sistema de almacenamiento de Docker. Para algunos esto podría ser algo bueno, un mejor rendimiento de E / S y menos piezas móviles, pero para otros podría ser un problema.