Django CMS en Cloud Run

Django CMS en Cloud Run

Acerca de este codelab

subjectÚltima actualización: ene 31, 2024
account_circleEscrito por Katie McLaughlin

1. Introducción

894762ebb681671c.png

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 interactúa de forma nativa con muchas otras partes del ecosistema de Google Cloud, incluido Cloud SQL para bases de datos administradas, Cloud Storage para el almacenamiento unificado de objetos y Secret Manager para la administración de secretos.

Django CMS es un sistema de administración de contenido empresarial (CMS) creado a partir de Django. Django es un framework web de alto nivel de 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 3.11.4 a django-cms/cms-template v3.11.

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 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.

fbef9caa1602edd0.png

a99b7ace416376c4.png

5e3ff691252acf41.png

  • 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.
  1. 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 Shell853e55310c205094.png.

8c1dabeca90e44e5.png

Si es la primera vez que inicias Cloud Shell, verás una pantalla intermedia que describe en qué consiste. Si apareció una pantalla intermedia, haz clic en Continuar.

9c92662c6a846a5c.png

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

9f0e51b578fecce5.png

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 mejora 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 estás autenticado y que el proyecto está configurado con tu ID del proyecto.

  1. 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`
  1. Ejecuta el siguiente comando en Cloud Shell para confirmar que el comando de 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].

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

Dado que es la primera vez que llamas a las APIs desde gcloud, se te pedirá autorización con 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 Django CMS cms-template 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-3]

Crea una copia del proyecto cms-template:

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

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

ls -F
manage.py*  media/  myproject/  project.db  requirements.in requirements.txt  static/ venv/

Ahora puedes salir y quitar el entorno virtual temporal:

deactivate
rm -rf venv

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

También puedes quitar el archivo requirements.in copiado automáticamente (que usa pip-tools para generar archivos requirements.txt). No se usará en este codelab:

rm requirements.in

5. Crea los servicios de copia de seguridad

Ahora crearás tus servicios de copia de seguridad: una cuenta de servicio dedicada, un 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 las contraseñas accidentalmente donde no pertenecen (por ejemplo, directamente en los archivos de configuración o escribidas directamente en tu terminal, donde se podrían recuperar del historial).

Para comenzar, establece dos variables de entorno base, una para el ID del proyecto:

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

Y uno para la región:

REGION=us-central1

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 futuras 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 repositorio 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

En secciones futuras de este codelab, harás referencia a este registro por nombre:

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 ese caso, 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 que se conecte 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 para que la cuenta de servicio administre 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 del bucket en lugar de una URL de Cloud Run), debes establecer la configuración del 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 Secret

Luego de configurar los servicios de copia de seguridad, 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 tiempo de ejecución.

Primero, crea un archivo con los valores para la string de conexión de la base de datos, el bucket de medios, una clave secreta para Django (que se utiliza para la firma criptográfica de las sesiones y los 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

Genera una lista de los secretos para confirmar que se creó:

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

Dados los servicios de copia de seguridad que acabas de crear, deberás realizar algunos cambios en el proyecto de plantilla.

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, debes extender la configuración de la plantilla. También deberás agregar dependencias adicionales de Python.

Establecer 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 URL to Django security settings
CLOUDRUN_SERVICE_URL
= env("CLOUDRUN_SERVICE_URL", default=None)
if CLOUDRUN_SERVICE_URL:
    ALLOWED_HOSTS
= [urlparse(CLOUDRUN_SERVICE_URL).netloc]
    CSRF_TRUSTED_ORIGINS
= [CLOUDRUN_SERVICE_URL]
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
= []
DEFAULT_FILE_STORAGE
= "storages.backends.gcloud.GoogleCloudStorage"
STATICFILES_STORAGE
= "storages.backends.gcloud.GoogleCloudStorage"
GS_DEFAULT_ACL
= "publicRead"

Tómate el tiempo para leer los comentarios agregados sobre cada configuración.

Ten en cuenta que puede que veas errores de análisis con 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, es posible que informe importaciones no válidas y sin usar.

Dependencias de Python

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

cloudshell edit requirements.txt

requirements.txt (agregar)

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

Imagen de Define tu aplicación

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

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

Para alojar 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 pasos de migración

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

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

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

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 tu contraseña de superusuario de Django

Para crear el superusuario, usarás la versión no interactiva del comando createsuperuser. Este comando requiere que se use una variable de entorno con un nombre especial en lugar de un mensaje 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 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 noop@example.com --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.

Imagen de Compila 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 la imagen existe, puedes usarla para crear trabajos de Cloud Run.

Estos trabajos usan la imagen que se compiló antes, 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

Ejecutar trabajos de Cloud Run

Con los parámetros de configuración del trabajo establecidos, ejecuta las migraciones:

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

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

Ejecutarás este comando más adelante cuando actualices 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 del 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 creados y propagados los servicios de copia de seguridad, 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 \
  --platform managed \
  --region $REGION \
  --image gcr.io/${PROJECT_ID}/myimage \
  --set-cloudsql-instances ${PROJECT_ID}:${REGION}:myinstance \
  --set-secrets APPLICATION_SETTINGS=application_settings:latest \
  --service-account $SERVICE_ACCOUNT \
  --allow-unauthenticated

Espere 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-...-uc.a.run.app

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

e54d1a1486427431.png

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

9. Accede al administrador de Django

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

Actualizar la configuración de CSRF

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 marca 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 CSRF_TRUSTED_ORIGINS y ALLOWED_HOSTS. Si bien definir ALLOWED_HOSTS no es obligatorio, te recomendamos que lo agregues, ya que ya es obligatorio para CSRF_TRUSTED_ORIGINS.

Dado que necesitas la URL del servicio, no podrás agregar esta configuración hasta después de la primera implementación.

Deberás actualizar tu servicio para agregar esta variable de entorno. Podría agregarse al Secret application_settings o agregarse directamente como una variable de entorno.

Recupera la URL de servicio:

CLOUDRUN_SERVICE_URL=$(gcloud run services describe djangocms-cloudrun \
  --platform managed \
  --region $REGION  \
  --format "value(status.url)")
echo $CLOUDRUN_SERVICE_URL

Configura 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_URL=$CLOUDRUN_SERVICE_URL

Accede al administrador de Django

Para acceder a la interfaz de administrador de Django, agrega /admin a tu URL de 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 ""

13d77046e2e7427.png

10. Aplicación de actualizaciones de aplicaciones

A medida que desarrolles tu aplicación, querrás probarla de forma local. Para hacerlo, 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 a través del proxy de autenticación de Cloud SQL. Esta aplicación crea una conexión entre tu máquina local y la base de datos.

Una vez que instales el proxy de autenticación de Cloud SQL, 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 --instances=${PROJECT_ID}:${REGION}:myinstance=tcp:5432

# 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 es compatible con bases de datos 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 apuntar a una base de datos local y, luego, aplicar las migraciones de esquemas.

Para configurar este método, haz lo siguiente:

# 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 base de datos, es posible que debas ejecutar python manage.py makemigrations para generar los archivos de migración de Django.

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

Aplicación de actualizaciones de aplicaciones

Para aplicar cambios en tu aplicación, necesitarás lo siguiente:

  • compilar los cambios en una nueva imagen
  • aplicar cualquier migración de base de datos o estática y, luego,
  • actualiza tu servicio de Cloud Run para usar la imagen nueva.

Para compilar tu imagen, sigue estos pasos:

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, 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 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 que se integra de forma nativa en muchos sistemas de Google Cloud.
  • Cloud Storage te permite disponer de almacenamiento en la nube de un modo al que se puede acceder sin problemas en Django.
  • Secret Manager te permite almacenar Secrets y hacer que se pueda acceder a ellos a través de ciertas partes de Google Cloud y no de otras.

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