Archivo de configuración app.yaml

El archivo app.yaml define la configuración de tu entorno de ejecución, así como la configuración general de apps, redes y otros recursos.

No agregues app.yaml al archivo .gcloudignore. Es posible que app.yaml sea necesario para la implementación, y que lo agregues a .gcloudignore hará que la implementación falle.

Sintaxis

La sintaxis del archivo app.yaml tiene el formato YAML. El formato YAML admite comentarios, en los que se ignora cualquier línea que comience con el carácter de numeral (#), por ejemplo:

# This is a comment.

Los patrones de URL y ruta de acceso al archivo usan la sintaxis de expresión regular extendida POSIX y excluyen los elementos y las clases de intercalación. Se admiten referencias inversas a las coincidencias agrupadas (p. ej.: \1), al igual que estas extensiones de Perl: \w \W \s \S \d \D.

Configuración general

Un archivo app.yaml puede incluir estas opciones de configuración general. Ten en cuenta que algunas de ellas son obligatorias:

Nombre	Descripción
`build_env_variables`	Opcional. Si usas un entorno de ejecución que admite buildpacks, puedes definir variables de entorno de compilación en el archivo `app.yaml`. Para obtener más información, consulta Usa las variables de entorno de compilación.
`runtime`	Obligatorio. El nombre del entorno de ejecución que usa la app. Por ejemplo, para especificar el entorno de ejecución, usa lo siguiente:
`env: flex`	Obligatorio: Elige el entorno flexible.
`service: service_name`	Es obligatorio si se crea un servicio. Es opcional para el servicio predeterminado. Cada servicio y cada versión deben tener un nombre. Un nombre puede contener números, letras y guiones. En el entorno flexible, la longitud combinada de `VERSION-dot-SERVICE-dot-PROJECT_ID` (en la que `VERSION` es el nombre de tu versión, `SERVICE` es el nombre de tu servicio y `PROJECT_ID` es el ID del proyecto) no puede tener más de 63 caracteres y no puede empezar o terminar con un guion. Si implementas sin especificar un nombre de servicio, se crea una versión nueva del servicio predeterminado. Si implementas con un nombre de servicio que ya existe, se crea una versión nueva de ese servicio. Si implementas con un nombre de servicio nuevo que no existe, se crean un servicio y una versión nuevos. Recomendamos usar un nombre único para cada combinación de versión del servicio. Nota: Los servicios se denominaban anteriormente "módulos".
`service_account`	Opcional. El elemento `service_account` te permite especificar una cuenta de servicio administrada por el usuario como la identidad para la versión. La cuenta de servicio especificada se usará para acceder a otros servicios de Google Cloud y ejecutar tareas. La cuenta de servicio debe proporcionarse en el siguiente formato: service_account: [SERVICE_ACCOUNT_NAME]@[PROJECT_ID].iam.gserviceaccount.com
`skip_files`	Opcional. Con el elemento `skip_files`, se especifica qué archivos del directorio de la aplicación no se deben subir a App Engine. El valor es una expresión regular o una lista de expresiones regulares. Cualquier nombre de archivo que coincida con cualquier expresión regular se omite de la lista de archivos que se subirán cuando se cargue la aplicación. Por ejemplo, para saltar archivos cuyos nombres terminan en `.bak`, agrega una sección `skip_files` como la siguiente: skip_files: - ^.*\.bak$

Configuración de red

Puedes especificar la configuración de red en tu archivo de configuración app.yaml, por ejemplo:

network:
  name: NETWORK_NAME
  instance_ip_mode: INSTANCE_IP_MODE
  instance_tag: TAG_NAME
  subnetwork_name: SUBNETWORK_NAME
  session_affinity: true
  forwarded_ports:
    - PORT
    - HOST_PORT:CONTAINER_PORT
    - PORT/tcp
    - HOST_PORT:CONTAINER_PORT/udp

Puedes usar las siguientes opciones cuando realices la configuración de red:

Opción	Descripción
`name`	Cada instancia de VM en el entorno flexible se asigna a una red de Google Compute Engine cuando se crea. Usa esta configuración para especificar un nombre de red. Proporciona el nombre corto, no la ruta de acceso del recurso (por ejemplo, `default` en lugar de `https://www.googleapis.com/compute/v1/projects/my-project/global/networks/default`). Si no especificas un nombre de red, las instancias se asignan a la red predeterminada del proyecto (que tiene el nombre `default`). Si deseas especificar un nombre de subred, debes especificar un nombre de red.
`instance_ip_mode`	Opcional. Si quieres evitar que las instancias reciban una dirección IP externa efímera, configura `internal` y habilita el Acceso privado a Google. Si tu instancia se implementó antes sin esta configuración o se implementó con esto configurado como `external`, volver a establecerlo como `internal` quita las direcciones IP externas efímeras de las instancias. La configuración `internal` tiene limitaciones. La cantidad predeterminada es `external`.
`instance_tag`	Opcional. Se asigna una etiqueta con ese nombre a cada instancia del servicio cuando se crea. Las etiquetas pueden ser útiles en los comandos de `gcloud` para dirigir una acción a un grupo de instancias. Por ejemplo, consulta el uso de las marcas `--source-tags` y `--target-tags` en el comando compute firewalls-create. Si no se especifica, la instancia se etiqueta con `aef-INSTANCE_ID` cuando no se usa la VPC compartida. Si se usa una VPC compartida, la instancia se etiqueta con `aef-INSTANCE_ID and aef-instance.`.
`subnetwork_name`	Opcional. Puedes segmentar tu red y usar una subred personalizada. Asegúrate de que se especifique el `name` de la red. Proporciona el nombre corto, no la ruta de acceso al recurso (por ejemplo, `default` en lugar de `https://www.googleapis.com/compute/v1/projects/my-project/global/networks/default/subnetworks/default`). La subred debe estar en la misma región que la aplicación.
`session_affinity`	Opcional. Establécela en `true` para configurar App Engine con el objetivo de que enrute varias solicitudes secuenciales para un usuario determinado a la misma instancia de App Engine, como cuando se almacenan datos del usuario de manera local durante una sesión. La afinidad de sesión permite inspeccionar el valor de una cookie para identificar varias solicitudes del mismo usuario y, luego, dirige todas esas solicitudes a la misma instancia. Si la instancia se reinicia, está en mal estado, se sobrecarga o deja de estar disponible cuando el número de instancias se reduce, la afinidad de sesión se interrumpirá y las solicitudes adicionales se enrutarán a una instancia diferente. Ten en cuenta que la habilitación de la afinidad de sesión puede afectar tu configuración de balanceo de cargas. Este parámetro está inhabilitado de forma predeterminada.
`forwarded_ports`	Opcional. Puedes reenviar puertos desde tu instancia (`HOST_PORT`) hasta el contenedor de Docker (`CONTAINER_PORT`). `HOST_PORT` debe estar entre 1024 y 65535 y no puede entrar en conflicto con los siguientes puertos: 22, 8080, 8090, 8443, 10000, 10001, 10400-10500, 11211, 24231. `CONTAINER_PORT` debe ser un número entre 1 y 65535, y no puede entrar en conflicto con los siguientes puertos: 22, 10001, 10400-10500, 11211. Si solo especificas un `PORT`, App Engine supone que es el mismo puerto en el host y en el contenedor. De forma predeterminada, se reenvía el tráfico de TCP y UDP. El tráfico debe dirigirse directamente a la dirección IP de la instancia de destino, en lugar de a través del dominio appspot.com o tu dominio personalizado.

Configuración de red avanzada

Puedes segmentar tu red de Compute Engine en subredes. Esto te permite habilitar situaciones de VPN, como acceder a bases de datos dentro de tu red corporativa.

Si deseas habilitar subredes para tu aplicación de App Engine, haz lo siguiente:

Crea una red de subredes personalizada.
Agrega el nombre de la red y el nombre de la subred a tu archivo app.yaml, como se especificó antes.
Si deseas establecer una VPN simple basada en el enrutamiento estático, crea una puerta de enlace y un túnel para una red de subredes personalizada. De lo contrario, consulta cómo crear otros tipos de VPN.

Redirección de puertos

La redirección de puertos permite conexiones directas al contenedor de Docker en tus instancias. Este tráfico puede viajar sobre cualquier protocolo. La redirección de puertos está destinada a ayudar en situaciones en las que podrías necesitar adjuntar un depurador o un generador de perfiles. El tráfico debe dirigirse directamente a la dirección IP de la instancia de destino, en lugar de a través del dominio appspot.com o tu dominio personalizado.

De forma predeterminada, los firewalls de Google Cloud Platform no permiten el tráfico entrante desde el exterior de tu red. Una vez que hayas especificado la redirección de puertos en tu archivo app.yaml, debes agregar una regla de firewall que permita el tráfico desde los puertos que deseas abrir.

Puedes especificar una regla de firewall en la página Reglas de firewall de las Herramientas de redes en la consola de Google Cloud o mediante los comandos de gcloud.

Por ejemplo, si deseas reenviar el tráfico de TCP desde el puerto 2222, haz lo siguiente:

En la configuración de red de tu app.yaml, incluye lo siguiente:
```
network:
  forwarded_ports:
    - 2222/tcp
```
1. Si usas el entorno de ejecución de Python, cambia app.yaml para que incluya lo siguiente:
```
entrypoint: gunicorn -b :$PORT -b :2222 main:app
```
Especifica una regla de firewall en la consola de Google Cloud o usa gcloud compute firewall-rules create para permitir el tráfico desde cualquier fuente (0.0.0.0/0) y desde tcp:2222.

Configuración de recursos

Esta configuración controla los recursos de procesamiento. App Engine asigna un tipo de máquina en función de la cantidad de CPU y memoria que hayas especificado. Se garantiza que la máquina tenga al menos el nivel de recursos que hayas especificado, pero podría tener más.

Puedes especificar hasta ocho volúmenes de tmpfs en la configuración de recursos. Luego puedes habilitar las cargas de trabajo que requieren memoria compartida a través de tmpfs y puedes mejorar la E/S del sistema de archivos.

Por ejemplo:

resources:
  cpu: 2
  memory_gb: 2.3
  disk_size_gb: 10
  volumes:
  - name: ramdisk1
    volume_type: tmpfs
    size_gb: 0.5

Puedes usar las siguientes opciones cuando realices la configuración de recursos:

Opción	Descripción	Predeterminado
`cpu`	La cantidad de núcleos debe ser un número par entre 2 y 32, o un múltiplo de 4 entre 32 y 80.	1 núcleo
`memory_gb`	RAM en GB. La memoria solicitada para la aplicación, que no incluye los ~0.4 GB de memoria que se necesitan cuando algunos procesos se sobrecargan. Cada núcleo de CPU requiere una memoria total de entre 1.0 y 6.5 GB. Para calcular la memoria requerida, haz el siguiente cálculo: `memory_gb` = `cpu` * [1.0 - 6.5] - 0.4 Para el ejemplo anterior, en el que especificaste 2 núcleos, puedes solicitar entre 1.6 y 12.6 GB. El entorno de ejecución establece la cantidad total de memoria disponible para la aplicación como la variable de entorno `GAE_MEMORY_MB`.	0.6 GB
`disk_size_gb`	Tamaño en GB. El mínimo es de 10 GB y el máximo, de 10,240 GB.	13 GB
`name`	Obligatorio, si se usan volúmenes. Nombre del volumen. Los nombres deben ser únicos y tener entre 1 y 63 caracteres. Los caracteres pueden ser letras minúsculas, números o guiones. El primer carácter debe ser una letra y el último no puede ser un guion. El volumen se activa en el contenedor de la app como `/mnt/NAME`.
`volume_type`	Es obligatorio si se usan volúmenes. Debe ser `tmpfs`.
`size_gb`	Es obligatorio si se usan volúmenes. El tamaño del volumen, en GB. El mínimo es 0.001 GB y el máximo es la cantidad de memoria disponible en el contenedor de la aplicación y en el dispositivo subyacente. Google no agrega RAM adicional al sistema para satisfacer los requisitos del disco. La RAM asignada a los volúmenes tmpfs se restará de la memoria disponible para el contenedor de la aplicación. La precisión depende del sistema.

Verificaciones de estado divididas

De forma predeterminada, las comprobaciones de estado divididas están habilitadas. Puedes usar solicitudes periódicas de comprobación de estado para confirmar que una instancia de VM se implementó de manera correcta y para verificar que una instancia en ejecución mantenga un buen estado. Cada comprobación de estado debe recibir una respuesta dentro de un intervalo de tiempo determinado.

Una instancia está en mal estado cuando no responde a un número específico de solicitudes consecutivas de comprobación de estado. Si una instancia no está activa, se reinicia. Si una instancia no está lista, no recibirá solicitudes de clientes. Una comprobación de estado también puede tener errores si no hay espacio libre en el disco.

Existen dos tipos de comprobaciones de estado que puedes usar:

Las comprobaciones de actividad confirman que la VM y el contenedor de Docker están en ejecución. App Engine reinicia instancias con mal estado.
Las comprobaciones de disponibilidad confirman que la instancia está lista para aceptar solicitudes entrantes. Las instancias que no aprueban la comprobación de preparación no se agregan al conjunto de instancias disponibles.

De forma predeterminada, las solicitudes HTTP de las comprobaciones de estado no se reenvían al contenedor de tu aplicación. Si deseas extender las comprobaciones de estado a la aplicación, especifica una ruta de acceso para las comprobaciones de actividad o las comprobaciones de disponibilidad. Una comprobación de estado personalizada de tu aplicación se considera exitosa si muestra un código de respuesta 200 OK.

Verificaciones de actividad

Las comprobaciones de actividad confirman que la VM y el contenedor de Docker están en ejecución. Las instancias que se consideran en mal estado se reinician.

Para personalizar las solicitudes de comprobación de actividad, agrega una sección liveness_check opcional a tu archivo app.yaml, por ejemplo:

liveness_check:
  path: "/liveness_check"
  check_interval_sec: 30
  timeout_sec: 4
  failure_threshold: 2
  success_threshold: 2

Las siguientes opciones de configuración están disponibles para las comprobaciones de actividad:

Campo	Predeterminado	Rango (mínimo-máximo)	Descripción
`path`	Ninguno		Si deseas que las comprobaciones de actividad se reenvíen al contenedor de la aplicación, especifica una ruta de URL, como `"/liveness_check"`.
`timeout_sec`	4 segundos	1-300	Intervalo de tiempo de espera para cada solicitud, en segundos
`check_interval_sec`	30 segundos	1-300	Intervalo de tiempo entre comprobaciones, en segundos. Ten en cuenta que este valor debe ser mayor que timeout_sec.
`failure_threshold`	4 verificaciones	1-10	El estado de una instancia no es bueno si falla este número de verificaciones consecutivas.
`success_threshold`	2 comprobaciones	1-10	Una instancia cambia de estado malo a bueno si responde correctamente a este número de verificaciones consecutivas.
`initial_delay_sec`	300 segundos	0-3600	Retraso, en segundos, después del inicio de la instancia durante el cual se ignoran las respuestas de la comprobación de estado. Esta configuración se aplica a cada instancia recién creada y puede permitir que una nueva instancia tenga más tiempo para empezar a funcionar. La configuración retrasa la reparación automática para que no lleve a cabo la comprobación y, potencialmente, la recreación prematura de la instancia si la instancia está en proceso de inicio. El temporizador de retraso inicial comienza cuando la instancia está en el modo en ejecución. Por ejemplo, es posible que desees aumentar el retraso si tu aplicación tiene tareas de inicialización que demoran mucho tiempo antes de que esté lista para entregar el tráfico.

Verificaciones de disponibilidad

Las comprobaciones de disponibilidad confirman que una instancia puede aceptar solicitudes entrantes. Las instancias que no pasan la comprobación de disponibilidad no se agregan al grupo de instancias disponibles.

Para personalizar las solicitudes de comprobación de estado, agrega una sección readiness_check opcional a tu archivo app.yaml, por ejemplo:

readiness_check:
  path: "/readiness_check"
  check_interval_sec: 5
  timeout_sec: 4
  failure_threshold: 2
  success_threshold: 2
  app_start_timeout_sec: 300

Las siguientes opciones de configuración están disponibles para las comprobaciones de disponibilidad:

Campo	Predeterminado	Rango (mínimo-máximo)	Descripción
`path`	Ninguno		Si deseas que las comprobaciones de disponibilidad se reenvíen al contenedor de la aplicación, especifica una ruta de URL, como `"/readiness_check"`.
`timeout_sec`	4 segundos	1-300	Intervalo de tiempo de espera para cada solicitud, en segundos
`check_interval_sec`	5 segundos	1-300	Intervalo de tiempo entre comprobaciones, en segundos. Ten en cuenta que este valor debe ser mayor que timeout_sec.
`failure_threshold`	2 comprobaciones	1-10	El estado de una instancia no es bueno si falla este número de verificaciones consecutivas.
`success_threshold`	2 comprobaciones	1-10	Una instancia cambia de estado malo a bueno si responde correctamente a este número de verificaciones consecutivas.
`app_start_timeout_sec`	300 segundos	1-1800	Esta configuración se aplica a las implementaciones nuevas, no a las VM individuales. Especifica el tiempo máximo en segundos que se permite para que una cantidad suficiente de instancias de una implementación pase las comprobaciones de estado. Si se excede esta duración, la implementación falla y se revierte. El temporizador se inicia luego del aprovisionamiento de las instancias de Compute Engine y la creación del servicio de backend del balanceador de cargas. Por ejemplo, es posible que desees aumentar el tiempo de espera si deseas proporcionar tiempos de espera más largos durante las implementaciones para que un número suficiente de instancias se recupere.

Frecuencia de las comprobaciones de estado

Para garantizar una alta disponibilidad, App Engine crea copias redundantes de cada verificador de estado. Si falla un verificador de estado, uno redundante puede reemplazarlo sin demora.

Si examinas los registros nginx.health_check de la aplicación, es posible que veas que el sondeo de la comprobación de estado se realiza con más frecuencia de la que configuraste, debido a los verificadores de estado redundantes que también siguen tu configuración. Estos verificadores de estado redundantes se crean de forma automática y no puedes configurarlos.

Configuración de escalamiento de servicios

Las claves usadas para controlar el ajuste de escala de un servicio dependen del tipo de ajuste de escala que asignes al servicio.

Puedes usar el ajuste de escala automático o manual. El valor predeterminado es el ajuste de escala automático.

Ajuste de escala automático

Para configurar el ajuste de escala automático, agrega una sección automatic_scaling al archivo app.yaml. Por ejemplo:

automatic_scaling:
  min_num_instances: 1
  max_num_instances: 15
  cool_down_period_sec: 180
  cpu_utilization:
    target_utilization: 0.6
  target_concurrent_requests: 100

En la siguiente tabla, se enumeran las configuraciones que puedes usar con el ajuste de escala automático:

Nombre	Descripción
`automatic_scaling`	El ajuste de escala automático se supone de manera predeterminada. Incluye esta línea si vas a especificar alguna de las configuraciones de ajuste de escala automático.
`min_num_instances`	Número mínimo de instancias otorgadas a tu servicio. Cuando se implementa un servicio, se le asigna esta cantidad de instancias y ajustes de escala de acuerdo con el tráfico. Debe ser `1` o mayor; el valor predeterminado es `2` para reducir la latencia. Nota: La cantidad de instancias en ejecución puede disminuir por debajo de este valor durante un período corto durante algunos eventos. Si tu aplicación requiere ejecución continua en una cantidad determinada de instancias, considera aprovisionamiento en exceso.
`max_num_instances`	Número máximo de instancias que tu servicio puede escalar. La cantidad máxima de instancias de tu proyecto está limitada por la cuota de recursos de tu proyecto. El valor predeterminado es `20`.
`cool_down_period_sec`	Cantidad de segundos que el escalador automático debe esperar antes de empezar a recopilar información de una instancia nueva. Esto evita que el escalador automático recopile información cuando la instancia se está inicializando, tiempo en el que el uso recopilado no sería confiable. El período de inactividad debe ser mayor o igual que 60 segundos. El valor predeterminado es `120`.
`cpu_utilization`	Emplea este encabezado si vas a especificar el uso de CPU objetivo.
`target_utilization`	Uso de CPU objetivo. El uso de CPU se promedia entre todas las instancias en ejecución y se emplea para decidir cuándo reducir o aumentar el número de instancias. Ten en cuenta que las instancias se reducen 25 segundos después de que una instancia recibe la señal de apagado sin importar las solicitudes activas. El valor predeterminado es `0.5`.
`target_concurrent_requests`	(beta) Cantidad objetivo de conexiones simultáneas por instancia. Si especificas un valor para este parámetro, el escalador automático usa el número promedio de conexiones simultáneas en todas las instancias en ejecución para decidir cuándo reducir o aumentar el número de instancias. Una instancia se reduce 25 segundos después de que recibe la señal de apagado, sin importar las solicitudes que están en proceso. Si no especificas un valor para este parámetro, el escalador automático no está orientado a una cantidad de conexiones simultáneas por instancia. Las conexiones son diferentes de las solicitudes. Un cliente puede reusar una conexión para enviar varias solicitudes.

Ajuste de escala manual

Para configurar el ajuste de escala manual, agrega una sección manual_scaling al archivo app.yaml. Por ejemplo:

manual_scaling:
  instances: 5

En la siguiente tabla, se enumeran las configuraciones que puedes usar con el ajuste de escala manual:

Nombre	Descripción
`manual_scaling`	Necesario para habilitar el ajuste de escala manual de un servicio
`instances`	Número de instancias para asignar al servicio Nota: La cantidad de instancias en ejecución puede disminuir por debajo de este valor durante un período corto durante algunos eventos. Si tu aplicación requiere ejecución continua en una cantidad determinada de instancias, considera aprovisionamiento en exceso.

Define variables de entorno

Puedes definir las variables de entorno en app.yaml para que estén disponibles para tu app, como en el siguiente ejemplo:

env_variables:
  MY_VAR: "my value"

En el ejemplo anterior, MY_VAR y my value son el nombre y el valor de la variable de entorno que deseas definir y cada entrada de variable de entorno tiene una sangría de dos espacios debajo del elemento env_variables.