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 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 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
Por ejemplo, para saltar archivos cuyos nombres terminan en 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. El valor predeterminado 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 . |
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:
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
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 desdetcp: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:
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 |
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 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. |
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.
|
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 |
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
.
Usa tus variables de entorno