Sobre este codelab
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 Django CMS é um sistema de gerenciamento de conteúdo empresarial (CMS, na sigla em inglês) baseado no Django. Django é uma biblioteca da Web em Python de alto nível.
Neste tutorial, você usará esses componentes para implantar um pequeno projeto Django CMS.
Observação: este codelab foi verificado pela última vez com o Django CMS 3.11.4 até o django-cms/cms-template v3.11.
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
- 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 do 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 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.
- 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 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 da 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 deve aparecer:
Operation "operations/acf.cc11852d-40af-47ad-9d59-477a12847c9e" finished successfully.
4. Criar um projeto de modelo
Você usará o CMS cms-template do Django como um projeto de exemplo de projeto do CMS do Django.
Para criar esse modelo de projeto, 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-3]
Crie uma cópia do projeto cms-template:
django-admin startproject --template https://github.com/django-cms/cms-template/archive/3.11.zip myproject .
Agora você terá um modelo de projeto CMS do Django em uma pasta chamada myproject
:
ls -F
manage.py* media/ myproject/ project.db requirements.in requirements.txt static/ venv/
Agora é possível sair e remover seu ambiente virtual temporário:
deactivate rm -rf venv
A partir daqui, o Django CMS será chamado dentro do contêiner.
Também é possível remover o arquivo requirements.in copiado automaticamente (usado por pip-tools para gerar arquivos requirements.txt). Ele não será usado neste codelab:
rm requirements.in
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 de base, 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 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
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
Crie 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
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 configuração como secret
Após configurar os serviços de apoio, você armazenará esses valores em um arquivo protegido com 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 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 para a string de conexão do banco de dados, o bucket de mídia, uma chave secreta para 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
Considerando os serviços de apoio que você acabou de criar, será necessário fazer algumas alterações no projeto modelo.
Isso inclui a introdução de django-environ
para usar variáveis de ambiente como configurações, que você vai propagar com os valores definidos como secrets. Para implementar isso, estenda as configurações do modelo. Você também 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 URL to Django security settings
CLOUDRUN_SERVICE_URL = env("CLOUDRUN_SERVICE_URL", default=None)
if CLOUDRUN_SERVICE_URL:
ALLOWED_HOSTS = [urlparse(CLOUDRUN_SERVICE_URL).netloc]
CSRF_TRUSTED_ORIGINS = [CLOUDRUN_SERVICE_URL]
else:
ALLOWED_HOSTS = ["*"]
# Default false. True allows default landing pages to be visible
DEBUG = env("DEBUG", default=False)
# Set this value from django-environ
DATABASES = {"default": env.db()}
# Change database settings if using the Cloud SQL Auth Proxy
if os.getenv("USE_CLOUD_SQL_AUTH_PROXY", None):
DATABASES["default"]["HOST"] = "127.0.0.1"
DATABASES["default"]["PORT"] = 5432
# Define static storage via django-storages[google]
GS_BUCKET_NAME = env("GS_BUCKET_NAME")
STATICFILES_DIRS = []
DEFAULT_FILE_STORAGE = "storages.backends.gcloud.GoogleCloudStorage"
STATICFILES_STORAGE = "storages.backends.gcloud.GoogleCloudStorage"
GS_DEFAULT_ACL = "publicRead"
Reserve um tempo para ler os comentários adicionados 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 deste projeto e, portanto, pode informar importações inválidas e não utilizadas.
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 vai executar 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
, mas usando Buildpacks nativos da nuvem. Os buildpacks ajudam a criar contêineres para linguagens comuns, incluindo Python.
Neste tutorial, optamos por personalizar o Procfile usado para iniciar o aplicativo da Web.
Para conteinerizar o projeto modelo, primeiro crie um novo arquivo com o nome 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 (em inglês)
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 do 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 jobs do Cloud Run. 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 noop@example.com --noinput
Agora você terá três entradas: o ponto de entrada padrão da 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 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 do 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ê 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 resposta ao comando mostra 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 djangocms-cloudrun \ --platform managed \ --region $REGION \ --image gcr.io/${PROJECT_ID}/myimage \ --set-cloudsql-instances ${PROJECT_ID}:${REGION}:myinstance \ --set-secrets APPLICATION_SETTINGS=application_settings:latest \ --service-account $SERVICE_ACCOUNT \ --allow-unauthenticated
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-...-uc.a.run.app
Para acessar o contêiner implantado, abra 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 é a administração interativa.
Como atualizar as configurações do 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 login no administrador do Django, a configuração 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, é 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, 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 adicionado diretamente como uma variável de ambiente.
Recupere o URL do serviço:
CLOUDRUN_SERVICE_URL=$(gcloud run services describe djangocms-cloudrun \ --platform managed \ --region $REGION \ --format "value(status.url)") echo $CLOUDRUN_SERVICE_URL
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_URL=$CLOUDRUN_SERVICE_URL
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. Aplicando atualizações do aplicativo
Ao desenvolver o aplicativo, é recomendável testá-lo localmente. Para isso, conecte-se ao banco de dados do Cloud SQL ("produção") ou ao banco de dados local ("teste").
Conectar-se 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
Não se esqueça de remover o arquivo temp_settings
depois de terminar seu trabalho.
Conectar-se 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 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
.
É possível executar esse comando depois de configurar a conexão do banco de dados de produção ou teste. Como alternativa, é possível gerar os arquivos de migração sem um banco de dados, fornecendo 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á:
- criar as alterações 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 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.
- 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 acessível no Django.
- Com o Secret Manager, é possível armazenar secrets e acessá-los apenas por determinadas partes do Google Cloud.
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