Cloud Run su GCP: deploy container serverless, guida operativa

Hai speso ore a configurare un server per un'applicazione che riceve 10 visite al giorno. E se domani ne arrivano 10.000? Con Cloud Run questo problema sparisce. Noi, di Meteora Web, lavoriamo con container dal 2017 e abbiamo scelto Cloud Run come cavallo di battaglia per tutti quei progetti che devono scalare senza preavviso e senza farci impazzire con la gestione dell'infrastruttura. In questa guida ti portiamo dritti al punto: come preparare un container, deployarlo su Cloud Run e gestirlo nella vita reale, con i trucchi che abbiamo imparato sul campo.

Cos'è Cloud Run e perché ti interessa

Cloud Run è un servizio serverless di Google Cloud che esegue container HTTP. Senza server da gestire, senza Kubernetes da configurare. Paghi solo il tempo di CPU e memoria consumato durante le richieste. Se la tua app non riceve traffico, non paghi nulla. Per noi è stato un cambio di paradigma: invece di tenere acceso un VM 24/7 per un'API che viene chiamata 100 volte al giorno, la mettiamo su Cloud Run e il costo crolla.

Errore comune: credere che Cloud Run sia solo per microservizi. No, ci girano anche applicazioni monolitiche, purché siano stateless e rispondano su HTTP. Abbiamo deployato WooCommerce containerizzato? Sì, con qualche accorgimento. Ma andiamo con ordine.

Cosa serve per partire

Un account Google Cloud con fatturazione attiva
gcloud CLI installata e configurata
Docker installato (per build locale o tramite Cloud Build)
Un container che ascolti su una porta (default 8080)

Preparare un container per Cloud Run (le regole d'oro)

Cloud Run non è Docker su una macchina qualsiasi. Ha dei vincoli precisi. Ignorarli significa cold start da 10 secondi e istanze che muoiono senza motivo.

Stateless per definizione

Il filesystem del container è effimero. Ogni richiesta può essere servita da un'istanza diversa. Non salvare file sul disco locale se devono essere permanenti. Usa Cloud Storage, Cloud SQL o Redis.

Porta e dichiarazione

Il container deve esporre una porta HTTP. Di default Cloud Run si aspetta la 8080. Ma puoi usare anche la 8000 o 3000, basta dichiararla nel comando di deploy. Noi usiamo sempre la variabile d'ambiente PORT (Cloud Run la imposta automaticamente). Ecco un esempio di Dockerfile per un'app Node.js:

FROM node:18-alpine
WORKDIR /app
COPY package*.json ./
RUN npm install --production
COPY . .
ENV PORT=8080
EXPOSE 8080
CMD ["node", "server.js"]

Il file server.js deve leggere process.env.PORT e avviare il server su quella porta. Se fai hard-code della porta, su Cloud Run non funziona.

Minimizzare la dimensione dell'immagine

Immagini grandi = cold start lenti. Usa immagini base leggere (alpine, distroless). Abbiamo visto container da 1.5 GB con tutte le dipendenze di sviluppo incluse. Risultato: 8 secondi per avviarsi. Dopo ottimizzazione (multi-stage build) siamo scesi a 150 MB e 1.2 secondi.

Deploy: dalla build al running

Puoi deployare in due modi: dal tuo terminale (gcloud run deploy) o tramite Cloud Build (CI/CD). Noi consigliamo il secondo per ambienti di produzione, ma partiamo dal più semplice.

Deploy manuale con un comando

# Assicurati di avere il progetto attivo
gcloud config set project YOUR_PROJECT_ID

# Costruisci e carica l'immagine (con Cloud Build)
gcloud builds submit --tag gcr.io/YOUR_PROJECT_ID/my-app:latest

# Deploy su Cloud Run
gcloud run deploy my-service \
  --image gcr.io/YOUR_PROJECT_ID/my-app:latest \
  --platform managed \
  --region europe-west1 \
  --allow-unauthenticated

In meno di un minuto ottieni un URL pubblico del tipo https://my-service-xxxxx-ew.a.run.app. Funziona.

Deploy con Cloud Build (CI/CD)

Per automatizzare, crea un file cloudbuild.yaml nella radice del repo:

steps:
- name: 'gcr.io/cloud-builders/docker'
  args: ['build', '-t', 'gcr.io/$PROJECT_ID/my-app:$COMMIT_SHA', '.']
- name: 'gcr.io/cloud-builders/docker'
  args: ['push', 'gcr.io/$PROJECT_ID/my-app:$COMMIT_SHA']
- name: 'gcr.io/google.com/cloudsdktool/cloud-sdk'
  entrypoint: gcloud
  args:
  - 'run'
  - 'deploy'
  - 'my-service'
  - '--image'
  - 'gcr.io/$PROJECT_ID/my-app:$COMMIT_SHA'
  - '--region'
  - 'europe-west1'
  - '--allow-unauthenticated'

Poi collega il repo a Cloud Build (trigger su push). Ogni commit produce un deploy. Noi lo usiamo per tutti i clienti: niente più SSH nei server, tutto da GitHub.

Scaling, concorrenza e cold start

Cloud Run scala a zero quando non c'è traffico. La prima richiesta dopo un periodo di inattività attiva una nuova istanza (cold start). Il tempo dipende dall'immagine e dall'avvio dell'app. Noi abbiamo ridotto i cold start a meno di 200 ms usando min-instance (mantieni 1 istanza sempre accesa) per i servizi critici. Costa un po' di più ma per API di produzione è essenziale.

# Deploy con minimo 1 istanza sempre attiva
gcloud run deploy my-service --image IMG --min-instances 1 --max-instances 10 --concurrency 80

Concurrency: quante richieste contemporanee può gestire la stessa istanza. Valori tipici: 80 per Node.js/Python, 10 per app pesanti. Non superare 250 per non rischiare timeout.

Connettere Cloud Run ad altri servizi GCP

Cloud SQL (database)

Cloud Run non ha accesso diretto a una rete VPC di default. Per connetterti a Cloud SQL devi usare Cloud SQL Auth Proxy o abilitare la connessione serverless VPC. Noi preferiamo il proxy perché funziona subito. Aggiungi il seguente snippet al tuo deploy:

gcloud run deploy my-service \
  --add-cloudsql-instances PROJECT:REGION:INSTANCE \
  --image IMG

Nel codice, connettiti a /cloudsql/PROJECT:REGION:INSTANCE con un socket Unix. (Se usi un ORM, molte librerie supportano nativamente questa sintassi.)

Secret Manager

Non inserire password nel Dockerfile o in env pubblici. Usa Secret Manager e monta i segreti come variabili d'ambiente o volumi. Esempio:

gcloud run deploy my-service \
  --update-secrets=DB_PASSWORD=my-db-password:latest

Domini personalizzati e SSL

Cloud Run assegna un URL di default con certificato SSL gestito da Google. Per usare il tuo dominio (es. api.meteoraweb.com) devi verificare la proprietà e creare un mapping:

gcloud beta run domain-mappings create \
  --service my-service \
  --domain api.meteoraweb.com \
  --region europe-west1

Poi aggiungi un record A nel tuo DNS con l'IP che fornisce il comando. Google gestisce il certificato SSL automaticamente. Niente più Let's Encrypt scaduto.

Monitoraggio e logging

Cloud Run si integra nativamente con Cloud Logging. Ogni log del container (stdout/stderr) viene raccolto. Puoi creare metriche personalizzate con Error Reporting per ricevere alert su eccezioni. Noi usiamo anche Google Cloud Monitoring per il numero di richieste e la latenza.

Costi: quanto paga davvero una PMI

Prendiamo un'API che gestisce 1000 richieste al giorno, ciascuna da 200 ms, con 256 MB di RAM. Costo stimato: circa 0.50 €/mese (grazie alla generosa free tier: 2 milioni di richieste/mese gratis). Se diventi grande e fai 1 milione di richieste/mese, parliamo di 5-10 €. Molto meno di un VM sempre acceso.

Errori comuni (e come evitarli)

Porta sbagliata: il server ascolta su 3000 ma Cloud Run manda traffico sulla 8080. Usa la variabile PORT.
Timeout richiesta: richieste che durano più di 60 minuti (massimo configurabile) vengono chiuse. Per job lunghi usa Cloud Run Jobs (non HTTP).
File system non persistente: salvi dati su /tmp e poi ti lamenti che spariscono.
Immagini patchate alla vecchia: usa tag con SHA o commit, non solo :latest.

In sintesi — cosa fare adesso

Prepara un'app stateless che ascolti sulla porta indicata da $PORT.
Costruisci un Dockerfile ottimizzato (multi-stage, immagine leggera).
Fai il deploy di prova con gcloud run deploy e testa l'URL.
Configura minimo 1 istanza per servizi critici, attiva i domini personalizzati.
Imposta Cloud Build per deploy automatici da GitHub.
Monitora i log e imposta alert sugli errori.

Noi, di Meteora Web, usiamo Cloud Run quotidianamente per clienti in tutta Italia. Se vuoi approfondire la parte di monitoraggio, sul nostro sito trovi una guida completa su GA4 con Google Tag Manager — altro strumento che usiamo per tracciare le performance delle app distribuite su Cloud Run.