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 all'ambiente di staging oppure assicurarti che l'ambiente di produzione mantenga almeno un'istanza attiva e pronta a gestire le richieste. Potresti anche voler specificare variabili di ambiente e segreti 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 tipo di ambiente"produzione".
  • In ogni progetto hai creato un backend App Hosting, con il ramo live impostato sul ramo GitHub che vuoi implementare (ad esempio main). Per ulteriori informazioni, 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 controllo del codice sorgente. Per ulteriori informazioni, vedi Configurare un backend.

Per iniziare, crea un file apphosting.yaml nella directory principale 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 ignorare i 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. Seleziona App Hosting dal menu di navigazione a sinistra.
  3. Fai clic su Visualizza dashboard nel 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 git push o manualmente tramite la console), App Hosting verifica la presenza di un file apphosting.ENVIRONMENT_NAME.yaml prima di ripristinare 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 build, App Hosting unisce questi due file, dando la priorità ai valori nel file YAML specifico per l'ambiente rispetto al file apphosting.yaml di base.

In questo esempio, creerai un file denominato apphosting.staging.yaml nella directory radice 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 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 controllare 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 determinati valori runConfig, come la CPU, sono stati sovrascritti, così come le variabili di ambiente sovrapposte.

Passaggio 3: esegui il deployment della base di codice

Una volta terminata la modifica del file apphosting.ENVIRONMENT_NAME.yaml specifico per l'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 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