Instância Mastodon com Docker Compose: Notas de Produção

Executar uma instância do Mastodon com Docker Compose em ambiente de produção exige mais do que copiar os arquivos de configuração padrão. Muitos administradores descobrem que a instância fica lenta, não responde ou sofre falhas de conexão com o banco de dados após alguns dias de uso. Esses problemas geralmente vêm da falta de ajustes de desempenho, alocação inadequada de recursos ou configuração incorreta de volumes e rede. Este artigo explica os ajustes críticos de produção que você deve fazer nos arquivos Docker Compose, nas variáveis de ambiente e nas configurações do sistema antes de colocar no ar.

Por que as Configurações Padrão do Docker Compose Falham em Produção

O repositório oficial do Mastodon Docker Compose fornece uma configuração voltada para desenvolvimento. Em produção, as configurações padrão permitem uso ilimitado de memória para o pool de workers do Sidekiq, o que rapidamente esgota a RAM do servidor ao processar uploads de imagens e atividade de federação. O processo web também usa um servidor Puma com uma única thread por padrão, causando fila de requisições sob tráfego moderado. O serviço de streaming API, baseado em Node.js, pode perder conexões se o tempo limite de heartbeat não for ajustado. Esses três fatores criam uma cascata de falhas: o pool do banco de dados fica cheio de conexões obsoletas, a memória do Redis transborda e a interface web fica sem resposta. O ajuste de produção trata cada uma dessas camadas explicitamente.

Limites de Recursos para os Serviços Docker

Sem limites explícitos de recursos, os contêineres Docker competem pela CPU e memória da máquina host. O serviço Sidekiq, que processa tarefas em segundo plano como compressão de mídia e entrega de federação, cria múltiplas threads. Se você não limitar a memória, uma única tarefa que processa um arquivo de vídeo grande pode fazer a instância inteira usar swap. Adicione os seguintes blocos de reserva de recursos em cada serviço no docker-compose.yml:

web:
  deploy:
    resources:
      limits:
        memory: 512M
      reservations:
        memory: 256M

sidekiq:
  deploy:
    resources:
      limits:
        memory: 1G
      reservations:
        memory: 512M

streaming:
  deploy:
    resources:
      limits:
        memory: 256M
      reservations:
        memory: 128M

Esses valores assumem um servidor com pelo menos 2 GB de RAM. Ajuste os limites com base no número esperado de usuários simultâneos. O serviço de streaming geralmente requer menos memória porque mantém conexões WebSocket de longa duração com baixo overhead por usuário.

Passos para Converter o Docker Compose para Produção

1. Gerar segredos de produção
   Execute RAILS_ENV=production bundle exec rake secret duas vezes dentro do diretório da aplicação Mastodon. Copie a primeira saída para SECRET_KEY_BASE e a segunda para OTP_SECRET no seu arquivo .env.production. Esses valores devem ter pelo menos 128 caracteres e conter uma mistura de letras, números e símbolos. Nunca use os valores padrão do arquivo .env de desenvolvimento.
2. Configurar o pool de conexões do banco de dados
   No .env.production, defina DB_POOL=25 para uma configuração de processo web único. Se você executar várias réplicas web, divida o total de conexões do banco pelo número de réplicas. Por exemplo, com 5 contêineres web e um max_connections de 100 no banco, defina DB_POOL=20. Isso evita que o PostgreSQL fique sem conexões disponíveis.
3. Ajustar a concorrência do Sidekiq
   Adicione SIDEKIQ_CONCURRENCY=10 ao .env.production. O valor padrão de 25 cria 25 threads por processo Sidekiq. Em um servidor de 2 núcleos, 10 threads oferecem melhor throughput sem excesso de troca de contexto. Monitore a latência da fila do Sidekiq no painel de administração do Mastodon e aumente o valor apenas se as filas ficarem consistentemente acima de 10 segundos.
4. Definir o intervalo de heartbeat da API de streaming
   Adicione STREAMING_API_BASE_URL=https://seudominio.com e STREAMING_CLUSTER_NUM=1 ao .env.production. O intervalo de heartbeat padrão é de 30 segundos. Para produção atrás de um proxy reverso como Nginx, aumente o tempo limite de leitura do proxy para 60 segundos para corresponder. Edite o arquivo streaming/index.js ou use uma variável de ambiente HEARTBEAT_INTERVAL_MS=45000 para reduzir desconexões.
5. Usar volumes nomeados para PostgreSQL e Redis
   No docker-compose.yml, substitua montagens bind por volumes nomeados. Exemplo:
   volumes:
postgres_data:
redis_data:

   Em seguida, referencie-os na definição do serviço:
   volumes:
- postgres_data:/var/lib/postgresql/data

   Volumes nomeados persistem entre atualizações de contêineres e são mais fáceis de fazer backup usando docker volume inspect.
6. Habilitar reinicialização automática e health checks
   Adicione restart: unless-stopped a todos os serviços. Para os serviços web e streaming, adicione um health check:
   healthcheck:
test: ["CMD", "curl", "-f", "http://localhost:3000/health"]
interval: 30s
timeout: 10s
retries: 3

   Isso permite que o Docker reinicie contêineres sem resposta automaticamente, sem intervenção manual.
7. Limitar o tamanho dos arquivos de log
   Adicione configuração de logging a cada serviço:
   logging:
driver: "json-file"
options:
max-size: "10m"
max-file: "3"

   Sem isso, os logs do contêiner podem encher a partição do disco, causando falha na instância. O driver json-file faz rotação dos logs quando atingem 10 MB e mantém três arquivos rotacionados.

Configurações Incorretas Comuns que Quebram Instâncias em Produção

Exaustão de Memória do Redis sem Política de Evicção

O Mastodon usa Redis para filas de jobs do Sidekiq, cache de sessão e limitação de taxa. A configuração padrão do Redis no Docker não define um limite de memória. Quando o Redis excede a RAM disponível, o OOM killer do kernel encerra o processo Redis. Adicione o seguinte ao seu redis.conf ou passe como argumento de comando:
maxmemory 256mb
maxmemory-policy allkeys-lru

Isso limita o Redis a 256 MB e remove as chaves menos usadas recentemente quando a memória enche. Para instâncias de alto tráfego, aumente para 512 MB.

Pool de Conexões do PostgreSQL Subestimado

Cada processo web do Mastodon abre um número fixo de conexões de banco definido por DB_POOL. Se você executar vários contêineres web atrás de um balanceador de carga, o total de conexões é igual a DB_POOL * número_de_contêineres_web. O PostgreSQL tem um max_connections padrão de 100. Se o total exceder 100, novas conexões são recusadas. Verifique os logs do contêiner do banco em busca de FATAL: sorry, too many clients already. Aumente max_connections na configuração do PostgreSQL ou reduza o número de réplicas web.

Falta de Timeout no Proxy Reverso para Uploads de Arquivos

O Mastodon permite uploads de arquivos até o limite definido em MAX_IMAGE_SIZE e MAX_VIDEO_SIZE. Se o seu proxy reverso Nginx ou Apache tiver um tempo limite de requisição padrão de 60 segundos, uploads grandes expiram antes de chegar à aplicação Mastodon. Aumente proxy_read_timeout e proxy_send_timeout para 300 segundos na configuração do proxy reverso. Também defina client_max_body_size para corresponder ao seu limite de upload, por exemplo client_max_body_size 100M.

Item	Padrão de Desenvolvimento	Recomendado para Produção
SECRET_KEY_BASE	ChangeMe	String aleatória de 128+ caracteres
OTP_SECRET	ChangeMe	String aleatória de 128+ caracteres
DB_POOL	5	20–25
SIDEKIQ_CONCURRENCY	25	10
Redis maxmemory	Ilimitado	256 MB
PostgreSQL max_connections	100	150–200
Driver de log	json-file (ilimitado)	json-file (10 MB, 3 arquivos)

Estas notas de produção cobrem as alterações essenciais que transformam uma configuração padrão do Mastodon com Docker Compose em uma instância estável e auto-hospedada. Após aplicar os limites de recursos, geração de segredos e ajustes no pool de conexões, execute docker-compose up -d e verifique os endpoints de saúde. Monitore a latência da fila do Sidekiq e a contagem de conexões do banco diariamente durante a primeira semana. Para ajustes avançados, considere adicionar um CDN para ativos estáticos e habilitar o Redis Sentinel para alta disponibilidade.