Esegui il deployment di più ambienti da un codebase

È normale avere più ambienti di cui è stato eseguito il deployment dalla stessa base di codice, ciascuno con una configurazione leggermente diversa. Ad esempio, potresti voler assegnare meno CPU e RAM al tuo ambiente di staging o assicurarti che il tuo ambiente di produzione mantenga almeno un'istanza attiva e pronta per 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 distinto. 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 su 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"production".
  • In ogni progetto hai creato un backend App Hosting con il ramo attivo impostato sul ramo GitHub che vuoi eseguire il deployment (ad esempio main). Per ulteriori informazioni, consulta la Guida introduttiva all'utilizzo di 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 nel controllo del codice sorgente. Per ulteriori informazioni, consulta Configurare un backend.

Per iniziare, crea un file apphosting.yaml nella directory principale dell'app. Si tratta del file di configurazione di riserva utilizzato quando non viene trovato un file di configurazione specifico per l'ambiente. I valori memorizzati in apphosting.yaml devono essere predefiniti e sicuri da utilizzare per tutti gli ambienti.

Le sezioni seguenti 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 per l'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 scelto.
  4. Nella scheda Impostazioni, seleziona Deployment.
  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 rollout di App Hosting per il tuo backend (su git push o manualmente tramite la console), App Hosting cercherà 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 dell'ambiente, crea un file denominato apphosting.ENVIRONMENT_NAME.yaml per specificare le sostituzioni specifiche 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.

In fase di compilazione, App Hosting unisce questi due file, assegnando 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 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 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 finale unito, 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 alcuni valori runConfig, come CPU, sono stati sovrascritti, così come eventuali 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 dell'ambiente utilizzeranno i valori di override specifici che hai specificato nel file YAML corrispondente e torneranno al valore apphosting.yaml quando non viene trovato un valore. Per i backend senza un nome di ambiente associato, puoi continuare a utilizzare apphosting.yaml.

Passaggi successivi