Cloud Server para Docker Registry privado seguro

Resposta direta

Um Cloud Server para Docker Registry privado é uma boa escolha quando a equipe precisa controlar onde as imagens ficam armazenadas, quem pode fazer push e pull, como os tokens são gerenciados e qual política de retenção será aplicada. Para um ambiente pequeno em produção, comece com 2 vCPUs, 4 GB de RAM, 80 a 160 GB de SSD ou NVMe, TLS obrigatório, autenticação por htpasswd ou integração com um proxy, firewall permitindo apenas 443 e SSH restrito, além de backup testado. O ponto crítico não é só instalar o registry. É planejar storage persistente, limpeza de camadas antigas, logs, monitoramento e integração segura com CI/CD, porque pipelines podem gerar dezenas de tags por dia e consumir disco rápido.

Resumo rápido

• Um Docker Registry privado reduz dependência de registries públicos e dá controle sobre imagens internas, tags e permissões.
• Para produção básica, use pelo menos 2 vCPUs, 4 GB de RAM e 80 GB de disco persistente, com margem para crescimento.
• TLS não é opcional. Clientes Docker modernos esperam HTTPS confiável para push e pull fora de ambientes locais.
• Autenticação simples com htpasswd funciona em times pequenos, mas equipes maiores devem considerar tokens, proxy reverso ou registry integrado a uma plataforma.
• O maior gargalo costuma ser disco e rede, não CPU. Imagens grandes e pipelines paralelos fazem o consumo subir rápido.
• Backups precisam incluir dados do registry e configuração, mas também devem ser testados com restore em outro servidor.
• Integração com CI/CD deve usar secrets do provedor, tokens com menor privilégio possível e rotação periódica.

Quando faz sentido hospedar um Docker Registry privado

Hospedar um Docker Registry privado faz sentido quando as imagens da sua aplicação não devem depender apenas de um serviço público ou quando a empresa precisa manter controle operacional sobre artefatos de build. Em projetos simples, publicar imagens no Docker Hub, GitHub Container Registry ou GitLab Container Registry pode resolver bem. O cenário muda quando existem imagens internas com dependências privadas, builds frequentes, políticas de compliance, restrição de acesso por equipe ou necessidade de manter cópias próximas dos servidores de produção.

Pense em uma equipe que mantém cinco microsserviços, cada um com uma imagem base de 900 MB e três tags por deploy, como staging, release candidate e produção. Se o pipeline roda 20 vezes por dia, o volume acumulado cresce rapidamente, principalmente porque camadas antigas continuam ocupando espaço até a limpeza ser executada. Um registry privado em Cloud Server permite definir retenção, controlar tags, limitar quem publica imagens e posicionar o serviço perto dos runners ou dos servidores de deploy.

O que muda em relação ao Docker Hub

A principal diferença é governança. Em um registry próprio, você define autenticação, domínio, certificado TLS, política de backup, retenção e limites de acesso. Também evita depender de rate limits de registries públicos em ambientes de CI/CD intensivo. Isso é útil quando vários runners executam pull da mesma imagem base durante o dia. Se a infraestrutura já usa Docker de forma ampla, vale complementar esta leitura com o guia de infraestrutura para Docker em VPS, porque muitos critérios de CPU, RAM, disco e rede continuam parecidos.

VPS, Cloud Server e registry em produção

Uma VPS tradicional pode hospedar um registry, mas um Cloud Server costuma ser mais flexível para produção porque facilita upgrade de recursos, troca de disco, snapshots e automação via API, dependendo do provedor e do plano. Não confunda isso com garantia automática de alta disponibilidade. Um único Cloud Server ainda é um ponto único de falha. Para times pequenos, esse desenho pode ser aceitável se houver backup e restore documentados. Para ambientes críticos, o registry deve entrar em uma arquitetura com storage externo, réplica ou solução gerenciada.

Arquitetura recomendada em Cloud Server

A arquitetura mais simples e funcional combina quatro peças: Docker Registry oficial, proxy reverso, volume persistente e mecanismo de autenticação. O registry escuta internamente, por exemplo na porta 5000, enquanto Nginx, Caddy ou Traefik expõe o serviço em HTTPS no domínio registry.exemplo.com. Essa separação facilita a renovação de certificados, a aplicação de cabeçalhos, limites de upload e logs de acesso. Em produção, evite expor a porta 5000 diretamente para a internet.

Um desenho comum usa o registry em container, Nginx como proxy e um diretório montado em /var/lib/registry para armazenar blobs, manifests e camadas. Em Cloud Server pequeno, o disco pode ser local, desde que seja persistente e esteja incluído no plano de backup. Em ambientes maiores, considere object storage compatível com S3 quando o volume de imagens crescer ou quando você precisar separar computação de armazenamento. A documentação oficial do Docker Registry suporta diferentes backends, mas cada opção muda custo, latência e complexidade.

Componentes essenciais

Uma implantação segura precisa de DNS apontando para o Cloud Server, certificado TLS válido, firewall ativo, autenticação, logs e backup. Em Ubuntu, por exemplo, a base pode incluir Docker Engine, Docker Compose Plugin, UFW, fail2ban e um usuário administrativo sem login por senha. O SSH deve aceitar chave pública, preferencialmente em uma porta padrão protegida por firewall e com acesso restrito por IP quando possível.

Na prática, a pilha mínima fica assim: registry privado em container, Nginx ou Caddy na frente, volume persistente em disco, arquivo htpasswd montado como secret ou volume somente leitura e logs enviados para journald ou um coletor externo. Se a equipe já usa runners próprios, o mesmo padrão de isolamento visto em GitLab Runner e CI/CD em VPS ajuda a evitar que builds e registry disputem recursos no mesmo servidor sem controle.

Separação entre registry, proxy e storage

Não coloque tudo no mesmo diretório sem planejamento. A configuração do proxy, as credenciais e os dados do registry têm ciclos de vida diferentes. Um backup de configuração deve ser pequeno, versionado e restaurável rapidamente. Já o diretório de blobs pode ter centenas de gigabytes e exigir outra estratégia. Essa separação evita restaurar 300 GB de imagens só para recuperar um arquivo Nginx quebrado. Também reduz o risco de apagar dados permanentes durante uma atualização de container.

Dimensionamento de CPU, RAM, disco e rede

O Docker Registry não costuma ser pesado em CPU. Ele recebe camadas, valida manifests, grava objetos e entrega conteúdo para clientes Docker. O consumo cresce quando há muitos pushes paralelos, compactação em trânsito, TLS no proxy e muitos pulls simultâneos. Para um time pequeno, 2 vCPUs e 4 GB de RAM são suficientes na maioria dos casos. Para pipelines com 10 a 30 jobs paralelos, comece a olhar para 4 vCPUs, 8 GB de RAM e disco com bom I/O.

Disco é o item que mais causa surpresa. Uma imagem final de 700 MB pode compartilhar camadas com outras tags, mas nem sempre isso reduz tanto quanto esperado. Builds mudam dependências, mudam layers e mantêm tags antigas. Um projeto com 8 serviços, imagens médias de 1 GB e 30 tags retidas por serviço pode ocupar algo entre 120 GB e 250 GB, dependendo do reaproveitamento de camadas. Por isso, um registry de produção raramente deveria começar com menos de 80 GB úteis.

Estimando espaço para imagens

Uma conta prática ajuda. Pegue o tamanho médio da imagem comprimida, multiplique pelo número de serviços e pelo número de tags que serão preservadas. Depois aplique uma margem de 40% a 100% para camadas não compartilhadas, uploads temporários e crescimento. Se você tem 6 serviços, imagens de 800 MB e 20 tags por serviço, a conta bruta dá 96 GB. Com margem de 50%, planeje pelo menos 144 GB. Nesse caso, um disco de 160 GB é o mínimo confortável, enquanto 240 GB dá mais espaço para retenção e rollback.

Também pense em rede. Um runner que faz pull de uma imagem de 1,2 GB em cada job pode consumir bastante tráfego diário. Dez jobs por hora, durante 8 horas, já movimentam 96 GB só em pull se não houver cache local. Quando o registry fica próximo dos runners, a latência melhora e o deploy fica mais previsível. Se os runners estão em outro provedor ou região, teste throughput real antes de migrar imagens críticas.

I/O, latência e tráfego de pipelines

SSD ou NVMe ajuda mais quando há muitos pushes, pulls e garbage collection. Mas disco rápido não corrige imagem mal construída. Dockerfiles com camadas grandes, cache desperdiçado e dependências copiadas antes da hora aumentam tráfego e storage. Um exemplo simples: copiar package.json antes do restante do código em uma aplicação Node.js permite reaproveitar a camada de npm install com mais frequência. Em pipelines com GitHub Actions, uma opção é aproximar runner e registry, tema que também aparece no guia de Cloud Server para GitHub Actions self-hosted runner.

Instalação segura com TLS e autenticação

A instalação básica pode ser feita com Docker Compose, mas a configuração precisa nascer segura. Use um domínio próprio, como registry.empresa.com.br, apontado para o IP do Cloud Server. Em seguida, instale Docker, configure firewall e exponha apenas 80 e 443 temporariamente para emissão do certificado, além do SSH restrito. Depois que o HTTPS estiver ativo, a porta 80 pode redirecionar para 443 ou ficar disponível apenas para renovação automática.

Um Compose simples teria um serviço registry usando a imagem registry:2, volume persistente em /var/lib/registry e variáveis de autenticação apontando para htpasswd. O proxy reverso recebe conexões externas e encaminha para registry:5000 na rede interna do Docker. Com Nginx, ajuste client_max_body_size para um valor compatível com suas imagens, como 2g ou 5g. Sem isso, pushes grandes podem falhar com erro 413. Com Caddy, a emissão de TLS fica mais simples, mas ainda é preciso configurar autenticação e limites.

Configuração base com Docker Compose

Um exemplo de estrutura segura é manter os arquivos em /opt/registry, com subdiretórios config, auth e data. O arquivo auth/htpasswd deve ser gerado com bcrypt. Um comando comum é usar htpasswd -Bbn usuario senha, mas a senha não deve ficar registrada em histórico de shell. Prefira gerar em terminal seguro, usar variável temporária ou ferramenta de secret management. O arquivo final pode ser montado somente leitura no container.

O registry deve receber REGISTRY_AUTH=htpasswd, REGISTRY_AUTH_HTPASSWD_REALM=Registry Realm e REGISTRY_AUTH_HTPASSWD_PATH=/auth/htpasswd. Para storage local, REGISTRY_STORAGE_FILESYSTEM_ROOTDIRECTORY=/var/lib/registry resolve. Em produção, também configure REGISTRY_STORAGE_DELETE_ENABLED=true se pretende executar garbage collection após remover tags. Sem essa opção, limpar manifests fica mais difícil e o disco pode continuar crescendo.

TLS, htpasswd e firewall

No cliente, o login deve funcionar com docker login registry.empresa.com.br. Se o certificado TLS for válido, não será necessário marcar o registry como insecure. Evite registries inseguros fora de laboratório, porque credenciais e manifests podem trafegar de forma exposta ou depender de exceções locais difíceis de auditar. No firewall, libere 443 para a internet, 22 apenas para IPs administrativos quando possível e bloqueie 5000 externamente. Logs de autenticação e acesso devem ser mantidos por pelo menos alguns dias para investigação de falhas em pipelines.

Storage persistente, retenção e backups

O storage é onde um registry privado deixa de ser só um container e passa a ser infraestrutura de verdade. Se você remover o container registry e perder o volume, perde imagens, tags e histórico operacional. Por isso, monte o diretório de dados fora do ciclo de vida do container, com permissões previsíveis e backup separado. Em Linux, um padrão simples é /srv/registry/data para blobs e /srv/registry/config para arquivos pequenos. Se usar disco adicional, monte por UUID no /etc/fstab para evitar troca de ordem de dispositivos após reboot.

A retenção precisa ser definida antes do problema aparecer. Times que publicam toda branch como tag podem gerar centenas de imagens por semana. Uma política realista mantém as últimas 10 tags por serviço em desenvolvimento, as últimas 20 em staging e todas as versões promovidas para produção por um período maior, como 90 ou 180 dias. O Docker Registry puro não oferece uma interface completa de lifecycle como alguns registries gerenciados, então a limpeza costuma exigir scripts, ferramentas externas ou convenções rígidas de tags.

Garbage collection e limpeza de tags

Garbage collection no registry oficial não é o mesmo que apagar tag. Primeiro você remove referências aos manifests, depois executa registry garbage-collect para limpar blobs sem uso. Em muitos ambientes, o registry precisa ficar em modo somente leitura durante a coleta para evitar inconsistência enquanto pushes acontecem. Uma janela semanal de manutenção, por exemplo aos domingos de madrugada, pode ser suficiente para times pequenos. Em ambientes com deploy contínuo, avalie uma solução com retenção nativa ou planeje janelas curtas e comunicadas.

Monitoramento de disco é obrigatório. Configure alertas em 70%, 80% e 90% de uso. Em 70%, revise retenção. Em 80%, execute limpeza. Em 90%, pare pushes não críticos e aumente disco ou mova storage. Um registry sem espaço pode deixar builds quebrados, deployments travados e imagens parcialmente enviadas. O sintoma comum é pipeline falhar no docker push, mas a causa real aparece no servidor como no space left on device.

Snapshots, cópias externas e teste de restore

Snapshots do Cloud Server são úteis, mas não substituem backup lógico e teste de restauração. Um snapshot captura o estado do disco em um momento, enquanto uma cópia externa protege contra erro operacional, exclusão acidental e falha na conta do provedor. Para um registry pequeno, um rsync diário para outro servidor ou um backup compactado incremental pode ser suficiente. Para volumes maiores, object storage com versionamento e retenção pode ser mais adequado. O teste final é simples: subir outro servidor, restaurar configuração e dados, executar docker pull de uma imagem antiga e confirmar digest.

Integração com CI/CD sem vazar credenciais

A integração com CI/CD precisa tratar credenciais como artefatos sensíveis. Nunca grave usuário e senha do registry em Dockerfile, repositório, arquivo .env versionado ou script aberto. Use secrets do GitLab CI, GitHub Actions, Jenkins ou da plataforma escolhida. O pipeline deve executar docker login usando senha via stdin, por exemplo com echo do secret direcionado para docker login —password-stdin. Isso reduz exposição em logs e evita que a senha apareça em argumentos de processo.

Para GitLab CI, um fluxo comum cria variáveis REGISTRY_USER e REGISTRY_PASSWORD protegidas e mascaradas. O job de build faz login, constrói a imagem com tag baseada no commit curto e publica também uma tag semântica quando há release. Para GitHub Actions, use secrets do repositório ou da organização, evitando secrets por ambiente quando a permissão precisa ser mais restrita. Em runners self-hosted, cuidado adicional: o cache local do Docker pode manter imagens e camadas após o job.

GitLab CI, GitHub Actions e runners próprios

Um exemplo prático: a branch main publica registry.empresa.com.br/api:main-SHA, enquanto uma tag v1.8.2 publica registry.empresa.com.br/api:1.8.2 e registry.empresa.com.br/api:stable. Isso facilita rollback sem depender de latest, que costuma gerar ambiguidade. Em GitLab Runner, limite concorrência se o Cloud Server do registry for pequeno. Cinco jobs enviando imagens de 1 GB ao mesmo tempo podem saturar rede e disco. Em GitHub Actions self-hosted, alinhe o runner ao mesmo datacenter quando possível para reduzir latência e tráfego externo.

Também vale separar credenciais por função. Um token ou usuário usado por pipeline de build precisa de push para projetos específicos. Servidores de produção normalmente só precisam de pull. Se todos usam a mesma conta admin, qualquer vazamento dá controle completo sobre o registry. Mesmo com htpasswd simples, você pode criar usuários diferentes, como ci-push, prod-pull e dev-pull. Não é perfeito como RBAC avançado, mas já melhora auditoria e resposta a incidentes.

Boas práticas para tokens e permissões

Rotacione credenciais em ciclos previsíveis, como a cada 90 dias, e imediatamente após saída de colaborador com acesso. Proteja secrets em branches. No GitLab, use variáveis protegidas para impedir uso em branches não protegidas. No GitHub, revise permissões de ambientes e aprove aprovações manuais para deploys sensíveis. Logs do proxy também ajudam a identificar puxadas incomuns de imagens, tentativas de login e clientes desatualizados. Não publique credenciais nos exemplos internos da equipe, nem em documentação copiada para tickets.

Tabela comparativa de perfis de implantação

A escolha do modelo depende mais do volume de imagens, da criticidade do deploy e da maturidade operacional do que do nome do produto. Um registry privado para laboratório pode rodar em uma instância simples. Um registry usado por produção, com dezenas de pipelines e vários servidores fazendo pull, precisa de margem de disco, backup confiável e plano de restauração. A tabela abaixo resume perfis comuns, usando números conservadores para planejamento inicial.

Perfil de uso	Recursos iniciais sugeridos	Storage e retenção	Segurança mínima	Quando evoluir
Laboratório ou dev solo	1 a 2 vCPUs, 2 GB RAM, 40 a 80 GB SSD	Retenção manual, poucas tags, backup semanal	TLS, htpasswd, firewall 443	Ao passar de 50 GB ou virar dependência de deploy
Time pequeno com CI/CD	2 vCPUs, 4 GB RAM, 120 a 160 GB SSD ou NVMe	Retenção por ambiente, limpeza semanal, backup diário	TLS, usuários separados, SSH por chave, logs	Ao ter mais de 10 jobs paralelos ou 200 GB de imagens
Produção com múltiplos serviços	4 vCPUs, 8 GB RAM, 240 GB ou storage externo	Política formal, alertas de disco, restore testado	Pull e push separados, rotação de secrets, monitoramento	Ao exigir alta disponibilidade ou compliance rígido
Ambiente crítico ou regulado	4 a 8 vCPUs, 8 a 16 GB RAM, object storage ou solução gerenciada	Lifecycle, versionamento, auditoria e cópia externa	RBAC, logs centralizados, MFA no painel do provedor	Quando indisponibilidade do registry bloqueia receita

Provedores como DigitalOcean, Vultr, Linode, AWS Lightsail, Hetzner, Contabo e LetsCloud podem aparecer no radar, mas preço, região, tipo de disco, tráfego incluído, snapshots e backups variam por plano e data. Esses dados precisam ser conferidos nas páginas oficiais antes de publicar qualquer comparativo de preço. Para público brasileiro, latência e cobrança em moeda local podem pesar na decisão, mas não substituem análise de backup, suporte, limites de rede e histórico operacional.

Recomendações por perfil

Dev solo

Para um desenvolvedor solo, o melhor começo é manter a arquitetura simples e previsível. Um Cloud Server com 1 ou 2 vCPUs, 2 GB de RAM e 40 a 80 GB de SSD atende testes, imagens pessoais, projetos pequenos e ambientes de homologação. Use TLS desde o primeiro dia, mesmo que só você acesse. Isso evita criar exceções inseguras no Docker daemon local e facilita convidar outra pessoa no futuro. Configure htpasswd com um usuário específico, faça backup semanal e defina um limite de retenção, por exemplo manter as últimas 10 tags por projeto. Se o registry virar parte do deploy de produção, suba para 4 GB de RAM e aumente o disco antes que o crescimento vire emergência.

Time pequeno

Um time pequeno com CI/CD deve tratar o registry como serviço compartilhado. A recomendação inicial é 2 vCPUs, 4 GB de RAM e 120 a 160 GB de disco, com alertas de uso e backup diário. Separe usuários de push e pull, use secrets protegidos no CI e mantenha tags previsíveis por commit, branch e release. Evite latest como única referência de deploy. O time também deve documentar como restaurar o registry em outro servidor, incluindo DNS, certificado, Compose, htpasswd e diretório de dados. Se os builds são frequentes, aproxime runners e registry na mesma região para reduzir tempo de push e pull. Essa decisão costuma dar mais resultado do que aumentar CPU sem diagnóstico.

Produção com múltiplos serviços

Para produção com múltiplos serviços, comece em 4 vCPUs, 8 GB de RAM e pelo menos 240 GB de storage, ou use object storage quando o volume crescer com rapidez. A equipe precisa de política clara de retenção, janela de garbage collection, monitoramento de disco, logs centralizados e restore testado. Também faz sentido separar o registry de outros workloads, como banco de dados, aplicações web e runners pesados. Se o registry cair, deploys e rollbacks podem ser afetados. Por isso, defina um plano B, como cache local das imagens críticas nos servidores ou réplica em outra região. Em empresas com compliance, prefira soluções com RBAC, auditoria e lifecycle nativo, ou valide se o registry oficial atende aos requisitos internos.

Equipe com exigência de auditoria

Quando auditoria entra no jogo, a pergunta deixa de ser apenas qual Cloud Server aguenta o registry. A equipe precisa provar quem publicou imagem, quando, a partir de qual pipeline e com qual digest. O Docker Registry oficial pode compor essa arquitetura, mas talvez precise de proxy com logs detalhados, integração com identity provider, assinatura de imagens e ferramentas como Docker Content Trust, Cosign ou políticas no Kubernetes. Nesse perfil, não economize em observabilidade. Registre acessos, proteja painel do provedor com MFA, revise permissões de CI/CD e teste revogação de usuário. O custo de uma credencial vazada é maior do que o custo de configurar permissões direito desde o início.