Nesta página, descrevemos como configurar o Cloud Build para armazenar artefatos em um repositório do Artifact Registry.
Antes de começar
- Se o repositório de destino não existir no Artifact Registry, Crie um novo repositório.
Se o Cloud Build e o repositório estiverem em projetos diferentes ou se você estiver usando uma conta de serviço especificada pelo usuário para executar builds, conceda o papel de escritor do registro de artefatos à conta de serviço do build no projeto com os repositórios.
A conta de serviço padrão do Cloud Build tem acesso para executar as seguintes ações com um repositório no mesmo projeto do Google Cloud:
- Fazer upload e download de artefatos
- Criar repositórios gcr.io no Artifact Registry
Configurar um build do Docker
Depois de conceder permissões ao repositório de destino, você vai poder configure seu build.
Para configurar o build:
No arquivo de configuração do build, adicione a etapa para criar e marcar a imagem.
steps: - name: 'gcr.io/cloud-builders/docker' args: [ 'build', '-t', '${_LOCATION}-docker.pkg.dev/$PROJECT_ID/${_REPOSITORY}/${_IMAGE}', '.' ] images: - '${_LOCATION}-docker.pkg.dev/$PROJECT_ID/${_REPOSITORY}/${_IMAGE}'
Este snippet usa substituições do Cloud Build. Essa abordagem é útil use o mesmo arquivo de configuração de build para enviar imagens aos repositórios para ambientes diferentes, como teste, preparação ou produção.
${_LOCATION}
,${_REPOSITORY}
e${_IMAGE}
estão substituição definida pelo usuário para o repositório local, nome do repositório e imagem. Você especifica os valores desses variáveis no tempo de build.$PROJECT_ID
é uma substituição padrão. que o Cloud Build resolve com o ID do projeto do Google Cloud para o build.- Se você executar o comando
gcloud builds submit
, o Cloud Build usa o ID do projeto ativo na sessão da gcloud. - Se você usa um gatilho de compilação, o Cloud Build usa o ID do em que o Cloud Build está sendo executado.
Como alternativa, você pode usar uma substituição definida pelo usuário em vez de
$PROJECT_ID
para especificar um ID do projeto no tempo de build.- Se você executar o comando
Quando estiver tudo pronto para executar o build, especifique os valores dos valores definidos pelo usuário de substituições. Por exemplo, este comando substitui:
us-east1
para o local do repositóriomy-repo
, como o nome do repositório.my-image
para o nome da imagem
gcloud builds submit --config=cloudbuild.yaml \ --substitutions=_LOCATION="us-east1",_REPOSITORY="my-repo",_IMAGE="my-image" .
Configurar um build do Go
Depois de conceder permissões ao repositório de destino, você vai poder configure seu build. As instruções a seguir descrevem como configurar seu build para fazer upload de um módulo Go para um repositório Go.
Para configurar seu build:
Para fazer upload de um módulo Go para o repositório Go no seu build, adicione o seguinte etapas no arquivo de configuração de build:
steps: - name: gcr.io/cloud-builders/gcloud args: - 'artifacts' - 'go' - 'upload' - '--project=$PROJECT_ID' - '--location=${_LOCATION}' - '--repository=${_REPOSITORY}' - '--module-path=${_MODULE_PATH}' - '--version=$TAG_NAME'
O arquivo de configuração do build inclui o Cloud Build substituições. Essa abordagem é útil se você quiser usar o mesmo arquivo de configuração de build para fazer upload de pacotes para repositórios de ambientes diferentes, como teste, preparo ou produção.
${_LOCATION}
,${_REPOSITORY}
e${_MODULE_PATH}
são definidos pelo usuário do repositório, do nome do repositório e do módulo caminho. Você especifica os valores dessas variáveis no tempo de build.$PROJECT_ID
e$TAG_NAME
são substituições padrão que o Cloud Build substitui pelo seguinte:$PROJECT_ID
é substituído pelo ID do projeto do Google Cloud para o build.- Se você executar o comando
gcloud builds submit
, o Cloud Build usa o ID do projeto ativo na sessão da gcloud. - Se você usa um gatilho de compilação, o Cloud Build usa o ID do em que o Cloud Build está sendo executado.
Como alternativa, você pode usar uma substituição definida pelo usuário em vez de
$PROJECT_ID
para especificar um ID do projeto no tempo de build.- Se você executar o comando
$TAG_NAME
é substituído pelo nome da sua tag para compatibilidade com o Go de usar tags do Git como números de versão.
Para instalar o pacote a partir do repositório do Go, adicione as seguintes etapas ao seu arquivo de configuração de build para:
- Adicionar um endpoint regional do Cloud Build ao repositório
para o arquivo
.netrc
. - Execute a ferramenta auxiliar de credenciais para atualizar os tokens OAuth.
- Execute o comando
go run
. Também é possível alterar isso parago build
para compilar o módulo,go test
para executar testes ougo mod tidy
para fazer o download. as dependências.
Para a etapa do comando
go
, oGOPROXY
é definido como a O repositório do Cloud Build que hospeda dependências privadas. É possível adicionar o proxy público à listaGOPROXY
separada por vírgulas se o módulo tiver dependências públicas.steps: - name: golang entrypoint: go args: ['run', 'github.com/GoogleCloudPlatform/artifact-registry-go-tools/cmd/auth@v0.1.0', 'add-locations', '--locations=${_LOCATION}'] env: # Set GOPROXY to the public proxy to pull the credential helper tool - 'GOPROXY=https://proxy.golang.org' - name: golang entrypoint: go args: ['run', 'github.com/GoogleCloudPlatform/artifact-registry-go-tools/cmd/auth@v0.1.0', 'refresh'] env: # Set GOPROXY to the public proxy to pull the credential helper tool - 'GOPROXY=https://proxy.golang.org' - name: golang entrypoint: go args: ['run', '.'] env: - 'GOPROXY=https://${_LOCATION}-go.pkg.dev/${_PROJECT_ID}/${_REPOSITORY}' options: env: # Disable GO sumdb checks for private modules. - 'GONOSUMDB=${_MODULE_PATH}'
- Adicionar um endpoint regional do Cloud Build ao repositório
para o arquivo
Quando estiver tudo pronto para executar o build, especifique os valores dos valores definidos pelo usuário de substituições. Por exemplo, este comando substitui:
us-east1
para o local do repositóriomy-project
para o ID do projeto.my-repo
, como o nome do repositório.example.com/greetings
para o caminho do módulo.
gcloud builds submit --config=cloudbuild.yaml \ --substitutions=_LOCATION="us-east1",_PROJECT_ID="my-project",_REPOSITORY="my-repo",_MODULE_PATH="example.com/greetings" .
Configurar um build Java
Depois de conceder permissões ao repositório de destino, você estará pronto para configurar o build. As instruções a seguir descrevem como configurar seu build para fazer upload de um pacote Java para um repositório Maven.
Para configurar seu build:
Configure a autenticação para Maven. Certifique-se de especificar o projeto de destino e o repositório corretos no arquivo
pom.xml
.No arquivo de configuração de versão do Cloud Build, adicione a etapa para fazer upload do pacote com o Maven:
steps: - name: gcr.io/cloud-builders/mvn args: ['deploy']
Quando seu arquivo de configuração de build estiver pronto, inicie o build com o seguinte comando:
gcloud builds submit
Configurar um build do Node.js
Depois de conceder permissões ao repositório de destino, você vai poder configure seu build. As instruções a seguir descrevem como configurar seu build para fazer upload de um pacote Node.js em um repositório npm.
Para configurar o build:
Adicione o repositório do Artifact Registry ao arquivo
.npmrc
no Node.js em um projeto de IA. O arquivo está localizado no diretório que contém o arquivopackage.json
.@SCOPE:registry=https://LOCATION-npm.pkg.dev/PROJECT_ID/REPOSITORY //LOCATION-npm.pkg.dev/PROJECT_ID/REPOSITORY/:always-auth=true
- SCOPE-NAME é o nome do escopo do npm a ser associado ao repositório. O uso de escopos garante que você sempre publicar e instalar pacotes do repositório correto.
- PROJECT_ID é o ID do projeto no Google Cloud.
- LOCATION é o local regional ou multirregional do repositório.
- REPOSITORY é o nome do repositório.
Adicione um script ao arquivo
package.json
no seu projeto que atualize o token de acesso para autenticação com o repositório."scripts": { "artifactregistry-login": "npx google-artifactregistry-auth" }
No arquivo de configuração da versão, adicione a etapa para fazer upload do pacote para o repositório.
steps: - name: gcr.io/cloud-builders/npm args: ['run', 'artifactregistry-login'] - name: gcr.io/cloud-builders/npm args: ['publish', '${_PACKAGE}']
${_PACKAGE}
é um Cloud Build. substituição que representa seu projeto Node.js diretório. É possível especificar o diretório ao executar o comando para executar o build.Por exemplo, este comando faz upload do pacote de um diretório chamado
src
:gcloud builds submit --config=cloudbuild.yaml \ --substitutions=_PACKAGE="src" .
Configurar um build do Python
Depois de conceder permissões ao repositório de destino, você vai poder configure seu build. As instruções a seguir descrevem como configurar seu build para carregar um pacote Python em um repositório Python e instalar o pacote usando pip.
Para criar e conteinerizar um aplicativo Python e, em seguida, enviá-lo por push para uma repositório do Docker, consulte Como criar aplicativos Python na Documentação do Cloud Build.
Para configurar seu build:
No diretório que contém o arquivo de configuração de build do Cloud Build, crie um arquivo chamado
requirements.txt
com as seguintes dependências:twine keyrings.google-artifactregistry-auth
- Twine é para fazer upload de pacotes para o Artifact Registry.
- keyrings.google-artifactregistry-auth é o back-end do chaveiro do Artifact Registry que processa a autenticação com o Artifact Registry para pip e Twine.
Para fazer upload de um pacote do Python para o repositório do Python no build, adicione o Siga estas etapas para o arquivo de configuração de build:
steps: - name: python entrypoint: pip args: ["install", "-r", "requirements.txt", "--user"] - name: python entrypoint: python args: - '-m' - 'twine' - 'upload' - '--repository-url' - 'https://${_LOCATION}-python.pkg.dev/$PROJECT_ID/${_REPOSITORY}/' - 'dist/*'
Neste snippet, a primeira etapa instala o Twine e o Artifact Registry back-end do keyring. A segunda etapa faz o upload dos arquivos Python criados no subdiretório
dist
. Ajuste os caminhos pararequirements.txt
e seu que criamos arquivos Python se eles não corresponderem ao snippet.O caminho do repositório inclui substituições do Cloud Build. Essa abordagem é útil se você quiser usar o mesmo arquivo de configuração de build para fazer upload de pacotes para repositórios de ambientes diferentes, como teste, preparo ou produção.
${_LOCATION}
e${_REPOSITORY}
são substituições definidas pelo usuário para o local, o nome do repositório e o nome do pacote. Você especifica valores dessas variáveis no tempo de build.$PROJECT_ID
é uma substituição padrão. que o Cloud Build resolve com o ID do projeto do Google Cloud para o build.- Se você executar o comando
gcloud builds submit
, o Cloud Build usa o ID do projeto ativo na sessão da gcloud. - Se você usa um gatilho de compilação, o Cloud Build usa o ID do em que o Cloud Build está sendo executado.
Como alternativa, você pode usar uma substituição definida pelo usuário em vez de
$PROJECT_ID
para especificar um ID do projeto no tempo de build.- Se você executar o comando
Para instalar o pacote a partir do repositório do Python, adicione uma etapa ao seu build arquivo de configuração que executa o comando
pip install
.steps: - name: python entrypoint: pip args: - 'install' - '--index-url' - 'https://${_LOCATION}-python.pkg.dev/$PROJECT_ID/${_REPOSITORY}/simple/' - '${_PACKAGE}' - '--verbose'
Esse snippet inclui uma substituição
${_PACKAGE}
adicional para o nome do pacote.Quando estiver tudo pronto para executar o build, especifique os valores dos valores definidos pelo usuário de substituições. Por exemplo, este comando substitui:
us-east1
para o local do repositóriomy-repo
, como o nome do repositório.my-package
como o nome do pacote.
gcloud builds submit --config=cloudbuild.yaml \ --substitutions=_LOCATION="us-east1",_REPOSITORY="my-repo",_PACKAGE="my-package" .
A seguir
- Saiba como implantar no Cloud Run.
- Saiba como implantar no Google Kubernetes Engine.