Do Docker à produção

Quem trabalha com infraestrutura e desenvolvimento sabe: o papel aceita tudo, mas o terminal não perdoa. Recentemente, passei por uma sequência de desafios reais que vão desde a configuração de containers até erros de execução em ambiente de produção com Prisma e Bun.

Decidi documentar o processo para quem, assim como eu, precisa de soluções que sobrevivam ao próximo reboot.

1. O dilema da persistência: "para onde foram meus arquivos?"#

A dúvida inicial era clássica: como subir containers Docker sem que os arquivos sejam removidos ao pausar ou reiniciar? Muitas vezes, confundimos o ciclo de vida do container com o armazenamento. Se você deleta um container e o recria, a camada de escrita temporária morre com ele. A solução é separar o processo dos dados.

A minha estratégia: volumes e BIND mounts#

Para garantir que os dados sobrevivessem, a estratégia que utilizei foi o mapeamento de volumes. No caso de uma distro como o Kali Linux rodando via Docker, o segredo é mapear a pasta de configurações interna para um diretório real na máquina hospedeira.

O código funcional do docker-compose.yml que eu executei:

services:
  kali-linux:
image: lscr.io/linuxserver/kali-linux:latest
container_name: kali-linux
environment:
  - PUID=0   # Rodando como root para o meu lab
  - PGID=0
  - TZ=America/Manaus
volumes:
  - /home/distros/kali:/config # O mapeamento real para persistência
ports:
  - 3000:3000
  - 3001:3001
shm_size: "1gb"
restart: unless-stopped

Ao apontar /home/distros/kali para o /config interno, tudo o que eu faço na interface gráfica ou no terminal - documentos, scripts e histórico - fica salvo fisicamente no meu SSD. Se o container cair, os dados estão lá.

2. O pesadelo do "table does not exist" no prisma#

Resolvida a infra do container, o próximo desafio foi no deploy de uma aplicação Node/TypeScript usando Prisma ORM. Ao rodar o seed do banco, o terminal cuspiu o erro P2021:

The table public.PlanLimits does not exist in the current database.

A causa que identifiquei: O código estava tentando inserir dados em uma estrutura que ainda não existia fisicamente no PostgreSQL. Isso acontece quando editamos o schema.prisma mas esquecemos da sincronia física.

O workflow de correção (via Bun)#

Eu segui esta hierarquia rigorosa para sanar o erro:

Push: Sincronizar o schema com o banco: bunx prisma db push
Generate: Atualizar o client para o código reconhecer os novos modelos: bunx prisma generate
Seed: Aí sim, popular as tabelas: bunx prisma db seed

3. "Command not found": o Bun sumiu do mapa?#

Para fechar a maratona, me deparei com um erro de runtime ao tentar subir o ambiente com nohup: nohup: failed to run command 'bun': No such file or directory.

Mesmo com o Bun instalado, o sistema não o encontrava no PATH ao rodar scripts em background. Isso ocorre porque o binário do Bun geralmente fica na pasta local do usuário (.bun/bin).

A solução "raiz"#

Em vez de brigar com variáveis de ambiente em cada sessão, a solução mais limpa que apliquei foi criar um link simbólico global:

# Tornando o Bun acessível em todo o sistema
ln -s /root/.bun/bin/bun /usr/local/bin/bun

Após isso, qualquer processo passou a reconhecer o comando, eliminando falhas de execução.

Considerações práticas#

Trabalhar com Docker e stacks modernas como Bun e Prisma exige entender que a infraestrutura precisa ser resiliente e previsível. Seja mapeando volumes corretamente para não perder horas de trabalho, ou garantindo que seus binários estejam no PATH global, o segredo é sempre conhecer o caminho que o dado e o processo percorrem.

A infraestrutura é o alicerce. Se ela não for sólida, o código mais bonito do mundo vai falhar no primeiro reinício.

Este artigo foi útil?

Deixe uma reação rápida para apoiar o conteúdo:

Este post está licenciado sob CC BY-NC.

Do Docker à produção: resolvendo a persistência e erros de runtime no "pé no barro

1. O dilema da persistência: "para onde foram meus arquivos?"#

A minha estratégia: volumes e BIND mounts#