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 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
- 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.
- 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
- No Console do Cloud, clique em Ativar o Cloud Shell.
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.
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ê vai notar que sua conta já está autenticada e que o projeto está configurado com seu ID do projeto.
- 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`
- 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:
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 ""
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
- Django no Cloud Run: https://cloud.google.com/python/django/run
- Apresentação do 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