Migrar de Python 2.7 al entorno de ejecución de Python 3 más reciente

En esta página se incluyen instrucciones para migrar de los tiempos de ejecución de Python de primera generación a los de segunda generación. Para actualizar tu aplicación de segunda generación y usar la última versión compatible de Python, consulta Actualizar una aplicación.

Python 2.7 llegó al final del periodo de asistencia el 31 de enero del 2024. Tus aplicaciones de Python 2.7 seguirán ejecutándose y recibiendo tráfico. Sin embargo, App Engine puede bloquear el nuevo despliegue de aplicaciones que usen tiempos de ejecución después de la fecha de finalización de su asistencia. Te recomendamos que migres a la versión compatible más reciente de Python siguiendo las directrices de esta página.

Si migras al tiempo de ejecución de Python 3, podrás usar funciones del lenguaje actualizadas y crear aplicaciones más portátiles con código idiomático. El entorno de ejecución de Python 3 usa la versión más reciente del intérprete de Python de código abierto proporcionado por la Python Software Foundation. Las aplicaciones creadas en el tiempo de ejecución de Python 3 pueden usar el amplio ecosistema de paquetes y frameworks de Python en tu aplicación, incluidos los que usan código C, declarando dependencias en un archivo requirements.txt.

Descripción general del proceso de migración del tiempo de ejecución

Te recomendamos que sigas este enfoque incremental para migrar el tiempo de ejecución, en el que mantendrás una aplicación funcional y que se pueda probar durante todo el proceso:

1. Actualiza tu aplicación para que sea compatible con Python 3.

   Hay varias soluciones disponibles para ayudarte con esta actualización. Por ejemplo, usa Six, Python-Future o Python-Modernize.

   Para obtener más información sobre este paso del proceso de migración del tiempo de ejecución, consulta el artículo Porting Python 2 Code to Python 3 (Migración de código de Python 2 a Python 3) en el sitio de documentación de Python Software Foundation.

2. Elige una de estas estrategias de implementación para cualquier servicio empaquetado de App Engine que use tu aplicación:

   1. Migra los servicios antiguos agrupados de tu aplicación Python 2 a servicios Google Cloud sin agrupar, servicios de terceros u otros sustitutos recomendados.

   2. Sigue usando los servicios antiguos incluidos en tus aplicaciones de Python 3. Este enfoque te ofrece la flexibilidad de cambiar a servicios independientes más adelante en el ciclo de migración.

      Nota: No todos los servicios agrupados antiguos disponibles para Python 2 tienen un servicio correspondiente en Python 3, por lo que deberán migrarse a un servicio de Google Cloud o de terceros antes de pasarse a Python 3.

   Asegúrate de probar tu aplicación después de migrar cada servicio.

3. Prepara los archivos de configuración de App Engine para el entorno de ejecución de Python 3. Se han realizado varios cambios importantes en los ajustes de configuración de app.yaml, entre los que se incluyen los siguientes:

   • Ahora se da por hecho que las aplicaciones son seguras para subprocesos. Si tu aplicación no es segura para subprocesos, debes asignar el valor 1 a max_concurrent_requests en tu app.yaml. Este ajuste puede provocar que se creen más instancias de las que necesitas para una aplicación threadsafe, lo que puede generar costes innecesarios.

   • El archivo app.yaml ya no dirige las solicitudes a tus secuencias de comandos. En su lugar, debe usar un framework web con enrutamiento en la aplicación y actualizar o quitar todos los controladores script en app.yaml. Para ver un ejemplo de cómo hacerlo con el framework Flask, consulta el ejemplo de código de la guía de migración de App Engine en GitHub.

     Para obtener más información sobre cómo cambiar este y otros archivos de configuración, consulta la sección Archivos de configuración.

4. En los tiempos de ejecución de segunda generación, los registros de aplicaciones ya no están anidados en los registros de solicitudes. Para mostrar la vista anidada de los registros de solicitudes y de aplicaciones en el Explorador de registros, debes seguir unos pasos adicionales. Para obtener más información, consulta Migrar a Cloud Logging.

5. Prueba y despliega la aplicación actualizada en un entorno de Python 3.

   Una vez que hayas superado todas las pruebas, despliega la aplicación actualizada en App Engine, pero evita que el tráfico se dirija automáticamente a la nueva versión. Usa la división del tráfico para migrar lentamente el tráfico de tu aplicación del entorno de ejecución de Python 2 a la aplicación del entorno de ejecución de Python 3. Si tienes algún problema, puedes dirigir todo el tráfico a una versión estable hasta que se solucione.

Para ver ejemplos de cómo convertir tus aplicaciones de Python 2 a Python 3, consulta estos recursos adicionales.

Diferencias clave entre los entornos de ejecución de Python 2 y Python 3

La mayoría de los cambios que debes hacer durante la migración del entorno de ejecución se deben a las siguientes diferencias entre los entornos de ejecución de Python 2 y Python 3:

• Diferencias en el uso de memoria
• Diferencias en el uso de la CPU
• Diferencias entre encabezados de solicitud
• Diferencias entre los workers de Gunicorn
• Problemas de compatibilidad entre Python 2 y Python 3
• Servicios agrupados de App Engine en el tiempo de ejecución de Python 3
• Diferencias entre archivos de configuración
• Se necesita un framework web para enrutar las solicitudes de contenido dinámico
• Aplicaciones con solo contenido estático
• Diferencias en las pruebas
• Diferencias en el despliegue

Diferencias en el uso de memoria

Los tiempos de ejecución de segunda generación tienen un uso de memoria de referencia más alto que los de primera generación. Esto se debe a varios factores, como las diferentes versiones de la imagen base y las diferencias en la forma en que las dos generaciones calculan el uso de memoria.

Los tiempos de ejecución de segunda generación calculan el uso de memoria de las instancias como la suma de lo que usa un proceso de aplicación y el número de archivos de aplicación almacenados dinámicamente en caché en la memoria. Para evitar que las aplicaciones que consumen mucha memoria experimenten cierres de instancias debido a que superan los límites de memoria, cambia a una clase de instancia más grande con más memoria.

Diferencias en el uso de la CPU

Los tiempos de ejecución de segunda generación pueden experimentar un aumento del uso de la CPU al iniciar una instancia por primera vez. En función de la configuración de escalado de una aplicación, esto puede tener efectos secundarios no deseados, como un número de instancias superior al previsto si una aplicación está configurada para escalarse en función de la utilización de la CPU. Para evitar este problema, revisa y prueba las configuraciones de escalado de la aplicación para asegurarte de que el número de instancias sea aceptable.

Diferencias en los encabezados de solicitud

Los tiempos de ejecución de primera generación permiten que los encabezados de solicitud con guiones bajos (por ejemplo, X-Test-Foo_bar) se reenvíen a la aplicación. Los runtimes de segunda generación introducen Nginx en la arquitectura del host. Como resultado de este cambio, los tiempos de ejecución de segunda generación se configuran para eliminar automáticamente los encabezados con guiones bajos (_). Para evitar problemas con las aplicaciones, no utilices guiones bajos en los encabezados de las solicitudes de las aplicaciones.

Diferencias entre los workers de Gunicorn

En los tiempos de ejecución de Python 3 o versiones posteriores, el número de procesos de trabajo de Gunicorn influye directamente en el uso de memoria. El aumento del uso de memoria es directamente proporcional al aumento del número de trabajadores. Para reducir el consumo de memoria, considera la opción de reducir el número de procesos de trabajo de Gunicorn. Consulta las prácticas recomendadas de Entrypoint para obtener instrucciones sobre cómo configurar el número de trabajadores de Gunicorn.

Problemas de compatibilidad entre Python 2 y Python 3

Cuando se lanzó Python 3 por primera vez en el 2008, se introdujeron varios cambios incompatibles con versiones anteriores en el lenguaje. Algunos de estos cambios solo requieren pequeñas actualizaciones en el código, como cambiar la instrucción print por una función print(). Otros cambios pueden requerir actualizaciones significativas en tu código, como la forma en que gestionas los datos binarios, el texto y las cadenas.

Muchas bibliotecas populares de código abierto, incluidas las bibliotecas estándar de Python, también cambiaron cuando pasaron de Python 2 a Python 3.

Servicios agrupados de App Engine en el entorno de ejecución de Python 3

Para reducir el esfuerzo y la complejidad de la migración, el entorno estándar de App Engine te permite acceder a muchos de los servicios y APIs antiguos incluidos en el entorno de ejecución de Python 3, como Memcache. Tu aplicación Python 3 puede llamar a las APIs de los servicios agrupados a través de bibliotecas idiomáticas del lenguaje y acceder a las mismas funciones que en el tiempo de ejecución de Python 2.

Nota: Para ver la lista completa de las APIs de servicios agrupados antiguos disponibles para Python 3, consulta las APIs de servicios agrupados antiguos disponibles.

También puedes usar Google Cloud productos que ofrecen funciones similares a las de los servicios antiguos agrupados. Te recomendamos que migres a los productos no agrupados Google Cloud , ya que así podrás aprovechar las mejoras y las nuevas funciones que se vayan lanzando.

En el caso de los servicios incluidos que no están disponibles como productos independientes enGoogle Cloud, como el procesamiento de imágenes, la búsqueda y la mensajería, puedes usar los proveedores externos que te sugerimos u otras soluciones alternativas.

Archivos de configuración

Para poder ejecutar tu aplicación en el tiempo de ejecución de Python 3 del entorno estándar de App Engine, es posible que tengas que cambiar algunos de los archivos de configuración que usa App Engine:

• app.yaml. Se ha modificado el comportamiento de algunos campos del app.yamlarchivo de configuración. Elimina los campos obsoletos y actualiza los demás campos tal como se describe en la guía de migración.

• requirements.txt. Crea este archivo para instalar dependencias de terceros, incluidas las de paquetes de Python que requieren extensiones nativas de C. App Engine instala automáticamente estas dependencias durante la implementación de la aplicación en el tiempo de ejecución de Python 3. Antes, para instalar dependencias en el tiempo de ejecución de Python 2, tenías que incluir las bibliotecas copiadas o empaquetadas en este archivo y, a continuación, ejecutar un comando pip install -t lib -r requirements.txt o incluir las bibliotecas de terceros "integradas" que requiriera tu aplicación en el archivo app.yaml.

• appengine_config.py. Este archivo no se usa en el entorno de ejecución de Python 3 y se ignora si se despliega. Antes, en el entorno de ejecución de Python 2, este archivo se usaba para configurar módulos de Python y dirigir la aplicación a bibliotecas de terceros copiadas o empaquetadas.

Framework web necesario para enrutar solicitudes de contenido dinámico.

En el tiempo de ejecución de Python 2, puede crear controladores de URLs en el archivo app.yaml para especificar qué aplicación se debe ejecutar cuando se solicite una URL o un patrón de URL concretos.

En el tiempo de ejecución de Python 3, tu aplicación debe usar un framework web, como Flask o Django, para enrutar las solicitudes de contenido dinámico en lugar de usar controladores de URLs en app.yaml. En el caso del contenido estático, puedes seguir creando controladores de URLs en el archivo app.yaml de tu aplicación.

Aplicaciones con solo contenido estático

Cuando alojas una aplicación web estática en App Engine, especificas controladores en el archivo app.yaml para asignar URLs a tus archivos estáticos.

En Python 2, si una solicitud no coincide con ninguno de los controladores especificados en el archivo app.yaml, App Engine devuelve un código de error 404.

En Python 3, si una solicitud no coincide con ninguno de los controladores, App Engine busca un archivo main.py y devuelve un error 5xx si no lo encuentra.main.py Como las aplicaciones de App Engine que solo tienen contenido estático no requieren un archivo main.py, la mayoría de los usuarios ven este error, además de errores de inicio de instancia en los registros de la aplicación.

Para mantener el mismo comportamiento de devolver un error 404 cuando no coincida ninguno de los controladores estáticos y evitar errores en los registros, puede hacer lo siguiente:

• Añade un controlador estático catch-all que apunte a un directorio vacío en el archivo app.yaml.
• Añade una aplicación dinámica sencilla en el archivo main.py para devolver un error 404.

Ejemplos de uso de cada opción:

app.yaml

Crea un directorio vacío en el directorio raíz de la aplicación, como empty/. En la sección del controlador del archivo app.yaml, cree un controlador al final para detectar todos los demás patrones de URL y especifique el directorio empty en los elementos static_files y upload:

  handlers:
  - url:
    .
    .
    .
  - url: /(.*)$
    static_files: empty/\1
    upload: empty/.*$

main.py

Crea un archivo main.py y añade el siguiente código para devolver un error 404:

  def app(env, start_response):
    start_response('404 Not Found', [('Content-Type','text/html')])
    return [b"Not Found"]

Pruebas

Te recomendamos que utilices un enfoque de prueba que sea propio de Python en lugar de depender de dev_appserver. Por ejemplo, puedes usar venv para crear un entorno local aislado de Python 3. Puedes usar cualquier framework de pruebas estándar de Python para escribir tus pruebas unitarias, de integración y de sistema. También puedes configurar versiones de desarrollo de tus servicios o usar los emuladores locales que están disponibles para muchos productos de Google Cloud.

También puede usar la versión de vista previa de dev_appserver, que es compatible con Python 3. Para obtener más información sobre esta función de prueba, consulta el artículo Utilizar el servidor de desarrollo local.

Despliegue

Las implementaciones mediante appcfg.py no se admiten en Python 3. En su lugar, usa la gcloudherramienta de línea de comandos para desplegar tu aplicación.

Almacenamiento de registros

El registro en el tiempo de ejecución de Python 3 sigue el estándar de registro de Cloud Logging. En el tiempo de ejecución de Python 3, los registros de aplicaciones ya no se incluyen en los registros de solicitudes, sino que se separan en registros diferentes. Para obtener más información sobre cómo leer y escribir registros en el entorno de ejecución de Python 3, consulta la guía de registro.

Recursos de migración adicionales

Para obtener más información sobre cómo migrar tus aplicaciones de App Engine a servicios de Cloud independientes o al entorno de ejecución de Python 3, consulta estos recursos de App Engine:

• Codelabs y vídeos sobre la migración de aplicaciones sin servidor
• Ejemplos de la comunidad para migrar aplicaciones de Python 2 a Python 3