App Hosting gestisce una serie complessa di attività in background per semplificare il deployment della tua app. Questa pagina descrive le parti principali di questo flusso di attività, fornendo informazioni sui punti in cui potresti voler personalizzare il flusso in base alle esigenze della tua app.
Termini e definizioni chiave
Per comprendere i dettagli del flusso App Hosting, è utile definire alcuni termini in modo molto specifico. Ecco i termini chiave fondamentali:
- Backend: la raccolta di risorse gestite che App Hosting crea per creare ed eseguire la tua app web.
- Build:una revisione specifica della tua app, in genere collegata a un commit Git. Il processo di creazione di una build prevede numerosi sottoprocessi, in particolare la creazione dell'app in Cloud Build, e il deployment di una revisione (che inizialmente gestisce lo 0% del traffico fino al suo lancio) in Cloud Run.
- Lancio: il processo di impostazione di una build per la gestione attiva del traffico. Quando viene attivato automaticamente da un commit Git, App Hosting prima crea una build utilizzando il branch pubblicato, quindi crea un lancio per indirizzare il traffico in tempo reale.
- Branch pubblicato: il branch del tuo repository GitHub di cui viene eseguito il deployment in URL pubblicato. Spesso è il branch in cui vengono uniti i branch delle funzionalità o i branch di sviluppo.
Architettura di Google Cloud e App Hosting
App Hosting orchestra un insieme di prodotti Google Cloud per consentirti di eseguire il deployment, gestire e monitorare la tua app web. Le app vengono create con Cloud Build, gestite su Cloud Run, e memorizzate nella cache in Cloud CDN. I servizi integrati come Cloud Secret Manager proteggono le tue chiavi API.
- Quando viene eseguito il push di un commit nel branch pubblicato, Google Cloud Developer Connect invia un evento a Firebase App Hosting.
- In risposta a questo evento, Firebase App Hosting crea una nuova build per
il backend collegato al repository.
- Innanzitutto, Firebase App Hosting crea una nuova build Cloud Build per il commit. In questo job, i buildpack di Google Cloud determinano quale framework viene utilizzato nella tua applicazione per creare un container e una configurazione (incluse variabili di ambiente, secret, istanze minime o massime, memoria di concorrenza, CPU e configurazione VPC) adatti alla tua applicazione. Per ulteriori informazioni, consulta la sezione the App Hosting processo di compilazione For.
- Al termine del job Cloud Build, il container viene archiviato in un repository Artifact Registry dedicato a Firebase App Hosting. Firebase App Hosting aggiunge quindi una nuova revisione Cloud Run a un servizio Cloud Run utilizzando l'immagine e la configurazione.
- Una volta completata e verificata la revisione di Cloud Run, Firebase App Hosting modifica la configurazione del traffico in modo da indirizzare tutte le nuove richieste alla nuova revisione di Cloud Run. A questo punto, il lancio è completo.
- Quando viene inviata una richiesta a un sito web ospitato su Firebase App Hosting, la richiesta viene gestita da Google Cloud Load Balancer con Cloud CDN abilitato. Le richieste non memorizzate nella cache vengono inviate al servizio Cloud Run. Per indicazioni su come ottimizzare il rendimento con Cloud CDN, consulta la sezione Memorizzare nella cache i contenuti dell'app.
Integrazione del framework
App Hosting fornisce supporto preconfigurato per la creazione e il deployment di app web sviluppate in questi framework:
- Next.js 13.5.x e versioni successive
- Angular 18.2.x e versioni successive
Per informazioni dettagliate su versioni e livelli di supporto specifici, consulta le pianificazioni di supporto.
Oltre a Next.js e Angular, App Hosting supporta anche qualsiasi framework web in grado di fornire un output di build che corrisponda alla nostra specifica del pacchetto di output. Per ulteriori informazioni sui framework, sugli adattatori di framework e sugli strumenti correlati supportati da App Hosting, consulta la sezione Frameworks and tooling for App Hosting.
Come funziona l'intezione del repository App Hosting
L'importante connessione tra il repository GitHub e il App Hosting backend viene gestita da Developer Connect, la piattaforma di connettività di Google Cloud per gli strumenti DevOps esterni. Quando configuri questa connessione (in genere durante la creazione di un backend App Hosting), il flusso di lavoro dell'interfaccia utente di Developer Connect ti guida nell'installazione dell'app Firebase GitHub. I passaggi chiave di questo processo sono:
- Concedi a Developer Connect il ruolo di amministratore di Secret Manager. In questo modo, il sistema può archiviare le credenziali in modo sicuro come "secret" in Cloud Secret Manager.
- Autorizza l'app Firebase GitHub ad accedere al tuo repository GitHub. Potresti aver bisogno di autorizzazioni GitHub aggiuntive GitHub per accedere al repository corretto.
- Developer Connect archivia un token di autorizzazione GitHub dedicato nel repository di Secret Manager del tuo progetto. Non modificare o eliminare questo token.
Inoltre, App Hosting si integra con l'API Checks di GitHub per fornire un controllo per i lanci. Questo controllo ti consente di visualizzare lo stato del lancio in GitHub e di eseguire il debug del processo di deployment in caso di errori.
Integrazione con Firebase e altri servizi Google
App Hosting configura gli ambienti di build e di runtime in modo che tu possa inizializzare l'SDK Admin di Firebase con le credenziali predefinite dell'applicazione Google. In questo modo, il backend può comunicare con altri prodotti Firebase sia in fase di build sia in fase di runtime. Per ulteriori informazioni sull'inizializzazione dell'app e su altri argomenti correlati all'SDK Firebase, consulta la sezione Integrare gli SDK Firebase nell'app web.
App Hosting località
App Hosting crea le risorse del backend in una località specifica, chiamata regione principale. Sebbene App Hosting si integri con una CDN globale per una distribuzione rapida, i contenuti non memorizzati nella cache vengono gestiti dalla regione principale dell'app. Questa flessibilità nella località dell'app web presenta vantaggi chiave:
- Miglioramento del rendimento e riduzione della latenza avvicinando geograficamente i dati agli utenti.
- Un errore catastrofico per App Hosting in una regione non influirebbe sulle app web di cui è stato eseguito il deployment in altre regioni.
Puoi scegliere una di queste regioni quando crei un App Hosting backend dalla Firebase console o dalla Firebase CLI:
us-central1(Iowa)us-east4(N. Virginia)us-east5(Columbus)asia-east1(Taiwan)asia-southeast1(Singapore)europe-west4(Paesi Bassi)
Il service account del servizio di backend App Hosting
Durante la build e in fase di runtime, il backend App Hosting esegue l'autenticazione con altri servizi Google con un service account. Un service account predefinito per questi scopi viene creato la prima volta che abiliti App Hosting in un progetto Firebase:
firebase-app-hosting-compute@PROJECT ID.iam.gserviceaccount.com
Per impostazione predefinita, questo service account si applica a tutti i backend e dispone di un insieme minimo di autorizzazioni per consentirti di creare, eseguire e monitorare l'app. Dispone anche dell' autorizzazione per autenticare l'SDK Admin con le credenziali predefinite dell'applicazione, per eseguire operazioni come il caricamento dei dati da Cloud Firestore. Consulta la sezione Ruoli App Hostingdi Firebase.
Se la tua app deve interagire con altri servizi Google in fase di build o da un backend in esecuzione, puoi personalizzare il service account predefinito aggiungendo ruoli. Ad esempio, se la tua app richiede autorizzazioni per Vertex AI, potresti dover aggiungere
roles/aiplatform.user
o un ruolo correlato.