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 build 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 siano impostate le autorizzazioni file corrette 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 build, responsabile della generazione di un'immagine container eseguibile e di un file bundle.yaml che definisce la configurazione della build. Utilizza Cloud Native Buildpacks e il file binario 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 build:

  1. Runtime Buildpack: garantisce che siano inclusi tutti i componenti necessari per l'esecuzione di un'applicazione Node.js di base 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

In questa fase finale vengono pacchettizzate tutte le informazioni estratte dal codice sorgente dell'applicazione , oltre all'immagine container di build, e vengono inviate 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 presente 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 build è open source.