Cache de artefato – Visão geral

Artigo
11/18/2023

O recurso Cache de artefato permite que os usuários armazenem em cache imagens de contêiner em um registro de contêiner privado. O Cache de artefato está disponível nas camadas de serviçoBásica, Standard e Premium.

Este artigo é a primeira parte de uma série de tutoriais de seis partes. O tutorial abrange:

Cache de artefato

O Cache de artefato permite a você armazenar em cache imagens de contêiner de repositórios públicos e privados.

A implementação do Cache de artefato fornece os seguintes benefícios:

Operações de pull mais confiáveis: pulls mais rápidos de imagens de contêiner são alcançáveis armazenando em cache as imagem de contêiner no ACR. Como a Microsoft gerencia a rede do Azure, as operações de pull são mais rápidas, oferecendo suporte para a Replicação Geográfica e Zona de Disponibilidade aos clientes.

Redes privadas: os registros armazenados em cache estão disponíveis em redes privadas. Portanto, os usuários podem configurar seu firewall para atender aos padrões de conformidade.

Garantir que o conteúdo upstream seja entregue: todos os registros, especialmente os públicos, como Docker Hub e outros, têm limites de pull anônimos para garantir que possam fornecer serviços a todos. O Cache de artefato permite que os usuários efetuem pull de imagens do ACR local em vez do registro upstream. O Cache de artefato garante a entrega do conteúdo upstream e que os usuários obtenham o benefício de efetuar pull de imagens de contêiner do cache sem contar para os limites de pull.

Terminologia

Regra de Cache - Uma Regra de Cache é uma regra que você pode criar para efetuar pull de artefatos de um repositório com suporte para o cache.
- Uma regra de cache contém quatro partes:
  1. Nome da Regra - O nome da regra de cache. Por exemplo, Hello-World-Cache.
  2. Origem - O nome do Registro de Origem.
  3. Caminho do Repositório - O caminho de origem do repositório para localizar e recuperar artefatos que você deseja armazenar em cache. Por exemplo, docker.io/library/hello-world.
  4. Novo Namespace do Repositório do ACR - O nome do novo caminho do repositório para armazenamento. Por exemplo, hello-world. O Repositório não pode existir dentro da instância do ACR.
Credenciais
- As credenciais são um conjunto de nome de usuário e senha para o registro de origem. Você precisa de Credenciais para autenticar com um repositório público ou privado. As credenciais contêm quatro partes
  1. Credenciais - O nome de suas credenciais.
  2. Servidor de Logon do Registro de Contêiner - O servidor de logon do registro de origem.
  3. Autenticação de Origem - Os locais do cofre de chaves para armazenar credenciais.
  4. Segredos de Nome de Usuário e Senha - Os segredos que contém o nome de usuário e a senha.

Limitações

O cache só ocorrerá depois que pelo menos um pull de imagem for concluído na imagem de contêiner disponível. Para cada nova imagem disponível, um novo pull de imagem deve ser concluído. O Cache de artefato não efetua pull automático de novas marcas de imagens quando uma nova marca está disponível. Ele está no roteiro, mas não é compatível com esta versão.
O Cache de artefato só dá suporte a 1.000 regras de cache.

Compatibilidade com upstream

Atualmente, o Cache de Artefatos dá suporte aos seguintes registros upstream:

Registros upstream	Suporte	Disponibilidade
Docker Hub	Compatível com pulls autenticados e pulls não autenticados.	CLI do Azure, portal do Azure
Registro de Artefato da Microsoft	Compatível apenas com pulls não autenticados.	CLI do Azure, portal do Azure
ECR Público	Compatível apenas com pulls não autenticados.	CLI do Azure, portal do Azure
Registro de Contêiner do GitHub	Compatível com pulls autenticados e pulls não autenticados.	CLI do Azure, portal do Azure
Nvidia	Compatível com pulls autenticados e pulls não autenticados.	CLI do Azure
Quay	Compatível com pulls autenticados e pulls não autenticados.	CLI do Azure, portal do Azure
registry.k8s.io	Compatível com pulls autenticados e pulls não autenticados.	CLI do Azure
Registro de contêiner do Google	Compatível com pulls autenticados e pulls não autenticados.	CLI do Azure

Curingas

Curinga use asteriscos (*) para corresponder a vários caminhos dentro do registro de imagem de contêiner. Atualmente, o Cache de Artefatos dá suporte aos seguintes curingas:

Observação

O mapa de regras de cache do Repositório de Destino => Repositório de Origem.

Curinga no Nível do Registro

O curinga no nível do Registro permite que você armazene em cache todos os repositórios de um registro upstream.

Regra de cache	Mapeamento	Exemplo
contoso.azurecr.io/* => mcr.microsoft.com/*	Mapeamento para todas as imagens em ACR para MCR.	contoso.azurecr.io/myapp/image1 => mcr.microsoft.com/myapp/image1 contoso.azurecr.io/myapp/image2 => mcr.microsoft.com/myapp/image2

Curinga no nível do repositório

O curinga no nível do repositório permite armazenar em cache todos os repositórios de um mapeamento de registro upstream para o prefixo do repositório.

Regra de cache	Mapeamento	Exemplo
contoso.azurecr.io/dotnet/* => mcr.microsoft.com/dotnet/*	Mapeando repositórios específicos no ACR para repositórios correspondentes no MCR.	contoso.azurecr.io/dotnet/sdk => mcr.microsoft.com/dotnet/sdk contoso.azurecr.io/dotnet/runtime => mcr.microsoft.com/dotnet/runtime
contoso.azurecr.io/library/dotnet/* => mcr.microsoft.com/dotnet/* contoso.azurecr.io/library/python/* => docker.io/library/python/*	Mapeando repositórios específicos no ACR para repositórios de diferentes registros upstream.	contoso.azurecr.io/library/dotnet/app1 => mcr.microsoft.com/dotnet/app1 contoso.azurecr.io/library/python/app3 => docker.io/library/python/app3

Limitações para regras de cache baseadas em curinga

As regras de cache curinga usam asteriscos (*) para corresponder a vários caminhos dentro do registro de imagem de contêiner. Essas regras não podem se sobrepor a outras regras de cache curinga. Em outras palavras, se você tiver uma regra de cache curinga para um determinado caminho do Registro, não poderá adicionar outra regra curinga que se sobreponha a ela.

Aqui estão alguns exemplos de regras sobrepostas:

Exemplo 1:

Regra de cache existente: contoso.azurecr.io/* => mcr.microsoft.com/*
Novo cache sendo adicionado: contoso.azurecr.io/library/* => docker.io/library/*

A adição da nova regra de cache é bloqueada porque o caminho contoso.azurecr.io/library/* do repositório de destino se sobrepõe à regra curinga existente contoso.azurecr.io/*.

Exemplo 2:

Regra de cache existente: contoso.azurecr.io/library/* =>mcr.microsoft.com/library/*
Novo cache sendo adicionado: contoso.azurecr.io/library/dotnet/* =>docker.io/library/dotnet/*

A adição da nova regra de cache é bloqueada porque o caminho do repositório de destino contoso.azurecr.io/library/dotnet/* se sobrepõe à regra curinga existente contoso.azurecr.io/library/*.

Limitações para regras de cache estáticas/fixas

As regras de cache estáticas ou fixas são mais específicas e não usam curingas. Eles podem se sobrepor às regras de cache baseadas em curinga. Se uma regra de cache especificar um caminho de repositório fixo, ela poderá se sobrepor a uma regra de cache baseada em curinga.