Django 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 quita la complejidad de la administración de la infraestructura para que puedas enfocarte en lo que más importa: compilar aplicaciones extraordinarias.

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

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.

Nota: La última vez que se verificó este codelab fue con Django 5.0. A menos que haya cambios drásticos en actualizaciones futuras, este codelab debería seguir funcionando. Consulta las notas de las versiones futuras de Django.

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 Secrets desde 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 implementar 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 describe qué es. Si aparece 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 se te autenticó y que el proyecto se configuró con tu ID de 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. Verás que admite el autocompletado con la tecla Tab. Es posible que se te solicite autenticarte 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 las instrucciones 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 sucederá 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 la plantilla de proyecto de Django predeterminada como tu proyecto de Django de ejemplo.

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

mkdir ~/django-cloudrun
cd ~/django-cloudrun

Luego, instala Django en un entorno virtual temporal:

virtualenv venv
source venv/bin/activate
pip install Django

Guarda la lista de paquetes instalados en requirements.txt.

pip freeze > requirements.txt

Esta lista debe incluir Django y sus dependencias: sqlparse y asgiref.

Luego, crea un nuevo proyecto de plantilla:

django-admin startproject myproject .

Obtendrás un archivo nuevo llamado manage.py y una carpeta nueva llamada myproject, que contendrá varios archivos, incluido un settings.py.

Confirma que el contenido de la carpeta de nivel superior sea el esperado:

ls -F

manage.py myproject/ requirements.txt venv/

Confirma que el contenido de la carpeta myproject sea el esperado:

ls -F myproject/

__init__.py asgi.py settings.py  urls.py  wsgi.py

Ahora puedes salir de tu entorno virtual temporal y quitarlo:

deactivate
rm -rf venv

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

5. Crea los servicios de copia de seguridad

Ahora, crearás tus servicios de respaldo: una cuenta de servicio dedicada, un Artifact Registry, una base de datos de Cloud SQL, un bucket de Cloud Storage y una serie de 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 por accidente donde no pertenecen (por ejemplo, directamente en los archivos de configuración o escritos directamente en la 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 uno para la región:

REGION=us-central1

Cuando trabajas con 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 global, 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 compatible con 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 secciones posteriores 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 Artifact Registry

Para almacenar la imagen del 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 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

Almacena la configuración como secreto

Después de configurar los servicios de copia de seguridad, ahora 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. Funciona bien 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 contenido multimedia, 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 y usa 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

Para confirmar que se creó el secreto, muestra una lista de 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

Dado que acabas de crear los servicios de respaldo, deberás hacer algunos cambios en el proyecto de plantilla para que se ajusten.

Esto incluirá la introducción de django-environ para usar variables de entorno como parámetros de configuración, que propagará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.

Configura la configuración

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 el tiempo para leer los comentarios agregados sobre cada configuración.

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

Dependencias de Python

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

cloudshell edit requirements.txt

requirements.txt (adición)

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

Define la imagen de tu aplicación

Cloud Run ejecutará cualquier contenedor, siempre que cumpla con el Contrato de Contenedores de Cloud Run. En este instructivo, se omite un Dockerfile, pero 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 elige personalizar el Procfile que se usa para iniciar la aplicación web.

Para organizar el proyecto de plantilla en contenedores, 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 propagar 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 trabajos de Cloud Run 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 del 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 usar en lugar de un mensaje que solicite 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 mejorar la claridad de tus trabajos de Cloud Run, crea atajos 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 predeterminado web, el punto de entrada migrate para aplicar migraciones de bases de datos y el punto de entrada createuser para ejecutar el comando createsuperuser.

Cómo compilar la imagen de tu aplicación

Con las actualizaciones de Procfile implementadas, 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 valores command diferentes. 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

Ejecuta trabajos de Cloud Run

Con las configuraciones de trabajo establecidas, ejecuta las migraciones:

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

Asegúrate de que el resultado de este comando diga que la ejecución se “completó correctamente”.

Ejecutarás este comando más adelante cuando realices actualizaciones en tu aplicación.

Con la configuración de la base de datos, crea el usuario con el trabajo:

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

Asegúrate de que el resultado de este comando diga que la ejecución se “completó correctamente”.

No tendrás que volver a ejecutar este comando.

8. Implementa en Cloud Run

Ahora que se crearon y propagaron los servicios de copia de seguridad, puedes crear el servicio de Cloud Run para acceder a ellos.

Usa el siguiente comando para implementar el servicio en Cloud Run con la imagen que compilaste antes:

gcloud run deploy django-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

Si la operación es exitosa, la línea de comandos mostrará la URL de servicio:

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

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

9. Accede al administrador de Django

Una de las funciones principales de Django es su administrador interactivo.

Actualiza la configuración de CSRF

Se modificó en Django 4.0: Ahora se aplica la verificación del encabezado de origen de CSRF. 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 la configuración de Orígenes de confianza. Si no coincide con el origen de la solicitud, Django muestra 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 es obligatorio para CSRF_TRUSTED_ORIGINS.

Debido a que necesitas la URL de tu servicio, esta configuración no se puede agregar hasta después de tu primera implementación.

Tendrás que 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 la escaping de gcloud.

Recupera las URLs de tu servicio:

CLOUDRUN_SERVICE_URLS=$(gcloud run services describe django-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 django-cloudrun \
  --region $REGION \
  --update-env-vars "^##^CLOUDRUN_SERVICE_URLS=$CLOUDRUN_SERVICE_URLS"

Cómo acceder al administrador de Django

Para acceder a la interfaz de administración 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. Desarrollo de tu 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.

Cómo conectarse a una base de datos SQLite local

Como alternativa, puedes usar una base de datos local cuando desarrolles tu aplicación. Django admite bases de datos de PostgreSQL y SQLite, y PostgreSQL tiene algunas funciones que SQLite no tiene, 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 esquemas.

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 tus modelos de 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 si proporcionas una configuración vacía:

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

Cómo aplicar actualizaciones de aplicaciones

Para aplicar los cambios a tu solicitud, deberás hacer lo siguiente:

• compilar los cambios en una imagen nueva
• aplicar cualquier base de datos o migraciones estáticas y, luego,
• 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 alguna migración que aplicar, ejecuta el trabajo de Cloud Run:

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

Para actualizar tu servicio con la imagen nueva, sigue estos pasos:

gcloud run services update django-cloudrun \
  --region $REGION \
  --image ${ARTIFACT_REGISTRY}/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 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 a la que se puede acceder sin problemas en Django.
• Secret Manager te permite almacenar secretos y permitir que ciertas partes de Google Cloud accedan a ellos y otras no.

Si bien este breve lab se realizó con la línea de comandos de gcloud, Cloud Run está disponible a través de la consola de Cloud ( console.cloud.google.com). Simplemente navega a Compute > Cloud Run y deberías ver 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
• Hola 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