Questa pagina descrive come configurare Cloud Build per archiviare gli artefatti creati in un repository Artifact Registry.
Prima di iniziare
- Se il repository di destinazione non esiste in Artifact Registry, crea un nuovo repository.
Se Cloud Build e il repository si trovano in progetti diversi o se utilizzi un account di servizio specificato dall'utente per eseguire le build, concedi il ruolo Writer Artifact Registry all'account di servizio di build nel progetto con i repository.
L'account di servizio Cloud Build predefinito può eseguire le seguenti azioni con un repository nello stesso progetto Google Cloud:
- Carica e scarica gli artefatti
- Crea repository gcr.io in Artifact Registry
Configura una build Docker
Dopo aver concesso le autorizzazioni al repository di destinazione, puoi configurare la build.
Per configurare la build:
Nel file di configurazione della build, aggiungi il passaggio per creare e taggare l'immagine.
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}'
Questo snippet utilizza le sostituzioni di Cloud Build. Questo approccio è utile se vuoi utilizzare lo stesso file di configurazione della build per eseguire il push delle immagini nei repository per ambienti diversi, ad esempio test, gestione temporanea o produzione.
${_LOCATION}
,${_REPOSITORY}
e${_IMAGE}
sono sostituzioni definite dall'utente per la località, il nome e l'immagine del repository. Devi specificare i valori per queste variabili al momento della creazione.$PROJECT_ID
è una sostituzione predefinita che Cloud Build risolve con l'ID progetto Google Cloud della build.- Se esegui il comando
gcloud builds submit
, Cloud Build utilizza l'ID progetto attivo nella sessione gcloud. - Se utilizzi un trigger di build, Cloud Build utilizza l'ID del progetto su cui è in esecuzione Cloud Build.
In alternativa, puoi utilizzare una sostituzione definita dall'utente anziché
$PROJECT_ID
in modo da poter specificare un ID progetto al momento della creazione.- Se esegui il comando
Quando è tutto pronto per eseguire la build, specifica i valori per le sostituzioni definite dall'utente. Ad esempio, questo comando sostituisce:
us-east1
per la posizione del repositorymy-repo
per il nome del repositorymy-image
per il nome dell'immagine
gcloud builds submit --config=cloudbuild.yaml \ --substitutions=_LOCATION="us-east1",_REPOSITORY="my-repo",_IMAGE="my-image" .
Configurare una build Go
Dopo aver concesso le autorizzazioni al repository di destinazione, puoi configurare la build. Le istruzioni seguenti descrivono la configurazione della build per caricare un modulo Go in un repository Go.
Per configurare la build:
Per caricare un modulo Go nel repository Go nella build, aggiungi i seguenti passaggi al file di configurazione della 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'
Il file di configurazione della build include le sostituzioni di Cloud Build. Questo approccio è utile se vuoi utilizzare lo stesso file di configurazione di compilazione per caricare pacchetti nei repository per ambienti diversi, come test, gestione temporanea o produzione.
${_LOCATION}
,${_REPOSITORY}
e${_MODULE_PATH}
sono sostituzioni definite dall'utente per località, nome repository e percorso modulo. Devi specificare i valori di queste variabili al momento della creazione.$PROJECT_ID
e$TAG_NAME
sono sostituzioni predefinite che Cloud Build sostituisce con quanto segue:$PROJECT_ID
viene sostituito con l'ID progetto Google Cloud per la build.- Se esegui il comando
gcloud builds submit
, Cloud Build utilizza l'ID progetto attivo nella sessione gcloud. - Se utilizzi un trigger di build, Cloud Build utilizza l'ID del progetto su cui è in esecuzione Cloud Build.
In alternativa, puoi utilizzare una sostituzione definita dall'utente anziché
$PROJECT_ID
in modo da poter specificare un ID progetto al momento della creazione.- Se esegui il comando
$TAG_NAME
viene sostituito con il nome del tag per supportare la convenzione Go che prevede l'utilizzo dei tag Git come numeri di versione.
Per installare il pacchetto dal repository Go, aggiungi i seguenti passaggi al file di configurazione della build a:
- Aggiungi al file
.netrc
un endpoint Cloud Build a livello di regione nella località del repository. - Esegui lo strumento di supporto per le credenziali per aggiornare i token OAuth.
- Esegui il comando
go run
. Puoi anche modificarlo ingo build
per compilare il modulo,go test
per eseguire i test ogo mod tidy
per scaricare le dipendenze.
Per il passaggio del comando
go
,GOPROXY
è impostato sul repository Cloud Build che ospita le dipendenze private. Puoi aggiungere il proxy pubblico all'elencoGOPROXY
separato da virgole se il modulo ha dipendenze pubbliche.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}'
- Aggiungi al file
Quando è tutto pronto per eseguire la build, specifica i valori per le sostituzioni definite dall'utente. Ad esempio, questo comando sostituisce:
us-east1
per la posizione del repositorymy-project
per l'ID progettomy-repo
per il nome del repositoryexample.com/greetings
per il percorso del modulo
gcloud builds submit --config=cloudbuild.yaml \ --substitutions=_LOCATION="us-east1",_PROJECT_ID="my-project",_REPOSITORY="my-repo",_MODULE_PATH="example.com/greetings" .
Configura una build Java
Dopo aver concesso le autorizzazioni al repository di destinazione, puoi configurare la build. Le istruzioni seguenti descrivono la configurazione della build per caricare un pacchetto Java in un Repository Maven.
Per configurare la build:
Configura l'autenticazione per Maven. Assicurati di specificare il progetto e il repository di destinazione corretti nel file
pom.xml
.Nel file di configurazione della build di Cloud Build, aggiungi il passaggio per caricare il pacchetto con Maven:
steps: - name: gcr.io/cloud-builders/mvn args: ['deploy']
Quando il file di configurazione della build è pronto, avvia la build con il seguente comando:
gcloud builds submit
Configura una build Node.js
Dopo aver concesso le autorizzazioni al repository di destinazione, puoi configurare la build. Le istruzioni seguenti descrivono la configurazione della build per caricare un pacchetto Node.js in un repository npm.
Per configurare la build:
Aggiungi il repository Artifact Registry al file
.npmrc
nel tuo progetto Node.js. Il file si trova nella directory del filepackage.json
.@SCOPE:registry=https://LOCATION-npm.pkg.dev/PROJECT_ID/REPOSITORY //LOCATION-npm.pkg.dev/PROJECT_ID/REPOSITORY:always-auth=true
- SCOPE-NAME è il nome dell'ambito npm da associare al repository. L'uso degli ambiti garantisce la pubblicazione e l'installazione dei pacchetti dal repository corretto.
- PROJECT_ID è l'ID del tuo progetto Google Cloud.
- LOCATION è la località a livello di una o più regioni del repository.
- REPOSITORY è il nome del repository.
Aggiungi uno script al file
package.json
nel progetto che aggiorni il token di accesso per l'autenticazione con il repository."scripts": { "artifactregistry-login": "npx google-artifactregistry-auth" }
Nel file di configurazione della build, aggiungi il passaggio per caricare il pacchetto nel repository.
steps: - name: gcr.io/cloud-builders/npm args: ['run', 'artifactregistry-login'] - name: gcr.io/cloud-builders/npm args: ['publish', '${_PACKAGE}']
${_PACKAGE}
è una sostituzione di Cloud Build che rappresenta la directory del progetto Node.js. Puoi specificare la directory quando esegui il comando per eseguire la build.Ad esempio, questo comando carica il pacchetto da una directory denominata
src
:gcloud builds submit --config=cloudbuild.yaml \ --substitutions=_PACKAGE="src" .
Configura una build Python
Dopo aver concesso le autorizzazioni al repository di destinazione, puoi configurare la build. Le seguenti istruzioni descrivono la configurazione della build per il caricamento di un pacchetto Python in un repository Python e l'installazione del pacchetto utilizzando pip.
Per creare e containerizzare un'applicazione Python ed eseguirne il push in un repository Docker, consulta Creazione di applicazioni Python nella documentazione di Cloud Build.
Per configurare la build:
Nella directory con il file di configurazione della build di Cloud Build, crea un file denominato
requirements.txt
con le seguenti dipendenze:twine keyrings.google-artifactregistry-auth
- Twine consente di caricare pacchetti su Artifact Registry.
- keyrings.google-artifactregistry-auth è il backend del keyring di Artifact Registry che gestisce l'autenticazione con Artifact Registry per pip e Twine.
Per caricare un pacchetto Python nel repository Python nella build, aggiungi i seguenti passaggi al file di configurazione della 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/*'
In questo snippet, il primo passaggio installa Twine e il backend keyring di Artifact Registry. Nel secondo passaggio vengono caricati i file Python creati nella sottodirectory
dist
. Modifica i percorsi direquirements.txt
e dei file Python creati se non corrispondono allo snippet.Il percorso del repository include sostituzioni di Cloud Build. Questo approccio è utile se vuoi utilizzare lo stesso file di configurazione di compilazione per caricare pacchetti nei repository per ambienti diversi, come test, gestione temporanea o produzione.
${_LOCATION}
e${_REPOSITORY}
sono sostituzioni definite dall'utente per la posizione del repository, il nome del repository e il nome del pacchetto. Devi specificare i valori di queste variabili al momento della creazione.$PROJECT_ID
è una sostituzione predefinita che Cloud Build risolve con l'ID progetto Google Cloud della build.- Se esegui il comando
gcloud builds submit
, Cloud Build utilizza l'ID progetto attivo nella sessione gcloud. - Se utilizzi un trigger di build, Cloud Build utilizza l'ID del progetto su cui è in esecuzione Cloud Build.
In alternativa, puoi utilizzare una sostituzione definita dall'utente anziché
$PROJECT_ID
in modo da poter specificare un ID progetto al momento della creazione.- Se esegui il comando
Per installare il pacchetto dal repository Python, aggiungi un passaggio al file di configurazione della build che esegue il comando
pip install
.steps: - name: python entrypoint: pip args: - 'install' - '--index-url' - 'https://${_LOCATION}-python.pkg.dev/$PROJECT_ID/${_REPOSITORY}/simple/' - '${_PACKAGE}' - '--verbose'
Questo snippet include un'ulteriore sostituzione
${_PACKAGE}
per il nome del pacchetto.Quando è tutto pronto per eseguire la build, specifica i valori per le sostituzioni definite dall'utente. Ad esempio, questo comando sostituisce:
us-east1
per la posizione del repositorymy-repo
per il nome del repositorymy-package
per il nome del pacchetto.
gcloud builds submit --config=cloudbuild.yaml \ --substitutions=_LOCATION="us-east1",_REPOSITORY="my-repo",_PACKAGE="my-package" .
Passaggi successivi
- Scopri come eseguire il deployment su Cloud Run.
- Scopri come eseguire il deployment su Google Kubernetes Engine.