Docker Compose no es suficiente

• docker-compose es una herramienta para gestionar contenedores de Docker que resuelve problemas complejos de despliegue de aplicaciones, pero no es suficiente para el self-hosting simple orientado al mercado masivo
• Se necesita una abstracción de más alto nivel que incluya conceptos como bases de datos SQL, caché local, almacenamiento persistente, descubrimiento de servicios y gestión de recursos

El papel de Docker

• Docker es la herramienta que popularizó la contenerización, y el sistema host puede compararse con un barco.
• Hay hardware, sistema operativo y un runtime de contenedores; los contenedores se ejecutan dentro del runtime y se comunican con otros servicios como bases de datos o servidores web.

El papel de Docker-compose

• docker-compose es una herramienta para definir grupos de contenedores que trabajan juntos, y facilita el despliegue de aplicaciones de self-hosting.
• Sin embargo, rompe la interfaz estandarizada y vuelve a reproducir los problemas que los contenedores originalmente resolvían.
• Ejemplo: Pihole
  • Pihole es un servidor DNS y requiere un archivo docker-compose complejo.
  • Hay que configurar nombre del contenedor, imagen, puertos, variables de entorno, volúmenes, funciones adicionales, políticas de reinicio, etc.
  • La configuración compleja debe ser gestionada directamente por el usuario, y eso es una desventaja de Docker Compose
• Ejemplo: Jitsi Meet
  • Jitsi Meet es un software complejo que genera una configuración de docker-compose con 4 contenedores, 7 volúmenes, 9 puertos y más de 200 variables de entorno.
• Ejemplo: otras aplicaciones populares de self-hosting también sufren problemas similares
  • Hay varias aplicaciones como Authentik, Nextcloud, Immich, Jellyfin y Paperless NGX, y cada configuración de docker-compose reemplaza desde decenas hasta cientos de comandos docker.
  • Cada aplicación puede incluir su propia base de datos, caché y manejador HTTP, lo que lleva a un uso duplicado de recursos.

Problemas

• docker-compose es demasiado flexible y detallado, y opera en una capa de abstracción incorrecta.
• Cada aplicación tiene su propio proceso de manejo HTTP, caché o base de datos. Hacer respaldos de las bases de datos queda en manos del operador del sistema.
• Ejemplo: proxy HTTP inverso
  • Un proxy HTTP inverso es un programa que reenvía solicitudes HTTP entrantes a otros programas. Cada programa debe decidir si incluirá o no un servidor web.
  • Incluir servidor web
    • Si se incluye un servidor web, el programa funciona, pero solo en puertos específicos, y si hay varios contenedores, hay que remapear los puertos.
  • No incluir servidor web
    • Si no se incluye un servidor web, no se desperdician recursos, pero la aplicación debe configurarse sin una interfaz de administración.
  • DNS
    • La interfaz web tiene una dirección y, si se quiere TLS, necesita un nombre. Si se ejecutan varios servicios en un solo host, las solicitudes deben enrutarse por nombre de dominio o por ruta.
  • Puertos
    • docker-compose permite exponer y remapear puertos, pero en la práctica debería soportar configuraciones de red complejas.
• Ejemplo: base de datos
  • En una base de datos, todos los cambios en archivos se eliminan cuando se borra el contenedor. El contenedor de la base de datos debe agregar un volumen para guardar su contenido.
  • N+1=2 o más
    • Para respaldar la base de datos se necesitan copias de seguridad fuera del sitio. Si cada servicio incluye su propio proceso de servidor de base de datos por separado, se desperdician recursos de cómputo.

Solución

• Hay que moverse a una capa de abstracción más alta y añadir semánticas que distingan tipos de contenedor como base de datos, proxy web inverso, caché y recursos web estáticos.
• Ejemplo de semánticas
  • Se introduce un nuevo formato de configuración para especificar nombre de la aplicación, build, proxy HTTPS inverso y servicio de caché.
• Solución #1
  • Cada programa solicita un proxy inverso, evitando duplicación y desperdicio. El proxy inverso proporciona un nombre DNS y reenvía todas las rutas al programa.
• Solución #1.5
  • Se agrega una sección de base de datos para solicitar una base de datos compatible con el estándar SQL, y el programa espera privilegios "completos".
• Solución para los puertos
  • Cada programa puede recibir su propia dirección IPv6 y usar números de puerto estándar. Por seguridad, se usa un firewall para que solo el proxy inverso pueda acceder a los puertos.

Tealok - un nuevo runtime de contenedores

• Tealok es un nuevo runtime de contenedores que ofrece una abstracción más alta e interfaces estandarizadas.
  • Maneja automáticamente certificados TLS, configuración de proxy inverso, registros DNS, gestión de respaldos y más.
  • Aprovecha IPv6 para que cada contenedor tenga una dirección IP independiente y pueda usar números de puerto estándar.
  • Los desarrolladores de aplicaciones pueden desplegarlas mediante interfaces estándar sin configuraciones complejas.
• Para los operadores, ofrece mejores prácticas consistentes, menos desperdicio de recursos y menor carga administrativa.
• Para los desarrolladores, simplifica la forma de desplegar y reduce la carga de tomar decisiones.
• Los usuarios pueden garantizar la propiedad de sus datos y la independencia de la computación en la nube.

[luminance]

Entré a tealok y, por lo que vi, no parece estar en un estado como para ser una alternativa, ¿no?

[savvykang]

Ojalá también hubieran quitado el runtime.

[tujuc]

Todavía creo que sigue siendo necesario usar docker-compose para armar un entorno de operación y entrar a él, pero...

Cuesta estar de acuerdo con eso de decir que, basándose en una experiencia dentro de un entorno especial y propio, eso está mal y por eso hicieron algo nuevo... jajaja

Es un contenido que se puede malinterpretar fácilmente jajajaja...

Como yo había pensado al ver solo el título: "Ah, de verdad no me gusta usarlo en el entorno de desarrollo..." jajaja

[ilbanin00]

Me parece que intentar usar Docker Compose para el mismo propósito que en el artículo es, desde el principio, un enfoque equivocado.

[tujuc]

Estoy parcialmente de acuerdo, pero no creo que el enfoque haya sido incorrecto.
Probablemente fue lo mejor que podían hacer en el entorno que tenían :)

[GN⁺]

Opiniones de Hacker News

• Existe una solución simple para los problemas de mapeo de puertos y respaldo de volúmenes de datos

  • Se puede usar un archivo separado de docker-compose para el entorno de desarrollo y definir configuraciones distintas según el entorno
  • Se puede escribir un script sencillo de Bash para respaldos y subirlos a S3

• Como alguien que usa Docker para self-hosting en un servidor personal, valoro positivamente la flexibilidad de la configuración de Docker

  • La configuración inicial tomó tiempo, pero después se volvió fácil de administrar
  • Agregar un nuevo servicio casi no toma tiempo, y por seguridad se crea un usuario no root para cada servicio
  • Se usa una red macvlan para asignar una IP y una dirección MAC únicas a cada contenedor
  • Se usa Nginx Proxy Manager para gestionar el proxy inverso, y no hay problema incluso al ejecutar varias instancias con base de datos

• docker-compose se usa principalmente para desarrollo o uso personal, y V2, a diferencia de V1, es un plugin integrado en Docker

• En producción, es mejor usar Kubernetes, mientras que docker-compose es adecuado para desarrollo local

• docker-compose es un producto para self-hosting a pequeña escala, dirigido a personas sin experiencia técnica

  • Hay escepticismo sobre que cambiar a TOML vaya a hacer más fácil el self-hosting

• Escribir un programa para controlar Docker es más simple de lo que parece, y se pueden resolver problemas usando scripts de Python

• Se está desarrollando canine.sh para que usar un clúster de Kubernetes sea tan fácil como Heroku

  • Se está usando en proyectos personales y permite alojar varias apps a bajo costo

• Resulta interesante que Tealok esté desarrollando una alternativa a docker-compose

• Se considera que docker-compose, Kubernetes y Helm son capas de abstracción equivocadas

  • Hay muchos intentos de desarrollar distintas formas de ejecutar y comunicar contenedores

• Hay confusión ante la afirmación de que docker-compose es una capa de abstracción equivocada

  • Parece que se espera una interfaz de alto nivel para resolver problemas específicos
  • El problema de crear instancias duplicadas no es algo grave en la mayoría de las aplicaciones
  • Forzar a diseñar las aplicaciones de una manera específica solo funcionará bien en ciertas situaciones