O processo de build do App Hosting

O Firebase App Hosting usa o Cloud Build para transformar o código-fonte do aplicativo em um formato em contêineres adequado para implantação no Cloud Run.

O processo de build opera nas seguintes etapas principais:

  1. ubuntu: inicialização do espaço de trabalho.

  2. preparer: coleta o código-fonte e a configuração do aplicativo.

  3. pre-buildpack: prepara o ambiente do buildpack.

  4. build: instala dependências e cria o aplicativo.

  5. publisher: finaliza o contêiner Cloud Run de produção.

Essas cinco etapas correspondem diretamente às etapas de build mostradas no Cloud Build no console do Google Cloud:

Captura de tela de uma visualização do console do Google Cloud das etapas do Cloud Build

Inicialização do espaço de trabalho

Essa etapa corresponde à etapa de build do Ubuntu. Ele inicializa o espaço de trabalho de build, garantindo que as permissões de arquivo corretas sejam definidas para os diretórios usados nas etapas de build subsequentes.

Preparador

Essa etapa é responsável por processar a lógica de pré-build. Ele lê, higieniza e grava variáveis de ambiente definidas pelo usuário. Ele também desreferencia e fixa todos os secrets especificados no arquivo apphosting.yaml.

Pré-buildpack

Esta etapa prepara o ambiente para o ciclo de vida dos Cloud Native Buildpacks. Isso envolve a execução de um shim que traduz as configurações e variáveis de ambiente preparadas na etapa anterior para o formato esperado pelas ferramentas do CNB.

Criar

Essa é a parte principal do processo de build, responsável por gerar uma imagem de contêiner executável e um arquivo bundle.yaml que define a configuração do build. Ele usa os buildpacks nativos do Cloud e o binário criador de ciclo de vida para empacotar o aplicativo de maneira eficiente. Para mais informações sobre o arquivo bundle.yaml, acesse o GitHub.

Os buildpacks são responsáveis por transformar o código-fonte do aplicativo em imagens de contêiner prontas para produção. O Firebase App Hosting encadeia vários buildpacks para concluir o processo de build:

  1. Buildpack de ambiente de execução: garante que todos os componentes necessários para executar um aplicativo básico do Node.js estejam incluídos e que as dependências sejam instaladas.
  2. Buildpack do monorepo: configura buildpacks subsequentes para processar diferentes cenários de monorepo.

  3. Buildpack do framework: instala o adaptador de framework correto (como Angular ou Next.js) e prepara os buildpacks subsequentes.

    Os adaptadores de framework são responsáveis por executar o comando de build de produção e mapear todos os valores de configuração relevantes específicos do framework para um formato padrão legível pelo App Hosting.

  4. Buildpack do gerenciador de pacotes: executa a instalação de dependências e cria o app usando npm, yarn ou pnpm.

  5. Buildpack do pacote de saída: define o comando de execução e prepara o pacote de saída para execução.

Editor

Essa etapa final empacota todas as informações extraídas do código-fonte do aplicativo, além da imagem do contêiner de build, e as envia para o back-end App Hosting. O back-end App Hosting usa essas informações para configurar o Cloud Run com as configurações adequadas.

Criar política de limpeza

Firebase App Hosting impõe uma política automatizada de retenção e limpeza de builds. De acordo com essa política, o App Hosting retém os builds bem-sucedidos e as revisões Cloud Run associadas dos últimos 14 dias. Além disso, para garantir que você sempre tenha um build para reverter, o App Hosting retém os cinco builds e lançamentos bem-sucedidos mais recentes, independentemente da idade deles.

O App Hosting nunca exclui ou remove um build que está na sua divisão de tráfego ativa ou associado a um lançamento em andamento.

Quando builds mais antigos excedem esses limites de retenção, o status interno deles é atualizado para EXPIRED. Não é possível fazer um rollback instantâneo em um build EXPIRED, e a opção de fazer rollback para esses builds será removida do console Firebase. Em vez disso, é necessário criar um novo build direcionado à mesma origem (um commit do Git, um contêiner em Artifact Registry ou um bucket Google Cloud Storage) e fazer o lançamento.

Uma maneira de conservar recursos de build é controlar a frequência com que você aciona implantações automáticas. Consulte gerenciar lançamentos automáticos.

Saiba mais

Todo o processo de build do App Hosting é de código aberto.