É comum ter vários ambientes implantados na mesma base de código, cada um com uma configuração ligeiramente diferente. Por exemplo, você pode atribuir menos CPU e RAM ao ambiente de preparo ou garantir que o ambiente de produção mantenha pelo menos uma instância ativa e pronta para atender solicitações. Também é possível especificar variáveis de ambiente e secrets diferentes, dependendo do ambiente e dos recursos que você quer usar.
Este guia descreve como implantar um ambiente de produção e preparo, cada um em um projeto separado do Firebase. Seguindo os mesmos princípios, você pode implantar em outros tipos de ambientes. Para saber mais sobre ambientes, confira a visão geral dos ambientes e as práticas recomendadas gerais para configurar projetos do Firebase.
Pré-requisitos
- O código do aplicativo já está armazenado no GitHub.
- Você já criou um projeto distinto para cada um dos seus ambientes, por exemplo,
my-production-firebase-projectemy-staging-firebase-project. Marque o projeto do Firebase de produção com o tipo de ambiente"produção". - Em cada projeto, você criou um back-end do App Hosting, com a ramificação ativa definida como a ramificação do GitHub que você quer implantar (como
main). Consulte Introdução ao App Hosting para mais informações.
Etapa 0: criar uma configuração padrão em apphosting.yaml
App Hosting oferece suporte a um arquivo de configuração chamado apphosting.yaml para gerenciar
as configurações de ambiente de execução (CPU, simultaneidade, limites de memória etc.) e variáveis de ambiente
do seu app. Ele também oferece suporte a referências a secrets gerenciados com o
Cloud Secret Manager, o que torna seguro fazer check-in no controle de origem. Para mais
informações, consulte Configurar um
back-end.
Para começar, crie um arquivo apphosting.yaml no diretório raiz do app.
Esse é o arquivo de configuração de fallback usado quando um arquivo de configuração específico do ambiente não é encontrado. Os valores armazenados em apphosting.yaml precisam ser padrões seguros para uso em todos os ambientes.
As próximas seções explicam como substituir valores padrão em apphosting.yaml para ambientes específicos. Esse fluxo de exemplo cria um ambiente de preparo.
Etapa 1: definir o nome do ambiente
Cada back-end App Hosting tem uma configuração de nome do ambiente. Esse campo é usado para mapear o back-end para um arquivo de configuração específico do ambiente e pode ser alterado a qualquer momento. Só é possível definir um nome de ambiente por back-end.
Para definir o nome do ambiente do back-end,
- No Console do Firebase, selecione o projeto de preparo (neste exemplo, my-staging-firebase-project).
- Selecione App Hosting na navegação à esquerda.
- Clique em Ver painel no back-end escolhido.
- Na guia Configurações, selecione Ambiente.
- Em Nome do ambiente,insira o nome do ambiente. Você pode nomear o ambiente como quiser. Neste exemplo, é preparo.
- Clique em Salvar.
Quando um lançamento do App Hosting é acionado para o back-end (no git
push ou manualmente pelo console), o App Hosting verifica um arquivo
apphosting.ENVIRONMENT_NAME.yaml antes de
voltar para apphosting.yaml.
Etapa 2: criar o arquivo apphosting.yaml específico do ambiente
Para a configuração específica do ambiente, crie um arquivo com o nome
apphosting.ENVIRONMENT_NAME.yaml para
especificar substituições específicas do ambiente. Esse arquivo tem o mesmo formato do
apphosting.yaml padrão e precisa estar localizado no
diretório raiz do app, ao lado de apphosting.yaml.
No tempo de build, App Hosting mescla esses dois arquivos, com prioridade para os
valores no arquivo YAML específico do ambiente em relação ao arquivo apphosting.yaml
de base.
Neste exemplo, você vai criar um arquivo chamado apphosting.staging.yaml no diretório raiz do app:
runConfig:
cpu: 1
memoryMiB: 512
concurrency: 5
env:
- variable: API_URL
value: api.staging.service.com
availability:
- BUILD
- variable: DATABASE_URL
secret: secretStagingDatabaseURL
Suponha que você já tenha um apphosting.yaml parecido com este:
runConfig:
cpu: 3
memoryMiB: 1024
maxInstances: 4
minInstances: 0
concurrency: 100
env:
- variable: API_URL
value: api.service.com
availability:
- BUILD
- RUNTIME
- variable: STORAGE_BUCKET
value: mybucket.firebasestorage.app
availability:
- RUNTIME
- variable: API_KEY
secret: secretIDforAPI
A saída mesclada final, que pode ser inspecionada nos registros do Cloud Build, seria assim:
runConfig:
cpu: 1
memoryMiB: 512
maxInstances: 4
minInstances: 0
concurrency: 5
env:
- variable: API_URL
value: api.staging.service.com
availability:
- BUILD
- variable: STORAGE_BUCKET
value: mybucket.firebasestorage.app
availability:
- RUNTIME
- variable: API_KEY
secret: secretIDforAPI
- variable: DATABASE_URL
secret: secretStagingDatabaseURL
Observe que determinados valores runConfig, como a CPU, foram substituídos, assim como todas as variáveis de ambiente sobrepostas.
Etapa 3: implantar a base de código
Quando terminar de editar o arquivo apphosting.ENVIRONMENT_NAME.yaml específico do ambiente, envie o arquivo para o GitHub:
$ git add apphosting.<ENVIRONMENT_NAME>.yaml
$ git commit -m "Added environment specific yaml file"
$ git push
Todos os back-ends marcados com esse nome de ambiente vão usar os valores de substituição específicos especificados no arquivo YAML correspondente e vão voltar para apphosting.yaml quando um valor não for encontrado. Para back-ends sem um nome de ambiente associado, você pode continuar usando apphosting.yaml.
Próximas etapas
- Aprofunde-se: siga um codelab do Firebase que integra um app hospedado com o Firebase Authentication e os recursos de IA do Google: Next.js | Angular
- Conecte um domínio personalizado.
- Configure o back-end.
- Monitore implantações, uso do site e registros.