Migración de usuarios de App Engine a Cloud Identification Platform (módulo 21)

publicado por wesley chun (@wescpy), promotor de desarrolladores, Google Cloud

En common, el Módulo 21 presenta cambios importantes en la aplicación de muestra del Módulo 20, implementando un cambio de los servicios integrados de App Engine (NDB y Usuarios) a servicios en la nube independientes (Cloud Datastore y Identification Platform). Identification Platform no sabe nada acerca de los administradores de App Engine, por lo que debe construirse, lo que requiere el uso de la Administrador de recursos en la nube API. Las aplicaciones que dependen de Python 2 tienen actualizaciones requeridas adicionales. Vamos a discutir con un poco más de detalle.

Migración “partes”

Se requieren los siguientes cambios en la aplicación de muestra:

• Migrar de usuarios de App Engine (lado del servidor) a Cloud Identification Platform (lado del cliente)

• migrar desde NDB del motor de aplicacionesel otro servicio empaquetado utilizado en el Módulo 20, para Nube NDB (requiere el uso de la API de Cloud Datastore)
• Utilizar el Administrador de recursos en la nube* (a través de su API) para obtener el Política de autorización de IAM del proyecto en la nube para recopilar el conjunto de usuarios administradores de App Engine para la aplicación.
• Utilizar el SDK de administración de Firebase para validar si el usuario es un administrador de App Engine
• Migrar de Python 2 a 3 (y posiblemente volver a Python 2 (más sobre esto a continuación))

*Al momento de escribir este artículo, el Documentación del administrador de recursos solo presenta instrucciones de configuración para acceder a la API desde el biblioteca de cliente de API de Google de nivel inferior en lugar de la Biblioteca cliente de Useful resource Supervisor. Para saber cómo configurar este último, vaya a la Documentación de la biblioteca cliente de Useful resource Supervisor directamente. La biblioteca de cliente de nivel inferior solo debe usarse en circunstancias en las que no exista una biblioteca de cliente en la nube o no tenga las funciones que necesita su aplicación. Uno de esos casos de uso es Python 2, y lo cubriremos en breve.

Pase de los servicios integrados de App Engine a servicios en la nube independientes

Él Migración de NDB a Cloud NDB es idéntico al Módulo 2 contenido de migración, por lo que no se cubre en profundidad aquí en el Módulo 21. El enfoque principal es cambiar a Identification Platform para continuar admitiendo los inicios de sesión de los usuarios, así como implementar el uso de Useful resource Supervisor y Firebase Admin SDK para crear un proxy para reconocer a los usuarios administradores de App Engine. según lo dispuesto por el servicio de Usuarios. A continuación, se muestra un pseudocódigo que implementa los cambios clave en la aplicación principal donde se encuentran líneas de código nuevas o actualizadas. en negrita:

Migración de usuarios de App Engine a Cloud Identification Platform(Click on para agrandar)

Las diferencias clave a tener en cuenta:

1. El código de servicio de los usuarios del lado del servidor desaparece de la aplicación principal y pasa a la plantilla net (del lado del cliente) (que no se muestra aquí).
2. Prácticamente todo el código nuevo en la aplicación Módulo 21 anterior es para reconocer a los usuarios administradores de App Engine. No hay cambios en las operaciones de la aplicación o los modelos de datos que no sean Cloud NDB que requieran el uso de administradores de contexto de Python para encapsular todo el código de Datastore (usando Python con bloques).

Las versiones completas de la aplicación antes y después de las actualizaciones se pueden encontrar en la Módulo 20 (Python 2) y Módulo 21 (Python 3) carpetas de repositorio, respectivamente. Además del video, asegúrese de ver el Documentación de la plataforma de identidad así como el Laboratorio de código del módulo 21 que lo guía paso a paso a través de las migraciones discutidas.

Aparte de los cambios de codificación necesarios, así como de pasar del lado del servidor al lado del cliente, tenga en cuenta que el uso del servicio de los Usuarios está cubierto por Modelo de precios de App Engine mientras que Identification Platform es un servicio de nube independiente facturado por MAU (usuarios activos mensuales), por lo que se deben tener en cuenta los costos si se realiza la migración. Se puede encontrar más información en el Documentación de precios de Identification Platform.

Consideraciones de Python 2

Con el puesta de sol de Python 2Java 8, PHP 5 y Go 1.11, por sus respectivas comunidades, Google Cloud ha asegurado a los usuarios expresando soporte a largo plazo de estos tiempos de ejecución heredados de App Engineincluido mantener el tiempo de ejecución de Python 2. Entonces, si bien no existe un requisito precise para que los usuarios migren, los propios desarrolladores están expresando interés en actualizar sus aplicaciones a las versiones de idioma más recientes.
La migración principal del Módulo 21 incluye automáticamente un puerto de Python 2 a 3, ya que es hacia donde se dirigen la mayoría de los desarrolladores. Para aquellos con dependencias que requieren permanecer en Python 2, se requiere un esfuerzo adicional:

El codelab cubre este backport en profundidad, así que consulte la sección específica para usuarios de Python 2 si se encuentra en esta situación. Si no quiere pensar en eso, solo diríjase al repositorio para obtener un trabajo Versión Python 2 de la aplicación Módulo 21.