リージョン ID
REGION_ID
は、アプリの作成時に選択したリージョンに基づいて Google が割り当てる省略形のコードです。一部のリージョン ID は、一般的に使用されている国や州のコードと類似しているように見える場合がありますが、このコードは国または州に対応するものではありません。2020 年 2 月以降に作成されたアプリの場合、REGION_ID.r
が App Engine の URL に含まれています。この日付より前に作成されたアプリの場合、URL のリージョン ID は省略可能です。
詳しくは、リージョン ID をご覧ください。
アプリケーションをローカルで実行し、App Engine にデプロイしてテストする方法を説明します。
ローカルでの実行
デプロイ前にアプリケーションの機能をテストするには、普段使用している開発ツールを使用して、アプリケーションをローカル環境で実行します。
アプリケーションをデプロイする前に
アプリケーションをデプロイする前に、次のことを確認してください。
- Cloud プロジェクトのオーナーが App Engine を有効にしていること。
- ユーザー アカウントに必要な権限が含まれていること。
アプリケーションのデプロイ
アプリをデプロイするには、次のいずれかの手法を使用できます。Google Cloud CLI を使用して、アプリのソースコードをデプロイし、Maven POM または Gradle ビルドファイルをデプロイします。Cloud Build がアプリをビルドし、App Engine にデプロイします。
Maven または Gradle 用 App Engine プラグインを使用します。このプラグインはアプリをローカルにビルドし、ビルドしたアプリを App Engine にデプロイします。
任意のビルド フレームワークを使用して Fat JAR(実行可能 JAR)をローカルにビルドしてから、Google Cloud CLI を使用して JAR を 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
ファイルを作成した場合:作成した実行可能な JAR ファイルと同じディレクトリにファイルをコピーします。
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
サービスの新しいバージョンをテストする手順は次のとおりです。
新しいバージョンをデプロイしますが、トラフィックが新しいバージョンに自動的にルーティングされないようにするには、次のコマンドを実行します。
mvn appengine:deploy -Dapp.deploy.projectId=PROJECT_ID -Dapp.deploy.promote=False
次の 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
に送信されたリクエストを、トラフィックを受信するように構成済みのバージョンにルーティングします。トラフィックが新しいバージョンに送信されるようにするには、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 を使用するには、プログラムを起動するの説明に従ってアプリの構成ファイルを設定し、アプリを再デプロイします。