Django CMS en Cloud Run

1. Introducción

Cloud Run es una plataforma de procesamiento administrada que te permite ejecutar contenedores sin estado que se pueden invocar a través de solicitudes HTTP. Cloud Run es una plataforma sin servidores que simplifica la administración de la infraestructura para que puedas enfocarte en lo que más importa: crear aplicaciones extraordinarias.

También se conecta de forma nativa con muchas otras partes del ecosistema de Google Cloud, como Cloud SQL para bases de datos administradas, Cloud Storage para almacenamiento de objetos unificado y Secret Manager para administrar secretos.

Django CMS es un sistema de administración de contenido (CMS) empresarial creado sobre Django. Django es un framework web de alto nivel en Python.

En este instructivo, usarás estos componentes para implementar un pequeño proyecto de Django CMS.

Nota: Este codelab se verificó por última vez con Django CMS 4.1.2 a través de django-cms/cms-template v4.1.

Qué aprenderás

• Cómo usar Cloud Shell
• Cómo crear una base de datos de Cloud SQL
• Cómo crear un bucket de Cloud Storage
• Cómo crear secretos de Secret Manager
• Cómo usar secretos de diferentes servicios de Google Cloud
• Cómo conectar componentes de Google Cloud a un servicio de Cloud Run
• Cómo usar Container Registry para almacenar contenedores compilados
• Cómo realizar implementaciones en Cloud Run
• Cómo ejecutar migraciones de esquemas de bases de datos en Cloud Build

2. Configuración y requisitos

Configuración del entorno de autoaprendizaje

1. Accede a Google Cloud Console y crea un proyecto nuevo o reutiliza uno existente. Si aún no tienes una cuenta de Gmail o de Google Workspace, debes crear una.

• El Nombre del proyecto es el nombre visible de los participantes de este proyecto. Es una cadena de caracteres que no se utiliza en las APIs de Google. Puedes actualizarla cuando quieras.
• El ID del proyecto es único en todos los proyectos de Google Cloud y es inmutable (no se puede cambiar después de configurarlo). La consola de Cloud genera automáticamente una cadena única. Por lo general, no importa cuál sea. En la mayoría de los codelabs, deberás hacer referencia al ID de tu proyecto (suele identificarse como PROJECT_ID). Si no te gusta el ID que se generó, podrías generar otro aleatorio. También puedes probar uno propio y ver si está disponible. No se puede cambiar después de este paso y se usa el mismo durante todo el proyecto.
• Recuerda que hay un tercer valor, un número de proyecto, que usan algunas APIs. Obtén más información sobre estos tres valores en la documentación.

Precaución: El ID del proyecto es único a nivel global y no lo puede usar nadie más después de que lo hayas seleccionado. Eres el único usuario de ese ID. Incluso si se borra un proyecto, no se puede volver a usar el ID.

Nota: Si usas una cuenta de Gmail, puedes dejar la ubicación predeterminada como Sin organización. Si usas una cuenta de Google Workspace, elige una ubicación adecuada para tu organización.

2. A continuación, deberás habilitar la facturación en la consola de Cloud para usar las APIs o los recursos de Cloud. Ejecutar este codelab no costará mucho, tal vez nada. Para cerrar recursos y evitar que se generen cobros más allá de este instructivo, puedes borrar los recursos que creaste o borrar el proyecto. Los usuarios nuevos de Google Cloud son aptos para participar en el programa Prueba gratuita de $300.

Google Cloud Shell

Si bien Google Cloud se puede operar de manera remota desde tu laptop, en este codelab usaremos Google Cloud Shell, un entorno de línea de comandos que se ejecuta en la nube.

Activar Cloud Shell

1. En la consola de Cloud, haz clic en Activar Cloud Shell.

Si es la primera vez que inicias Cloud Shell, aparecerá una pantalla intermedia en la que se describirá qué es. Si apareció una pantalla intermedia, haz clic en Continuar.

El aprovisionamiento y la conexión a Cloud Shell solo tomará unos minutos.

Esta máquina virtual está cargada con todas las herramientas de desarrollo necesarias. Ofrece un directorio principal persistente de 5 GB y se ejecuta en Google Cloud, lo que permite mejorar considerablemente el rendimiento de la red y la autenticación. Gran parte de tu trabajo en este codelab, si no todo, se puede hacer con un navegador.

Una vez que te conectes a Cloud Shell, deberías ver que te autenticaste y que el proyecto se configuró con tu ID del proyecto.

2. En Cloud Shell, ejecuta el siguiente comando para confirmar que tienes la autenticación:

gcloud auth list

Resultado del comando

 Credentialed Accounts
ACTIVE  ACCOUNT
*       <my_account>@<my_domain.com>

To set the active account, run:
    $ gcloud config set account `ACCOUNT`

Nota: gcloud es la herramienta de línea de comandos potente y unificada de Google Cloud. Ya está preinstalada en Cloud Shell. Notarás que admite el autocompletado con la tecla Tab. Es posible que se te solicite que te autentiques la primera vez que ejecutes un comando. Para obtener más información, consulta la descripción general de la herramienta de línea de comandos de gcloud.

3. En Cloud Shell, ejecuta el siguiente comando para confirmar que el comando gcloud conoce tu proyecto:

gcloud config list project

Resultado del comando

[core]
project = <PROJECT_ID>

De lo contrario, puedes configurarlo con el siguiente comando:

gcloud config set project <PROJECT_ID>

Resultado del comando

Updated property [core/project].

Nota: Si completas este instructivo fuera de Cloud Shell, sigue los pasos para configurar las credenciales predeterminadas de la aplicación.

3. Habilita las APIs de Cloud

En Cloud Shell, habilita las APIs de Cloud para los componentes que se usarán:

gcloud services enable \
  run.googleapis.com \
  sql-component.googleapis.com \
  sqladmin.googleapis.com \
  compute.googleapis.com \
  cloudbuild.googleapis.com \
  secretmanager.googleapis.com \
  artifactregistry.googleapis.com

Como es la primera vez que llamas a las APIs desde gcloud, se te pedirá que autorices el uso de tus credenciales para realizar esta solicitud. Esto ocurrirá una vez por sesión de Cloud Shell.

Es posible que esta operación se tarde unos minutos en completarse.

Cuando se complete, debería aparecer un mensaje de éxito similar a este:

Operation "operations/acf.cc11852d-40af-47ad-9d59-477a12847c9e" finished successfully.

4. Crea un proyecto de plantilla

Usarás el cms-template de Django CMS como tu proyecto de muestra de Django CMS.

Para crear este proyecto de plantilla, usa Cloud Shell para crear un directorio nuevo llamado djangocms-cloudrun y navega hasta él:

mkdir ~/djangocms-cloudrun
cd ~/djangocms-cloudrun

Instala el paquete django-cms en un entorno virtual temporal:

virtualenv venv
source venv/bin/activate
pip install djangocms-frontend\[cms-4]

Crea una copia del proyecto cms-template:

django-admin startproject --template https://github.com/django-cms/cms-template/archive/4.1.zip myproject .

Cambia el nombre del archivo requirements.in por requirements.txt. (El archivo .in se usa con pip-tools para generar archivos requirements.txt, pero se puede usar tal como está si se cambia la extensión. En pasos posteriores, pip espera la extensión .txt).

mv requirements.in requirements.txt

Ahora tendrás un proyecto de plantilla de Django CMS en una carpeta llamada myproject:

ls -F

manage.py*  media/  myproject/  project.db requirements.txt  static/ venv/

Ahora puedes salir y quitar tu entorno virtual temporal:

deactivate
rm -rf venv

Desde aquí, se llamará a Django CMS dentro del contenedor.

5. Crea los servicios de respaldo

Ahora crearás tus servicios de respaldo: una cuenta de servicio dedicada, un registro de Artifact Registry, una base de datos de Cloud SQL, un bucket de Cloud Storage y varios valores de Secret Manager.

Proteger los valores de las contraseñas que se usan en la implementación es importante para la seguridad de cualquier proyecto y garantiza que nadie coloque contraseñas accidentalmente donde no corresponden (por ejemplo, directamente en los archivos de configuración o escritas directamente en tu terminal, donde se podrían recuperar del historial).

Para comenzar, establece dos variables de entorno básicas, una para el ID del proyecto:

PROJECT_ID=$(gcloud config get-value core/project)

Y una para la región:

REGION=us-central1

Cuando trabajas con la infraestructura, es útil tener todos los componentes en la misma ubicación para que puedan comunicarse entre sí de manera más eficiente. Si bien algunos componentes están disponibles a nivel mundial, no todos lo están en todas las regiones.

Para este codelab, te recomendamos que uses us-central1, europe-north1 o asia-northeast1, o cualquier región en la que se admita Cloud Run (completamente administrado).

Más información:

• Ubicaciones de Cloud Run (completamente administrado)
• Ubicaciones de Cloud SQL
• Ubicaciones de Cloud Storage

Crear una cuenta de servicio

Para limitar el acceso que tendrá el servicio a otras partes de Google Cloud, crea una cuenta de servicio dedicada:

gcloud iam service-accounts create cloudrun-serviceaccount

En las próximas secciones de este codelab, harás referencia a esta cuenta por su correo electrónico. Establece ese valor en una variable de entorno:

SERVICE_ACCOUNT=$(gcloud iam service-accounts list \
    --filter cloudrun-serviceaccount --format "value(email)")

Crea un registro de Artifact Registry

Para almacenar la imagen de contenedor compilada, crea un registro de contenedores en la región que elijas:

gcloud artifacts repositories create containers --repository-format docker --location $REGION

Harás referencia a este registro por su nombre en secciones posteriores de este codelab:

ARTIFACT_REGISTRY=${REGION}-docker.pkg.dev/${PROJECT_ID}/containers

Crea la base de datos

Crea una instancia de Cloud SQL:

gcloud sql instances create myinstance --project $PROJECT_ID \
  --database-version POSTGRES_14 --tier db-f1-micro --region $REGION

Esta operación puede tardar unos minutos en completarse.

En esa instancia, crea una base de datos:

gcloud sql databases create mydatabase --instance myinstance

En esa misma instancia, crea un usuario:

DJPASS="$(cat /dev/urandom | LC_ALL=C tr -dc 'a-zA-Z0-9' | fold -w 30 | head -n 1)"
gcloud sql users create djuser --instance myinstance --password $DJPASS

Otorga permiso a la cuenta de servicio para conectarse a la instancia:

gcloud projects add-iam-policy-binding $PROJECT_ID \
    --member serviceAccount:${SERVICE_ACCOUNT} \
    --role roles/cloudsql.client

Crea el bucket de almacenamiento

Crea un bucket de Cloud Storage (ten en cuenta que el nombre debe ser único a nivel global):

GS_BUCKET_NAME=${PROJECT_ID}-media
gcloud storage buckets create gs://${GS_BUCKET_NAME} --location ${REGION} 

Otorga permisos a la cuenta de servicio para administrar el bucket:

gcloud storage buckets add-iam-policy-binding gs://${GS_BUCKET_NAME} \
    --member serviceAccount:${SERVICE_ACCOUNT} \
    --role roles/storage.admin

Dado que los objetos almacenados en el bucket tendrán un origen diferente (una URL de bucket en lugar de una URL de Cloud Run), debes configurar los parámetros de configuración de uso compartido de recursos multiorigen (CORS).

Crea un archivo nuevo llamado cors.json con el siguiente contenido:

touch cors.json
cloudshell edit cors.json

cors.json

[
    {
      "origin": ["*"],
      "responseHeader": ["Content-Type"],
      "method": ["GET"],
      "maxAgeSeconds": 3600
    }
]

Aplica esta configuración de CORS al bucket de almacenamiento recién creado:

gsutil cors set cors.json gs://$GS_BUCKET_NAME

Almacena la configuración como un secreto

Una vez que hayas configurado los servicios de respaldo, almacenarás estos valores en un archivo protegido con Secret Manager.

Secret Manager te permite almacenar, administrar y acceder a los secretos como BLOB binarios o cadenas de texto. Es eficaz para almacenar información de configuración, como contraseñas de bases de datos, claves de API o certificados TLS que necesita una aplicación en el entorno de ejecución.

Primero, crea un archivo con los valores de la cadena de conexión de la base de datos, el bucket de medios, una clave secreta para Django (que se usa para la firma criptográfica de sesiones y tokens) y para habilitar la depuración:

echo DATABASE_URL=\"postgres://djuser:${DJPASS}@//cloudsql/${PROJECT_ID}:${REGION}:myinstance/mydatabase\" > .env

echo GS_BUCKET_NAME=\"${GS_BUCKET_NAME}\" >> .env

echo SECRET_KEY=\"$(cat /dev/urandom | LC_ALL=C tr -dc 'a-zA-Z0-9' | fold -w 50 | head -n 1)\" >> .env

echo DEBUG=True >> .env

Luego, crea un secreto llamado application_settings con ese archivo como secreto:

gcloud secrets create application_settings --data-file .env

Permite que la cuenta de servicio acceda a este secreto:

gcloud secrets add-iam-policy-binding application_settings \
  --member serviceAccount:${SERVICE_ACCOUNT} --role roles/secretmanager.secretAccessor

Confirma que se creó el secreto enumerando los secretos:

gcloud secrets versions list application_settings

Después de confirmar que se creó el secreto, quita el archivo local:

rm .env

6. Configura tu aplicación

Teniendo en cuenta los servicios de respaldo que acabas de crear, deberás realizar algunos cambios en el proyecto de plantilla para que se adapte.

Esto incluirá la introducción de django-environ para usar variables de entorno como parámetros de configuración, que inicializarás con los valores que definiste como secretos. Para implementar esto, extenderás la configuración de la plantilla. También deberás agregar dependencias adicionales de Python.

Configurar los parámetros

Mueve el archivo settings.py y cámbiale el nombre a basesettings.py:.

mv myproject/settings.py myproject/basesettings.py

Con el editor web de Cloud Shell, crea un archivo settings.py nuevo con el siguiente código:

touch myproject/settings.py
cloudshell edit myproject/settings.py

myproject/settings.py

import io
import os
from urllib.parse import urlparse

import environ

# Import the original settings from each template
from .basesettings import *

# Load the settings from the environment variable
env = environ.Env()
env.read_env(io.StringIO(os.environ.get("APPLICATION_SETTINGS", None)))

# Setting this value from django-environ
SECRET_KEY = env("SECRET_KEY")

# Ensure myproject is added to the installed applications
if "myproject" not in INSTALLED_APPS:
    INSTALLED_APPS.append("myproject")

# If defined, add service URLs to Django security settings
CLOUDRUN_SERVICE_URLS = env("CLOUDRUN_SERVICE_URLS", default=None)
if CLOUDRUN_SERVICE_URLS:
    CSRF_TRUSTED_ORIGINS = env("CLOUDRUN_SERVICE_URLS").split(",")
    # Remove the scheme from URLs for ALLOWED_HOSTS
    ALLOWED_HOSTS = [urlparse(url).netloc for url in CSRF_TRUSTED_ORIGINS]
else:
    ALLOWED_HOSTS = ["*"]

# Default false. True allows default landing pages to be visible
DEBUG = env("DEBUG", default=False)

# Set this value from django-environ
DATABASES = {"default": env.db()}

# Change database settings if using the Cloud SQL Auth Proxy
if os.getenv("USE_CLOUD_SQL_AUTH_PROXY", None):
    DATABASES["default"]["HOST"] = "127.0.0.1"
    DATABASES["default"]["PORT"] = 5432

# Define static storage via django-storages[google]
GS_BUCKET_NAME = env("GS_BUCKET_NAME")
STATICFILES_DIRS = []
GS_DEFAULT_ACL = "publicRead"
STORAGES = {
    "default": {
        "BACKEND": "storages.backends.gcloud.GoogleCloudStorage",
    },
    "staticfiles": {
        "BACKEND": "storages.backends.gcloud.GoogleCloudStorage",
    },
}

Tómate tu tiempo para leer los comentarios que se agregaron sobre cada configuración.

Ten en cuenta que es posible que veas errores de linting en este archivo. Esta situación es esperable. Cloud Shell no tiene contexto de los requisitos de este proyecto y, por lo tanto, puede informar importaciones no válidas y sin usar.

Dependencias de Python

Busca el archivo requirements.txt y agrega los siguientes paquetes:

cloudshell edit requirements.txt

requirements.txt (agregar)

gunicorn
psycopg2-binary
django-storages[google]
django-environ

Define la imagen de tu aplicación

Cloud Run ejecutará cualquier contenedor, siempre y cuando cumpla con el Contrato de Contenedores de Cloud Run. En este instructivo, se opta por omitir un Dockerfile y, en su lugar, se usan paquetes de compilación nativos de la nube. Los paquetes de compilación ayudan a compilar contenedores para lenguajes comunes, incluido Python.

En este instructivo, se opta por personalizar el objeto Procfile que se usa para iniciar la aplicación web.

Para crear contenedores para el proyecto de plantilla, primero crea un archivo nuevo llamado Procfile en el nivel superior de tu proyecto (en el mismo directorio que manage.py) y copia el siguiente contenido:

touch Procfile
cloudshell edit Procfile

Procfile

web: gunicorn --bind 0.0.0.0:$PORT --workers 1 --threads 8 --timeout 0 myproject.wsgi:application

7. Configura, compila y ejecuta los pasos de migración

Para crear el esquema de la base de datos en tu base de datos de Cloud SQL y completar tu bucket de Cloud Storage con tus recursos estáticos, debes ejecutar migrate y collectstatic.

Estos comandos de migración de Django básicos deben ejecutarse en el contexto de la imagen de contenedor compilada con acceso a tu base de datos.

También deberás ejecutar createsuperuser para crear una cuenta de administrador y acceder al administrador de Django.

Para ello, usarás Cloud Run Jobs para realizar estas tareas. Los trabajos de Cloud Run te permiten ejecutar procesos que tienen un final definido, lo que los hace ideales para tareas de administración.

Define la contraseña de superusuario de Django

Para crear el superusuario, usarás la versión no interactiva del comando createsuperuser. Este comando requiere una variable de entorno con un nombre especial para usarla en lugar de una solicitud para ingresar la contraseña.

Crea un secreto nuevo con una contraseña generada de forma aleatoria:

echo -n $(cat /dev/urandom | LC_ALL=C tr -dc 'a-zA-Z0-9' | fold -w 30 | head -n 1) | gcloud secrets create django_superuser_password --data-file=-

Permite que tu cuenta de servicio acceda a este secreto:

gcloud secrets add-iam-policy-binding django_superuser_password \
  --member serviceAccount:${SERVICE_ACCOUNT} \
  --role roles/secretmanager.secretAccessor

Actualiza tu Procfile

Para que tus trabajos de Cloud Run sean más claros, crea accesos directos en tu Procfile y agrega los siguientes puntos de entrada a Procfile:

migrate: python manage.py migrate && python manage.py collectstatic --noinput --clear
createuser: python manage.py createsuperuser --username admin --email [e-mail] --noinput

Ahora deberías tener tres entradas: el punto de entrada web predeterminado, el punto de entrada migrate para aplicar migraciones de bases de datos y el punto de entrada createuser para ejecutar el comando createsuperuser.

Compila la imagen de tu aplicación

Con las actualizaciones de tu Procfile, compila la imagen:

gcloud builds submit --pack image=${ARTIFACT_REGISTRY}/myimage

Crea trabajos de Cloud Run

Ahora que existe la imagen, puedes crear trabajos de Cloud Run con ella.

Estos trabajos usan la imagen compilada anteriormente, pero usan diferentes valores de command. Estos se asignan a los valores de Procfile.

Crea un trabajo para la migración:

gcloud run jobs create migrate \
  --region $REGION \
  --image ${ARTIFACT_REGISTRY}/myimage \
  --set-cloudsql-instances ${PROJECT_ID}:${REGION}:myinstance \
  --set-secrets APPLICATION_SETTINGS=application_settings:latest \
  --service-account $SERVICE_ACCOUNT \
  --command migrate

Crea un trabajo para la creación del usuario:

gcloud run jobs create createuser \
  --region $REGION \
  --image ${ARTIFACT_REGISTRY}/myimage \
  --set-cloudsql-instances ${PROJECT_ID}:${REGION}:myinstance \
  --set-secrets APPLICATION_SETTINGS=application_settings:latest \
  --set-secrets DJANGO_SUPERUSER_PASSWORD=django_superuser_password:latest \
  --service-account $SERVICE_ACCOUNT \
  --command createuser

Ejecutar trabajos de Cloud Run

Con las configuraciones de trabajo implementadas, ejecuta las migraciones:

gcloud run jobs execute migrate --region $REGION --wait

Asegúrate de que el resultado de este comando indique que la ejecución se "completó correctamente".

Ejecutarás este comando más adelante cuando actualices tu aplicación.

Con la base de datos configurada, crea el usuario con el trabajo:

gcloud run jobs execute createuser --region $REGION --wait

Asegúrate de que el resultado de este comando indique que la ejecución se "completó correctamente".

No tendrás que volver a ejecutar este comando.

8. Implementa en Cloud Run

Una vez que se crearon y completaron los servicios de respaldo, puedes crear el servicio de Cloud Run para acceder a ellos.

La implementación inicial de tu aplicación alojada en contenedores en Cloud Run se crea con el siguiente comando:

gcloud run deploy djangocms-cloudrun \
  --region $REGION \
  --image ${ARTIFACT_REGISTRY}/myimage \
  --set-cloudsql-instances ${PROJECT_ID}:${REGION}:myinstance \
  --set-secrets APPLICATION_SETTINGS=application_settings:latest \
  --service-account $SERVICE_ACCOUNT \
  --allow-unauthenticated

Espera un momento a que finalice la implementación. Si la operación es exitosa, la línea de comandos mostrará la URL de servicio:

Service [djangocms-cloudrun] revision [djangocms-cloudrun-00001-...] has been deployed and is serving 100 percent of traffic.
Service URL: https://djangocms-cloudrun-...run.app

Ahora puedes abrir esta URL en un navegador web para visitar el contenedor implementado:

Como se trata de una instalación nueva, se te redireccionará automáticamente a la página de acceso.

9. Cómo acceder al administrador de Django

Una de las principales características de Django CMS es su administrador interactivo.

Actualiza la configuración de CSRF

Cambio en Django 4.0: Ahora se aplica la verificación del encabezado CSRF Origin. Consulta la documentación de Django.

Django incluye protecciones contra la falsificación de solicitudes entre sitios (CSRF). Cada vez que se envía un formulario en tu sitio de Django, incluido el acceso al administrador de Django, se verifica el parámetro de configuración de orígenes de confianza. Si no coincide con el origen de la solicitud, Django devuelve un error.

En el archivo mysite/settings.py, si se define la variable de entorno CLOUDRUN_SERVICE_URL, se usa en la configuración de CSRF_TRUSTED_ORIGINS y ALLOWED_HOSTS. Si bien no es obligatorio definir ALLOWED_HOSTS, se recomienda agregarlo, ya que ya es obligatorio para CSRF_TRUSTED_ORIGINS.

Como necesitas la URL del servicio, esta configuración no se puede agregar hasta después de la primera implementación.

Deberás actualizar tu servicio para agregar esta variable de entorno. Se puede agregar al secreto application_settings o directamente como una variable de entorno.

La siguiente implementación aprovecha el formato y el escape de gcloud.

Recupera la URL de tu servicio:

CLOUDRUN_SERVICE_URLS=$(gcloud run services describe djangocms-cloudrun \
  --region $REGION  \
  --format "value(metadata.annotations[\"run.googleapis.com/urls\"])" | tr -d '"[]')
echo $CLOUDRUN_SERVICE_URLS

Establece este valor como una variable de entorno en tu servicio de Cloud Run:

gcloud run services update djangocms-cloudrun \
  --region $REGION \
  --update-env-vars "^##^CLOUDRUN_SERVICE_URLS=$CLOUDRUN_SERVICE_URLS"

Accede al administrador de Django

Para acceder a la interfaz de administrador de Django, agrega /admin a la URL de tu servicio.

Ahora accede con el nombre de usuario "admin" y recupera tu contraseña con el siguiente comando:

gcloud secrets versions access latest --secret django_superuser_password && echo ""

10. Cómo aplicar actualizaciones de la aplicación

A medida que desarrolles tu aplicación, querrás probarla de forma local. Para ello, deberás conectarte a tu base de datos de Cloud SQL ("producción") o a una base de datos local ("prueba").

Conéctate a tu base de datos de producción

Puedes conectarte a tus instancias de Cloud SQL con el proxy de Cloud SQL Auth. Esta aplicación crea una conexión desde tu máquina local a la base de datos.

Una vez que hayas instalado el proxy de Cloud SQL Auth, sigue estos pasos:

# Create a virtualenv
virtualenv venv
source venv/bin/activate
pip install -r requirements.txt

# Copy the application settings to your local machine
gcloud secrets versions access latest --secret application_settings > temp_settings

# Run the Cloud SQL Auth Proxy
./cloud-sql-proxy ${PROJECT_ID}:${REGION}:myinstance

# In a new tab, start the local web server using these new settings
USE_CLOUD_SQL_AUTH_PROXY=true APPLICATION_SETTINGS=$(cat temp_settings) python manage.py runserver

Asegúrate de quitar el archivo temp_settings después de terminar tu trabajo.

Conéctate a una base de datos local de SQLite

Como alternativa, puedes usar una base de datos local cuando desarrolles tu aplicación. Django admite bases de datos PostgreSQL y SQLite, y hay algunas funciones que PostgreSQL tiene y SQLite no, pero, en muchos casos, la funcionalidad es idéntica.

Para configurar SQLite, deberás actualizar la configuración de tu aplicación para que apunte a una base de datos local y, luego, deberás aplicar tus migraciones de esquema.

Para configurar este método, sigue estos pasos:

# Create a virtualenv
virtualenv venv
source venv/bin/activate
pip install -r requirements.txt

# Copy the application settings to your local machine
gcloud secrets versions access latest --secret application_settings > temp_settings

# Edit the DATABASE_URL setting to use a local sqlite file. For example:
DATABASE_URL=sqlite:////tmp/my-tmp-sqlite.db

# Set the updated settings as an environment variable
APPLICATION_SETTINGS=$(cat temp_settings) 

# Apply migrations to the local database
python manage.py migrate

# Start the local web server
python manage.py runserver

Asegúrate de quitar el archivo temp_settings después de terminar tu trabajo.

Creando migraciones

Cuando realices cambios en los modelos de tu base de datos, es posible que debas generar los archivos de migración de Django ejecutando python manage.py makemigrations.

Puedes ejecutar este comando después de configurar la conexión de la base de datos de producción o de prueba. Como alternativa, puedes generar los archivos de migración sin una base de datos proporcionando una configuración vacía:

SECRET_KEY="" DATABASE_URL="" GS_BUCKET_NAME="" python manage.py makemigrations

Cómo aplicar actualizaciones de la aplicación

Para aplicar cambios a tu aplicación, deberás hacer lo siguiente:

• compila tus cambios en una imagen nueva
• aplicar cualquier migración estática o de base de datos
• Actualiza tu servicio de Cloud Run para usar la imagen nueva.

Para compilar tu imagen, haz lo siguiente:

gcloud builds submit --pack image=${ARTIFACT_REGISTRY}/myimage

Si tienes migraciones para aplicar, ejecuta el trabajo de Cloud Run:

gcloud run jobs execute migrate --region $REGION --wait

Para actualizar tu servicio con la nueva imagen, haz lo siguiente:

gcloud run services update djangocms-cloudrun \
  --platform managed \
  --region $REGION \
  --image gcr.io/${PROJECT_ID}/myimage

11. ¡Felicitaciones!

Acabas de implementar un proyecto complejo en Cloud Run.

• Cloud Run escala la imagen del contenedor automáticamente y de forma horizontal para controlar las solicitudes que se reciben y, luego, reduce la escala verticalmente cuando disminuye la demanda. Solo debes pagar por la CPU, la memoria y las herramientas de redes que se utilicen durante la administración de la solicitud.
• Cloud SQL te permite aprovisionar una instancia de PostgreSQL administrada que se mantiene automáticamente y se integra de forma nativa en muchos sistemas de Google Cloud.
• Cloud Storage te permite tener almacenamiento en la nube de una manera que es accesible sin problemas en Django.
• Secret Manager te permite almacenar secretos y hacer que sean accesibles para ciertas partes de Google Cloud y no para otras.

Si bien este breve lab se realizó con la línea de comandos de gcloud, Cloud Run está disponible a través de Cloud Console ( console.cloud.google.com). Simplemente navega a Compute > Cloud Run y verás tu servicio en la lista.

Realiza una limpieza

Sigue estos pasos para evitar que se apliquen cargos a tu cuenta de Google Cloud Platform para los recursos que se usaron en este instructivo:

• En la consola de Cloud, ve a la página Administrar recursos.
• En la lista de proyectos, selecciona el tuyo y haz clic en Borrar.
• En el diálogo, escribe el ID del proyecto y, luego, haz clic en Cerrar para borrarlo.

Más información

• Django en Cloud Run: https://cloud.google.com/python/django/run
• Hello Cloud Run con Python: https://codelabs.developers.google.com/codelabs/cloud-run-hello-python3
• Python en Google Cloud: https://cloud.google.com/python
• Cliente de Python de Google Cloud: https://github.com/googleapis/google-cloud-python