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 configuração de um build para veicular tráfego ativamente. Quando acionado automaticamente por um commit do Git, App Hosting primeiro cria um build usando a 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 a 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 o 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) que se adequam 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 específicos de suporte.
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 que você confira o status do lançamento no GitHub e depure 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 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:
- Melhora a performance e reduz a latência, aproximando geograficamente os dados 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)
A 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.