Para la configuración avanzada, como las variables de entorno o los ajustes del entorno de ejecución, como los límites de simultaneidad, CPU y memoria, deberás crear y editar el archivo apphosting.yaml
en el directorio raíz de la app. Este archivo también admite referencias a secretos administrados con Cloud Secret Manager, lo que hace que sea seguro registrarse en el control de código fuente.
Así es como se vería un archivo apphosting.yaml
típico, con la configuración para
el servicio de Cloud Run del backend, algunas variables de entorno y algunas
referencias a los secretos que administra 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 de configuración.
Establece la configuración del servicio de Cloud Run
Con la configuración de apphosting.yaml
, puedes establecer cómo se aprovisiona tu servicio de Cloud Run. La configuración disponible para el
servicio de 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 administrado por cuota)minInstances
: la cantidad de contenedores que se mantendrán siempre activos (el valor predeterminado es 0).concurrency
: La cantidad máxima de solicitudes que puede recibir cada instancia de entrega (el valor predeterminado es 80).
Ten en cuenta la importante relación entre cpu
y memoryMiB
; la memoria se puede establecer en cualquier valor entero entre 128 y 32,768, pero aumentar el límite de memoria puede requerir mayores límites de CPU:
- 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 configuras un valor
menor que 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 una configuración adicional para el proceso de compilación, como claves de API de terceros o una configuración ajustable. App Hosting ofrece la configuración
del entorno en apphosting.yaml
para almacenar y recuperar este
tipo de datos para tu proyecto.
env:
- variable: STORAGE_BUCKET
value: mybucket.appspot.com
En el caso de las apps de Next.js, los archivos dotenv que contienen variables de entorno también funcionarán con App Hosting. Recomendamos usar apphosting.yaml
para un control detallado de las variables de entorno con cualquier framework.
En apphosting.yaml
, puedes especificar qué procesos tienen acceso a tu variable de entorno mediante la propiedad availability
. Puedes restringir una variable de entorno para que esté disponible solo para el entorno de compilación o solo para el entorno de ejecución. De forma predeterminada, está disponible para ambos.
env:
- variable: STORAGE_BUCKET
value: mybucket.appspot.com
availability:
- BUILD
- RUNTIME
En el caso de las apps de Next.js, también puedes usar el prefijo NEXT_PUBLIC_
de la misma manera que
lo harías en tu archivo dotenv para 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. Algunas claves de variables de entorno están reservadas para uso interno. No uses ninguna de estas claves 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 secretos en apphosting.yaml
para evitar registrar información sensible en el control de la fuente.
Los parámetros de tipo secret
representan parámetros de cadena que tienen un valor
almacenado en Cloud Secret Manager.
En lugar de derivar el valor directamente, los parámetros secretos comprueban la existencia en Cloud Secret Manager y cargan los valores durante el lanzamiento.
- variable: API_KEY
secret: myApiKeySecret
Los Secrets de Cloud Secret Manager pueden tener varias versiones. De forma predeterminada, el valor de un parámetro de secreto disponible para el backend en vivo se fija a la última versión disponible del secreto en el momento en que se compiló el backend. Si tienes requisitos para el control de versiones y la administración del ciclo de vida de los parámetros, puedes fijar versiones específicas con Cloud Secret Manager. Por ejemplo, para fijar la versión 5, haz lo siguiente:
- variable: PINNED_API_KEY
secret: myApiKeySecret@5
Puedes crear secretos con el comando firebase apphosting:secrets:set
de la CLI,
y se te solicitará que agregues los permisos necesarios. Este flujo te da la opción de agregar automáticamente la referencia secreta a apphosting.yaml
.
Para usar el kit completo de funciones de Cloud Secret Manager, puedes usar la consola de Cloud Secret Manager. Si lo haces, deberás otorgarle permisos al 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 usar el SDK web de Firebase para ayudar a mantener
el estado de autenticación sincronizado entre el cliente y el servidor. Esto se puede
facilitar implementando FirebaseServerApp
con un service worker. El flujo de tareas básico es el siguiente:
- Implementa un service worker que agregue los encabezados correctos para tu app en las solicitudes al servidor.
- Obtén los encabezados de la solicitud en el servidor y conviértelos en un usuario de autenticación con
FirebaseServerApp
.