Referencia de app.yaml de App Engine

ID de región

El REGION_ID es un código abreviado que Google asigna en función de la región que selecciones al crear tu aplicación. El código no corresponde a un país o provincia, aunque algunos IDs de región pueden parecerse a los códigos de país y provincia que se usan habitualmente. En las aplicaciones creadas después de febrero del 2020, REGION_ID.r se incluye en las URLs de App Engine. En las aplicaciones creadas antes de esa fecha, el ID de región es opcional en la URL.

Más información sobre los IDs de región

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

Cada servicio de tu aplicación tiene su propio archivo app.yaml, que actúa como descriptor de su implementación. Primero debes crear el archivo app.yaml para el servicio default antes de poder crear e implementar archivos app.yaml para otros servicios de tu aplicación.

Estructura de directorios

Para obtener más información sobre cómo estructurar varios servicios en tu aplicación, consulta el artículo Estructurar los 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, lo que significa que la secuencia de comandos usa WSGI.

Sintaxis

La sintaxis de app.yaml es el formato YAML.

El formato YAML admite comentarios. Se ignora una línea que empieza por el carácter almohadilla (#):

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

Tiempo de ejecución y elementos de la aplicación

Elemento Descripción
application

Lo más recomendable es 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 la aplicación:

  • Para usar el comando gcloud app deploy, debes especificar la marca --project: 
    gcloud app deploy --project [YOUR_PROJECT_ID]

Para obtener más información sobre cómo usar estos comandos, consulta Implementar tu aplicación.

El ID de la aplicación es el Google Cloud ID del proyecto de la consola que especificaste al crear la aplicación en la Google Cloud console.

api_version

Obligatorio. La versión de la API del entorno de ejecución determinado que usa tu aplicación.

Este campo está obsoleto en los entornos de ejecución más recientes de App Engine.

Cuando Google anuncie la compatibilidad con una nueva versión de la API de un entorno de ejecución, tu aplicación desplegada seguirá usando la versión para la que se escribió. Para actualizar tu aplicación a una nueva versión de la API, cambia este valor y vuelve a implementar la aplicación en App Engine. Si especifica el valor 1 , se usará el entorno de ejecución compatible más reciente cada vez que despliegue esa aplicación (actualmente, ).

Por el momento, App Engine tiene una versión del python27entorno de ejecución1:

auto_id_policy Opcional. Si configura los identificadores de entidad automáticamente, puede cambiar el método que se utiliza configurando la política de ID automático. Estas son las opciones válidas:
default
Predeterminado. Usa IDs automáticos dispersos que son números enteros grandes y bien distribuidos, pero lo suficientemente pequeños como para representarse con números de coma flotante de 64 bits.
legacy
La opción antigua dejará de estar disponible en una versión futura y se eliminará. Para obtener más información, consulta la entrada de blog en la que se anuncia este cambio.
builtins

Opcional. El SDK de Python 2 incluye varios controladores integrados para funciones de aplicaciones comunes. La directiva builtins te permite incluir controladores específicos en app.yaml.

Este campo ya no está disponible en el entorno de ejecución de Python 3.

Puedes usar los siguientes controladores integrados:

appstats
Habilita Appstats en /_ah/stats/, que puedes usar para medir el rendimiento de tu aplicación. Para usar Appstats, también debes instalar el registrador de eventos.
deferred
Habilita el controlador diferido en /_ah/queue/deferred. Esta función integrada permite a los desarrolladores usar deferred.defer() para simplificar la creación de tareas de la cola de tareas.
remote_api
Habilita el remote_api integrado 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. Cada directiva builtin es equivalente, en Python, a una directiva includes con una ruta ampliada. Por ejemplo: 

builtins:
- name: on

Equivale a:

includes:
- $PYTHON_LIB/google/appengine/ext/builtins/name/

Cuando usas builtins en tu archivo app.yaml, los controladores definidos en el archivo include.yaml integrado sustituirán a los que definas en tu archivo app.yaml. Sin embargo, si incluyes un archivo que usa builtins o includes, los controladores se añaden por orden de la jerarquía de inclusión. En otras palabras, los controladores de la inclusión "parent" se añaden antes que los elementos integrados de la inclusión "child", y así sucesivamente.

Por ejemplo, considere el siguiente app.yaml, que usa los controladores appstats integrados: 

handlers:
- url: /.*
  script: main.app
builtins:
- appstats: on

La lista de controladores resultante es la siguiente:

[/_ah/stats, /.*]

Si el app.yaml usa una directiva includes: 

includes:
- included.yaml

El archivo included.yaml usa builtins: 

handlers:
- url: /.*
  script: main.app
builtins:
- appstats: on

La lista de controladores resultante es ahora la siguiente: 

[/.*, /_ah/stats]

El orden de colocación de la cláusula builtins en un archivo .yaml no cambia el comportamiento.

default_expiration

Opcional. Define un periodo de caché predeterminado global para todos los controladores de archivos estáticos de una aplicación. También puedes configurar una duración de la caché para controladores de archivos estáticos específicos. El valor es una cadena de números y unidades, separados por espacios, donde las unidades pueden ser d para días, h para horas, m para minutos y s para segundos. Por ejemplo, "4d 5h" establece la caducidad de la caché en 4 días y 5 horas después de que se solicite el archivo por primera vez. Si se omite, el servidor de producción establece la caducidad en 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 para que estén disponibles en tu aplicación. Asegúrate de que la clave de las variables de entorno coincida con la expresión "[a-zA-Z_][a-zA-Z0-9_]*" (empieza por una letra o "_" seguida de cualquier carácter alfanumérico o "_").

Las variables de entorno que tienen el prefijo GAE están reservadas para el uso del sistema y no se permiten 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 usa para configurar páginas de error personalizadas que se devuelven para diferentes tipos de error.

Este elemento puede contener los siguientes elementos:

error_code
Opcional. El elemento error_code puede ser uno de los siguientes:
over_quota
Indica que la aplicación ha superado una cuota de recursos
timeout
Se publica si se alcanza una fecha límite antes de que tu aplicación envíe una respuesta.

El código de error es opcional. Si no se especifica, el archivo proporcionado es la respuesta de error predeterminada de tu aplicación.

file
Cada entrada de archivo indica un archivo estático que se debe servir en lugar de la respuesta de error genérica. Si especifica un elemento file sin el elemento error_code correspondiente, el archivo estático será la página de error predeterminada de su aplicación. Los datos de error personalizados deben tener un tamaño inferior a 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 sobre cómo se deben procesar. App Engine puede gestionar URLs ejecutando código de aplicación o sirviendo archivos estáticos subidos con el código, como imágenes, CSS o JavaScript.

Consulta la sintaxis de los controladores y los subelementos.

includes

Opcional. La directiva includes te permite incluir el archivo de configuración de cualquier biblioteca o servicio en toda tu 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 orden siguiente:

  • Ruta de acceso absoluta o relativa al directorio de trabajo. La ruta especificada se resuelve en un archivo.
  • En relación con el directorio de la aplicación, también conocido como ruta base. La ruta base y la ruta se resuelven en un archivo.
  • Ruta de acceso 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, App Engine busca en ese directorio un archivo llamado include.yaml. Si la directiva include es un archivo, se incluye ese archivo específico. Si se usa includes, solo se recuperan los siguientes tipos de directivas del archivo de destino (si están presentes):

Los patrones skip_files incluidos se añaden a los de app.yaml, o a la lista predeterminada si no hay ninguna lista explícita en app.yaml. Ten en cuenta que skip_files compara rutas absolutas.

inbound_services

Opcional. Las aplicaciones deben habilitar esos servicios para poder recibir solicitudes entrantes. Puedes habilitar el servicio en una aplicación de Python 2 incluyendo una sección inbound_services en el archivo app.yaml.

Existen los siguientes servicios de entrada:

mail
Permite que tu aplicación reciba correo.
warmup
Habilita las solicitudes de preparación. Consulta Configurar solicitudes de preparación.
Ejemplo: 
inbound_services:
  - mail
  - warmup
instance_class

Opcional. La clase de instancia de este servicio.

Están disponibles los siguientes valores en función del escalado de tu servicio:

Escalado automático
F1, F2, F4, F4_1G
Predeterminado: F1

También puedes usar el elemento automatic_scaling para cambiar los ajustes predeterminados del escalado automático, como el número mínimo y máximo de instancias, la latencia y las conexiones simultáneas.

Nota: Si instance_class tiene el valor F2 o superior, puede optimizar sus instancias definiendo max_concurrent_requests con un valor superior al valor predeterminado de 10. Para determinar el valor óptimo, auméntalo gradualmente y monitoriza el rendimiento de tu aplicación.

Escalado básico y manual
B1, B2, B4, B4_1G, B8
Predeterminado: B2

Las clases de instancia 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 están disponibles de forma predeterminada, mientras que otras solo se pueden usar si se configuran. Puedes especificar la versión que quieras usar indicando los valores name y version.

Este campo ya no está disponible 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 más reciente de la biblioteca en el momento de la implementación. Una vez desplegada, la versión de la biblioteca no cambiará. La única forma de obtener una versión diferente de la biblioteca es volver a implementarla.

Si estás desarrollando una aplicación que aún no tiene usuarios, no es necesario que monitorices las versiones nuevas. Sin embargo, si tu aplicación se está usando activamente, ten cuidado: puede que te sorprenda que tu aplicación empiece a usar una nueva versión de la biblioteca que no es compatible con versiones anteriores.

Para ver una lista de las bibliotecas de terceros incluidas, consulta Bibliotecas de terceros. Puedes usar bibliotecas de terceros adicionales de Python puro instalándolas en un directorio local.

Si usas el entorno flexible, consulta Usar bibliotecas de Python en el entorno flexible.

module

Nota: Los módulos ahora se llaman "Servicios".

Para gestionar tu aplicación con gcloud CLI, usa el elemento service.

runtime

Obligatorio. El nombre del entorno de ejecución que usa tu aplicación. Por ejemplo, para especificar Python 2.7, usa lo siguiente: 

runtime: python27
service

Antes, los servicios se llamaban módulos.

Solo se admite en la CLI de gcloud o en los complementos basados en la CLI de gcloud. Por ejemplo, gcloud app deploy .

Obligatorio si se crea un servicio. Opcional para el servicio default. Cada servicio y cada versión deben tener un nombre. El nombre puede contener números, letras y guiones. 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 el ID de tu proyecto, no puede superar los 63 caracteres ni empezar o terminar con un guion. Elige un nombre único para cada servicio y cada versión. No reutilices 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 que incluyan servicios declarados como módulos. Por ejemplo: 

module: service-name
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 usa al acceder a otros Google Cloud servicios y ejecutar tareas.

Ejemplo: 
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 omitirá de la lista de archivos que se van a subir cuando se suba la aplicación. Los nombres de archivo dependen del directorio del proyecto.

skip_files tiene el siguiente valor predeterminado: 

skip_files:
- ^(.*/)?#.*#$
- ^(.*/)?.*~$
- ^(.*/)?.*\.py[co]$
- ^(.*/)?.*/RCS/.*$
- ^(.*/)?\..*$

El patrón predeterminado excluye los archivos de copia de seguridad de Emacs con nombres del tipo #...# y ...~, .pyc y .pyo, los archivos de un directorio de control de versiones RCS y los archivos ocultos de Unix con nombres que empiezan por un punto (.).

Para ampliar la lista de expresiones regulares anterior, copia y pega la lista anterior en tu app.yaml y añade tus propias expresiones regulares. Por ejemplo, para omitir los archivos cuyos nombres terminen en .bak además de los patrones predeterminados, añade una entrada como esta para skip_files: 

skip_files:
- ^(.*/)?#.*#$
- ^(.*/)?.*~$
- ^(.*/)?.*\.py[co]$
- ^(.*/)?.*/RCS/.*$
- ^(.*/)?\..*$
- ^(.*/)?.*\.bak$

Para omitir un directorio completo, añade el nombre del directorio a la lista. Por ejemplo, para omitir un directorio llamado logs, añade la siguiente línea a las que se han descrito anteriormente: 

skip_files:
- logs/
threadsafe

Obligatorio. Configura tu aplicación para que use solicitudes simultáneas. Si usas la biblioteca de threading de Python, los datos locales del hilo, tal como los devuelve threading.local(), se borran después de cada solicitud.

Este campo ya no está disponible 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 secuencias de comandos sean WSGI. Es decir, cada secuencia de comandos debe especificarse en una directiva script: a mediante una ruta de 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 el service:. Esa variable debe ser una aplicación WSGI y, por convención, suele llamarse app.

version

Lo más recomendable es eliminar el elemento version de tu archivo app.yaml y, en su lugar, usar una marca de línea de comandos para especificar tu ID de versión:

  • Para usar el comando gcloud app deploy, especifica la marca -v: 
    gcloud app deploy -v [YOUR_VERSION_ID]

Para obtener más información sobre cómo usar este comando, consulta el artículo Implementar tu aplicación.

Identificador de la versión del código de la aplicación que despliega en App Engine.

El ID de versión puede contener letras minúsculas, dígitos y guiones. No puede empezar por el prefijo ah-. Los nombres default y latest están reservados y no se pueden usar.

Nota: Los nombres de las versiones deben empezar por una letra para distinguirlos de las instancias numéricas, que siempre se especifican con un número. De esta forma, se evita la ambigüedad con URLs como 123-dot-my-service.uc.r.appspot.com, que se pueden interpretar de dos formas: si existe la versión "123", el destino será la versión "123" del servicio en cuestión. 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 se crea o se sustituye con la subida. Un administrador puede cambiar la versión de la aplicación que está sirviendo tráfico mediante el comando Google Cloud consoley también puede probar otras versiones antes de configurarlas para que reciban tráfico.

vpc_access_connector

Opcional. Configura tu aplicación para que use un conector de acceso a VPC sin servidor, lo que permite que la aplicación envíe solicitudes a recursos internos de tu red de VPC. Para obtener más información, consulta Conectarse a una red VPC.

name
Literal de cadena. Especifica el nombre completo de tu conector de acceso a VPC sin servidor entre comillas: 
"projects/PROJECT_ID/locations/REGION/connectors/CONNECTOR_NAME"
egress_setting
Opcional. El valor predeterminado es private-ranges-only. El elemento egress_setting puede ser uno de los siguientes:
private-ranges-only
Predeterminado. Las solicitudes a direcciones IP internas se envían a través del conector de Acceso a VPC sin servidor a la red de VPC conectada. Las solicitudes a direcciones IP externas se envían a Internet público.
all-traffic
Todas las solicitudes se envían a través del conector de Acceso a VPC sin servidor a la red de VPC conectada.
Ejemplo 
vpc_access_connector:
  name: "projects/PROJECT_ID/locations/REGION/connectors/CONNECTOR_NAME"
  egress_setting: all-traffic

Elemento Handlers

El elemento handlers es obligatorio en el archivo de configuración app.yaml. El elemento proporciona una lista de patrones de URL y descripciones de cómo deben gestionarse. App Engine puede gestionar URLs ejecutando código de aplicación o sirviendo 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. Se usa la primera asignación cuyo patrón coincida con la URL para gestionar la solicitud.

En la siguiente tabla se enumeran los subelementos del elemento handlers que controlan el comportamiento de las secuencias de comandos, los archivos estáticos, los directorios estáticos y otros ajustes.

Elemento Descripción
application_readable Opcional. Booleano. De forma predeterminada, los archivos declarados en los controladores de archivos estáticos se suben como datos estáticos y solo se sirven a los usuarios finales. Las aplicaciones no pueden leerlas. Si este campo tiene el valor true, los archivos también se suben como datos de código para que tu aplicación pueda leerlos. Ambas subidas se contabilizan en las cuotas de recursos de almacenamiento de datos estáticos y de código.

Este campo está obsoleto en los entornos de ejecución más recientes de App Engine.
expiration Opcional. El tiempo que un archivo estático servido por este controlador debe almacenarse en caché por proxies web y navegadores. El valor es una cadena de números y unidades separados por espacios. Las unidades pueden ser d (días), h (horas), m (minutos) y s (segundos). Por ejemplo, "4d 5h" define la caducidad de la caché en 4 días y 5 horas después de que se solicite el archivo por primera vez. Si se omite, se usará el de la aplicación. default_expiration. Consulta más información sobre la caducidad de la caché.
http_headers

Opcional. Puedes definir encabezados HTTP para las respuestas de tus controladores de archivos estáticos o de directorios. Si necesitas definir encabezados HTTP en tus controladores script, debes hacerlo en el código de tu aplicación. Para obtener información sobre qué encabezados de respuesta influyen en el almacenamiento en caché, consulta Almacenamiento en caché de 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

Uno de los usos importantes de esta función es admitir el uso compartido de recursos entre dominios (CORS), como acceder a archivos alojados en otra aplicación de App Engine.

Por ejemplo, puedes tener una aplicación de juego mygame.uc.r.appspot.com que acceda a recursos alojados en myassets.uc.r.appspot.com. Sin embargo, si mygame intenta hacer una llamada de JavaScript XMLHttpRequest a myassets, no se completará a menos que el controlador de myassets devuelva un encabezado de respuesta Access-Control-Allow-Origin: que contenga el valor http://mygame.uc.r.appspot.com.

A continuación, se explica cómo hacer que el controlador de archivos estáticos devuelva ese valor de encabezado de respuesta obligatorio: 

handlers:
- url: /images
  static_dir: static/images
  http_headers:
    Access-Control-Allow-Origin: https://mygame.uc.r.appspot.com
  # ...

Nota: Si quieres permitir que todos los usuarios accedan a tus recursos, puedes usar el comodín '*' en lugar de https://mygame.uc.r.appspot.com.

mime_type

Opcional. Si se especifica, todos los archivos que sirva este controlador se servirán con el tipo MIME especificado. Si no se especifica, el tipo MIME de un archivo se derivará de la extensión del nombre de archivo. Si se sube el mismo archivo con varias extensiones, la extensión resultante puede depender del orden en el que se hayan subido los archivos.

Para obtener más información sobre los tipos de medios MIME posibles, consulta el sitio web de tipos de medios MIME de IANA.

redirect_http_response_code

Opcional. redirect_http_response_code se usa con el ajuste secure para definir el código de respuesta HTTP que se devuelve al realizar una redirección necesaria según la configuración del ajuste secure. El elemento redirect_http_response_code puede tener los siguientes valores:

301
Código de respuesta
Movido permanentemente.
302
Se ha encontrado el código de respuesta.
303
Consulta el código de respuesta See Other.
307
Código de respuesta de redirección temporal.
Ejemplo 
handlers:
- url: /youraccount/.*
  script: accounts.app
  login: required
  secure: always
  redirect_http_response_code: 301

Cuando se redirige la solicitud de un usuario, el código de estado HTTP se asignará al valor del parámetro redirect_http_response_code. Si el parámetro no está presente, se devolverá 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 apunta a una aplicación WSGI. El último componente de una directiva script: que usa una ruta de módulo de Python es el nombre de una variable global del módulo. Esta variable debe ser una aplicación WSGI y, por convención, suele llamarse app.

Nota: Al igual que en el caso de una instrucción import de Python, cada subdirectorio que sea un paquete debe contener un archivo llamado __init__.py.

En los entornos de ejecución más recientes de App Engine, el el comportamiento de este campo ha cambiado.
secure Opcional. Cualquier controlador de URLs puede usar el ajuste secure, incluidos los controladores de secuencias de comandos y los controladores de archivos estáticos. El elemento secure puede tener los siguientes valores:
optional
Las solicitudes HTTP y HTTPS con URLs que coincidan con el controlador se completarán sin redirecciones. La aplicación puede examinar la solicitud para determinar qué protocolo se ha usado y responder en consecuencia. Este es el valor predeterminado cuando no se proporciona secure para un controlador.
never
Las solicitudes de una URL que coincida con este controlador y que use HTTPS se redirigen automáticamente a la URL HTTP equivalente. Cuando la solicitud HTTPS de un usuario se redirige para que sea una solicitud HTTP, los parámetros de consulta se eliminan de la solicitud. De esta forma, se evita que un usuario envíe por error datos de consulta a través de una conexión no segura que estaba destinada a una conexión segura.
always
Las solicitudes de una URL que coincida con este controlador y que no use HTTPS se redirigen automáticamente a la URL HTTPS con la misma ruta. Los parámetros de consulta se conservan en la redirección.
Ejemplo 
handlers:
- url: /youraccount/.*
  script: accounts.app
  login: required
  secure: always

El servidor web de desarrollo no admite las conexiones HTTPS. Ignora el parámetro secure, por lo que las rutas diseñadas para usarse con HTTPS se pueden probar mediante conexiones HTTP normales al servidor web de desarrollo.

Para orientar sus anuncios a una versión específica de su aplicación mediante el REGION_ID.r.appspot.com dominio, sustituya los puntos que suelen separar los componentes del subdominio de la URL por la cadena "-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 certificados SSL para ese dominio.

El inicio y el cierre de sesión de las cuentas de Google siempre se realizan mediante una conexión segura, independientemente de cómo se configuren las URLs de la aplicación.

static_dir

Opcional. Ruta al directorio que contiene los archivos estáticos, desde el directorio raíz de la aplicación. Todo lo que haya después del final del patrón url coincidente se añade a static_dir para formar la ruta completa al archivo solicitado.

Cada archivo del directorio estático se sirve con el tipo MIME que corresponde a la extensión de su nombre de archivo, a menos que se anule con el ajuste mime_type del directorio. Todos los archivos del directorio indicado se suben como archivos estáticos y ninguno de ellos se puede ejecutar como secuencia de comandos.

Todos los archivos de este directorio se suben con tu aplicación como archivos estáticos. App Engine almacena y sirve archivos estáticos por separado de los archivos de tu aplicación. Los archivos estáticos no están disponibles en el sistema de archivos de la aplicación de forma predeterminada. Para cambiarlo, define la opción application_readable como true.

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 patrones de archivos estáticos asocia un patrón de URL con rutas a 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 utilicen en la creación de la ruta del archivo. Puedes usarlo en lugar de static_dir para asignar archivos específicos de una estructura de directorios sin asignar todo el directorio.

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 sirve archivos estáticos por separado de los archivos de la aplicación. Los archivos estáticos no están disponibles en el sistema de archivos de la aplicación de forma predeterminada. Para cambiarlo, define la opción application_readable como true.

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ática coincide con la ruta de 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 coincida con las rutas de archivo de todos los archivos a los que hará referencia este controlador. Esto es necesario porque el controlador no puede determinar qué archivos del directorio de tu aplicación corresponden a los patrones url y static_files. Los archivos estáticos se suben y se gestionan por separado de los archivos de la aplicación. En el ejemplo anterior, se podría usar el siguiente patrón upload: archives/(.*)/items/(.*)

url

Elemento obligatorio en handlers. El patrón de URL, como una expresión regular. La expresión puede contener agrupaciones a las que se puede hacer referencia en la ruta de archivo de 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 primer y segundo grupo, respectivamente.

El patrón de URL tiene algunas diferencias de 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 utilice con el elemento static_dir. Todas las URLs que empiecen por este prefijo se gestionarán con este controlador, usando la parte de la URL que va después del prefijo como parte de la ruta del archivo.
static_files
Un controlador de patrones de archivos estáticos asocia un patrón de URL con rutas a 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 usarán en la creación de la ruta del archivo. Puedes usarlo en lugar de static_dir para asignar archivos específicos de una estructura de directorios sin asignar todo el directorio.

Escalar elementos

Los elementos de la siguiente tabla configuran cómo se escala tu aplicación. Para obtener más información sobre cómo se escalan las aplicaciones de App Engine, consulta Tipos de escalado.

Elemento Descripción
automatic_scaling

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

Especifica este elemento para cambiar la configuración predeterminada del escalado automático, como los niveles mínimo y máximo del número de instancias, la latencia y las conexiones simultáneas de un servicio.

Este elemento puede contener los siguientes elementos:

max_instances
Opcional. Especifica un valor entre 0 y 2147483647. Si es cero, se inhabilita el ajuste.

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

min_instances
Opcional. El número mínimo de instancias que App Engine debe crear para esta versión del módulo. Estas instancias sirven tráfico cuando llegan solicitudes y siguen sirviendo tráfico incluso cuando se inician instancias adicionales según sea necesario para gestionar el tráfico.

Especifica un valor entre 0 y 1000. Puede asignar el valor 0 al parámetro para permitir que se escale a 0 instancias y, de este modo, reducir los costes cuando no se sirvan solicitudes. Ten en cuenta que se te cobrará por el número de instancias especificadas, independientemente de si reciben tráfico o no.

max_idle_instances

Opcional. El número máximo de instancias inactivas que App Engine debe mantener para esta versión. Especifica un valor entre 1 y 1000. Si no se especifica ningún valor, se utiliza automatic de forma predeterminada, lo que significa que App Engine gestionará el número de instancias inactivas. Ten en cuenta lo siguiente:

  • Un valor máximo alto reduce el número de instancias inactivas de forma más gradual cuando los niveles de carga vuelven a la normalidad después de un pico. De esta forma, tu aplicación mantiene un rendimiento constante durante las fluctuaciones de la carga de solicitudes, pero también aumenta el número de instancias inactivas (y los costes de ejecución correspondientes) durante esos periodos de carga elevada.
  • Si el máximo es bajo, los costes de funcionamiento serán menores, pero el rendimiento puede verse afectado si los niveles de carga son volátiles.

Nota: Cuando se vuelve a los niveles normales después de un pico de carga, el número de instancias inactivas puede superar temporalmente 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: Número de instancias adicionales que se mantendrán en ejecución y listas para servir tráfico para esta versión.

App Engine calcula el número de instancias necesarias para gestionar el tráfico actual de tu aplicación en función de los ajustes de escalado, como target_cpu_utilization y target_throughput_utilization. El ajuste min_idle_instances especifica el número de instancias que se van a ejecutar además del número calculado. Por ejemplo, si App Engine calcula que se necesitan 5 instancias para atender el tráfico y min_idle_instances se define como 2, App Engine ejecutará 7 instancias (5, calculadas en función del tráfico, más 2 adicionales por min_idle_instances).

Ten en cuenta que se te cobrará por el número de instancias especificadas, independientemente de si reciben tráfico o no. Ten en cuenta lo siguiente:

  • Un mínimo bajo ayuda a mantener bajos los costes de funcionamiento durante los periodos de inactividad, pero significa que es posible que haya menos instancias disponibles de inmediato 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 solicitudes. App Engine mantiene en ejecución el número mínimo de instancias para atender las solicitudes entrantes. Se te cobra por el número de instancias especificadas, independientemente de si gestionan solicitudes o no.

    Si defines un número mínimo de instancias inactivas, la latencia pendiente afectará menos al 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 umbral de uso de la CPU en el que se iniciarán nuevas instancias para gestionar el tráfico, lo que te permite encontrar el equilibrio entre el rendimiento y el coste. Los valores más bajos aumentan el rendimiento y el coste, mientras que los valores más altos disminuyen el rendimiento y el coste. Por ejemplo, un valor de 0,7 significa que las nuevas instancias se iniciarán cuando el uso de la CPU alcance el 70 %.

target_throughput_utilization
Opcional. Especifica un valor entre 0,5 y 0,95. El valor predeterminado es 0.6.

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

max_concurrent_requests

Opcional. Número de solicitudes simultáneas que puede aceptar una instancia de escalado automático antes de que el programador genere una nueva instancia (valor predeterminado: 10; valor máximo: 1000).

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

Te recomendamos que no definas max_concurrent_requests en un valor inferior a 10 a menos que necesites un solo subproceso. Si el valor es inferior a 10, es probable que se creen más instancias de las que necesitas para una aplicación segura para subprocesos, lo que puede generar costes innecesarios.

Si este ajuste es demasiado alto, es posible que la latencia de la API aumente. Ten en cuenta que el programador puede generar una nueva instancia antes de que se alcance el número máximo real de solicitudes.

max_pending_latency

Tiempo máximo que debe permitir App Engine que espere una solicitud en la cola pendiente antes de iniciar instancias adicionales para gestionar las solicitudes, de forma que se reduzca la latencia pendiente. Cuando se alcanza este umbral, se envía una señal para aumentar la escala, lo que provoca un incremento en el número de instancias. Si no se especifica ningún valor, se utiliza automatic de forma predeterminada. Esto significa que las solicitudes pueden permanecer en la cola pendiente hasta 10 segundos, el límite de tiempo de solicitud pendiente máximo, antes de que se activen los nuevos inicios de instancia.

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

Si el valor máximo es alto, es posible que los usuarios tengan que esperar más para que se atiendan sus solicitudes (si hay solicitudes pendientes y no hay instancias inactivas para atenderlas), pero el coste de ejecutar la aplicación será menor.

min_pending_latency

Elemento opcional que puedes definir para especificar el tiempo mínimo que debe esperar una solicitud en la cola pendiente antes de iniciar una nueva instancia para gestionarla. Si especifica un valor, puede reducir los costes de ejecución, pero aumentará el tiempo que los usuarios deben esperar para que se atiendan sus solicitudes.

En el caso de las aplicaciones gratuitas, el valor predeterminado es 500ms. En el caso de las aplicaciones de pago, el valor predeterminado es 0.

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

  • Si es inferior al valor min_pending_latency que especifiques, App Engine no creará instancias nuevas.
  • Si se supera este límite, App Engine intentará crear una instancia.max_pending_latency
  • Entre la hora especificada por min_pending_latency y max_pending_latency, App Engine intentará reutilizar una instancia. Si ninguna instancia puede procesar la solicitud antes de max_pending_latency, App Engine creará una nueva instancia.
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 usen una clase instance de B1 o una versión posterior deben especificar este elemento o manual_scaling.

Este elemento permite el escalado 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 puede crear para esta versión del servicio. Esto resulta útil para limitar los costes de un servicio.
idle_timeout
Opcional. La instancia se cerrará al cabo de este tiempo después de recibir su última solicitud. El valor predeterminado es 5 minutos (5m).
Ejemplo 
basic_scaling:
  max_instances: 11
  idle_timeout: 10m
manual_scaling

Las aplicaciones que usen una clase instance de B1 o una versión posterior deben especificar este elemento o basic_scaling.

Este elemento permite escalar manualmente las clases de instancia B1 y superiores, y puede contener el siguiente elemento:

instances
Número de instancias que se asignarán al servicio al inicio.
Ejemplo 
manual_scaling:
  instances: 5