Runtime SaaS ti consente di archiviare, ospitare, gestire e monitorare le applicazioni Software as a Service (SaaS) su Google Cloud. Runtime SaaS gestisce i deployment di Terraform su larga scala, consentendoti di gestire sia l'applicazione SaaS che l'infrastruttura su cui è in esecuzione.
Runtime SaaS può essere utilizzato in molti modi da una serie di stakeholder all'interno della pipeline SaaS. Se il tuo lavoro rientra in uno di questi ruoli, potresti essere interessato a utilizzare SaaS Runtime:
- Amministratore della piattaforma
- Sviluppatore di applicazioni
- Architect
- Amministratore della conformità
- Platform engineer
- Operazioni finanziarie
Runtime SaaS offre i seguenti vantaggi:
- Semplifica la gestione dei servizi su larga scala automatizzando le attività di gestione dei servizi (come deployment, rollout e gestione dei flag funzionalità) nei tenant SaaS.
- Espandi la visibilità e il controllo perfezionando gli aggiornamenti e le release in unità configurabili per gestire la tua offerta SaaS con precisione su larga scala.
- Crea coerenza nel tuo ecosistema Google Cloud gestendo i servizi in vari prodotti Google Cloud , tra cui Google Cloud, Google Distributed Cloud, fatturazione, osservabilità e Resource Manager.
- Utilizza un'architettura flessibile e basata su modelli che promuove aggiornamenti e deployment di gruppi basati su unità per una maggiore efficienza e riutilizzabilità.
Come funziona Runtime SaaS?
Runtime SaaS esegue il deployment di artefatti che definiscono la tua offerta SaaS. Questi artefatti devono avere una configurazione Terraform. Il deployment è organizzato in unità distinte che possono essere aggiornate con release contenenti modifiche alla tua offerta tramite un processo di implementazione configurabile.
Per saperne di più sulla nomenclatura di Runtime SaaS, consulta il Glossario.
Prepara il workload per Runtime SaaS
Prima di eseguire il deployment della tua offerta SaaS, ti consigliamo di determinare la disposizione ideale della tua offerta SaaS all'interno dell'ecosistema di Runtime SaaS.
Organizza le parti della tua offerta SaaS che devono essere aggiornate o modificate insieme in configurazioni Terraform distinte. Quando pianifichi la tua offerta SaaS, utilizza i tipi di unità per ogni raggruppamento della tua offerta SaaS.
Una volta definita la struttura ideale per il tuo workload su SaaS Runtime, puoi creare la tua offerta SaaS, i tipi di unità e poi eseguire il deployment delle unità utilizzando un rollout.
Per un esempio di configurazione di Runtime SaaS, consulta la guida rapida.
Service account Runtime SaaS
Runtime SaaS utilizza una combinazione di service account gestiti da Google e gestiti dall'utente:
Service account di runtime SaaS (gestito da Google): questo account viene creato automaticamente dopo la creazione della prima risorsa dell'offerta SaaS. È gestito da Google. Esegue azioni per tuo conto, ad esempio interagisce con altri servizi Google Cloud durante il provisioning dell'unità.
Service account di servizio (gestito dall'utente): crei e gestisci questo service account. Runtime SaaS (tramite Infrastructure Manager) utilizza questo account per eseguire le configurazioni Terraform durante il provisioning o l'aggiornamento delle unità. Questo account funge da identità per la creazione e la gestione delle risorse definite in Terraform. Le autorizzazioni del account di servizio di attivazione sono collegate direttamente alle risorse gestite dalla configurazione Terraform.
Puoi avere più service account di attivazione. Ti consigliamo di avere un account di servizio di attivazione per ogni tenant.
(Facoltativo) account di servizio per la creazione di artefatti (gestito dall'utente): questo service account viene utilizzato per creare e caricare il pacchetto Terraform negli artefatti OCI. Spesso si tratta di un account di servizio Cloud Build, ma può essere qualsiasi account di servizio con le autorizzazioni appropriate per la tua offerta SaaS.
Account di servizio Runtime SaaS (gestito da Google)
Il service account Runtime SaaS è un service agent gestito da Google utilizzato da Runtime SaaS per eseguire operazioni all'interno del progetto.
Questo account di servizio viene eseguito il provisioning automaticamente quando crei la prima risorsa SaaS Runtime. Il account di servizio Runtime SaaS viene creato utilizzando questo formato:
service-PROJECT_NUMBER@gcp-sa-saasservicemgmt.iam.gserviceaccount.com
Sostituisci:
- PROJECT_NUMBER: il numero del progetto.
Account di servizio di attivazione (gestito dall'utente)
Il service account di attivazione è un account di servizio gestito dall'utente che devi creare. Runtime SaaS (tramite Infra Manager) utilizza questo account di servizio per eseguire le configurazioni Terraform. È l'identità che crea, modifica ed elimina le risorse definite in Terraform.
Sei responsabile della creazione di questo account di servizio all'interno del tuo progetto o del tuo progetto tenant.
Variabili di input del account di servizio di attivazione
Quando crei un'unità, devi fornire il account di servizio di attivazione come variabile di input coppia chiave-valore per la configurazione Terraform:
- Nome:
actuation_sa - Tipo di variabile:
String Valore della variabile: indirizzo email del account di servizio di attivazione:
my-actuation-sa@my-identifier.iam.gserviceaccount.com
Autorizzazioni richieste
L'account di servizio di attivazione richiede autorizzazioni sufficienti per gestire le risorse definite nella configurazione Terraform. Come minimo, deve includere:
roles/iam.serviceAccountTokenCreator: consente al account di servizio di generare token per l'autenticazione.roles/config.admin: concede il controllo completo delle risorse di Infra Manager.roles/storage.admin: Concede il controllo completo di Cloud Storage.
Il account di servizio di attivazione deve disporre anche delle autorizzazioni per creare e gestire le risorse Google Cloud specifiche utilizzate dalla tua applicazione.
Ad esempio:
- Se Terraform crea cluster Google Kubernetes Engine (GKE),
il account di servizio deve disporre dei ruoli GKE appropriati
(ad esempio
roles/container.admin). - Se Terraform crea istanze Compute Engine, il service account richiede il ruolo
roles/compute.admin. - Se Terraform crea istanze Cloud SQL, il account di servizio
deve disporre dei ruoli Cloud SQL appropriati (ad esempio
roles/cloudsql.admin).
Consulta la documentazione relativa a ogni Google Cloud risorsa che utilizzi in Terraform per determinare le autorizzazioni necessarie. Concedi il privilegio minimo necessario per il funzionamento dell'applicazione.
Account di servizio di creazione degli artefatti (gestito dall'utente)
Il service account di creazione degli artefatti è un account di servizio gestito dall'utente che crei per utilizzare un sistema di compilazione (come Cloud Build) per creare pacchetti e caricare gli artefatti Terraform in Artifact Registry.
Questo account di servizio è separato dai service account Runtime SaaS e di attivazione, crea il codice Terraform e invia l'artefatto risultante ad Artifact Registry. Spesso si tratta del account di servizio Cloud Build.
Creazione manuale di artefatti
Se crei e carichi manualmente gli artefatti Terraform (ad esempio utilizzando Docker build e Docker push direttamente), non hai bisogno di un account di servizio di creazione degli artefatti separato.
Devi invece eseguire l'autenticazione utilizzando le tue credenziali o un account di servizio con le autorizzazioni Artifact Registry necessarie.
Autorizzazioni richieste
Se utilizzi Cloud Build, il service account Cloud Build in genere richiede i seguenti ruoli:
roles/artifactregistry.writer: per eseguire il push degli artefatti in Artifact Registry.roles/artifactregistry.repoAdmin: per gestire il repository Artifact Registry.roles/storage.admin: Per gestire i bucket Cloud Storage.roles/developerconnect.admin: Autorizzazioni per utilizzare Developer Connect.roles/developerconnect.readTokenAccessor: Autorizzazioni per ottenere il token di lettura di Developer Connect.roles/logging.logWriter: Autorizzazioni per scrivere log.- Se esegui il deployment della configurazione Terraform utilizzando Developer Connect:
roles/cloudbuild.builds.builder: per eseguire le build. - Qualsiasi altra autorizzazione richiesta dal processo di compilazione (ad esempio, l'accesso ai repository di codice sorgente).
Strategie di implementazione
Runtime SaaS utilizza diverse strategie di implementazione per gestire l'aggiornamento delle unità nella tua offerta SaaS. Queste strategie di implementazione seguono l'approccio di Google Cloudal cambiamento applicando approcci coerenti all'implementazione delle modifiche nella tua offerta SaaS.
Utilizza le strategie di implementazione per ridurre al minimo gli impatti negativi sui clienti e isolare i problemi in singoli domini di errore logici e fisici. Definisci le strategie di implementazione creando un tipo di implementazione che specifichi una delle seguenti strategie di implementazione:
Una località alla volta (semplice): una località viene implementata alla volta, senza attese tra le località. Le unità vengono selezionate in modo arbitrario all'interno di una località, con un massimo del 20% delle unità della località aggiornate in un determinato momento.
Questa strategia è consigliata per gli ambienti di sviluppo e gli scenari di emergenza.
Tutte contemporaneamente (semplice): tutte le località iniziano l'implementazione contemporaneamente.
Questa strategia è consigliata per gli ambienti di sviluppo e gli scenari di emergenza.
Progressivo (graduale): all'interno di ogni località, le unità vengono implementate in batch statici basati su percentuali (ad esempio, 1%, 10%, 20%, 30%, ~40%) con tempi di attesa tra i batch. Nelle varie sedi, l'implementazione procede con un aumento esponenziale del numero di sedi simultanee (ad esempio, una sede, poi due, poi quattro) con tempi di attesa (ad esempio, 18 ore) tra le ondate. Le unità all'interno di una località vengono selezionate in modo casuale.
Questa strategia è progettata per implementazioni sicure e prevedibili in più località. Inizia con un'impronta ridotta e si espande gradualmente man mano che aumenta la fiducia. Questa strategia è consigliata negli ambienti di produzione con più di una sede.
Progressivo (singola località): le unità vengono aggiornate in batch statici basati su percentuali (ad esempio 1%, 10%, 20%, 30%, ~40%) con tempi di soak più lunghi (ad esempio 18 ore) tra i batch per consentire un tempo sufficiente per il rilevamento dei problemi e per limitare l'impatto negativo delle modifiche all'implementazione.
Questa strategia è pensata per le offerte SaaS che operano in un'unica località, dando priorità alla sicurezza e alla cautela. Consigliamo questa strategia negli ambienti di produzione con una sede.
Per saperne di più sulla creazione di tipi di implementazione, consulta Creare un tipo di implementazione.
Passaggi successivi
- Prova la guida rapida per scoprire come eseguire il deployment di una VM utilizzando Runtime SaaS.
- Per iniziare a utilizzare Runtime SaaS, inizia con Crea un'offerta SaaS.