Google Cloud Platform: ejecución de diferentes versiones de Python en Google Cloud Run

Planteamiento del problema:

Rinki trabaja para StoreCraft(Say) como ingeniera de confiabilidad del sitio, donde está de guardia manteniendo su escaparate personalizado. Los sistemas de StoreCraft se desarrollan internamente en Python y se han estado ejecutando en máquinas virtuales durante años, una configuración que evolucionó a medida que lo hicieron los negocios de StoreCraft. Estas máquinas virtuales usan versiones ligeramente diferentes de Python. Esto está causando más dolor y trabajo para Rinki y su equipo. Rinki está buscando una manera de reducir este dolor actualizando todos los componentes a Python actual y también migrando de las máquinas virtuales a algo más escalable, como sin servidor. StoreCraft está a punto de lanzar un nuevo motor de recomendaciones, que está escrito con Python 3.8 (la última versión en 2020). Sin embargo, depende del paquete sweet-ldap , que aún no es compatible con Python 3.

Rinki sabe que esta actualización llevará tiempo. Y su equipo necesita asegurarse de que el sistema existente siga funcionando. ¿Cómo resolverá Rinki este problema en GCP?

Solución:

Se da cuenta de que la mejor manera de lograrlo es completando la actualización en dos pasos. Primero, migrar a sin servidor y luego realizar las actualizaciones de idioma. Como StoreCraft está a punto de lanzar un nuevo motor de recomendaciones, que está escrito con Python 3.9. Rinki ve esto como el candidato perfecto para implementar un serverless omitiendo la máquina virtual por completo. Al observar las opciones disponibles en Google Cloud, Rinki ve que, si bien podría implementar Cloud Functions , se vería obligada a usar solo versiones específicas de Python. Sin embargo, ve que la oferta sin servidor más reciente de Google Cloud, llamada Cloud Run , no tiene esta limitación.

Entonces ella elige desplegarse allí en su lugar. Al crear este servicio en Cloud Run, Rinki tiene control total sobre el contenedor. Haciendo uso de las imágenes oficiales de Python en el centro de Docker , puede elegir la versión exacta de Python (es decir, Python 3.8) que necesita hasta el nivel de parche especificando la imagen base en la primera línea del Dockerfile . Dado que cada servicio de Cloud Run se basa en su propia imagen de contenedor, cada una definida por su propio archivo Docker, Rinki tiene control total sobre los idiomas utilizados en cada parte de su configuración.

Dado que cada servicio de Cloud Run tiene este nivel de aislamiento, Rinki puede mover cada uno de ellos a Cloud Run de uno en uno. También puede mantener los servicios ejecutándose en las máquinas virtuales originales hasta que el equipo tenga la disponibilidad para actualizar. 

Depende del paquete sweet-ldap , que aún no es compatible con Python 3. Rinki puede mantener el servicio en ejecución en el ahora obsoleto Python 2.7 especificando la última versión de Python 2 en el archivo Docker como se muestra a continuación:

$ cat sweet-ldap/setup.py
...
 classifiers = [
                'Programming Language : : Python : : 2.7'
               ]
...
$ head Dockerfile
From python : 2.7.18 #final

Tan pronto como el paquete sweet-ldap sea compatible con Python 3, Rinki podrá probar esta nueva versión implementando gradualmente una nueva revisión del servicio utilizando la función de división de tráfico de Cloud Run. 

Puede configurar la nueva revisión del servicio de conteo para, digamos, atender solo al 5% de los visitantes, de esa manera solo algunos de sus clientes terminan usando el nuevo código. Si nota que algo no funciona según lo previsto, puede retroceder fácilmente a la versión anterior. Al migrar cada servicio por turno, Rinki puede controlarlos de forma aislada, lo que permite un proceso de actualización más gradual y un entorno más confiable.