¿Docker es adecuado para mi caso de uso?

Mi compañía tiene un sistema que vendemos que consiste básicamente en una mini computadora "Smartbox" que ejecuta Ubuntu 12.04. Este cuadro ejecuta una aplicación Django más una serie de diferentes procesos de arranque relacionados con él. No mucho mas. Tenemos miles de estas cajas en el campo. Gestionamos las dependencias del paquete, el registro del proceso, etc. a través de un paquete deb con diversos grados de éxito.

Necesitamos una forma de enviar actualizaciones de manera eficiente y robusta a nuestros usuarios en el campo. También necesitamos algo que, a medida que actualizamos el sistema operativo (estamos atrasados ​​para una actualización de Ubuntu, como puede ver), podamos sentirnos relativamente seguros acerca de nuestros paquetes "simplemente funcionando".

No sé mucho sobre Docker, pero cuando escuché por primera vez sobre nuestro problema (soy un nuevo empleado), Docker fue mi primer pensamiento. Pero cuanto más lo pensaba, sentía que tal vez no lo era, ya que estos cuadros son nuestros, controlamos el sistema operativo, que es una gran parte de la propuesta de valor de Docker, o eso entiendo. Entonces, si SABEMOS que nuestras cajas siempre serán Ubuntu y básicamente solo tenemos una aplicación Django más algunos procesos para ejecutar, ¿es Docker mejor que un paquete deb?

TL; DR: paquetes Docker vs deb para un dispositivo distribuido que siempre ejecutará Ubuntu, por lo que la independencia de la plataforma no es tan importante.

No estoy 100% seguro de entender de la pregunta, pero parece que la solución de Docker sería pasar de tener un dispositivo (físico) con un sistema operativo y su aplicación instalada en él, a tener un dispositivo con un sistema operativo y Docker en él, ejecutando un solo contenedor con su aplicación en él. Eso no elimina la necesidad de actualizar el sistema operativo en el host, y agrega una capa de complejidad (y más actualizaciones para enfrentar, ya que ahora tendrá que mantener Docker y el sistema operativo parcheados) sin ningún beneficio aparente en lo que respecta a las áreas específicas mencionadas en la pregunta.

Sin embargo, si está hablando de pasar de un dispositivo virtual a un contenedor Docker, eso podría facilitarle las cosas, pero también agrega Docker como una dependencia para su producto; estás excluyendo a cualquiera que no esté usando Docker y no quiera agregarlo a su pila solo para usar tu producto. Puede continuar apoyando a aquellos que no usan / no usarán Docker al continuar enviando el dispositivo virtual (ahora "heredado") como antes, pero ahora acaba de duplicar su carga de trabajo porque tiene dos distribuciones para soportar en lugar de uno.

He trabajado con Docker mucho tiempo. La independencia de la plataforma es agradable, pero no es lo que considero más útil sobre Docker.

En primer lugar, obtienes repetibilidad. Puede crear un Dockerfile, depurar en un contenedor en su máquina de desarrollador, ejecutar pruebas en un servidor de integración continua y luego en su producto final, y sabe que se comportará igual en todos esos entornos. Sin olvidar una dependencia que un desarrollador había instalado en su máquina. Además, sus desarrolladores no tienen que usar Ubuntu en su escritorio. Importante para mantenernos contentos con los usuarios de Arch Linux :-)

En segundo lugar, para su escenario de actualización, puede tener varias versiones extraídas en una máquina a la vez. Si hace un docker pull myapp:2.0tiempo en 1.0ejecución, puede cambiar a 2.0extremadamente rápido. Mucho más rápido de lo que normalmente llevaría una actualización completa del sistema operativo. Si usa un orquestador con múltiples instancias de microservicios, incluso puede hacer actualizaciones continuas que no interrumpan el servicio en absoluto.

Si usa un modelo de microservicios, Docker también proporciona cajas de arena que pueden limitar la cantidad de daño que los atacantes pueden hacer en caso de una vulnerabilidad. En lugar de obtener el control de una máquina completa, solo obtienen el control de un contenedor.

El principal inconveniente es que necesita el sistema operativo host y algún tipo de orquestación. Hay muchas opciones para eso, pero no subestimes la cantidad de trabajo que se necesita para evaluar uno, ponerlo en su lugar y mantenerlo.

En general, la ventana acoplable ofrece muchas ventajas tanto para los desarrolladores como para el personal de operaciones. Uso docker para algunas de mis aplicaciones y considero que es un enfoque muy confiable y robusto.

Mi problema con la adopción de Docker es que no te escucho hacer las preguntas correctas y que potencialmente podrías complicarte la vida sin abordar tus requisitos más importantes.

La primera pregunta que debe hacer (usted dijo que era nuevo) es cómo se manejan las actualizaciones del sistema operativo y la aplicación ahora. ¿La metodología actual funciona para usted (su empresa)? ¿Qué funciona bien? ¿Qué se podría mejorar? ¿Puede hacer una auditoría de configuración física en sus máquinas de destino en el campo para verificar que tienen los parches de sistema operativo correctos, la aplicación y si hubo cambios no autorizados?

Me encanta Docker, pero no me subiría al tren de Docker sin evaluar primero dónde estás ahora, incluido lo que funciona bien y lo que hay que mejorar.

Si bien hay una pequeña región superpuesta, Docker y los sistemas de empaquetado de Debian esencialmente resuelven dos problemas muy diferentes :

• El sistema de empaquetado de Debian está diseñado para instalar software en un host y actualizarlo tan fácilmente como sea posible. Es capaz de manejar patrones complejos de dependencia y restricción entre componentes de software, como "la versión A del software X requiere el software Y con la versión B o más reciente instalada" o "el software X nunca debe instalarse con la versión C del software Z".

• El sistema Docker está concebido para describir e implementar fácilmente servicios, especialmente microservicios, posiblemente en varios hosts, por ejemplo, un enjambre Docker o un clúster Kubernetes.

Estos dos problemas son esencialmente ortogonales, lo que significa que, dado el problema de implementación a resolver, uno puede usar uno de ellos, ambos, o tal vez ninguno de ellos, como parte de la solución. Cuando se usan ambos, el paquete Debian se usa en la producción de la imagen Docker, y su Dockerfile (las recetas utilizadas para preparar la imagen Docker que describe el "sistema virtualizado" ejecutado en un contenedor) esencialmente registraría su repositorio Debian en el fuentes del sistema de empaquetado de Debian e instale su paquete.

Con esto en mente, me parece que lo que realmente está buscando es implementar el patrón de servidor inmutable. El reciente desarrollo en tecnologías en la nube hizo posible actualizar el software no utilizando el sistema clásico de actualización de software desde un sistema de paquete de software (como el sistema de empaquetado Debian) sino simplemente reemplazando el servidor completo de una vez. (Algunas personas hicieron esto antes de este desarrollo al tener tres OS-s en un servidor, dos utilizados alternativamente para ejecutar el dispositivo y un mini-OS dedicado a realizar el reemplazo del dispositivo. Aunque no es demasiado complejo, parece que siempre ha sido un nicho.) Esta técnica puede ser de su interés porque si está acostumbrado a actualizar el software en su servidor utilizando el administrador de paquetes, el estado final del servidor depende del "historial de actualizaciones" del servidor, especialmente si se producen errores en el servidor. proceso de actualización Esta heterogeneidad es mala.

Tenemos miles de estas cajas en el campo. Gestionamos las dependencias del paquete, el registro del proceso, etc. a través de un paquete deb con diversos grados de éxito.

podría relacionarse con esto. El patrón de servidor inmutable borra esta fuente de errores al destruir esencialmente la noción de "historial de actualizaciones" del problema.

Ahora hay varias opciones para implementar el patrón de servidor inmutable, dos opciones populares son usar imágenes Docker, imágenes o usar "imágenes de instancia maestra" de su proveedor de la nube (se llaman AMI en AWS y solo imágenes personalizadas en Google Compute Engine) . Su caso de uso prohíbe el uso de técnicas basadas en la nube, por lo tanto, asumiré las imágenes de Docker como la única opción elegible. (En aras de la finalización, ciertamente es posible utilizar otros enfoques, por ejemplo, utilizando Virtual Box o una solución de virtualización similar, como una alternativa a Docker).

Cuando utiliza la técnica de patrón de servidor inmutable, introduce un nuevo artefacto (la imagen de Docker) que representa su servidor y este artefacto también se puede probar, y es muy fácil obtener una configuración que reproduzca verdaderamente sus configuraciones de producción, aparte de la carga de servicio.

Ahora, para considerar el problema concreto que describió, supongamos que implementar el patrón de servidor inmutable con Docker es realmente lo que desea. Dado que el sistema Docker y el sistema de empaquetado Debian son complementarios en lugar de mutuamente excluyentes (véase la introducción), aún tenemos que abordar la pregunta de si debe preparar un paquete Debian para su software.

La pertinencia de utilizar un paquete Debian para instalar su software (en la imagen de Docker o en un host) radica en la complejidad del problema de versiones que debe resolver. Si ejecuta al mismo tiempo varias versiones de su software, ocasionalmente necesita una versión anterior y tiene requisitos de versión complejos que debe documentar cuidadosamente, debe tener un paquete Debian. De lo contrario, este paso se puede omitir, pero dado que ya se esforzó por producir e implementar estos paquetes, no hay un valor real para deshacerse de su trabajo. Por lo tanto, sugeriría continuar produciendo sus paquetes Debian.

Creo que podría ser una buena opción (se necesitan más pruebas)

Puede proporcionar una URL con todas las etiquetas / versiones del contenedor que ha creado y los clientes leerán esa URL para ver si hay una nueva versión del contenedor.

Puede almacenar archivos / configuraciones personales en local y nunca perderá esa información en las actualizaciones y se asegurará de que lo que ha hecho y probado funcionará para todos de la misma manera.

Incluso podría dar a los usuarios la posibilidad de elegir qué versión de la disponible quieren usar (si desea dar esa posibilidad).

Será como "" solo actualizar un paquete "", hablando de recuperar solo una nueva versión del contenedor, mucho mejor que tratar con paquetes debian;)

Docker me parece razonable, ya que podría hacer y probar cambios en el contenedor de la casa, y luego, dependiendo de su proceso de lanzamiento, reinicie los contenedores siempre tirando: lo último o algo similar que proporcionaría una actualización probada.

Las consideraciones con las que debería lidiar incluyen el almacenamiento de datos, ya que los contenedores no retienen los cambios al reiniciar, por lo que desearía un volumen de datos. Probablemente hay muchas más consideraciones que tendrías también una vez que profundices en ello. El sistema con el que estoy trabajando actualmente (todo basado en Docker) ha estado en desarrollo durante más de un año y todavía estamos encontrando áreas en las que necesitamos realizar cambios en el contenedor, las configuraciones, etc.