Deploy su Cloud Run, GKE e App Engine

Le piattaforme applicative gestite di Google Cloud hanno modelli di deploy diversi, e l’esame verifica che tu sappia scegliere. Cloud Run esegue container stateless che scalano fino a zero: ogni deploy crea una nuova revision immutabile e il traffico viene instradato per percentuali tra revision. È il modello ideale per rilasci progressivi senza gestire infrastruttura (occhio a min-instances e concurrency per contenere il cold start). GKE offre controllo fine sul rollout tramite i Deployment Kubernetes (strategia RollingUpdate con maxSurge/maxUnavailable), utile quando servono sidecar, StatefulSet o un service mesh. App Engine standard versiona l’applicazione e permette lo split del traffico tra version. In tutti i casi il container proviene da Artifact Registry, non dal codice sorgente.

Strategie di rilascio: blue/green, canary, rolling, traffic splitting

Il rolling update sostituisce gradualmente le istanze vecchie con le nuove: è il default di GKE, minimizza il downtime ma per un breve periodo convivono due versioni (attenzione a compatibilità API e schema DB). Il blue/green tiene due ambienti completi e sposta il traffico in modo atomico dal blue al green: switch e rollback istantanei, ma costo doppio durante la transizione e nessuna validazione graduale. Il canary espone la nuova versione a una piccola quota di traffico reale, la si osserva (tasso di errore, latenza con Cloud Trace) e si aumenta la percentuale solo se le metriche reggono.

Su Cloud Run il canary si realizza con il traffic splitting tra revision: si rilascia la nuova revision con --no-traffic e un tag, che le assegna un URL dedicato per il test, poi si sposta il traffico per gradi (es. 5% → 50% → 100%). Su App Engine lo split avviene tra version, su GKE con Deployment/Service multipli o tramite service mesh.

Cloud Deploy e la pipeline CI/CD

Distinzione chiave, spesso oggetto di domanda: la CI (Continuous Integration) è compito di Cloud Build, che a ogni commit compila, esegue i test e produce l’immagine da pubblicare in Artifact Registry. La CD (Continuous Delivery) è compito di Cloud Deploy, servizio gestito che definisce una delivery pipeline con target in sequenza (dev → stage → prod). Si crea una release e la si promuove di stage in stage; per la produzione si possono imporre approvazioni manuali. Cloud Deploy supporta nativamente la strategia canary con fase di verifica e il rollback con un singolo comando, mantenendo lo storico dei rollout. Sotto il cofano usa Skaffold e rilascia su target Cloud Run e GKE.

Rollback, feature flag e config per ambiente

Il rollback deve essere rapido e senza rebuild. Su Cloud Run basta riportare il 100% del traffico a una revision precedente (immutabile); su GKE si usa kubectl rollout undo; con Cloud Deploy c’è il rollback della pipeline. I feature flag disaccoppiano il deploy dal rilascio: il codice è già in produzione ma la feature si attiva o disattiva a runtime, evitando di dover fare rollback dell’intera revision per spegnere una singola funzionalità (dark launch).

La configurazione va separata per ambiente: env vars per i parametri non sensibili e progetti distinti per dev/stage/prod. I segreti non vanno mai hardcoded nel codice né messi in env in chiaro o nell’immagine: si usano Secret Manager, con versioni referenziate per ambiente, e l’accesso avviene tramite Workload Identity/impersonation, non con service account key scaricate.

Trappole tipiche d’esame

  • Rollback immediato dopo un deploy fallito su Cloud Run → soluzione: le revision sono immutabili, riporta il 100% del traffico a quella precedente; non serve ricostruire l’immagine né ridistribuire.
  • Testare la nuova versione su traffico reale limitato → soluzione: canary via traffic splitting (rilascio con --no-traffic + tag per un URL di test, poi aumento delle percentuali). Il blue/green fa uno switch atomico e non consente esposizione graduale.
  • “Buildare e testare a ogni commit” vs “promuovere tra ambienti” → soluzione: la prima è CI (Cloud Build), la seconda è CD (Cloud Deploy); sono prodotti distinti, non confonderli.
  • Promozione dev→stage→prod con approvazione prima della produzione → soluzione: delivery pipeline di Cloud Deploy con target in sequenza e approval gate su prod, non script manuali.
  • Configurazione e segreti diversi per ambiente → soluzione: Secret Manager per i segreti (mai in env in chiaro o nell’immagine) con accesso via Workload Identity, non service account key.
  • Disattivare una feature senza ridistribuire → soluzione: feature flag a runtime che disaccoppia deploy e release; il rollback dell’intera revision è sproporzionato per spegnere una singola funzionalità.