Docker para agentes e bots (Sandboxing de contêineres)

1. Visão geral do conceito e o problema sistêmico

Executar agentes autônomos, scrapers, bots e scripts de geração de código diretamente no sistema operacional do servidor (por exemplo, via chamada direta python agent.py ou node bot.js) cria ameaças críticas:

• Erros catastróficos e injeções: um modelo que recebe uma ferramenta para executar comandos shell pode acidentalmente excluir o diretório de trabalho do projeto, alterar permissões em /etc/shadow ou vazar variáveis de ambiente do host.
• Conflitos de dependências ("Dependency Hell"): um bot requer Node.js 18 e Python 3.10, enquanto outro exige Node.js 22 e bibliotecas do sistema Chromium para Playwright. Tentar implantá-los no mesmo host quebra os pacotes do sistema.
• Esgotamento de memória (Fork Bombs): um loop autônomo infinito pode criar milhares de processos paralelos, causando Kernel Panic ou travamento completo do servidor.

Docker para agentes e bots oferece containerização determinística e isolamento robusto (Sandboxing). Utilizando primitivas nativas do kernel Linux, o container cria uma cápsula efêmera e leve, onde o agente obtém todas as utilitários necessários, mas não consegue afetar o sistema hospedeiro ou serviços vizinhos.

2. Taxonomia arquitetural e modelo mental

A arquitetura de isolamento seguro de agentes baseia-se em três níveis de controle do kernel Linux:

┌─────────────────────────────────────────────────────────────┐
│                 ARQUITETURA DO SANDBOX DO AGENTE DOCKER     │
├─────────────────────────────────────────────────────────────┤
│ 1. Isolamento de Processos (Namespaces do Linux):           │
│    • PID (O agente vê apenas seus próprios processos)       │
│    • NET (Pilha de rede isolada, pares veth)                │
│    • MNT (Sistema de arquivos raiz rootfs próprio)          │
├─────────────────────────────────────────────────────────────┤
│ 2. Enclausuramento de Recursos (Control Groups - cgroups v2):│
│    • Limite de memória (por exemplo, máx. 1,5 GB de RAM)    │
│    • Cota de CPU (por exemplo, máx. 1 núcleo)               │
│    • Limite de PIDs (proteção contra fork infinito de processos)│
├─────────────────────────────────────────────────────────────┤
│ 3. Camada de Endurecimento de Segurança:                    │
│    • Usuário sem privilégios (`USER nonroot` em vez de UID 0)│
│    • Sistema de arquivos raiz somente leitura (`--read-only`)│
│    • Capacidades do Linux removidas (`--cap-drop=ALL`)      │
├─────────────────────────────────────────────────────────────┤
│ 4. Integração com o Host: Volumes Nomeados & Verificações   │
│    de Integridade                                           │
└─────────────────────────────────────────────────────────────┘

1. Namespaces (Linux Namespaces):
   • Garantem a virtualização de processos, rede e sistema de arquivos. O agente dentro do container vê-se como um SO separado e não tem acesso aos processos do host.
2. Control Groups (cgroups v2):
   • Quotas de hardware rígidas: limites de RAM, CPU e número de threads. Se o script do agente começar a vazar memória, o OOM-killer do Linux mata apenas o container, sem afetar os serviços principais do servidor.
3. Containers efêmeros descartáveis (Throwaway Sandboxes):
   • Execução com a flag --rm. Após a execução do código, o container se autodestrói junto com todas as alterações temporárias.
4. Políticas de reinicialização (Restart Policies):
   • Para bots de longa duração, a diretiva restart: unless-stopped no docker-compose.yml garante a subida imediata do serviço após o reinício da VPS.

3. Pipeline técnico e mecânica interna

O ciclo de vida da execução segura de código não verificado em um sandbox de agente:

1. Definição da tarefa e criação da configuração: O agente de IA gera o script (por exemplo, código Python para parsing de dados financeiros).
2. Preparação do volume isolado: O sistema hospedeiro cria uma pasta temporária /tmp/sandbox-run-981, grava o script nela e define permissões de usuário não privilegiado UID 1000.
3. Iniciação do container descartável protegido: O orquestrador inicia o comando com reset completo de privilégios:

   docker run --rm \
     --network none \
     --memory 512m \
     --cpus 1.0 \
     --pids-limit 64 \
     --read-only \
     --tmpfs /tmp:rw,noexec,nosuid,size=64m \
     --user 1000:1000 \
     -v /tmp/sandbox-run-981:/app:ro \
     python:3.12-slim python /app/script.py
   

4. Execução isolada: O script é executado:
   • A rede está totalmente desativada (--network none), impossibilitando vazamento de dados para a nuvem do atacante.
   • O sistema de arquivos é somente leitura (--read-only).
   • A escrita é permitida apenas em um pequeno disco temporário na RAM (/tmp).
5. Leitura da saída e limpeza: Os fluxos STDOUT e STDERR são retornados ao núcleo do agente, após o que o diretório temporário é excluído em fração de segundo.

4. Cenários práticos de engenharia em produção

01. Stack de produção resiliente para Telegram Bot

Implantação do bot usando docker-compose.yml:

services:
  bot:
    build: .
    restart: unless-stopped
    environment:
      - BOT_TOKEN=${BOT_TOKEN}
      - DATABASE_URL=postgres://user:pass@db:5432/botdb
    depends_on:
      db:
        condition: service_healthy
    deploy:
      resources:
        limits:
          memory: 512M

  db:
    image: postgres:17-alpine
    restart: unless-stopped
    volumes:
      - pgdata:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U user -d botdb"]
      interval: 10s

volumes:
  pgdata:

• O bot reinicia automaticamente em caso de falhas inesperadas de memória, e os dados do banco são persistidos no volume pgdata.

02. Execução isolada de agente de navegador Playwright

Testes automatizados e scraping de SPAs complexas:

• O agente sobe um container com Chromium headless instalado.
• Abas de navegador travadas ou animações pesadas consomem apenas a memória virtual alocada ao container, sem sobrecarregar a estação de trabalho.

03. Execução em lote de scripts de usuários não verificados

Plataforma online de teste de código:

• Cada teste de usuário roda em seu próprio container com timeout rígido de 5 segundos, impedindo o travamento do servidor por loops infinitos while(true).

5. Armadilhas, erros comuns e segurança

• Perda de dados pela ausência de volumes (Volume Absence): Se você implantar um container de banco de dados sem montar um volume persistente (volumes: - db_data:/var/lib/postgresql/data), no primeiro update da imagem ou comando docker compose down, todo o banco de dados do cliente será apagado permanentemente.
• Execução padrão como Root: Se o Dockerfile não especificar a instrução USER appuser, os processos dentro do container rodam com privilégios de superusuário (UID 0). Em caso de vulnerabilidade do kernel (Container Escape), o atacante obtém instantaneamente root total no servidor hospedeiro.
• Estouro de disco por imagens órfãs: Builds regulares de imagens de agentes deixam gigabytes de camadas "órfãs". Configure um comando semanal de limpeza: docker system prune -af --volumes.
• Ignorar .dockerignore: Se você não criar um arquivo .dockerignore, pastas como node_modules, .git e arquivos de segredos locais .env serão copiados para dentro da imagem pública do container durante o build.