Django no Cloud Run

1. Introdução

894762ebb681671c.png

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 tem interface nativa 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 gerenciamento de segredos.

O Django é um framework da Web de alto nível em Python.

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

Observação: este codelab foi verificado pela última vez com o Django 5.0. A menos que haja mudanças importantes em atualizações futuras, este codelab continuará funcionando. Verifique as próximas notas de versão do Django.

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

fbef9caa1602edd0.png

a99b7ace416376c4.png

5e3ff691252acf41.png

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

3c1dabeca90e44e5.png

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

9c92662c6a846a5c.png

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

9f0e51b578fecce5.png

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ê vai notar que sua conta já está autenticada e que o projeto está configurado com seu ID do projeto.

  1. 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`
  1. 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].

3. ativar as APIs do Cloud

No Cloud Shell, ative as APIs 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 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 modelo de projeto padrão do Django como seu projeto de exemplo.

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

mkdir ~/django-cloudrun
cd ~/django-cloudrun

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

virtualenv venv
source venv/bin/activate
pip install Django

Salvar a lista de pacotes instalados em requirements.txt

pip freeze > requirements.txt

A lista precisa incluir o Django e as dependências dele: sqlparse e asgiref.

Em seguida, crie um novo projeto de modelo:

django-admin startproject myproject .

Você vai receber um novo arquivo chamado manage.py e uma nova pasta chamada myproject, que vai conter vários arquivos, incluindo um settings.py.

Confirme se o conteúdo da sua pasta de nível superior está como esperado:

ls -F
manage.py myproject/ requirements.txt venv/

Confirme se o conteúdo da pasta myproject é o esperado:

ls -F myproject/
__init__.py asgi.py settings.py  urls.py  wsgi.py

Agora é possível sair e remover seu ambiente virtual temporário:

deactivate
rm -rf venv

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

5. Criar os serviços de apoio

Agora você vai criar os serviços de suporte: 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 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

Criar uma conta de serviço

Para limitar o acesso que o serviço terá 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 do 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 em seções futuras 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

Nessa 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

Criar o bucket de armazenamento

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

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

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.

Com o Secret Manager, é possível 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, 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

Liste-os para confirmar se o secret foi criado:

gcloud secrets versions list application_settings

Depois de confirmar que o secret foi criado, remova o arquivo local:

rm .env

6. Configurar seu aplicativo

Com os serviços de suporte que você acabou de criar, é necessário fazer algumas mudanças no projeto de modelo para se adequar.

Isso inclui a introdução de django-environ para usar variáveis de ambiente como configurações, que serão inicializadas com os valores definidos como chaves secretas. Para implementar isso, estenda as configurações do modelo. Você também vai precisar adicionar outras dependências do Python.

Definir configurações

Mova o arquivo settings.py, renomeando-o para basesettings.py:

mv myproject/settings.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",
    },
}

Leia o comentário adicionado sobre cada configuração.

Talvez você encontre erros de lint nesse 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.

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.

Este tutorial opta por personalizar o Procfile usado para iniciar o aplicativo da Web.

Para colocar o projeto de modelo em contêiner, 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 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 Django básicos 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 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.

Definir 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 digitar 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 a 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 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 noop@example.com --noinput

Agora você tem três entradas: o ponto de entrada web padrão, 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 em vigor, 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 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 do job em vigor, execute as migrações:

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

Verifique se a saída do comando informa 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.

Implante o serviço no Cloud Run usando a imagem criada anteriormente com este comando:

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

Em caso de sucesso, a linha de comando vai exibir o URL de serviço:

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

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

d2dfaf668baabfcc.png

9. Como acessar o administrador do Django

Um dos principais recursos do Django é sua administração interativa.

Como atualizar as configurações de CSRF

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 o login no administrador do Django, a configuração de origens confiáveis é verificada. Se não corresponder à origem da solicitação, o Django 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, é recomendável adicioná-la, já que ela é necessária para CSRF_TRUSTED_ORIGINS.

Como você precisa do URL do serviço, não é possível adicionar essa configuração até a primeira implantação.

Você precisará atualizar o 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 os URLs de serviço:

CLOUDRUN_SERVICE_URLS=$(gcloud run services describe django-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 django-cloudrun \
  --region $REGION \
  --update-env-vars "^##^CLOUDRUN_SERVICE_URLS=$CLOUDRUN_SERVICE_URLS"

Como fazer login no administrador do Django

Para acessar a interface de administração 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 ""

678cd382b7039769.png

de755ef7a1779dc6.png

10. Desenvolver um aplicativo

Ao desenvolver o aplicativo, é recomendável testá-lo localmente. Para isso, você precisa se conectar ao seu banco de dados do Cloud SQL ("produção") ou a um banco de dados local ("teste").

Conectar ao banco de dados de produção

Você pode 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

Remova o arquivo temp_settings depois de terminar o 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ê terá que atualizar as configurações do aplicativo para apontar para um banco de dados local e, em seguida, terá que aplicar suas 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 mudanças nos modelos do banco de dados, talvez seja 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 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 django-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, é possível provisionar uma instância gerenciada do PostgreSQL que é mantida automaticamente para você e se integra nativamente 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.
  • O Secret Manager permite armazenar secrets e ter acesso a eles em determinadas partes do Google Cloud, mas não em outras.

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