この Codelab について
1. はじめに
Cloud Run は、マネージド型のコンピューティング プラットフォームで、HTTP リクエスト経由で呼び出し可能なステートレス コンテナを実行できます。Cloud Run はサーバーレスです。インフラストラクチャ管理が一切不要なため、最も重要な作業であるアプリケーションの構築に集中できます。
また、マネージド データベース用の Cloud SQL、統合オブジェクト ストレージ用の Cloud Storage、シークレット管理用の Secret Manager など、Google Cloud エコシステムの他の多くの部分とのネイティブ インターフェースも提供されます。
Django CMS は、Django 上に構築されたエンタープライズ コンテンツ マネジメント システム(CMS)です。Django は、高レベルの Python ウェブ フレームワークです。
このチュートリアルでは、これらのコンポーネントを使用して小規模な Django CMS プロジェクトをデプロイします。
注: この Codelab の最終検証は、django-cms/cms-template v3.11 を通じて Django CMS 3.11.4 で行われました。
学習内容
- 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 では Cloud 上で動作するコマンドライン環境である Google Cloud Shell を使用します。
Cloud Shell をアクティブにする
- Cloud Console で、[Cloud Shell をアクティブにする]
をクリックします。
Cloud Shell を初めて起動する場合は、内容を説明する中間画面が表示されます。中間画面が表示されたら、[続行] をクリックします。
Cloud Shell のプロビジョニングと接続に少し時間がかかる程度です。
この仮想マシンには、必要なすべての開発ツールが読み込まれます。5 GB の永続的なホーム ディレクトリが用意されており、Google Cloud で稼働するため、ネットワークのパフォーマンスと認証が大幅に向上しています。この 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 APIs を有効にします。
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 CMS の cms-template をサンプル Django CMS プロジェクトとして使用します。
このテンプレート プロジェクトを作成するには、Cloud Shell を使用して djangocms-cloudrun
という名前の新しいディレクトリを作成し、そのディレクトリに移動します。
mkdir ~/djangocms-cloudrun cd ~/djangocms-cloudrun
django-cms パッケージを一時的な仮想環境にインストールします。
virtualenv venv source venv/bin/activate pip install djangocms-frontend\[cms-3]
cms-template プロジェクトのコピーを作成します。
django-admin startproject --template https://github.com/django-cms/cms-template/archive/3.11.zip myproject .
これで、myproject
というフォルダにテンプレートの Django CMS プロジェクトが作成されます。
ls -F
manage.py* media/ myproject/ project.db requirements.in requirements.txt static/ venv/
これで、一時的な仮想環境を終了して削除できます。
deactivate rm -rf venv
ここから、Django CMS がコンテナ内で呼び出されます。
自動的にコピーされた requirements.in ファイル(pip-tools が requirements.txt ファイルを生成するために使用する)を削除することもできます。この Codelab では使用されません。
rm requirements.in
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
バケットに保存されるオブジェクトのオリジンは異なるため(Cloud Run の URL ではなくバケットの URL)、クロスオリジン リソース シェアリング(CORS)の設定を構成する必要があります。
次の内容の新しいファイルを cors.json
という名前で作成します。
touch cors.json cloudshell edit cors.json
cors.json
[
{
"origin": ["*"],
"responseHeader": ["Content-Type"],
"method": ["GET"],
"maxAgeSeconds": 3600
}
]
新しく作成したストレージ バケットに、この CORS 構成を適用します。
gsutil cors set cors.json gs://$GS_BUCKET_NAME
構成をシークレットとして保存する
バッキング サービスを設定したら、これらの値を 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
この Secret へのアクセスをサービス アカウントに許可します。
gcloud secrets add-iam-policy-binding application_settings \ --member serviceAccount:${SERVICE_ACCOUNT} --role roles/secretmanager.secretAccessor
シークレットを一覧表示して、シークレットが作成されたことを確認します。
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 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"
各構成について追加された解説をお読みください。
このファイルには 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
これで、デフォルトのウェブ エントリ ポイント、データベース移行を適用する 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 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
デプロイが完了するまで少しお待ちください。成功すると、コマンドラインにサービス URL が表示されます。
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
ウェブブラウザで次の URL を開くと、デプロイしたコンテナにアクセスできます。
これは新規インストールなので、ログインページに自動的にリダイレクトされます。
9. Django 管理へのアクセス
Django CMS の主な機能の一つは、インタラクティブな管理機能です。
CSRF 設定の更新
Django には、クロスサイト リクエスト フォージェリ(CSRF)に対する保護対策が用意されています。Django 管理者へのログインなど、Django サイトでフォームが送信されるたびに、[Trusted Origins] の設定がチェックされます。リクエストの送信元と一致しない場合、Django はエラーを返します。
mysite/settings.py
ファイルで、CLOUDRUN_SERVICE_URL
環境変数が定義されている場合は、CSRF_TRUSTED_ORIGINS
と ALLOWED_HOSTS
の設定でその変数が使用されます。ALLOWED_HOSTS
の定義は必須ではありませんが、CSRF_TRUSTED_ORIGINS
ではすでに必須となっているため、追加することをおすすめします。
サービス URL が必要なため、最初のデプロイが完了するまでこの構成を追加することはできません。
この環境変数を追加するには、サービスを更新する必要があります。これは、application_settings Secret に追加するか、環境変数として直接追加します。
サービスの URL を取得します。
CLOUDRUN_SERVICE_URL=$(gcloud run services describe djangocms-cloudrun \ --platform managed \ --region $REGION \ --format "value(status.url)") echo $CLOUDRUN_SERVICE_URL
Cloud Run サービスで、この値を環境変数として設定します。
gcloud run services update djangocms-cloudrun \ --region $REGION \ --update-env-vars CLOUDRUN_SERVICE_URL=$CLOUDRUN_SERVICE_URL
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 djangocms-cloudrun \ --platform managed \ --region $REGION \ --image gcr.io/${PROJECT_ID}/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