Nota: Python 2.7 alcanzó el fin de la asistencia el 31 de enero de 2024. Tus aplicaciones existentes de Python 2.7 seguirán ejecutándose y recibiendo tráfico. Sin embargo, App Engine podría bloquear la reimplementación de aplicaciones que usan entornos de ejecución después de la fecha de finalización de la asistencia. Te recomendamos que migres a la última versión compatible de Python.

Entorno de ejecución de Python 2

Con App Engine, puedes compilar aplicaciones web mediante el uso del lenguaje de programación Python y aprovechar las distintas bibliotecas, herramientas y marcos de trabajo para Python que usan los desarrolladores profesionales para compilar aplicaciones de primer nivel. Tu aplicación de Python se ejecuta en la infraestructura escalable de Google, y usa servicios y almacenamiento continuo a gran escala.

Introducción

App Engine ejecuta el código de la aplicación Python mediante un intérprete de Python precargado en un entorno seguro "de zona de pruebas". Tu aplicación recibe solicitudes web, ejecuta trabajo y envía respuestas mediante la interacción con este entorno.

Una aplicación web de Python interactúa con el servidor web de App Engine mediante el protocolo WSGI, por lo que las aplicaciones pueden utilizar cualquier marco de trabajo de aplicación web compatible con WSGI. App Engine incluye un marco de trabajo de aplicación web simple, llamado webapp2, para facilitar el inicio. Para aplicaciones más grandes, los frameworks de terceros maduros, como Django, funcionan bien con App Engine.

El intérprete de Python puede ejecutar cualquier código de Python, incluidos los módulos de Python que incluyes con tu aplicación, así como la biblioteca estándar de Python. El intérprete no puede cargar módulos de Python con código C; es un entorno Python "puro".

El entorno seguro de "zona de pruebas" aísla la aplicación para servicio y seguridad. Este entorno se asegura de que las aplicaciones solo puedan realizar acciones que no interfieran en el rendimiento y la escalabilidad de otras aplicaciones. Por ejemplo, una aplicación no puede escribir datos en el sistema de archivos local o realizar conexiones de red arbitrarias. En su lugar, las aplicaciones usan servicios escalables prestados por App Engine para almacenar datos y comunicarse por Internet. El intérprete de Python genera una excepción cuando una aplicación intenta importar un módulo de Python desde la biblioteca estándar que se sabe que no funciona dentro de las restricciones de la zona de pruebas.

La plataforma de App Engine brinda una gran cantidad de servicios a los que tu código puede llamar. Tu aplicación también puede configurar tareas programadas que se ejecutan en intervalos específicos.

Selecciona el entorno de ejecución de Python 2

Debes especificar el entorno de ejecución de Python en el archivo de configuración app.yaml, que se usa para implementar la aplicación en App Engine. Por ejemplo, debes agregar la siguiente información al archivo app.yaml para usar la versión 2.7 de Python:

runtime: python27
api_version: 1
threadsafe: true
...

El primer elemento, runtime, selecciona el entorno de ejecución de Python.

El segundo elemento, api_version, selecciona qué versión del entorno de ejecución de Python se usará. En el momento en que se escribió este documento, App Engine solo tiene una versión del entorno de Python, la 1. Si, en algún momento, el equipo de App Engine necesita lanzar cambios en el entorno que pueden no ser compatibles con el código existente, lo harán con un nuevo identificador de versión. La app seguirá usando la versión seleccionada hasta que cambies la configuración de api_version y subas tu app.

Para obtener más información sobre el archivo app.yaml y cómo implementar la app en App Engine, consulta los temas Referencia de app.yaml, Migra a Python 2.7 e Implementa una app de Python.

Zona de pruebas

La aplicación se ejecuta en un entorno de “zona de pruebas” restringido con el objetivo de permitir que App Engine distribuya solicitudes para aplicaciones en varios servidores web y evitar que una aplicación interfiera en otra. En este entorno, la aplicación puede ejecutar el código, almacenar y consultar datos en Datastore, y usar el servicio de recuperación de URL, los servicios de usuario y el correo electrónico de App Engine. También puede examinar la solicitud web del usuario y preparar la respuesta.

Una aplicación de App Engine no puede hacer lo siguiente:

Escribir en el sistema de archivos: Las aplicaciones deben usar Datastore para almacenar datos persistentes. Leer desde el sistema de archivos está permitido, y todos los archivos de la aplicación subidos con esta están disponibles.
responder lentamente. Una solicitud web a una aplicación debe manejarse en cuestión de segundos. Los procesos que tardan mucho tiempo en responder se finalizan para evitar una sobrecarga del servidor web.
hacer otro tipo de llamadas del sistema.

Zonas de pruebas en Python

Puedes subir y usar archivos .pyc cuando usas el entorno de ejecución de Python 2.7, pero no puedes subir una versión .py y una .pyc del mismo archivo. Puedes subir archivos ZIP que contengan archivos .py o .pyc (o una combinación de estos). Ten en cuenta las siguientes advertencias importantes si subes archivos .pyc:

Para una secuencia de comandos de CGI, el controlador de secuencia de comandos debe seguir usando la extensión de archivo .py, incluso si subes un archivo .pyc.
De forma predeterminada, se omiten los archivos .pyc durante la implementación. Debes anular el elemento skip_files en el archivo app.yaml para que el nuevo valor no haga que se omitan los archivos .pyc.
Debes usar Python 2.7 para compilar el archivo .pyc. Si tienes una versión diferente de Python (como Python 2.6) en tu máquina de desarrollo, deberás obtener la versión 2.7 para compilar un archivo .pyc compatible.

Python 2 puro

Todo el código para el entorno de ejecución de Python debe ser Python puro, sin ninguna extensión de C o de otro código que deba compilarse.

El entorno incluye la biblioteca estándar de Python. Algunos módulos se inhabilitaron dado que sus funciones principales no son compatibles con App Engine, como las herramientas de redes o la escritura en el sistema de archivos. Además, el módulo os está disponible, pero con las funciones que no son compatibles inhabilitadas. Un intento de importar un módulo no compatible o usar una función no compatible generará una excepción.

Se ha reemplazado o personalizado algunos módulos de la biblioteca estándar para que funcionen con App Engine. Estos módulos varían entre los dos entornos de ejecución de Python, como se describe a continuación.

Bibliotecas personalizadas en Python versión 2.7

En el entorno de ejecución de Python versión 2.7, se reemplazaron o personalizaron los siguientes módulos:

tempfile está inhabilitado, a excepción de TemporaryFile, que tiene un alias para StringIO.
Logging está disponible y su uso es altamente recomendado. Consulta Registro.

Además de la biblioteca estándar de Python y las bibliotecas de App Engine, el entorno de ejecución de la versión 2.7 de Python incluye varias bibliotecas de terceros.

Agregar bibliotecas de Python de terceros

Puedes incluir bibliotecas de Python de terceros con tu aplicación a través del código en el directorio de tu aplicación. Si creas un vínculo simbólico al directorio de una biblioteca en el directorio de tu aplicación, ese vínculo se seguirá, y la biblioteca se incluirá en la app que implementes en App Engine.

La ruta de acceso de inclusión del módulo de Python incluye el directorio raíz de tu aplicación, que es el directorio que contiene el archivo app.yaml. Los módulos de Python que creas en el directorio raíz de tu aplicación están disponibles mediante una ruta desde la raíz. No olvides crear los archivos __init__.py requeridos en los subdirectorios para que Python reconozca los subdirectorios como paquetes. También asegúrate de que tus bibliotecas no necesiten extensiones C.

Subprocesos

Los subprocesos se pueden crear en la versión 2.7 de Python mediante los módulos thread o threading. Ten en cuenta que los subprocesos se unirán con el entorno de ejecución cuando finalice la solicitud, por lo que no se pueden ejecutar luego de la finalización de la solicitud.

Subprocesos en segundo plano

El código que se ejecuta en una instancia con ajuste de escala manual o básico puede iniciar un subproceso en segundo plano que puede sobrevivir a la solicitud que la genera. Esto permite que una instancia realice tareas arbitrarias periódicas o programadas, o que continúe trabajando en segundo plano después de que se muestre el resultado de una solicitud al usuario.

Las entradas de registro y el os.environ de un subproceso en segundo plano son independientes de los del subproceso de generación.

Debes importar el módulo google.appengine.api.background_thread desde el SDK para App Engine.

from google.appengine.api import background_thread

La clase BackgroundThread es como la clase threading.Threadclass normal de Python, pero puede “sobrevivir” a la solicitud que la genera. También hay una función start_new_background_thread() que crea un subproceso en segundo plano y lo inicia:

# sample function to run in a background thread
def change_val(arg):
    global val
    val = arg

if auto:
    # Start the new thread in one command
    background_thread.start_new_background_thread(change_val, ['Cat'])
else:
    # create a new thread and start it
    t = background_thread.BackgroundThread(
        target=change_val, args=['Cat'])
    t.start()

La cantidad máxima de subprocesos en segundo plano simultáneos creados por la API de App Engine es 10 por instancia. (Este límite no se aplica a los subprocesos de Java normales no relacionados con la API de App Engine).

Herramientas

En el SDK para App Engine, se incluyen herramientas destinadas a probar la aplicación, subir los archivos de la aplicación, administrar índices de Datastore, descargar datos de registro y subir grandes cantidades de datos a Datastore.

El servidor de desarrollo ejecuta la aplicación en tu computadora local para probarla. El servidor simula los servicios de Datastore y las restricciones de la zona de pruebas. El servidor de desarrollo también puede generar la configuración de los índices de Datastore según las consultas que realiza la app durante las pruebas.

La herramienta de gcloud controla toda la interacción entre la línea de comandos y la aplicación que se ejecuta en App Engine. Usa gcloud app deploy para subir la aplicación a App Engine o actualizar archivos de configuración individuales, como la configuración de índices de Datastore, que te permite compilar índices nuevos antes de implementar el código. También puedes ver los datos de registro de la app, de modo que puedas analizar su rendimiento con tus propias herramientas.

Simultaneidad y latencia

La latencia de tu aplicación tiene el mayor impacto en la cantidad de instancias necesarias para entregar tu tráfico. Si procesas las solicitudes con rapidez, una única instancia puede manejar muchas solicitudes.

Las instancias de subprocesos únicos pueden controlar muchas solicitudes simultáneas. Por lo tanto, hay una relación directa entre la latencia y la cantidad de solicitudes que se pueden manejar en la instancia por segundo. Por ejemplo, 10 ms de latencia equivalen a 100 solicitudes por segundo por instancia.

Las instancias de subprocesos múltiples pueden controlar muchas solicitudes simultáneas. Por lo tanto, existe una relación directa entre la CPU consumida y la cantidad de solicitudes por segundo.

Las aplicaciones de la versión 2.7 de Python admiten solicitudes simultáneas, por lo que una sola instancia puede controlar nuevas solicitudes mientras se espera que se completen otras solicitudes. La simultaneidad reduce significativamente la cantidad de instancias que requiere tu aplicación, pero debes diseñar tu aplicación para multiprocesos.

Por ejemplo, si una instancia B4 (un aproximado de 2.4 GHz) consume 10 Mcycles por solicitud, puedes procesar 240 solicitudes por segundo por instancia. Si consume 100 Mcycles por solicitud, puedes procesar 24 solicitudes por segundo por instancia. Estos números son el caso ideal, pero son bastante realistas en términos de lo que puedes lograr en una instancia.

Variables de entorno

El entorno de ejecución configura las siguientes variables del entorno:

Variable de entorno	Descripción
`GAE_APPLICATION`	ID de tu aplicación de App Engine. Este ID tiene el prefijo “`region code`~”, como “e~”, para aplicaciones implementadas en Europa.
`GAE_DEPLOYMENT_ID`	ID de la implementación actual.
`GAE_ENV`	Entorno de App Engine. Se define en `standard`.
`GAE_INSTANCE`	ID de la instancia en la que se está ejecutando tu servicio.
`GAE_RUNTIME`	Entorno de ejecución especificado en el archivo `app.yaml`.
`GAE_SERVICE`	Nombre de servicio especificado en el archivo `app.yaml`. Si no se especifica un nombre de servicio, se asigna `default`.
`GAE_VERSION`	Etiqueta de la versión actual de tu servicio.
`GOOGLE_CLOUD_PROJECT`	ID del proyecto de Google Cloud asociado a tu aplicación.
`PORT`	Puerto que recibe las solicitudes HTTP.

Puedes definir variables de entorno adicionales en tu archivo app.yaml, pero los valores anteriores no se pueden anular.