La procedura di compilazione di App Hosting

Firebase App Hosting utilizza Cloud Build per trasformare il codice sorgente dell'applicazione in un formato containerizzato adatto al deployment su Cloud Run.

Il processo di compilazione si svolge nelle seguenti fasi principali:

  1. ubuntu: inizializzazione del workspace.

  2. preparer: raccoglie il codice sorgente e la configurazione dell'applicazione.

  3. pre-buildpack: prepara l'ambiente buildpack.

  4. build: installa le dipendenze e crea l'applicazione.

  5. publisher: finalizza il container di produzione Cloud Run.

Questi cinque passaggi corrispondono direttamente ai passaggi di build visualizzati in Cloud Build nella console Google Cloud:

Acquisizione schermo di una visualizzazione della console Google Cloud dei passaggi di Cloud Build

Inizializzazione del workspace

Questa fase corrisponde al passaggio di build ubuntu. Inizializza il workspace di build, assicurandosi che le autorizzazioni dei file corrette siano impostate per le directory utilizzate dai passaggi di build successivi.

Preparer

Questa fase è responsabile della gestione della logica pre-build. Legge, sanifica e scrive le variabili di ambiente definite dall'utente. Inoltre, annulla il riferimento e blocca tutti i secret specificati nel file apphosting.yaml.

Pre-buildpack

Questo passaggio prepara l'ambiente per il ciclo di vita di Cloud Native Buildpacks. Ciò comporta l'esecuzione di uno shim che traduce le configurazioni e le variabili di ambiente preparate nella fase precedente nel formato previsto dagli strumenti CNB.

Build

Questo è il cuore del processo di compilazione, responsabile della generazione di un'immagine container eseguibile e di un file bundle.yaml che definisce la configurazione di compilazione. Utilizza Cloud Native Buildpacks e il file binario del creatore del ciclo di vita per pacchettizzare l' applicazione in modo efficiente. Ulteriori informazioni sul file bundle.yaml sono disponibili su GitHub.

I buildpack sono responsabili della trasformazione del codice sorgente dell'applicazione in immagini container pronte per la produzione. Firebase App Hosting concatena diversi buildpack per completare il processo di compilazione:

  1. Runtime Buildpack: garantisce che tutti i componenti necessari per l'esecuzione di un'applicazione Node.js di base Node.js siano inclusi e che le dipendenze siano installate.
  2. Monorepo Buildpack: configura i buildpack successivi per gestire diversi scenari monorepo.

  3. Framework Buildpack: installa l'adattatore del framework corretto (come Angular o Next.js) e prepara i buildpack successivi.

    Gli adattatori del framework sono responsabili dell'esecuzione del comando di build di produzione e del mapping di tutti i valori di configurazione specifici del framework pertinenti a un formato standard leggibile da App Hosting.

  4. Package Manager Buildpack: esegue l'installazione delle dipendenze e crea l'app utilizzando npm, yarn o pnpm.

  5. Output Bundle Buildpack: definisce il comando di esecuzione e prepara il pacchetto di output per l'esecuzione.

Publisher

Questa fase finale pacchettizza tutte le informazioni estratte dal codice sorgente dell'applicazione , oltre all'immagine container di build, e le invia al App Hosting backend. Il backend App Hosting utilizza queste informazioni per configurare Cloud Run con le configurazioni appropriate.

Policy di pulizia della build

Firebase App Hosting applica una policy di conservazione e pulizia automatica delle build. In base a questa policy, App Hosting conserva le build riuscite e le revisioni associate Cloud Run degli ultimi 14 giorni. Inoltre, per assicurarti di avere sempre una build a cui eseguire il rollback, App Hosting conserva le 5 build e i rollout riusciti più recenti, indipendentemente dalla loro età.

App Hosting non eliminerà né rimuoverà mai una build attualmente nella suddivisione del traffico attiva o associata a un rollout in corso.

Quando le build precedenti superano questi limiti di conservazione, il loro stato interno viene aggiornato a EXPIRED. Non puoi eseguire un rollback immediato su una build EXPIRED e l'opzione per eseguire il rollback a queste build verrà rimossa dalla Firebase console. Dovrai invece creare una nuova build che abbia come target la stessa origine (un commit Git, un container in Artifact Registry o un bucket Google Cloud Storage) ed eseguirne il rollout.

Un modo per conservare le risorse di build è controllare la frequenza con cui attivi i rollout automatici. Consulta Gestire i rollout automatici.

Scopri di più

L'intero App Hosting processo di compilazione è open source.