Esegui il deployment di più ambienti da un codebase

È comune avere più ambienti di cui è stato eseguito il deployment dallo stesso codebase, ognuno con una configurazione leggermente diversa. Ad esempio, potresti voler assegnare meno CPU e RAM al tuo ambiente di staging oppure potresti voler assicurarti che il tuo ambiente di produzione mantenga almeno un'istanza attiva e pronta a gestire le richieste. Potresti anche voler specificare variabili di ambiente e secret diversi a seconda dell'ambiente e delle risorse che vuoi utilizzare.

Questa guida descrive come eseguire il deployment di un ambiente di produzione e di gestione temporanea, ciascuno in un progetto Firebase separato. Seguendo gli stessi principi, puoi eseguire il deployment in altri tipi di ambienti. Per scoprire di più sugli ambienti, consulta la Panoramica degli ambienti e le best practice generali per la configurazione dei progetti Firebase.

Prerequisiti

  • Il codice dell'applicazione è già archiviato in GitHub.
  • Hai già creato un progetto distinto per ciascuno dei tuoi ambienti, ad esempio my-production-firebase-project e my-staging-firebase-project. Assicurati di taggare il tuo progetto Firebase di produzione con il tipo di ambiente"produzione".
  • In ogni progetto hai creato un backend App Hosting, con il branch live impostato sul branch GitHub che vuoi eseguire il deployment (ad esempio main). Per saperne di più, consulta la sezione Guida introduttiva a App Hosting.

Passaggio 0: crea una configurazione predefinita in apphosting.yaml

App Hosting supporta un file di configurazione denominato apphosting.yaml per gestire le impostazioni di runtime (CPU, concorrenza, limiti di memoria e così via) e le variabili di ambiente per la tua app. Supporta anche i riferimenti ai secret gestiti con Cloud Secret Manager, rendendo sicuro il check-in nel controllo del codice sorgente. Per saperne di più, consulta Configurare un backend.

Per iniziare, crea un file apphosting.yaml nella directory root dell'app. Questo è il file di configurazione di riserva utilizzato quando non viene trovato un file di configurazione specifico per l'ambiente. I valori archiviati in apphosting.yaml devono essere valori predefiniti sicuri da utilizzare per tutti gli ambienti.

Le sezioni successive spiegano come eseguire l'override dei valori predefiniti in apphosting.yaml per ambienti specifici. Questo flusso di esempio crea un ambiente di gestione temporanea.

Passaggio 1: imposta il nome dell'ambiente

Ogni backend App Hosting ha un'impostazione Nome ambiente. Questo campo viene utilizzato per mappare il backend a un file di configurazione specifico dell'ambiente e può essere modificato in qualsiasi momento. Puoi impostare un solo nome di ambiente per backend.

Per impostare il nome dell'ambiente del backend:

  1. Nella console Firebase, seleziona il progetto di staging (in questo esempio, my-staging-firebase-project).
  2. Vai a Hosting e serverless > App Hosting.
  3. Fai clic su Visualizza sul backend che hai scelto.
  4. Nella scheda Impostazioni, seleziona Ambiente.
  5. In Nome ambiente,inserisci il nome del tuo ambiente. Puoi assegnare all'ambiente il nome che preferisci. In questo esempio, è staging.
  6. Fai clic su Salva.

Quando viene attivato un rollout App Hosting per il backend (tramite push git o manualmente tramite la console Firebase), App Hosting verifica la presenza di un file apphosting.ENVIRONMENT_NAME.yaml prima di eseguire il fallback a apphosting.yaml.

Passaggio 2: crea il file apphosting.yaml specifico per l'ambiente

Per la configurazione specifica per l'ambiente, crea un file con il nome apphosting.ENVIRONMENT_NAME.yaml per specificare gli override specifici per l'ambiente. Questo file ha lo stesso formato del file apphosting.yaml predefinito e deve trovarsi nella directory principale dell'app insieme a apphosting.yaml.

Al momento della compilazione, App Hosting unisce questi due file, dando la priorità ai valori nel file YAML specifico dell'ambiente rispetto al file apphosting.yaml di base.

In questo esempio, creerai un file denominato apphosting.staging.yaml nella directory principale dell'app:


runConfig:
  cpu: 1
  memoryMiB: 512
  concurrency: 5

env:
-   variable: API_URL
    value: api.staging.service.com
    availability:
      -   BUILD

-   variable: DATABASE_URL
    secret: secretStagingDatabaseURL

Supponiamo di avere già un apphosting.yaml simile a questo:

runConfig:
  cpu: 3
  memoryMiB: 1024
  maxInstances: 4
  minInstances: 0
  concurrency: 100

env:
-   variable: API_URL
    value: api.service.com
    availability:
      -   BUILD
      -   RUNTIME

-   variable: STORAGE_BUCKET
    value: mybucket.firebasestorage.app
    availability:
      -   RUNTIME

-   variable: API_KEY
    secret: secretIDforAPI

L'output unito finale, che puoi esaminare nei log di Cloud Build, avrebbe questo aspetto:

runConfig:
  cpu: 1
  memoryMiB: 512
  maxInstances: 4
  minInstances: 0
  concurrency: 5

env:
-   variable: API_URL
    value: api.staging.service.com
    availability:
      -   BUILD

-   variable: STORAGE_BUCKET
    value: mybucket.firebasestorage.app
    availability:
      -   RUNTIME

-   variable: API_KEY
    secret: secretIDforAPI

-   variable: DATABASE_URL
    secret: secretStagingDatabaseURL

Tieni presente che anche alcuni valori di runConfig, come la CPU, sono stati sovrascritti, così come le variabili di ambiente sovrapposte.

Passaggio 3: esegui il deployment del codebase

Una volta terminata la modifica del file apphosting.ENVIRONMENT_NAME.yaml specifico per l'ambiente, esegui il push del file in GitHub:

$ git add apphosting.<ENVIRONMENT_NAME>.yaml
$ git commit -m "Added environment specific yaml file"
$ git push

Tutti i backend taggati con questo nome di ambiente utilizzeranno gli override specifici che hai specificato nel file YAML corrispondente e torneranno a apphosting.yaml quando non viene trovato un valore. Per i backend senza un nome ambiente associato, puoi continuare a utilizzare apphosting.yaml.

Passaggi successivi