App Hosting processa uma série complexa de tarefas em segundo plano para simplificar a implantação do app. Esta página descreve as principais partes desse fluxo de tarefas, fornecendo informações sobre os pontos em que você pode personalizar o fluxo de acordo com as necessidades do app.
Principais termos e definições
Para entender os detalhes do fluxo App Hosting, é útil definir alguns termos de forma muito específica. Confira os principais termos fundamentais:
- Back-end: a coleção de recursos gerenciados que App Hosting cria para criar e executar seu app da Web.
- Build:uma revisão específica do app, normalmente vinculada a um commit do Git. O processo de criação de um build tem vários subprocessos, principalmente a criação do app no Cloud Build, e a implantação de uma revisão (inicialmente veiculando 0% do tráfego até ser lançado) no Cloud Run.
- Lançamento: o processo de definir um build para veicular tráfego ativamente. Quando acionado automaticamente por um commit do Git, App Hosting primeiro cria um build usando sua ramificação ativa e, em seguida, cria um lançamento para direcionar o trânsito em tempo real a ele.
- Ramificação ativa: a ramificação do seu repositório do GitHub que é implantada no seu URL ativo. Geralmente, é a ramificação em que as ramificações de recursos ou de desenvolvimento são mescladas.
Arquitetura do Google Cloud e App Hosting
App Hosting orquestra um conjunto de produtos do Google Cloud para que você possa implantar, veicular e monitorar seu app da Web. Os apps são criados com Cloud Build, veiculados no Cloud Run, e armazenados em cache no Cloud CDN. Serviços integrados, como o Cloud Secret Manager, protegem suas chaves de API.
- Quando um commit é enviado para sua ramificação ativa, o Developer Connect do Google Cloud envia um evento para Firebase App Hosting.
- Em resposta a esse evento, Firebase App Hosting cria um novo build para
o back-end conectado ao repositório.
- Primeiro, Firebase App Hosting cria um novo build Cloud Build para seu commit. Nesse job, os buildpacks do Google Cloud determinam qual framework está sendo usado no aplicativo para criar um contêiner e uma configuração (incluindo variáveis de ambiente, secrets, instâncias mínimas ou máximas, memória de simultaneidade, CPU e configuração de VPC) adequados ao aplicativo. Consulte o App Hosting processo de build para mais informações.
- Quando o job Cloud Build é concluído, o contêiner é armazenado em um repositório Artifact Registry dedicado a Firebase App Hosting. Firebase App Hosting em seguida, adiciona uma nova revisão Cloud Run a um serviço Cloud Run usando a imagem e a configuração.
- Depois que a revisão do Cloud Run é concluída e verificada como íntegra, Firebase App Hosting modifica a configuração de tráfego para direcionar todas as novas solicitações à nova revisão do Cloud Run. Nesse ponto, o lançamento está concluído.
- Quando uma solicitação é enviada a um site hospedado no Firebase App Hosting, a solicitação é veiculada pelo balanceador de carga do Google Cloud com o Cloud CDN ativado. As solicitações não armazenadas em cache são enviadas ao seu serviço Cloud Run. Consulte Conteúdo do app em cache para orientações sobre como otimizar a performance com o Cloud CDN.
Integração de framework
App Hosting oferece suporte pré-configurado de build e implantação para apps da Web desenvolvidos nestes frameworks:
- Next.js 13.5.x e mais recentes
- Angular 18.2.x e mais recentes
Consulte as programações de suporte para detalhes sobre versões e níveis de suporte específicos.
Além do Next.js e do Angular, App Hosting também oferece suporte a qualquer web framework que possa fornecer uma saída de build que corresponda à nossa output bundle specification. Consulte Frameworks e ferramentas para App Hosting para mais informações sobre frameworks, adaptadores de framework e ferramentas relacionadas com suporte do App Hosting.
Como funciona a integração do repositório App Hosting
A conexão importante entre o repositório do GitHub e o App Hosting back-end é processada pelo Developer Connect, a plataforma de conectividade do Google Cloud para ferramentas externas de DevOps. Ao configurar essa conexão (normalmente durante a criação de um back-end App Hosting), o fluxo de trabalho da interface do Developer Connect orienta você na instalação do app do GitHub do Firebase. As principais etapas desse processo são:
- Você concede ao Developer Connect o papel de administrador do Secret Manager. Isso permite que o sistema armazene credenciais com segurança como "secrets" no Cloud Secret Manager.
- Você autoriza o app do GitHub do Firebase a acessar seu repositório do GitHub. Talvez você precise de outras permissões do GitHub para acessar o repositório correto.
- O Developer Connect armazena um token de autorização dedicado do GitHub no repositório do Secret Manager do projeto. Não modifique nem exclua esse token.
Além disso, App Hosting se integra à API de verificações do GitHub para fornecer uma verificação de lançamentos. Essa verificação permite visualizar o status do lançamento no GitHub e depurar o processo de implantação em caso de erros.
Integração com o Firebase e outros serviços do Google
App Hosting configura os ambientes de build e de execução para que você possa inicializar o SDK Admin do Firebase com as Application Default Credentials do Google. Dessa forma, o back-end pode se comunicar com outros produtos do Firebase durante o build e a execução. Consulte Integrar SDKs do Firebase no seu app da Web para mais informações sobre como inicializar o app e outros tópicos relacionados ao SDK do Firebase.
App Hosting locais
App Hosting cria os recursos de back-end em um local específico, chamado sua região principal. Embora App Hosting se integre a um CDN global para entrega rápida, o conteúdo não armazenado em cache é veiculado na região principal do app. Essa flexibilidade no local do app da Web tem vantagens importantes:
- Melhoria da performance e redução da latência, aproximando os dados geograficamente dos usuários.
- Uma falha catastrófica do App Hosting em uma região não afetaria apps da Web implantados em outras regiões.
É possível escolher qualquer uma dessas regiões ao criar um App Hosting back-end no Firebase console ou na Firebase CLI:
us-central1(Iowa)us-east4(N. Virginia)us-east5(Columbus)asia-east1(Taiwan)asia-southeast1(Singapura)europe-west4(Países Baixos)
Conta de serviço de back-end App Hosting
Durante o build e no momento da execução, o back-end do App Hosting é autenticado com outros serviços do Google usando uma conta de serviço. Uma conta de serviço padrão para essas finalidades é criada na primeira vez que você ativa App Hosting em um projeto do Firebase:
firebase-app-hosting-compute@PROJECT ID.iam.gserviceaccount.com
Essa conta de serviço é aplicada a todos os back-ends por padrão e tem um conjunto mínimo de permissões para permitir que você crie, execute e monitore o app. Ela também tem permissão para autenticar o SDK Admin com as Application Default Credentials, para realizar operações como o carregamento de dados de Cloud Firestore. Consulte Papéis do FirebaseApp Hosting.
Se o app precisar interagir com outros serviços do Google durante o build ou em um back-end em execução, você poderá personalizar a conta de serviço padrão adicionando papéis. Por exemplo, se o app exigir permissões para a Vertex AI, talvez seja necessário adicionar roles/aiplatform.user ou algum papel relacionado.