Registry costuma ser tratado como detalhe de infraestrutura: um lugar para guardar imagens de container, resolvido com a opção padrão da plataforma de CI. Funciona por um bom tempo — até o dia em que o build falha porque o registry público aplicou limite de taxa, ou o rollback é impossível porque a imagem foi apagada pela política de limpeza, ou uma dependência foi removida da origem e o pipeline inteiro para.
Esses três incidentes têm a mesma solução, e ela é barata comparada ao que evita.
Os três problemas que o registry próprio resolve
Limite de taxa e disponibilidade. Ambientes que baixam imagens públicas a cada execução de pipeline esbarram em limites e passam a falhar de forma intermitente e aparentemente aleatória — o tipo de falha que consome mais tempo de diagnóstico do que qualquer outra. E quando o registry público está indisponível, o seu deploy também está.
Dependência que desaparece. Pacote removido da origem, versão apagada, projeto descontinuado. Não é hipotético — já aconteceu em escala suficiente para quebrar builds no mundo inteiro.
Rollback impossível. Política de retenção agressiva apagando a imagem para a qual você precisaria voltar. É a causa mais evitável de reversão frustrada.
O registry como espelho
O primeiro uso, e o de maior retorno imediato: configurar o seu registry como proxy com cache dos repositórios públicos que você consome.
Como funciona: o pipeline pede uma imagem ao seu registry; se ele não a tem, busca na origem, guarda e entrega. Nas próximas vezes, entrega do cache.
O que isso resolve de uma vez:
- Limite de taxa, porque a origem é consultada uma vez por artefato.
- Velocidade, porque o cache é local.
- Disponibilidade, porque a indisponibilidade da origem não para você.
- Desaparecimento, porque o que passou pelo cache continua lá.
Vale fazer isso para tudo que você consome: imagens de container, pacotes da linguagem, pacotes do sistema operacional, gráficos de implantação. Cada ecossistema que você não espelha é uma dependência externa no caminho crítico do seu deploy.
Um cuidado: cache não é backup. O repositório de proxy precisa ter a própria retenção e o próprio backup, ou você reintroduz o problema.
Promoção entre ambientes
O padrão que separa operação madura de improviso: construa uma vez, promova o mesmo artefato.
O erro comum é reconstruir a imagem para cada ambiente. Isso significa que a imagem testada em homologação não é a imagem que vai para produção — bases podem ter mudado, dependências transitivas podem ter sido resolvidas diferente, e você perdeu a garantia que o teste deveria dar.
O desenho correto usa repositórios por estágio no mesmo registry:
| Repositório | Conteúdo | Retenção |
|---|---|---|
dev | Toda construção de branch | Dias |
staging | Promovido após aprovação no pipeline | Semanas |
prod | Promovido após validação em homologação | Longa, com as últimas versões preservadas |
A promoção é uma cópia ou uma nova referência ao mesmo conteúdo — não uma nova construção. E o registro de qual artefato foi promovido, quando e por quem é parte da auditoria.
Retenção: o equilíbrio que preserva o rollback
Registry cresce rápido e a limpeza é necessária. Mas política agressiva demais destrói o caminho de volta.
Uma política que funciona:
- Construções de desenvolvimento: 7 a 14 dias.
- Homologação: 30 a 60 dias.
- Produção: preservar sempre as N últimas versões — um número que cubra confortavelmente o histórico de rollback —, além de todas as versões marcadas como release.
- Nunca apagar a versão que está em execução em algum ambiente. Se o registry consegue consultar o que está implantado, use isso; se não, marque explicitamente.
- Limpar camadas órfãs periodicamente, que é onde o espaço realmente vai.
E uma regra que evita o incidente mais bobo: verifique a política de retenção sempre que ela for alterada, com um teste de que a imagem anterior à atual ainda existe. É uma verificação de trinta segundos que já salvou muita gente.
Imutabilidade de tag
Tag sobrescrevível significa que a imagem rodando em produção pode mudar sem novo deploy — alguém publica de novo com a mesma tag, o próximo pod que subir pega outra coisa, e você tem um ambiente com duas versões diferentes sob o mesmo nome.
O que fazer:
- Tags de versão imutáveis nos repositórios de produção. Publicada, não muda.
- Referência por digest nos manifestos de implantação, que é a garantia criptográfica de que o conteúdo é exatamente aquele.
- Tags móveis (
latest,stable) apenas como conveniência de desenvolvimento, nunca em produção.
Segurança e cadeia de suprimentos
O registry é o ponto natural para aplicar controle, porque tudo passa por ele:
- Autenticação e autorização por repositório. Quem publica não é quem consome. O pipeline publica; o cluster só lê.
- Credenciais de leitura separadas por ambiente, revogáveis individualmente.
- Scan automático na publicação, com resultado visível e bloqueio por severidade em repositórios de produção.
- Scan periódico do que já está armazenado, porque vulnerabilidade nova aparece em artefato que não mudou.
- Assinatura e atestado de procedência publicados junto do artefato, e verificação obrigatória no momento da execução. Assinar sem verificar é cerimônia.
- SBOM por artefato, que transforma a pergunta "estamos afetados por essa vulnerabilidade?" em uma consulta de minutos.
- Bloqueio de registries não aprovados no cluster, por política de admissão. Sem isso, um manifesto pode puxar imagem de qualquer lugar da internet.
Esse último item é o que fecha o ciclo. Todo o controle no registry é inútil se o cluster aceita imagem de qualquer origem.
Escolher a ferramenta
| Opção | Perfil |
|---|---|
| Registry da plataforma de CI (GitLab, GitHub) | Integração imediata; menos recursos de proxy e de política |
| Harbor | Open source, completo: proxy, replicação, scan, assinatura, política |
| Nexus / Artifactory | Multi-ecossistema: container, pacotes de linguagem e de sistema no mesmo lugar |
| Registry do provedor de nuvem | Bom se você já está lá; aprisionamento e custo de tráfego |
O critério prático: se você só precisa de imagens de container e já usa GitLab ou GitHub, comece por ali. Se precisa espelhar vários ecossistemas de pacotes, uma solução multi-formato paga o esforço. Para quem opera infraestrutura própria e quer controle completo com código aberto, Harbor é a escolha mais frequente.
Alta disponibilidade e recuperação
Registry indisponível para o deploy e, pior, impede a recuperação — um nó que precisa subir um pod não consegue baixar a imagem.
O mínimo:
- Armazenamento redundante por trás do registry.
- Backup dos metadados e do armazenamento, com restauração testada.
- Replicação para um segundo registry, em outro local, para o cenário de perda do principal.
- Cache local nos nós do cluster, que reduz a dependência do registry no dia a dia e ajuda na recuperação.
Vale colocar o registry na mesma conversa de disaster recovery que o resto da infraestrutura. Ele é uma dependência crítica do processo de recuperação e costuma ser esquecido justamente por parecer acessório.
Erros comuns
- Depender de registry público a cada execução de pipeline.
- Não espelhar os ecossistemas de pacotes, só as imagens.
- Tratar o repositório de proxy como se fosse backup.
- Reconstruir a imagem por ambiente em vez de promover a mesma.
- Política de retenção apagando a imagem necessária para reverter.
- Tags sobrescrevíveis em produção.
- Usar tag móvel em manifesto de produção.
- Mesma credencial para publicar e consumir.
- Scan só na publicação, sem varredura periódica do armazenado.
- Assinar e não verificar na execução.
- Não bloquear registries não aprovados no cluster.
- Registry sem backup nem replicação.
- Esquecer o registry no plano de recuperação de desastre.
Onde a Solvefy/Cloud entra
Implantamos e operamos registry de artefatos como parte da esteira: proxy com cache de todos os ecossistemas que você consome, repositórios por estágio com promoção do mesmo artefato, retenção que preserva o caminho de rollback, imutabilidade de tag e referência por digest, scan na publicação e periódico, assinatura com atestado de procedência e verificação obrigatória no cluster, e o registry incluído no plano de recuperação com backup e replicação testados.
Se o registry público cair agora, você consegue fazer deploy? Diagnóstico gratuito, sem compromisso, em solvefy.cloud.
Solvefy/Cloud — Infraestrutura que cresce com você.