このページは Cloud Translation API によって翻訳されました。

Cloud Run での Django

1. はじめに

Cloud Run は、マネージド型のコンピューティングプラットフォームで、HTTP リクエスト経由で呼び出し可能なステートレスコンテナを実行できます。Cloud Run はサーバーレスです。インフラストラクチャ管理が一切不要なため、最も重要な作業であるアプリケーションの構築に集中できます。

また、マネージドデータベース用の Cloud SQL、統合オブジェクトストレージ用の Cloud Storage、シークレット管理用の Secret Manager など、Google Cloud エコシステムの他の多くの部分とのネイティブインターフェースも提供されます。

Django は、高レベルの Python ウェブフレームワークです。

このチュートリアルでは、これらのコンポーネントを使用して、小さな Django プロジェクトをデプロイします。

注: この Codelab の最終検証は Django 5.0 で行われました。今後のアップデートで破壊的変更がない限り、この Codelab は引き続き機能するはずです。今後の Django リリースノートを確認する。

学習内容

Cloud Shell を使用する方法
Cloud SQL データベースを作成する方法
Cloud Storage バケットを作成する方法
Secret Manager シークレットを作成する方法
異なる Google Cloud サービスからシークレットを使用する方法
Google Cloud コンポーネントを Cloud Run サービスに接続する方法
Container Registry を使用してビルドしたコンテナを保存する方法
Cloud Run にデプロイする方法
Cloud Build でデータベーススキーマの移行を実行する方法

2. 設定と要件

セルフペース型の環境設定

Google Cloud Console にログインして、プロジェクトを新規作成するか、既存のプロジェクトを再利用します。Gmail アカウントも Google Workspace アカウントもまだお持ちでない場合は、アカウントを作成してください。

プロジェクト名は、このプロジェクトの参加者に表示される名称です。Google API では使用されない文字列です。いつでも更新できます。
プロジェクト ID は、すべての Google Cloud プロジェクトにおいて一意でなければならず、不変です（設定後は変更できません）。Cloud コンソールでは一意の文字列が自動生成されます。通常は、この内容を意識する必要はありません。ほとんどの Codelab では、プロジェクト ID（通常は PROJECT_ID と識別されます）を参照する必要があります。生成された ID が好みではない場合は、ランダムに別の ID を生成できます。または、ご自身で試して、利用可能かどうかを確認することもできます。このステップ以降は変更できず、プロジェクトを通して同じ ID になります。
なお、3 つ目の値として、一部の API が使用するプロジェクト番号があります。これら 3 つの値について詳しくは、こちらのドキュメントをご覧ください。

次に、Cloud のリソースや API を使用するために、Cloud コンソールで課金を有効にする必要があります。この Codelab の操作をすべて行って、費用が生じたとしても、少額です。このチュートリアルの終了後に請求が発生しないようにリソースをシャットダウンするには、作成したリソースを削除するか、プロジェクトを削除します。Google Cloud の新規ユーザーは、300 米ドル分の無料トライアルプログラムをご利用いただけます。

Google Cloud Shell

Google Cloud はノートパソコンからリモートで操作できますが、この Codelab では、Google Cloud Shell（Cloud 上で動作するコマンドライン環境）を使用します。

Cloud Shell をアクティブにする

Cloud Console で、[Cloud Shell をアクティブにする] をクリックします。

Cloud Shell を初めて起動する場合、その内容を説明する中間画面が表示されます。中間画面が表示された場合は、[続行] をクリックします。

Cloud Shell のプロビジョニングと接続に少し時間がかかる程度です。

この仮想マシンには、必要なすべての開発ツールが読み込まれます。仮想マシンは Google Cloud で稼働し、永続的なホームディレクトリが 5 GB 用意されているため、ネットワークのパフォーマンスと認証が大幅に向上しています。この Codelab での作業のほとんどは、ブラウザから実行できます。

Cloud Shell に接続すると、認証が完了し、プロジェクトに各自のプロジェクト ID が設定されていることがわかります。

Cloud Shell で次のコマンドを実行して、認証されたことを確認します。

gcloud auth list

コマンド出力

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

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

Cloud Shell で次のコマンドを実行して、gcloud コマンドがプロジェクトを認識していることを確認します。

gcloud config list project

コマンド出力

[core]
project = <PROJECT_ID>

上記のようになっていない場合は、次のコマンドで設定できます。

gcloud config set project <PROJECT_ID>

コマンド出力

Updated property [core/project].

3. Cloud APIs を有効にする

Cloud Shell で、使用するコンポーネントの Cloud API を有効にします。

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

gcloud から API を呼び出すのは初めてであるため、認証情報を使用してリクエストを行うことを承認するよう求められます。これは Cloud Shell セッションごとに 1 回行われます。

このオペレーションには少し時間がかかることがあります。

完了すると、次のような成功メッセージが表示されます。

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

4. テンプレートプロジェクトを作成する

ここでは、デフォルトの Django プロジェクトテンプレートをサンプル Django プロジェクトとして使用します。

このテンプレートプロジェクトを作成するには、Cloud Shell を使用して django-cloudrun という名前の新しいディレクトリを作成し、そのディレクトリに移動します。

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

次に、Django を一時的な仮想環境にインストールします。

virtualenv venv
source venv/bin/activate
pip install Django

インストールされたパッケージのリストを requirements.txt に保存する

pip freeze > requirements.txt

このリストには、Django とその依存関係（sqlparse と asgiref）を含める必要があります。

次に、新しいテンプレートプロジェクトを作成します。

django-admin startproject myproject .

manage.py という新しいファイルと、myproject という新しいフォルダが作成されます。このフォルダには、settings.py を含むいくつかのファイルが含まれます。

最上位フォルダの内容が想定どおりであることを確認します。

ls -F

manage.py myproject/ requirements.txt venv/

myproject フォルダの内容が想定どおりであることを確認します。

ls -F myproject/

__init__.py asgi.py settings.py  urls.py  wsgi.py

これで、一時的な仮想環境を終了して削除できます。

deactivate
rm -rf venv

以降、Django はコンテナ内で呼び出されます。

5. バッキングサービスを作成する

次に、バッキングサービス（専用のサービスアカウント、Artifact Registry、Cloud SQL データベース、Cloud Storage バケット、多数の Secret Manager 値）を作成します。

デプロイで使用されるパスワードの値を保護することは、プロジェクトのセキュリティにとって重要です。これにより、パスワードが誤って不適切な場所（設定ファイルに直接入力したり、履歴から取得できるターミナルに直接入力したりするなど）に配置されることがなくなります。

まず、2 つの基本環境変数を設定します。1 つはプロジェクト ID 用です。

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

もう一つはリージョン用です。

REGION=us-central1

サービスアカウントを作成する

サービスが Google Cloud の他の部分にアクセスできるように制限するには、専用のサービスアカウントを作成します。

gcloud iam service-accounts create cloudrun-serviceaccount

このアカウントは、この Codelab の後のセクションでメールアドレスで参照します。その値を環境変数に設定します。

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

Artifact Registry を作成する

ビルドしたコンテナイメージを保存するには、選択したリージョンに Container Registry を作成します。

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

この Codelab の今後のセクションでは、このレジストリを名前で参照します。

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

データベースを作成する

Cloud SQL インスタンスを作成します。

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

完了するまでに数分ほどかかることがあります。

そのインスタンスでデータベースを作成します。

gcloud sql databases create mydatabase --instance myinstance

同じインスタンスで、ユーザーを作成します。

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

サービスアカウントにインスタンスへの接続権限を付与します。

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

Storage バケットを作成する

Cloud Storage バケットを作成します（名前はグローバルに一意にする必要があります）。

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

バケットを管理する権限をサービスアカウントに付与します。

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

構成をシークレットとして保存する

バッキングサービスを設定したので、これらの値を Secret Manager を使用して保護されたファイルに保存します。

Secret Manager を使用すると、シークレットをバイナリ blob またはテキスト文字列として保存、管理し、シークレットにアクセスできます。実行時にアプリケーションが必要とする構成情報（データベースパスワード、API キー、TLS 証明書など）を保存するのに便利です。

まず、データベース接続文字列、メディアバケット、Django のシークレットキー（セッションとトークンの暗号署名に使用）、デバッグを有効にする値を含むファイルを作成します。

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

次に、このファイルをシークレットとして使用して、application_settings というシークレットを作成します。

gcloud secrets create application_settings --data-file .env

サービスアカウントにこのシークレットへのアクセスを許可します。

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

Secret を一覧表示して、Secret が作成されたことを確認します。

gcloud secrets versions list application_settings

シークレットが作成されたことを確認したら、ローカルファイルを削除します。

rm .env

6. アプリケーションを構成する

先ほど作成したバッキングサービスを考慮して、適切なテンプレートプロジェクトにいくつかの変更を加える必要があります。

これには、環境変数を構成設定として使用する django-environ の導入が含まれます。シークレットとして定義した値がシードされます。これを実装するには、テンプレートの設定を拡張します。また、Python 依存関係を追加する必要もあります。

設定を行う

settings.py ファイルを移動し、名前を basesettings.py: に変更します。

mv myproject/settings.py myproject/basesettings.py

Cloud Shell ウェブエディタを使用して、次のコードを含む新しい settings.py ファイルを作成します。

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",
    },
}

各構成について追加されたコメントをよく読んでください。

このファイルには lint チェックのエラーが表示される場合があります。これは予期されたエラーです。Cloud Shell にはこのプロジェクトの要件のコンテキストがないため、無効なインポートや未使用のインポートが報告される場合があります。

Python 依存関係

requirements.txt ファイルを見つけて、次のパッケージを追加します。

cloudshell edit requirements.txt

requirements.txt（追加）

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

アプリケーションイメージを定義する

Cloud Run は、Cloud Run コンテナ契約を遵守している限り、任意のコンテナを実行します。このチュートリアルでは、Dockerfile を省略し、代わりに Cloud Native Buildpack を使用します。Buildpack は、Python などの一般的な言語用のコンテナのビルドを支援します。

このチュートリアルでは、ウェブアプリケーションの起動に使用する Procfile をカスタマイズします。

テンプレートプロジェクトをコンテナ化するには、まずプロジェクトの最上位レベル（manage.py と同じディレクトリ）に Procfile という名前の新しいファイルを作成し、次の内容をコピーします。

touch Procfile
cloudshell edit Procfile

Procfile

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

7. 移行ステップの構成、ビルド、実行

Cloud SQL データベースにデータベーススキーマを作成し、Cloud Storage バケットに静的アセットを設定するには、migrate と collectstatic を実行する必要があります。

これらの基本的な Django 移行コマンドは、データベースにアクセスできるビルド済みコンテナイメージのコンテキスト内で実行する必要があります。

また、createsuperuser を実行して、Django 管理にログインする管理者アカウントを作成する必要があります。

そのためには、Cloud Run ジョブを使用してこれらのタスクを実行します。Cloud Run ジョブを使用すると、終了が定義されたプロセスを実行できるため、管理タスクに最適です。

Django スーパーユーザーのパスワードを定義する

スーパーユーザーを作成するには、非対話型バージョンの createsuperuser コマンドを使用します。このコマンドでは、パスワードの入力を求めるプロンプトの代わりに、特別な名前の環境変数を使用する必要があります。

ランダムに生成されたパスワードを使用して、新しいシークレットを作成します。

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

サービスアカウントにこの Secret へのアクセスを許可します。

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

Procfile を更新する

Cloud Run ジョブを明確にするために、Procfile でショートカットを作成し、次のエントリポイントを Procfile に追加します。

migrate: python manage.py migrate && python manage.py collectstatic --noinput --clear
createuser: python manage.py createsuperuser --username admin --email noop@example.com --noinput

これで、デフォルトの web エントリポイント、データベース移行を適用する migrate エントリポイント、createsuperuser コマンドを実行するための createuser エントリポイントの 3 つのエントリが作成されます。

アプリケーションイメージをビルドする

Procfile を更新したら、イメージをビルドします。

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

Cloud Run ジョブを作成する

イメージが作成されたので、それを使用して Cloud Run ジョブを作成できます。

これらのジョブでは以前にビルドされたイメージを使用しますが、command 値は異なります。これらは、Procfile の値にマッピングされます。

移行のジョブを作成します。

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

ユーザー作成用のジョブを作成します。

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

Cloud Run ジョブを実行する

ジョブの構成が完了したら、移行を実行します。

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

このコマンド出力に、実行が「正常に完了しました」と表示されていることを確認します。

このコマンドは、後でアプリケーションを更新するときに実行します。

データベースの設定が完了したら、ジョブを使用してユーザーを作成します。

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

このコマンド出力に「正常に完了」と表示されていることを確認します。

このコマンドを再度実行する必要はありません。

8. Cloud Run にデプロイする

バッキングサービスを作成してデータが入力されたので、それにアクセスするための Cloud Run サービスを作成できます。

先ほどビルドしたイメージを使用して、次のコマンドでサービスを Cloud Run にデプロイします。

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

成功すると、コマンドラインにサービス URL が表示されます。

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

ウェブブラウザで次の URL を開くと、デプロイしたコンテナにアクセスできます。

9. Django 管理へのアクセス

Django の主な機能の一つは、インタラクティブな管理機能です。

CSRF 設定の更新

Django には、クロスサイトリクエストフォージェリ（CSRF）に対する保護機能が組み込まれています。Django サイトのフォームが送信されるたびに（Django 管理へのログインを含む）、信頼できる送信元の設定が確認されます。リクエストの送信元と一致しない場合、Django はエラーを返します。

mysite/settings.py ファイルで、CLOUDRUN_SERVICE_URL 環境変数が定義されている場合は、CSRF_TRUSTED_ORIGINS と ALLOWED_HOSTS の設定でその変数が使用されます。ALLOWED_HOSTS の定義は必須ではありませんが、CSRF_TRUSTED_ORIGINS ですでに必須であるため、追加することをおすすめします。

サービス URL が必要になるため、この構成は最初のデプロイ後に追加する必要があります。

この環境変数を追加するには、サービスを更新する必要があります。application_settings シークレットに追加することも、環境変数として直接追加することもできます。

以下の実装では、gcloud の書式設定とエスケープを利用しています。

サービスの URL を取得します。

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

この値を Cloud Run サービスの環境変数として設定します。

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

Django 管理者にログインする

Django 管理インターフェースにアクセスするには、サービス URL に /admin を追加します。

「admin」というユーザー名でログインします次のコマンドでパスワードを取得します。

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

10. アプリケーションの開発

アプリケーションを開発する際には、ローカルでテストする必要があります。そのためには、Cloud SQL（「本番環境」）データベースまたはローカル（「テスト」）データベースに接続する必要があります。

本番環境データベースに接続する

Cloud SQL インスタンスに接続するには、Cloud SQL Auth Proxy を使用します。このアプリケーションは、ローカルマシンからデータベースへの接続を作成します。

Cloud SQL Auth Proxy をインストールしたら、次の操作を行います。

# 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

作業が終了したら、temp_settings ファイルを削除してください。

ローカル SQLite データベースに接続する

または、アプリケーションの開発時にローカルデータベースを使用することもできます。Django は PostgreSQL データベースと SQLite データベースの両方をサポートしています。PostgreSQL には SQLite にはない機能もありますが、多くの場合、機能は同じです。

SQLite を設定するには、アプリケーション設定を更新してローカルデータベースを参照するようにし、スキーマ移行を適用する必要があります。

このメソッドを設定するには:

# 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

作業が終了したら、temp_settings ファイルを削除してください。

移行を作成しています

データベースモデルに変更を加える場合は、python manage.py makemigrations を実行して Django の移行ファイルを生成する必要があります。

このコマンドは、本番環境またはテスト環境のデータベース接続を設定した後に実行できます。または、空の設定を指定して、データベースなしで移行ファイルを生成することもできます。

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

アプリケーションアップデートの適用

アプリに変更を適用するには、次の操作を行う必要があります。

変更を新しいイメージにビルドします。
データベースまたは静的移行を適用し、
新しいイメージを使用するように Cloud Run サービスを更新します。

イメージをビルドするには:

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

適用する移行がある場合は、Cloud Run ジョブを実行します。

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

新しいイメージでサービスを更新するには:

gcloud run services update django-cloudrun \
  --region $REGION \
  --image ${ARTIFACT_REGISTRY}/myimage

11. 完了

これで、複雑なプロジェクトが Cloud Run にデプロイされました。

Cloud Run は、受信したリクエストを処理するためにコンテナイメージを自動的に水平方向にスケーリングします。リクエスト数が減少すると、スケールダウンします。料金は、リクエストの処理中に使用した CPU、メモリ、ネットワークに対してのみ発生します。
Cloud SQL を使用すると、自動的にメンテナンスされ、多くの Google Cloud システムにネイティブに統合されるマネージド PostgreSQL インスタンスをプロビジョニングできます。
Cloud Storage を使用すると、Django でシームレスにアクセスできるクラウドストレージを実現できます。
Secret Manager を使用すると、シークレットを保存し、Google Cloud の特定の部分のみがアクセスできるようにし、それ以外の部分からはアクセスできないようにすることができます。

クリーンアップ

このチュートリアルで使用したリソースについて、Google Cloud Platform アカウントに課金されないようにする手順は次のとおりです。

Cloud コンソールで、[リソースの管理] ページに移動します。
プロジェクトリストで、プロジェクトを選択し、[削除] をクリックします。
ダイアログでプロジェクト ID を入力し、[シャットダウン] をクリックしてプロジェクトを削除します。

詳細

Cloud Run での Django: https://cloud.google.com/python/django/run
Python を使用した Cloud Run: https://codelabs.developers.google.com/codelabs/cloud-run-hello-python3
Google Cloud 上の Python: https://cloud.google.com/python
Google Cloud Python クライアント: https://github.com/googleapis/google-cloud-python

Cloud Run での Django

1. はじめに

学習内容

2. 設定と要件

セルフペース型の環境設定

Google Cloud Shell

Cloud Shell をアクティブにする

3. Cloud APIs を有効にする

4. テンプレート プロジェクトを作成する

5. バッキング サービスを作成する

サービス アカウントを作成する

Artifact Registry を作成する

データベースを作成する

Storage バケットを作成する

構成をシークレットとして保存する

6. アプリケーションを構成する

設定を行う

myproject/settings.py

Python 依存関係

requirements.txt（追加）

アプリケーション イメージを定義する

Procfile

7. 移行ステップの構成、ビルド、実行

Django スーパーユーザーのパスワードを定義する

Procfile を更新する

アプリケーション イメージをビルドする

Cloud Run ジョブを作成する

Cloud Run ジョブを実行する

8. Cloud Run にデプロイする

9. Django 管理へのアクセス

CSRF 設定の更新

Django 管理者にログインする

10. アプリケーションの開発

本番環境データベースに接続する

ローカル SQLite データベースに接続する

移行を作成しています

アプリケーション アップデートの適用

11. 完了

クリーンアップ

詳細

4. テンプレートプロジェクトを作成する

5. バッキングサービスを作成する

サービスアカウントを作成する

アプリケーションイメージを定義する

アプリケーションイメージをビルドする

アプリケーションアップデートの適用