Docker en producción sin dramas

Docker se vende como lo que simplifica los despliegues. Y lo hace, hasta la primera vez que un contenedor se come el disco o un reinicio borra datos que nadie sabía que estaban dentro.

Los tres errores que más vemos

Datos viviendo dentro del contenedor. Si no están en un volumen con nombre o en un montaje, desaparecen en cuanto reconstruyes. Es el error más común y el más caro.

Sin límites de recursos. Un contenedor con una fuga de memoria puede tumbar todos los demás servicios de la máquina. Unas líneas en el compose lo evitan.

Logs que crecen sin fin. Por defecto Docker guarda cada línea escrita. Hemos visto 40 GB de logs llenar un disco y tumbar un sitio en producción.

services:
  app:
    image: myapp:latest
    restart: unless-stopped
    volumes:
      - app-data:/var/lib/app      # datos fuera del contenedor
    deploy:
      resources:
        limits:
          memory: 512M            # un fallo no tumba el resto
    logging:
      driver: json-file
      options:
        max-size: "10m"           # los logs no comen el disco
        max-file: "3"

Portainer merece la pena

Todo se puede hacer desde la terminal, pero un panel visual cambia quién puede ayudar. Cuando un cliente ve sus contenedores, reinicia uno y lee los logs sin llamarte, ganan los dos.

Los backups no son opcionales

Un contenedor es desechable. Sus volúmenes no. Sea cual sea tu rutina de backups, comprueba que cubre los volúmenes y, esto es lo que todos se saltan, comprueba que la restauración funciona. Un backup que nunca has restaurado es una hipótesis.