アプリケーションのテストとデプロイ

アプリケーションをローカルで実行し、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

始める前に

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

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

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

デプロイ中に、Cloud Build サービスが App Engine スタンダード環境で実行するアプリケーションのコンテナ イメージを作成します。詳細は、ビルドイメージの管理をご覧ください。

アプリをプログラムでデプロイするには、Admin API を使用します。

サービスのデプロイ

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

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

gcloud app deploy

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

コマンドのデフォルトの動作を変更するには、特定のファイルをターゲットとして指定するか、追加のパラメータを指定します。

  • サービスの他の構成ファイルをデプロイするには、各ファイルを個別にターゲットとして指定してデプロイする必要があります。次に例を示します。
    gcloud app deploy cron.yaml
    gcloud app deploy dispatch.yaml
    gcloud app deploy index.yaml
    
  • 独自のバージョン ID を指定するには、--version フラグを使用します。
  • トラフィックが新しいバージョンに自動的にルーティングされないようにするには、--no-promote フラグを使用します。
  • 特定の GCP プロジェクトにデプロイするには、--project フラグを使用します。

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

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

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

複数のサービスのデプロイ

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

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

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

複数のサービスをデプロイするための要件

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

ファイルの無視

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

ビルドイメージの管理

新しいバージョンをデプロイするたびに、Cloud Build サービスによってコンテナ イメージが作成されます。このコンテナ イメージは App Engine スタンダード環境で実行されます。

作成されたコンテナ イメージは、Container Registryapp-engine フォルダに保存されます。これらのイメージをダウンロードして、任意の場所に保存したり、別の場所で実行したりできます。デプロイが完了したコンテナ イメージは、App Engine ではもう必要でなくなります。なお、不要になったイメージは自動的に削除されないので、保存容量の上限に達する前に削除するとよいでしょう。Container Registry 内のイメージを管理する方法の詳細は、Container Registry のドキュメントをご覧ください。

アプリケーションの表示

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

gcloud app browse

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

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

  1. --no-promote フラグを指定して新しいバージョンをデプロイします。

    gcloud app deploy --no-promote

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

    http://VERSION_ID.default.YOUR_PROJECT_ID.appspot.com

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

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

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

    バージョンの管理

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

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

http://VERSION_ID.SERVICE_ID.YOUR_PROJECT_ID.appspot.com

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

ローカル開発用サーバーの使用

Google Cloud SDK には、本番環境の App Engine で動作しているアプリケーションをシミュレートするために、ローカルで実行できるローカル開発用サーバー(dev_appserver)が含まれています。この開発用サーバーは、アプリケーションが実行される環境を部分的にシミュレートします。

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

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

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

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

    dev_appserver.py --application=PROJECT_ID app.yaml

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

    dev_appserver.py --application=PROJECT_ID app.yaml --port=9999

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

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

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

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

  4. ローカル サーバーをコマンドラインから停止するには、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 クライアント ライブラリの多くは、GCP プロジェクト ID を表す GOOGLE_CLOUD_PROJECT 環境変数の存在に依存しています。プロジェクト ID の値を確認するには、gcloud config list project コマンドを実行するか、Google Cloud Platform Console でプロジェクト ページを参照します。

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

クラウド エミュレータ

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

requirements.txt の自動再読み込みと app.yaml の変更

ローカル開発用サーバーは、requirements.txt ファイルにある依存関係を自動的にインストールします。dev_appserver では、app.yaml で構成された機能をテストすることもできます。たとえば、アプリの静的ファイルの処理機能をテストできます。dev_appserver が実行されている場合、requirements.txtapp.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 ファイルを使用してアプリケーションを起動しようとすると、サーバーはログストリームでエラーを報告します。