O Firebase App Hosting usa o Cloud Build para transformar o código-fonte do aplicativo em um formato conteinerizado adequado para implantação no Cloud Run.
O processo de build funciona por meio das seguintes etapas principais:
ubuntu: inicialização do espaço de trabalho.
preparer: reúne o código-fonte e a configuração do aplicativo.
pre-buildpack: prepara o ambiente do buildpack.
build: instala dependências e cria o aplicativo.
publisher: finaliza o contêiner de produção Cloud Run.
Essas cinco etapas correspondem diretamente às etapas de build, conforme exibido em Cloud Build no console do Google Cloud:
Inicialização do espaço de trabalho
Essa etapa corresponde à etapa de build do Ubuntu. Ele inicializa o espaço de trabalho do build, garantindo que as permissões do arquivo corretas sejam definidas para os diretórios usados pelas etapas de build subsequentes.
Preparador
Essa etapa é responsável por processar a lógica de pré-compilação. Ele lê, limpa 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 Buildpacks nativos da nuvem. Isso envolve a execução de um shim que traduz as configurações e as variáveis de ambiente preparadas na etapa anterior para o formato esperado pelas ferramentas do CNB.
Criar
Esse é o núcleo do processo de build, responsável por gerar uma imagem do contêiner executável e um arquivo bundle.yaml que define a configuração do build.
Ele usa os Buildpacks nativos da nuvem
e o binário do criador de ciclo de vida
para empacotar o
aplicativo de maneira eficiente. Mais informações sobre o arquivo bundle.yaml podem ser encontradas
no 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:
- Buildpack de ambiente de execução: garante que todos os componentes necessários para executar um aplicativo básico do Node.js sejam incluídos e que as dependências sejam instaladas.
- Buildpack do Monorepo: configura os buildpacks subsequentes para lidar com diferentes cenários de monorepo.
Buildpack de 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 produzido e mapear todos os valores de configuração relevantes específicos do framework para um formato padrão legível por App Hosting.
Buildpack do gerenciador de pacotes: executa a instalação de dependências e cria o app usando npm, yarn ou pnpm.
Buildpack do pacote de saída: define o comando de execução e prepara o pacote de saída para execução.
Editor
Esse estágio 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 do App Hosting. O back-end do App Hosting usa essas informações para configurar o Cloud Run com as definições adequadas.
Política de limpeza de build
Firebase App Hosting aplica uma política automatizada de retenção e limpeza de builds. De acordo com essa política, o App Hosting retém as versões bem-sucedidas e as revisões do 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.
O App Hosting não vai excluir nem remover um build que esteja na divisão de tráfego ativa ou que esteja associado a um lançamento em andamento.
Quando as versões mais antigas excedem esses limites de retenção, o status interno delas é
atualizado para EXPIRED. Não é possível realizar uma reversão instantânea em um build do EXPIRED, e a opção de reverter para esses builds será removida do console do Firebase. Em vez disso, você precisará
criar um novo build que tenha como destino a mesma origem
(um commit do Git,
um contêiner no Artifact Registry ou um bucket do Google Cloud Storage) e lançá-lo.
Uma maneira de conservar os recursos de build é controlar a frequência com que você aciona as implementações automáticas. Consulte Gerenciar lançamentos automáticos.
Saiba mais
Todo o processo de build do App Hosting é de código aberto.
- O código do buildpack está no repositório de buildpacks do Google Cloud.
- O código dos adaptadores de framework está no repositório apphosting-adapters.
- Saiba mais sobre os buildpacks nativos da nuvem e o Cloud Build.