アプリケーションをテストしてデプロイする

リージョン ID

REGION_ID は、アプリの作成時に選択したリージョンに基づいて Google が割り当てる省略形のコードです。一部のリージョン ID は、一般的に使用されている国や州のコードと類似しているように見える場合がありますが、このコードは国または州に対応するものではありません。2020 年 2 月以降に作成されたアプリの場合、REGION_ID.r は App Engine の URL に含まれています。この日付より前に作成されたアプリの場合、URL のリージョン ID は省略可能です。

詳しくは、リージョン ID をご覧ください。

OK

Go Java Node.js PHP Python Ruby .NET カスタム

アプリケーションをローカルで実行し、App Engine にデプロイしてテストする方法を説明します。

ローカルで実行する

デプロイ前にアプリケーションをテストするには、普段使用している開発ツールを使用して、アプリケーションをローカル環境で実行します。たとえば、Flask の開発用サーバーで Flask アプリケーションを実行する場合、通常は次のコマンドを使用します。

python main.py

Django アプリケーションを起動する場合は、次のコマンドを使用します。

python manage.py runserver

App Engine 本番環境をシミュレートするには、完全なウェブ サーバー ゲートウェイ インターフェース（WSGI）サーバーをローカルで実行します。app.yaml ファイルで entrypoint として指定したのと同じコマンドを使用してください。次に例を示します。

gunicorn -b :$PORT main:app

アプリケーションをデプロイする

gcloud app deploy コマンドを使用して、アプリケーションを App Engine にデプロイします。

デプロイするアプリは Cloud Build サービスによって自動的にコンテナ イメージにビルドされ、そのイメージが App Engine フレキシブル環境にデプロイされます。このコンテナには、ローカルでランタイム イメージに行った変更が含まれます。

プログラムによってアプリをデプロイする場合は、Admin API を使用します。

始める前に

アプリケーションをデプロイする前に、次のことを確認してください。

• Google Cloud プロジェクトのオーナーが App Engine 用に Google Cloud プロジェクトを設定する必要があります。

• ユーザー アカウントに必要な権限が割り当てられていることを確認します。

デプロイを成功させるための注意事項

更新されたヘルスチェックを有効にすると、アプリケーションが正常な状態でない場合にデプロイがロールバックされます。最初のアプリケーションをフレキシブル環境にデプロイするときに、仮想マシン（VM）や他のインフラストラクチャが設定されていると、遅延が発生することがあります。最初のセットアップ後、ヘルスチェックは、インスタンスが正常で、トラフィックを受信可能な状態であることを確認します。app.yaml ファイルの liveness_check セクションの initial_delay_sec フィールドで指定された時間内にアプリケーションが準備完了ステータスに到達しない場合、デプロイは失敗しロールバックされます。

アプリケーションが準備完了になるまで時間がかかる場合があります。たとえば、アプリケーションの初期化時に、大きなファイルのダウンロードやキャッシュのプリロードが行われることがあります。最新のヘルスチェックを使用している場合は、app.yaml ファイルの readiness_check セクションで app_start_timeout_sec 構成設定を変更して、この時間を延長できます。

デプロイが失敗した場合は、Cloud Build API がプロジェクトで有効になっていることを確認してください。この API は、初めてアプリをデプロイする際に App Engine により自動的に有効になりますが、その後に無効にされた場合はデプロイが失敗します。

サービスをデプロイする

アプリケーション サービスのバージョンと構成ファイルをデプロイし、App Engine にアプリケーションをデプロイします。

アプリケーションのサービスをデプロイするには、サービスの app.yaml ファイルが存在するディレクトリから次のコマンドを実行します。

gcloud app deploy

デフォルトでは、gcloud app deploy コマンドは、現在のディレクトリに app.yaml ファイルのみをデプロイします。このコマンドを実行すると、App Engine はデプロイするバージョンの一意の ID を生成し、gcloud CLI で使用するように構成した Google Cloud プロジェクトにそのバージョンをデプロイして、すべてのトラフィックを新しいバージョンに転送します。新しいバージョンがデフォルトのバージョンになります。

注: Google Cloud コンソールで App Engine の [バージョン] ページを確認するか、gcloud app deploy コマンドを実行した後に gcloud app versions list を実行して、トラフィックを受信しているバージョンを確認することをおすすめします。

deploy コマンドのデフォルトの動作は、対象のファイルを指定するか、バージョンを指定するか、追加のパラメータを指定することで変更できます。

• 各ファイルを個別にターゲットとして指定してデプロイすることで、サービスの他の構成ファイルをデプロイできます。以下に例を示します。

  gcloud app deploy cron.yaml
  gcloud app deploy dispatch.yaml
  gcloud app deploy index.yaml
  

• 独自のバージョン ID を指定するには、--version フラグを使用します。

• トラフィックが新しいバージョンに自動的にルーティングされないようにするには、--no-promote フラグを使用します。

• 特定の Google Cloud プロジェクトにデプロイするには、--project フラグを使用します。

たとえば、app.yaml ファイルで定義されているサービスを特定の Google Cloud プロジェクトにデプロイし、独自のバージョン ID を割り当て、トラフィックが新しいバージョンにルーティングされないようにするには、次のコマンドを実行します。

gcloud app deploy --project PROJECT_ID --version VERSION_ID --no-promote

詳細については、gcloud app deploy リファレンスをご覧ください。

gcloud CLI 用のプロパティを設定し、SDK 構成を作成して管理すると、デプロイのたびに --project などのフラグを指定する必要がなくなります。

複数のサービスをデプロイする

アプリケーションを構成する複数のサービスをデプロイまたは更新する場合にも、同じデプロイ コマンドを使用します。

開始する前に:

• 最初にアプリケーションのバージョンの 1 つを default サービスにデプロイする必要があります。これで、後続のサービスを作成してデプロイできるようになります。

• 各サービスの ID は、対応する app.yaml 構成ファイルで指定する必要があります。サービス ID を指定するには、各構成ファイルに service 要素の定義を追加します。この要素の定義が構成ファイル内にないと、デフォルトでバージョンのデプロイ先は default サービスとなります。

複数のサービスをデプロイするには、各サービスの app.yaml ファイルを個別にデプロイする必要があります。以下に例を示します。

gcloud app deploy service1/app.yaml
gcloud app deploy service2/app.yaml

1 つのデプロイ コマンドで、複数のファイルを指定できます。

gcloud app deploy service1/app.yaml service2/app.yaml

ファイルを無視する

.gcloudignore ファイルを使用すると、サービスのデプロイ時に Google Cloud にアップロードしないファイルとディレクトリを指定できます。これは、デプロイ時にアップロードする必要のないビルド アーティファクトやその他のファイルを無視する場合に便利です。

注: .gcloudignore ファイルが存在する場合は、app.yaml ファイル内で skip_files フィールドを指定できません。

.gcloudignore ファイルの構文の詳細については、gcloud リファレンスをご覧ください。

デプロイ用にコンテナを手動でビルドする

注意: Container Registry は非推奨となりました。今後、提供終了となります。2024 年 1 月 8 日より前に Container Registry を使用していない組織では、デフォルトで Artifact Registry に新しい gcr.io リポジトリがホストされます。2024 年 5 月 15 日以降、それまで Container Registry を使用していなかった Google Cloud プロジェクトでは、Artifact Registry で gcr.io ドメインのイメージのホスティングと管理のみがサポートされます。

Container Registry は 2025 年 3 月 18 日に提供終了となる予定です。サポート終了の詳細については、Container Registry のサポート終了をご覧ください。

Google Cloud の外部でコンテナ イメージをビルドする手順は次のとおりです。

1. イメージを Artifact Registry リポジトリにアップロードします。詳細については、イメージの push と pull をご覧ください。
2. gcloud app deploy コマンドを使用してイメージを App Engine にデプロイします。

たとえば Docker を使用してローカルでコンテナ イメージをビルドした場合は、イメージを Artifact Registry に push し、次のようにコマンドの --image-url フラグでイメージの URL を指定できます。

gcloud app deploy --image-url LOCATION-docker.pkg.dev/PROJECT-ID/REPOSITORY/IMAGE

次のように置き換えます。

• LOCATION は、イメージが保存されているリポジトリの場所に置き換えます。

• PROJECT-ID は、Google Cloud プロジェクト ID に置き換えます。

• REPOSITORY は、イメージが保存されているリポジトリの名前に置き換えます。

• IMAGE は、コンテナ イメージの名前に置き換えます。

自動化された継続的デプロイ パイプラインを使用する

Cloud Build では、継続的デプロイ パイプラインを使用してデプロイを自動化できます。詳細については、Cloud Build ドキュメントの App Engine へのデプロイとビルドトリガーの作成と管理をご覧ください。

Docker のベースイメージ

カスタム ランタイム アプリケーションをビルドする場合は、Docker ファイルを作成するをご覧ください。

アプリケーションを表示する

アプリケーションを App Engine にデプロイした後、次のコマンドを実行してブラウザを起動できます。https://PROJECT_ID.REGION_ID.r.appspot.com にアクセスすると、アプリケーションが表示されます。

gcloud app browse

App Engine でテストする

新しいバージョンを構成してトラフィックを受信する前に、App Engine でテストを行うことができます。たとえば、default サービスの新しいバージョンをテストする手順は次のとおりです。

1. promote パラメータを false に設定して新しいバージョン。--no-promote フラグを含めます。

   gcloud app deploy --no-promote

2. 次の URL に移動して、新しいバージョンにアクセスします。

   https://VERSION_ID-dot-default-dot-PROJECT_ID.REGION_ID.r.appspot.com

   注: Google Cloud コンソールでバージョン ID を確認するか、version パラメータでデプロイするときにバージョン ID を指定できます。

   これで、新しいバージョンを App Engine ランタイム環境でテストできるようになりました。Google Cloud コンソールのログ エクスプローラにログを表示して、アプリケーションをデバッグできます。詳細については、アプリケーション ログの書き込みをご覧ください。

   https://PROJECT_ID.REGION_ID.r.appspot.com に送信されたリクエストは、トラフィックを受信するように以前に構成したバージョンに引き続きルーティングされます。

3. トラフィックが新しいバージョンに送信されるようにするには、Google Cloud コンソールでトラフィックを移行します。

   バージョンの管理

   デプロイしたバージョンを選択して、[トラフィックを移行] をクリックします。

同じ手順で他のサービスの新しいバージョンをテストできます。この場合、上記の URL の default をサービスの名前に置き換えます。

https://VERSION-dot-SERVICE-dot-PROJECT_ID.REGION_ID.r.appspot.com

特定のサービスとバージョンをターゲットにする方法については、リクエストのルーティング方法をご覧ください。

ビルド環境変数を使用する

Buildpack をサポートするランタイム用のビルド環境変数を設定することもできます。

ビルド環境変数は、アプリのデプロイに使用する Buildpack の構成に指定できる Key-Value ペアです。たとえば、コンパイラ オプションを指定できます。

始める前に、次のことを行います。

• キーの先頭は大文字の ASCII 文字にする必要があります。キーには大文字の ASCII 文字、数字、アンダースコアのみ使用できます。
• 接尾辞に GOOGLE_* キーを持つ変数は作成しないでください。
• 次のキーは Google で使用するために予約されています。
  • GOOGLE_RUNTIME
  • GOOGLE_RUNTIME_VERSION
  • GOOGLE_ENTRYPOINT
  • GOOGLE_DEVMODE
• Buildpack でサポートされている任意の鍵を使用できます。

Buildpack で環境変数を使用するには、app.yaml ファイルで build_env_variables フィールドを指定します。

Buildpack の詳細については、こちらをご覧ください。

Cloud Trace を使用する

Cloud Trace は、リクエストがアプリケーションを通じてどのように伝播するかを把握するために役立ちます。リクエストごとの詳しいレイテンシ情報の分析や、アプリケーション全体のレイテンシの確認などができます。

トレースの詳細の表示ができます。Trace エクスプローラでは、特定の App Engine サービスとバージョンでフィルタできます。

トラブルシューティング

アプリのデプロイ時に発生する可能性のある一般的なエラー メッセージは次のとおりです。

PERMISSION_DENIED: Operation not allowed

The "appengine.applications.create" permission is required.

必要な App Engine アプリケーションが Google Cloud プロジェクトに含まれていない場合、gcloud app deploy コマンドが gcloud app create コマンドを実行しようとしたときに失敗する可能性があります。App Engine アプリケーションの作成に必要な権限は、オーナーのロールを持つアカウントのみに付与されています。

502 Bad Gateway

app.yaml の構成に誤りがあると、Google Cloud プロジェクトを起動できないことがあります。詳細なエラー メッセージについては、アプリのログを確認してください。

[13] An internal error occurred while creating a Cloud Storage bucket.

App Engine が、アプリケーションを作成するリージョンと同じリージョンに、デフォルトの Cloud Storage マルチリージョン バケットを作成します。アプリケーションのコンテンツを保存するために、このバケットが必要です。次のシナリオのように、このバケットを作成できない場合に、エラーが返されます。

• App Engine フレキシブル環境サービス エージェントがプロジェクトに存在しないか、App Engine flexible environment Service Agent ロールがありません。正しい IAM 権限を付与することで、エージェントのサービス アカウントをプロジェクトに戻すことができます。削除されたサービス エージェントを復元するをご覧ください。

• デフォルトの App Engine サービス アカウントがプロジェクトに存在しません。App Engine サービス アカウントが削除されてから 30 日が経過する前であれば、そのアカウントを復元できます。

• プロジェクトが constraints/gcp.resourceLocations ポリシーを適用している組織に属しており、その組織では、作成された App Engine のリージョンと同じリージョンでのリソースの作成が許可されていません。プロジェクトに適用される constraints/gcp.resourceLocations ポリシーをオーバーライドし、App Engine アプリが作成されるのと同じリージョンでマルチリージョン ロケーションを許可する必要があります。

たとえば、App Engine アプリが europe-west リージョンで作成される場合、このリージョンが europe-west1 のロケーションにマッピングされている場合でも、in:eu-locations（これにはすべての EU リージョンが含まれます）のリソースを許可するように制約を変更する必要があります。App Engine で作成されるバケットがマルチリージョン バケットであるため、このような変更が必要です。App Engine アプリが US リージョンで作成される場合は in:us-locations を許可し、ASIA リージョンで作成された場合は in:asia-locations を許可する必要があります。

[13] An internal error occurred.

このエラーは、共有 VPC 設定を使用してネットワーク構成でサービスをデプロイしている場合に発生する可能性があります。次のようにしてください。

1. app.yaml 構成が有効であることを確認します。
2. App Engine フレキシブル環境が、共有 VPC 設定のすべての要件を満たしていることを確認します。共有 VPC ネットワークでの App Engine フレキシブル環境の使用をご覧ください。
3. プロジェクト内でサービス アカウントが構成されていることを確認します。ない場合は、アカウントを復元する必要があります。共有 VPC ホスト プロジェクトのサブネット リージョンは、App Engine 環境が作成されたロケーションと一致する必要があります。

問題が解決しない場合は、Google Cloud SDK を使用してサービスを再デプロイします。必ず --verbosity=debug フラグを追加してください。Google Cloud サポートに連絡し、コマンドの出力をお知らせください。

IP space of {USER_SUBNETWORK_NAME} is exhausted and needs to be expanded.

このエラー メッセージでデプロイが失敗した場合、App Engine サービス用に構成されたネットワークに、サービスの新しいインスタンスに割り振るアドレスが残っていません。この問題を解決するには、App Engine フレキシブル環境サービス用に構成されたサブネットで VPC の範囲を拡張するします。