Acerca de este codelab
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 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
- 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.
- 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
- En la consola de Cloud, haz clic en Activar Cloud Shell
.
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.
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 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.
- 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`
- 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:
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 ""
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
- 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 Google Cloud para Python: https://github.com/googleapis/google-cloud-python