Google Cloud Platform: implementación de Django y sus sistemas de gestión de contenido

Django es un marco web escrito en Python que maneja el servicio de páginas web por usted. Los modelos de datos se definen como objetos de Python y Django simplifica la comunicación de estos a una base de datos.

Cloud Run es una plataforma administrada sin servidor, donde cada servidor se ejecuta sin estado. No se almacenan datos en los propios servidores. Pero Cloud Run puede conectarse al estado para respaldar servicios, bases de datos, API y similares. Los marcos web que se basan en bases de datos como Django pueden ejecutarse en una configuración sin servidor con alguna configuración.

Los pasos generales descritos en este artículo se pueden usar no solo para Django, sino también para cualquier otro sistema de administración de contenido que use Django, como Wagtail y Django CMS . Cualquier sitio de Django se puede construir en una imagen de contenedor. Esta imagen se puede implementar como un servicio de Cloud Run, pero eso solo maneja la parte del código. Django también necesita una base de datos para almacenar datos relacionales y un lugar para almacenar medios y activos estáticos. Estos dos servicios de respaldo deben ser aprovisionados y accesibles por el servicio.

Django admite muchas bases de datos relacionales, incluidas PostgreSQL y MySQL. También podemos usar Cloud SQL, un servicio de base de datos administrado, que admite tanto PostgreSQL como MySQL, e incluso MS SQL.

Cuando los usuarios implementen su servicio de Cloud Run por primera vez, deberán establecer el parámetro de agregar instancia de SQL, vinculando su servicio de Cloud Run con su base de datos de Cloud SQL como se muestra a continuación:

$ gcloud run deploy PROJECT_NAME\
  --platform managed\
  --add--cloudsql-instances vivid: REGION: Project\
  ...

Esto permite que el servicio en la base de datos se comunique a través de una conexión encriptada automáticamente.

Django también necesitará configuraciones de conexión. No solo el nombre de host de la instancia , sino también el nombre de usuario y la contraseña de la base de datos. 

$ gcloud secrets create DATABASE_URL \ 
  --data-file db_config.txt

Los usuarios pueden almacenar estas credenciales usando Secret Manager, recuperándolas en tiempo de ejecución. Desde aquí, todo está configurado para ejecutar el comando de migración de Django:

python manage.py migrate

En segundo lugar, los medios y los activos estáticos. Los usuarios pueden configurar su nueva aplicación Django para usar un depósito de Google Cloud Storage para almacenar estos archivos. El almacenamiento en la nube se puede configurar como un backend de almacenamiento personalizado en Django utilizando el paquete de almacenamiento de Django. Los usuarios solo necesitan instalar el paquete usando el siguiente comando:

$ pip install django-storages [google]

 Y edite su settings.py para usar este nuevo backend de almacenamiento y apunte a su nuevo depósito de Cloud Storage como se muestra a continuación:

$ cat Project/setting.py
'''
DEFAULT_FILE_STORAGE = (
  'storage.backends.gcloud.GoogleCloudStorage')
GS_BUCKET = 'Project-dotcom-media'
...
'''

 Desde aquí, todo está configurado para ejecutar el comando recopilar estático de Django.

Cloud Run se enfoca en servir contenedores y no proporciona una forma de ejecutar un comando de shell único en un servicio en ejecución. Lo que pueden hacer los usuarios es ejecutar estos comandos como parte de su proceso de integración continua con Google Cloud Build.

En su configuración de Cloud Build, pueden agregar un nuevo paso llamado migrar entre su paso construido y su paso de implementación.

$ cat cloudbuild.yaml

steps:
    -id: "build"
    -id: "django migrate"
    name: gcr.io/google-appengine/exec-wrapper'
    args:{ '-i', 'gcr.io/.....,
          '--', 'python', 'manage.py', 'migrate']
    -id: 'deploy'
    ...

Este paso de migración usa el contenedor exec de App Engine, que permite que los comandos se ejecuten en una base de datos durante un trabajo de Cloud Build. Además, pueden configurar este trabajo para que se ejecute automáticamente cada vez que se actualice el código del proyecto en el control de código fuente mediante activadores de Cloud Build .

$ gclud builds triggers create github \
  --build-config cloudbuild.yaml \
  -- repo-owner project \
  -- repo-name project-dotcom \
  -- branch-pattern "^prod$"

Si un proceso automatizado no funciona para la estrategia de migración de los usuarios, pueden ejecutar sus comandos de migración manualmente con la ayuda del proxy de Cloud SQL.

$ ./cloud_sql_proxy ..&

Al conectar los servicios de estos administradores, los usuarios podrán alojar sus sitios web en la nube. Estos servicios aumentan y disminuyen automáticamente a medida que cambia su carga a lo largo del día, sin tener que pagar un precio fijo por un servidor virtual.