Esegui il deployment di più ambienti da un codebase

È normale avere più ambienti di cui è stato eseguito il deployment dalla stessa codebase, ognuno con una configurazione leggermente diversa. Ad esempio, potresti voler assegnare meno CPU e RAM al tuo ambiente di gestione temporanea oppure 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, ognuno 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 progetto Firebase di produzione con il "production" environment type.
  • In ogni progetto hai creato un backend App Hosting, con il ramo live impostato sul ramo GitHub di cui vuoi eseguire il deployment (ad esempio main). Per maggiori informazioni, consulta la pagina Inizia a utilizzare 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, il che rende sicuro il controllo del codice sorgente. Per maggiori informazioni, consulta la pagina Configurare un backend.

Per iniziare, crea un file apphosting.yaml nella directory principale della tua app. Questo è il file di configurazione di riserva utilizzato quando non viene trovato un file di configurazione specifico dell'ambiente. I valori archiviati in apphosting.yaml devono essere predefiniti che possono essere utilizzati in sicurezza 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 ambiente per backend.

Per impostare il nome dell'ambiente del backend:

  1. Nella console Firebase, seleziona il progetto di gestione temporanea (in questo esempio, my-staging-firebase-project).
  2. Seleziona App Hosting nella barra di navigazione a sinistra.
  3. Fai clic su Visualizza dashboard nel backend scelto.
  4. Nella scheda Impostazioni, seleziona Ambiente.
  5. In Nome ambiente,inserisci il nome dell'ambiente. Puoi assegnare all'ambiente il nome che preferisci. In questo esempio, è staging.
  6. Fai clic su Salva.

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

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

Per la configurazione specifica dell'ambiente, crea un file con il nome apphosting.ENVIRONMENT_NAME.yaml per specificare gli override specifici dell'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 tempo di 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 che tu abbia già un file apphosting.yaml simile al seguente:

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 controllare nei log di Cloud Build, sarà simile al seguente:

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 sono stati sovrascritti alcuni valori di runConfig, come la CPU, e tutte le variabili di ambiente sovrapposte.

Passaggio 3: esegui il deployment della codebase

Al termine della modifica del file apphosting.ENVIRONMENT_NAME.yaml specifico dell'ambiente, esegui il push del file su GitHub:

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

Tutti i backend taggati con questo nome ambiente utilizzeranno i valori di override specifici che hai specificato nel file YAML corrispondente ed eseguiranno il fallback 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