Referencia de app.yaml

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 solicitudes y los archivos estáticos. El archivo app.yaml también contiene información sobre el código de la aplicación como, por ejemplo, el entorno de ejecución y el último identificador de la versión.

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

Estructura del directorio

Cada servicio debe tener un archivo app.yaml en su directorio raíz. Para obtener más información sobre cómo estructurar servicios múltiples en la aplicación, consulta Cómo estructurar servicios web en App Engine.

Ejemplo

El siguiente es un ejemplo de archivo app.yaml para una aplicación de PHP:

runtime: php55
api_version: 1

handlers:
# Serve images as static resources.
- url: /(.+\.(gif|png|jpg))$
  static_files: \1
  upload: .+\.(gif|png|jpg)$
  application_readable: true

# Serve php scripts.
- url: /(.+\.php)$
  script: \1

En este ejemplo se entregan archivos con extensión gif, png o jpg como recursos estáticos. Los archivos se configuran para ser legibles por el código de la aplicación en el entorno de ejecución.

El ejemplo también entrega todas las secuencias de comandos PHP. Puedes restringir el controlador a secuencias de comandos de nivel raíz mediante la expresión url: /([^/]+\.php). Para las aplicaciones existentes, puede ser útil simular el enrutamiento mod_rewrite$_GET['q'] de Apache.

A continuación, se proporciona un ejemplo más extenso de app.yaml:

runtime: php55
api_version: 1

handlers:
- url: /
  script: home.php

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

- url: /stylesheets
  static_dir: stylesheets

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

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

- url: /.*
  script: not_found.php

Sintaxis

La sintaxis de app.yaml es 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 utilizan la sintaxis de expresión regular extendida POSIX, con exclusión de los elementos y las clases de intercalación. Se admiten referencias inversas a las coincidencias agrupadas (p. ej., \1), al igual que estas extensiones Perl: \w \W \s \S \d \D.

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

Elemento Descripción
application

El enfoque recomendado es quitar el elemento application del archivo app.yaml y, en su lugar, utilizar 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, especifica la marca -A:
    
    appcfg.py update -A [YOUR_PROJECT_ID]

Para obtener más información sobre cómo utilizar estos comandos, consulta Implementa la aplicación.

El ID de aplicación es el ID del proyecto de GCP Console que especificaste cuando creaste la aplicación en Google Cloud Platform Console.

api_version

Obligatorio. La versión de la API en un entorno de ejecución determinado que utiliza la aplicación.

Cuando Google anuncia la compatibilidad con una versión nueva de la API de un entorno de ejecución, la aplicación implementada continuará utilizando la API para la cual se escribió. Para actualizar la aplicación a una versión nueva de la API, debes cambiar este valor y, a continuación, volver a implementar la aplicación en App Engine. Cuando especificas el valor 1, se usa el entorno de ejecución compatible más reciente cada vez que implementas esa aplicación (actualmente ).

En este momento, App Engine tiene una versión del entorno de ejecución php: 1

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, donde las unidades pueden ser d para días, h para horas, m para minutos y s para segundos. Por ejemplo, "4d 5h" establece el vencimiento de la caché dentro de 4 días y 5 horas después de que el archivo se solicita por primera vez. Si se omite, el servidor de producción establece el vencimiento dentro de 10 minutos.

Ejemplo:

runtime: php55
api_version: 1

default_expiration: "4d 5h"

handlers:
  # ...

Para obtener más información, consulta Vencimiento de caché estática.

env_variables

Opcional: Puedes definir variables de entorno en el archivo app.yaml a fin de que estén disponibles para la aplicación.

Las variables de entorno que tienen el prefijo GAE se reservan para uso del sistema y no se admiten en el archivo app.yaml.

Ejemplo:

env_variables:
  MY_VAR: 'my value'
donde MY_VAR y my value son el nombre y el valor de la variable de entorno que deseas definir y cada entrada de variable de entorno tiene una sangría de dos espacios debajo del elemento env_variables.

Puedes recuperar el valor de estas variables con getenv() o $_SERVER, pero no con $_ENV. Los siguientes comandos repiten el valor de la variable de entorno MY_VAR:


echo getenv('MY_VAR');
o

echo $_SERVER['MY_VAR'];
error_handlers

Opcional: Se utiliza para configurar las páginas de error personalizadas que se muestran para los tipos de errores diferentes.

Este elemento puede contener los siguientes componentes:

error_code
Opcional: error_code puede ser uno de los siguientes:
over_quota
Indica que la aplicación ha superado una cuota de recursos.
dos_api_denial
Indica que la configuración de protección contra DoS de la aplicación bloqueó la solicitud.
timeout
Se entrega si se alcanza un plazo antes de que exista una respuesta de la aplicación.

El error_code es opcional; si no se especifica, el archivo dado es la respuesta de error predeterminada para la aplicación.

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, el archivo estático será la página de error predeterminada para la aplicación. Los datos de error personalizados deben ser inferiores 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 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.

Consulta Sintaxis de controladores y subelementos

inbound_services

Opcional: Las aplicaciones deben habilitar esos servicios para poder recibir solicitudes entrantes. Puedes habilitar el servicio para una aplicación de PHP si incluyes una sección inbound_services en el archivo app.yaml.

Se encuentran disponibles los siguientes servicios de entrada:

mail
Permite que la aplicación reciba correos electrónicos.
warmup
Habilita las solicitudes de preparación. Consulta Cómo configurar 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
Valor predeterminado: Se asigna F1 si no especificas una clase de instancia junto con el elemento automatic_scaling.
Ajuste de escala básico y manual
B1, B2, B4, B4_1G, B8
Valor predeterminado: Se asigna B2 si no especificas una clase de instancia junto con el elemento basic_scaling o el elemento manual_scaling.

Nota: Si instance_class se establece en F2 o un nivel superior, puedes optimizar las instancias; para ello, establece max_concurrent_requests en un valor superior a 10, que es el valor predeterminado. Para encontrar el valor óptimo, auméntalo de manera gradual y supervisa el rendimiento de tu aplicación.

module

Nota: Los módulos ahora se denominan servicios.

Para administrar la app con la herramienta de gcloud, utiliza el elemento servicio en su lugar.

Para utilizar la herramienta appcfg, los servicios deben declararse en los archivos app.yaml como módulos, por ejemplo:


module: service-name

Es obligatorio si se crea un servicio. Es opcional para el servicio default. Cada servicio y cada versión deben tener un nombre. Un nombre puede contener números, letras y guiones. La longitud combinada del servicio y la versión 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 utilizar nombres entre servicios y versiones.

runtime

Obligatorio. El nombre del entorno de ejecución que usa tu app. Para especificar PHP, usa la información siguiente:


runtime: php55
service

Los servicios antes se llamaban módulos.

Solo son compatibles con la herramienta de gcloud o con complementos basados en el SDK de Cloud, por ejemplo: gcloud app deploy.

Para usar la herramienta appcfg, consulta módulo.

Es obligatorio si se crea un servicio. Es opcional para el servicio default. Cada servicio y cada versión deben tener un nombre. Un nombre puede contener números, letras y guiones. La longitud combinada del servicio y la versión 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 utilizar nombres entre servicios y versiones.

Ejemplo:

service: service-name

Nota: El comando de gcloud app deploy es compatible con versiones anteriores y admite archivos app.yaml existentes que incluyan servicios declarados como módulos, por ejemplo:


module: service-name
skip_files

Opcional: El elemento skip_files especifica qué archivos en el directorio de la aplicación no se subirán en App Engine. El valor es 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 siguiente valor predeterminado:


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

El patrón predeterminado excluye los archivos de copia de seguridad Emacs con nombres que tienen la forma #...# y ...~, archivos .pyc y .pyo, archivos en un directorio de control de revisión RCS y archivos ocultos Unix con nombres que comienzan con un punto (.).

Para ampliar la lista de expresiones regulares mencionada arriba, copia y pega la lista anterior en app.yaml y agrega tus propias expresiones regulares. Por ejemplo, para omitir archivos cuyos nombres terminan en .bak además de los patrones predeterminados, agrega 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 esta línea a las anteriores:


skip_files:
- logs/
version

El método recomendado es quitar 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 usar el comando appcfg.py update, especifica la marca -V:
    
    appcfg.py update -V [YOUR_VERSION_ID]

Para obtener más información sobre cómo utilizar estos comandos, consulta Implementa la aplicación.

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- y los nombres default y latest están reservados y no pueden utilizarse.

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. Esto evita la ambigüedad con las URL como 123.my-service.appspot.com, que pueden interpretarse de dos maneras: si existe la versión “123”, el objetivo será la versión “123” del servicio específico. Si esa versión no existe, el objetivo será el número de instancia 123 de la versión predeterminada del servicio.

Cada versión de una aplicación conserva su propia copia de app.yaml. Cuando se carga una aplicación, la versión mencionada en el archivo app.yaml que se está subiendo es la versión que se crea o reemplaza con la carga. Un administrador puede cambiar la versión de la aplicación que entrega el tráfico mediante Google Cloud Platform Console y también puede probar otras versiones antes de configurarlas para recibir tráfico.

Elemento de los controladores

El elemento handlers es un elemento obligatorio en el archivo de configuración app.yaml. El elemento proporciona 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.

Los patrones se evalúan en el orden en que aparecen en el archivo app.yaml, de arriba abajo. El primer mapeo cuyo patrón coincide con la URL es el que se utiliza para manejar la solicitud.

En la siguiente lista, 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 otras configuraciones.

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

Opcional: Describe la acción realizada cuando se especifica el elemento login para un controlador y el usuario no ha accedido. Tiene dos valores posibles:

redirect
Valor predeterminado. Se redirecciona al usuario a la página de acceso de Google, o /_ah/login_required si se utiliza la autenticación de OpenID. Se redirecciona nuevamente al usuario a la URL de la aplicación después de acceder a la cuenta o crear una cuenta.
unauthorized
La solicitud se rechaza con un código de estado HTTP 401 y un mensaje de error.

Si una aplicación necesita un comportamiento diferente, la aplicación puede implementar el manejo de los accesos de los usuarios. Consulta API de usuarios para obtener más información.

El siguiente ejemplo requiere acceso para el directorio /profile/ y acceso de administrador para el directorio /admin/:


handlers:

- url: /profile/.*
  script: user_profile.php
  login: required

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

- url: /.*
  script: welcome.php

Puedes configurar un controlador para rechazar el acceso a las URL protegidas cuando el usuario no ha accedido, 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.php
  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, donde las unidades pueden ser d para días, h para horas, m para minutos y s para segundos. Por ejemplo, "4d 5h" establece el vencimiento de la caché dentro de 4 días y 5 horas después de que el archivo se solicita por primera vez. Si se omite, se utiliza el default_expiration de la aplicación. Consulta Vencimiento de caché estática para obtener más información.
http_headers

Opcional: Puedes configurar los encabezados HTTP para las respuestas del archivo estático o los controladores de directorio. Si necesitas configurar los encabezados HTTP en los controladores script, debes hacerlo en el código de la aplicación.

Ejemplo

handlers:
- url: /images
  static_dir: static/images
  http_headers:
    X-Foo-Header: foo
    X-Bar-Header: bar value
  # ...

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 aplicación de App Engine.

Por ejemplo, podrías tener una aplicación de juegos mygame.appspot.com que acceda a los activos que myassets.appspot.com aloja. Sin embargo, si mygame intenta hacer un XMLHttpRequest de JavaScript para myassets, no podrá hacerlo, a menos que el controlador para myassets muestre un encabezado de respuesta Access-Control-Allow-Origin: que contenga el valor http://mygame.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: http://mygame.appspot.com
  # ...

Nota: Si deseas permitir que todos accedan a los activos, puedes utilizar el comodín '*', en lugar de http://mygame.appspot.com.

login

Opcional: Determina si el controlador de URL requiere que el usuario haya ingresado. Este elemento tiene tres valores posibles:

optional
Valor predeterminado. No requiere que el usuario haya ingresado.
required
Si el usuario ha ingresado, el controlador procede normalmente. De lo contrario, se realiza la acción que determina auth_fail_action.
admin
Como ocurre con required, se realiza la acción de 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, sin importar la configuración de auth_fail_action. Si el usuario es un administrador, el controlador continúa.

Cuando un controlador de URL con una configuración de 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, mediante la configuración predeterminada, se redirecciona al usuario a la página de acceso. También puedes usar auth_fail_action para configurar la app de forma que rechace las solicitudes de un controlador provenientes de usuarios que no están autenticados de manera correcta, en lugar de redireccionarlos a la página de acceso.

Nota: La restricción de acceso admin también se cumple para las solicitudes internas para las que App Engine establece encabezados especiales X-Appengine adecuados. Por ejemplo, las tareas programadas cron cumplen con la restricción admin porque App Engine establece un encabezado HTTP X-AppEngine-Cron: true en las solicitudes respectivas. Sin embargo, las solicitudes no cumplen con la restricción de acceso required, ya que las tareas cron programadas no se ejecutan de parte de 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. redirect_http_response_code se utiliza con el ajuste secure para configurar el código de respuesta HTTP que se muestra cuando se realiza un redireccionamiento que se requiere por cómo se configura el ajuste secure. El elemento redirect_http_response_code tiene los siguientes valores posibles:

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.php
  secure: always
  redirect_http_response_code: 301

Cuando se redirecciona la solicitud de un usuario, el código de estado HTTP se configurará 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:
- url: /profile/(.*)/(.*)
  script: /employee/\2/\1.php  # specify a script
secure Opcional: Cualquier controlador de URL puede utilizar el ajuste secure, esto incluye los controladores de secuencias de comandos y los controladores de archivos estáticos. El elemento secure tiene los siguientes valores posibles:
optional
Las solicitudes HTTP y HTTPS con las URL que coinciden con el controlador funcionan 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 utilizan HTTPS se redireccionan automáticamente a la URL equivalente de HTTP. Cuando la solicitud HTTPS del usuario se redirecciona para que sea una solicitud HTTP, los parámetros de consulta se quitan de la solicitud. Esto evita que el usuario envíe accidentalmente 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 utilizan HTTPS se redireccionan automáticamente a la URL de HTTPS con la misma ruta. Los parámetros de consulta se conservan para el redireccionamiento.
Ejemplo

handlers:
- url: /youraccount/.*
  script: accounts.php
  secure: always

El servidor web de desarrollador 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.

Para orientar una versión específica de tu aplicación con el dominio appspot.com, reemplaza los puntos que normalmente superarían los componentes del subdominio de la URL por la string "-dot-", como en el ejemplo siguiente:


https://[VERSION_ID]-dot-[YOUR_PROJECT_ID].appspot.com

Para utilizar 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 al 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 realice la anulación. Todos los archivos en el directorio específico 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 aplicación. Para cambiar esto, configura 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 utilizar esto en lugar de static_dir para mapear a archivos específicos en una estructura de directorio sin mapear 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 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, configura 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 separados de los archivos de la aplicación. El ejemplo anterior podría usar el siguiente patrón de 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 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 la segunda agrupación.

El patrón de URL tiene algunas diferencias de comportamiento cuando se utiliza con los siguientes elementos:

static_dir
Utiliza un prefijo de URL. El patrón de expresión regular no debe contener agrupaciones cuando se utiliza con el elemento static_dir. Este controlador maneja todas las URL que comienzan con este prefijo; para ello, utiliza 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 construcción de la ruta del archivo. Puedes utilizar esto en lugar de static_dir para mapear a archivos específicos en una estructura de directorio sin mapear todo el directorio.

Elementos de escalamiento

Para obtener más información sobre cómo escalar las aplicaciones de App Engine, consulta Cómo escalar instancias dinámicas.

En la tabla siguiente, se enumeran las opciones para definir cómo debe escalar tu aplicación.

Elemento Descripción
automatic_scaling

Opcional: El ajuste de escala automático se supone por defecto con una clase de instancia predeterminada de F1, a menos que se especifique lo contrario.

El elemento automatic_scaling configura niveles mínimos y máximos para el número de instancias, latencia y conexiones simultáneas de un servicio.

Este elemento puede contener los siguientes componentes:

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 CPU en el que se iniciarán instancias nuevas para manejar el tráfico, lo que te permite balancear entre rendimiento y costo, con valores más bajos que aumentan el rendimiento y el costo, y valores más altos que disminuyen el rendimiento, pero también el costo. Por ejemplo, un valor de 0.7 significa que se iniciarán instancias nuevas cuando el uso de CPU alcance el 70%.

Importante: Si usas appcfg del SDK de App Engine para PHP con el fin de realizar la implementación, no puedes usar este parámetro en tu archivo app.yaml. En su lugar, configura 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.

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

Se utiliza 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 multiplicado por target_throughput_utilization, el programador inicia una instancia nueva.

Importante: Si usas appcfg del SDK de App Engine para PHP con el fin de realizar la implementación, no puedes usar este parámetro en tu archivo app.yaml. En su lugar, configura 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_instances
Opcional: Especifica un valor entre 0 y 2147483647, donde 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 PHP con el fin de realizar la implementación, no puedes usar este parámetro en tu archivo app.yaml. En su lugar, configura 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.

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 el número de instancias especificadas, ya sea que reciban tráfico o no.

Importante: Si usas appcfg del SDK de App Engine para PHP con el fin de realizar la implementación, no puedes usar este parámetro en tu archivo app.yaml. En su lugar, configura 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: El número de solicitudes simultáneas que puede aceptar una instancia con ajuste de escala automático antes de que el programador genere una instancia nueva (valor predeterminado: 5; valor máximo: 80).

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

Es posible que experimentes una mayor latencia de API si esta configuración es demasiado alta. Ten en cuenta que el programador puede generar una instancia nueva antes de que se alcance el número máximo real de solicitudes.

Nota: Si instance_class se establece en F2 o en un nivel superior, puedes optimizar las instancias; para ello, establece max_concurrent_requests en un valor superior a 10, que es el valor predeterminado. Para encontrar el valor óptimo, auméntalo de manera gradual y supervisa el rendimiento de tu aplicación.

max_idle_instances

Opcional: El número máximo de instancias inactivas que App Engine debería mantener para esta versión. Especifica un valor de 1 a 1000, 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 temporalmente el máximo especificado. Sin embargo, no se te cobrarán más instancias que el número máximo que hayas especificado.

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 manejar las solicitudes a fin de reducir la latencia pendiente. Cuando se alcanza este límite, es una señal para aumentar la escala, y se traduce en un aumento en el número de instancias. El valor predeterminado es 30ms.

App Engine puede crear una instancia en cualquier momento entre el tiempo especificado en min_pending_latency y max_pending_latency. En otras palabras, App Engine no creará una instancia para entregar una solicitud pendiente antes del tiempo especificado en min_pending_latency, pero App Engine creará una instancia después de que se alcance max_pending_latency.

  • 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 pueden esperar más tiempo para que se entreguen las solicitudes (si existen solicitudes pendientes y no hay instancias inactivas para entregarlas), pero la aplicación tardará menos en ejecutarse.
min_idle_instances

El número de instancias que se mantendrán en funcionamiento y listas para entregar el tráfico. 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 el número de instancias especificadas, ya sea que manejen solicitudes o no. Para que esta característica funcione de manera adecuada, debes asegurarte de que las solicitudes de preparación estén habilitadas y de que la aplicación maneje las solicitudes de preparación.

    Si configuras un número mínimo de instancias inactivas, la latencia pendiente tendrá menos efecto en el rendimiento de la aplicación. Debido a que App Engine mantiene las instancias inactivas en reserva, es poco probable que las solicitudes ingresen en la lista de pendientes, excepto en picos de carga excepcionalmente altos. Tendrás que probar la aplicación y el volumen de tráfico esperado para determinar el número ideal de instancias para mantener en reserva.

min_pending_latency

La cantidad mínima de tiempo que App Engine debe permitir que una solicitud espere en la lista de pendientes antes de iniciar una instancia nueva para entregarla. Cuando se alcanza este límite, es una señal para reducir la escala, y se traduce en una disminución en el número de instancias. El valor predeterminado es 30ms.

  • Un mínimo bajo significa que las solicitudes deben pasar menos tiempo en la lista de pendientes cuando todas las instancias existentes están activas. Esto mejora el rendimiento, pero aumenta el costo de ejecución de la aplicación.
  • Un mínimo alto significa que las solicitudes permanecerán pendientes por más tiempo si todas las instancias existentes están activas. Esto reduce los costos de ejecución, pero aumenta el tiempo que los usuarios deben esperar para que se entreguen sus solicitudes.
Ejemplo

service: my_service
runtime: php55
instance_class: F2
automatic_scaling:
  target_cpu_utilization: 0.65
  min_instances: 5
  max_instances: 100
  min_pending_latency: 30ms  # default value
  max_pending_latency: automatic
basic_scaling

Opcional: El elemento basic_scaling configura el número de instancias para un servicio.

Este elemento puede contener los siguientes componentes:

idle_timeout
Opcional: La instancia se cerrará durante este período después de recibir la última solicitud. El valor predeterminado es 5 minutos (5m).
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.
Ejemplo

service: my_service
runtime: php55
instance_class: B8
basic_scaling:
  max_instances: 11
  idle_timeout: 10m
manual_scaling

Opcional: El elemento manual_scaling habilita el escalamiento manual para un servicio y configura el número de instancias para un servicio.

Este elemento puede contener los siguientes componentes:

instances
El número de instancias a asignar al servicio en el inicio.
Ejemplo

service: my_service
runtime: php55
instance_class: B8
manual_scaling:
  instances: 5

Vencimiento de la caché estática

A menos que se indique lo contrario, los proxies y los navegadores web retienen los archivos que suben de un sitio web durante un período limitado.

Puedes definir un período de caché predeterminado global para todos los controladores de archivos estáticos de una aplicación mediante la inclusión del elemento de nivel superior default_expiration. También puedes configurar la duración de una caché para controladores de archivos estáticos específicos.

El tiempo de vencimiento se enviará en los encabezados de respuesta HTTP Cache-Control y Expires y, por lo tanto, es probable que el navegador del usuario almacene en caché los archivos, además de los servidores proxy de almacenamiento en caché como, por ejemplo, los proveedores de servicios de Internet. Después de que un archivo se transmite con un tiempo de vencimiento determinado, generalmente no hay forma de borrarlo de las memorias caché intermedias, incluso si el usuario borra su propia caché del navegador. Volver a implementar una versión nueva de la aplicación no restablecerá ninguna caché. Por lo tanto, si alguna vez planeas modificar un archivo estático, debe tener un tiempo de vencimiento corto (menos de una hora). En la mayoría de los casos, el tiempo de vencimiento predeterminado de 10 minutos es adecuado.

¿Te ha resultado útil esta página? Enviar comentarios:

Enviar comentarios sobre...

Entorno estándar de App Engine para PHP 5