Eseguire il deployment dei servizi dal codice sorgente

Questa pagina descrive come eseguire il deployment di un nuovo servizio o di una nuova revisione del servizio in Cloud Run direttamente dal codice sorgente utilizzando un singolo comando gcloud CLI, gcloud run deploy con il flag --source. Per una procedura dettagliata di esempio del deployment di un servizio Hello World, consulta Guide rapide per il deployment dal codice sorgente.

Esistono due modi diversi per utilizzare questa funzionalità:

Tieni presente che i deployment di origine utilizzano Artifact Registry per archiviare i container creati. Se il tuo progetto non ha già un repository Artifact Registry con il nome cloud-run-source-deploy nella regione in cui stai eseguendo il deployment, questa funzionalità crea automaticamente un repository Artifact Registry con il nome cloud-run-source-deploy.

Se nella directory del codice sorgente è presente un Dockerfile, il codice sorgente caricato viene creato utilizzando quel Dockerfile. Se nella directory del codice sorgente non è presente alcun Dockerfile, i buildpack di Google Cloud rilevano automaticamente il linguaggio che stai utilizzando e recuperano le dipendenze del codice per creare un'immagine container pronta per la produzione, utilizzando un'immagine di base sicura gestita da Google.

Per impostazione predefinita, le correzioni di sicurezza vengono applicate solo quando viene eseguito il deployment del servizio Cloud Run. Quando attivi gli aggiornamenti automatici della sicurezza per un servizio, questo riceve le patch automaticamente senza tempi di inattività. Scopri di più sulla configurazione degli aggiornamenti della sicurezza.

Prima di iniziare

  • Assicurati di aver configurato un nuovo progetto per Cloud Run come descritto nella pagina di configurazione.

  • Se il tuo progetto è soggetto a una policy dell'organizzazione con limitazione del dominio che limita le chiamate non autenticate, dovrai accedere al servizio di cui hai eseguito il deployment come descritto in Test dei servizi privati.

  • Abilita l'API Cloud Run Admin, se non è già abilitata.

    Ruoli richiesti per abilitare le API

    Per abilitare le API, devi disporre dell'autorizzazione serviceusage.services.enable. Se hai creato il progetto, probabilmente hai già questa autorizzazione tramite il ruolo Proprietario (roles/owner). In caso contrario, puoi ottenere questa autorizzazione tramite il ruolo Amministratore Service Usage (roles/serviceusage.serviceUsageAdmin). Scopri come concedere i ruoli.

    Abilitare l'API

    Dopo l'abilitazione dell'API Cloud Run Admin, viene creato automaticamente il account di servizio predefinito di Compute Engine.

Ruoli obbligatori

Per eseguire il deployment dall'origine, tu o l'amministratore dovete concedere all'account deployer i seguenti ruoli IAM.

Fai clic per visualizzare i ruoli richiesti per l'account deployer

Per ottenere le autorizzazioni necessarie per creare ed eseguire il deployment dal codice sorgente, chiedi all'amministratore di concederti i seguenti ruoli IAM:

Per un elenco di ruoli e autorizzazioni IAM associati a Cloud Run, consulta Ruoli IAM di Cloud Run e Autorizzazioni IAM di Cloud Run. Se il tuo servizio Cloud Run interagisce con le APIGoogle Cloud , come le librerie client Cloud, consulta la guida alla configurazione dell'identità del servizio. Per saperne di più sulla concessione dei ruoli, consulta Autorizzazioni di deployment e Gestisci l'accesso.

Lingue supportate

Oltre alle origini con un Dockerfile, il deployment dall'origine supporta i seguenti linguaggi utilizzando i buildpack di Google Cloud:

Runtime Deployment di origine Configurazione
Vai Esegui il deployment di un servizio Go Configura i buildpack Go
Node.js Esegui il deployment di un servizio Node.js Configura i buildpack di Node.js
Python Esegui il deployment di un servizio Python Configura i buildpack Python
Java
(include Kotlin, Groovy, Scala)		 Esegui il deployment di un servizio Java Configura i buildpack Java
.NET Esegui il deployment di un servizio .NET Configura i buildpack .NET
Ruby Esegui il deployment di un servizio Ruby Configura i buildpack Ruby
PHP Esegui il deployment di un servizio PHP Configura i buildpack PHP
Solo sistema operativo Esegui il deployment di un servizio Go Configura il runtime solo per il sistema operativo

Scopri di più sulle versioni delle lingue supportate.

Esegui il deployment dall'origine con la build

Questa sezione descrive come utilizzare i buildpack di Google Cloud e Cloud Build per creare automaticamente immagini container dal codice sorgente senza dover installare Docker sulla tua macchina o configurare i buildpack o Cloud Build.

Limitazioni

  • Il deployment dall'origine utilizza Artifact Registry e Cloud Build, pertanto questa funzionalità è disponibile solo nelle regioni supportate da Artifact Registry e Cloud Build.
  • Il deployment dall'origine è una funzionalità di praticità e non consente la personalizzazione completa della build. Per un maggiore controllo, crea l'immagine container utilizzando Cloud Build, ad esempio utilizzando gcloud builds submit, quindi esegui il deployment dell'immagine container utilizzando, ad esempio, gcloud run deploy --image.
  • Il deployment dall'origine con i buildpack di Google Cloud imposta la data dell'ultima modifica dei file di origine sul 1° gennaio 1980. Questo è il comportamento predefinito dei buildpack ed è progettato per supportare le build riproducibili. A seconda del framework della lingua, ciò può influire sulla memorizzazione nella cache lato browser dei file statici. Se la tua applicazione è interessata da questo problema, Google consiglia di disattivare le intestazioni HTTP etag e Last-Modified nell'applicazione.
  • Il deployment dall'origine con i buildpack di Google Cloud utilizza sempre gcr.io/buildpacks/builder:latest. Se la lingua o la configurazione del sistema operativo che preferisci non sono disponibili in latest, utilizza un builder specifico per creare un'immagine dell'applicazione utilizzando il builder che preferisci.

  • Puoi eseguire il deployment del servizio dal codice sorgente utilizzando Kotlin e altri linguaggi JVM, come Java. Il linguaggio utilizzato deve essere conforme alle seguenti regole:

    • Puoi creare l'applicazione utilizzando Maven o Gradle.
    • Il file di build contiene tutti i plug-in necessari per produrre classi.

Prima di eseguire il deployment con la build

Prima di eseguire il deployment dall'origine con build:

  • Segui i passaggi descritti in Prima di iniziare.

  • Abilita l'API Cloud Build, se non è già abilitata.

    Ruoli richiesti per abilitare le API

    Per abilitare le API, devi disporre dell'autorizzazione serviceusage.services.enable. Se hai creato il progetto, probabilmente hai già questa autorizzazione tramite il ruolo Proprietario (roles/owner). In caso contrario, puoi ottenere questa autorizzazione tramite il ruolo Amministratore Service Usage (roles/serviceusage.serviceUsageAdmin). Scopri come concedere i ruoli.

    Abilitare l'API

Ruoli obbligatori

Per eseguire il deployment dall'origine con la build, tu o il tuo amministratore dovete concedere al account di servizio Cloud Build i seguenti ruoli IAM.

Fai clic per visualizzare i ruoli richiesti per il account di servizio Cloud Build

Cloud Build utilizza automaticamente l'account di servizio predefinito di Compute Engine come account di servizio Cloud Build predefinito per creare il codice sorgente e la risorsa Cloud Run, a meno che non esegui l'override di questo comportamento. Per consentire a Cloud Build di creare le tue origini, chiedi all'amministratore di concedere il ruolo Cloud Run Builder (roles/run.builder) al account di servizio Compute Engine predefinito nel tuo progetto:

  gcloud projects add-iam-policy-binding PROJECT_ID \
      --member=serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com \
      --role=roles/run.builder

Sostituisci PROJECT_NUMBER con il tuo numero di progetto Google Cloude PROJECT_ID con il tuo ID progetto Google Cloud. Per istruzioni dettagliate su come trovare l'ID progetto e il numero di progetto, consulta Creazione e gestione dei progetti.

La concessione del ruolo Cloud Run Builder al account di servizio predefinito di Compute Engine richiede un paio di minuti per la propagazione.

Per un elenco di ruoli e autorizzazioni IAM associati a Cloud Run, consulta Ruoli IAM di Cloud Run e Autorizzazioni IAM di Cloud Run. Se il tuo servizio Cloud Run interagisce con le APIGoogle Cloud , come le librerie client Cloud, consulta la guida alla configurazione dell'identità del servizio. Per saperne di più sulla concessione dei ruoli, consulta Autorizzazioni di deployment e Gestisci l'accesso.

Esegui il deployment con la build

Per eseguire il deployment dal codice sorgente, fai clic sulla scheda per visualizzare le istruzioni sull'utilizzo dello strumento che preferisci.

gcloud

  1. Nella console Google Cloud , attiva Cloud Shell.

    Attiva Cloud Shell

    Nella parte inferiore della console Google Cloud , viene avviata una sessione di Cloud Shell e viene visualizzato un prompt della riga di comando. Cloud Shell è un ambiente shell con Google Cloud CLI già installata e con valori già impostati per il progetto corrente. L'inizializzazione della sessione può richiedere alcuni secondi.

  2. Passa alla directory di origine. La directory di origine utilizza un Dockerfile, se presente, anche se non è obbligatorio.

  3. Crea ed esegui il deployment del servizio:

    gcloud run deploy SERVICE --source .

    Sostituisci SERVICE con il nome che vuoi assegnare al servizio.

  4. Rispondi a eventuali prompt per installare le API richieste digitando y quando richiesto. Devi eseguire questa operazione una sola volta per un progetto. Rispondi agli altri prompt fornendo la piattaforma e la regione, se non hai impostato i valori predefiniti per queste come descritto nella pagina di configurazione.

  5. Attendi il completamento della build e del deployment. Al termine, Cloud Run visualizza un messaggio di operazione riuscita.

Dopo il deployment, questa revisione del servizio gestisce il 100% del traffico.

Scrivi

Puoi archiviare la specifica Compose in un file YAML e poi eseguirne il deployment dal codice sorgente come servizio Cloud Run utilizzando un singolo comando gcloud.

  1. Passa alla directory di origine. La directory di origine utilizza un Dockerfile, se presente, anche se non è obbligatorio.

  2. Nella directory del progetto, crea un file compose.yaml con le definizioni dei servizi.

    services:
  web:
    build: .
    ports:
      - "8080:8080"

    Puoi anche specificare altre opzioni di configurazione, come variabili di ambiente, secret e montaggi di volumi.

Esegui il deployment dei servizi

  1. Per eseguire il deployment dei servizi, esegui il comando gcloud run compose up:

    gcloud run compose up compose.yaml

  2. Rispondi y a eventuali prompt per installare i componenti richiesti o per abilitare le API.

  3. (Facoltativo) Rendi pubblico il servizio se vuoi consentire l'accesso non autenticato al servizio.

Dopo il deployment, viene visualizzato l'URL del servizio Cloud Run. Copia questo URL e incollalo nel browser per visualizzare il container in esecuzione. Puoi disattivare l'autenticazione predefinita dalla console Google Cloud .

Esegui il deployment dell'origine predefinita

Puoi eseguire il deployment degli artefatti di origine predefiniti direttamente in Cloud Run, ignorando il passaggio di Cloud Build. In questo modo, anziché creare un'immagine container dal codice sorgente, puoi caricare un archivio pre-pacchettizzato della tua applicazione direttamente in un bucket Cloud Storage. Cloud Run prende quindi questo archivio e lo esegue direttamente su un'immagine di base. Questo approccio ti consente di sviluppare ed eseguire iterazioni rapidamente a livello locale e di ridurre drasticamente i tempi di deployment.

Limitazioni

Il deployment dell'origine predefinita supporta solo quanto segue:

  • Servizi Cloud Run.
  • Runtime supportati (nessun supporto per Dockerfile).
  • Archivio di origine (.tar.gz) <= 250 MiB.
  • Il file binario (ad esempio, un file binario Go) o lo script (ad esempio, uno script Python) deve essere compatibile con l'architettura x86.
  • L'origine deve essere autonoma, con tutte le dipendenze pacchettizzate. L'immagine di base del runtime contiene solo il sistema operativo minimo e alcune librerie di linguaggio.

Prima di eseguire il deployment del codice sorgente predefinito

Per utilizzare la funzionalità "esegui il deployment senza build":

  • Assicurati di aver seguito i passaggi descritti in Prima di iniziare.

  • Abilita le API Cloud Run e Cloud Storage:

    gcloud services enable run.googleapis.com \
  storage.googleapis.com

  • Devi installare le dipendenze dell'applicazione localmente prima del deployment, poiché non verranno installate (nessuna build).

Esegui il deployment senza build

Questa sezione descrive come eseguire il deployment del codice sorgente predefinito direttamente in Cloud Run.

gcloud

Per eseguire il deployment del codice sorgente predefinito da una directory locale, utilizza il flag --no-build per indicare al comando deploy di ignorare il passaggio di Cloud Build:

gcloud beta run deploy SERVICE_NAME \
  --source APPLICATION_PATH \
  --no-build \
  --base-image=BASE_IMAGE \
  --command=COMMAND \
  --args=ARG

Sostituisci quanto segue:

  • SERVICE_NAME: il nome del tuo servizio Cloud Run.
  • APPLICATION_PATH: la posizione della tua applicazione nel file system locale.

  • BASE_IMAGE: l'immagine di base del runtime che vuoi utilizzare per la tua applicazione. Ad esempio us-central1-docker.pkg.dev/serverless-runtimes/google-24/runtimes/nodejs24. Puoi anche utilizzare l'alias breve nodejs24.

    Puoi anche eseguire il deployment di un file binario precompilato senza configurare componenti di runtime aggiuntivi specifici per il linguaggio utilizzando l'immagine di base solo per il sistema operativo, ad esempio osonly24. Per saperne di più, consulta OS only runtime nella documentazione dei buildpack.

  • COMMAND: il comando con cui viene avviato il container. Facoltativo. Se non specifichi un comando, l'immagine di base dedurrà il comando di avvio del container in fase di runtime.

  • ARG: un argomento che invii al comando del container. Se utilizzi più argomenti, specificali ciascuno su una riga separata. Facoltativo. Se non specifichi argomenti, l'immagine di base dedurrà gli argomenti in fase di runtime.

YAML

Puoi archiviare la specifica del servizio in un file YAML e poi eseguirne il deployment utilizzando gcloud CLI o l'editorservice.yamldella console Google Cloud .

  1. Crea un bucket di archiviazione per contenere la tua applicazione:

    gcloud storage buckets create gs://BUCKET_NAME --location=BUCKET_LOCATION

    Sostituisci quanto segue:

    • BUCKET_NAME: il nome che vuoi assegnare al bucket, soggetto ai requisiti di denominazione. Ad esempio: my-bucket.
    • BUCKET_LOCATION: la località del tuo bucket. Ad esempio: US.

  2. Crea un archivio con l'origine dell'applicazione utilizzando zip o tar, ad esempio:

    tar -cvzf ARCHIVE_NAME APPLICATION_PATH

    Sostituisci quanto segue:

    • ARCHIVE_NAME: il nome dell'archivio da creare. Ad esempio, app.tar.gz.
    • APPLICATION_PATH: la posizione della tua applicazione nel file system locale. Ad esempio, ~/my-application. Per archiviare la directory di lavoro corrente, imposta questo valore su *.

  3. Carica l'archivio dell'applicazione su Cloud Storage:

    gcloud storage cp ARCHIVE_NAME gs://BUCKET_NAME

    Sostituisci quanto segue:

    • ARCHIVE_NAME: il percorso locale dell'archivio che hai creato in precedenza. Ad esempio, app.tar.gz.
    • BUCKET_NAME: il nome del bucket che hai creato in precedenza. Ad esempio, my-bucket.

  4. Crea un nuovo file service.yaml con i seguenti contenuti:

    apiVersion: serving.knative.dev/v2
kind: Service
metadata:
 name: SERVICE_NAME
spec:
 template:
   metadata:
     annotations:
       run.googleapis.com/sources: '{"": "gs://BUCKET_NAME/ARCHIVE_NAME"}'
       run.googleapis.com/base-images: '{"": "BASE_IMAGE"}'
   spec:
     containers:
     - image: scratch
       command:
       - COMMAND
       args:
       - ARG1
       - ARG-N
     runtimeClassName: run.googleapis.com/linux-base-image-update

    Sostituisci quanto segue:

    • SERVICE_NAME: il nome del tuo servizio Cloud Run. I nomi dei servizi devono avere una lunghezza massima di 49 caratteri ed essere univoci per regione e progetto.
    • BUCKET_NAME: il nome del bucket che hai creato in precedenza. Ad esempio, my-bucket.
    • ARCHIVE_NAME: il percorso locale dell'archivio che hai creato in precedenza. Ad esempio, app.tar.gz.

    • BASE_IMAGE: l'immagine di base del runtime che vuoi utilizzare per la tua applicazione. Ad esempio, us-central1-docker.pkg.dev/serverless-runtimes/google-24/runtimes/nodejs24.

      Puoi anche eseguire il deployment di un file binario precompilato senza configurare componenti di runtime aggiuntivi specifici per il linguaggio utilizzando l'immagine di base solo per il sistema operativo, ad esempio osonly24. Per saperne di più, consulta OS only runtime nella documentazione dei buildpack.

    • COMMAND: il comando con cui deve essere avviato il container. Facoltativo. Se non specifichi un comando, l'immagine di base dedurrà il comando di avvio del container in fase di runtime.

    • ARG1: l'argomento che stai inviando al comando del container. Se utilizzi più argomenti, specificali ciascuno sulla propria riga, ad esempio, come mostrato, ARG-N. Facoltativo. Se non specifichi argomenti, l'immagine di base dedurrà gli argomenti in fase di runtime.

  5. Esegui il deployment del nuovo servizio:

    gcloud run services replace service.yaml

API REST

Per eseguire il deployment utilizzando l'API REST:

curl -H "Content-Type: application/json" \
-H "Authorization: Bearer ACCESS_TOKEN" \
-X POST \
-d '{"template": {"containers": [{"command": ["COMMAND"], "args": ["ARG1"], "image": "scratch", "baseImageUri": "BASE_IMAGE", "sourceCode": {"cloudStorageSource": {"bucket": "'GCS_BUCKET_NAME", "object":"ARCHIVE_NAME"}}}]}}' \
https://run.googleapis.com/v2/projects/PROJECT_ID/locations/REGION/services?serviceId=SERVICE_NAME

Sostituisci quanto segue:

  • ACCESS_TOKEN: un token di accesso valido per un account che dispone delle autorizzazioni IAM per il deployment dei servizi. Ad esempio, se hai eseguito l'accesso a gcloud, puoi recuperare un token di accesso utilizzando gcloud auth print-access-token. All'interno di un'istanza container di Cloud Run, puoi recuperare un token di accesso utilizzando il server dei metadati dell'istanza container.
  • COMMAND: il comando con cui deve essere avviato il container. Facoltativo. Se non specifichi un comando, l'immagine di base dedurrà il comando di avvio del container in fase di runtime.
  • ARG1: l'argomento che stai inviando al comando del container. Se utilizzi più argomenti, specificali ciascuno sulla propria riga, ad esempio, come mostrato, ARG-N. Facoltativo. Se non specifichi argomenti, l'immagine di base dedurrà gli argomenti al runtime.

  • BASE_IMAGE: l'immagine di base del runtime che vuoi utilizzare per la tua applicazione. Ad esempio, us-central1-docker.pkg.dev/serverless-runtimes/google-24/runtimes/nodejs24.

    Puoi anche eseguire il deployment di un file binario precompilato senza configurare componenti di runtime aggiuntivi specifici per il linguaggio utilizzando l'immagine di base solo per il sistema operativo, ad esempio osonly24. Per saperne di più, consulta OS only runtime nella documentazione dei buildpack.

  • BUCKET_NAME: il nome del bucket che hai creato in precedenza. Ad esempio, my-bucket.

  • ARCHIVE_NAME: il percorso locale dell'archivio che hai creato in precedenza. Ad esempio, app.tar.gz.

  • PROJECT-ID: l'ID progetto Google Cloud .

  • REGION: la regione Google Cloud del servizio.

  • SERVICE_NAME: il nome del tuo servizio Cloud Run. I nomi dei servizi devono avere una lunghezza massima di 49 caratteri ed essere univoci per regione e progetto.

Terraform

Per scoprire come applicare o rimuovere una configurazione Terraform, consulta Comandi Terraform di base.

Aggiungi quanto segue a una risorsa google_cloud_run_v2_service nella configurazione Terraform:
resource "google_storage_bucket_object" "source_tar" {
  provider = google-beta
  name   = "ARCHIVE_NAME"
  bucket = "BUCKET_NAME"
  source = "ARCHIVE_PATH"
}

resource "google_cloud_run_v2_service" "default" {
  provider = google-beta
  name     = "SERVICE_NAME"
  location = "REGION"
  deletion_protection = false

  template {
    containers {
      image = "scratch"
      base_image_uri = "BASE_IMAGE"
      command = ["COMMAND"]
      args = ["ARG1"]
      source_code {
        cloud_storage_source {
          bucket = "BUCKET_NAME"
          object = google_storage_bucket_object.source_tar.name
          generation = google_storage_bucket_object.source_tar.generation
        }
      }
    }
  }
}

Sostituisci quanto segue:

  • ARCHIVE_NAME: il nome del file così come apparirà nel tuo bucket Cloud Storage. Ad esempio, source-code.tar.gz.
  • BUCKET_NAME: il nome del bucket in cui vuoi caricare l'archivio di origine. Ad esempio, my-source-bucket.
  • ARCHIVE_PATH: il percorso locale dell'archivio che hai creato in precedenza. Ad esempio, ./app.tar.gz. Questo archivio deve essere in formato GZIP (.tar.gz).
  • SERVICE_NAME: il nome del servizio Cloud Run
  • REGION: la regione Google Cloud sia per il bucket che per il servizio. Ad esempio, europe-west1. Entrambe le risorse devono trovarsi nella stessa regione per evitare timeout di estrazione.
  • BASE_IMAGE: l'immagine di base del runtime che vuoi utilizzare per la tua applicazione. Ad esempio, us-central1-docker.pkg.dev/serverless-runtimes/google-24/runtimes/nodejs24.
  • COMMAND: il comando con cui deve essere avviato il container. Facoltativo. Se non specifichi un comando, l'immagine di base dedurrà il comando di avvio del container in fase di runtime.
  • ARG1: l'argomento che stai inviando al comando del container. Facoltativo. Se non specifichi argomenti, l'immagine di base li dedurrà in fase di runtime.

MCP

Puoi utilizzare un agente AI per eseguire il deployment del tuo servizio con o senza un bucket di archiviazione utilizzando il server MCP Cloud Run ufficiale.

Per ottenere risultati ottimali, indica all'agente di preferire gli strumenti MCP a gcloud CLI prima di iniziare a utilizzare questo server MCP.

  1. Per configurare il server MCP remoto di Cloud Run, segui le istruzioni riportate nella guida Utilizza il server MCP remoto di Cloud Run.

    • Con un bucket di archiviazione

      Per creare un bucket di archiviazione ed eseguire il deployment di un servizio, fornisci all'agente il seguente prompt: Create storage bucket "my-bucket" for my source code and deploy service "my-app" to Cloud Run from source in this current directory.

      L'agente utilizza lo strumento deploy_service_from_archive per passare il codice sorgente direttamente a Cloud Run da un archivio di codice sorgente autonomo per un deployment più rapido.

      Puoi anche indicare all'agente di riutilizzare un bucket Cloud Storage esistente per il codice sorgente.

    • Senza un bucket di archiviazione

      Per snippet di codice di dimensioni pari o inferiori a 50 MiB senza dipendenze esterne, indica all'agente di eseguire il deployment senza un bucket di archiviazione utilizzando il seguente prompt: Deploy service "my-app" to Cloud Run from source in this current directory.

      L'agente utilizza lo strumento deploy_service_from_file_contents per passare il codice sorgente direttamente dai file di codice sorgente locali a Cloud Run.

Utilizza il prompt /deploy

Puoi utilizzare il prompt /deploy per eseguire rapidamente il deployment di un servizio utilizzando il server MCP di Cloud Run. Potresti dover navigare nel menu del chatbot per trovare lo strumento o il prompt necessario.

Per eseguire il deployment della directory di lavoro attuale in Cloud Run, esegui il seguente prompt /deploy:

/deploy SERVICE_NAME \
    --project PROJECT_ID \
    --region REGION \

Sostituisci quanto segue:

  • SERVICE_NAME: il nome del servizio Cloud Run
  • PROJECT_ID: l'ID progetto Google Cloud
  • REGION: il nome della regione

Esempi di distribuzione di sorgenti precompilate

Questa sezione mostra esempi di come eseguire il deployment dal codice sorgente senza utilizzare la build.

Node.js

Crea un servizio Node.js:

  1. Crea una nuova directory denominata helloworld e accedi alla directory:

    mkdir helloworld
cd helloworld

  2. Crea un file package.json con i seguenti contenuti:

    {
  "name": "helloworld",
  "description": "Simple hello world sample in Node",
  "version": "1.0.0",
  "private": true,
  "main": "index.js",
  "type": "module",
  "scripts": {
    "start": "node index.js"
  },
  "engines": {
    "node": ">=16.0.0"
  },
  "author": "Google LLC",
  "license": "Apache-2.0",
  "dependencies": {
    "express": "^5.2.1"
  }
}

  3. Nella stessa directory, crea un file index.js e copia al suo interno le seguenti righe:

    import express from 'express';
const app = express();

app.get('/', (req, res) => {
  const name = process.env.NAME || 'World';
  res.send(`Hello ${name}!`);
});

const port = parseInt(process.env.PORT) || 8080;
app.listen(port, () => {
  console.log(`helloworld: listening on port ${port}`);
});

    Questo codice crea un server web di base in ascolto sulla porta definita dalla variabile di ambiente PORT.

  4. Nella directory helloworld, esegui questo comando per installare le dipendenze del servizio localmente:

    npm install

  5. Nella directory helloworld, esegui il deployment del servizio utilizzando il flag --no-build, che indica al comando deploy di saltare il passaggio di Cloud Build:

    gcloud beta run deploy helloworld \
 --source . \
 --region=REGION \
 --no-build \
 --base-image=nodejs24 \

    Sostituisci quanto segue:

    • REGION: la regione in cui è stato eseguito il deployment del servizio.

Python

Crea un servizio Python:

  1. Crea una nuova directory denominata helloworld e accedi alla directory:

    mkdir helloworld
cd helloworld

  2. Crea un file denominato main.py e incolla il seguente codice:

    import os

from flask import Flask

app = Flask(__name__)


@app.route("/")
def hello_world():
    """Example Hello World route."""
    name = os.environ.get("NAME", "World")
    return f"Hello {name}!"


if __name__ == "__main__":
    app.run(debug=True, host="0.0.0.0", port=int(os.environ.get("PORT", 8080)))

    Questo codice risponde alle richieste con il saluto "Hello World". La gestione HTTP viene eseguita da un server web Gunicorn nel container. Quando viene richiamato direttamente per l'utilizzo in locale, questo codice crea un server web di base che rimane in ascolto tramite la porta definita dalla variabile di ambiente PORT.

  3. Crea un file denominato requirements.txt e incolla il seguente codice:

    Flask==3.1.3; python_version >= '3.9'
gunicorn==23.0.0
Werkzeug==3.1.9; python_version >= '3.10'

    Questo codice aggiunge i pacchetti necessari per l'esempio.

  4. Esegui il vendoring delle dipendenze:

    pip3 install -r requirements.txt --target=./vendor

  5. Esegui il deployment del servizio utilizzando gcloud CLI. Il flag --no-build indica al comando deploy di ignorare il passaggio di Cloud Build:

    gcloud beta run deploy helloworld \
  --source . \
  --region=REGION \
  --no-build \
  --base-image=python314 \

Sostituisci REGION con la regione in cui è stato eseguito il deployment del servizio.

Vai

Crea ed esegui il deployment di un servizio Go utilizzando il runtime solo per il sistema operativo:

  1. Crea una nuova directory denominata helloworld e accedi alla directory:

    mkdir helloworld
cd helloworld

  2. Inizializza un file go.mod dalla directory del progetto per dichiarare il modulo go:

    go mod init github.com/GoogleCloudPlatform/golang-samples/run/helloworld

  3. Crea un nuovo file denominato main.go e incolla il seguente codice:

    
// Sample run-helloworld is a minimal Cloud Run service.
package main

import (
	"fmt"
	"log"
	"net/http"
	"os"
)

func main() {
	log.Print("starting server...")
	http.HandleFunc("/", handler)

	// Determine port for HTTP service.
	port := os.Getenv("PORT")
	if port == "" {
		port = "8080"
		log.Printf("defaulting to port %s", port)
	}

	// Start HTTP server.
	log.Printf("listening on port %s", port)
	if err := http.ListenAndServe(":"+port, nil); err != nil {
		log.Fatal(err)
	}
}

func handler(w http.ResponseWriter, r *http.Request) {
	name := os.Getenv("NAME")
	if name == "" {
		name = "World"
	}
	fmt.Fprintf(w, "Hello %s!\n", name)
}

  4. Crea il file binario che ha come target un sistema operativo Linux, ad esempio linux/amd64, eseguendo questo comando:

    GOOS="linux" GOARCH=amd64 go build main.go

  5. Esegui il deployment del servizio utilizzando gcloud CLI. Il flag --no-build indica al comando deploy di ignorare il passaggio di Cloud Build:

    gcloud beta run deploy helloworld \
  --source . \
  --region=REGION \
  --no-build \
  --base-image=osonly24 \
  --command=./main

Sostituisci REGION con la regione in cui è stato eseguito il deployment del servizio.

Risoluzione dei problemi

Questa sezione fornisce alcuni suggerimenti per la risoluzione dei problemi relativi al deployment dall'origine senza utilizzare la build.

Sviluppo locale

Il deployment dall'origine senza utilizzare la build funziona in modo simile al montaggio del codice o dell'eseguibile nell'immagine di base.

Ad esempio:

  1. Crea una copia di tutti i contenuti:

    cp -R python/hello-world/ workspace

  2. Esegui l'immagine di base come utente root con l'origine montata. Se devi eseguire curl da una macchina host, puoi includere -p 8080:8080.

    docker run -it -v "LOCAL_PATH" -u 0 us-central1-docker.pkg.dev/serverless-runtimes/google-22-full/runtimes/python314 /bin/bash`

    Sostituisci LOCAL_PATH con la posizione dei file di origine locali.

  3. Esegui il server:

    python main.py

Log esecuzione

Il log di esecuzione è utile per il debug degli errori di deployment. Nella consoleGoogle Cloud , vai a Osservabilità > Log.

Autorizzazione negata per l'accesso a Cloud Storage

Se il tuo servizio Cloud Run riscontra errori "Autorizzazione negata" quando tenta di accedere agli oggetti Cloud Storage, devi concedere il ruolo roles/storage.objectViewer al account di servizio Cloud Run:

gcloud projects add-iam-policy-binding PROJECT \
  --member="SERVICE_ACCOUNT" \
  --role="roles/storage.objectViewer"

Sostituisci quanto segue:

  • PROJECT: il tuo ID progetto Google Cloud .
  • SERVICE_ACCOUNT: il tuo account di servizio Cloud Run. Ad esempio, service-123@serverless-robot-staging.iam.gserviceaccount.com.

Automazione della creazione dal codice sorgente

Come best practice per evitare modifiche senza versione nell'origine locale, Google consiglia di eseguire il deployment automatico quando viene eseguito il push delle modifiche al repository Git. Per semplificare questa operazione, puoi connettere e configurare il deployment continuo al tuo servizio Cloud Run. Collegando i tuoi repository GitHub a Cloud Run, puoi configurare le build ed eseguire il deployment dei repository senza scrivere Dockerfile o file di build.

Per configurare le build automatiche, configura l'automazione come descritto nella pagina delle build continue, assicurandoti di scegliere l'opzione per la creazione dell'origine con i buildpack.

Disattivazione del controllo di integrità del deployment

Per impostazione predefinita, Cloud Run verifica che il deployment sia integro avviando un'istanza e attendendo che il probe di avvio venga superato. Se il controllo di integrità non va a buon fine, la revisione verrà contrassegnata come non integra e il traffico non verrà indirizzato a questa revisione.

Se non è necessario o per aumentare la velocità di deployment, il controllo di integrità del deployment può essere disattivato:

gcloud

Per disattivare il controllo di integrità del deployment, utilizza il flag --no-deploy-health-check:

gcloud run deploy --image IMAGE_URL --no-deploy-health-check

Sostituisci quanto segue:

  • IMAGE_URL: un riferimento all'immagine container, ad esempio us-docker.pkg.dev/cloudrun/container/hello:latest. Se utilizzi Artifact Registry, il repository REPO_NAME deve essere già stato creato. L'URL segue il formato LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG.

Utilizza --deploy-health-check per riattivare il controllo di integrità del deployment se era stato disattivato in precedenza.

YAML

Per disattivare il controllo di integrità del deployment, aggiungi l'annotazione run.googleapis.com/health-check-disabled con il valore 'true' a spec.template.metadata.annotations.

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: SERVICE
spec:
  template:
    metadata:
      annotations:
        run.googleapis.com/health-check-disabled: 'true'

Terraform

Per disattivare il controllo di integrità del deployment, imposta l'argomento health_check_disabled su true nel blocco template.

resource "google_cloud_run_v2_service" "default" {
  name     = "SERVICE"
  ...
  template {
    health_check_disabled = true
    ...
  }
}

Passaggi successivi

Dopo aver eseguito il deployment di un servizio Cloud Run, puoi:

Scopri di più sulle configurazioni di deployment del codice sorgente:

Puoi automatizzare le build e i deployment dei tuoi servizi Cloud Run utilizzando i trigger di Cloud Build: