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:

service_account: [SERVICE_ACCOUNT_NAME]@[PROJECT_ID].iam.gserviceaccount.com

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:

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:

1. Crea una red de subredes personalizada.

2. Agrega el nombre de la red y el nombre de la subred a tu archivo app.yaml, como se especificó antes.

3. 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:

1. 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
      

2. 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:

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:

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:

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:

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:

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