Esta página foi traduzida pela API Cloud Translation.

Configurar a hospedagem de apps

Para configurações avançadas, como variáveis de ambiente ou configurações de ambiente de execução, como limites de simultaneidade, CPU e memória, você precisará criar e editar o arquivo apphosting.yaml no diretório raiz do app. Esse arquivo também é compatível com referências a secrets gerenciados com o Cloud Secret Manager, o que torna seguro verificar o controle de origem.

Veja como pode ser um arquivo apphosting.yaml típico, com configurações para o serviço de back-end do Cloud Run, algumas variáveis de ambiente e algumas referências a secrets gerenciados pelo Cloud Secret Manager:

# Settings for Cloud Run
runConfig:
  minInstances: 2
  maxInstances: 100
  concurrency: 100
  cpu: 2
  memoryMiB: 1024

# Environment variables and secrets
env:
  - variable: STORAGE_BUCKET
    value: mybucket.appspot.com
    availability:
      - BUILD
      - RUNTIME

  - variable: API_KEY
    secret: myApiKeySecret

    # Same as API_KEY above but with a pinned version.
  - variable: PINNED_API_KEY
    secret: myApiKeySecret@5

    # Same as API_KEY above but with the long form secret reference as defined by Cloud Secret Manager.
  - variable: VERBOSE_API_KEY
    secret: projects/test-project/secrets/secretID

    # Same as API_KEY above but with the long form secret reference with pinned version.
  - variable: PINNED_VERBOSE_API_KEY
    secret: projects/test-project/secrets/secretID/versions/5

O restante deste guia fornece mais informações e contexto para essas configurações de exemplo.

Definir as configurações do serviço do Cloud Run

Com as configurações apphosting.yaml, é possível configurar como o serviço do Cloud Run é provisionado. As configurações disponíveis para o serviço do Cloud Run são fornecidas no objeto runConfig:

cpu: número de CPUs usadas para cada instância de exibição (padrão 0).
memoryMiB: quantidade de memória alocada para cada instância de exibição em MiB (padrão 512)
maxInstances: número máximo de contêineres a serem executados por vez (padrão de 100 e gerenciado por cota)
minInstances: número de contêineres que devem ser sempre mantidos ativos (padrão 0).
concurrency: número máximo de solicitações que cada instância de exibição pode receber (o padrão é 80).

Observe a relação importante entre cpu e memoryMiB. A memória pode ser definida como qualquer valor inteiro entre 128 e 32.768, mas aumentar o limite de memória pode exigir aumentar os limites de CPU:

Mais de 4 GiB exigem pelo menos 2 CPUs
Mais de 8 GiB exigem pelo menos 4 CPUs
Mais de 16 GiB exigem pelo menos 6 CPUs
Mais de 24 GiB requerem pelo menos 8 CPUs

Da mesma forma, o valor de cpu afeta as configurações de simultaneidade. Se você definir um valor menor que uma CPU, precisará definir a simultaneidade como 1, e a CPU será alocada somente durante o processamento da solicitação.

Configurar o ambiente de build

Às vezes, você vai precisar de outras configurações para o processo de build, como chaves de API de terceiros ou configurações ajustáveis. O App Hosting oferece a configuração de ambiente em apphosting.yaml para armazenar e extrair esse tipo de dados para seu projeto.

env:
-   variable: STORAGE_BUCKET
    value: mybucket.appspot.com

Para apps Next.js, os arquivos dotenv que contêm variáveis de ambiente também funcionam com o App Hosting. Recomendamos o uso de apphosting.yaml para controle granular de variáveis de ambiente com qualquer framework.

Em apphosting.yaml, é possível especificar quais processos têm acesso à variável de ambiente usando a propriedade availability. É possível restringir uma variável de ambiente disponível apenas para o ambiente de build ou apenas para o ambiente de execução. Por padrão, ele está disponível para ambos.

env:
-   variable: STORAGE_BUCKET
    value: mybucket.appspot.com
    availability:
    -   BUILD
    -   RUNTIME

Para apps Next.js, você também pode usar o prefixo NEXT_PUBLIC_ da mesma forma que faria no arquivo dotenv para tornar uma variável acessível no navegador.

env:
-   variable: NEXT_PUBLIC_STORAGE_BUCKET
    value: mybucket.appspot.com
    availability:
    -   BUILD
    -   RUNTIME

As chaves de variáveis válidas são compostas por caracteres de A a Z ou sublinhados. Algumas chaves de variáveis de ambiente são reservadas para uso interno. Não use nenhuma destas chaves nos arquivos de configuração:

Qualquer variável que comece com X_FIREBASE_
PORT
K_SERVICE
K_REVISION
K_CONFIGURATION

Armazenar e acessar parâmetros do secret

Informações sensíveis, como chaves de API, precisam ser armazenadas como secrets. É possível referenciar secrets no apphosting.yaml para evitar a verificação de informações confidenciais no controle de origem.

Os parâmetros do tipo secret representam parâmetros de string que têm um valor armazenado no Cloud Secret Manager. Em vez de derivar o valor diretamente, os parâmetros do secret verificam a existência no Cloud Secret Manager e carregam os valores durante o lançamento.

  -   variable: API_KEY
      secret: myApiKeySecret

Os secrets no Cloud Secret Manager podem ter várias versões. Por padrão, o valor de um parâmetro do secret disponível para o back-end ativo é fixado na versão disponível mais recente do secret no momento da criação do back-end. Se você tiver requisitos para o controle de versões e o gerenciamento do ciclo de vida dos parâmetros, poderá fixar versões específicas com o Cloud Secret Manager. Por exemplo, para fixar na versão 5:

  - variable: PINNED_API_KEY
    secret: myApiKeySecret@5

É possível criar secrets com o comando da CLI firebase apphosting:secrets:set. Você será solicitado a adicionar as permissões necessárias. Esse fluxo oferece a opção de adicionar automaticamente a referência de secret a apphosting.yaml.

Para usar o pacote completo de funcionalidades do Cloud Secret Manager, use o console do Cloud Secret Manager. Se fizer isso, será necessário conceder permissões ao back-end do App Hosting com o comando firebase apphosting:secrets:grantaccess da CLI.

Sincronizar o estado do Firebase Auth

Os apps que usam o Firebase Auth devem considerar o uso do SDK da Web do Firebase para ajudar a manter o estado da autenticação sincronizado entre o cliente e o servidor. Para facilitar, implemente FirebaseServerApp com um service worker. O fluxo de tarefas básico é:

Implemente um service worker que adicione os cabeçalhos certos ao seu app nas solicitações ao servidor.
Receba os cabeçalhos da solicitação no servidor e converta-os em um usuário de autenticação com FirebaseServerApp.