CMS do Django no Cloud Run

1. Introdução

O Cloud Run é uma plataforma de computação gerenciada onde você executa contêineres sem estado que podem ser invocados usando solicitações HTTP. O Cloud Run não tem servidor. Ele cuida de todo o gerenciamento da infraestrutura para que você possa se concentrar no que mais importa: criar aplicativos incríveis.

Ele também se conecta de forma nativa a muitas outras partes do ecossistema do Google Cloud, incluindo o Cloud SQL para bancos de dados gerenciados, o Cloud Storage para armazenamento unificado de objetos e o Secret Manager para gerenciar secrets.

O Django CMS é um sistema de gerenciamento de conteúdo (CMS) empresarial criado com base no Django. O Django é um framework da Web em Python de alto nível.

Neste tutorial, você vai usar esses componentes para implantar um pequeno projeto do Django CMS.

Observação: este codelab foi verificado pela última vez com o Django CMS 4.1.2 usando o django-cms/cms-template v4.1.

O que você vai aprender

• Como usar o Cloud Shell
• Como criar um banco de dados do Cloud SQL
• Como criar um bucket do Cloud Storage
• Como criar secrets do Secret Manager
• Como usar secrets de diferentes serviços do Google Cloud
• Como conectar componentes do Google Cloud a um serviço do Cloud Run
• Como usar o Container Registry para armazenar contêineres criados
• Como implantar no Cloud Run
• Como executar migrações de esquema de banco de dados no Cloud Build

2. Configuração e requisitos

Configuração de ambiente autoguiada

1. Faça login no Console do Google Cloud e crie um novo projeto ou reutilize um existente. Crie uma conta do Gmail ou do Google Workspace, se ainda não tiver uma.

• O Nome do projeto é o nome de exibição para os participantes do projeto. É uma string de caracteres não usada pelas APIs do Google e pode ser atualizada quando você quiser.
• O ID do projeto precisa ser exclusivo em todos os projetos do Google Cloud e não pode ser mudado após a definição. O console do Cloud gera automaticamente uma string exclusiva. Em geral, não importa o que seja. Na maioria dos codelabs, é necessário fazer referência ao ID do projeto, normalmente identificado como PROJECT_ID. Se você não gostar do ID gerado, crie outro aleatório. Se preferir, teste o seu e confira se ele está disponível. Ele não pode ser mudado após essa etapa e permanece durante o projeto.
• Para sua informação, há um terceiro valor, um Número do projeto, que algumas APIs usam. Saiba mais sobre esses três valores na documentação.

Atenção: o ID do projeto é globalmente exclusivo e não pode ser usado por outras pessoas após a seleção. Você é o único usuário com esse ID. Mesmo que um projeto seja excluído, o ID não poderá ser usado novamente.

Observação: se você usa uma conta do Gmail, defina o local padrão como Sem organização. Se você usa uma conta do Google Workspace, escolha um local adequado para a organização.

2. Em seguida, ative o faturamento no console do Cloud para usar os recursos/APIs do Cloud. A execução deste codelab não vai ser muito cara, se tiver algum custo. Para encerrar os recursos e evitar cobranças além deste tutorial, exclua os recursos criados ou exclua o projeto. Novos usuários do Google Cloud estão qualificados para o programa de US$ 300 de avaliação sem custos.

Google Cloud Shell

Embora o Google Cloud possa ser operado remotamente em seu laptop, neste codelab vamos usar o Google Cloud Shell, um ambiente de linha de comando executado no Cloud.

Ativar o Cloud Shell

1. No Console do Cloud, clique em Ativar o Cloud Shell.

Se esta for a primeira vez que você inicia o Cloud Shell, vai aparecer uma tela intermediária com a descrição dele. Se isso acontecer, clique em Continuar.

Leva apenas alguns instantes para provisionar e se conectar ao Cloud Shell.

Essa máquina virtual contém todas as ferramentas de desenvolvimento necessárias. Ela oferece um diretório principal persistente de 5 GB, além de ser executada no Google Cloud. Isso aprimora o desempenho e a autenticação da rede. Neste codelab, quase todo o trabalho pode ser feito com um navegador.

Depois de se conectar ao Cloud Shell, você vai ver que sua conta já está autenticada e que o projeto está configurado com o ID do seu projeto.

2. Execute o seguinte comando no Cloud Shell para confirmar se a conta está autenticada:

gcloud auth list

Resposta ao comando

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

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

Observação: a ferramenta de linha de comando gcloud é a poderosa e unificada do Google Cloud. Ela vem pré-instalado no Cloud Shell. Essa ferramenta aceita preenchimento com tabulação. Talvez seja necessário fazer a autenticação na primeira vez que você executar um comando. Para obter mais informações, consulte aos aspectos gerais da ferramenta de linha de comando gcloud.

3. Execute o comando a seguir no Cloud Shell para confirmar se o comando gcloud sabe sobre seu projeto:

gcloud config list project

Resposta ao comando

[core]
project = <PROJECT_ID>

Se o projeto não estiver configurado, configure-o usando este comando:

gcloud config set project <PROJECT_ID>

Resposta ao comando

Updated property [core/project].

Observação:se você estiver concluindo este tutorial fora do Cloud Shell, siga as etapas em Configurar as credenciais padrão do aplicativo.

3. Ativar as APIs do Cloud

No Cloud Shell, ative as APIs do Google Cloud para os componentes que serão usados:

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 esta é a primeira vez que você chama APIs da gcloud, será necessário autorizar o uso das suas credenciais para fazer essa solicitação. Isso vai acontecer uma vez por sessão do Cloud Shell.

A conclusão dessa operação pode levar alguns instantes.

Depois de concluída, uma mensagem de sucesso semelhante a esta vai aparecer:

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

4. Criar um projeto de modelo

Você vai usar o cms-template do Django CMS como projeto de exemplo.

Para criar esse projeto de modelo, use o Cloud Shell para criar um novo diretório chamado djangocms-cloudrun e navegue até ele:

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

Instale o pacote django-cms em um ambiente virtual temporário:

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

Crie uma cópia do projeto cms-template:

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

Renomeie o arquivo requirements.in como requirements.txt. O arquivo .in é usado pelo pip-tools para gerar arquivos requirements.txt, mas pode ser usado como está se a extensão for alterada. Nas etapas posteriores, o pip espera a extensão .txt.)

mv requirements.in requirements.txt

Agora você tem um projeto de modelo do Django CMS em uma pasta chamada myproject:

ls -F

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

Agora você pode sair e remover o ambiente virtual temporário:

deactivate
rm -rf venv

A partir daqui, o Django CMS será chamado dentro do contêiner.

5. Criar os serviços de apoio

Agora, crie os serviços de apoio: uma conta de serviço dedicada, um Artifact Registry, um banco de dados do Cloud SQL, um bucket do Cloud Storage e vários valores do Secret Manager.

Proteger os valores das senhas usadas na implantação é importante para a segurança de qualquer projeto e garante que ninguém coloque senhas por engano onde elas não pertencem (por exemplo, diretamente em arquivos de configurações ou digitadas diretamente no terminal, onde podem ser recuperadas do histórico).

Para começar, defina duas variáveis de ambiente básicas, uma para o ID do projeto:

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

e uma para a região:

REGION=us-central1

Ao trabalhar com infraestrutura, é útil ter todos os componentes no mesmo local para que eles possam se comunicar com mais eficiência. Embora alguns componentes estejam disponíveis globalmente, nem todos estão disponíveis em todas as regiões.

Para este codelab, recomendamos usar us-central1, europe-north1 ou asia-northeast1, ou qualquer região em que o Cloud Run (totalmente gerenciado) seja compatível.

Saiba mais:

• Locais do Cloud Run (totalmente gerenciado)
• Locais do Cloud SQL
• Locais do Cloud Storage

Criar uma conta de serviço

Para limitar o acesso do serviço a outras partes do Google Cloud, crie uma conta de serviço dedicada:

gcloud iam service-accounts create cloudrun-serviceaccount

Você vai consultar essa conta pelo e-mail dela nas próximas seções deste codelab. Defina esse valor em uma variável de ambiente:

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

Criar um Artifact Registry

Para armazenar a imagem de contêiner criada, crie um registro de contêiner na região escolhida:

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

Você vai fazer referência a esse registro por nome nas próximas seções deste codelab:

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

Criar o banco de dados

Crie uma instância do Cloud SQL:

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

Esta operação leva alguns minutos para ser concluída.

Nessa instância, crie um banco de dados:

gcloud sql databases create mydatabase --instance myinstance

Na mesma instância, crie um usuário:

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

Conceda à conta de serviço permissão para se conectar à instância:

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

Criar o bucket de armazenamento

Crie um bucket do Cloud Storage (o nome precisa ser globalmente exclusivo):

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

Conceda permissões para a conta de serviço administrar o bucket:

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

Como os objetos armazenados no bucket terão uma origem diferente (um URL de bucket em vez de um URL do Cloud Run), é necessário configurar as definições de Compartilhamento de recursos entre origens (CORS).

Crie um arquivo chamado cors.json com o seguinte conteúdo:

touch cors.json
cloudshell edit cors.json

cors.json

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

Aplique essa configuração do CORS ao bucket de armazenamento recém-criado:

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

Armazenar configuração como secret

Depois de configurar os serviços de apoio, você vai armazenar esses valores em um arquivo protegido usando o Secret Manager.

O Secret Manager permite armazenar, gerenciar e acessar secrets como blobs binários ou strings de texto. Ele funciona bem para armazenar informações de configuração, como senhas de banco de dados, chaves de API ou certificados TLS necessários para um aplicativo no ambiente de execução.

Primeiro, crie um arquivo com os valores da string de conexão do banco de dados, do bucket de mídia, de uma chave secreta para o Django (usada para assinatura criptográfica de sessões e tokens) e para ativar a depuração:

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

Em seguida, crie um secret chamado application_settings usando esse arquivo como secret:

gcloud secrets create application_settings --data-file .env

Permita que a conta de serviço acesse o secret:

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

Confirme se o secret foi criado listando os secrets:

gcloud secrets versions list application_settings

Depois de confirmar a criação do secret, remova o arquivo local:

rm .env

6. Configurar seu aplicativo

Considerando os serviços de suporte que você acabou de criar, será necessário fazer algumas mudanças no projeto de modelo para adequá-lo.

Isso inclui apresentar o django-environ para usar variáveis de ambiente como configurações, que você vai preencher com os valores definidos como secrets. Para implementar isso, você vai estender as configurações do modelo. Você também precisa adicionar outras dependências do Python.

Definir as configurações

Mova o arquivo settings.py e renomeie-o como basesettings.py:.

mv myproject/settings.py myproject/basesettings.py

Usando o editor da Web do Cloud Shell, crie um arquivo settings.py com o seguinte 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",
    },
}

Leia os comentários adicionados sobre cada configuração.

É possível que você veja erros de linting nesse arquivo. Isso já é esperado. O Cloud Shell não tem contexto dos requisitos deste projeto e, portanto, pode informar importações inválidas e não usadas.

Dependências do Python

Localize o arquivo requirements.txt e adicione os seguintes pacotes:

cloudshell edit requirements.txt

requirements.txt (anexar)

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

Definir a imagem do aplicativo

O Cloud Run executa qualquer contêiner, desde que ele esteja em conformidade com o contrato de contêiner do Cloud Run. Neste tutorial, optamos por omitir um Dockerfile e usar Cloud Native Buildpacks. Os buildpacks ajudam a criar contêineres para linguagens comuns, incluindo Python.

Neste tutorial, vamos personalizar o Procfile usado para iniciar o aplicativo da Web.

Para contentorizar o projeto de modelo, primeiro crie um arquivo chamado Procfile no nível superior do projeto (no mesmo diretório de manage.py) e copie o seguinte conteúdo:

touch Procfile
cloudshell edit Procfile

Procfile

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

7. Configurar, criar e executar etapas de migração

Para criar o esquema de banco de dados no Cloud SQL e preencher o bucket do Cloud Storage com seus recursos estáticos, execute migrate e collectstatic.

Esses comandos básicos de migração do Django precisam ser executados no contexto da imagem de contêiner criada com acesso ao banco de dados.

Você também precisará executar createsuperuser para criar uma conta de administrador e fazer login no admin do Django.

Para isso, use os jobs do Cloud Run. Os jobs do Cloud Run permitem executar processos com um fim definido, o que os torna ideais para tarefas de administração.

Defina a senha do superusuário do Django

Para criar o superusuário, use a versão não interativa do comando createsuperuser. Esse comando exige uma variável de ambiente com um nome especial para usar no lugar de uma solicitação para inserir a senha.

Crie um novo secret usando uma senha gerada aleatoriamente:

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

Permita que sua conta de serviço acesse o secret:

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

Atualizar o Procfile

Para ajudar na clareza dos jobs do Cloud Run, crie atalhos no Procfile e adicione os seguintes pontos 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

Agora você tem três entradas: o ponto de entrada padrão web, o ponto de entrada migrate para aplicar migrações de banco de dados e o ponto de entrada createuser para executar o comando createsuperuser.

Criar a imagem do aplicativo

Com as atualizações do Procfile, crie a imagem:

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

Criar jobs do Cloud Run

Agora que a imagem existe, você pode criar jobs do Cloud Run usando-a.

Esses jobs usam a imagem criada anteriormente, mas com valores de command diferentes. Eles são mapeados para os valores em Procfile.

Crie um job para a migração:

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

Crie um job para a criação do usuário:

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

Executar jobs do Cloud Run

Com as configurações de job no lugar, execute as migrações:

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

Confira se a saída do comando diz que a execução foi "concluída com sucesso".

Você vai executar esse comando mais tarde, quando fizer atualizações no aplicativo.

Com o banco de dados configurado, crie o usuário usando o job:

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

Confira se a saída do comando diz que a execução foi "concluída com sucesso".

Não será necessário executar esse comando novamente.

8. Implantar no Cloud Run

Com os serviços de apoio criados e preenchidos, agora é possível criar o serviço do Cloud Run para acessá-los.

A implantação inicial do seu aplicativo conteinerizado no Cloud Run é criada usando o seguinte comando:

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

Aguarde alguns instantes até a implantação terminar. Em caso de sucesso, a linha de comando vai exibir o URL de serviço:

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

Agora você pode acessar o contêiner implantado abrindo este URL em um navegador da Web:

Como esta é uma nova instalação, você será redirecionado automaticamente para a página de login.

9. Como acessar o administrador do Django

Um dos principais recursos do Django CMS é o administrador interativo.

Atualizando as configurações de CSRF

Mudança no Django 4.0: agora, a verificação do cabeçalho de origem do CSRF é obrigatória. Consulte a documentação do Django.

O Django inclui proteções contra falsificação de solicitações entre sites (CSRF). Sempre que um formulário é enviado no seu site Django, incluindo o login no administrador do Django, a configuração de origens confiáveis é verificada. Se não corresponder à origem da solicitação, o Django vai retornar um erro.

No arquivo mysite/settings.py, se a variável de ambiente CLOUDRUN_SERVICE_URL estiver definida, ela será usada nas configurações CSRF_TRUSTED_ORIGINS e ALLOWED_HOSTS. Embora não seja obrigatório, é recomendável definir ALLOWED_HOSTS, já que ele é necessário para CSRF_TRUSTED_ORIGINS.

Como você precisa do URL do serviço, essa configuração só pode ser adicionada após a primeira implantação.

Você precisará atualizar seu serviço para adicionar essa variável de ambiente. Ele pode ser adicionado ao secret application_settings ou diretamente como uma variável de ambiente.

A implementação abaixo aproveita a formatação e o escape da gcloud.

Recupere o URL do serviço:

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

Defina esse valor como uma variável de ambiente no serviço do Cloud Run:

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

Como fazer login no administrador do Django

Para acessar a interface de administrador do Django, anexe /admin ao URL do serviço.

Agora faça login com o nome de usuário "admin" e recupere sua senha usando o seguinte comando:

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

10. Aplicar atualizações de aplicativos

À medida que você desenvolve o aplicativo, é importante testá-lo localmente. Para isso, conecte-se ao banco de dados do Cloud SQL ("produção") ou a um banco de dados local ("teste").

Conectar ao banco de dados de produção

É possível se conectar às instâncias do Cloud SQL usando o proxy de autenticação do Cloud SQL. Esse aplicativo cria uma conexão da sua máquina local com o banco de dados.

Depois de instalar o proxy de autenticação do Cloud SQL, siga estas etapas:

# 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

Remova o arquivo temp_settings depois de concluir o trabalho.

Conectar-se a um banco de dados SQLite local

Como alternativa, use um banco de dados local ao desenvolver o aplicativo. O Django é compatível com bancos de dados PostgreSQL e SQLite. Há alguns recursos que o PostgreSQL tem e o SQLite não, mas, em muitos casos, a funcionalidade é idêntica.

Para configurar o SQLite, atualize as configurações do aplicativo para apontar para um banco de dados local e aplique as migrações de esquema.

Para configurar esse método:

# 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

Remova o arquivo temp_settings depois de concluir o trabalho.

Como criar migrações

Ao fazer mudanças nos modelos de banco de dados, talvez seja necessário gerar os arquivos de migração do Django executando python manage.py makemigrations.

É possível executar esse comando depois de configurar a conexão do banco de dados de produção ou de teste. Como alternativa, é possível gerar os arquivos de migração sem um banco de dados usando configurações vazias:

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

Aplicar atualizações de aplicativos

Para aplicar mudanças ao seu aplicativo, faça o seguinte:

• criar suas mudanças em uma nova imagem;
• aplique migrações estáticas ou de banco de dados e
• atualize o serviço do Cloud Run para usar a nova imagem.

Para criar a imagem:

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

Se você tiver migrações para aplicar, execute o job do Cloud Run:

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

Para atualizar o serviço com a nova imagem:

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

11. Parabéns!

Você acabou de implantar um projeto complexo no Cloud Run.

• O Cloud Run escalona de maneira automática e horizontal a imagem do contêiner para processar as solicitações recebidas, depois reduz o escalonamento quando a demanda diminui. Você paga apenas pela CPU, memória e rede consumidas durante o processamento da solicitação.
• O Cloud SQL permite provisionar uma instância gerenciada do PostgreSQL que é mantida automaticamente para você e se integra de forma nativa a muitos sistemas do Google Cloud.
• Com o Cloud Storage, você tem armazenamento em nuvem acessível de maneira integrada no Django.
• Com o Secret Manager, é possível armazenar secrets e disponibilizá-los para algumas partes do Google Cloud, mas não para outras.

Embora este laboratório curto tenha sido feito usando a linha de comando gcloud, o Cloud Run está disponível no console do Cloud ( console.cloud.google.com). Basta acessar Compute > Cloud Run para ver seu serviço listado.

Limpeza

Para evitar que os recursos usados nesse tutorial sejam cobrados na sua conta do Google Cloud Platform:

• No console do Cloud, acesse a página Gerenciar recursos.
• Na lista de projetos, selecione seu projeto e clique em Excluir.
• Na caixa de diálogo, digite o ID do projeto e clique em Encerrar para excluí-lo.

Saiba mais

• Django no Cloud Run: https://cloud.google.com/python/django/run
• Olá, Cloud Run com Python: https://codelabs.developers.google.com/codelabs/cloud-run-hello-python3
• Python no Google Cloud: https://cloud.google.com/python
• Cliente Python do Google Cloud: https://github.com/googleapis/google-cloud-python