Configura y administra los backends de App Hosting

App Hosting se diseñó para facilitar el uso y reducir el mantenimiento, con parámetros de configuración predeterminados optimizados para la mayoría de los casos de uso. Al mismo tiempo, App Hosting proporciona herramientas para que administres y configures backends según tus necesidades específicas. En esta guía, se describen esos procesos y herramientas.

Configurar un backend

Para la configuración avanzada, como variables de entorno o parámetros del entorno de ejecución como límites de simultaneidad, CPU y memoria, deberás crear y editar el apphosting.yaml en el directorio raíz de tu app. Este archivo también admite referencias a Secrets administrados con Cloud Secret Manager, lo que hace que sea seguro acceder al control del código fuente.

Así es como podría verse un archivo apphosting.yaml típico, con la configuración para el servicio Cloud Run del backend, algunas variables de entorno y otras referencias a Secrets administrados por 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

En el resto de esta guía, se proporciona más información y contexto sobre estos ejemplos configuración.

Establece la configuración del servicio de Cloud Run

Con la configuración de apphosting.yaml, puedes establecer cómo se El servicio de Cloud Run es o con el que se aprovisionen. Los parámetros de configuración disponibles El servicio Cloud Run se proporciona en el objeto runConfig:

  • cpu: Cantidad de CPU usadas para cada instancia de entrega (el valor predeterminado es 0).
  • memoryMiB: Cantidad de memoria asignada a cada instancia de entrega en MiB (el valor predeterminado es 512)
  • maxInstances: Cantidad máxima de contenedores que se ejecutarán a la vez (valor predeterminado de 100 y se administra mediante cuota)
  • minInstances: la cantidad de contenedores que se mantendrán siempre activos (el valor predeterminado es 0).
  • concurrency: Cantidad máxima de solicitudes que puede cada instancia de entrega recibir (el valor predeterminado es 80).

Ten en cuenta la relación importante entre cpu y memoryMiB. se puede establecer la memoria a cualquier valor entero entre 128 y 32,768, pero aumentar el límite de memoria requieren límites de CPU cada vez mayores:

  • Más de 4 GiB requiere al menos 2 CPU
  • Más de 8 GiB requiere al menos 4 CPU
  • Más de 16 GiB requiere al menos 6 CPU
  • Más de 24 GiB requiere al menos 8 CPU

De manera similar, el valor de cpu afecta la configuración de simultaneidad. Si estableces un valor menos de 1 CPU, debes establecer la simultaneidad en 1, y la CPU solo se asignará durante el procesamiento de la solicitud.

Cómo configurar el entorno de compilación

A veces necesitarás configuración adicional para tu proceso de compilación, como claves de API de terceros o parámetros de configuración ajustables. Entorno de ofertas de App Hosting de Terraform en apphosting.yaml para almacenar y recuperar este tipos de datos para tu proyecto.

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

En las apps de Next.js, los archivos dotenv que contienen variables de entorno también trabajar con App Hosting Recomendamos usar apphosting.yaml para datos detallados el control de variables de entorno con cualquier framework.

En apphosting.yaml, puedes especificar qué procesos tienen acceso a tu variable de entorno con la propiedad availability. Puedes restringir un variable de entorno estén disponibles solo para el entorno de compilación o solo en el entorno de ejecución. De forma predeterminada, está disponible para ambos.

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

En las apps de Next.js, también puedes usar el prefijo NEXT_PUBLIC_ de la misma manera que en tu archivo dotenv para hacer que una variable sea accesible en el navegador.

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

Las claves de variables válidas están compuestas por caracteres de la A a la Z o guiones bajos. Algunos las claves de variable de entorno se reservan para uso interno. No uses ninguno de estos métodos en tus archivos de configuración:

  • Cualquier variable que comience con X_FIREBASE_
  • PORT
  • K_SERVICE
  • K_REVISION
  • K_CONFIGURATION

Almacena parámetros de secretos y accede a ellos

La información sensible, como las claves de API, se debe almacenar como Secrets. Puedes hacer referencia a los Secrets en apphosting.yaml para evitar verificar información sensible al control de origen.

Los parámetros de tipo secret representan parámetros de cadenas que tienen un valor almacenados en Cloud Secret Manager. En lugar de Derivan el valor directamente, los parámetros secretos comprueban la existencia en Cloud Secret Manager y cargarás los valores durante el lanzamiento.

  -   variable: API_KEY
      secret: myApiKeySecret

Los Secrets en Cloud Secret Manager pueden tener varias versiones. De forma predeterminada, el valor de un parámetro secreto disponible para tu backend en vivo se fija al a la última versión disponible del secreto en el momento en que se compiló el backend. Si requisitos para el control de versiones y la administración del ciclo de vida de los parámetros, y fijar versiones específicas con Cloud Secret Manager. Por ejemplo, para fijar versión 5:

  - variable: PINNED_API_KEY
    secret: myApiKeySecret@5

Puedes crear Secrets con el comando firebase apphosting:secrets:set de la CLI. y se te pedirá que agregues los permisos necesarios. Este flujo te da la Opción para agregar automáticamente la referencia del Secret a apphosting.yaml.

Para usar el kit completo de funciones de Cloud Secret Manager, puedes en la consola de Cloud Secret Manager. Si lo haces, tendrás que otorgar permisos para tu backend de App Hosting con el comando firebase apphosting:secrets:grantaccess de la CLI.

Sincroniza el estado de Firebase Auth

Las apps que usan Firebase Auth deben considerar el uso del SDK web de Firebase para ayudar a estado de autenticación sincronizado entre el cliente y el servidor. Puede ser que se da si se implementa FirebaseServerApp con un service worker. Aspectos básicos de la tarea es:

  1. Implementa un service worker que agregue los encabezados correctos para tu aplicación en las solicitudes al servidor.
  2. Obtener los encabezados de la solicitud en el servidor y convertirlos en una autenticación usuario con FirebaseServerApp.

Administrar backends

Los comandos para la administración básica de backends de App Hosting se que se proporciona en la CLI de Firebase. Algunos también están disponibles en la consola de Firebase. En esta sección, describirás algunas de las tareas de gestión más comunes, incluidas la creación y y borrar backends.

Crear un backend

Un backend App Hosting es la colección de recursos administrados que App Hosting crea para compilar y ejecutar tu app web. Puedes crear y enumerar Backends App Hosting con la consola de Firebase CLI de Firebase.

Firebase console: En el menú Compilación, selecciona App Hosting y, luego, Comienza ahora.

CLI: (versión 3.9 o posterior). Para crear un backend, ejecuta el siguiente comando: desde la raíz del directorio del proyecto local project ID como argumento (para la vista previa, solo se admite la región us-central1):

firebase apphosting:backends:create --project PROJECT_ID --location us-central1

Tanto en la consola como en la CLI, sigue las indicaciones y asigna un nombre a tu backend, para establece un Conexión con GitHub, y establece estos parámetros de configuración básicos de implementación:

  • Configura el directorio raíz de la app (el valor predeterminado es /).

    Por lo general, aquí es donde se encuentra el archivo package.json.

  • Configura la rama activa

    Esta es la rama de tu repositorio de GitHub que se implementa en tu URL publicada. A menudo, es la rama en la que las ramas de atributos o los modelos se fusionan las ramas.

  • Aceptar o rechazar lanzamientos automáticos

    Los lanzamientos automáticos están habilitados de forma predeterminada. Cuando finaliza la creación del backend, Puedes elegir que tu app se implemente en App Hosting de inmediato.

Borrar un backend

Para quitar un backend por completo, primero usa la CLI de Firebase y, luego, de forma manual quite los recursos relacionados, con especial cuidado de no borrar los recursos que podrían usar otros backends u otros aspectos de tu proyecto de Firebase.

  1. Ejecuta el siguiente comando para borrar el backend App Hosting. Esto inhabilita todos los dominios para tu backend y borra los dominios Servicio Cloud Run:

    firebase apphosting:backends:delete BACKEND_ID --project PROJECT_ID --location us-central1

  2. (Opcional) En la La pestaña de la consola de Google Cloud para Artifact Registry borrar la imagen de tu backend en “firebaseapphosting-images”.

  3. En Cloud Secret Manager, borrar todos los Secrets que tengan “apphosting” en el nombre del Secret, lo que significa asegúrate de que otros backends no usen estos Secrets otros aspectos de tu proyecto de Firebase.