Implantar vários ambientes usando uma base de código

É comum ter vários ambientes implantados na mesma base de código, cada um com uma configuração um pouco diferente. Por exemplo, talvez você queira 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. Você também pode especificar variáveis de ambiente e segredos diferentes, dependendo do ambiente e dos recursos que você quer usar.

Este guia descreve como implantar um ambiente de produção e de preparação, cada um em um projeto do Firebase separado. Seguindo os mesmos princípios, é possível implantar em outros tipos de ambientes. Para saber mais sobre ambientes, consulte 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 ambientes, por exemplo, my-production-firebase-project e my-staging-firebase-project. Marque seu projeto do Firebase de produção com o tipo de ambiente"produção".
  • Em cada projeto, você criou um back-end App Hosting, com a ramificação ativa definida para a ramificação do GitHub que você quer implantar (como main). Consulte Começar a usar o App Hosting para mais informações.

Etapa 0: criar uma configuração padrão no apphosting.yaml

O App Hosting oferece suporte a um arquivo de configuração chamado apphosting.yaml para gerenciar configurações de execução (CPU, simultaneidade, limites de memória etc.) e variáveis de ambiente para o app. Ele também oferece suporte a referências a segredos gerenciados com o Cloud Secret Manager, tornando o processo de verificação no controle de origem seguro. 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 alternativo 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 todos os ambientes.

As próximas seções explicam como substituir valores padrão em apphosting.yaml para ambientes específicos. Este 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 seu 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,

  1. No console do Firebase, selecione seu projeto de preparo (neste exemplo, my-staging-firebase-project).
  2. Selecione App Hosting no menu de navegação à esquerda.
  3. Clique em Ver painel no back-end escolhido.
  4. Na guia Configurações, selecione Implantação.
  5. Em Nome do ambiente,digite o nome do ambiente. Você pode nomear o ambiente como quiser. Neste exemplo, é estágio.
  6. Clique em Salvar.

Quando um lançamento de App Hosting é acionado para seu back-end (no push do git ou manualmente pelo console), o App Hosting verifica um arquivo apphosting.ENVIRONMENT_NAME.yaml antes de retornar ao 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 com apphosting.yaml.

No momento da criação, o App Hosting mescla esses dois arquivos, com prioridade dada aos valores no arquivo YAML específico do ambiente em relação ao arquivo apphosting.yaml 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, fica 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

Alguns valores de runConfig, como CPU, foram substituídos, assim como qualquer variável de ambiente sobreposta.

Etapa 3: implantar a base de código

Quando terminar de editar o arquivo apphosting.ENVIRONMENT_NAME.yaml específico do ambiente, envie-o 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 usarão os valores de substituição específicos que você especificou no arquivo YAML correspondente e retornarão a apphosting.yaml quando um valor não for encontrado. Para back-ends sem um nome de ambiente associado, continue usando o apphosting.yaml.

Próximas etapas