Docker em produção sem dramas

Docker é vendido como o que simplifica os deploys. E simplifica, até a primeira vez que um contêiner come o disco ou um restart apaga dados que ninguém sabia que estavam lá dentro.

Os três erros que mais vemos

Dados morando dentro do contêiner. Se não estiverem em um volume nomeado ou em um bind mount, somem no momento em que você reconstrói. É o erro mais comum e mais caro.

Sem limites de recursos. Um contêiner com vazamento de memória pode derrubar todos os outros serviços da máquina. Algumas linhas no compose evitam isso.

Logs crescendo para sempre. Por padrão o Docker guarda cada linha escrita. Já vimos 40 GB de logs encherem um disco e derrubarem um site em produção.

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 vale a pena

Dá para fazer tudo pelo terminal, mas um painel visual muda quem consegue ajudar. Quando um cliente vê os próprios contêineres, reinicia um e lê os logs sem te ligar, todo mundo ganha.

Backups não são opcionais

Um contêiner é descartável. Os volumes dele não. Seja qual for sua rotina de backup, confirme que ela cobre os volumes e — essa é a parte que todos pulam — confirme que a restauração funciona. Um backup que você nunca restaurou é uma hipótese.