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

リージョン ID

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

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

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

ローカルでの実行

デプロイ前にアプリケーションの機能をテストするには、普段使用している開発ツールを使用して、アプリケーションをローカル環境で実行します。

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

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

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

アプリをデプロイするには、次のいずれかの手法を使用できます。

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

アプリのソースコードをデプロイする

Maven または Gradle アプリを使用してローカルビルドを管理し、またアプリのすべての依存関係をダウンロードできる場合、アプリの pom.xml または build.gradle ファイルを含むディレクトリから gcloud app deploy コマンドを入力できます。

gcloud app deploy

このコマンドは、App Engine ビルドパックを使用してアプリをビルドし、App Engine にデプロイするように Cloud Build に指示するものです。

Maven を使用する場合:

  • Buildpack は mvn clean package --batch-mode -DskipTests というビルドコマンドを使用します。

  • アプリのルート ディレクトリに mvnw ファイルが含まれている場合、ビルドコマンドは mvn の代わりに ./mvnw を使用します。Cloud Build は、target ディレクトリでメインクラスのマニフェスト エントリを持つ .jar ファイルを検索し、値 java -jar <jarfile> を含む entrypoint を作成します。

Gradle を使用する場合:

  • Buildpack は gradle clean assemble -x test --build-cache というビルドコマンドを使用します。

  • アプリのルート ディレクトリに gradlew ファイルが含まれている場合、ビルドコマンドは gradle の代わりに ./gradlew を使用します。Cloud Build は、build/libs ディレクトリでメインクラスのマニフェスト エントリを持つ .jar ファイルを検索し、値 java -jar <jarfile> を含む entrypoint を作成します。

  • プロジェクトのルートに pom.xml がないことを確認します。Maven プロジェクトは Gradle プロジェクトより優先されます。

ビルドログの表示

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

デプロイ手法については、次の点にご注意ください。

  • アプリにローカルでのみ使用可能な依存関係がある場合、Cloud Build はアプリをビルドできず、デプロイに失敗します。この場合は、App Engine Maven プラグインまたは Gradle プラグインを使用することをおすすめします。

  • アプリのビルドでは Cloud Build の割り当てが使用されます。アプリのソースコードの保存には Cloud Storage の割り当てが使用されます。Cloud Build と Cloud Storage には無料の割り当てがあります。この割り当てを超過するまで App Engine アプリの費用はかかりません。詳細については、料金をご覧ください。

  • 現時点では、Gradle ビルドコマンドに追加の引数を指定することはできません。詳しくは、Google 公開バグトラッカーをご覧ください。

App Engine Maven または Gradle プラグインの使用

App Engine には、アプリのビルドとデプロイに使用できる Maven プラグインと Gradle プラグインが用意されています。たとえば、App Engine Maven プラグインを設定したら、プロジェクトの pom.xml ファイルを含むディレクトリから次のコマンドを入力します。

mvn package appengine:deploy -Dapp.deploy.projectId=PROJECT_ID

PROJECT_ID は実際の Cloud プロジェクトの ID に置き換えます。pom.xml ファイルですでにプロジェクト ID を指定している場合は、実行するコマンドに -Dapp.deploy.projectId プロパティを含める必要はありません。

詳細については、Apache Maven と App Engine プラグインの使用または Gradle と App Engine プラグインの使用をご覧ください。

実行可能な JAR をデプロイする

任意のビルド フレームワークを使用して実行可能な JAR をローカルにビルドし、アプリに app.yaml ファイルを作成したかどうかに応じて、次のいずれかを行います。

  • app.yaml ファイルを作成した場合:

    1. 作成した実行可能な JAR ファイルと同じディレクトリにファイルをコピーします。

    2. app.yaml と JAR を含むディレクトリから次のコマンドを入力します。

      gcloud app deploy

  • app.yaml ファイルを作成していない場合は、次のコマンドを入力します。

    gcloud app deploy your-executable.jar

    gcloud app deploy はすべてのデフォルト値を使用して、最小の設定を含む app.yaml ファイルを作成します。

ファイルの無視

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

ビルドイメージの管理

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

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

アプリケーションの表示

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

gcloud app browse

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

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

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

    mvn appengine:deploy -Dapp.deploy.projectId=PROJECT_ID -Dapp.deploy.promote=False

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

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

    これで、新しいバージョンを 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

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

ビルド環境変数の使用

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

ビルド環境変数は、buildpacks に構成情報を渡すことができるアプリと一緒にデプロイされる Key-Value ペアです。たとえば、コンパイラ オプションをカスタマイズできます。こうしたビルド環境変数は、app.yaml ファイルの build_env_variables フィールドを構成することで追加や削除できます。

Cloud デバッガの使用

デバッガを使用すると、実行中のアプリを停止せずに、任意のコードの場所でデプロイされたアプリの状態を検査できます。デバッガにより、アプリの処理が遅くなることもありません。

Java 11 アプリでデバッガを使用するには、app.yaml ファイルの entrypoint フィールドに次のフラグを含める必要があります。

-agentpath:/opt/cdbg/cdbg_java_agent.so=--log_dir=/var/log

app.yaml で entrypoint をすでに指定している場合は、entrypoint フィールドの java コマンドに agentpath フラグを追加します。

entrypoint フィールドを指定していない場合、またはアプリのデプロイ時に app.yaml ファイルを生成した場合、App Engine はアプリの起動に使用するコマンドにフラグを追加します。

Cloud Profiler の使用

Cloud Profiler は、本番環境のアプリケーションから CPU 使用率やメモリ割り当てなどの情報を継続的に収集する、オーバーヘッドの少ないプロファイラです。収集した情報からアプリのソースコードが特定されるので、最もリソースを消費しているコード部分を容易に識別できます。コードの特定が難しい場合でも、パフォーマンスの特長を把握できます。

Cloud Profiler を使用するには、プログラムを起動するの説明に従ってアプリの構成ファイルを設定し、アプリを再デプロイします。