Questa pagina fornisce le best practice per l'accelerazione delle build di Cloud Build.
Creazione di container più snelli
Quando inserisci un'applicazione in un container, i file non necessari in fase di runtime, ad esempio le dipendenze in fase di compilazione e i file intermedi, possono essere inclusi inavvertitamente nell'immagine container. Questi file non necessari possono aumentare le dimensioni dell'immagine del container e aggiungere tempo e costi aggiuntivi man mano che l'immagine si sposta tra il registro delle immagini container e il runtime del container.
Per ridurre le dimensioni dell'immagine container, separa la creazione dell'applicazione, insieme agli strumenti utilizzati per crearla, dall'assemblaggio del container di runtime.
Per saperne di più, consulta Creazione di container più snelli.
Utilizzo di un'immagine Docker memorizzata nella cache
Il modo più semplice per aumentare la velocità di creazione dell'immagine Docker è
specificare un'immagine memorizzata nella cache che può essere utilizzata per le build successive. Puoi specificare l'immagine memorizzata nella cache aggiungendo l'argomento --cache-from nel file di configurazione della build, che indicherà a Docker di eseguire la build utilizzando questa immagine come origine della cache.
Ogni immagine Docker è costituita da livelli impilati. L'utilizzo di --cache-from ricompila
tutti i livelli dal livello modificato fino alla fine della build. Pertanto,
l'utilizzo di --cache-from non è utile se modifichi un livello nelle fasi
precedenti della build Docker.
Ti consigliamo di utilizzare sempre --cache-from per le build, ma tieni presente
i seguenti avvertimenti:
- Devi disporre di un'immagine Docker precedentemente creata da cui eseguire la memorizzazione nella cache.
- Puoi utilizzare
--cache-fromsolo per le build Docker; non puoi utilizzarlo per builder che creano altri tipi di artefatti. - L'immagine memorizzata nella cache deve essere recuperata da un registro, il che potrebbe aumentare il tempo necessario per la creazione.
I seguenti passaggi spiegano come eseguire la build utilizzando un'immagine memorizzata nella cache in precedenza:
YAML
Nella configurazione della build, aggiungi le istruzioni per:
- Estrai l'immagine memorizzata nella cache da Artifact Registry. Il passaggio di build
docker pullimpostaentrypointsubash, il che ti consente di eseguire il comando e ignorare l'errore restituito. Questa configurazione è obbligatoria quando crei un'immagine per la prima volta edocker pullnon esiste un'immagine da estrarre. Aggiungi un argomento
--cache-fromper utilizzare l'immagine per le ricompilazioni.steps: - name: 'gcr.io/cloud-builders/docker' entrypoint: 'bash' args: ['-c', 'docker pull ${_LOCATION}-docker.pkg.dev/$PROJECT_ID/${_REPOSITORY}/${_IMAGE}:latest || exit 0'] - name: 'gcr.io/cloud-builders/docker' args: [ 'build', '-t', '${_LOCATION}-docker.pkg.dev/$PROJECT_ID/${_REPOSITORY}/${_IMAGE}:latest', '--cache-from', '${_LOCATION}-docker.pkg.dev/$PROJECT_ID/${_REPOSITORY}/${_IMAGE}:latest' '.' ] images: ['${_LOCATION}-docker.pkg.dev/$PROJECT_ID/${_REPOSITORY}/${_IMAGE}:latest']
- Estrai l'immagine memorizzata nella cache da Artifact Registry. Il passaggio di build
Crea l'immagine utilizzando la configurazione della build precedente:
gcloud builds submit --config cloudbuild.yaml .
JSON
Nella configurazione della build, aggiungi le istruzioni per:
- Estrai l'immagine memorizzata nella cache da Artifact Registry. Il passaggio di build
docker pullimpostaentrypointsubash, il che ti consente di eseguire il comando e ignorare l'errore restituito. Questa configurazione è obbligatoria quando crei un'immagine per la prima volta edocker pullnon esiste un'immagine da estrarre. - Aggiungi un argomento
--cache-fromper utilizzare l'immagine per le ricompilazioni.
{ "steps": [ { "name": "gcr.io/cloud-builders/docker", "entrypoint": "bash", "args": ["-c", "docker pull ${_LOCATION}-docker.pkg.dev/$PROJECT_ID/${_REPOSITORY}/${_IMAGE}:latest || exit 0"] }, { "name": "gcr.io/cloud-builders/docker", "args": [ "build", "-t", "${_LOCATION}-docker.pkg.dev/$PROJECT_ID/${_REPOSITORY}/${_IMAGE}:latest", "--cache-from", "${_LOCATION}-docker.pkg.dev/$PROJECT_ID/${_REPOSITORY}/${_IMAGE}:latest", "." ] } ], "images": ["${_LOCATION}-docker.pkg.dev/$PROJECT_ID/${_REPOSITORY}/${_IMAGE}:latest"] }where [IMAGE] is the name of your image.- Estrai l'immagine memorizzata nella cache da Artifact Registry. Il passaggio di build
Crea l'immagine utilizzando la configurazione della build precedente:
gcloud builds submit --config cloudbuild.json .
Memorizzazione nella cache delle directory con Google Cloud Storage
Per aumentare la velocità di una build, riutilizza i risultati di una build precedente. Puoi copiare i risultati di una build precedente in un bucket Cloud Storage, utilizzare i risultati per un calcolo più rapido e quindi copiare i nuovi risultati nel bucket. Utilizza questo metodo quando la build richiede molto tempo e produce un numero ridotto di file che non richiedono tempo per essere copiati da e verso Cloud Storage.
A differenza di --cache-from, che è solo per le build Docker, la memorizzazione nella cache di Cloud Storage può essere utilizzata per qualsiasi builder supportato da Cloud Build.
Per memorizzare nella cache le directory utilizzando Cloud Storage:
YAML
Nel file di configurazione della build, aggiungi le istruzioni per:
- Copia i risultati di una build precedente dal bucket Cloud Storage.
- Utilizza i risultati per la build corrente.
Copia i nuovi risultati nel bucket.
steps: - name: gcr.io/cloud-builders/gcloud args: ['storage', 'cp', 'gs://mybucket/results.zip', 'previous_results.zip'] # operations that use previous_results.zip and produce new_results.zip - name: gcr.io/cloud-builders/gcloud args: ['storage', 'cp', 'new_results.zip', 'gs://mybucket/results.zip']
Crea il codice utilizzando la configurazione della build precedente:
gcloud builds submit --config cloudbuild.yaml .
JSON
Nel file di configurazione della build, aggiungi le istruzioni per:
- Copia i risultati di una build precedente dal bucket Cloud Storage.
- Utilizza i risultati per la build corrente.
Copia i nuovi risultati nel bucket.
{ "steps": [ { "name": "gcr.io/cloud-builders/gcloud", "args": ["storage", "cp", "gs://mybucket/results.zip", "previous_results.zip"] }, { // operations that use previous_results.zip and produce new_results.zip }, { "name": "gcr.io/cloud-builders/gcloud", "args": ["storage", "cp", "new_results.zip", "gs://mybucket/results.zip"] } ] }
Crea il codice utilizzando la configurazione della build precedente:
gcloud builds submit --config cloudbuild.json .
Evitare il caricamento di file non necessari
Quando viene attivata una build, la directory del codice viene caricata per essere utilizzata da Cloud Build.
Puoi escludere i file non necessari per la build con un file
.gcloudignore per ottimizzare il tempo di caricamento.
Esempi di file comunemente esclusi:
- Documentazione e codice campione per gli sviluppatori di progetti
- Codice di scaffolding, file binari, file
*.jaro asset web compilati generati utilizzati per lo sviluppo. - Dipendenze di terze parti di proprietà del fornitore per lo sviluppo locale
Per preparare un file .gcloudignore per risolvere questi casi, crea un file nella radice del progetto con contenuti come:
.git
dist
node_modules
vendor
*.jar
L'esclusione del codice compilato e delle dipendenze di terze parti comporta anche un processo di compilazione più coerente e un rischio ridotto di deployment accidentale di codice ancora in fase di sviluppo attivo.
Passaggi successivi
- Scopri come aumentare le vCPU per le build.