Cloud Run 環境での Django の実行

Django のような Cloud Run にステートフル アプリケーションをにデプロイすると、サービスが連携して統合プロジェクトを形成します。

このチュートリアルは、Django ウェブ開発の知識があることを前提としています。Django 開発を初めて使用する場合は、続行する前に最初の Django アプリを作成するを実施することをおすすめします。

このチュートリアルでは Django について具体的に説明しますが、このデプロイ プロセスは Wagtail や Django CMS などの他の Django ベースのフレームワークでも使用できます。

このチュートリアルでは Django 5 を使用します。Django 5 には Python 3.10 以降が必要です。

目標

このチュートリアルの内容は次のとおりです。

• Cloud SQL データベースを作成して接続する。
• Secret Manager のシークレット値を作成して使用する。

• Django アプリを Cloud Run にデプロイする。

• Cloud Storage で静的ファイルをホストする。

• Cloud Build を使用してデプロイを自動化する。

費用

このドキュメントでは、課金対象である次の Google Cloudコンポーネントを使用します。

• Cloud SQL
• Cloud Storage
• Cloud Run
• Cloud Build
• Artifact Registry
• Secret Manager

料金計算ツールを使うと、予想使用量に基づいて費用の見積もりを生成できます。

新規の Google Cloud ユーザーは無料トライアルをご利用いただける場合があります。

始める前に

Google Cloud アカウントにログインします。 Google Cloudを初めて使用する場合は、 アカウントを作成して、実際のシナリオでの Google プロダクトのパフォーマンスを評価してください。新規のお客様には、ワークロードの実行、テスト、デプロイができる無料クレジット $300 分を差し上げます。
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
Roles required to select or create a project
• Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
• Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.
Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.
Go to project selector
Verify that billing is enabled for your Google Cloud project.
Enable the Cloud Run, Cloud SQL, Cloud Build, Secret Manager, Artifact Registry, and Compute Engine APIs.
Roles required to enable APIs
To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.
Enable the APIs
gcloud CLI をインストールします。
外部 ID プロバイダ（IdP）を使用している場合は、まず連携 ID を使用して gcloud CLI にログインする必要があります。
gcloud CLI を初期化するには、次のコマンドを実行します。
gcloud init
注: gcloud CLI をインストールせずに、 Google Cloud コンソールで gcloud CLI を実行できます。 Google Cloud コンソールで gcloud CLI を実行するには、Cloud Shell を使用します。

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Roles required to select or create a project

• Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
• Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

Enable the Cloud Run, Cloud SQL, Cloud Build, Secret Manager, Artifact Registry, and Compute Engine APIs.

Roles required to enable APIs

To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

Enable the APIs

gcloud CLI をインストールします。

外部 ID プロバイダ（IdP）を使用している場合は、まず連携 ID を使用して gcloud CLI にログインする必要があります。

gcloud CLI を初期化するには、次のコマンドを実行します。

gcloud init

注: gcloud CLI をインストールせずに、 Google Cloud コンソールで gcloud CLI を実行できます。 Google Cloud コンソールで gcloud CLI を実行するには、Cloud Shell を使用します。
1. このチュートリアルで使用するアカウントに十分な権限が付与されていることを確認してください。
   注: Owner ロールを使用できない場合、チュートリアルを完了するには、少なくとも Cloud SQL 管理者、ストレージ管理者、Cloud Run 管理者、Artifact Registry 管理者、Secret Manager 管理者のロールが必要です。

環境を準備する

サンプルアプリのクローンを作成する

Django サンプルアプリのコードは、GitHub の GoogleCloudPlatform/python-docs-samples リポジトリにあります。

1. ZIP ファイルとしてサンプルをダウンロードして展開するか、ローカルマシンにリポジトリのクローンを作成します。

   git clone https://github.com/GoogleCloudPlatform/python-docs-samples.git
   

2. サンプルコードのあるディレクトリに移動します。

   Linux / macOS

   cd python-docs-samples/run/django
   

   Windows

   cd python-docs-samples\run\django
   

Python の設定を確認する

このチュートリアルでは、Python を使用してサンプル アプリケーションをマシン上で実行します。サンプルコードでは依存関係もインストールする必要があります。

詳細については、Python 開発環境ガイドをご覧ください。

1. Python のバージョンが 3.10 以降であることを確認します。

    python -V
   

   Python 3.10.0 以上が表示される必要があります。

   注: バージョン番号が「2」で始まる場合は、python ではなく、python3 を実行する必要があります。この場合、python コマンドの実行時には、必ず選択した Python インストールを参照してください。

2. Python 仮想環境を作成し、依存関係をインストールします。

   Linux / macOS

   python -m venv venv
   source venv/bin/activate
   pip install --upgrade pip
   pip install -r requirements.txt
   

   Windows

   python -m venv venv
   venv\scripts\activate
   pip install --upgrade pip
   pip install -r requirements.txt
   

ローカルマシンから Cloud SQL Auth Proxy をダウンロードして Cloud SQL に接続する

注: このチュートリアルを Cloud Shell から完了している場合、このセクションは必要ありません。

デプロイされたアプリは、Cloud Run 環境に組み込まれた Cloud SQL Auth Proxy を使用して Cloud SQL インスタンスと通信します。ただし、アプリをローカルでテストするには、プロキシのローカルコピーを開発環境にインストールして使用する必要があります。詳しくは、Cloud SQL Auth Proxy ガイドをご覧ください。

Cloud SQL Auth Proxy は、Cloud SQL API を使用して SQL インスタンスとやり取りします。これを行うには、gcloud CLI でアプリケーションの認証を行う必要があります。

1. API の認証情報を取得して認証します。

   gcloud auth application-default login
   

2. Cloud SQL Auth Proxy をダウンロードしてローカルマシンにインストールします。

   Linux 64 ビット

   1. Cloud SQL Auth Proxy をダウンロードします。

      curl -o cloud-sql-proxy https://storage.googleapis.com/cloud-sql-connectors/cloud-sql-proxy/v2.21.1/cloud-sql-proxy.linux.amd64

   2. Cloud SQL Auth Proxy を動作可能にします。

      chmod +x cloud-sql-proxy

   Linux 32 ビット

   1. Cloud SQL Auth Proxy をダウンロードします。

      curl -o cloud-sql-proxy https://storage.googleapis.com/cloud-sql-connectors/cloud-sql-proxy/v2.21.1/cloud-sql-proxy.linux.386

   2. curl コマンドが見つからない場合は、sudo apt install curl を実行してダウンロード コマンドを繰り返します。
   3. Cloud SQL Auth Proxy を動作可能にします。

      chmod +x cloud-sql-proxy

   macOS 64 ビット

   1. Cloud SQL Auth Proxy をダウンロードします。

      curl -o cloud-sql-proxy https://storage.googleapis.com/cloud-sql-connectors/cloud-sql-proxy/v2.21.1/cloud-sql-proxy.darwin.amd64

   2. Cloud SQL Auth Proxy を動作可能にします。

      chmod +x cloud-sql-proxy

   Mac M1

   1. Cloud SQL Auth Proxy をダウンロードします。

        curl -o cloud-sql-proxy https://storage.googleapis.com/cloud-sql-connectors/cloud-sql-proxy/v2.21.1/cloud-sql-proxy.darwin.arm64
        

   2. Cloud SQL Auth Proxy を動作可能にします。

        chmod +x cloud-sql-proxy
        

   Windows 64 ビット

   https://storage.googleapis.com/cloud-sql-connectors/cloud-sql-proxy/v2.21.1/cloud-sql-proxy.x64.exe を右クリックして [名前を付けてリンク先を保存] を選択し、Cloud SQL Auth Proxy をダウンロードします。ファイル名を cloud-sql-proxy.exe に変更します。

   Windows 32 ビット

   https://storage.googleapis.com/cloud-sql-connectors/cloud-sql-proxy/v2.21.1/cloud-sql-proxy.x86.exe を右クリックして [名前を付けてリンク先を保存] を選択し、Cloud SQL Auth Proxy をダウンロードします。ファイル名を cloud-sql-proxy.exe に変更します。

   Cloud SQL Auth Proxy Docker イメージ

   Cloud SQL Auth Proxy には、distroless、alpine、buster など、さまざまなコンテナ イメージがあります。デフォルトの Cloud SQL Auth Proxy コンテナ イメージでは、シェルを含まない distroless を使用します。シェルまたは関連ツールが必要な場合は、alpine または buster を基盤とするイメージをダウンロードします。詳細については、Cloud SQL Auth Proxy コンテナ イメージをご覧ください。

   次のコマンドを使用して、ローカルマシンに最新のイメージを Docker で pull できます。

   docker pull gcr.io/cloud-sql-connectors/cloud-sql-proxy:2.21.1
   

   注: Cloud SQL Auth Proxy は、gcr.io ドメインをサポートする一方で Artifact Registry からイメージを提供するリポジトリを使用します。詳細については、Container Registry からの移行をご覧ください。

   その他の OS

   ここに記載されていないその他のオペレーティング システムの場合は、ソースから Cloud SQL Auth Proxy をコンパイルできます。

   ダウンロード先は、PATH の場所やホーム ディレクトリなど、一般的な場所に移動できます。これを行う場合は、チュートリアルの後半で Cloud SQL Auth Proxy を起動する際の cloud-sql-proxy コマンド使用時に、選択したロケーションを必ず参照してください。

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

このチュートリアルでは、さまざまな Google Cloud サービスを使用して、デプロイ済みの Django プロジェクトをサポートするデータベース、メディア ストレージ、シークレット ストレージを準備します。これらのサービスは、特定のリージョンにデプロイされます。サービス間の効率を高めるために、すべてのサービスを同じリージョンにデプロイすることをおすすめします。最も近いリージョンの詳細については、リージョン別に提供されるプロダクトをご覧ください。

このチュートリアルでは、Cloud Run 環境で統合された静的アセット ホスティング メカニズムを使用します。

Cloud SQL for PostgreSQL インスタンスを設定する

Django は正式に複数のリレーショナル データベースに対応していますが、PostgreSQL に最も対応しています。PostgreSQL は Cloud SQL でサポートされているため、このチュートリアルではそのようなタイプのデータベースを使用します。

次のセクションでは、アプリ用の PostgreSQL インスタンス、データベース、データベース ユーザーの作成について説明します。

1. PostgreSQL インスタンスを作成します。

   コンソール

   1. Google Cloud コンソールで、[Cloud SQL インスタンス] ページに移動します。

      Cloud SQL インスタンス ページに移動

   2. [インスタンスを作成] をクリックします。

   3. [PostgreSQL を選択] をクリックします。

   4. [SQL Edition] で、[Enterprise] を選択します。

   5. [エディションのプリセット] で、[サンドボックス] を選択します。

   6. [インスタンス ID] フィールドに「INSTANCE_NAME」と入力します。

   7. postgres ユーザーのパスワードを入力します。

   8. 他のフィールドはデフォルト値を使用します。

   9. [インスタンスを作成] をクリックします。

   インスタンスを使用できるようになるまで数分かかります。

   gcloud

   • PostgreSQL インスタンスを作成します。

     gcloud sql instances create INSTANCE_NAME \
         --project PROJECT_ID \
         --database-version POSTGRES_16 \
         --tier db-n1-standard-2 \
         --region REGION
     

   以下を置き換えます。

   • INSTANCE_NAME: Cloud SQL インスタンス名
   • PROJECT_ID: Google Cloud プロジェクト ID
   • REGION: Google Cloud リージョン

   インスタンスの作成と使用準備が完了するまでに数分かかります。

2. 作成したインスタンス内に、データベースを作成します。

   Console

   1. インスタンス ページで、[データベース] タブに移動します。
   2. [データベースを作成] をクリックします。
   3. [データベース名] ダイアログで「DATABASE_NAME」と入力します。
   4. [作成] をクリックします。

   gcloud

   • 最近作成したインスタンス内にデータベースを作成します。

     gcloud sql databases create DATABASE_NAME \
         --instance INSTANCE_NAME
     

     DATABASE_NAME を、このインスタンス内のデータベースの名前に置き換えます。

3. データベース ユーザーを作成するには:

   注: この方法で作成したユーザーには、追加のデータベース権限が付与されます。別の方法については、データベース ユーザーの権限を制限するをご覧ください。

   Console

   1. インスタンス ページで、[ユーザー] タブに移動します。
   2. [ユーザー アカウントを追加] をクリックします。
   3. [組み込み認証] の [認証方法を選択してください] ダイアログで、次の操作を行います。
   4. DATABASE_USERNAME というユーザー名を入力します。
   5. DATABASE_PASSWORD というパスワードを入力します。
   6. [追加] をクリックします。

   gcloud

   • 最近作成したインスタンス内にデータベース ユーザーを作成します。

     gcloud sql users create DATABASE_USERNAME \
         --instance INSTANCE_NAME \
         --password DATABASE_PASSWORD
     

     PASSWORD を安全なパスワードに置き換えます。

Artifact Registry を設定する

Artifact Registry を使用して、コンテナ イメージを保存するレジストリを作成します。

注: このリポジトリは、Cloud Run ソース デプロイを使用すると自動的に作成されます。プロジェクトにすでに存在している可能性があります。

コンソール

1. Google Cloud コンソールで、[Artifact Registry] ページに移動します。

   Artifact Registry ページに移動

2. [リポジトリを作成] をクリックします。

3. 次の情報を入力します。

   • [名前] に「cloud-run-source-deploy」と入力します。
   • [形式] で [Docker] を選択します。
   • [リージョン] で REGION を選択します。

4. 他のフィールドはデフォルト値を使用します。

5. [作成] をクリックします。

gcloud

• Artifact Registry を作成します。

gcloud artifacts repositories create cloud-run-source-deploy \
    --repository-format docker \
    --location REGION

Cloud Storage バケットを設定する

Django に含まれている静的アセットやユーザーがアップロードしたメディアを、Cloud Storage を使用する可用性の高いオブジェクト ストレージに保存できます。django-storages[google] パッケージは、Django とこのストレージ バックエンドとのインタラクションを処理します。

コンソール

1. Google Cloud コンソールで、[Cloud Storage] ページに移動します。

   Cloud Storage ページに移動

2. [バケットを作成] をクリックします。

3. 以下を入力します（必要に応じて [続行] をクリックします）。

   • [名前] に「PROJECT_ID_MEDIA_BUCKET」と入力します。
   • [リージョン] で REGION を選択します。
   • [ストレージ クラス] はデフォルトのままにします。
   • [公開アクセスの防止] で、[公開アクセス禁止を適用する] をオフにします。
   • [アクセス制御] で [きめ細かい管理] を選択します。

4. 他のフィールドはデフォルト値を使用します。

5. [作成] をクリックします。

gcloud

• Cloud Storage バケットを作成します。

  gcloud storage buckets create gs://PROJECT_ID_MEDIA_BUCKET --location=REGION
  

  MEDIA_BUCKET は、メディア バケットの接尾辞に置き換えます。プロジェクト ID と組み合わされることで、一意のバケット名になります。

Secret Manager にシークレット値を保存する

バッキング サービスが構成されたので、Django はこれらのサービスに関する情報を必要とします。このチュートリアルでは、これらの値を Django のソースコードに直接入力せず、Secret Manager を使用してこの情報を安全に保存します。

Secret Manager シークレットとして Django 環境ファイルを作成する

Django の起動に必要な設定を、保護された env ファイルに保存します。サンプルアプリは、Secret Manager API を使用してシークレット値を取得し、django-environ パッケージを使用して Django 環境に値を読み込みます。シークレットは、Cloud Run と Cloud Build からアクセスできるように構成されています。

1. .env という名前のファイルを作成し、データベースの接続文字列、メディア バケット名、新しい SECRET_KEY 値を定義します。

   echo DATABASE_URL=postgres://DATABASE_USERNAME:DATABASE_PASSWORD@//cloudsql/PROJECT_ID:REGION:INSTANCE_NAME/DATABASE_NAME > .env
   echo GS_BUCKET_NAME=PROJECT_ID_MEDIA_BUCKET >> .env
   echo SECRET_KEY=$(cat /dev/urandom | LC_ALL=C tr -dc '[:alpha:]'| fold -w 50 | head -n1) >> .env
   

2. シークレットを Secret Manager に保存します。

   コンソール

   1. Google Cloud コンソールで、[Secret Manager] ページに移動します。

      シークレット マネージャー ページに移動

   2. [シークレットの作成] をクリックします。

   3. [名前] フィールドに「django_settings」と入力します。

   4. [シークレットの値] ダイアログで、.env ファイルの内容を貼り付けます。

   5. [シークレットの作成] をクリックします。

   6. ローカル設定のオーバーライドを防ぐため、ローカル ファイルを削除します。

   gcloud

   1. 新しいシークレット django_settings を .env ファイルの値で作成します。

      gcloud secrets create django_settings --data-file .env
      

   2. ローカル設定のオーバーライドを防ぐため、ローカル ファイルを削除します。

      rm .env
      

3. シークレットへのアクセスを設定します。

   コンソール

   1. [シークレット: django_settings] で、プロジェクト番号をメモします。

      projects/PROJECTNUM/secrets/django_settings
      

   2. [権限] タブをクリックします。

   3. [アクセス権を付与] をクリックします。

   4. [新しいメンバー] フィールドに「[e-mail]」と入力し、Enter を押します。

   5. [ロール] プルダウン メニューで [Secret Manager のシークレット アクセサー] を選択します。

   6. [保存] をクリックします。

   gcloud

   1. プロジェクト番号（PROJECTNUM）の値を取得します。

     gcloud projects describe PROJECT_ID --format='value(projectNumber)'
   

   1. Cloud Run サービス アカウントにシークレットへのアクセス権を付与します。

      gcloud secrets add-iam-policy-binding django_settings \
          --member serviceAccount:[e-mail] \
          --role roles/secretmanager.secretAccessor
      

   出力で、bindings が新しいサービス アカウントをリストしていることを確認します。

Django の管理者パスワード用のシークレットを作成する

Django 管理ユーザーは通常、インタラクティブ管理コマンド createsuperuser を実行して作成されます。

このチュートリアルでは、データ移行を使用して管理ユーザーを作成し、Secret Manager から管理パスワードを取得します。

コンソール

1. Google Cloud コンソールで、[Secret Manager] ページに移動します。

2. [シークレットの作成] をクリックします。

3. [名前] フィールドに「superuser_password」と入力します。

4. [シークレット値] フィールドにランダムな一意のパスワードを入力します。

5. [シークレットの作成] をクリックします。

6. [superuser_password の詳細] で、プロジェクト番号（projects/PROJECTNUM/secrets/superuser_password）をメモしておきます。

7. [権限] タブをクリックします。

8. [追加] をクリックします。

9. [新しいメンバー] フィールドに「[e-mail]」と入力し、Enter を押します。

10. [ロール] プルダウン メニューで [Secret Manager のシークレット アクセサー] を選択します。

11. [保存] をクリックします。

gcloud

1. ランダムに生成されたパスワードから新しい Secret superuser_password を作成します。

   echo -n "$(cat /dev/urandom | LC_ALL=C tr -dc '[:alpha:]'| fold -w 30 | head -n1)" | gcloud secrets create superuser_password --data-file -
   

2. Cloud Build にシークレットへのアクセス権を付与します。

   gcloud secrets add-iam-policy-binding superuser_password \
       --member serviceAccount:[e-mail] \
       --role roles/secretmanager.secretAccessor
   

   出力で、bindings が Cloud Build のみをメンバーとしてリストしていることを確認します。

ローカル コンピュータでアプリを実行する

バッキング サービスを設定したら、パソコン上でアプリを実行できます。この設定により、ローカルでの開発とデータベース移行の適用が可能になります。データベース移行は Cloud Build にも適用されますが、makemigrations を行うには、このローカル設定が必要です。

1. 別のターミナルで Cloud SQL Auth Proxy を起動します。

   Linux / macOS

   ./cloud-sql-proxy PROJECT_ID:REGION:INSTANCE_NAME
   

   Windows

   cloud-sql-proxy.exe PROJECT_ID:REGION:INSTANCE_NAME
   

   このステップで、ローカル パソコンから Cloud SQL インスタンスへのローカルテスト用接続が確立されます。ローカルでのアプリのテストが終了するまで、Cloud SQL Auth Proxy を実行したままにしてください。このプロセスを別のターミナルで実行すると、このプロセスの実行中も作業を継続できます。

2. 元のターミナルで、プロジェクト ID をローカルに設定します（Secret Manager API で使用します）。

   Linux / macOS

   export GOOGLE_CLOUD_PROJECT=PROJECT_ID
   

   Windows

   set GOOGLE_CLOUD_PROJECT=PROJECT_ID
   

3. Cloud SQL Auth Proxy を使用していることを示す環境変数を設定します（この値はコードで認識できます）。

   Linux / macOS

   export USE_CLOUD_SQL_AUTH_PROXY=true
   

   Windows

   set USE_CLOUD_SQL_AUTH_PROXY=true
   

4. Django の移行を実行してモデルとアセットを設定します。

   python manage.py makemigrations
   python manage.py makemigrations polls
   python manage.py migrate
   python manage.py collectstatic
   

5. Django ウェブサーバーを起動します。

   python manage.py runserver 8080
   

6. ブラウザで、http://localhost:8080 にアクセスします。

   Cloud Shell を使用している場合は、[ウェブでプレビュー] ボタンをクリックし、[ポート 8080 でプレビュー] を選択します。

   「Hello, world. You're at the polls index.」というテキストを含む簡単なウェブページが表示されます。コンピュータで実行されている Django ウェブサーバーは、サンプルアプリのページを配信します。

7. Ctrl/Cmd+C キーを押して、ローカル ウェブサーバーを停止します。

Cloud Run にアプリをデプロイする

バッキング サービスを設定できたので、Cloud Run サービスをデプロイできるようになりました。

1. 提供された cloudmigrate.yaml を使用して、Cloud Build を使用してイメージをビルドし、データベースの移行を実行して、静的アセットにデータを入力します。

   gcloud builds submit --config cloudmigrate.yaml \
       --substitutions _INSTANCE_NAME=INSTANCE_NAME,_REGION=REGION
   

   最初のビルドが完了するまで数分かかります。

2. ビルドが成功したら、Cloud Run サービスを初めてデプロイし、サービス リージョン、ベースイメージ、接続された Cloud SQL インスタンスを設定します。

   gcloud run deploy polls-service \
       --region REGION \
       --image REGION-docker.pkg.dev/PROJECT_ID/cloud-run-source-deploy/polls-service \
       --add-cloudsql-instances PROJECT_ID:REGION:INSTANCE_NAME \
       --allow-unauthenticated
   

   サービスの URL とともに、デプロイが成功したことを示す出力が表示されます。

   Service [polls-service] revision [polls-service-00001-tug] has been deployed
   and is serving 100 percent of traffic.
   Service URL: https://polls-service-PROJECT_ID.REGION.run.app
   

3. サービス URL を環境変数としてサービスに更新します。

   CLOUDRUN_SERVICE_URLS=$(gcloud run services describe polls-service \
       --region $REGION  \
       --format "value(metadata.annotations[\"run.googleapis.com/urls\"])" | tr -d '"[]')
   
   gcloud run services update polls-service \
       --region REGION \
       --update-env-vars "^##^CLOUDRUN_SERVICE_URLS=$CLOUDRUN_SERVICE_URLS"
   

   注: これは CSRF を構成します。

4. デプロイされたサービスを確認するには、サービスの URL に移動します。

5. Django 管理にログインするには、URL に /admin を加え、ユーザー名 admin と前に設定したパスワードでログインします。

   Secret Manager からスーパーユーザー パスワードを取得するには:

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

アプリケーションを更新する

最初のプロビジョニングとデプロイの手順は複雑でしたが、更新はより簡単なプロセスです。

1. Cloud Build のビルドと移行スクリプトを実行します。

   gcloud builds submit --config cloudmigrate.yaml \
       --substitutions _INSTANCE_NAME=INSTANCE_NAME,_REGION=REGION
   

2. リージョンとイメージのみを指定して、サービスをデプロイします。

   gcloud run deploy polls-service \
       --region REGION \
       --image REGION-docker.pkg.dev/PROJECT_ID/cloud-run-source-deploy/polls-service
   

本番環境用の構成

これで Django のデプロイが機能するようになりましたが、アプリケーションが本番環境に対応できるよう、追加の手順を行う必要があります。

デバッグを無効にする

mysite/settings.py の DEBUG 変数が False に設定されていることを確認します。これにより、ユーザーに詳細なエラーページが表示されなくなり、設定に関する情報が漏洩を防ぎます。

データベース ユーザーの権限を制限する

Cloud SQLを使用して作成されたすべてのユーザーには、cloudsqlsuperuser ロールに関連付けられた特権（CREATEROLE、CREATEDB、および LOGIN）があります。

Django データベース ユーザーにこれらの権限が付与されないようにするには、PostgreSQL でユーザーを手動で作成します。psql インタラクティブ ターミナルをインストールするか、このツールがプリインストールされている Cloud Shell を使用する必要があります。

コンソール

1. Google Cloud コンソールで Cloud Shell をアクティブにします。

   Cloud Shell をアクティブにする

2. Cloud Shell で、組み込みターミナルを使用して INSTANCE_NAME インスタンスに接続します。

   gcloud sql connect INSTANCE_NAME --user postgres
   

3. postgres ユーザー パスワードを入力します。

   現在、psql を使用しています。postgres=> プロンプトが表示されます。

4. ユーザーを作成します。

   CREATE USER DATABASE_USERNAME WITH PASSWORD 'DATABASE_PASSWORD';
   

   PASSWORD は、ランダムな一意のパスワードに置き換えます。

5. 新しいデータベースに対する完全な権限を新しいユーザーに付与します。

   GRANT ALL PRIVILEGES ON DATABASE DATABASE_NAME TO DATABASE_USERNAME;
   

6. psql を終了します。

   \q
   

gcloud

注: Cloud SQL を使用して作成されたユーザーには、cloudsqlsuperuser のロールに関連付けられた権限（CREATEROLE、CREATEDB、LOGIN）が付与されます。このチュートリアルでは、PostgreSQL 内でユーザーを直接作成します。

1. SQL インスタンスへの接続を開始します。

   gcloud sql connect INSTANCE_NAME --user postgres
   

   INSTANCE_NAME は、作成した Cloud SQL インスタンスに置き換えます。

2. postgres ユーザー パスワードを入力します。

   現在、psql を使用しています。postgres=> プロンプトが表示されます。

3. ユーザーを作成します。

   CREATE USER DATABASE_USERNAME WITH PASSWORD 'DATABASE_PASSWORD';
   

4. 新しいデータベースに対する完全な権限を新しいユーザーに付与します。

   GRANT ALL PRIVILEGES ON DATABASE DATABASE_NAME TO DATABASE_USERNAME;
   

5. psql を終了します。

   \q
   

最小限の権限の設定

デフォルトでは、このサービスは、デフォルトのコンピューティング サービス アカウントでデプロイされます。ただし、デフォルトのサービス アカウントを使用すると、付与される権限が多くなりすぎることがあります。制限を強める必要がある場合は、独自のサービス アカウントを作成して、サービスに必要な権限のみを割り当てる必要があります。必要な権限は、特定のサービスにより使用されるリソースに応じて、サービスごとに異なります。

このサービスに必要な最小限のプロジェクト ロールは次のとおりです。

• Cloud Run 起動元
• Cloud SQL クライアント
• メディア バケットの Storage 管理者
• Django 設定シークレットの Secret Manager Accessor。（Django 管理シークレットへのアクセスは、サービス自体には必要ありません。）

必要な権限を持つサービス アカウントを作成し、サービスに割り当てるには、次のコマンドを実行します。

1. gcloud CLI で、必要なロールを持つサービス アカウントを作成します。

   gcloud iam service-accounts create polls-service-account
   SERVICE_ACCOUNT=polls-service-account@PROJECT_ID.iam.gserviceaccount.com
   
   # Cloud SQL Client
   gcloud projects add-iam-policy-binding PROJECT_ID \
       --member serviceAccount:${SERVICE_ACCOUNT} \
       --role roles/cloudsql.client
   
   # Storage Admin, on the media bucket
   gcloud storage buckets add-iam-policy-binding gs://MEDIA_BUCKET \
       --member=serviceAccount:${SERVICE_ACCOUNT} \
       --role=roles/storage.objectAdmin
   
   # Secret Accessor, on the Django settings secret.
   gcloud secrets add-iam-policy-binding django_settings \
       --member serviceAccount:${SERVICE_ACCOUNT} \
       --role roles/secretmanager.secretAccessor
   
   # Secret Accessor, on the Django super user password.
   gcloud secrets add-iam-policy-binding superuser_password \
       --member serviceAccount:${SERVICE_ACCOUNT} \
       --role roles/secretmanager.secretAccessor
   

2. サービスを新しいサービス アカウントに関連付けてデプロイします。

   gcloud run services update polls-service \
       --region REGION \
       --service-account ${SERVICE_ACCOUNT}
   

3. cloudmigrate.yaml の Cloud Run ジョブを更新して、この --service-account 設定も適用します。

コードを理解する

サンプル アプリケーション

Django サンプルアプリは、Django の標準ツールを使用して作成されています。次のコマンドは、プロジェクトとアンケート アプリを作成します。

django-admin startproject mysite
python manage.py startapp polls

ベースビュー、モデル、ルート構成は、最初の Django アプリを作成する（パート 1およびパート 2）からコピーされました。

Secret Manager のシークレット

settings.py ファイルには、Secret Manager Python API を使用して指定されたシークレットの最新バージョンを取得し、（django-environ を使用して）その環境に pull するコードが含まれています。

# SECURITY WARNING: don't run with debug turned on in production!
# Change this to "False" when you are ready for production
env = environ.Env(DEBUG=(bool, True))
env_file = os.path.join(BASE_DIR, ".env")

# Attempt to load the Project ID into the environment, safely failing on error.
try:
    _, os.environ["GOOGLE_CLOUD_PROJECT"] = google.auth.default()
except google.auth.exceptions.DefaultCredentialsError:
    pass

if os.path.isfile(env_file):
    # Use a local secret file, if provided

    env.read_env(env_file)
# ...
elif os.environ.get("GOOGLE_CLOUD_PROJECT", None):
    # Pull secrets from Secret Manager
    project_id = os.environ.get("GOOGLE_CLOUD_PROJECT")

    client = secretmanager.SecretManagerServiceClient()
    settings_name = os.environ.get("SETTINGS_NAME", "django_settings")
    name = f"projects/{project_id}/secrets/{settings_name}/versions/latest"
    payload = client.access_secret_version(name=name).payload.data.decode("UTF-8")

    env.read_env(io.StringIO(payload))
else:
    raise Exception("No local .env or GOOGLE_CLOUD_PROJECT detected. No secrets found.")

シークレットは、構成する必要のあるさまざまなシークレットの数を減らすために、複数のシークレット値を格納するために使用されます。

CSRF の構成

Django には、クロスサイト リクエスト フォージェリ（CSRF）に対する保護機能が組み込まれています。Django 4.0 以降では、この機能の動作方法が変更されました。そのため、ホストされている URL を Django に指示して、データを送信するユーザーを最適に保護できるようにすることが重要です。

アプリの URL を環境変数として settings.py ファイルで指定します。これは、Django で関連する設定に使用する値です。

# SECURITY WARNING: It's recommended that you use this when
# running in production. The URLs will be known once you first deploy
# to Cloud Run. This code takes the URLs and converts it to both these settings formats.
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]

    SECURE_SSL_REDIRECT = True
    SECURE_PROXY_SSL_HEADER = ("HTTP_X_FORWARDED_PROTO", "https")
else:
    ALLOWED_HOSTS = ["*"]

ローカル シークレットのオーバーライド

ローカルのファイル システムで .env ファイルが見つかった場合は、Secret Manager の値の代わりに使用されます。ローカルで .env ファイルを作成すると、ローカルテスト（SQLite データベースに対するローカル開発やその他のローカル設定など）に役立ちます。

データベースへの接続

settings.pyファイルには、SQL データベースの構成が含まれています。django-environ の env.db() ヘルパーを使用して、DATABASE_URL で設定された接続文字列を DATABASES 設定に読み込みます。

アプリケーションをローカルで実行し、Cloud SQL Auth Proxy を使用してホスト型データベースにアクセスする場合、USE_CLOUD_SQL_AUTH_PROXY フラグはプロキシを使用するようにデータベースの設定を調整します。

# Use django-environ to parse the connection string
DATABASES = {"default": env.db()}

# If the flag as been set, configure to use proxy
if os.getenv("USE_CLOUD_SQL_AUTH_PROXY", None):
    DATABASES["default"]["HOST"] = "127.0.0.1"
    DATABASES["default"]["PORT"] = 5432

クラウドに保存された静的

また、settings.py ファイルは、django-storages を使用して Cloud Storage メディア バケットをプロジェクトに直接統合します。

# Define static storage via django-storages[google]
GS_BUCKET_NAME = env("GS_BUCKET_NAME")
STATIC_URL = "/static/"
STORAGES = {
    "default": {
        "BACKEND": "storages.backends.gcloud.GoogleCloudStorage",
    },
    "staticfiles": {
        "BACKEND": "storages.backends.gcloud.GoogleCloudStorage",
    },
}
GS_DEFAULT_ACL = "publicRead"

Cloud Build による自動化

cloudmigrate.yaml は、新しいコンテナ イメージの作成と、それを使用したデータベース移行の適用に必要なすべての手順を処理します。

このチュートリアルでは、Buildpack を使用してコンテナ イメージをビルドし、Procfile のカスタム エントリ ポイントを使用して管理コマンドを処理します。これらは Cloud Run ジョブで参照してコマンドを実行できます。

steps:
  - id: "Build Container Image"
    name: gcr.io/k8s-skaffold/pack
    args: ["build", "${_IMAGE_NAME}", "--builder=gcr.io/buildpacks/builder"]

  - id: "Push Container Image"
    name: "gcr.io/cloud-builders/docker"
    args: ["push", "${_IMAGE_NAME}"]

  - id: "Migrate database"
    name: "gcr.io/google.com/cloudsdktool/cloud-sdk"
    entrypoint: /bin/bash
    args:
      - "-c"
      - |
        gcloud run jobs create migrate-job \
          --region ${_REGION} \
          --image ${_IMAGE_NAME} \
          --set-cloudsql-instances ${_CLOUD_SQL_CONNECTION_NAME} \
          --set-env-vars SETTINGS_NAME=${_SECRET_SETTINGS_NAME} \
          --command migrate \
          --execute-now

  - id: "Create superuser"
    name: "gcr.io/google.com/cloudsdktool/cloud-sdk"
    entrypoint: /bin/bash
    args:
      - "-c"
      - |
        gcloud run jobs create superuser-job \
          --region ${_REGION} \
          --image ${_IMAGE_NAME} \
          --set-cloudsql-instances ${_CLOUD_SQL_CONNECTION_NAME} \
          --set-env-vars SETTINGS_NAME=${_SECRET_SETTINGS_NAME} \
          --set-env-vars DJANGO_SUPERUSER_EMAIL=${_ADMIN_EMAIL} \
          --set-secrets DJANGO_SUPERUSER_PASSWORD=${_ADMIN_PASSWORD_NAME}:latest \
          --command createsuperuser \
          --execute-now

options:
  dynamicSubstitutions: true

substitutions:
  _INSTANCE_NAME: django-instance
  _CLOUD_SQL_CONNECTION_NAME: ${PROJECT_ID}:${_REGION}:${_INSTANCE_NAME}
  _REGION: us-central1
  _SERVICE_NAME: polls-service
  _SECRET_SETTINGS_NAME: django_settings
  _ARTIFACT_REGISTRY: cloud-run-source-deploy
  _IMAGE_NAME: ${_REGION}-docker.pkg.dev/${PROJECT_ID}/${_ARTIFACT_REGISTRY}/${_SERVICE_NAME}
  _ADMIN_EMAIL: [e-mail]
  _ADMIN_PASSWORD_NAME: superuser_password

images:
  - "${_IMAGE_NAME}"

この構成では代入変数が使用されます。

Cloud Run ジョブによるスーパーユーザーの作成

Django 管理コマンド createsuperuser は、DJANGO_SUPERUSER_EMAIL と DJANGO_SUPERUSER_PASSWORD を設定することで、インタラクティブではない方法で実行できます。

このチュートリアルでは、Cloud Run ジョブを使用してこのコマンドを実行します。これは、createsuperuser を実行する Procfile にカスタム エントリを追加することで行われます。

# Create superuser (requires DJANGO_SUPERUSER_PASSWORD and DJANGO_SUPERUSER_EMAIL envvars)
createsuperuser: python manage.py createsuperuser --username admin --noinput || echo "User already exists."

クリーンアップ

このチュートリアルで使用したリソースについて、Google Cloud アカウントに課金されないようにするには、リソースを含むプロジェクトを削除するか、プロジェクトを維持して個々のリソースを削除します。

プロジェクトを削除する

注意: プロジェクトを削除すると、次のような影響があります。

• プロジェクト内のすべてのものが削除されます。既存のプロジェクトを使用してこのドキュメントのタスクを行った場合、そのプロジェクトを削除すると、プロジェクト内で行った他の作業もすべて削除されます。
• カスタム プロジェクト ID が失われます。このプロジェクトを作成したときに、将来使用するカスタム プロジェクト ID を作成した可能性があります。そのプロジェクト ID を使用した URL（例: appspot.com）を保持するには、プロジェクト全体ではなく、プロジェクト内の選択したリソースだけを削除します。

複数のアーキテクチャ、チュートリアル、クイックスタートを実施する予定がある場合は、プロジェクトを再利用すると、プロジェクトの割り当て上限を超えないようにすることができます。

1. Google Cloud コンソールで [リソースの管理] ページに移動します。

   [リソースの管理] に移動

2. プロジェクト リストで、削除するプロジェクトを選択し、[削除] をクリックします。
3. ダイアログでプロジェクト ID を入力し、[シャットダウン] をクリックしてプロジェクトを削除します。

次のステップ

• PostgreSQL を本番環境用に構成する方法を学習する。
• Google Cloudでの Django について詳細を学習する。