Vista geral do repositório

O Artifact Registry permite-lhe armazenar diferentes tipos de artefactos, criar vários repositórios num único projeto e associar uma localização regional ou multirregional específica a cada repositório. Esta página descreve as considerações que ajudam a planear as localizações e a organização dos seus repositórios.

Considere os processos internos para criar os seus artefactos e a utilização dos seus artefactos pelos consumidores quando criar os seus repositórios.

Formatos de repositório

Cada repositório está associado a um formato de artefacto específico. Por exemplo, um repositório do Docker armazena imagens do Docker. Pode criar vários repositórios para cada formato no mesmo Google Cloud projeto.

Modos de repositório

Existem vários modos de repositório. Cada modo tem uma finalidade diferente, pelo que não pode alterar o modo do repositório depois de criar um repositório.

Repositório padrão

Os repositórios padrão são repositórios normais do Artifact Registry para os seus artefactos privados. Carrega e transfere artefactos diretamente com estes repositórios e usa a análise de artefactos para procurar vulnerabilidades e outros metadados.

Para criar repositórios padrão, siga os passos em Crie repositórios padrão.

Repositório remoto

Os repositórios remotos são repositórios só de leitura que atuam como proxies para armazenar artefactos das seguintes origens a montante:

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

Quando pede uma versão de um artefacto pela primeira vez, o repositório transfere-a da origem a montante e armazena em cache uma cópia da mesma. O repositório remoto publica a cópia em cache quando a mesma versão é pedida novamente.

Os repositórios remotos reduzem a latência e melhoram a disponibilidade para compilações e implementações no Google Cloud. Também pode usar a análise de artefactos para verificar vulnerabilidades e outros metadados em pacotes em cache.

Para saber mais sobre os repositórios remotos, leia o artigo Vista geral do repositório remoto. Para criar repositórios remotos, siga os passos em Crie repositórios remotos.

Repositório virtual

Um repositório só de leitura que funciona como um único ponto de acesso para transferir, instalar ou implementar artefactos do mesmo formato a partir de um ou mais repositórios a montante. Um repositório a montante 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 artefactos. Também pode mitigar ataques de confusão de dependências configurando a sua política a montante para dar prioridade a repositórios com os seus artefactos privados em vez de repositórios remotos que armazenam em cache artefactos públicos.

Para saber mais sobre os repositórios virtuais, leia o artigo Vista geral do repositório virtual. Para criar repositórios virtuais, siga os passos em Crie repositórios virtuais.

Exemplo de utilização do repositório

O diagrama seguinte mostra uma das muitas formas possíveis de usar repositórios em diferentes modos em conjunto. O diagrama mostra um fluxo de trabalho em dois Google Cloud projetos. Num projeto de desenvolvimento, os programadores criam uma aplicação Java. Num projeto de tempo de execução separado, outra compilação cria uma imagem de contentor com a aplicação para implementação no Google Kubernetes Engine.

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

  1. No projeto de desenvolvimento, uma equipa de desenvolvimento em Java usa o Cloud Build para criar uma aplicação Java.

    • A compilação pode pedir dependências Java públicas através do repositório virtual. O repositório virtual serve as dependências do repositório remoto, que é um proxy de colocação em cache para o Maven Central.
    • O Cloud Build carrega o pacote para o repositório Maven padrão no projeto do componente.

  2. No projeto de tempo de execução, o Cloud Build coloca a aplicação Java em contentores.

    A compilação usa o repositório virtual Maven para transferir a aplicação. O repositório virtual disponibiliza o pacote a partir do repositório padrão no projeto de desenvolvimento. A compilação também pode transferir dependências Java públicas do mesmo repositório virtual.

  3. No projeto de tempo de execução, o Cloud Build carrega a imagem do contentor 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 a montante fornece imagens privadas, como a aplicação Java em contentor.
    • O repositório remoto a montante fornece imagens que o GKE pede ao Docker Hub.

Neste exemplo, todos os repositórios, compilações e clusters do GKE estão na mesma região. A utilização da mesma localização para os Google Cloud serviços tem vantagens descritas em Localização do repositório.

Localização do repositório

Pode criar um ou mais repositórios numa região ou multirregião suportada. Uma boa localização do repositório equilibra a latência, a disponibilidade e os custos de largura de banda para os consumidores de dados. A sua organização também pode ter requisitos de conformidade específicos.

Considerações sobre a localização

Esta secção descreve os motivos pelos quais pode querer criar um repositório na mesma região que outros Google Cloud serviços.

Pode reduzir a latência e os custos de saída de rede criando repositórios na mesma região onde executa o GKE, o Cloud Run, o Cloud Build e outros serviços Google Cloud que interagem com o repositório. Não é cobrada nenhuma taxa de saída do Artifact Registry para outros serviços Google Cloud na mesma região.

Embora não haja custos de saída de uma região múltipla para um serviçoGoogle Cloud numa região correspondente, esta tabela de preços aplica-se apenas a um conjunto limitado de regiões.

  • Para a us multirregião, a saída para uma região nos Estados Unidos, como us-central, não tem custo financeiro. A saída para qualquer região no Canadá ou na América do Sul tem custo financeiro.
  • Para a asia multirregião, 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ó pode usar o streaming de imagens no GKE e no Dataproc Serverless se as imagens de contentores estiverem armazenadas em repositórios do Artifact Registry na mesma região que as suas cargas de trabalho ou numa região múltipla que corresponda à região com as suas cargas de trabalho. O streaming de imagens pode reduzir significativamente o tempo de inicialização da carga de trabalho quando usa imagens de contentores maiores, uma vez que as cargas de trabalho podem começar antes de a imagem completa ser transferida.

Considere a localização dos consumidores fora de Google Cloud. Por exemplo, se a sua equipa de programadores na Austrália precisar de transferir artefactos do Artifact Registry para as respetivas estações de trabalho locais, um repositório numa região australiana reduz a latência e incorre em custos de saída mais baixos do que um repositório localizado noutro continente.

Restringir localizações de repositórios

Se precisar de agir em conformidade com regulamentos ou políticas que exijam o armazenamento de dados em regiões específicas, pode incluir uma restrição de localizações de recursos na sua política de organização que só permita a criação de repositórios em regiões em conformidade. Google Cloud O Artifact Registry só aplica a restrição depois de a incluir na política da sua organização. Se tiver repositórios existentes em localizações não conformes, tem de mover os seus artefactos para um repositório numa localização em conformidade e, em seguida, eliminar o repositório não conforme.

Políticas de limpeza

Uma política de limpeza do Artifact Registry define critérios para eliminar automaticamente versões de artefactos de que já não precisa ou manter artefactos que quer armazenar indefinidamente.

As políticas de limpeza são úteis se armazenar muitas versões dos seus artefactos, mas só precisar de manter versões específicas que lança para produção. Pode definir políticas de eliminação com critérios para eliminar artefactos e políticas de conservação com critérios para reter artefactos.

Se uma versão de artefacto corresponder aos critérios de uma política de eliminação e de uma política de conservação, o Artifact Registry aplica a política de conservação.

Elimine políticas

As políticas de eliminação eliminam artefactos que correspondem aos seguintes critérios obrigatórios:

  • Estado da etiqueta: indica se a política deve verificar a existência de artefactos etiquetados ou não etiquetados. Os artefactos são etiquetados quando envia ou extrai uma imagem para ou de um repositório. Para mais informações sobre as etiquetas do Docker, consulte o artigo Conceitos de contentores.

    • Qualquer estado da etiqueta: ignora o estado da etiqueta e aplica-se a artefactos etiquetados e não etiquetados.
    • Etiquetado: aplica-se apenas a artefactos etiquetados.
    • Sem etiqueta: aplica-se apenas a artefactos sem etiqueta.

    Os formatos que não suportam etiquetas são tratados como untagged. Não é possível eliminar artefactos etiquetados em repositórios com etiquetas imutáveis ativadas.

    Para mais informações sobre o estado da etiqueta no que se refere às políticas de limpeza, consulte a referência TagState.

Seguem-se formas opcionais de definir a sua política de eliminação:

  • Prefixos de etiquetas: é uma lista de prefixos de etiquetas separados por vírgulas. Por exemplo, os prefixos test e staging corresponderiam a imagens com as etiquetas testenv e staging-1.5. tagState tem de estar definido como TAGGED para usar prefixos de etiquetas.
    • Prefixos de versão: - é uma lista separada por vírgulas de prefixos de versão do artefacto. Por exemplo, v1, v2 corresponderia às versões v1.5, v2.0alpha e v10.2.
  • Prefixos de pacotes: é uma lista de prefixos de nomes de artefactos. Pode introduzir vários prefixos premindo Enter ou , entre os prefixos. Por exemplo, red, blue criaria dois prefixos, red e blue, e corresponderia aos nomes dos artefactos red-team, redis> e bluebird.
  • Mais antigo que: é um tempo mínimo desde que uma versão do artefacto foi carregada para o repositório, especificado como uma duração. Por exemplo, 30d é de 30 dias. Pode especificar durações de segundos, minutos, horas ou dias anexando s, m, h ou d, respetivamente.
  • Mais recente que: é um tempo máximo desde que foi carregada uma versão do artefacto para o repositório, especificado como uma duração. Por exemplo, 30d é de 30 dias.

Manter políticas

As políticas de conservação mantêm os artefactos que correspondem às mesmas condições que as políticas de eliminação ou um número definido das versões mais recentes.

Por exemplo, dado um repositório que contém os seguintes artefactos:

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 3 versões de pacotes que correspondam aos Prefixos de pacotes: {release-xyz}, apenas release-xyz-v1 e release-xyz-v2 são mantidos.

As eliminações acionadas por políticas de eliminação contam para a sua quota de pedidos de eliminação por projeto do Artifact Registry.

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

Suporte do domínio gcr.io

O Artifact Registry suporta o alojamento de imagens no domínio gcr.io. Se estiver a fazer a transição do Container Registry para o Artifact Registry, pode configurar repositórios gcr.io no Artifact Registry para minimizar as alterações à sua automatização e fluxos de trabalho existentes. Estes repositórios oferecem:

  • Redirecionamento de pedidos para o domínio gcr.io.
  • Criação de repositórios gcr.io quando a primeira imagem é enviada para um nome de anfitrião gcr.io para compatibilidade com o comportamento do Container Registry.

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

Estrutura do projeto

A sua hierarquia de recursos é a forma como organiza os seus recursos em Google Cloud projetos. A estrutura que escolher depende de fatores como os requisitos de governação de dados, os limites de confiança e a estrutura da equipa.

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

Centralize os repositórios
Crie todos os repositórios num único projeto e, em seguida, conceda acesso a diretores de outros projetos ao nível do repositório. Esta abordagem pode ser mais eficaz quando uma única pessoa ou equipa gere a administração do repositório e o acesso ao repositório em toda a sua organização.
Também pode simplificar a configuração de repositórios virtuais, uma vez que só precisa de ativar e gerir uma única instância do Artifact Registry.
Repositórios específicos do projeto
Crie repositórios em projetos que armazenam e transferem artefactos. Esta abordagem pode ser necessária quando tem políticas de administração de dados ou limites de confiança que requerem uma maior separação ao nível do projeto e controlo dos recursos.

Controlo de acesso

Os repositórios só estão acessíveis com as autorizações adequadas, a menos que configure o repositório para acesso público. Pode conceder autorizações ao nível do projeto ou do repositório.

Alguns Google Cloud serviços usam contas de serviço predefinidas com autorizações predefinidas para repositórios no mesmo Google Cloud projeto. No entanto, estas predefinições podem não ser adequadas para o seu processo de desenvolvimento de software ou podem não estar em conformidade com os requisitos de segurança ou de políticas na sua organização. O administrador do repositório tem de conceder explicitamente a estes serviços acesso aos repositórios se:

  • O Artifact Registry está num projeto diferente do serviço que está a interagir com ele.
  • Está a usar funções de IAM personalizadas com as contas de serviço predefinidas em vez da função predefinida.
  • Não está a usar a conta de serviço predefinida para o serviço Google Cloud .
  • Está a configurar repositórios virtuais. Tem de conceder explicitamente à conta de serviço do Artifact Registry acesso aos repositórios a montante.

Para outros responsáveis que necessitam de acesso a repositórios, o administrador do repositório tem de conceder acesso. Seguindo o princípio de segurança do menor privilégio, conceda as autorizações mínimas necessárias. Por exemplo:

  • Implementa imagens de contentores no Artifact Registry em clusters do GKE em vários projetos diferentes. A conta de serviço para nós nestes clusters só requer acesso de leitura aos repositórios.
  • Tem um repositório de desenvolvimento para aplicações em desenvolvimento e um repositório de produção para aplicações lançadas. Os programadores precisam de acesso de leitura e escrita ao repositório de desenvolvimento e acesso só de leitura ao repositório de produção.
  • Tem um repositório de demonstração com aplicações de exemplo. A sua equipa de vendas só precisa de acesso só de leitura para transferir as demonstrações.

Restrinja as transferências de artefactos

Pode restringir as transferências de artefactos com regras de transferência. As regras de transferência permitem-lhe autorizar ou recusar transferências de artefactos dos seus repositórios e pacotes. Também pode definir condições para que a regra se aplique a etiquetas ou versões específicas.

Para ver detalhes sobre como funcionam as regras de transferências, consulte a secção Restrinja as transferências de artefactos da vista geral de controle o acesso e proteja os artefactos.

Encriptação de dados

Por predefinição,o Google Cloud Google encripta automaticamente os dados quando estão em repouso através de chaves de encriptaçãocom tecnologia Google Cloud. Se tiver requisitos de conformidade ou regulamentares específicos relacionados com as chaves que protegem os seus dados, pode criar repositórios encriptados com chaves de encriptação geridas pelo cliente (CMEK).

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

Etiquetas e marcadores

As etiquetas oferecem uma forma de organizar recursos específicos de um Google Cloud serviço. No Artifact Registry, pode adicionar etiquetas a repositórios para os agrupar ou filtrar listas de repositórios por etiqueta. Por exemplo, pode usar etiquetas para agrupar repositórios por fase de desenvolvimento ou por equipa para fins de automatização ou faturação. Para mais informações sobre como criar e usar etiquetas de repositório, consulte o artigo Etiquetar repositórios.

Também pode aplicar etiquetas a repositórios. Embora as etiquetas se destinem principalmente a organizar e filtrar recursos específicos do serviço, as etiquetas destinam-se ao controlo programático de políticas numa Google Cloud organização. Para mais informações, consulte o artigo Etiquetar repositórios.

O que se segue