È 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 all'ambiente di staging o assicurarti che l'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
emy-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 archiviati in apphosting.yaml
devono essere predefiniti e sicuri 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:
- Nella console Firebase, seleziona il progetto di staging (in questo esempio, my-staging-firebase-project).
- Seleziona App Hosting dal menu di navigazione a sinistra.
- Fai clic su Visualizza dashboard nel backend scelto.
- Nella scheda Impostazioni, seleziona Deployment.
- In Nome ambiente,inserisci il nome dell'ambiente. Puoi assegnare all'ambiente il nome che preferisci. In questo esempio, si tratta di staging.
- Fai clic su Salva.
Quando viene attivato un implementazione 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 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
.
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.appspot.com
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.appspot.com
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
Dopo aver modificato il 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
- Per approfondire, consulta un codelab di Firebase che integra un'app ospitata con Firebase Authentication e le funzionalità di IA di Google: Next.js | Angular
- Collega un dominio personalizzato.
- Configura il backend.
- Monitora le implementazioni, l'utilizzo del sito e i log.