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 diversi stakeholder all'interno della pipeline SaaS. Se il tuo lavoro si identifica con uno di questi ruoli, potrebbe interessarti 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, implementazioni e gestione flag funzionalità) nei tuoi tenant SaaS.
  • Espandi l'osservabilità e il controllo perfezionando gli aggiornamenti e le release tra unità configurabili per gestire l'offerta di app con precisione su larga scala.
  • Crea coerenza nel tuo ecosistema Google Cloud gestendo i servizi gestiti tra vari prodotti Google Cloud , tra cui Google Cloud, Google Distributed Cloud, fatturazione Cloud, 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 riusabilità.

Come funziona App Lifecycle Manager?

App Lifecycle Manager esegue il deployment degli artefatti che definiscono la tua offerta di app. 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'implementazione 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 dell'offerta di app, ti consigliamo di determinare la disposizione ideale dell'offerta di app all'interno dell'ecosistema di App Lifecycle Manager.

Organizza le parti della tua offerta di app che devono essere aggiornate o modificate insieme in configurazioni Terraform distinte. Quando pianifichi l'offerta dell'app, utilizza i tipi di unità per ogni raggruppamento dell'offerta dell'app.

Una volta definita la struttura ideale per il tuo workload su App Lifecycle Manager, puoi creare l'offerta di app, i tipi di unità e poi eseguire il deployment delle unità utilizzando un'implementazione.

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

Utilizza i template compositi con App Lifecycle Manager

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

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

Puoi modificare i modelli compositi in App Design Center e visualizzare le modifiche applicate alle offerte di app di App Lifecycle Manager.

Per saperne di più sui template compositi, consulta la documentazione Progetta template compositi. Per saperne di più sul collegamento di template compositi alle offerte di App Lifecycle Manager, consulta Modella e pacchettizza le unità di deployment.

Service account App Lifecycle Manager

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

  • Service account di servizio Lifecycle Manager (gestito da Google): questo account viene creato automaticamente dopo la creazione della prima risorsa di offerta dell'app. È gestito da Google. Esegue azioni per tuo conto, ad esempio interagisce con altri servizi Google Cloud durante il provisioning delle unità.

  • Service account di servizio (gestito dall'utente): sei tu a creare e gestire 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 attuazione sono direttamente collegate alle risorse gestite dalla configurazione Terraform.

    Puoi avere più service account di attuazione. Ti consigliamo di avere un account di servizio di attuazione 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 in 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 di app.

Account di servizio App Lifecycle Manager (gestito da Google)

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

Il provisioning di questo account di servizio viene eseguito automaticamente quando crei la tua 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 attuazione (gestito dall'utente)

Il service account di attuazione è 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.

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 attuazione

Quando crei un'unità, devi fornire il account di servizio di attuazione come variabile di input della coppia chiave-valore per la configurazione di Terraform:

  • Nome: actuation_sa
  • Tipo di variabile: String

  • Valore della variabile: indirizzo email del account di servizio di attuazione:

    my-actuation-sa@my-identifier.iam.gserviceaccount.com

Autorizzazioni richieste

Il service account di attuazione richiede autorizzazioni sufficienti per gestire le risorse definite nella configurazione Terraform. Come minimo, sono necessari:

  • 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 attuazione deve inoltre disporre 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 avere i ruoli GKE appropriati (ad esempio roles/container.admin).
  • Se Terraform crea istanze Compute Engine, il service account deve avere il ruolo roles/compute.admin.
  • Se Terraform crea istanze Cloud SQL, il account di servizio deve avere i ruoli Cloud SQL appropriati (ad esempio roles/cloudsql.admin).

Consulta la documentazione di ogni risorsa Google Cloud che utilizzi in Terraform per determinare le autorizzazioni necessarie. Concedi il privilegio minimo necessario per il funzionamento della tua applicazione.

Account di servizio per la creazione di artefatti (gestito dall'utente)

Il service account per la creazione di artefatti è un account di servizio gestito dall'utente che crei per utilizzare un sistema di compilazione (come Cloud Build) per pacchettizzare e caricare gli artefatti Terraform in Artifact Registry.

Questo account di servizio è separato dai service account App Lifecycle Manager e di attuazione e crea il codice Terraform ed esegue il push dell'artefatto risultante in 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 separato per la creazione degli artefatti.

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 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 i log.
  • Se esegui il deployment della configurazione Terraform utilizzando Developer Connect: roles/cloudbuild.builds.builder: per eseguire le build.
  • Eventuali altre autorizzazioni richieste dal processo di compilazione (ad esempio, l'accesso ai repository di codice sorgente).

Strategie di implementazione

App Lifecycle Manager utilizza diverse strategie di implementazione per gestire l'aggiornamento delle unità nella tua offerta di app. Queste strategie di implementazione seguono l'approccio di Google Cloudal cambiamento applicando approcci coerenti al deployment delle modifiche nell'offerta di app.

Utilizza strategie di implementazione per ridurre al minimo gli impatti negativi sui clienti e isolare i problemi in singoli domini in errore logici e fisici. Definisci le tue strategie di implementazione creando un tipo di implementazione che specifichi una delle seguenti strategie di implementazione:

  • Una località alla volta (semplice): viene aggiornata una località alla volta, senza attesa tra una località e l'altra. Le unità vengono selezionate arbitrariamente 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.

  • Tutto in una volta (semplice): l'aggiornamento di tutte le località inizia contemporaneamente.

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

  • Progressivo (graduale): all'interno di ogni località, le unità vengono aggiornate in batch statici basati su percentuali (ad esempio 1%, 10%, 20%, 30%, ~40%) con tempi di soak tra i batch. Nelle varie località, l'implementazione 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 wave. 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 località.

  • Progressiva (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 limitare l'impatto negativo delle modifiche dell'implementazione.

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

Per saperne di più sulla creazione di tipi di implementazione, consulta Crea un tipo di implementazione.

Regionalizzazione di App Lifecycle Manager

Le risorse Offerta di app definiscono dove possono risiedere le unità di App Lifecycle Manager e come vengono gestiti i rollout. Quando crei un'offerta di app, le regioni che selezioni fungono da Single Source Of Truth per le regioni supportate della tua offerta di app. Le regioni selezionate sono le regioni disponibili che hai definito per la tua offerta di app.

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

App Lifecycle Manager replica queste risorse:

  • Offerta dell'app (Saas)
  • Tipo di unità (UnitKind)
  • Release (Release)

Utilizzo di global come regione

In genere, non è consigliabile includere global come regione all'interno dell'offerta di app per i target 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 dell'implementazione

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

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

Replica delle risorse

App Lifecycle Manager gestisce la creazione e gli aggiornamenti delle risorse in tutte le regioni disponibili della tua offerta di app.

Quando aggiorni le regioni disponibili per l'offerta di app, App Lifecycle Manager gestisce la replica:

  • Località aggiunte: le risorse vengono replicate nelle località appena aggiunte.
  • Posizioni 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 Google Cloud valida. Non è necessario che siano incluse nelle regioni disponibili dell'offerta dell'app.

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

    Ciò richiede la presenza di risorse di tipo offerta, release e unità dell'app in tutte le regioni definite nell'offerta dell'app, anche se Artifact Registry e Developer Connect si trovano in un'unica regione (potenzialmente diversa).

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

Esempio di configurazione delle regioni di App Lifecycle Manager

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

Ad esempio, se vuoi eseguire il deployment della tua offerta di app 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 alla seguente:

  • Regioni in cui è disponibile l'offerta di app: ['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 considerare attentamente 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, consulta Crea un'offerta di app.