Referencia de app.yaml

ID de región

REGION_ID es un código abreviado que Google asigna en función de la región que seleccionas cuando creas la app. El código no corresponde a un país ni a una provincia, aunque algunos ID de región puedan parecer similares a los códigos de país y provincia que se suelen usar. Incluir REGION_ID.r en las URL de App Engine es opcional en el caso de las apps existentes, y pronto será obligatorio para todas las apps nuevas.

A fin de garantizar una transición sin problemas, estamos actualizando App Engine de forma paulatina para usar los ID de región. Si aún no actualizamos tu proyecto de Google Cloud, no verás un ID de región para la app. Dado que el ID es opcional en las apps existentes, no es necesario que actualices las URL ni realices otros cambios una vez que el ID de región esté disponible en las apps existentes.

Obtén más información acerca de los ID de región.

Puedes configurar tu app de App Engine en el archivo app.yaml. Este archivo especifica cómo las rutas de URL se corresponden con los controladores de solicitud y los archivos estáticos. El archivo app.yaml también contiene información sobre el código de la app, como el entorno de ejecución y el identificador de versión más reciente.

Cada servicio de la app tiene su propio archivo app.yaml, que actúa como descriptor para su implementación. Primero debes crear el archivo app.yaml para el servicio default, antes de que puedas crear y, luego, implementar archivos app.yaml a servicios adicionales dentro de la app.

Estructura del directorio

Para obtener más información sobre cómo estructurar servicios múltiples en tu aplicación, consulta Cómo estructurar servicios web en App Engine.

Ejemplo

A continuación, se muestra un ejemplo de un archivo app.yaml para una aplicación de Python 2:

runtime: python27
api_version: 1
threadsafe: true

handlers:
- url: /
  script: home.app

- url: /index\.html
  script: home.app

- url: /stylesheets
  static_dir: stylesheets

- url: /(.*\.(gif|png|jpg))$
  static_files: static/\1
  upload: static/.*\.(gif|png|jpg)$

- url: /admin/.*
  script: admin.app
  login: admin

- url: /.*
  script: not_found.app

Una directiva script: puede contener una ruta de archivo que termine en .py, lo que significa que la secuencia de comandos usa CGI o una ruta de módulo de Python, con nombres de paquetes separados por puntos. Esto significa que la secuencia de comandos usa WSGI.

Sintaxis

La sintaxis de app.yaml usa el formato YAML.

El formato YAML admite el uso de comentarios. Se ignoran las líneas que comienzan con el signo numeral (#):

# This is a comment.

Los patrones de ruta de archivo y URL usan la sintaxis de expresiones regulares extendidas de 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.

Entorno de ejecución y elementos de la app

Elemento	Descripción
`application`	Advertencia: El elemento `application` y el uso de las herramientas `appcfg` se encuentran obsoletos. Consulta las siguientes instrucciones para especificar la aplicación mediante las herramientas del SDK de Cloud, como la línea de comandos de `gcloud`. Se recomienda quitar el elemento `application` del archivo `app.yaml` y, en su lugar, usar una marca de línea de comandos para especificar el ID de aplicación: Para usar el comando `gcloud app deploy`, debes especificar la marca `--project`: gcloud app deploy --project [YOUR_PROJECT_ID] Para usar el comando `appcfg.py update`, debes especificar la marca `-A`: appcfg.py update -A [YOUR_PROJECT_ID] A fin de obtener más información para usar estos comandos, consulta Implementa la app. El ID de aplicación es el ID del proyecto de Cloud Console que especificaste cuando creaste la aplicación en Google Cloud Console.
`api_version`	Obligatorio. La versión de la API en un entorno de ejecución determinado que usa la app. Este campo está obsoleto en los entornos de ejecución más recientes de App Engine. Cuando Google anuncia la compatibilidad con una versión nueva de la API de un entorno de ejecución, la app implementada continuará usando la API para la cual se escribió. Cuando quieras actualizar tu app a una versión nueva de la API, tendrás que cambiar este valor y, luego, volver a implementar la aplicación en App Engine. Cuando especificas el valor `1`, se usa el último entorno de ejecución compatible cada vez que implementas esa app (en la actualidad, ). En este momento, App Engine tiene una versión del entorno de ejecución de `python27`: `1`
`auto_id_policy`	Opcional. Si configuras identificadores de entidad de manera automática, puedes cambiar el método empleado; para ello, configura la política de ID automático. Las siguientes son opciones válidas: `default` Predeterminado. Usa ID automáticos dispersos que son números enteros grandes y bien distribuidos, pero lo suficientemente pequeños para que los representen números de punto flotante de 64 bits. `legacy` La opción heredada quedará obsoleta en una actualización futura y, al final, se quitará. Para obtener más información, consulta la entrada de blog que anuncia este cambio.
`builtins`	Opcional. El SDK de Python 2 incluye varios controladores integrados para las funciones de aplicación comunes. La directiva `builtins` te permite incluir controladores específicos en `app.yaml`. Este campo está obsoleto en el entorno de ejecución de Python 3. Los siguientes controladores integrados están disponibles para su uso: `appstats` Habilita estadísticas de la aplicación en `/_ah/stats/`, que puedes usar para medir el rendimiento de la aplicación. Para usar las estadísticas de la aplicación, también tienes que instalar el registrador de eventos. `deferred` Habilita el controlador diferido en `/_ah/queue/deferred`. Este elemento integrado permite que los desarrolladores usen `deferred.defer()` para simplificar la creación de tareas de la lista de tareas en cola. También consulta Trabajo en segundo plano con la biblioteca diferida. `remote_api` Habilita el elemento integrado `remote_api` en `/_ah/remote_api/`. Este elemento integrado permite que las aplicaciones remotas con las credenciales adecuadas accedan al almacén de datos de forma remota. Ejemplo: builtins: - deferred: on - appstats: on La directiva `builtins` es una instancia especial de la directiva `includes`. En Python, cada directiva `builtin` es equivalente a una directiva `includes` con una ruta expandida. Por ejemplo: builtins: - name: on Es equivalente a lo siguiente: includes: - $PYTHON_LIB/google/appengine/ext/builtins/name/ Cuando usas `builtins` en el archivo `app.yaml`, cualquier controlador definido en el archivo `include.yaml` integrado sustituirá a cualquier controlador que definas en el archivo `app.yaml`. Sin embargo, si incluyes un archivo que luego usa `builtins` o `includes`, los controladores se agregan según el orden de la jerarquía de inclusión. En otras palabras, los controladores de la inclusión “superior” se agregan antes que los elementos integrados de las inclusiones “secundarias”, y así sucesivamente. Por ejemplo, considera el siguiente `app.yaml`, que usa los controladores `appstats` integrados: handlers: - url: /.* script: main.app builtins: - appstats: on La lista resultante de controladores es la siguiente: [/_ah/stats, /.] Si `app.yaml` usa una directiva `includes`: includes: - included.yaml Y el archivo `included.yaml` usa `builtins`: handlers: - url: /. script: main.app builtins: - appstats: on La lista resultante de controladores ahora es la siguiente: [/.*, /_ah/stats] El orden de ubicación de la cláusula `builtins` en un archivo `.yaml` no cambia el comportamiento.
`default_expiration`	Opcional. Establece un período de caché predeterminado global para todos los controladores de archivos estáticos de una aplicación. También puedes configurar la duración de la caché para controladores de archivos estáticos específicos. El valor es una string de números y unidades, separados por espacios, en la que las unidades pueden ser d para días, h para horas, m para minutos y s para segundos. Por ejemplo, con `"4d 5h"` se establece el vencimiento de la caché dentro de 4 días y 5 horas después de que se solicita el archivo por primera vez. Si se omite, el servidor de producción establece el vencimiento dentro de 10 minutos. Ejemplo: runtime: python27 api_version: 1 threadsafe: true default_expiration: "4d 5h" handlers: # ... Para obtener más información, consulta Vencimiento de la caché.
`env_variables`	Opcional. Puedes definir variables de entorno en el archivo `app.yaml` a fin de que estén disponibles para la app. Las variables de entorno que tienen el prefijo `GAE` se reservan para el uso del sistema y no están permitidas en el archivo `app.yaml`. Estas variables estarán disponibles en el diccionario `os.environ`: env_variables: DJANGO_SETTINGS_MODULE: "myapp.settings"
`error_handlers`	Opcional. Se utiliza para configurar las páginas de error personalizadas que se muestran para los tipos de errores diferentes. Puede contener los siguientes elementos: `error_code` Opcional. El `error_code` puede ser uno de los siguientes: `over_quota` Indica que la app superó una cuota de recursos. `dos_api_denial` Indica que la configuración de protección contra DoS de la app bloqueó la solicitud. `timeout` Se entrega si se alcanza un plazo antes de que exista una respuesta por parte de la app. El error_code es opcional; si no se especifica, el archivo es la respuesta de error predeterminada para la app. `file` Cada entrada de archivo indica un archivo estático que debe entregarse en lugar de la respuesta de error genérica. Si especificas un elemento `file` sin el elemento `error_code` correspondiente, la página de error predeterminada de la app será el archivo estático. Advertencia: Asegúrate de que la ruta al archivo de respuesta de error no se superponga con las rutas del controlador de los archivos estáticos. Los datos de error personalizados deben pesar menos de 10 kilobytes. Ejemplo error_handlers: - file: default_error.html - error_code: over_quota file: over_quota.html
`handlers`	Obligatorio. Una lista de patrones de URL y descripciones acerca de cómo deben manejarse. App Engine puede manejar las URL mediante la ejecución del código de aplicación, o la entrega de archivos estáticos subidos con el código, como imágenes, CSS o JavaScript. Consultar la sintaxis de controladores y subelementos
`includes`	Opcional. La directiva `includes` te permite incluir el archivo de configuración de cualquier biblioteca o servicio en toda la aplicación. Por ejemplo, puedes incluir una biblioteca de administración de usuarios de la siguiente manera: includes: - lib/user_admin.yaml App Engine resuelve la ruta incluida en el siguiente orden: Ruta absoluta o relativa al directorio de trabajo. La ruta especificada se resuelve en un archivo. Relativa al directorio de la aplicación, que también se conoce como ruta base. La ruta base y la ruta se resuelven en un archivo. Relativa al archivo que incluía el archivo actual. La ubicación del archivo de referencia y la ruta de inclusión se resuelven en el archivo incluido. Si la directiva `include` especifica un directorio, entonces App Engine busca un archivo llamado `include.yaml`. Si la directiva de inclusión es un archivo, entonces se incluye ese archivo específico. El uso de `includes` recupera solo los siguientes tipos de directivas del archivo de destino (si están presentes): `builtins` `includes` `handlers` `skip_files` Los patrones `skip_files` incluidos se agregan a aquellos en el archivo `app.yaml` incluido o a la lista predeterminada si no hay una lista explícita en `app.yaml`. Ten en cuenta que `skip_files` compara las rutas absolutas.
`inbound_services`	Opcional. Las aplicaciones deben habilitar esos servicios para poder recibir solicitudes entrantes. Puedes habilitar el servicio para una app de Python 2 si incluyes una sección `inbound_services` en el archivo `app.yaml`. Los siguientes servicios de entrada están disponibles: `mail` Permite que la aplicación reciba correos electrónicos. `warmup` Habilita las solicitudes de preparación. Consulta Configura solicitudes de preparación. Ejemplo: inbound_services: - mail - warmup
`instance_class`	Opcional. La clase de instancia para este servicio. Los siguientes valores están disponibles según el escalamiento del servicio: Ajuste de escala automático `F1`, `F2`, `F4`, `F4_1G` Predeterminada: `F1` De manera opcional, usa el elemento `automatic_scaling` para cambiar la configuración predeterminada del ajuste de escala automático, como la cantidad mínima y máxima de instancias, la latencia y las conexiones simultáneas. Nota: Si `instance_class` está configurado como `F2` o superior, puedes optimizar tus instancias si estableces `max_concurrent_requests` en un valor superior al valor predeterminado de 10. Para determinar el valor óptimo, auméntalo de manera gradual y supervisa el rendimiento de la aplicación. Ajuste de escala básico y manual `B1`, `B2`, `B4`, `B4_1G`, `B8` Predeterminada: `B2` Las clases de instancias básicas y manuales requieren que especifiques el elemento `basic_scaling` o el elemento `manual_scaling`.
`libraries`	Opcional. El entorno de ejecución de Python 2.7 incluye algunas bibliotecas de terceros. Algunas de estas bibliotecas están disponibles de forma predeterminada; otras solo están disponibles si se las configura. Puedes especificar qué versión quieres usar si especificas los valores `name` y `version`. Este campo está obsoleto en el entorno de ejecución de Python 3. libraries: - name: PIL version: "1.1.7" - name: webob version: "latest" Ten en cuenta que cuando especificas `latest`, el SDK determina la versión de biblioteca más reciente en el momento de la implementación. Una vez implementada, la versión de la biblioteca no cambiará. La única forma de obtener una versión diferente de la biblioteca es implementarla de nuevo. Si estás desarrollando una aplicación que aún no tiene usuarios: no necesitas realizar un seguimiento de las versiones nuevas. Pero si la aplicación se utiliza de manera activa, ten cuidado: tal vez te sorprenda saber que la aplicación comienza a utilizar una versión nueva de biblioteca que no es compatible con las versiones anteriores. Para obtener una lista de las bibliotecas de terceros incluidas, consulta Bibliotecas de terceros. Puedes usar bibliotecas de terceros adicionales exclusivas de Python; para ello, instálalas en un directorio local. Si utilizas el entorno flexible, consulta Cómo usar bibliotecas de Python en el entorno flexible.
`module`	Nota: Ahora, los módulos se denominan servicios. Para administrar la app con la herramienta de `gcloud`, usa el elemento servicio en su lugar. Para usar la herramienta `appcfg`, se deben declarar los servicios en archivos `app.yaml` como módulos, como se muestra a continuación: module: service-name Advertencia: El elemento `module` y el uso de las herramientas `appcfg` se encuentran obsoletos. Consulta las siguientes instrucciones para especificar la aplicación mediante las herramientas del SDK de Cloud, como la línea de comandos de `gcloud`. Es obligatorio si se crea un servicio. Es opcional para el servicio `default`. Cada servicio y versión deben tener un nombre. Un nombre puede contener números, letras y guiones. 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. Elige un nombre único para cada servicio y cada versión. No vuelvas a usar nombres entre servicios y versiones.
`runtime`	Obligatorio El nombre del entorno de ejecución que usa la app. Para especificar Python 2.7, usa lo siguiente: runtime: python27
`service`	Antes, los servicios se llamaban módulos. Solo son compatibles con la herramienta de `gcloud` o los complementos basados en el SDK de Cloud, como `gcloud app deploy`. Para usar la herramienta `appcfg`, consulta module. Obligatorio si se crea un servicio. Es opcional para el servicio `default`. Cada servicio y versión deben tener un nombre. Un nombre puede contener números, letras y guiones. 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. Elige un nombre único para cada servicio y cada versión. No vuelvas a usar nombres entre servicios y versiones. Ejemplo: service: service-name Nota: El comando `gcloud app deploy` es compatible con versiones anteriores y admite archivos `app.yaml` existentes que incluyen servicios declarados como módulos, por ejemplo: module: service-name
`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 puede ser 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 para subir cuando se carga la aplicación. Los nombres de archivos son relativos al directorio del proyecto. `skip_files` tiene el valor predeterminado siguiente: skip_files: - ^(./)?#.#$ - ^(./)?.~$ - ^(./)?.\.py[co]$ - ^(./)?./RCS/.$ - ^(./)?\..$ Con el patrón predeterminado se excluyen los archivos de copia de seguridad Emacs con nombres de la forma `#...#`, `...~`, los archivos `.pyc` y `.pyo`, los archivos en un directorio de control de revisión `RCS` y los archivos ocultos de Unix cuyos nombres comienzan con un punto (`.`). Para ampliar la lista anterior de expresiones regulares, copia y pega la lista en tu `app.yaml` y agrega tus propias expresiones regulares. Por ejemplo, para omitir archivos cuyos nombres terminan en `.bak`, además de los patrones predeterminados, debes agregar una entrada como esta para `skip_files`: skip_files: - ^(./)?#.#$ - ^(./)?.~$ - ^(./)?.\.py[co]$ - ^(./)?./RCS/.$ - ^(./)?\..$ - ^(./)?.\.bak$ Para omitir un directorio completo, agrega el nombre del directorio a la lista. Por ejemplo, para omitir un directorio llamado `logs`, agrega la siguiente línea a las descritas con anterioridad: skip_files: - logs/
`threadsafe`	Obligatorio. Configura la aplicación para usar solicitudes simultáneas. Si usas la biblioteca de subprocesos de Python, los datos locales de subprocesos, como los muestra `threading.local()`, se borran después de cada solicitud. Este campo está obsoleto en el entorno de ejecución de Python 3. threadsafe: [true \| false] Nota: La directiva `threadsafe` es obligatoria para las aplicaciones de Python 2.7. `threadsafe: true` requiere que todos los controladores de la secuencia de comandos sean WSGI. Es decir, cada secuencia de comandos debe especificarse en una directiva `script:` mediante la ruta del módulo de Python, con los nombres de los paquetes separados por puntos. El último componente de una directiva `script:` que usa una ruta de módulo de Python es el nombre de una variable global en `service:`. Esa variable debe ser una app WSGI, y, en general, se la denomina `app` por convención.
`version`	Se recomienda quitar el elemento `version` del archivo `app.yaml` y, en su lugar, usar una marca de línea de comandos para especificar el ID de versión: Para usar el comando `gcloud app deploy`, debes especificar la marca `-v`: gcloud app deploy -v [YOUR_VERSION_ID] Para usar el comando `appcfg.py update`, debes especificar la marca `-V`: appcfg.py update -V [YOUR_VERSION_ID] Advertencia: La herramienta `appcfg` ahora está obsoleta. Debes usar las herramientas del SDK de Cloud, como la línea de comandos de `gcloud`. A fin de obtener más información para usar estos comandos, consulta Implementa la app. Un identificador para la versión del código de la aplicación que implementas en App Engine. El ID de versión puede contener letras en minúscula, dígitos y guiones. No puede comenzar con el prefijo `ah-`; los nombres `default` y `latest` están reservados y no se pueden usar. Nota: Los nombres de las versiones deben comenzar con una letra para distinguirlos de las instancias numéricas que siempre se especifican mediante un número. Así se evita la ambigüedad con URL como `123-dot-my-service.uc.r.appspot.com`, que se pueden interpretar de dos maneras: si existe la versión “123”, el destino será la versión “123” de ese servicio. Si esa versión no existe, el destino será la instancia número 123 de la versión predeterminada del servicio. Cada versión de una aplicación conserva su propia copia de `app.yaml`. Cuando se sube una aplicación, la versión mencionada en el archivo `app.yaml` que se está subiendo es la versión que la carga crea o reemplaza. Un administrador puede cambiar la versión de la aplicación que entrega el tráfico mediante Google Cloud Console y, además, puede probar otras versiones antes de configurarlas para recibir tráfico.
`vpc_access_connector`	Opcional. Configura la aplicación para que use un conector de Acceso a VPC sin servidores, lo que le permite enviar solicitudes a recursos internos de tu red de VPC. Especifica el nombre completamente calificado de un conector en el campo `name`: vpc_access_connector: name: "projects/[PROJECT_ID]/locations/[REGION]/connectors/[CONNECTOR_NAME]" Para obtener más información, consulta Conecta recursos internos a una red de VPC.

Elemento handlers

El elemento handlers es un elemento obligatorio para el archivo de configuración app.yaml. El elemento proporciona una lista de patrones de URL y descripciones acerca de cómo deben controlar. App Engine puede controlar las URL mediante la ejecución del código de aplicación o la entrega de archivos estáticos subidos con el código, como imágenes, CSS o JavaScript.

Los patrones se evalúan en el orden en que aparecen en el archivo app.yaml, de arriba abajo. Para controlar la solicitud, se utiliza la primera asignación cuyo patrón coincide con la URL.

En la siguiente tabla, se muestran los subelementos del elemento handlers que controlan el comportamiento de las secuencias de comandos, los archivos estáticos, los directorios estáticos y otras opciones de configuración.

Elemento	Descripción
`application_readable`	Opcional. Booleano. Mediante la configuración predeterminada, los archivos declarados en los controladores de los archivos estáticos se suben como datos estáticos y solo se entregan a los usuarios finales. Una aplicación no puede leerlos. Si el campo se establece en verdadero, los archivos también se suben como datos de código para que la aplicación pueda leerlos. Ambas cargas se cobran en el código y las cuotas de recursos de almacenamiento de datos estáticos. Este campo está obsoleto en los entornos de ejecución más recientes de App Engine.
`auth_fail_action`	Opcional. Describe la acción realizada cuando se especifica el elemento `login` para un controlador y el usuario no accedió. Tiene dos valores posibles: `redirect` Predeterminado. Se redirige al usuario a la página de inicio de sesión de Google o `/_ah/login_required` si se usa la autenticación OpenID. Se redirecciona de nuevo al usuario a la URL de la aplicación después de acceder a la cuenta o crear una. `unauthorized` Se rechaza la solicitud con un código de estado `HTTP 401` y un mensaje de error. Si una aplicación necesita un comportamiento diferente, esta puede implementar el control de los accesos de los usuarios. Consulta la API de usuarios para obtener más información. En el ejemplo siguiente, se requiere un inicio de sesión para el directorio `/profile/` y un inicio de sesión de administrador para el directorio `/admin/`: handlers: - url: /profile/.* script: user_profile.app login: required - url: /admin/.* script: admin.app login: admin - url: /.* script: welcome.app Puedes configurar un controlador para que rechace el acceso a las URL protegidas cuando el usuario no accedió, en lugar de redireccionar al usuario a la página de acceso. Para ello, agrega `auth_fail_action: unauthorized` a la configuración del controlador: handlers: - url: /secure_api/.* script: api_handler.app login: required auth_fail_action: unauthorized
`expiration`	Opcional. El tiempo durante el cual los proxies y los navegadores web deben almacenar en caché el archivo estático que entrega este controlador. El valor es una string de números y unidades, separados por espacios, en la que las unidades pueden ser `d` por días, `h` por horas, `m` por minutos y `s` por segundos. Por ejemplo, `"4d 5h"` establece el vencimiento de la caché en 4 días y 5 horas después de que se solicita el archivo por primera vez. Si se omite, se usa el `default_expiration` de la aplicación. Consulta Vencimiento de la caché para obtener más detalles.
`http_headers`	Opcional. Puedes configurar los encabezados HTTP para las respuestas del archivo estático o los controladores de directorio. Si necesitas establecer encabezados HTTP en los controladores de `script`, debes hacerlo en el código de la app. Para obtener información sobre qué encabezados de respuesta influyen en el almacenamiento en caché, consulta Almacena en caché el contenido estático. Ejemplo handlers: - url: /images static_dir: static/images http_headers: X-Foo-Header: foo X-Bar-Header: bar value vary: Accept-Encoding # ... Compatibilidad con CORS Un uso importante de esta función es admitir el uso compartido de recursos multiorigen (CORS), como el acceso a archivos alojados por otra app de App Engine. Por ejemplo, puedes tener una app de juegos `mygame.uc.r.appspot.com` que acceda a los recursos alojados en `myassets.uc.r.appspot.com`. Sin embargo, si `mygame` intenta hacer un JavaScript `XMLHttpRequest` a `myassets`, no tendrá éxito, a menos que el controlador de `myassets` muestre un encabezado de respuesta `Access-Control-Allow-Origin:` que contenga el valor `http://mygame.uc.r.appspot.com`. A continuación, se muestra cómo tendrías que hacer para que el controlador de archivos estáticos muestre ese valor de encabezado de respuesta requerido: handlers: - url: /images static_dir: static/images http_headers: Access-Control-Allow-Origin: https://mygame.uc.r.appspot.com # ... Nota: Si deseas permitir que todos accedan a tus recursos, puedes usar el comodín `'*'`, en lugar de `https://mygame.uc.r.appspot.com`.
`login`	Opcional. Determina si el controlador de URL requiere que el usuario haya accedido. Este campo no está disponible en los entornos de ejecución más recientes de App Engine. Este elemento tiene tres valores posibles: `optional` Predeterminado. No requiere que el usuario haya accedido. `required` Si el usuario accedió, el controlador procede con normalidad. De lo contrario, se toma la medida indicada en `auth_fail_action`. `admin` Al igual que con `required`, se realiza `auth_fail_action` si el usuario no accedió. Además, si el usuario no es un administrador de la aplicación, recibirá un mensaje de error, más allá de la configuración `auth_fail_action`. Si el usuario es un administrador, el controlador continúa. Cuando un controlador de URL con una configuración `login` distinta de `optional` coincide con una URL, el controlador primero comprueba si el usuario accedió a la aplicación con la opción de autenticación. De lo contrario, por configuración predeterminada, se redirecciona al usuario a la página de acceso. También puedes usar `auth_fail_action` para configurar la app a fin de que simplemente rechace las solicitudes de un controlador de usuarios que no estén autenticados de forma correcta, en lugar de redirigir al usuario a la página de inicio de sesión. Nota: La restricción de inicio de sesión `admin` también se cumple con las solicitudes internas para las cuales App Engine establece los encabezados especiales `X-Appengine` apropiados. Por ejemplo, las tareas programadas `cron` satisfacen la restricción `admin`, porque App Engine establece un encabezado HTTP `X-Appengine-Cron: true` en las solicitudes respectivas. Sin embargo, las solicitudes no satisfarían la restricción de inicio de sesión `required` porque las tareas programadas cron no se ejecutan como ningún usuario.
`mime_type`	Opcional. Si se especifica, todos los archivos que entrega el controlador se entregarán mediante el uso del tipo MIME especificado. Si no se especifica, el tipo MIME para un archivo se derivará de la extensión del nombre del archivo. Si el mismo archivo se sube con varias extensiones, la extensión resultante puede depender del orden en que se subieron. Para obtener más información sobre los tipos de medios MIME posibles, consulta el sitio web Tipos de medios MIME de IANA
`redirect_http_response_code`	Opcional. Se usa `redirect_http_response_code` con la configuración `secure` para establecer el código de respuesta HTTP que se muestra cuando se realiza una redirección obligatoria por la configuración de `secure`. El elemento `redirect_http_response_code` puede tener los siguientes valores: `301` Código de respuesta Movido permanentemente. `302` Código de respuesta Encontrado. `303` Código de respuesta Ver otros. `307` Código de respuesta Redireccionamiento temporal. Ejemplo handlers: - url: /youraccount/.* script: accounts.app login: required secure: always redirect_http_response_code: 301 Cuando se redirecciona una solicitud de un usuario, el código de estado HTTP se establecerá en el valor del parámetro `redirect_http_response_code`. Si el parámetro no está presente, se mostrará 302.
`script`	Opcional. Especifica la ruta a la secuencia de comandos desde el directorio raíz de la aplicación: handlers: # The root URL (/) is handled by the WSGI application named # "app" in home.py. No other URLs match this pattern. - url: / script: home.app # The URL /index.html is also handled by the home.py script. - url: /index\.html script: home.app # A regular expression can map parts of the URL to the # path of the script. - url: /browse/(books\|videos\|tools) script: \1.catalog.app # All other URLs use the WSGI application named in "app" # in not_found.py. - url: /.* script: not_found.app Una directiva `script:` debe ser una ruta de importación de Python, por ejemplo `package.module.app`, que apunte a una aplicación WSGI. El último componente de una directiva `script:` que usa una ruta del módulo de Python es el nombre de una variable global en el módulo; esa variable debe ser una app WSGI y, por lo general, se llama `app` por convención. Nota: Al igual que ocurre con una sentencia `import` de Python, cada subdirectorio que es un paquete debe contener un archivo llamado `__init__.py`. En los entornos de ejecución más recientes de App Engine, cambió el comportamiento de este campo.
`secure`	Opcional. Cualquier controlador de URL puede usar la configuración `secure`, incluidos los controladores de secuencia de comandos y de archivos estáticos. El elemento `secure` puede tener los siguientes valores: `optional` Las solicitudes HTTP y HTTPS con URL que coinciden con el controlador se realizan de forma correcta sin redireccionamientos. La aplicación puede examinar la solicitud para determinar qué protocolo se utilizó, y responder según corresponda. Este es el valor predeterminado cuando no se proporciona `secure` para un controlador. `never` Las solicitudes para una URL que coinciden con este controlador y que usan HTTPS se redireccionan de manera automática a la URL HTTP equivalente. Cuando la solicitud HTTPS del usuario se redirecciona para que sea una solicitud HTTP, los parámetros de consulta se quitan de la solicitud. Así se evita que el usuario envíe por accidente datos de consulta a través de una conexión no segura que se diseñó para una conexión segura. `always` Las solicitudes para una URL que coinciden con este controlador y que no usan HTTPS se redireccionan de forma automática a la URL HTTPS con la misma ruta. Los parámetros de consulta se conservan para el redireccionamiento. Ejemplo handlers: - url: /youraccount/.* script: accounts.app login: required secure: always El servidor web de desarrollado no admite conexiones HTTPS. Ignora el parámetro `secure`, por lo que las rutas diseñadas para el uso con HTTPS pueden probarse mediante conexiones HTTP regulares al servidor web de desarrollador. A fin de orientar una versión específica de la app mediante el dominio `REGION_ID.r.appspot.com`, debes reemplazar los puntos que suelen separar los componentes del subdominio de la URL por la string “`-dot-`”, por ejemplo: `https://VERSION_ID-dot-default-dot-PROJECT_ID.REGION_ID.r.appspot.com` Para usar dominios personalizados con HTTPS, primero debes activar y configurar los certificados SSL para ese dominio. El ingreso a las Cuentas de Google y el cierre de sesión siempre se realizan mediante el uso de una conexión segura, no relacionada con la forma en que se configuran las URL de la aplicación.
`static_dir`	Opcional. La ruta al directorio que contiene los archivos estáticos, desde el directorio raíz de la aplicación. Todo después del final del patrón `url` coincidente se agrega a `static_dir` para formar la ruta completa del archivo solicitado. Cada archivo en el directorio estático se entrega mediante un tipo MIME que coincide con la extensión del nombre del archivo, a menos que el ajuste `mime_type` del directorio lo anule. Todos los archivos en el directorio se suben como archivos estáticos y ninguno de ellos puede ejecutarse como secuencias de comandos. Todos los archivos en este directorio se suben con la aplicación como archivos estáticos. App Engine almacena y entrega archivos estáticos separados de los archivos de la aplicación. Los archivos estáticos no están disponibles en la configuración predeterminada del sistema de archivos de la app. Para cambiar esto, establece la opción `application_readable` como verdadera. Ejemplo: handlers: # All URLs beginning with /stylesheets are treated as paths to # static files in the stylesheets/ directory. - url: /stylesheets static_dir: stylesheets # ...
`static_files`	Opcional. Un controlador de patrón de archivo estático asocia un patrón de URL con las rutas a los archivos estáticos subidos con la aplicación. La expresión regular del patrón de URL puede definir agrupaciones de expresiones regulares que se utilizarán en la construcción de la ruta del archivo. Puedes usar esto en lugar de `static_dir` para asignar a archivos específicos en una estructura de directorio sin asignar el directorio completo. Ejemplo: handlers: # All URLs ending in .gif .png or .jpg are treated as paths to # static files in the static/ directory. The URL pattern is a # regular expression, with a grouping that is inserted into the # path to the file. - url: /(.\.(gif\|png\|jpg))$ static_files: static/\1 upload: static/.\.(gif\|png\|jpg)$ # ... App Engine almacena y entrega archivos estáticos separados de los archivos de la aplicación. Los archivos estáticos no están disponibles en la configuración predeterminada del sistema de archivos de la aplicación. Para cambiar esto, establece la opción `application_readable` como verdadera. Los archivos estáticos no pueden ser los mismos que los archivos de código de la aplicación. Si una ruta de archivo estático coincide con una ruta a una secuencia de comandos utilizada en un controlador dinámico, la secuencia de comandos no estará disponible para el controlador dinámico.
`upload`	Opcional. Una expresión regular que coincide con las rutas de los archivos para todos los archivos a los que el controlador hará referencia. Esto es necesario porque el controlador no puede determinar qué archivos en el directorio de la aplicación coinciden con los patrones `url` y `static_files` específicos. Los archivos estáticos se suben y manejan por separado de los archivos de la aplicación. En el ejemplo anterior, se puede usar el siguiente patrón `upload`: `archives/(.)/items/(.)`
`url`	Elemento obligatorio en `handlers`. El patrón de URL, como expresión regular. La expresión puede contener agrupaciones a las que se puede hacer referencia en la ruta del archivo a la secuencia de comandos con referencias inversas de expresiones regulares. Por ejemplo, `/profile/(.)/(.)` coincidiría con la URL `/profile/edit/manager` y usaría `edit` y `manager` como la primera y segunda agrupación. El patrón de URL tiene algunas diferencias en el comportamiento cuando se usa con los siguientes elementos: `static_dir` Usa un prefijo de URL. El patrón de expresión regular no debe contener agrupaciones cuando se usa con el elemento `static_dir`. Este controlador maneja todas las URL que comienzan con este prefijo mediante el uso de la parte de la URL después del prefijo como parte de la ruta del archivo. `static_files` Un controlador de patrón de archivo estático asocia un patrón de URL con las rutas a los archivos estáticos subidos con la aplicación. La expresión regular del patrón de URL puede definir agrupaciones de expresiones regulares que se utilizarán en la creación de la ruta del archivo. Puedes usar esto en lugar de `static_dir` para mapear a archivos específicos en una estructura de directorio sin mapear el directorio completo.

Elementos de escalamiento

Mediante los elementos de la siguiente tabla, se configura el escalamiento de tu aplicación. A fin de obtener más información para escalar las apps de App Engine, consulta Tipos de escalamiento.

Elemento Descripción

Elemento	Descripción
`automatic_scaling`	Opcional. Solo se aplica a las aplicaciones que usan una clase de instancia de F1 o superior. Especifica este elemento a fin de cambiar la configuración predeterminada del ajuste de escala automático, como establecer niveles mínimos y máximos para la cantidad de instancias, la latencia y las conexiones simultáneas de un servicio. Puede contener los siguientes elementos: `max_instances` Opcional. Especifica un valor de entre 0 y 2147483647, en el que cero inhabilita la configuración. Este parámetro especifica el número máximo de instancias que App Engine debe crear para esta versión del módulo. Esto es útil para limitar los costos de un módulo. Importante: Si usas appcfg del SDK de App Engine para Python 2 a fin de realizar una implementación, no puedes usar este parámetro en tu `app.yaml`. En su lugar, debes configurar el parámetro como se describe en Configura parámetros de ajuste de escala automático en el Explorador de API, o puedes usar la API de Administrador de App Engine. `min_instances` Advertencia: Para que esta característica funcione de manera adecuada, debes asegurarte de que las solicitudes de preparación estén habilitadas y de que tu aplicación las controle. Opcional. El número mínimo de instancias que App Engine debe crear para esta versión del módulo. Estas instancias entregan tráfico cuando llegan solicitudes, y continúan entregando tráfico incluso cuando se inician instancias adicionales según sea necesario para manejar el tráfico. Especifica un valor de 0 a 1,000. Puedes configurar el parámetro en el valor 0 para permitir que el escalamiento a 0 instancias reduzca los costos cuando no se entregan solicitudes. Ten en cuenta que se te cobrará por la cantidad de instancias especificadas, ya sea que reciban tráfico o no. Importante: Si usas appcfg del SDK de App Engine para Python 2 a fin de realizar una implementación, no puedes usar este parámetro en tu `app.yaml`. En su lugar, debes configurar el parámetro como se describe en Configura los parámetros de ajuste de escala automático en el Explorador de API, o puedes usar la API de Administrador de App Engine. `max_idle_instances` Opcional. El número máximo de instancias inactivas que App Engine debería conservar para esta versión. Especifica un valor de 1 a 1,000, o `automatic`. El valor predeterminado es `automatic`. Ten en cuenta lo siguiente: Un máximo alto reduce el número de instancias inactivas de manera más gradual cuando los niveles de cargo vuelven a la normalidad después de un pico. Esto ayuda a que la aplicación mantenga un rendimiento constante a través de las fluctuaciones en la carga de solicitud, pero también aumenta el número de instancias inactivas (y los consiguientes costos de ejecución) durante los períodos de carga pesada. Un máximo bajo mantiene los costos de ejecución más bajos, pero puede degradar el rendimiento ante niveles de carga volátiles. Nota: Cuando se vuelve a los valores normales después de un pico de carga, el número de instancias inactivas puede superar de forma temporal el máximo especificado. Sin embargo, no se te cobrarán más instancias que el número máximo que hayas especificado. `min_idle_instances` Advertencia: Para que esta característica funcione de manera adecuada, debes asegurarte de que las solicitudes de preparación estén habilitadas y de que tu aplicación las controle. Opcional: Es el número de instancias adicionales que se seguirán ejecutando y están listas a fin de entregar tráfico para esta versión. App Engine calcula la cantidad de instancias necesarias para entregar el tráfico de la aplicación actual según la configuración de escalamiento, como `target_cpu_utilization` y `target_throughput_utilization`. La configuración de `min_idle_instances` especifica la cantidad de instancias que se ejecutarán además de esta cantidad calculada. Por ejemplo, si App Engine calcula que se necesitan 5 instancias para entregar tráfico y `min_idle_instances` se configura en 2, App Engine ejecutará 7 instancias (5, que se calculan en función de tráfico, más 2 adicionales por `min_idle_instances`). Ten en cuenta que se te cobrará por el número de instancias especificadas, ya sea que reciban tráfico o no. Esta configuración solo se aplica a la versión que recibe la mayor parte del tráfico. Ten en cuenta lo siguiente: Un mínimo bajo ayuda a mantener bajos los costos de ejecución durante los períodos de inactividad, pero significa que hay menos instancias inmediatamente disponibles para responder a un pico de carga repentino. Un mínimo alto te permite preparar la aplicación para picos rápidos en la carga de solicitud. App Engine mantiene el número mínimo de instancias en ejecución para entregar las solicitudes entrantes. Se te cobrará por la cantidad de instancias especificadas, ya sea que controlen solicitudes o no. Si estableces un mínimo de instancias inactivas, la latencia pendiente tendrá menos efecto en el rendimiento de tu aplicación. `target_cpu_utilization` Opcional. Especifica un valor entre 0.5 y 0.95. El valor predeterminado es `0.6`. Este parámetro especifica el límite de uso de la CPU en el que se iniciarán instancias nuevas para manejar el tráfico, lo que te permite balancear el rendimiento y el costo. Los valores más bajos aumentan el rendimiento y el costo, y los valores más altos disminuyen el rendimiento, pero también el costo. Por ejemplo, un valor de 0.7 implica que se iniciarán instancias nuevas cuando el uso de CPU alcance el 70%. Importante: Si usas la herramienta appcfg del SDK de App Engine para Python 2 a fin de realizar una implementación, no puedes usar este parámetro en tu `app.yaml`. En su lugar, debes configurar el parámetro como se describe en Configura parámetros de ajuste de escala automático en el Explorador de API, o puedes usar la API de Administrador de App Engine. `target_throughput_utilization` Opcional. Especifica un valor de 0.5 a 0.95. El valor predeterminado es `0.6`. Se usa con `max_concurrent_requests` para especificar cuándo se inicia una instancia nueva debido a solicitudes simultáneas. Cuando la cantidad de solicitudes simultáneas alcanza un valor igual a `max_concurrent_requests` por `target_throughput_utilization`, el programador intenta iniciar una instancia nueva. Importante: Si usas la herramienta appcfg del SDK de App Engine para Python 2 a fin de realizar una implementación, no puedes usar este parámetro en tu `app.yaml`. En su lugar, debes configurar el parámetro como se describe en Configura los parámetros de ajuste de escala automático en el Explorador de API, o puedes usar la API de Administrador de App Engine. `max_concurrent_requests` Opcional. La cantidad de solicitudes simultáneas que una instancia de ajuste de escala automático puede aceptar antes de que el programador genere una instancia nueva (el valor predeterminado es 10 y el máximo es 80). Se usa con `target_throughput_utilization` para especificar cuándo se inicia una instancia nueva debido a solicitudes simultáneas. Cuando la cantidad de solicitudes simultáneas alcanza un valor igual a `max_concurrent_requests` por `target_throughput_utilization`, el programador intenta iniciar una instancia nueva. Te recomendamos que no configures `max_concurrent_requests` con un valor menor que 10, a menos que necesites un subproceso único. Es probable que un valor inferior a 10 genere más instancias de las que necesitas en una app segura para los subprocesos, lo que puede generar costos innecesarios. Si esta configuración es demasiado alta, es posible que experimentes una mayor latencia de la API. Ten en cuenta que el programador puede generar una instancia nueva antes de que se alcance la cantidad máxima real de solicitudes. `max_pending_latency` La cantidad máxima de tiempo que App Engine debe permitir que una solicitud espere en la lista de pendientes antes de iniciar instancias adicionales para controlar las solicitudes a fin de reducir la latencia pendiente. Cuando se alcanza este límite, es una señal para escalar verticalmente, y se traduce en un aumento en la cantidad de instancias. Un máximo bajo significa que App Engine iniciará instancias nuevas antes para las solicitudes pendientes, lo que mejora el rendimiento, pero aumenta los costos de ejecución. Un máximo alto significa que los usuarios podrían esperar más tiempo hasta que se entreguen las solicitudes (si existen solicitudes pendientes y no hay instancias inactivas para entregarlas), pero la ejecución de tu aplicación costará menos. `min_pending_latency` Un elemento opcional que puedes establecer para especificar el tiempo mínimo que App Engine debe permitir que una solicitud espere en la cola de pendientes antes de iniciar una instancia nueva a fin de controlarla. Especificar un valor puede reducir los costos de ejecución, pero aumenta el tiempo que los usuarios deben esperar para que se entreguen sus solicitudes. En el caso de las apps gratuitas, el valor predeterminado es `500ms`. Para las apps pagadas, el valor predeterminado es `0`. Este elemento funciona junto con el elemento `max_pending_latency` para determinar cuándo App Engine crea instancias nuevas. Si hay solicitudes pendientes en la cola, ocurre lo siguiente: Si hay menos de la `min_pending_latency` que especifiques, App Engine no creará instancias nuevas. Si hay más de la `max_pending_latency`, App Engine intentará crear una instancia nueva. Si el tiempo es uno entre el especificado por `min_pending_latency` y `max_pending_latency`, App Engine intentará volver a usar una instancia existente. Si ninguna instancia puede procesar la solicitud antes de la `max_pending_latency`, App Engine creará una instancia nueva. Ejemplo automatic_scaling: target_cpu_utilization: 0.65 min_instances: 5 max_instances: 100 min_pending_latency: 30ms max_pending_latency: automatic max_concurrent_requests: 50
`basic_scaling`	Las aplicaciones que usan una clase de instancia B1 o superior deben especificar este elemento o `manual_scaling`. Este elemento habilita el ajuste de escala básico de las clases de instancia B1 y superiores, y puede contener los siguientes elementos: `max_instances` Obligatorio. El número máximo de instancias que App Engine debe crear para esta versión de servicio. Esto es útil para limitar los costos de un servicio. `idle_timeout` Opcional. La instancia se desactivará durante este período después de recibir la última solicitud. El valor predeterminado es de 5 minutos (`5m`) Ejemplo basic_scaling: max_instances: 11 idle_timeout: 10m
`manual_scaling`	Las aplicaciones que usan una clase de instancia B1 o superior deben especificar este elemento o `basic_scaling`. Este elemento habilita el ajuste de escala manual de las clases de instancia B1 y superiores, y puede contener el siguiente elemento: `instances` La cantidad de instancias que se deben asignar al servicio en el inicio. Ejemplo manual_scaling: instances: 5

automatic_scaling

Opcional. Solo se aplica a las aplicaciones que usan una clase de instancia de F1 o superior.

Especifica este elemento a fin de cambiar la configuración predeterminada del ajuste de escala automático, como establecer niveles mínimos y máximos para la cantidad de instancias, la latencia y las conexiones simultáneas de un servicio.

Puede contener los siguientes elementos:

max_instances

Opcional. Especifica un valor de entre 0 y 2147483647, en el que cero inhabilita la configuración.

Este parámetro especifica el número máximo de instancias que App Engine debe crear para esta versión del módulo. Esto es útil para limitar los costos de un módulo.

Importante: Si usas appcfg del SDK de App Engine para Python 2 a fin de realizar una implementación, no puedes usar este parámetro en tu app.yaml. En su lugar, debes configurar el parámetro como se describe en Configura parámetros de ajuste de escala automático en el Explorador de API, o puedes usar la API de Administrador de App Engine.

min_instances

Opcional. El número mínimo de instancias que App Engine debe crear para esta versión del módulo. Estas instancias entregan tráfico cuando llegan solicitudes, y continúan entregando tráfico incluso cuando se inician instancias adicionales según sea necesario para manejar el tráfico.

Especifica un valor de 0 a 1,000. Puedes configurar el parámetro en el valor 0 para permitir que el escalamiento a 0 instancias reduzca los costos cuando no se entregan solicitudes. Ten en cuenta que se te cobrará por la cantidad de instancias especificadas, ya sea que reciban tráfico o no.

Importante: Si usas appcfg del SDK de App Engine para Python 2 a fin de realizar una implementación, no puedes usar este parámetro en tu app.yaml. En su lugar, debes configurar el parámetro como se describe en Configura los parámetros de ajuste de escala automático en el Explorador de API, o puedes usar la API de Administrador de App Engine.

max_idle_instances

Opcional. El número máximo de instancias inactivas que App Engine debería conservar para esta versión. Especifica un valor de 1 a 1,000, o automatic. El valor predeterminado es automatic. Ten en cuenta lo siguiente:

Un máximo alto reduce el número de instancias inactivas de manera más gradual cuando los niveles de cargo vuelven a la normalidad después de un pico. Esto ayuda a que la aplicación mantenga un rendimiento constante a través de las fluctuaciones en la carga de solicitud, pero también aumenta el número de instancias inactivas (y los consiguientes costos de ejecución) durante los períodos de carga pesada.
Un máximo bajo mantiene los costos de ejecución más bajos, pero puede degradar el rendimiento ante niveles de carga volátiles.

Nota: Cuando se vuelve a los valores normales después de un pico de carga, el número de instancias inactivas puede superar de forma temporal el máximo especificado. Sin embargo, no se te cobrarán más instancias que el número máximo que hayas especificado.

min_idle_instances

Opcional: Es el número de instancias adicionales que se seguirán ejecutando y están listas a fin de entregar tráfico para esta versión.

App Engine calcula la cantidad de instancias necesarias para entregar el tráfico de la aplicación actual según la configuración de escalamiento, como target_cpu_utilization y target_throughput_utilization. La configuración de min_idle_instances especifica la cantidad de instancias que se ejecutarán además de esta cantidad calculada. Por ejemplo, si App Engine calcula que se necesitan 5 instancias para entregar tráfico y min_idle_instances se configura en 2, App Engine ejecutará 7 instancias (5, que se calculan en función de tráfico, más 2 adicionales por min_idle_instances).

Ten en cuenta que se te cobrará por el número de instancias especificadas, ya sea que reciban tráfico o no. Esta configuración solo se aplica a la versión que recibe la mayor parte del tráfico. Ten en cuenta lo siguiente:

Un mínimo bajo ayuda a mantener bajos los costos de ejecución durante los períodos de inactividad, pero significa que hay menos instancias inmediatamente disponibles para responder a un pico de carga repentino.
Un mínimo alto te permite preparar la aplicación para picos rápidos en la carga de solicitud. App Engine mantiene el número mínimo de instancias en ejecución para entregar las solicitudes entrantes. Se te cobrará por la cantidad de instancias especificadas, ya sea que controlen solicitudes o no.

Si estableces un mínimo de instancias inactivas, la latencia pendiente tendrá menos efecto en el rendimiento de tu aplicación.

target_cpu_utilization

Opcional. Especifica un valor entre 0.5 y 0.95. El valor predeterminado es 0.6.

Este parámetro especifica el límite de uso de la CPU en el que se iniciarán instancias nuevas para manejar el tráfico, lo que te permite balancear el rendimiento y el costo. Los valores más bajos aumentan el rendimiento y el costo, y los valores más altos disminuyen el rendimiento, pero también el costo. Por ejemplo, un valor de 0.7 implica que se iniciarán instancias nuevas cuando el uso de CPU alcance el 70%.

Importante: Si usas la herramienta appcfg del SDK de App Engine para Python 2 a fin de realizar una implementación, no puedes usar este parámetro en tu app.yaml. En su lugar, debes configurar el parámetro como se describe en Configura parámetros de ajuste de escala automático en el Explorador de API, o puedes usar la API de Administrador de App Engine.

target_throughput_utilization

Opcional. Especifica un valor de 0.5 a 0.95. El valor predeterminado es 0.6.

Se usa con max_concurrent_requests para especificar cuándo se inicia una instancia nueva debido a solicitudes simultáneas. Cuando la cantidad de solicitudes simultáneas alcanza un valor igual a max_concurrent_requests por target_throughput_utilization, el programador intenta iniciar una instancia nueva.

Importante: Si usas la herramienta appcfg del SDK de App Engine para Python 2 a fin de realizar una implementación, no puedes usar este parámetro en tu app.yaml. En su lugar, debes configurar el parámetro como se describe en Configura los parámetros de ajuste de escala automático en el Explorador de API, o puedes usar la API de Administrador de App Engine.

max_concurrent_requests

Opcional. La cantidad de solicitudes simultáneas que una instancia de ajuste de escala automático puede aceptar antes de que el programador genere una instancia nueva (el valor predeterminado es 10 y el máximo es 80).

Se usa con target_throughput_utilization para especificar cuándo se inicia una instancia nueva debido a solicitudes simultáneas. Cuando la cantidad de solicitudes simultáneas alcanza un valor igual a max_concurrent_requests por target_throughput_utilization, el programador intenta iniciar una instancia nueva.

Te recomendamos que no configures max_concurrent_requests con un valor menor que 10, a menos que necesites un subproceso único. Es probable que un valor inferior a 10 genere más instancias de las que necesitas en una app segura para los subprocesos, lo que puede generar costos innecesarios.

Si esta configuración es demasiado alta, es posible que experimentes una mayor latencia de la API. Ten en cuenta que el programador puede generar una instancia nueva antes de que se alcance la cantidad máxima real de solicitudes.

max_pending_latency

La cantidad máxima de tiempo que App Engine debe permitir que una solicitud espere en la lista de pendientes antes de iniciar instancias adicionales para controlar las solicitudes a fin de reducir la latencia pendiente. Cuando se alcanza este límite, es una señal para escalar verticalmente, y se traduce en un aumento en la cantidad de instancias.

Un máximo bajo significa que App Engine iniciará instancias nuevas antes para las solicitudes pendientes, lo que mejora el rendimiento, pero aumenta los costos de ejecución.

Un máximo alto significa que los usuarios podrían esperar más tiempo hasta que se entreguen las solicitudes (si existen solicitudes pendientes y no hay instancias inactivas para entregarlas), pero la ejecución de tu aplicación costará menos.

min_pending_latency

Un elemento opcional que puedes establecer para especificar el tiempo mínimo que App Engine debe permitir que una solicitud espere en la cola de pendientes antes de iniciar una instancia nueva a fin de controlarla. Especificar un valor puede reducir los costos de ejecución, pero aumenta el tiempo que los usuarios deben esperar para que se entreguen sus solicitudes.

En el caso de las apps gratuitas, el valor predeterminado es 500ms. Para las apps pagadas, el valor predeterminado es 0.

Este elemento funciona junto con el elemento max_pending_latency para determinar cuándo App Engine crea instancias nuevas. Si hay solicitudes pendientes en la cola, ocurre lo siguiente:

Si hay menos de la min_pending_latency que especifiques, App Engine no creará instancias nuevas.
Si hay más de la max_pending_latency, App Engine intentará crear una instancia nueva.
Si el tiempo es uno entre el especificado por min_pending_latency y max_pending_latency, App Engine intentará volver a usar una instancia existente. Si ninguna instancia puede procesar la solicitud antes de la max_pending_latency, App Engine creará una instancia nueva.

Ejemplo


automatic_scaling:
  target_cpu_utilization: 0.65
  min_instances: 5
  max_instances: 100
  min_pending_latency: 30ms
  max_pending_latency: automatic
  max_concurrent_requests: 50

basic_scaling

Las aplicaciones que usan una clase de instancia B1 o superior deben especificar este elemento o manual_scaling.

Este elemento habilita el ajuste de escala básico de las clases de instancia B1 y superiores, y puede contener los siguientes elementos:

max_instances: Obligatorio. El número máximo de instancias que App Engine debe crear para esta versión de servicio. Esto es útil para limitar los costos de un servicio.
idle_timeout: Opcional. La instancia se desactivará durante este período después de recibir la última solicitud. El valor predeterminado es de 5 minutos (5m)

Ejemplo


basic_scaling:
  max_instances: 11
  idle_timeout: 10m

manual_scaling

Las aplicaciones que usan una clase de instancia B1 o superior deben especificar este elemento o basic_scaling.

Este elemento habilita el ajuste de escala manual de las clases de instancia B1 y superiores, y puede contener el siguiente elemento:

instances: La cantidad de instancias que se deben asignar al servicio en el inicio.

Ejemplo


manual_scaling:
  instances: 5

Referencia de app.yaml

ID de región

Estructura del directorio

Ejemplo

Sintaxis

Entorno de ejecución y elementos de la app

Elemento handlers

Compatibilidad con CORS

Elementos de escalamiento