Wagtail 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 interage nativamente com 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 Wagtail é um sistema de gerenciamento de conteúdo (CMS) de código aberto criado com base no Django. Django é uma biblioteca da Web em Python de alto nível.

Neste tutorial, você usará esses componentes para implantar um pequeno projeto do Wagtail.

Observação: este codelab foi verificado pela última vez com o Wagtail 5.2.2, que oferece suporte ao Django 5.

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 você estiver iniciando o Cloud Shell pela primeira vez, verá uma tela intermediária com a descrição dele. Se aparecer uma tela intermediária, clique em Continuar.

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

Essa máquina virtual tem 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. Grande parte do trabalho neste codelab, se não todo, pode ser feito em um navegador.

Depois de se conectar ao Cloud Shell, você verá sua autenticação e o projeto estará 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 seguinte comando no Cloud Shell para confirmar que 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 instruções em Configurar as credenciais padrão do aplicativo.

3. Ativar as APIs do Cloud

No Cloud Shell, ative as APIs do 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 do gcloud, será necessário autorizar o uso das suas credenciais para fazer essa solicitação. Isso 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 modelo de projeto padrão do Wagtail como seu exemplo. Para fazer isso, instale temporariamente o Wagtail para gerar o modelo.

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

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

Em seguida, instale o Wagtail em um ambiente virtual temporário:

virtualenv venv
source venv/bin/activate
pip install wagtail

Em seguida, crie um novo projeto de modelo na pasta atual:

wagtail start myproject .

Agora você terá um modelo de projeto do Wagtail na pasta atual:

ls -F

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

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

deactivate
rm -rf venv

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

5. Criar os serviços de apoio

Agora você criará 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 alguns 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 acidentalmente onde elas não pertencem (por exemplo, diretamente em arquivos de configuração ou digitada diretamente no seu terminal, de onde elas 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 o uso de us-central1, europe-north1 ou asia-northeast1. ou em qualquer região do Cloud Run (totalmente gerenciado).

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 fazer referência a essa conta pelo e-mail em seções futuras deste codelab. Defina esse valor em uma variável de ambiente:

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

Crie 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 mencionar esse registro pelo 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.

Nesse caso, 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 permissão à conta de serviço para se conectar à instância:

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

Crie 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 que a conta de serviço administre 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 têm uma origem diferente (um URL do bucket em vez de um URL do Cloud Run), é necessário definir as configurações de Compartilhamento de recursos entre origens (CORS).

Crie um novo 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 esta configuração do CORS ao bucket de armazenamento recém-criado:

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

Armazenar a configuração como secret

Depois de configurar os serviços de suporte, 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 bancos de dados, chaves de API ou certificados TLS, necessários para um aplicativo no tempo de execução.

Primeiro, crie um arquivo com os valores da string de conexão do banco de dados, o bucket de mídia, 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 este 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 que o secret foi criado, remova o arquivo local:

rm .env

6. Configurar seu aplicativo

O projeto de modelo que você criou anteriormente precisa de algumas alterações. Essas mudanças vão reduzir a complexidade das configurações de modelos que vêm com o Wagtail e integrar o Wagtail aos serviços de suporte que você criou anteriormente.

Definir configurações

Encontre o arquivo de configurações base.py gerado e o renomeie como basesettings.py na pasta myproject principal:

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

Usando o editor da Web do Cloud Shell, crie um novo 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",
    },
}

Reserve um tempo para ler os comentários adicionados sobre cada configuração.

Talvez você encontre erros de linting neste arquivo. Isso já é esperado. O Cloud Shell não tem o contexto dos requisitos para este projeto e, portanto, pode informar importações inválidas e não usadas.

Em seguida, remova a antiga pasta de configurações.

rm -rf myproject/settings/

Você terá dois arquivos de configuração: um do Wagtail e outro que você acabou de criar com base nessas configurações:

ls myproject/*settings*

myproject/basesettings.py  myproject/settings.py

Por fim, abra o arquivo de configurações manage.py e atualize a configuração para instruir o Wagtail a apontar para o arquivo settings.py principal.

cloudshell edit manage.py

Linha manage.py (antes)

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

Linha manage.py (depois)

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

Faça a mesma mudança de configuração para o arquivo myproject/wsgi.py:

cloudshell edit myproject/wsgi.py

myproject/wsgi.py line (before)

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

myproject/wsgi.py (depois)

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

Remova o Dockerfile criado automaticamente:

rm Dockerfile

Dependências do Python

Localize o arquivo requirements.txt e anexe 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 Buildpacks nativos do Cloud. Os buildpacks ajudam a criar contêineres para linguagens comuns, incluindo Python.

Neste tutorial, optamos por personalizar a Procfile usada para iniciar o aplicativo da Web.

Para conteinerizar o projeto modelo, primeiro crie um novo arquivo chamado Procfile no nível superior do projeto (no mesmo diretório que 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 as etapas de migração

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

Esses comandos de migração de base do Django precisam ser executados dentro do contexto da sua imagem de contêiner criada com acesso ao seu banco de dados.

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

Para isso, você vai usar os jobs do Cloud Run para realizar essas tarefas. Os jobs do Cloud Run permitem executar processos com um final definido, o que os torna ideais para tarefas de administração.

Defina sua senha de superusuário do Django

Para criar o superusuário, use a versão não interativa do comando createsuperuser. Esse comando exige o uso de uma variável de ambiente com um nome em vez de um prompt 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 este secret:

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

Atualizar seu Procfile

Para aumentar a clareza dos jobs do Cloud Run, crie atalhos no Procfile e anexe 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ê terá três entradas: o padrão web, migrate para aplicar migrações de banco de dados e createuser para executar o comando createsuperuser.

Criar a imagem do aplicativo

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

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

Criar jobs do Cloud Run

Agora que a imagem existe, é possível criar jobs do Cloud Run usando-a.

Esses jobs usam a imagem criada anteriormente, mas usam valores command diferentes. Eles são mapeados para os valores no 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 em vigor, execute as migrações:

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

Verifique se a resposta ao comando mostra que a execução foi "concluída com sucesso".

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

Com a configuração do banco de dados, crie o usuário usando o job:

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

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

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

8. Implantar no Cloud Run

Depois de criar e preencher os serviços de apoio, crie o serviço do Cloud Run para acessá-los.

A implantação inicial do aplicativo conteinerizado no Cloud Run é criada usando o seguinte 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

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

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

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

9. Como acessar o administrador do Django

Como atualizar as configurações do CSRF

Alterado no Django 4.0: a verificação de cabeçalho de origem do CSRF agora é aplicada. Consulte a documentação do Django.

O Django inclui proteções contra falsificação de solicitações entre sites (CSRF, na sigla em inglês). Sempre que um formulário é enviado no seu site do Django, incluindo login no administrador do Django, a configuração 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 a definição de ALLOWED_HOSTS não seja obrigatória, é uma prática recomendada adicionar esse valor, já que isso já é obrigatório para o 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ê vai 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 a escapa de caracteres do gcloud.

Recupere o URL do serviço:

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

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

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

Como fazer login no administrador do Django

Para acessar a interface administrativa 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. Desenvolver um aplicativo

Ao desenvolver o aplicativo, teste-o localmente. Para fazer isso, você precisa se conectar 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. Este aplicativo cria uma conexão da sua máquina local com o banco de dados.

Depois de instalar o proxy do Cloud SQL Auth, 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 --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

Não se esqueça de remover o arquivo temp_settings depois de terminar seu trabalho.

Conectar a um banco de dados SQLite local

Como alternativa, você pode usar um banco de dados local ao desenvolver seu aplicativo. O Django suporta ambos os bancos de dados PostgreSQL e SQLite, e existem alguns recursos que o PostgreSQL tem que o SQLite não, mas em muitos casos a funcionalidade é idêntica.

Para configurar o SQLite, você precisa atualizar as configurações do aplicativo para apontar para um banco de dados local e aplicar 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

Não se esqueça de remover o arquivo temp_settings depois de terminar seu trabalho.

Como criar migrações

Ao fazer alterações nos seus modelos de banco de dados, pode ser necessário gerar os arquivos de migração do Django executando python manage.py makemigrations.

Você pode 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, definindo configurações vazias:

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

Aplicando atualizações do aplicativo

Para aplicar as mudanças ao seu aplicativo, você precisará:

• crie as mudanças em uma nova imagem,
• aplicar qualquer migração estática ou banco de dados e, em seguida,
• atualize o serviço do Cloud Run para usar a nova imagem.

Para criar sua imagem:

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

Se você tiver alguma migração 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 wagtail-cloudrun \
  --region $REGION \
  --image ${ARTIFACT_REGISTRY}/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.
• Com o Cloud SQL, você pode provisionar uma instância gerenciada do PostgreSQL que é mantida automaticamente e integrada de forma nativa a muitos sistemas do Google Cloud.
• O Cloud Storage permite que você tenha armazenamento em nuvem de uma forma que seja acessível sem problemas no Django.
• Com o Secret Manager, é possível armazenar secrets e acessá-los apenas por determinadas partes do Google Cloud.

Embora este laboratório rápido tenha sido feito usando a linha de comando gcloud, o Cloud Run está disponível no console do Cloud (console.cloud.google.com). Basta navegar até 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
• Hello 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

/