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

É comum ter vários ambientes implantados na mesma base de código, cada com uma configuração um pouco diferente. Por exemplo, talvez você queira atribuir ou menos CPU e RAM para o ambiente de preparação ou seu ambiente de produção mantém pelo menos uma instância ativa e pronta para veiculação solicitações. Você também pode especificar diferentes variáveis de ambiente e secrets, dependendo do ambiente e dos recursos que você quer usar.

Este guia descreve como implantar um ambiente de produção e preparo, cada um para um projeto separado do Firebase. Seguindo os mesmos princípios, é possível implantar em outros tipos diferentes de ambientes. Para saber mais sobre ambientes, consulte a Visão geral ambientes e Geral práticas recomendadas para configurar o Firebase projetos.

Pré-requisitos

  • O código do aplicativo já está armazenado no GitHub.
  • Você já criou um projeto diferente para cada um ambientes, por exemplo, my-production-firebase-project e my-staging-firebase-project. Adicione uma tag ao Firebase de produção projeto com o rótulo "production" meio ambiente tipo.
  • Em cada projeto, você criou um back-end App Hosting, com os definida para a ramificação do GitHub que você quer implantar (como main). Consulte Comece a usar o App Hosting para saber mais informações imprecisas ou inadequadas.
.

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

App Hosting oferece suporte ao arquivo de configuração apphosting.yaml para gerenciar configurações de ambiente de execução (CPU, simultaneidade, limites de memória etc.) e o ambiente variáveis para seu app. Ele também aceita referências a secrets gerenciados com Com o Cloud Secret Manager, é seguro verificar o 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 seu app. Esse é o arquivo de configuração de substituição usado quando um arquivo de configuração específico do ambiente não foi 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 os valores padrão no apphosting.yaml para ambientes específicos. Este fluxo de exemplo cria um ambiente de preparação.

Etapa 1: definir o nome do ambiente

Cada back-end App Hosting tem uma configuração de nome do ambiente. Este campo é usada 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 teste (neste exemplo, my-staging-firebase-project).
  2. Selecione App Hosting na 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,insira o nome do seu ambiente. Você pode nomear o ambiente como quiser. Neste exemplo, é de preparo.
  6. Clique em Salvar.

Quando um lançamento de App Hosting é acionado para seu back-end (seja no git por push ou manualmente pelo console), o App Hosting vai verificar se há apphosting.ENVIRONMENT_NAME.yaml arquivo antes de voltando 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 e especificar substituições específicas do ambiente. Esse arquivo tem o mesmo formato que o apphosting.yaml padrão e precisa estar localizado em diretório raiz do app junto com apphosting.yaml.

No tempo de build, App Hosting mescla esses dois arquivos, com a prioridade dada a valores no arquivo YAML específico do ambiente na apphosting.yaml de base .

Neste exemplo, você criará um arquivo chamado apphosting.staging.yaml na diretório raiz do seu 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 com esta aparência:

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.appspot.com
    availability:
      -   RUNTIME

  -   variable: API_KEY
    secret: secretIDforAPI

A saída final mesclada, 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.appspot.com
    availability:
      -   RUNTIME

  -   variable: API_KEY
    secret: secretIDforAPI

  -   variable: DATABASE_URL
    secret: secretStagingDatabaseURL

Alguns valores de runConfig, como CPU, também foram substituídos como 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 para o GitHub:

$ git add apphosting.<ENVIRONMENT_NAME>.yaml
$ git commit -m "Added environment specific yaml file"
$ git push

Os back-ends marcados com esse nome de ambiente usarão a substituição específica especificados em seu arquivo YAML correspondente e voltar para apphosting.yaml quando um valor não é encontrado. Para back-ends sem uma conexão nome do ambiente, continue usando apphosting.yaml.

Próximas etapas