Panoramica di App Lifecycle Manager

App Lifecycle Manager (precedentemente noto come Runtime SaaS) ti consente di archiviare, ospitare, gestire e monitorare le applicazioni Software as a Service (SaaS) su Google Cloud. App Lifecycle Manager gestisce i deployment di Terraform su larga scala, consentendoti di gestire sia l'applicazione SaaS che l'infrastruttura su cui è in esecuzione.

App Lifecycle Manager può essere utilizzato in molti modi da una varietà di stakeholder all'interno della pipeline SaaS. Se il tuo lavoro rientra in uno di questi ruoli, potresti essere interessato a utilizzare App Lifecycle Manager:

  • Amministratore della piattaforma
  • Sviluppatore di applicazioni
  • Architect
  • Amministratore della conformità
  • Platform engineer
  • Operazioni finanziarie

App Lifecycle Manager offre i seguenti vantaggi:

  • Semplifica la gestione dei servizi su larga scala automatizzando le attività di gestione dei servizi (come deployment, rollout e gestione flag funzionalità) tra i tenant SaaS.
  • Espandi l'osservabilità e il controllo ottimizzando gli aggiornamenti e le release tra le unità configurabili per gestire la tua offerta SaaS con precisione su larga scala.
  • Crea coerenza nel tuo Google Cloud ecosistema gestendo i servizi su vari Google Cloud prodotti, tra cui Google Cloud, Google Distributed Cloud, fatturazione, osservabilità e Resource Manager.
  • Utilizza un'architettura flessibile e basata su template che promuove gli aggiornamenti e i deployment dei gruppi basati su unità per migliorare l'efficienza e la riusabilità.

Come funziona App Lifecycle Manager?

App Lifecycle Manager esegue il deployment degli 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 rollout configurabile.

Per ulteriori informazioni sulla nomenclatura di App Lifecycle Manager, consulta il Glossario.

Prepara il workload per App Lifecycle Manager

Prima di eseguire il deployment della tua offerta SaaS, ti consigliamo di determinare la disposizione ideale della tua offerta SaaS all'interno dell'ecosistema App Lifecycle Manager.

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 App Lifecycle Manager, puoi creare la tua offerta SaaS, i tipi di unità e poi eseguire il deployment delle unità utilizzando un rollout.

Per un esempio della configurazione di App Lifecycle Manager, consulta la Guida rapida.

Utilizza i template compositi con App Lifecycle Manager

Puoi utilizzare template compositi tramite App Design Center per definire l'infrastruttura delle offerte di applicazioni App Lifecycle Manager.

Dopo aver collegato un template composito alla tua offerta SaaS, App Lifecycle Manager popolerà i tipi di unità definiti nel template. In questo modo, puoi eseguire il deployment delle unità in base alla struttura e alle risorse definite nel template composito.

Puoi modificare i template compositi in App Design Center e vedere le modifiche riflesse nelle offerte SaaS di App Lifecycle Manager.

Per ulteriori informazioni sui template compositi, consulta la documentazione relativa alla progettazione dei template compositi. Per ulteriori informazioni sul collegamento dei template compositi alle offerte di App Lifecycle Manager, consulta Modellare e impacchettare le unità di deployment.

Service account App Lifecycle Manager

App Lifecycle Manager utilizza una combinazione di service account gestiti da Google e gestiti dall'utente:

  • Service account di servizio Lifecycle Manager (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 Google Cloud servizi durante il provisioning delle unità.

  • Service account di servizio (gestito dall'utente): crei e gestisci questo service account. App Lifecycle Manager (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 direttamente collegate 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 di creazione degli 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 App Lifecycle Manager (gestito da Google)

Il service account App Lifecycle Manager è un service agent gestito da Google utilizzato da App Lifecycle Manager per eseguire operazioni all'interno del progetto.

Questo account di servizio viene sottoposto a provisioning automatico quando crei la prima risorsa App Lifecycle Manager. Il account di servizio App Lifecycle Manager 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. App Lifecycle Manager (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.

Hai la responsabilità di creare questo account di servizio all'interno del tuo progetto o del 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 della 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

Il service account di attivazione richiede autorizzazioni sufficienti per gestire le risorse definite nella configurazione Terraform. Come minimo, deve avere:

  • roles/iam.serviceAccountTokenCreator: consente al account di servizio di generare token per l'autenticazione.
  • roles/config.admin: concede il controllo completo sulle risorse di Infra Manager.
  • roles/storage.admin: concede il controllo completo di Cloud Storage.

Il account di servizio di attivazione deve anche disporre delle autorizzazioni per creare e gestire le risorse Google Cloud specifiche utilizzate dall'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 deve disporre del 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 di ogni Google Cloud risorsa utilizzata 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 impacchettare e caricare gli artefatti Terraform in Artifact Registry.

Questo account di servizio è separato dai service account App Lifecycle Manager 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 degli artefatti

Se crei e carichi manualmente gli artefatti Terraform (ad esempio, utilizzando direttamente Docker build e Docker push), non hai bisogno di un account di servizio di creazione degli artefatti separato.

Devi invece eseguire l'autenticazione utilizzando le tue credenziali o un service account 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 inviare gli artefatti ad 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 i 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, accesso ai repository di codice sorgente).

Strategie di rollout

App Lifecycle Manager utilizza diverse strategie di rollout per gestire l'aggiornamento delle unità nella tua offerta SaaS. Queste strategie di rollout seguono Google Cloud's approach to change applicando approcci coerenti al deployment delle modifiche nella tua offerta SaaS.

Utilizza le strategie di rollout 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 rollout creando un tipo di rollout specificando una delle seguenti strategie di rollout:

  • Una località alla volta (semplice): il rollout viene eseguito in una località alla volta, senza attesa tra le località. Le unità vengono selezionate in modo arbitrario all'interno di una località, con un massimo del 5% 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): il rollout inizia in tutte le località contemporaneamente.

    Questa strategia è consigliata per gli ambienti di sviluppo e gli scenari di emergenza.

  • Progressiva (graduale): all'interno di ogni località, il rollout delle unità viene eseguito in batch statici basati sulla percentuale (ad esempio, 1%, 10%, 20%, 30%, ~40%) con tempi di soak tra i batch. Tra le località, il rollout procede con un aumento esponenziale del numero di località simultanee (ad esempio, una località, poi due, poi quattro) con tempi di soak (ad esempio, 18 ore) tra le ondate. Le unità all'interno di una località vengono selezionate in modo casuale.

    Questa strategia è progettata per rollout sicuri 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 località.

  • Progressiva (singola località): le unità vengono aggiornate in batch statici basati sulla percentuale (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 limitare l'impatto negativo delle modifiche del rollout.

    Questa strategia è pensata per le offerte SaaS che operano in un'unica località, dando priorità alla sicurezza e alla cautela. Ti consigliamo questa strategia negli ambienti di produzione con una località.

Per ulteriori informazioni sulla creazione di tipi di rollout, consulta Creare un tipo di rollout.

Regionalizzazione di App Lifecycle Manager

Le risorse dell'offerta SaaS definiscono dove possono risiedere le unità App Lifecycle Manager e come vengono gestiti i rollout. Quando crei un'offerta SaaS, le regioni selezionate fungono da unica fonte di verità per le regioni supportate della tua offerta SaaS. Le regioni selezionate sono le regioni disponibili che hai definito per la tua offerta SaaS.

Quando utilizzi App Lifecycle Manager tramite Google Cloud console, App Lifecycle Manager automatizza la replica delle risorse definite nella tua offerta SaaS tra le regioni. In questo modo, garantisci la coerenza e la disponibilità delle risorse App Lifecycle Manager in tutte le regioni disponibili che hai definito nella tua offerta SaaS.

App Lifecycle Manager replica queste risorse:

  • Offerta SaaS (Saas)
  • Tipo di unità (UnitKind)
  • Release (Release)

Utilizzare global come regione

Includere global come regione all'interno dell'offerta SaaS è in genere sconsigliato per le destinazioni di deployment. App Lifecycle Manager utilizza la regione global per propagare i rollout regionali. I rollout regionali non possono essere eseguiti nella regione global.

Regionalizzazione del rollout

Le località supportate per i rollout sono determinate dalle regioni di primo livello definite nelle regioni disponibili dell'offerta SaaS.

I rollout leggono l'elenco delle regioni disponibili dall'offerta SaaS associata.

Replica delle risorse

App Lifecycle Manager gestisce la creazione e gli aggiornamenti delle risorse in tutte le regioni disponibili dell'offerta SaaS.

Quando aggiorni le regioni disponibili dell'offerta SaaS, App Lifecycle Manager gestisce la replica:

  • Località aggiunte: le risorse vengono replicate nelle località appena aggiunte.
  • Località con copie precedenti: i contenuti vengono aggiornati.

Località di Artifact Registry e Developer Connect

Le località del repository Artifact Registry e dell'istanza Developer Connect hanno requisiti specifici:

  • La regione del repository Artifact Registry e dell'istanza Developer Connect può essere qualsiasi regione valida Google Cloud . Non devono essere incluse nelle regioni disponibili dell'offerta SaaS.

  • La regione del repository Artifact Registry deve corrispondere alla regione dell'istanza Developer Connect.

    Ciò richiede la presenza di risorse di offerta SaaS, release e tipo di unità in tutte le regioni definite nell'offerta SaaS, anche se Artifact Registry e Developer Connect risiedono in una singola regione (potenzialmente diversa).

  • Le unità possono essere create solo nelle regioni specificate nell'offerta SaaS.

Esempio di configurazione delle regioni di App Lifecycle Manager

Abbiamo fornito questo esempio per dimostrare come funziona la regionalizzazione quando si utilizza App Lifecycle Manager con la replica delle risorse gestite.

Ad esempio, se volessi eseguire il deployment della tua offerta SaaS in us-central1 e europe-west4, ospitando il repository Artifact Registry e l'istanza Developer Connect in us-east1, l'infrastruttura delle regioni di App Lifecycle Manager sarebbe simile a questa:

  • Regioni disponibili dell'offerta SaaS: ['us-central1', 'europe-west4']
  • Regione del repository Artifact Registry: us-east1
  • Regione dell'istanza Developer Connect: us-east1
  • Risorse tipo di unità e release: App Lifecycle Manager gestisce la creazione e gli aggiornamenti di queste risorse nelle regioni global, us-central1 e europe-west4
  • Unità: le unità possono essere create in us-central1 o europe-west4

Questa configurazione ti consente di gestire i deployment in due regioni mantenendo la gestione degli artefatti centralizzata in una terza regione distinta con la replica automatica delle risorse. Quando selezioni le regioni, devi tenere attentamente in considerazione i requisiti di latenza, conformità e residenza dei dati.

Passaggi successivi

  • Prova la Guida rapida per scoprire come eseguire il deployment di una VM utilizzando App Lifecycle Manager.
  • Per iniziare a utilizzare App Lifecycle Manager, inizia con Creare un'offerta SaaS.