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 uma região ou multirregião específica 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 está associado a um formato de artefato específico. Por exemplo, um repositório Python armazena pacotes Python. É possível criar vários repositórios para cada formato no mesmo projeto do Google Cloud.

Modos de repositório

Há vários modos de repositório. Cada modo tem uma finalidade diferente. Por isso, não é possível alterar 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 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.

Repositório remoto

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

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

Repositório virtual

Um repositório somente leitura que funciona como um ponto de acesso único para fazer o download, instalar ou implantar artefatos do mesmo formato de um ou mais repositórios upstream. Um repositório upstream pode ser 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ência configurando a política upstream para priorizar repositórios com seus artefatos particulares em vez dos repositórios remotos que armazenam em cache artefatos públicos.

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 projetos do Google Cloud. 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.

No projeto de desenvolvimento, uma equipe de desenvolvimento em Java usa o Cloud Build para criar um aplicativo Java.
- O build pode solicitar dependências Java públicas 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 o upload do pacote para o repositório Maven padrão no projeto do componente.
No projeto de ambiente de execução, o Cloud Build coloca o aplicativo Java em um contêiner.

O build usa o repositório virtual 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 Java públicas do mesmo repositório virtual.
No projeto de ambiente de execução, o Cloud Build faz o upload da imagem do contêiner criada para um repositório padrão do Docker.
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 solicita 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 os serviços do Google Cloud tem os benefícios descritos em Local do repositório.

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, poderá configurar repositórios gcr.io do Artifact Registry para minimizar 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 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

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 os custos de latência, disponibilidade e 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

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

Reduza os custos de latência e 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 para 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 multirregião para um serviço do Google Cloud em uma região correspondente, esse preço se aplica apenas 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, para qualquer região no Canadá ou na América do Sul.
- 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 Dataproc sem servidor se as imagens de contêiner estiverem armazenadas em repositórios do Artifact Registry na mesma região das 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 do download da imagem inteira.
Considere a localização dos consumidores fora do Google Cloud. Por exemplo, se sua 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 gerará taxas de saída mais baixas do que um repositório localizado em outro continente.

Como restringir locais do repositório

Se for necessário 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 política da organização do Google Cloud que permita a criação de repositórios apenas em regiões compatíveis. 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 seus artefatos para um repositório em um local compatível e exclua o repositório não compatível.

Estrutura do projeto

A hierarquia de recursos é a maneira de organizar seus recursos nos projetos do Google Cloud. 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 seus repositórios em organizações com vários projetos.

Centralize repositórios: Criar todos os repositórios em um único projeto e conceder acesso aos 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 de repositórios e o 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 de projetos: Criar 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 no nível do projeto.

Controle de acesso

Os repositórios só podem ser acessados com as permissões adequadas, 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 serviços do Google Cloud, como o Cloud Build, o Cloud Run e o GKE, usam contas de serviço 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 processo de desenvolvimento de software ou podem não estar em conformidade com os requisitos de segurança ou política da organização. O administrador do repositório precisará conceder explicitamente a esses serviços acesso aos repositórios se:

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

Para outros principais que exigem acesso aos repositórios, o administrador do repositório precisa conceder esse acesso. Seguindo o princípio de segurança de privilégio mínimo, 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 para nós nesses clusters requer apenas acesso de leitura aos repositórios.
Você tem um repositório de desenvolvimento para aplicativos que estão em desenvolvimento e de produção para aplicativos que foram lançados. Os desenvolvedores precisam de 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 requer apenas acesso somente leitura para fazer o download das demonstrações.

Criptografia de dados

Por padrão, o Google Cloud automaticamente criptografa os dados quando em repouso por meio de chaves de criptografia gerenciadas pelo Google. Se você tiver requisitos regulamentares ou de compliance específicos relacionados às chaves que protegem seus dados, crie repositórios criptografados com chaves de criptografia gerenciadas pelo cliente (CMEK, na sigla em inglês).

O Artifact Registry também oferece suporte a restrições da política 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 de um serviço do Google Cloud. No Artifact Registry, é possível adicionar identificadores 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 rotular repositórios.

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