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

Wagtail es un sistema de administración de contenido (CMS) de código abierto creado en 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 Wagtail.

Nota: La última vez que se verificó este codelab fue con Wagtail 5.2.2, que es compatible con Django 5.

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 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 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 realizó la autenticación 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 autenticar 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. 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].

Nota: Si estás completando este instructivo fuera de Cloud Shell, sigue Configura 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

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 la plantilla predeterminada del proyecto de Wagtail como tu proyecto de muestra de Wagtail. Para ello, instalarás temporalmente Wagtail a fin de generar la plantilla.

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

mkdir ~/wagtail-cloudrun
cd ~/wagtail-cloudrun

Luego, instala Wagtail en un entorno virtual temporal:

virtualenv venv
source venv/bin/activate
pip install wagtail

Luego, crea un nuevo proyecto de plantilla en la carpeta actual:

wagtail start myproject .

Ahora tendrás un proyecto de plantilla de Wagtail en la carpeta actual:

ls -F

Dockerfile  home/  manage.py*  myproject/  requirements.txt  search/ venv/

Ahora puedes salir y quitar el entorno virtual temporal:

deactivate
rm -rf venv

Desde aquí, se llamará a Wagtail 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 base, 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 en todo el mundo, no todos están disponibles 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. Configura 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 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 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 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 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 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 secreto

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. 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 para la string 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 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

El proyecto de plantilla que creaste anteriormente ahora necesita algunas alteraciones. Estos cambios reducirán la complejidad de la configuración de plantillas que incluye Wagtail y también integrarán Wagtail con los servicios de copia de seguridad que creaste anteriormente.

Opciones de configuración

Busca el archivo de configuración base.py generado y cámbiale el nombre a basesettings.py en la carpeta myproject principal:

mv myproject/settings/base.py myproject/basesettings.py

Con el editor web de Cloud Shell, crea un nuevo archivo settings.py 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 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.

Luego, quita la carpeta de configuración anterior.

rm -rf myproject/settings/

A continuación, tendrás dos archivos de configuración: uno de Wagtail y otro que acabas de crear para compilar a partir de estos parámetros de configuración:

ls myproject/*settings*

myproject/basesettings.py  myproject/settings.py

Por último, abre el archivo de configuración manage.py y actualiza la configuración para indicarle a Wagtail que apunte al archivo settings.py principal.

cloudshell edit manage.py

Línea de manage.py (antes)

os.environ.setdefault("DJANGO_SETTINGS_MODULE", "myproject.settings.dev")

Línea de manage.py (después)

os.environ.setdefault("DJANGO_SETTINGS_MODULE", "myproject.settings")

Realiza el mismo cambio de configuración para el archivo myproject/wsgi.py:

cloudshell edit myproject/wsgi.py

Línea myproject/wsgi.py (antes)

os.environ.setdefault("DJANGO_SETTINGS_MODULE", "myproject.settings.dev")

Línea myproject/wsgi.py (después)

os.environ.setdefault("DJANGO_SETTINGS_MODULE", "myproject.settings")

Quita el Dockerfile creado de forma automática:

rm Dockerfile

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

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 los 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 de Django básicos deben ejecutarse en el contexto de la imagen de contenedor compilada con acceso a tu base de datos.

También tendrás que 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 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 la imagen existe, puedes usarla para crear trabajos de Cloud Run.

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 del comando indique 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.

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

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

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 [wagtail-cloudrun] revision [wagtail-cloudrun-00001-...] has been deployed and is serving 100 percent of traffic.
Service URL: https://wagtail-cloudrun-...run.app

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

9. Accede al administrador de Django

Actualizar la configuración de CSRF

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

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. Podría agregarse al secreto application_settings o agregarse directamente como una variable de entorno.

La siguiente implementación aprovecha el formateo y el escaping de gcloud.

Recupera la URL de tu servicio:

CLOUDRUN_SERVICE_URLS=$(gcloud run services describe wagtail-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 wagtail-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 a través del proxy de autenticación de Cloud SQL. 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 --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 que, en muchos casos, es idéntica.

Para configurar SQLite, deberás actualizar la configuración de la aplicación para que apunte a una base de datos local y, luego, deberás aplicar las 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

Aplicación de actualizaciones de aplicaciones

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

• compilar los cambios en una imagen nueva
• 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, 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, haz lo siguiente:

gcloud run services update wagtail-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 disponer de almacenamiento en la nube de un modo al 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 lab breve se realizó con la línea de comandos de gcloud, Cloud Run está disponible en la consola de Cloud ( console.cloud.google.com). Simplemente navega hasta 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

/