Visão geral de repositório

O Artifact Registry permite que você armazene diferentes tipos de artefatos, crie vários repositórios em um único projeto e associe um local regional ou multirregional específico a cada repositório. Nesta página, você verá considerações sobre como planejar os locais e a organização dos repositórios.

Quando criar os repositórios, pense em processos internos para criar os artefatos e no uso que os consumidores fazem dos artefatos.

Formatos de repositório

Cada repositório é associado a um formato de artefato específico . Por exemplo, um repositório do Docker armazena imagens do Docker. É possível criar vários repositórios para cada formato em no mesmo Google Cloud projeto.

Modos de repositório

Há vários modos de repositório. Cada modo tem uma finalidade diferente. Portanto, não é possível mudar o modo do repositório depois de criar um.

Repositório padrão

Os repositórios padrão são repositórios normais do Artifact Registry para seus artefatos particulares. Você faz upload e download de artefatos diretamente com esses repositórios e usa o Artifact Analysis para verificar vulnerabilidades e outros metadados.

Para criar repositórios padrão, siga as etapas em Criar repositórios padrão.

Repositório remoto

Os repositórios remotos são repositórios somente leitura que atuam como proxies para armazenar artefatos das seguintes fontes upstream:

  • Repositórios padrão do Artifact Registry.
  • Fontes externas, como Docker Hub, Maven Central, Python Package Index (PyPI), Debian ou CentOS.

Na primeira vez que você solicita uma versão de artefato, o repositório faz o download dela da fonte upstream e armazena uma cópia em cache. O repositório remoto disponibiliza a cópia armazenada em cache quando a mesma versão é solicitada novamente.

Os repositórios remotos reduzem a latência e melhoram a disponibilidade para builds e implantações no Google Cloud. Também é possível usar o Artifact Analysis para verificar vulnerabilidades e outros metadados em pacotes armazenados em cache.

Para saber mais sobre repositórios remotos, leia Visão geral do repositório remoto. Para criar repositórios remotos, siga as etapas em Criar repositórios remotos.

Repositório virtual

Um repositório somente leitura que atua como um único ponto de acesso para fazer o download, instalar ou implantar artefatos do mesmo formato de um ou mais repositórios upstream. Um repositório upstream pode ser um repositório padrão, remoto ou virtual.

Os repositórios virtuais simplificam a configuração do cliente para os consumidores dos seus artefatos. Também é possível mitigar ataques de confusão de dependências configurando sua política upstream para priorizar repositórios com seus artefatos particulares em vez de repositórios remotos que armazenam artefatos públicos em cache.

Para saber mais sobre repositórios virtuais, leia Visão geral do repositório virtual. Para criar repositórios virtuais, siga as etapas em Criar repositórios virtuais.

Exemplo de uso do repositório

O diagrama a seguir mostra uma das muitas maneiras possíveis de usar repositórios em diferentes modos juntos. O diagrama mostra um fluxo de trabalho em dois Google Cloud projetos. Em um projeto de desenvolvimento, os desenvolvedores criam um aplicativo Java. Em um projeto de ambiente de execução separado, outro build cria uma imagem de contêiner com o aplicativo para implantação no Google Kubernetes Engine.

Repositórios padrão, virtuais e remotos usados em dois projetos.

  1. No projeto de desenvolvimento, uma equipe de desenvolvimento Java usa o Cloud Build para criar um aplicativo Java.

    • O build pode solicitar dependências públicas do Java usando o repositório virtual. O repositório virtual disponibiliza as dependências do repositório remoto, que é um proxy de armazenamento em cache para o Maven Central.
    • O Cloud Build faz upload do pacote para o repositório Maven padrão no projeto de componente.

  2. No projeto de ambiente de execução, o Cloud Build containeriza o aplicativo Java.

    O build usa o repositório virtual do Maven para fazer o download do aplicativo. O repositório virtual disponibiliza o pacote do repositório padrão no projeto de desenvolvimento. O build também pode fazer o download de dependências públicas do Java do mesmo repositório virtual.

  3. No projeto de ambiente de execução, o Cloud Build faz upload da imagem de contêiner criada para um repositório Docker padrão.

  4. O GKE extrai imagens do repositório virtual do Docker.

    • O repositório Docker padrão upstream fornece imagens particulares, como o aplicativo Java containerizado.
    • O repositório remoto upstream fornece imagens que o GKE solicita do Docker Hub.

Neste exemplo, todos os repositórios, builds e clusters do GKE estão na mesma região. O uso do mesmo local para Google Cloud serviços tem benefícios descritos em Localização do repositório.

Localização do repositório

É possível criar um ou mais repositórios em uma região ou multirregião compatível. Um bom local de repositório equilibra custos de latência, disponibilidade e largura de banda para os consumidores de dados. Sua organização também pode ter requisitos de conformidade específicos.

Considerações sobre o local

Esta seção descreve por que você pode querer criar um repositório na mesma região que outros Google Cloud serviços.

É possível reduzir a latência e os custos de saída de rede criando repositórios na mesma região em que você executa o GKE, o Cloud Run, o Cloud Build e outros Google Cloud serviços que interagem com o repositório. Não há cobrança pela saída do Artifact Registry para outros Google Cloud serviços na mesma região.

Embora não haja cobrança pela saída de uma multirregião para um Google Cloud serviço em uma região correspondente, esse preço só se aplica a um conjunto limitado de regiões.

  • Para a multirregião us, a saída para uma região nos Estados Unidos, como us-central, não é cobrada, mas a saída para qualquer região no Canadá ou na América do Sul é cobrada.
  • Para a multirregião asia, a saída para regiões na Ásia, como asia-northeast1 não é cobrada, mas a saída para regiões na Austrália é cobrada.
Só é possível usar o streaming de imagens no GKE e no Managed Service for Apache Spark se as imagens de contêiner forem armazenadas em repositórios do Artifact Registry na mesma região que as cargas de trabalho ou em uma multirregião que corresponda à região com as cargas de trabalho. O streaming de imagens pode reduzir significativamente o tempo de inicialização da carga de trabalho quando você usa imagens de contêiner maiores, já que as cargas de trabalho podem começar antes que a imagem inteira seja baixada.

Considere o local dos consumidores fora de Google Cloud. Por exemplo, se a equipe de desenvolvedores na Austrália precisar fazer o download de artefatos do Artifact Registry para as estações de trabalho locais, um repositório em uma região australiana reduzirá a latência e incorrerá em taxas de saída mais baixas do que um repositório localizado em outro continente.

Restringir locais de repositório

Se você precisar obedecer a regulamentações ou políticas que exigem o armazenamento de dados em regiões específicas, inclua uma restrição de locais de recursos na sua Google Cloud política da organização que permita apenas a criação de repositórios em regiões em conformidade. O Artifact Registry só aplica a restrição depois que você a inclui na política da organização. Se você tiver repositórios em locais não compatíveis, mova os artefatos para um repositório em um local compatível e exclua o repositório não compatível.

Políticas de revisão dos dados

Uma política de limpeza do Artifact Registry define critérios para excluir automaticamente versões de artefatos que você não precisa mais ou manter artefatos que você quer armazenar indefinidamente.

As políticas de limpeza são úteis se você armazena muitas versões dos seus artefatos, mas só precisa manter versões específicas que você lança para produção. É possível definir políticas de exclusão com critérios para excluir artefatos e políticas de manutenção com critérios para reter artefatos.

Se uma versão de artefato corresponder a critérios em uma política de exclusão e em uma política de manutenção, o Artifact Registry aplicará a política de manutenção.

Usar políticas de exclusão

As políticas de exclusão excluem artefatos que correspondem aos seguintes critérios obrigatórios:

  • Estado da tag: indica se a política deve verificar artefatos marcados ou não marcados. Os artefatos são marcados ao enviar ou extrair uma imagem para ou de um repositório. Para mais informações sobre tags do Docker, consulte Conceitos de contêiner.

    • Qualquer estado de tag: ignora o estado da tag e se aplica a artefatos marcados e não marcados.
    • Marcado: só se aplica a artefatos marcados.
    • Não marcado: só se aplica a artefatos não marcados.

    Os formatos que não oferecem suporte a tags são tratados como untagged. Não é possível excluir artefatos marcados em repositórios com tags imutáveis ativadas.

    Para mais informações sobre o estado da tag aplicado às políticas de limpeza, consulte a referência TagState.

É possível usar qualquer uma das seguintes configurações para configurar a política de exclusão:

  • Prefixos de tag: é uma lista de prefixos de tag separados por vírgulas. Por exemplo, os prefixos test e staging corresponderiam a imagens com tags testenv e staging-1.5. tagState precisa ser definido como TAGGED para usar prefixos de tag.
    • Prefixos de versão: - é uma lista de prefixos de versão de artefato separados por vírgulas. Por exemplo, v1, v2 corresponderiam às versões v1.5, v2.0alpha, e v10.2.
  • Prefixos de pacote: é uma lista de prefixos de nome de artefato. É possível inserir vários prefixos pressionando Enter ou , entre os prefixos. Por exemplo red, blue criaria dois prefixos, red e blue, e corresponderia aos nomes de artefato red-team, redis, e bluebird.
  • Mais antigo que: é um tempo mínimo desde que uma versão de artefato foi enviada para o repositório, especificada como uma duração. Por exemplo, 30d é 30 dias. É possível especificar durações de segundos, minutos, horas ou dias anexando s, m, h, ou d, respectivamente.
  • Mais recente que: é um tempo máximo desde que uma versão de artefato foi enviada para o repositório, especificada como uma duração. Por exemplo, 30d é 30 dias.

Usar políticas de manutenção

As políticas de manutenção mantêm artefatos que correspondem às mesmas condições das políticas de exclusão ou um número definido de versões mais recentes.

Por exemplo, considerando um repositório que contém os seguintes artefatos:

IMAGE: us-west1-docker.pkg.dev/my-project/release-xyz-v1
DIGEST: sha256:1b0a26bd07a3d17473d8d8468bea84015e27f87124b2831234581bce13f61370
TAGS:
CREATE_TIME: 2023-06-19T18:59:09
UPDATE_TIME: 2023-06-19T18:59:10

IMAGE: us-west1-docker.pkg.dev/my-project/release-xyz-v2
DIGEST: sha256:6e494387c901caf429c1bf77bd92fb82b33a68c0e19f123456a3ac8d27a7049d
TAGS: latest
CREATE_TIME: 2023-06-19T18:59:09
UPDATE_TIME: 2023-06-19T18:59:09

IMAGE: us-west1-docker.pkg.dev/my-project/release-v2
DIGEST: sha256:6e494387c901caf429c1bf77bd92fb82b33a68c0e19f123456a3ac8d27a7049d
TAGS: latest
CREATE_TIME: 2023-06-19T18:59:09
UPDATE_TIME: 2023-06-19T18:59:09

Se a política Manter as versões mais recentes estiver definida para manter três versões de pacotes que correspondam aos Prefixos de pacote: {release-xyz}, somente release-xyz-v1 e release-xyz-v2 serão mantidos.

As exclusões acionadas por políticas de exclusão são contabilizadas na cota de solicitação de exclusão por projeto do Artifact Registry .

Para criar e aplicar políticas de limpeza ao repositório, consulte Configurar políticas de limpeza.

Suporte ao domínio gcr.io

O Artifact Registry oferece suporte à hospedagem de imagens no domínio gcr.io. Se você estiver fazendo a transição do Container Registry para o Artifact Registry, configure os repositórios gcr.io do Artifact Registry para minimizar as mudanças na automação e nos fluxos de trabalho atuais. Esses repositórios oferecem:

  • Redirecionamento de solicitações para o domínio gcr.io.
  • Criação de repositórios gcr.io quando a primeira imagem é enviada por push para um nome de host gcr.io para compatibilidade com o comportamento do Container Registry.

Para mais informações, consulte Transição para repositórios com suporte ao domínio gcr.io

Estrutura do projeto

A hierarquia de recursos é a maneira de organizar os recursos em Google Cloud projetos. A estrutura escolhida depende de fatores como requisitos de governança de dados, limites de confiança e estrutura da equipe.

Há duas abordagens gerais para configurar os repositórios em organizações com vários projetos.

Centralizar repositórios

Crie todos os repositórios em um único projeto e conceda acesso a principais de outros projetos no nível do repositório. Essa abordagem pode ser mais eficaz quando uma única pessoa ou equipe lida com a administração e o acesso ao repositório em toda a organização.

Ela também pode simplificar a configuração de repositórios virtuais, já que você só precisa ativar e gerenciar uma única instância do Artifact Registry.

Repositórios específicos do projeto

Crie repositórios em projetos que armazenam e fazem o download de artefatos. Essa abordagem pode ser necessária quando você tem políticas de governança de dados ou limites de confiança que exigem mais separação e controle de recursos para envolvidos no projeto.

Controle de acesso

Os repositórios só podem ser acessados com as permissões apropriadas, a menos que você configure o repositório para acesso público. É possível conceder permissões no nível do projeto ou do repositório.

Alguns Google Cloud serviços usam contas de serviço padrão com permissões padrão para repositórios no mesmo Google Cloud projeto. No entanto, esses padrões podem não ser adequados para o processo de desenvolvimento de software ou podem não obedecer aos requisitos da política ou de segurança da sua organização. O administrador do repositório precisa conceder acesso explicitamente a esses serviços aos repositórios se:

  • O Artifact Registry estiver em um projeto diferente do serviço que está interagindo com ele.
  • Você estiver usando papéis personalizados do IAM com as contas de serviço padrão em vez do papel predefinido.
  • Você não estiver usando a conta de serviço padrão para o Google Cloud serviço.
  • Você estiver configurando repositórios virtuais. É necessário conceder explicitamente à conta de serviço do Artifact Registry acesso a repositórios upstream.

Para outros principais que exigem acesso a repositórios, o administrador do repositório precisa conceder acesso. Seguindo o princípio de segurança do menor privilégio, conceda as permissões mínimas necessárias. Exemplo:

  • Você implanta imagens de contêiner no Artifact Registry em clusters do GKE em vários projetos diferentes. A conta de serviço dos nós nesses clusters só exige acesso de leitura aos repositórios.
  • Você tem um repositório de desenvolvimento para aplicativos que estão em desenvolvimento e um repositório de produção para aplicativos lançados. Os desenvolvedores exigem acesso de leitura e gravação ao repositório de desenvolvimento e acesso somente leitura ao repositório de produção.
  • Você tem um repositório de demonstração com aplicativos de amostra. Sua equipe de vendas só exige acesso somente leitura para fazer o download das demonstrações.

Restringir downloads de artefatos

É possível restringir downloads de artefatos com regras de download. As regras de download permitem permitir ou negar downloads de artefatos de repositórios e pacotes. Também é possível definir condições para que a regra se aplique a tags ou versões específicas.

Para detalhes sobre como as regras de download funcionam, consulte a seção Restringir downloads de artefatos da Visão geral de controle de acesso e proteção de artefatos.

Criptografia de dados

Por padrão, Google Cloud criptografa automaticamente os dados quando estão em repouso usando Google Cloude de propriedade do Google. Se você tiver requisitos regulatórios ou de conformidade específicos relacionados às chaves que protegem seus dados, crie repositórios criptografados com chaves de criptografia gerenciadas pelo cliente (CMEK).

O Artifact Registry também oferece suporte a restrições de política da organização que podem exigir CMEK para proteger recursos.

Rótulos e tags

Os rótulos oferecem uma maneira de organizar recursos específicos de um Google Cloud serviço. No Artifact Registry, é possível adicionar rótulos aos repositórios para agrupá-los ou filtrar listas de repositórios por rótulo. Por exemplo, é possível usar rótulos para agrupar repositórios por estágio de desenvolvimento ou por equipe para fins de automação ou faturamento. Para mais informações sobre como criar e usar rótulos de repositório, consulte Como etiquetar repositórios.

Também é possível aplicar tags aos repositórios. Embora os rótulos sejam principalmente para organizar e filtrar recursos específicos do serviço, as tags são para controle programático de políticas em uma Google Cloud organização. Para mais informações, consulte Como marcar repositórios.

A seguir