Do local ao cloud: o guia de sobrevivência para migrar Distrobox e containers Podman

Recentemente, tomei uma decisão estratégica para o meu fluxo de trabalho: mover meus ambientes de desenvolvimento locais para uma VM robusta na nuvem (OVH). O objetivo? Transformar meu notebook em um thin client e deixar o processamento pesado no servidor.

Neste processo, enfrentei desafios de rede, latência internacional e inconsistência de rota (especialmente operando do Norte do Brasil). Aqui está o relato técnico de como migrei minhas boxes do Distrobox e containers Podman sem perder um bit de configuração.

1. O ponto de partida: criando a snapshot de backup#

O Distrobox é fantástico pela sua integração fluida com a /home do host, mas sob o capô, ele é gerenciado pelo Podman. Para levar o ambiente completo (binários no /usr/bin, configurações de sistema no /etc, libs instaladas via apt), o primeiro passo é congelar o container "vivo" em uma imagem estática.

No meu caso, eu tinha um container chamado kali-dev. O comando para gerar o snapshot foi:

# Transformando o container em execução em uma imagem local estática
podman commit kali-dev kali-cloud-image

1.1. Verificação de versão do Podman e compatibilidade#

Antes de prosseguir, é essencial verificar a versão do Podman no host local e no host de destino para evitar incompatibilidades de runtime (por exemplo, incompatibilidade entre runc e crun, ou diferenças nas especificações do OCI):

# Verificar versão local
podman --version

# Verificar versão remota no servidor de destino
ssh user@remote-ip "podman --version"

# Inspecionar detalhes de runtime do container
podman info | grep -i "version\|runtime"

Se houver uma grande disparidade de versões (ex: Podman v3 vs v4), certas flags do Distrobox ou opções de montagem rootless do Podman podem falhar ao inicializar no destino.

1.2. Validação da integridade da imagem local#

Antes de realizar a serialização da imagem, valide se ela foi gerada corretamente no registro local:

# Verificar imagem local no repositório
podman images | grep kali-cloud-image

# Verificar tamanho real da imagem gerada no storage local
podman image inspect kali-cloud-image | jq '.[0].Size'

Com a imagem validada, serializamos em um arquivo físico .tar:

# Exportando a imagem para um arquivo .tar indexado
podman save localhost/kali-cloud-image -o backup_ambiente.tar

Após a exportação, verifique a integridade do arquivo tarball resultante para garantir que não houve corrupção na escrita do disco:

# Verificar tamanho físico do arquivo gerado
du -sh backup_ambiente.tar

# Testar estrutura e integridade lógica do arquivo tarball
tar -tvf backup_ambiente.tar | head -10

1.3. Backup estruturado dos arquivos pessoais (dotfiles e projetos)#

Lembre-se: o Distrobox monta a /home do host de forma transparente. Isso significa que seus arquivos pessoais, chaves SSH, dotfiles e repositórios git não estão dentro da imagem exportada. Eles precisam ser migrados separadamente.

Podemos criar um arquivo comprimido excluindo diretórios de cache e caches do Podman locais que causariam overhead e duplicação desnecessária:

# Backup seletivo excluindo caches pesados e volumes temporários
tar czf home-backup.tar.gz \
  --exclude='.cache' \
  --exclude='node_modules' \
  --exclude='.local/share/containers' \
  ~/dotfiles ~/projects ~/Documents

Ou, alternativamente, preparar um sincronismo direto via rsync na etapa de transferência.

2. O desafio da latência: lutando contra a física da rede internacional#

Tentar enviar um arquivo de vários Gigabytes para um servidor no Canadá (OVH) a partir de uma conexão doméstica no Brasil é um teste de paciência e conhecimento de rede.

2.1. Medindo a latência e capacidade de banda#

Antes de iniciar qualquer transferência de grande porte, realize um diagnóstico completo de rede para mapear o throughput máximo e a latência de tráfego (RTT):

# Ping básico para verificar perda de pacotes e latência média (RTT)
ping -c 10 remote-ip

# Mapear saltos de roteamento (hops) para identificar gargalos de tráfego
traceroute remote-ip

# Análise de rede dinâmica em tempo real
mtr --report --report-cycles=10 remote-ip

Se o servidor remoto possuir o daemon iperf3 rodando, realize um teste de largura de banda TCP real para determinar a taxa de transferência real suportada pela rota física:

# Executar teste de banda em modo client por 30 segundos
iperf3 -c remote-ip -t 30

2.2. Métodos de transferência e desempenho#

Tentativa 1: O rsync "ingênuo"#

Tentei o rsync clássico para garantir a integridade e compressão de transferência:

rsync -vhP backup_ambiente.tar user@remote-ip:~/

Diagnóstico: O algoritmo de delta-transfer del rsync e o overhead do protocolo resultaram em uma velocidade pífia de 600 KiB/s. Tempo estimado: +7 horas. Inviável para quem precisa de produtividade.

Tentativa 2: SSH pipe com gzip e pipe viewer (pv)#

Para maximizar o throughput, tentei compressão em tempo real e cifragem SSH otimizada:

pv backup_ambiente.tar | gzip -1 -c | ssh -c [email protected] user@remote-ip "gunzip -c > ~/backup_ambiente.tar"

Percepção Técnica: O pv me deu a telemetria real. Notei que o gargalo não era CPU (compressão), mas o peering internacional da operadora. A rota direta Brasil -> Canadá sofria com buffers de ISP saturados e perda de pacotes em roteadores Tier 2. Podemos também testar a velocidade física de transferência enviando o tráfego para /dev/null no destino para isolar gargalos de disco:

pv backup_ambiente.tar | ssh user@remote-ip "cat > /dev/null"

3. Segurança da transferência e validação de recursos#

Trabalhar com servidores em nuvem exige a aplicação de protocolos seguros e planejamento de capacidade de recursos.

3.1. Verificação de espaço em disco#

Antes de enviar arquivos de dezenas de gigabytes, certifique-se de que o servidor de destino possui armazenamento disponível suficiente na partição /home ou /var onde o Podman opera. Um disco cheio durante a transferência resultará em falhas silenciosas ou travamento do sistema de arquivos:

# No destino, verificar o espaço em disco da partição destino
ssh user@remote-ip "df -h ~"

# Comparar o tamanho do arquivo local com o espaço remoto disponível
echo "Tamanho do Arquivo Local: $(du -sh backup_ambiente.tar | awk '{print $1}')"
echo "Espaço Disponível no Destino: $(ssh user@remote-ip 'df -h ~' | tail -1 | awk '{print $4}')"

3.2. Chaves SSH e known_hosts#

Certifique-se de que seu chaveiro SSH local está carregado e que o host remoto possui sua chave pública cadastrada para evitar timeouts causados por prompts interativos:

# Listar chaves SSH ativas no agente de autenticação
ssh-add -l

# Verificar se a chave pública do host remoto já está registrada no known_hosts
ssh-keygen -F remote-ip

3.3. Sincronismo seguro e validação criptográfica (checksum)#

Para transferência segura, use chaves criptográficas fortes. Após o envio da imagem, é imperativo rodar uma verificação criptográfica com o algoritmo SHA-256 para assegurar que nenhum bit foi corrompido em trânsito:

# Gerar hash SHA-256 local
sha256sum backup_ambiente.tar

# Gerar hash SHA-256 remoto
ssh user@remote-ip "sha256sum ~/backup_ambiente.tar"

Os hashes gerados em ambos os lados devem coincidir exatamente.

4. A estratégia de mestre: o "jump server" (relay stratagem)#

Como profissional de infraestrutura, percebi que não adiantava lutar contra a rota física direta. A solução foi aplicar um Relay usando uma VM intermediária na Oracle Cloud localizada em São Paulo (Vinhedo).

A Lógica da Tabela de Roteamento Humana:

1. Local → Oracle (São Paulo): Conexão via PTT/IX.BR. Rota doméstica, latência baixíssima, aproveitamento de 100% da minha banda de upload.
2. Oracle → OVH (Canadá): Comunicação via Backbone Tier 1. A Oracle e a OVH possuem peering direto em grandes points of presence nos EUA, permitindo transferências em velocidades de centenas de Megabits por segundo.

Execução: Subi o arquivo para a Oracle em 10 minutos, e da Oracle para a OVH em menos de 2 minutos.

5. Restaurando o ambiente no destino (cloud)#

Com o .tar finalmente na VM final, o processo de reidratação do container foi executado seguindo verificações de permissões e infraestrutura de rede.

5.1. Verificação de permissões do arquivo#

Antes de rodar a importação, valide se o arquivo possui as permissões corretas para que o daemon do Podman consiga realizar a leitura lógica dele (especialmente em ambientes rootless):

# Verificar ownership e permissões
ssh user@remote-ip "ls -la ~/backup_ambiente.tar"

# Inspecionar detalhes de ownership detalhados
ssh user@remote-ip "stat ~/backup_ambiente.tar"

Se necessário, ajuste o ownership para o usuário que executará o Podman rootless.

5.2. Reidratação da imagem e criação do container#

Com o arquivo validado, executamos a carga lógica da imagem no registro do destino:

# Importar a imagem para o Podman remoto
podman load -i backup_ambiente.tar

Após o carregamento, valide se a imagem foi devidamente registrada e se suas variáveis de ambiente originais foram preservadas:

# Verificar imagem importada no destino
podman images | grep kali-cloud-image

# Inspecionar variáveis de ambiente e metadados da imagem importada
podman image inspect localhost/kali-cloud-image | jq '.[0].Config.Env'

Crie o container usando o Distrobox:

# Gerar a nova Box no Distrobox no destino
distrobox create --name kali-prod --image localhost/kali-cloud-image

5.3. Verificação de permissões e infraestrutura de rede no destino#

Containers rootless do Podman dependem da correta configuração de namespaces de usuário e firewalls. Valide a infraestrutura de rede no destino antes de subir serviços complexos:

# Verificar interfaces de rede disponíveis no host destino
ssh user@remote-ip "ip addr show"

# Verificar tabela de rotas do host
ssh user@remote-ip "ip route show"

# Listar regras de firewall ativas no host (iptables ou firewalld)
ssh user@remote-ip "sudo iptables -L -n -v"

# Verificar portas em escuta para garantir que serviços expostos não sofram conflito
ssh user@remote-ip "ss -lntp"

6. Verificação pós-migração e validação do container#

Após criar e iniciar o container, é mandatório rodar um roteiro de testes detalhado dentro da box para garantir o seu pleno funcionamento.

6.1. Roteiro de validação do status interno#

Acesse o container via Distrobox e confirme os parâmetros de identidade e integridade de arquivos:

# Verificar se o container inicia corretamente e expõe o usuário correto
distrobox enter kali-prod -- whoami

# Validar se binários essenciais e ferramentas de diagnóstico continuam acessíveis
distrobox enter kali-prod -- bash -c "which python3 && which git && which curl && which nmap"

# Verificar se as variáveis e aliases do .bashrc foram preservados
distrobox enter kali-prod -- cat ~/.bashrc | head -10

# Validar a presença e ownership de arquivos dotfiles mapeados na home
distrobox enter kali-prod -- ls -la ~/

6.2. Testes de rede e carga de pacotes interna#

Valide a integridade da comunicação externa e a quantidade de pacotes do sistema:

# Testar conectividade de internet a partir de dentro do container
distrobox enter kali-prod -- curl -I https://google.com

# Verificar a contagem de pacotes instalados para confirmar que o SO não sofreu perda de libs
distrobox enter kali-prod -- dpkg -l | wc -l

Checklist: migrar Distrobox local → cloud#

1. Pré-migração#

• [ ] Verificar versão e compatibilidade do Podman local e remoto (podman --version).
• [ ] Verificar espaço em disco local e no destino (df -h).
• [ ] Validar a integridade da imagem local no repositório (podman images).
• [ ] Realizar backup dos dotfiles e projetos locais excluindo caches desnecessários.

2. Exportação e empacotamento#

• [ ] Commitar o container: podman commit CONTAINER IMAGE.
• [ ] Salvar imagem no arquivo tarball: podman save localhost/IMAGE -o backup.tar.
• [ ] Validar o tamanho e estrutura física do tarball (tar -tvf backup.tar).

3. Conectividade e latência#

• [ ] Medir a latência del link doméstico até o servidor destino com ping e mtr.
• [ ] Verificar a largura de banda disponível via iperf3.
• [ ] Executar teste físico preliminar de velocidade de canal.

4. Transferência segura#

• [ ] Validar chaves SSH carregadas no agente e host no known_hosts.
• [ ] Executar a transferência via rsync ou pipe SSH compactado.
• [ ] Verificar integridade criptográfica pós-transferência via hash SHA-256 (sha256sum).

5. Importação e rehidratação#

• [ ] Verificar propriedade e permissões de leitura do tarball no destino.
• [ ] Carregar imagem no Podman de destino: podman load -i backup.tar.
• [ ] Validar metadados e configuração interna da imagem carregada.
• [ ] Criar a nova box com distrobox create.

6. Validação pós-migração#

• [ ] Testar acesso inicial: distrobox enter NAME -- whoami.
• [ ] Verificar existência e funcionamento dos binários cruciais.
• [ ] Validar integridade e replicação de dotfiles na home do destino.
• [ ] Validar conectividade de rede interna e externa do container.

Matriz de riscos e resolução de problemas (troubleshooting)#

Lições de SRE para o seu playbook#

• Sincronização da Home: Lembre-se: o Distrobox mapeia a sua /home. A imagem exportada contém os binários e o SO, mas não os seus arquivos pessoais. Usei um rsync separado para os dotfiles e pastas de projetos.
• Topologia de Rede Importa: Às vezes, o caminho mais rápido entre dois pontos não é uma linha reta, mas uma triangulação entre provedores de nuvem que possuem roteamento BGP otimizado.
• Ferramental de Diagnóstico: Nunca ignore o pv (Pipe Viewer) e o iperf3. Eles são os seus olhos em problemas de transferência de grandes volumes.

Agora meu ambiente de trabalho está 100% cloud-based, acessível via SSH de qualquer lugar, com o processamento pesado ocorrendo fora do meu hardware local.

Veja também

Infraestrutura Rodando fastpanel e aaPanel no Podman (Rocky Linux): o pesadelo do UID mapping e soluções reais

Infraestrutura O Dia em que o Python 3.10 "quebrou" meu aaPanel no Podman (e como resolvi)

Infraestrutura Mão no barro: o guia de sobrevivência para transição de filtros anti-spam e validação de infra

Este post está licenciado sob CC BY-NC.