Esta página se ha traducido con Cloud Translation API.

Archivo de configuración app.yaml

El archivo app.yaml define los ajustes de configuración de tu entorno de ejecución, así como los ajustes generales de la aplicación, la red y otros recursos.

No añadas app.yaml al archivo .gcloudignore. Es posible que se necesite app.yaml para el despliegue, y si se añade a .gcloudignore, el despliegue fallará.

Sintaxis

La sintaxis del archivo app.yaml es el formato YAML. El formato YAML admite comentarios, por lo que se ignora cualquier línea que empiece por el símbolo de almohadilla (#). Por ejemplo:

# This is a comment.

Los patrones de URL y de ruta de archivo usan la sintaxis de expresiones regulares extendidas POSIX, excepto los elementos de ordenación y las clases de ordenación. Se admiten las referencias inversas a coincidencias agrupadas (por ejemplo, \1) y estas extensiones de Perl: \w \W \s \S \d \D.

Configuración general

Un archivo app.yaml puede incluir estos ajustes generales. Ten en cuenta que algunos de ellos son obligatorios:

Nombre	Descripción
`build_env_variables`	Opcional. Si usas un tiempo 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 Usar variables de entorno de compilación.
`runtime`	Obligatorio. Nombre del entorno de ejecución que usa tu aplicación. Por ejemplo, para especificar el entorno de ejecución, usa:
`env: flex`	Obligatorio: selecciona el entorno flexible.
`service: service_name`	Obligatorio si se crea un servicio. Opcional para el servicio predeterminado. Cada servicio y cada versión deben tener un nombre. El nombre puede contener números, letras y guiones. En el entorno flexible, la longitud combinada de `VERSION-dot-SERVICE-dot-PROJECT_ID` (donde `VERSION` es el nombre de tu versión, `SERVICE` es el nombre de tu servicio y `PROJECT_ID` es tu ID de proyecto) no puede superar los 63 caracteres ni empezar o terminar con un guion. Si realizas la implementación sin especificar un nombre de servicio, se creará una nueva versión del servicio predeterminado. Si implementas un servicio con un nombre que ya existe, se creará una nueva versión de ese servicio. Si implementas con un nombre de servicio nuevo que no existe, se crearán un servicio y una versión nuevos. Te recomendamos que uses un nombre único para cada combinación de servicio y versión. Nota: Antes, los servicios se llamaban "módulos".
`service_account`	Opcional. El elemento `service_account` te permite especificar una cuenta de servicio gestionada por el usuario como identidad de la versión. La cuenta de servicio especificada se usará al acceder a otros servicios Google Cloud y al ejecutar tareas. La cuenta de servicio debe proporcionarse con el siguiente formato: service_account: [SERVICE_ACCOUNT_NAME]@[PROJECT_ID].iam.gserviceaccount.com
`skip_files`	Opcional. El elemento `skip_files` 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 alguna de las expresiones regulares se omite de la lista de archivos que se van a subir cuando se sube la aplicación. Por ejemplo, para omitir los archivos cuyos nombres terminen en `.bak`, añade una sección `skip_files` como la siguiente: skip_files: - ^.*\.bak$

Configuración de red

Puede especificar los ajustes de red en el 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

Puede usar las siguientes opciones al configurar los ajustes de red:

Opción	Descripción
`name`	Cada instancia de VM del entorno flexible se asigna a una red de Google Compute Engine cuando se crea. Usa este ajuste para especificar un nombre de red. Indica el nombre abreviado, no la ruta 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 asignarán a la red predeterminada del proyecto (que tiene el nombre `default`). Si quieres especificar un nombre de subred, debes especificar un nombre de red.
`instance_ip_mode`	Opcional. Para evitar que las instancias reciban una dirección IP externa efímera, asigna el valor `internal` y habilita Acceso privado a Google. Si tu instancia se implementó anteriormente sin este ajuste o con el valor `external`, al volver a implementarla con el valor `internal`, se eliminarán las direcciones IP externas efímeras de tus instancias. El ajuste `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 `gcloud` para orientar 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 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 ha especificado la red `name`. Indica el nombre abreviado, no la ruta del 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. Defina el valor `true` para configurar App Engine de forma que enrute varias solicitudes secuenciales de un usuario determinado a la misma instancia de App Engine, como cuando se almacenan datos de usuario de forma 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, a continuación, dirigir todas esas solicitudes a la misma instancia. Si la instancia se reinicia, no está en buen estado, está sobrecargada o deja de estar disponible cuando se ha reducido el número de instancias, la afinidad de sesión se interrumpirá y las solicitudes posteriores se dirigirán a otra instancia. Ten en cuenta que habilitar la afinidad de sesión puede afectar a la configuración del balanceo de carga. Este parámetro está inhabilitado de forma predeterminada.
`forwarded_ports`	Opcional. Puedes reenviar puertos de tu instancia (`HOST_PORT`) al contenedor 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 y 24231. `CONTAINER_PORT` debe estar entre 1 y 65535, y no puede entrar en conflicto con los siguientes puertos: 22, 10001, 10400-10500 y 11211. Si solo especificas un `PORT`, App Engine asume que es el mismo puerto en el host y en el contenedor. De forma predeterminada, se reenvía el tráfico TCP y UDP. El tráfico debe dirigirse directamente a la dirección IP de la instancia de destino, en lugar de hacerlo a través del dominio appspot.com o de tu dominio personalizado.

Configuración de red avanzada

Puedes segmentar tu red de Compute Engine en subredes. De esta forma, puedes habilitar escenarios de VPN, como acceder a bases de datos de tu red corporativa.

Para habilitar subredes en tu aplicación de App Engine, haz lo siguiente:

Crea una red de subredes personalizada.
Añade el nombre de la red y el nombre de la subred al archivo app.yaml, tal como se indica más arriba.
Para establecer una VPN sencilla basada en el enrutamiento estático, crea una pasarela y un túnel para una red de subred personalizada. De lo contrario, consulta cómo crear otros tipos de VPNs.

Redirección de puertos

El reenvío de puertos permite establecer conexiones directas con el contenedor Docker de tus instancias. Este tráfico puede viajar a través de cualquier protocolo. La redirección de puertos está pensada para ayudarte en situaciones en las que necesites 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 hacerlo a través del dominio appspot.com o de tu dominio personalizado.

De forma predeterminada, el tráfico entrante que sea ajeno a tu red no puede atravesar los cortafuegos de Google Cloud Platform. Después de especificar el reenvío de puertos en el archivo app.yaml, debes añadir una regla de cortafuegos que permita el tráfico de los puertos que quieras abrir.

Puedes especificar una regla de cortafuegos en la página Reglas de cortafuegos de la sección Redes de la Google Cloud consola o con comandos gcloud.

Por ejemplo, si quieres reenviar tráfico TCP desde el puerto 2222:

En los ajustes de red de tu app.yaml, incluye lo siguiente:
```
network:
  forwarded_ports:
    - 2222/tcp
```
1. Si usas el entorno de ejecución de Python, modifica app.yaml para incluir lo siguiente:
```
entrypoint: gunicorn -b :$PORT -b :2222 main:app
```
Especifica una regla de cortafuegos en la consola deGoogle Cloud o con gcloud compute firewall-rules create para permitir el tráfico de cualquier origen (0.0.0.0/0) y de tcp:2222.

Configuración de recursos

Estos ajustes controlan los recursos de computación. 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 tendrá al menos el nivel de recursos que hayas especificado, pero puede que tenga más.

Puedes especificar hasta ocho volúmenes de tmpfs en la configuración de recursos. Después, puedes habilitar cargas de trabajo que requieran memoria compartida mediante tmpfs y 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 al configurar los ajustes de los recursos:

Opción	Descripción	Predeterminado
`cpu`	El número de núcleos. Debe ser 1, 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 tu aplicación, que no incluye los ~0,4 GB de memoria que se requieren para la sobrecarga de algunos procesos. Cada núcleo de CPU requiere una memoria total de entre 1,0 y 6,5 GB. Para calcular la memoria solicitada, sigue estos pasos: `memory_gb` = `cpu` * [1,0 - 6,5] - 0,4 En el ejemplo anterior, en el que has especificado 2 núcleos, puedes solicitar entre 1,6 y 12,6 GB. El entorno de ejecución define 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 es 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 monta en el contenedor de la aplicación como `/mnt/NAME`.
`volume_type`	Obligatorio si se usan volúmenes. Debe ser `tmpfs`.
`size_gb`	Obligatorio si se usan volúmenes. Tamaño del volumen en GB. El mínimo es de 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 añade RAM adicional a tu sistema para cumplir los requisitos de 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.

Comprobaciones del estado divididas

Las comprobaciones del estado divididas están habilitadas de forma predeterminada. Puedes usar solicitudes periódicas de comprobación del estado para confirmar que una instancia de VM se ha implementado correctamente y para comprobar que una instancia en ejecución mantiene un estado correcto. Cada comprobación de estado debe responderse en un intervalo de tiempo especificado.

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

Hay dos tipos de comprobaciones de estado que puedes usar:

Las comprobaciones de actividad confirman que la máquina virtual y el contenedor Docker se están ejecutando. App Engine reinicia las instancias que no están en buen estado.
Las comprobaciones de preparación confirman que tu instancia está lista para aceptar solicitudes entrantes. Las instancias que no superen la comprobación de disponibilidad no se añadirán al grupo 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 quieres ampliar las comprobaciones de estado a tu aplicación, especifica una ruta para las comprobaciones de actividad o las comprobaciones de disponibilidad. Se considera que una comprobación de estado personalizada de tu aplicación se ha realizado correctamente si devuelve un código de respuesta 200 OK.

Comprobaciones de actividad

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

Puedes personalizar las solicitudes de comprobación de autenticidad añadiendo una liveness_check sección 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

Puedes usar los siguientes ajustes para las comprobaciones de vitalidad:

Campo	Predeterminado	Intervalo (mínimo-máximo)	Descripción
`path`	Ninguno		Si quieres que las comprobaciones de actividad se reenvíen al contenedor de tu aplicación, especifica una ruta de URL, como `"/liveness_check"`.
`timeout_sec`	4 segundos	1-300	Intervalo de tiempo de espera de 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	Una instancia no está en buen estado después de no superar este número de comprobaciones consecutivas.
`success_threshold`	2 comprobaciones	1-10	Una instancia en mal estado vuelve a estar en buen estado después de responder correctamente a este número de comprobaciones consecutivas.
`initial_delay_sec`	300 segundos	0-3600	El tiempo de espera, en segundos, después de que se inicie la instancia durante el cual se ignoran las respuestas de comprobación del estado. Este ajuste se aplica a cada instancia recién creada y puede permitir que una instancia nueva tarde más tiempo en iniciarse y ponerse en marcha. Este ajuste retrasa la comprobación del estado de la reparación automática y la posible recreación prematura de la instancia si esta se está iniciando. El temporizador de retardo inicial se inicia cuando la instancia está en modo RUNNING. Por ejemplo, puede que quieras aumentar el tiempo de espera si tu aplicación tiene tareas de inicialización que tardan mucho en completarse antes de que esté lista para servir tráfico.

Comprobaciones de preparación

Las comprobaciones de disponibilidad confirman que una instancia puede aceptar solicitudes entrantes. Las instancias que no superen la comprobación de disponibilidad no se añadirán al grupo de instancias disponibles.

Puedes personalizar las solicitudes de comprobación del estado añadiendo 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

Puedes usar los siguientes ajustes para las comprobaciones de preparación:

Campo	Predeterminado	Intervalo (mínimo-máximo)	Descripción
`path`	Ninguno		Si quiere que las comprobaciones de disponibilidad se reenvíen al contenedor de su aplicación, especifique una ruta de URL, como `"/readiness_check"`.
`timeout_sec`	4 segundos	1-300	Intervalo de tiempo de espera de 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	Una instancia no está en buen estado después de no superar este número de comprobaciones consecutivas.
`success_threshold`	2 comprobaciones	1-10	Una instancia en mal estado pasa a estar en buen estado después de responder correctamente a este número de comprobaciones consecutivas.
`app_start_timeout_sec`	300 segundos	1-1800	Este ajuste se aplica a las implementaciones nuevas, no a las máquinas virtuales individuales. Especifica el tiempo máximo en segundos que se permite para que un número suficiente de instancias de una implementación supere las comprobaciones del estado. Si se supera esta duración, la implementación falla y se revierte. El temporizador se inicia cuando se han aprovisionado las instancias de Compute Engine y se ha creado el servicio de backend del balanceador de carga. Por ejemplo, puede que quieras aumentar el tiempo de espera si quieres proporcionar tiempos de espera más largos durante las implementaciones para que un número suficiente de instancias se pongan en buen estado.

Frecuencia de comprobación del estado

Para garantizar la alta disponibilidad, App Engine crea copias redundantes de cada comprobador de estado. Si falla un comprobador de estado, otro redundante puede hacerse cargo sin demora.

Si examinas los registros nginx.health_check de tu aplicación, puede que veas que la comprobación del estado se realiza con más frecuencia de la que has configurado, debido a los comprobadores del estado redundantes que también siguen tu configuración. Estas comprobaciones del estado redundantes se crean automáticamente y no se pueden configurar.

Ajustes de escalado de servicios

Las claves que se usan para controlar el escalado de un servicio dependen del tipo de escalado que asignes al servicio.

Puedes usar el escalado automático o manual. El valor predeterminado es el escalado automático.

Escalado automático

Para configurar el escalado automático, añade 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 indican los ajustes que puede usar con el escalado automático:

Nombre	Descripción
`automatic_scaling`	El escalado automático se da por supuesto de forma predeterminada. Incluye esta línea si vas a especificar alguno de los ajustes de escalado automático.
`min_num_instances`	El número mínimo de instancias asignadas a tu servicio. Cuando se implementa un servicio, se le asigna este número de instancias y se escala en función del tráfico. Debe ser `1` o superior. El valor predeterminado es `2` para reducir la latencia. Nota: El número de instancias en ejecución puede ser inferior a este valor durante un breve periodo en algunos eventos. Si tu aplicación requiere ejecutarse continuamente en un número determinado de instancias, te recomendamos que utilices el sobreaprovisionamiento.
`max_num_instances`	Número máximo de instancias al que se puede escalar tu servicio. El número máximo de instancias de tu proyecto está limitado por la cuota de recursos del proyecto. El valor predeterminado es `20`.
`cool_down_period_sec`	Número de segundos que debe esperar el escalador automático antes de empezar a recoger información de una nueva instancia. De esta forma, el escalador automático no recogerá información cuando la instancia se esté inicializando, ya que el uso recogido no sería fiable. El periodo de enfriamiento debe ser igual o superior a 60 segundos. El valor predeterminado es `120` (ADMITE VALORES NULL).
`cpu_utilization`	Usa este encabezado si vas a especificar el uso de CPU objetivo.
`target_utilization`	Uso de CPU objetivo. El uso de la CPU se calcula como la media de todas las instancias en ejecución y se usa para decidir cuándo reducir o aumentar el número de instancias. Ten en cuenta que las instancias se reducen independientemente de las solicitudes en curso 25 segundos después de que una instancia reciba la señal de cierre. El valor predeterminado es `0.5` (ADMITE VALORES NULL).
`target_concurrent_requests`	(Beta) Número objetivo de conexiones simultáneas por instancia. Si especifica un valor para este parámetro, el escalador automático usará el número medio 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 recibir la señal de apagado, independientemente de las solicitudes que estén en proceso. Si no especifica ningún valor para este parámetro, el escalador automático no se dirigirá a un número de conexiones simultáneas por instancia. Las conexiones son diferentes de las solicitudes. Un cliente puede reutilizar una conexión para enviar varias solicitudes.

Escalado manual

Para configurar el escalado manual, añade una sección manual_scaling al archivo app.yaml. Por ejemplo:

manual_scaling:
  instances: 5

En la siguiente tabla se indican los ajustes que puede usar con el escalado manual:

Nombre	Descripción
`manual_scaling`	Se requiere para habilitar el escalado manual de un servicio.
`instances`	Número de instancias que se asignarán al servicio. Nota: El número de instancias en ejecución puede ser inferior a este valor durante un breve periodo en algunos eventos. Si tu aplicación requiere ejecutarse continuamente en un número determinado de instancias, te recomendamos que utilices el sobreaprovisionamiento.

Definir variables de entorno

Puedes definir variables de entorno en app.yaml para que estén disponibles en tu aplicación. Por ejemplo:

env_variables:
  MY_VAR: "my value"

donde MY_VAR y my value son el nombre y el valor de la variable de entorno que quieres definir, y cada entrada de variable de entorno tiene una sangría de dos espacios en el elemento env_variables.