Registro de Contêiner do Azure para soluções de IA: ACR Tasks, tags, versionamento e ciclo de vida
Projete uma cadeia privada de imagens para APIs de inferência e serviços de apoio, compile de forma consistente no Azure, automatize reconstruções e implante artefatos rastreáveis e reproduzíveis.
Tempo de estudo sugerido: 70 minutos • Nível intermediário • Reescrita autoral completa com versão resumida de cada tópico e laboratório guiado na CLI do Azure
Por João Ricardo Dutra••Conteúdo autoral completo
1. Por que uma solução de IA precisa de um registro gerenciado
Uma solução de IA real não é apenas um arquivo de modelo. Ela pode reunir de inferência, workers de pré-processamento, tarefas de dados e de monitoramento. Quando cada desenvolvedor compila os contêineres na própria estação, as dependências divergem, o histórico fica impreciso e um pode não reproduzir a imagem que funcionava.
O (ACR) centraliza artefatos privados e permite transferir a compilação para o . O objetivo é controlar o caminho entre código-fonte e Dockerfile, uma imagem rastreável e a implantação no , nos , no ou em outro runtime.
Explicar registros, repositórios, namespaces, artefatos, manifests, camadas, tags e digests.
Compilar e executar imagens com ACR Tasks sem um Docker Engine local.
Escolher referências estáveis, semânticas, exclusivas ou por digest conforme a etapa.
Proteger imagens implantadas e remover conteúdo obsoleto sem interromper a produção.
Resumo do tópico
O registro gerenciado substitui compilações dependentes da estação por uma cadeia centralizada e auditável de imagens para serviços de IA.
2. Capacidades e camadas de serviço do
O ACR é um registro privado gerenciado compatível com Docker Registry e Open Initiative (OCI). Ele armazena imagens, gráficos Helm, assinaturas, listas de materiais de software e outros artefatos OCI. Identidade, funções, rede e políticas permanecem sob controle do ambiente da organização.
Capacidades relevantes para cargas de IA.
Capacidade
Valor arquitetural
privado
Mantém imagens de inferência, pré-processamento e operação no ambiente controlado.
Integração
Fornece imagens diretamente ao ,, e .
Replicação geográfica
Sincroniza conteúdo para regiões escolhidas e atende pelo global; exige Premium.
Compatibilidade OCI
Reúne imagens e artefatos da cadeia de fornecimento no mesmo registro.
Execução na nuvem
ACR Tasks compila, testa, executa e mantém contêineres no .
Basic atende aprendizado e desenvolvimento de menor volume. Standard aumenta armazenamento e taxa de transferência incluídos. Premium acrescenta recursos corporativos, como replicação geográfica e privados, além de limites superiores. A escolha deve considerar volume, taxa de pull e gravação, isolamento de rede e distribuição regional.
O módulo fornecido cita Docker Content Trust como recurso Premium. A orientação vigente da Microsoft informa desativação completa em 31 de março de 2028 e impede nova habilitação desde 31 de maio de 2026; projetos novos devem seguir a transição para o Notary Project.
Resumo do tópico
O ACR combina armazenamento OCI privado, integração com runtimes do , distribuição regional opcional e tarefas de nuvem; recursos avançados de rede e replicação exigem Premium.
3. Hierarquia de registro, repositório, e artefato
O registro é o recurso superior. Seu nome globalmente exclusivo forma o servidor de logon, como contosoinference.azurecr.io. Autenticação, atribuições de função, rede, replicação e políticas gerais são controladas nesse nível.
O repositório reúne artefatos do mesmo nome lógico com tags diferentes. inference-:v1.1.0 e inference-:v1.2.0 pertencem ao repositório inference-. Barras criam namespaces como production/inference-, staging/inference- e ml-team/model-server, facilitando organização, propriedade e permissões por repositório.
O artefato é a imagem, o gráfico ou o objeto OCI armazenado. Ele possui camadas, configuração e manifest. Um artefato pode receber várias tags; cada manifest possui seu próprio digest derivado do conteúdo.
O endereço parte do servidor de logon, seleciona um repositório e termina em uma tag legível ou em um digest de manifest imutável.
Resumo do tópico
O registro controla o serviço, repositórios e namespaces organizam o conteúdo, e artefatos são os objetos efetivamente armazenados e versionados.
4. Tags, camadas, manifests e digests
A tag é um ponteiro legível no formato repositório:tag. Se nenhuma tag for informada, o Docker usa latest. Um mesmo artefato pode receber v1.2.0 e stable, mas tags são mutáveis: enviar novo conteúdo com a mesma tag move o ponteiro.
Imagens são formadas por camadas endereçadas por conteúdo, geralmente criadas por instruções do Dockerfile. O ACR elimina duplicação de camadas idênticas. Assim, imagens de IA que compartilham a mesma base Python ou de aprendizado de máquina reutilizam conteúdo e reduzem armazenamento e downloads.
O manifest enumera camadas e configuração. Seu digest não muda depois da publicação. Por isso, uma referência sha256:… identifica com precisão um manifest e oferece a melhor garantia de que todos os nós de produção executarão os mesmos bytes.
Resumo do tópico
Tags são ponteiros mutáveis; camadas guardam conteúdo reutilizável; o manifest descreve o artefato; e o digest estabelece identidade imutável.
5. Endereçamento e organização de repositórios
O endereçamento por tag é legível e adequado quando o consumidor deve acompanhar uma versão móvel. O endereçamento por digest é mais longo, porém reproduzível. Uma promoção de produção pode conservar uma tag exclusiva para leitura humana e registrar o digest exato para implantação e auditoria.
# Push e pull por tag
docker push myregistry.azurecr.io/inference-api:v1.2.0
docker pull myregistry.azurecr.io/inference-api:v1.2.0
# Pull imutável
docker pull myregistry.azurecr.io/inference-api@sha256:<digest-do-manifest>
Organize namespaces por equipe, ambiente, produto ou ciclo de vida.
Mantenha o registro perto do runtime e use replicação geográfica Premium quando a implantação for realmente multirregional.
Monitore armazenamento, crescimento dos repositórios, latência de pull e limitação de taxa.
Use permissões de menor privilégio baseadas no ; nomes não constituem uma barreira de segurança.
Reduza o tamanho da imagem e ordene o Dockerfile para aproveitar de camadas.
Resumo do tópico
Use tags para intenção legível, digests para reprodução exata, namespaces para organização e políticas de identidade para autorização real.
6. ACR Tasks e compilações consistentes na nuvem
ACR Tasks transfere o ciclo de vida do contêiner das estações para execução gerenciada no . O mesmo ambiente pode compilar imagens Linux, Windows, AMD64, ou ARM64, reduzindo diferenças locais e eliminando a exigência de instalar Docker para iniciar a compilação.
Três cenários de ACR Tasks.
Cenário
Uso
Tarefa rápida
Compilar e enviar uma imagem sob demanda com az acr build.
Tarefa com gatilho
Reagir a código-fonte, imagem base ou temporizador.
Tarefa multietapa
Descrever build, teste, push e comandos em com dependências e condições.
Cada execução gera . Execuções interativas transmitem a saída ao terminal; automações armazenam para consulta. O ACR Tasks pode integrar CI/CD, mas identidade, conectividade privada, credenciais da origem e exposição de dados em continuam sendo responsabilidades de projeto.
O ACR Tasks converte o contexto-fonte em artefato compilado e testado; exclusivos ligam o resultado à execução.
Resumo do tópico
ACR Tasks oferece execução repetível para builds sob demanda, automação acionada por eventos e fluxos multietapa.
7. Tarefas rápidas e contextos de compilação
az acr build empacota o contexto, envia-o ao ACR, executa o Dockerfile no e publica o resultado bem-sucedido. O contexto pode ser um diretório local, repositório do GitHub ou , ou arquivo tar remoto. Use .dockerignore para excluir segredos, resultados de build, ambientes virtuais, conjuntos de dados e arquivos desnecessários.
az acr build --registry myregistry --image inference-api:v1.0.0 .
az acr build --registry myregistry \
--image inference-api:v1.0.0 \
https://github.com/myorg/inference-api.git
A tarefa rápida serve para validar Dockerfile, produzir uma imagem pontual, experimentar nova base ou dependência e compor uma etapa simples de . Ela não substitui uma política de release que registre código, testes, aprovação e evidências de implantação.
Resumo do tópico
A tarefa rápida é o caminho mais curto entre contexto local, Git ou tar e uma imagem compilada na nuvem; o contexto deve ser pequeno e livre de segredos.
8. Gatilhos de código-fonte, imagem base e agenda
O gatilho de origem conecta uma tarefa persistente ao GitHub ou e reage a commits ou pull por . Para fonte privada, use credencial protegida e de escopo mínimo. Não grave de acesso pessoal em repositório, script, ou comando sujeito a diagnóstico; use um fluxo seguro, como o .
O gatilho de imagem base acompanha a imagem referenciada por FROM. Quando , sistema operacional, CUDA, Python ou base interna muda, imagens dependentes podem ser recompiladas. O ACR descobre a dependência durante o build; valide comportamento para origens públicas, privadas e redes restritas.
Gatilhos agendados usam cron para builds noturnos, atualização de patches, testes, manutenção ou limpeza. A agenda fornece cadência, mas não comprova que a imagem está pronta: testes e controles de promoção continuam necessários.
Gatilhos reagem a eventos de código, mudanças na base ou horários; credenciais e releases resultantes ainda exigem menor privilégio, testes e promoção.
9. Fluxos multietapa, variáveis e validação
A tarefa multietapa usa para coordenar build, push e cmd. Etapas podem depender do sucesso anterior, executar em paralelo ou usar condições. Assim é possível compilar, executar testes unitários ou de fumaça em contêiner e somente depois publicar ou promover.
Variáveis como {{.Run.ID}} e {{.Run.Date}} criam tags rastreáveis. az acr run também executa um comando em imagem existente usando /dev/null como contexto, útil para teste de inicialização, inventário de runtime e verificação de ou saúde.
az acr run --registry myregistry \
--cmd 'inference-api:v1.0.0 python --version' \
/dev/null
az acr task logs --registry myregistry --name build-inference-api
Analise e retenha conforme auditoria.
Coloque etapas estáveis antes das cópias de aplicação no Dockerfile para reutilizar .
Use identidades de execução em vez de credenciais incorporadas.
Não coloque segredos em parâmetros que possam aparecer em diagnóstico.
Resumo do tópico
multietapa combina build, teste, push e comandos; variáveis e ligam o artefato à execução que o produziu.
10. Estratégias de tags estáveis e exclusivas
Tags estáveis como 1, 1.2, stable ou latest são reutilizadas. Elas atendem imagens base atualizadas, desenvolvimento ou consumidores que devem receber mudanças. O risco é dois nós solicitarem a mesma tag em horários diferentes e receberem manifests distintos.
Uma tag exclusiva nunca é reutilizada. ID de build, de commit, timestamp UTC e combinações como v1.2.0-build4567-abc123f oferecem rastreabilidade. O isolado não diferencia uma recompilação causada apenas por nova base; de produção devem combiná-lo com ID de execução ou build.
Referência indicada por etapa.
Necessidade
Referência recomendada
Imagem base mantida
Tag estável de major ou minor, seguida de recompilação e validação.
Conveniência em desenvolvimento
Tag móvel quando a mudança é esperada.
Implantação em produção
Tag exclusiva e digest registrado.
Auditoria e
de execução ligados ao código, testes e digest imutável.
Resumo do tópico
Tags estáveis movem intencionalmente; tags exclusivas preservam o histórico. Produção normalmente requer uma tag exclusiva e seu digest.
11. Versionamento semântico e a armadilha de latest
O versionamento semântico comunica compatibilidade por MAJOR.MINOR.: MAJOR muda quando há quebra, MINOR para recurso retrocompatível e para correção retrocompatível ou de segurança. Ele pode coexistir com ponteiros: 1 acompanha 1.x, 1.1 acompanha 1.1.x e 1.1.0 registra uma versão específica.
inference-api:1.0.0
inference-api:1.0.1
inference-api:1.1.0
inference-api:2.0.0
# Tag de produção rastreável
inference-api:v1.2.0-build4567-abc123f
latest é apenas a tag padrão do Docker quando nenhuma é informada; ela não comprova atualidade, qualidade, aprovação ou compatibilidade. Evite-a em produção porque oculta intenção e permite mudança silenciosa. Prefira tag exclusiva explícita ou digest.
A tag pode mudar de manifest; o digest permanece ligado ao mesmo manifest. A política de release deve preservar intenção legível e identidade imutável.
Resumo do tópico
Versões semânticas comunicam compatibilidade, exclusivos fornecem rastreabilidade e latest não deve representar uma implantação de produção.
12. Bloqueio de imagens em produção
Um artefato implantado não deve ser removido ou sobrescrito acidentalmente. Atributos do repositório ACR podem desabilitar gravação para uma versão ou para o repositório. Essa proteção de dados difere de um bloqueio do no recurso de registro, que protege operações de gerenciamento, mas não torna o conteúdo imutável.
# Bloquear uma tag implantada
az acr repository update \
--name myregistry \
--image inference-api:v1.2.0 \
--write-enabled false
# Restaurar gravação e exclusão durante a retirada
az acr repository update \
--name myregistry \
--image inference-api:v1.2.0 \
--write-enabled true --delete-enabled true
A estratégia completa controla separadamente gravação, exclusão e leitura. Verifique os atributos da tag e do manifest, pois são objetos relacionados, mas distintos. Desbloqueie somente em um processo controlado de retirada.
Resumo do tópico
Use atributos dos dados do repositório, e não apenas bloqueio do recurso , para impedir sobrescrita ou exclusão do artefato implantado.
13. Manifests sem tag, purge e retenção
Mover uma tag estável pode deixar o manifest anterior sem tag, ainda consumindo armazenamento. A exclusão indiscriminada é perigosa porque um manifest sem tag pode estar implantado por digest. Inventarie workloads em execução e proteja conteúdo necessário antes da limpeza.
# Simular o filtro antes de excluir
az acr run --registry myregistry \
--cmd "acr purge --filter 'inference-api:.*' --untagged --ago 30d --dry-run" \
/dev/null
acr purge executa como ACR Task e filtra repositórios, tags, idade e manifests sem tag. Uma tarefa agendada automatiza a manutenção. A Premium é uma alternativa em para manifests Docker elegíveis; aplica-se aos objetos que ficaram sem tag depois da habilitação e não cobre todos os tipos OCI. A exclusão é irrecuperável: valide filtros, locks e escopo.
Resumo do tópico
Conteúdo sem tag ainda ocupa espaço; use simulação, inventário de implantação, locks, purge restrito ou retenção elegível antes da exclusão permanente.
14. Laboratório guiado: compilar e gerenciar uma de IA
O exercício fornecido estima cerca de 30 minutos e exige assinatura do com permissão de implantação, , Python 3.12 ou superior e CLI do atualizada. Execuções do ACR Tasks estão temporariamente indisponíveis para créditos gratuitos; use assinatura paga elegível. Há possibilidade de cobrança e os recursos devem ser removidos ao final.
Obtenha ou crie arquivos iniciais com de inferência, dependências, Dockerfile e teste simples.
Entre no , selecione a assinatura e crie um grupo de recursos dedicado.
Crie um registro Basic com nome globalmente exclusivo.
Execute az acr build com tag exclusiva e acompanhe build e push.
Liste repositórios, tags e ; registre o digest.
Execute um comando de validação inofensivo com az acr run.
Crie outra versão ou tag com ID de execução e compare os digests.
Bloqueie a tag promovida e documente a referência de .
Exclua o grupo dedicado se nenhum recurso compartilhado estiver nele.
RG=rg-ai200-acr-lab
LOCATION=eastus
ACR_NAME=<nome-globalmente-exclusivo>
az group create --name $RG --location $LOCATION
az acr create --resource-group $RG --name $ACR_NAME --sku Basic
az acr build --registry $ACR_NAME --image inference-api:v1.0.0 .
az acr repository list --name $ACR_NAME --output table
az acr repository show-tags --name $ACR_NAME --repository inference-api --detail --output table
az acr manifest list-metadata --registry $ACR_NAME --name inference-api --output table
az acr run --registry $ACR_NAME --cmd 'inference-api:v1.0.0 python --version' /dev/null
Não coloque de produção em comandos, build args, camadas da imagem, Git ou tarefas. Em reais, use identidades gerenciadas e armazenamento seguro de segredos, e examine e testes antes de promover.
Resumo do tópico
O laboratório cria o registro, compila na nuvem, valida e runtime, registra a identidade imutável, protege o release e remove recursos com segurança.
15. Verificação de conhecimento reescrita e justificativas
Use a justificativa para aprender a decisão.
Pergunta
Melhor resposta
Justificativa
Como eliminar diferenças de build entre estações?
Use build rápido ou tarefa persistente do ACR Tasks.
A compilação ocorre em ambiente controlado no .
Como garantir o mesmo artefato em todos os nós depois que uma tag mudar?
Referencie o digest do manifest.
O digest é imutável; a tag é um ponteiro.
Como recompilar ao mudar a base PyTorch?
Configure gatilho de atualização da imagem base.
A tarefa acompanha a dependência FROM descoberta no build.
Qual tag facilita rastreamento do código e ?
Tag exclusiva com commit e ID de build ou execução.
Ela não é reutilizada e liga artefato, fonte e .
Como impedir sobrescrita da imagem ativa?
Defina write-enabled como false.
O atributo protege o próprio objeto do repositório.
Resumo do tópico
As decisões centrais são build controlado, digest imutável, gatilho da imagem base, tag exclusiva e bloqueio no nível do repositório.
16. Revisão final e referências Microsoft
Registro → repositório/ → artefato é a hierarquia.
Tags expressam intenção humana; manifests e digests fixam identidade.
ACR Tasks oferece tarefas rápidas, acionadas, agendadas e multietapa.
Uma cadeia confiável para contêineres de IA combina armazenamento organizado, builds reproduzíveis, identidade imutável, ciclo de vida controlado e automação protegida.
