Python 2 ya no es compatible con la comunidad. Recomendamos que migres las apps de Python 2 a Python 3.

Cómo se enrutan las solicitudes

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 tu app. El código no corresponde a un país o provincia, aunque algunos ID de región puedan parecer similares a los códigos de país y provincia de uso común. La inclusión de REGION_ID.r en las URL de App Engine es opcional para las aplicaciones existentes y pronto será obligatoria para todas las aplicaciones nuevas.

A fin de garantizar una transición sin problemas, estamos actualizando App Engine con lentitud 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 para las apps existentes, no necesitas actualizar las URL ni realizar otros cambios una vez que el ID de región esté disponible para las apps existentes.

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

En esta página, se detalla cómo las solicitudes HTTP de los usuarios llegan a la versión correcta de un servicio. Las solicitudes se pueden enrutar de las siguientes maneras:

Si pruebas la aplicación con el servidor de desarrollo local, las funciones de enrutamiento y despacho son ligeramente diferentes. Para crear URL de manera programática que funcionen con los servidores de producción y de desarrollo, usa el método get_hostname.

Consulta enrutar en el servidor de desarrollo para obtener más información.

Enrutamiento con URL

Una vez que tu app se esté ejecutando en App Engine, puedes usar la siguiente URL para enviar solicitudes HTTP a la app:
https://PROJECT_ID.REGION_ID.r.appspot.com

en la que PROJECT_ID es el ID del proyecto de Google Cloud que contiene la app.

Esta URL envía solicitudes al servicio predeterminado de tu app en la versión que configuraste para recibir tráfico.

URL para servicios y versiones

Si creas más de un servicio en tu app, cada servicio tiene su propia URL. Cada versión de un servicio también tiene su propia URL. Esto te permite implementar y probar una versión nueva antes de configurarla para recibir tráfico.

Las URL de servicios y versiones específicos tienen el siguiente formato:

VERSION-dot-SERVICE-dot-PROJECT_ID.REGION_ID.r.appspot.com

Puedes omitir VERSION-dot- si no necesitas orientar a una versión específica.

Para recuperar los ID de los servicios y las versiones de la aplicación, puedes usar cualquiera de las siguientes herramientas:

Console

En Cloud Console, puedes ver las páginas Instancias, Servicios y Versiones correspondientes.

gcloud

Ejecuta el comando gcloud app instances list para ver la lista de los ID de recursos de un proyecto de Cloud específico.

API

Para recuperar los ID de recursos de manera programática, consulta los métodos list en la API de Administrador.

URL de ejemplo

Estos son algunos ejemplos de URL para App Engine que muestran el dominio appspot.com que App Engine asigna a tu aplicación y un dominio personalizado que puedes configurar para tu aplicación.

  • Envía la solicitud a una instancia disponible del servicio default:
    
    https://PROJECT_ID.REGION_ID.r.appspot.com
    https://CUSTOM_DOMAIN

    Cualquier versión que esté configurada para el tráfico en el servicio default recibe las solicitudes.

  • Envía una solicitud a una instancia disponible de un servicio específico:
    
    https://SERVICE_ID-dot-PROJECT_ID.REGION_ID.r.appspot.com
    https://SERVICE_ID.CUSTOM_DOMAIN

    Cualquier versión que esté configurada para el tráfico en el servicio orientado recibe las solicitudes. Si el servicio no existe, la solicitud se realiza mediante el enrutamiento secundario.

  • Envía una solicitud a una instancia disponible de una versión específica en el
    servicio default:
    
    https://VERSION_ID-dot-default-dot-PROJECT_ID.REGION_ID.r.appspot.com
    https://VERSION_ID.CUSTOM_DOMAIN

    Cuando un servicio no está orientado, las solicitudes se envían al servicio default.

Enrutamiento secundario

Si una solicitud coincide con la parte PROJECT_ID.REGION_ID.r.appspot.com del nombre de host, pero incluye el nombre de un servicio, de una versión o de una instancia que no existe, se enruta al servicio default. El enrutamiento secundario no se aplica a dominios personalizados; las solicitudes enviadas a estos dominios mostrarán un código de estado HTTP 404 si el nombre de host no es válido.

Enrutamiento dirigido

Se garantiza que los siguientes patrones de URL alcanzarán sus objetivos, si existen. Los patrones que defines en el archivo de envío nunca interceptan ni vuelven a enrutar estas solicitudes:

  • Envía la solicitud a una instancia disponible de un servicio y de una versión específicos:
    
    https://VERSION_ID-dot-SERVICE_ID-dot-PROJECT_ID.REGION_ID.r.appspot.com
    https://VERSION_ID.SERVICE_ID.PROJECT_ID.CUSTOM_DOMAIN
  • Si usas servicios escalados de forma manual, puedes orientar y enviar una solicitud a una instancia si incluyes el ID de esta. El ID de instancia es un número entero entre 0 y la cantidad total de instancias que se ejecutan, y puede especificarse de la siguiente manera:

    Envía una solicitud a un servicio y una versión específicos dentro de una instancia determinada:

    https://INSTANCE_ID-dot-VERSION_ID-dot-SERVICE_ID-dot-PROJECT_ID.REGION_ID.r.appspot.com
    https://INSTANCE_ID.VERSION_ID.SERVICE_ID.CUSTOM_DOMAIN

Enruta con un archivo de envío

Puedes crear un archivo de envío para anular las reglas de enrutamiento basadas en URL de App Engine y definir tus propias reglas de enrutamiento personalizadas. Mediante un archivo de envío, puedes enviar las solicitudes con contenido nuevo a un servicio específico de acuerdo con el nombre de la ruta o del host en la URL de la solicitud.

Crea un archivo de envío

Para crear un archivo de envío, sigue estos pasos:

  1. Crea un archivo llamado dispatch.yaml en la raíz del directorio de tu proyecto o en el directorio raíz del servicio default.

  2. Define las reglas de enrutamiento en el archivo como se describe en la referencia de dispatch.yaml.

Ten en cuenta lo siguiente sobre las reglas de enrutamiento:

  • Puedes definir hasta 20 reglas de enrutamiento. Cada regla debe contener los elementos url y service.
  • Las reglas deben usar patrones de URL HTTP que incluyan la notación "." para separar los subdominios. Las URL definidas con la notación “-dot-” de HTTPS no son compatibles.
  • Las reglas también se aplican a las URL que defines en tu archivo cron.

Por ejemplo, puedes crear un archivo de envío para enrutar solicitudes móviles, como https://simple-sample.uc.r.appspot.com/mobile/, a un frontend móvil y enrutar solicitudes de trabajador, como https://simple-sample.uc.r.appspot.com/work/, a un backend estático:

dispatch:
  # Send all mobile traffic to the mobile frontend.
  - url: "*/mobile/*"
    service: mobile-frontend

  # Send all work to the one static backend.
  - url: "*/work/*"
    service: static-backend

Implementa el archivo de envío

Para implementar el archivo de envío, ejecute el siguiente comando:

    gcloud app deploy dispatch.yaml

Enrutamiento con Cloud Load Balancing

Cloud Load Balancing es un producto separado que habilita las configuraciones de red avanzadas para todas tus aplicaciones que se ejecutan en Google Cloud.

Cuando el balanceo de cargas HTTP(S) está habilitado para apps sin servidores, puedes hacer lo siguiente:

  • Configura tu app sin servidores para entregar desde una dirección IP IPv4 o IPv6 dedicada que no se comparta con otros servicios.

  • Vuelve a usar los mismos certificados SSL y claves privadas que usas para Compute Engine, Google Kubernetes Engine y Cloud Storage. Esto elimina la necesidad de administrar certificados separados para las aplicaciones sin servidores.

El balanceador de cargas no interfiere ni interactúa con las reglas de enrutamiento en tu archivo dispatch.yaml. Las reglas dispatch.yaml no se evalúan hasta que un NEG sin servidores dirige el tráfico a App Engine.

Ten en cuenta la siguiente limitación:

  • No puedes inhabilitar las URL que Google Cloud asigna automáticamente a los servicios de App Engine. Los usuarios que ya tienen la URL predeterminada del servicio de App Engine pueden omitir el balanceador de cargas y dirigirse directamente a la URL del servicio. Esto significa que, aunque puedes configurar políticas de seguridad, certificados SSL y claves privadas de Google Cloud Armor, los usuarios con la URL predeterminada pueden eludir estas políticas.

Enrutamiento en el servidor de desarrollo

Cómo detectar direcciones de instancias

En el servidor de desarrollo local se crean todas las instancias de ajuste de escala manual en el inicio. Las instancias para los servicios de ajuste de escala automático y básico se administran de manera dinámica. El servidor asigna un puerto a cada servicio y los clientes pueden confiar en el servidor para balancear la carga y seleccionar una instancia de manera automática. Las asignaciones de puerto para direccionar cada servicio aparecen en el flujo de mensajes de registro del servidor. Estos son los puertos para una aplicación que define tres servicios (el tipo de ajuste de escala de cada servicio no es relevante):

INFO Starting module "default" running at: http://localhost:8084
INFO Starting module "service1" running at: http://localhost:8082
INFO Starting module "service2" running at: http://localhost:8083

Cuando usas la dirección de un servicio (por ejemplo, http://localhost:8082/), el servidor seleccionará (o creará) una instancia del servicio y enviará la solicitud a esa instancia.

El servidor asigna puertos únicos a cada instancia de un servicio. Para detectar estos puertos, necesitas usar el servidor de administrador. Existe un puerto único para el servidor de administrador que aparece en el registro de mensajes:

INFO Starting admin server at: http://localhost:8000

Esta dirección te lleva a la consola del servidor de administrador. Desde allí, puedes hacer clic en Instancias para ver el estado dinámico de las instancias de tu aplicación:

Captura de pantalla de la Consola del administrador de dev_appserver

Aparecerá una entrada independiente para cada instancia manual y básica. Los números de instancia son vínculos con direcciones de puerto únicas para cada instancia. Puedes desplazarte sobre un vínculo a fin de ver el puerto asignado a esa instancia o hacer clic en el vínculo para enviar una solicitud directo a esa instancia.

Archivos de envío

Si tu app incluye un archivo dispatch.yaml, la transmisión de mensajes de registro incluirá un puerto de despachador:

INFO Starting dispatcher running at: http://localhost:8080

Las solicitudes a este puerto se enrutan según las reglas del archivo de envío. El servidor no admite reglas del archivo dispatch.yaml que incluyan nombres de host (por ejemplo, url: "customer1.myapp.com/*"). Las reglas con patrones de rutas relativas (url: "*/fun") funcionarán, por lo que puedes usar URL como http://localhost/fun/mobile para llegar a las instancias. El servidor mostrará un error en la transmisión de registro si intentas iniciar una aplicación con un archivo dispatch.yaml que contenga reglas basadas en el host.

Restringe el acceso a un servicio

Todos los servicios son públicos de forma predeterminada. Si deseas restringir el acceso a un servicio, agrega el elemento login: admin a sus controladores.

Detalles adicionales sobre las URL de App Engine

Información sobre el ID de región en las URL

REGION_ID es un código abreviado que Google asigna en función de la región que seleccionas cuando creas tu app. El código no corresponde a un país o provincia, aunque algunos ID de región puedan parecer similares a los códigos de país y provincia de uso común. La inclusión de REGION_ID.r en las URL de App Engine es opcional para las aplicaciones existentes y pronto será obligatoria para todas las aplicaciones nuevas.

A fin de garantizar una transición sin problemas, estamos actualizando App Engine con lentitud 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 para las apps existentes, no necesitas actualizar las URL ni realizar otros cambios una vez que el ID de región esté disponible para las apps existentes.

Puedes usar las siguientes herramientas para ver el ID de región de tu app:

Console

En Cloud Console, puedes ver las URL para las Instancias, Servicios y Versiones de tu app.

Todas estas URL incluyen el ID de la región.

gcloud

Cuando implementas una app o un servicio, el comando de gcloud app deploy muestra la URL una vez que la implementación se realiza correctamente. Esta URL incluye el ID de la región.

Para ver la URL de un servicio que ya está implementado, haz lo siguiente:

  1. Ingresa el comando gcloud app versions list para ver una lista de las versiones de un servicio específico. Por ejemplo, para ver las versiones del servicio predeterminado, ingresa gcloud app versions list --service=default.

  2. Ingresa el comando de gcloud app versions describe. El resultado de ese comando incluye la URL de la versión con el ID de región de la app. Por ejemplo, para describir la versión 20191023t101741 del servicio predeterminado, ingresa gcloud app versions describe 20191023t101741 --service=default

El nombre de dominio se incluye en los datos de la solicitud

El nombre de dominio que se usa para la solicitud se incluye en los datos de la solicitud que se transmiten a la aplicación. Por lo tanto, puedes usar esos datos para controlar el modo en que la aplicación responde según el nombre de dominio en la solicitud. Por ejemplo, si deseas realizar un redireccionamiento a un dominio oficial, puedes codificar la aplicación para que verifique el encabezado de la solicitud Host y responda de manera acorde según el nombre de dominio.