Visão geral de repositório

O Artifact Registry permite armazenar diferentes tipos de artefatos, criar múltiplos repositórios em um único projeto e associar um repositório região ou multirregião com 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 projeto do Google Cloud.

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 de repositório depois de criar um repositório.

Repositório padrão
Os repositórios padrão são repositórios regulares do Artifact Registry para os artefatos particulares. Você faz upload e download de artefatos diretamente com essas repositórios e usar o Artifact Analysis para verificar vulnerabilidades e outros metadados.
Repositório remoto

Um repositório somente leitura que funciona como um proxy para armazenar artefatos de fontes externas predefinidas, como o Docker Hub, o Maven Central, o índice de pacotes do Python (PyPI), o Debian ou o CentOS, além de fontes definidas pelo usuário para formatos compatíveis. Na primeira vez que você solicita do artefato, o repositório faz o download dela da fonte externa e armazena uma cópia dele em cache. O repositório envia a cópia em cache quando o mesmo versão é solicitada novamente.

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

Repositório virtual

Um repositório somente leitura que atua como um ponto de acesso para fazer o download instalar ou implantar artefatos do mesmo formato usando 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 consumidores de seus artefatos. Também é possível reduzir ataques de confusão de dependência configurando o fluxo para priorizar repositórios com seus artefatos particulares em vez de que armazenam artefatos públicos em cache.

Exemplo de uso do repositório

O diagrama a seguir mostra uma das muitas maneiras possíveis de usar repositórios em modos diferentes. O diagrama mostra um fluxo de trabalho em dois projetos do Google Cloud. Em um projeto de desenvolvimento, os desenvolvedores criam um para o aplicativo. Em um projeto 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 de Java usando a repositório de dados. O repositório virtual disponibiliza as dependências do repositório , 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 do componente.

  2. No projeto do ambiente de execução, o Cloud Build conteineriza o Java para o aplicativo.

    O build usa o repositório virtual Maven para fazer o download do aplicativo. O repositório virtual serve 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 do ambiente de execução, o Cloud Build faz upload do contêiner criado. imagem para um repositório padrão do Docker.

  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 conteinerizado.
    • O repositório remoto upstream fornece imagens que o GKE do Docker Hub.

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

Localização do repositório

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

Considerações sobre o local

Criar um repositório na mesma região que outros serviços do Google Cloud tem uma série de benefícios:

  • Reduza 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 serviços do Google Cloud que interagem com o repositório. Não há cobrança pela saída do Artifact Registry para outros serviços do Google Cloud na mesma região.

    Embora não haja cobrança pela saída de uma região multirregional para uma serviço do Google Cloud em uma região correspondente, somente esse preço 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 é cobrado, para qualquer região do Canadá ou da América do Sul é carregado.
    • Para a multirregião asia, a saída para regiões na Ásia como asia-northeast1 não são cobrados, mas a saída para regiões na Austrália é carregado.

  • Só é possível usar o streaming de imagem no GKE e no Dataproc Serverless se as imagens do contêiner estiverem 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 tempo de inicialização da carga de trabalho significativamente ao usar porque as cargas de trabalho podem ser iniciadas antes do download da imagem inteira.

  • Considere a localização dos consumidores fora do Google Cloud. Para Por exemplo, se sua equipe de desenvolvedores na Austrália precisar fazer o download de artefatos do Artifact Registry às estações de trabalho locais, um repositório em uma região australiana reduz a latência e gera cobranças de saída mais baixas do que um repositório em outro continente.

Como restringir locais de repositório

Se for preciso cumprir regulamentações ou políticas que exijam o armazenamento dados em regiões específicas, inclua uma restrição de locais de recursos na sua Google Cloud política da organização que só permita a criação de repositórios em regiões em conformidade. O Artifact Registry só aplica a restrição depois que ela é incluída na política da organização. Se você tiver repositórios em locais sem compliance, você precisa mover seus artefatos para um repositório local em conformidade por conta própria e, em seguida, exclua o repositório não compatível.

Políticas de limpeza

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

As políticas de limpeza são úteis se você armazenar muitas versões dos artefatos, mas precisa manter apenas versões específicas lançadas para produção. Você definir políticas de exclusão com critérios para excluir artefatos e Manter políticas com critérios para reter artefatos.

Se uma versão de artefato corresponder aos critérios em uma política de exclusão e em uma manutenção o Artifact Registry aplica a política Keep.

Excluir políticas

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

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

    • Qualquer estado de tag: ignora o estado da tag e se aplica às tags e artefatos sem tag.
    • Com tag: só se aplica a artefatos marcados.
    • Sem tag: só se aplica a artefatos sem tag.

    Os formatos incompatíveis com tags são tratados como untagged. Artefatos marcados em repositórios com tags imutáveis ativadas.

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

Veja a seguir maneiras opcionais de definir sua política de exclusão:

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

Manter políticas

As políticas Keep mantêm os artefatos que correspondem às mesmas condições que as políticas de exclusão. 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 do Pacotes que correspondam aos Prefixos do pacote: {release-xyz}, somente release-xyz-v1 e release-xyz-v2 são mantidos.

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

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

Suporte a domínios gcr.io

O Artifact Registry oferece suporte à hospedagem de imagens no domínio gcr.io. Se você for durante a transição do Container Registry para o Artifact Registry, é possível O gcr.io armazena o Artifact Registry para minimizar mudanças nas automação e fluxos de trabalho. 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 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 forma como você organiza os recursos nos projetos do Google Cloud. A estrutura escolhida depende fatores como requisitos de governança de dados, limites de confiança e na estrutura dos preços.

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

Centralize 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 o repositório administração de rede e acesso ao repositório em toda a organização.
Ele também simplifica a configuração de repositórios virtuais ou soluções como o Software Delivery Shield, 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 armazenem e façam o download de artefatos. Isso 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 do projeto do Google Cloud.

Controle de acesso

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

Alguns serviços do Google Cloud usam contas padrão com permissões padrão para repositórios no mesmo projeto do Google Cloud. No entanto, esses padrões podem não ser adequados para seu software de desenvolvimento de aplicativos ou podem não estar em conformidade com na sua organização. O administrador do repositório precisa conceder o acesso desses serviços aos repositórios se:

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

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

  • Implante imagens de contêiner no Artifact Registry para o GKE clusters em vários projetos diferentes. A conta de serviço para nós nesses clusters só exigem acesso de leitura aos repositórios.
  • Você tem um repositório de desenvolvimento para aplicativos que estão em desenvolvimento repositório de produção para aplicativos que são lançados. Os desenvolvedores precisam ter 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 exemplo. Apenas para sua equipe de vendas requer acesso somente leitura para fazer o download das demonstrações.

Criptografia de dados

Por padrão, o Google Cloud criptografa automaticamente os dados quando rest usando Chaves de propriedade e gerenciadas pelo Google. Se você tiver requisitos regulatórios ou de compliance específicos relacionados às chaves que protegem seus dados, crie repositórios criptografados com chaves de criptografia gerenciadas pelo cliente (CMEKs).

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

Rótulos e tags

Os rótulos são uma maneira de organizar recursos específicos para uma 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 para fins de automação ou faturamento. Para mais informações sobre como criar e usar rótulos de repositório, consulte Como rotular repositórios.

Você também pode aplicar tags aos repositórios. Os rótulos servem principalmente organizando e filtrando recursos específicos do serviço, as tags são destinadas à programática e controle de políticas em uma organização do Google Cloud. Para mais informações, consulte Repositórios de tags.

A seguir