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

リージョン ID

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

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

OK

Go Java Node.js PHP Python Ruby

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

ローカルで実行する

デプロイ前にアプリケーションをテストするには、普段使用している開発ツールを使用して、アプリケーションをローカル環境で実行します。 Google Cloud SDK に付属するローカル開発用サーバーである dev_appserver に依存するのではなく、標準的な Python ツールを使用することをおすすめします。こうしたツールには、隔離された環境を作成するための virtualenv、単体テストや統合テストを実行するための pytest などがあります。

たとえば、Flask の開発用サーバーで Flask アプリケーションを実行するには、通常以下のコマンドを使用します。

python main.py

次のコマンドを使用して Django アプリケーションを起動します。

python manage.py runserver

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

gunicorn -b :$PORT main:app

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

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

• Google Cloud プロジェクトのオーナーが App Engine 用に Google Cloud プロジェクトを設定する必要があります。
• ユーザー アカウントに必要な権限が割り当てられていることを確認します。

アプリケーションのデプロイ

gcloud app deploy コマンドを使用して、アプリケーションを App Engine にデプロイします。デプロイ中に、Cloud Build サービスがスタンダード環境で実行するアプリケーションのコンテナ イメージを作成します。各ビルドは、Google Cloud プロジェクトと同じリージョンで実行されます。詳細については、ビルドイメージを管理するをご覧ください。

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

サービスをデプロイする

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

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

gcloud app deploy

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

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

• サービスの他の構成ファイルをデプロイするには、各ファイルを個別にターゲットとして指定してデプロイする必要があります。例:

  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 リファレンスをご覧ください。

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

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

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

開始する前に:

• 最初にアプリケーションのバージョンの 1 つを default サービスにデプロイする必要があります。これで、後続のサービスを作成してデプロイできるようになります。
• 各サービスの ID は、対応する app.yaml 構成ファイルで指定する必要があります。サービス ID を指定するには、各構成ファイルに service 要素の定義を追加します。この要素の定義が構成ファイル内にないと、デフォルトでバージョンのデプロイ先は default サービスとなります。

複数のサービスをデプロイする場合は、各サービスの app.yaml ファイルを個別にデプロイします。次のように、1 つの gcloud app deploy コマンドで、複数のファイルを指定できます。

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

ビルドログを表示

Cloud Build がストリーミングしたビルドとデプロイのログは、Google Cloud コンソールの Cloud Build のビルド履歴セクションで確認できます。アプリのリージョンのビルドを表示するには、[リージョン] メニューを使用してリージョンでフィルタします。

ビルドイメージを管理する

注意: 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 のサポート終了をご覧ください。

新しいバージョンをデプロイするたびに、次の処理が行われます。

1. App Engine は、Cloud Build サービスを使用してコンテナ イメージを作成します。

2. Cloud Build は、アプリのリージョンでコンテナ イメージをビルドし、App Engine スタンダード環境で実行します。

3. App Engine は、ビルドされたコンテナ イメージを Artifact Registry に保存します。これらのイメージをダウンロードして、別の場所に保存する、または別の場所で実行できます。

デプロイが完了したコンテナ イメージは、App Engine ではもう必要でなくなります。コンテナ イメージは自動的に削除されません。保存容量の上限に達する前に、不要な画像を削除することをおすすめします。ただし、将来イメージが必要になった場合や、イメージのコピーを保持する場合は、削除する前にコピーをエクスポートする必要があります。Artifact Registry でのイメージの管理について詳しくは、イメージを管理するをご覧ください。

ファイルを無視する

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

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

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

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

gcloud app browse

トラフィック移行前の App Engine でのテスト

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

1. 新しいバージョンをデプロイしますが、トラフィックが新しいバージョンに自動的にルーティングされないようにするには、次のコマンドを実行します。

   gcloud app deploy --no-promote

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

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

   注: Google Cloud コンソールでバージョン ID を確認するか、--version flag でデプロイするときにバージョン ID を指定できます。また、デプロイ時に Google Cloud CLI でバージョン ID を出力することもできます。

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

   App Engine は、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 の詳細については、こちらをご覧ください。

ローカル開発用サーバーを使用する

Google Cloud CLI には、本番環境の App Engine で動作しているアプリケーションをシミュレートするために、ローカルで実行できるローカル開発用サーバー（dev_appserver）が含まれています。この開発用サーバーは、アプリケーションが実行される環境を部分的にシミュレートするため、任意のスタンダード環境ランタイム用に作成されたアプリをテストできます。

ローカル開発用サーバーの実行

重要:

• ローカル開発用サーバーを実行する前に、設定手順に沿って操作してください。
• dev_appserver ツールは、Windows での Python 3 アプリの開発をサポートしていません。

アプリの app.yaml 構成ファイルを作成した後、dev_appserver.py コマンドを使用してローカル開発用サーバーを起動し、アプリをローカルで実行できます。

1. ユーザー アカウントのアクセス認証情報を取得するには、次のコマンドを実行します。

   gcloud auth login
   

2. ローカル アプリケーションで、API アクセス用のユーザー認証情報の使用を一時的に許可します。

   gcloud auth application-default login
   

3. ローカル開発用サーバーを起動するには:

   app.yaml 構成ファイルを含むディレクトリで、dev_appserver.py コマンドを実行し、プロジェクト ID と app.yaml ファイルへのパスを指定します。

   python3 CLOUD_SDK_ROOT/bin/dev_appserver.py --application=PROJECT_ID app.yaml

   ポートを変更する場合は、--port オプションを含めます。

   python3 CLOUD_SDK_ROOT/bin/dev_appserver.py --application=PROJECT_ID app.yaml --port=9999

   Python 3 アプリをテストするには、Python 3 インタープリタで dev_appserver.py を実行し、--runtime_python_path フラグで Python 3 バイナリを指定する必要があります。たとえば、次のようにします。

   python3 CLOUD_SDK_ROOT/bin/dev_appserver.py --runtime_python_path=/usr/bin/python3 --application=PROJECT_ID app.yaml --port=9999

   dev_appserver.py コマンドのオプションについて詳しくは、ローカル開発用サーバーのオプションをご覧ください。

4. ローカル開発用サーバーが起動すると、開発環境がセットアップされ、requirements.txt ファイルにある依存関係が事前にインストールされます。

5. ローカル開発用サーバーが起動し、リクエストを待機します。ウェブブラウザで http://localhost:8080/ にアクセスして、アプリの動作を確認します。

   --port オプションでカスタムポートを指定した場合は、そのポートでブラウザを開くようにしてください。

6. ローカル サーバーをコマンドラインから停止するには、Control-C キーを押します。

アプリケーションのランタイム環境を検出する

コードが本番環境とローカル開発用サーバーのどちらで動作しているのかを確かめるには、GAE_ENV 環境変数を確認します。

if os.getenv('GAE_ENV', '').startswith('standard'):
  # Production in the standard environment
else:
  # Local execution.

Google Cloud サービスでローカル開発用サーバーを使用する

dev_appserver とその他の Google Cloud コンポーネントを統合できます。

Cloud クライアント ライブラリ

Google Cloud クライアント ライブラリの多くは、GOOGLE_CLOUD_PROJECT 環境変数（通常はご使用の Google Cloud プロジェクト ID）に依存しています。この値を確認するには、gcloud config list project コマンドを実行するか、Google Cloud コンソールでプロジェクト ページを参照します。

この環境変数がローカルでの開発時に正しく設定されるようにするには、上記の例に示すように、--application=PROJECT_ID パラメータを使用して dev_appserver を初期化します。

クラウド エミュレータ

Cloud Datastore、Cloud Bigtable、Cloud Pub/Sub のエミュレータでアプリケーションをテストできます。

requirements.txt と app.yaml の変更内容を自動的に再読み込みする

ローカル開発用サーバーは、requirements.txt ファイルにある依存関係を自動的にインストールします。dev_appserver では、app.yaml で構成された機能をテストすることもできます。たとえば、アプリの静的ファイルの処理機能をテストできます。dev_appserver が実行されている場合、requirements.txt と app.yaml を変更すると、アプリが自動的に再起動して変更が反映されます。依存関係がダウンロードされてインストールされる間、一時的な遅延が発生する可能性があります。

開発用サーバーでのインスタンス管理とルーティング

インスタンスのアドレスを検出する

開発用サーバーは起動時に、すべての手動スケーリングのインスタンスを作成します。自動スケーリングおよび基本スケーリング サービスのインスタンスは動的に管理されます。サーバーは各サービスにポートを割り当て、クライアントはサーバーを使用して、ロード バランシングを行い、インスタンスを自動的に選択します。各サービスに対応するポートの割り当ては、サーバーのログメッセージ ストリームに表示されます。

次は、3 つのサービスを定義するアプリのポートです。

INFO Starting module "default" running at: http://localhost:8084
INFO Starting module "service1" running at: http://localhost:8082
INFO Starting module "service2" running at: http://localhost:8083

サービスのアドレス（たとえば http://localhost:8082/）を使用すると、サーバーはサービスのインスタンスを作成または選択し、そのインスタンスにリクエストを送信します。

サーバーは、サービスの各インスタンスに一意のポートを割り当てます。管理サーバーを使用して、これらのポートを検出できます。管理サーバーには一意のポートがあり、メッセージログで確認できます。

INFO Starting admin server at: http://localhost:8000

このアドレスにより、管理サーバーのコンソールに移動できます。[Instances] をクリックすると、アプリのインスタンスの動的な状態が表示されます。

手動インスタンスと基本インスタンスのそれぞれに、別々のエントリが表示されます。インスタンス番号は、各インスタンスの一意のポートアドレスとリンクしています。リンクをクリックすると、インスタンスに直接リクエストが送信されます。

ディスパッチ ファイル

アプリに dispatch.yaml ファイルが含まれている場合、ログメッセージ ストリームにはディスパッチ ポートが含まれます。

INFO Starting dispatcher running at: http://localhost:8080

このポートへのリクエストは、ディスパッチ ファイルのルールに従ってルーティングされます。サーバーは、ホスト名を含む dispatch.yaml ファイルルール（url: "customer1.myapp.com/*" など）をサポートしません。相対パスのパターンを利用したルール（url: "*/fun"）は機能するので、http://localhost/fun/mobile などの URL を使用してインスタンスを指定できます。ホストベースのルールが含まれている dispatch.yaml ファイルを使用してアプリケーションを起動しようとすると、サーバーはログストリームでエラーを報告します。

Cloud Trace を使用する

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

Cloud Trace でトレースの詳細を表示するには、トレースを検索して調査するの説明に従います。トレース エクスプローラでフィルタを使用して、特定の App Engine サービスやバージョンでトレースをフィルタできます。