No ecossistema de alta disponibilidade que suportamos na Nuvem Online, a eficiência na distribuição de imagens de container é um pilar crítico para reduzir latência em pipelines de CI/CD e otimizar custos operacionais. O recurso de Artifact Cache do Azure Container Registry (ACR) é uma ferramenta poderosa para mitigar a dependência de registries upstream, mas seu comportamento em cenários de multi-arch images gera dúvidas constantes em times de Operações e DevOps.
O que é o Artifact Cache?
O Artifact Cache atua como um proxy pull-through. Ao configurar uma regra de cache, o cluster ou servidor não aponta diretamente para o registry externo, mas sim para o seu endpoint no ACR. Quando a imagem não está presente no cache local, o ACR busca o artefato no upstream, entrega ao cliente e, simultaneamente, dispara um job assíncrono para persistir o conteúdo localmente. Entender que esse processo é um pull-through proxy — e não um simples redirecionamento — é fundamental para garantir a estabilidade e previsibilidade de seus deployments.
Comportamento em Imagens Multi-Arch
Ao lidar com manifest lists (ou OCI image indexes), muitas equipes questionam se o ACR baixa todas as arquiteturas disponíveis. A resposta curta é: o ACR realiza uma "cópia de fechamento parcial". Ele armazena o manifest list (o índice), mas copia para o armazenamento local apenas o manifesto da plataforma que foi explicitamente requisitada pelo cliente.
Isso evita o desperdício de espaço em disco e, consequentemente, a cobrança desnecessária de armazenamento para arquiteturas que sua infraestrutura nunca utilizará.
Monitorando via Webhooks
Para equipes que trabalham com infraestrutura como código (laC) e precisam de garantias de que imagens estão "quentes" no cache, o uso de push webhooks é a estratégia técnica recomendada. Um ponto de atenção: o ACR emite eventos push quando a cópia assíncrona é finalizada.
Para uma pull única de um manifesto multi-arch, você verá três eventos:
- Manifest List (Tagged): O registro que aponta para as arquiteturas.
- Manifest List (Untagged): A mesma estrutura, garantindo a integridade do índice.
- Manifest Específico da Arquitetura: Apenas a camada (ex:
linux/amd64) que foi requisitada.
O que ignorar? Não espere webhooks separados para cada blob ou layer da imagem. O ACR notificará apenas o final do processo por digest/tag.
Consequências Práticas para o seu Time
- Custo e Armazenamento: Como apenas o manifesto e o índice são armazenados inicialmente, o custo de armazenamento só será impactado conforme diferentes arquiteturas forem requisitadas.
- Latência de Implantação: Se você depende de uma arquitetura específica (ex:
arm64) que nunca foi requisitada para o seu ACR, o primeiro pull de um deployment ainda passará pelo processo de proxy para o upstream. Considere fazer um pre-warming do seu cache em ambientes críticos. - Orquestração: Não assuma que os eventos chegam em ordem. Seu handler de webhook deve ser idempotente e capaz de processar os eventos sem depender de uma sequência cronológica rígida.
Para cenários de grande escala ou ambientes de missão crítica, a gestão cuidadosa de artifacts previne gargalos operacionais e reduz o risco de downtime em situações de interrupção temporária dos registries upstream.
Artigo originalmente publicado em Azure Updates - Latest from Azure Charts.
