アプリをデプロイして、App Engine にアプリをアップロードし実行します。アプリをデプロイすると、そのアプリのバージョンと、それに対応するサービスが App Engine 内に作成されます。アプリ全体(すべてのソースコードと構成ファイルも含む)をデプロイすることも、個々のバージョンまたは構成ファイルをデプロイして更新することもできます。
アプリをプログラムでデプロイするには、Admin API を使用します。
始める前に
アプリをデプロイする前に:
GCP プロジェクトのオーナーが App Engine アプリケーションを作成する必要があります。
ユーザー アカウントに必要な権限が割り当てられていること。
Maven ビルドツールを設定する(推奨)
Maven ビルドツールを使用してアプリをデプロイするには、Maven plugin for App Engine を使用するようにプロジェクトを設定する必要があります。
gcloud
コマンドライン ツールのインストール
gcloud
ツールを使用してアプリをデプロイする場合は、Cloud SDK をダウンロードしてインストールし、初期化する必要があります。
インストール済みの gcloud
ツールを、初期化時とは異なる GCP プロジェクト ID を使用するように構成する場合は、Cloud SDK 構成の管理をご覧ください。
プロキシの使用
HTTP プロキシまたは HTTPS プロキシを使用するシステムからデプロイ コマンドを実行する場合は、プロキシ経由で通信を行うようにツールを構成する必要があります。
gcloud
次のコマンドを実行して gcloud
ツールを構成します。
gcloud config set proxy/type [PROXY_TYPE]
gcloud config set proxy/address [PROXY_ADDRESS]
gcloud config set proxy/port [PROXY_PORT]
プロキシに username
と password
を設定することもできます。詳細については、gcloud config をご覧ください。
appcfg
プロキシの環境変数を設定します。
- Mac / Linux
-
export HTTP_PROXY="http://cache.example.com:3128" export HTTPS_PROXY="http://cache.example.com:3128"
- Windows
-
set HTTP_PROXY=http://cache.example.com:3128 set HTTPS_PROXY=http://cache.example.com:3128
アプリをデプロイする
アプリを App Engine にデプロイするには、アプリケーションのルート ディレクトリで、Maven ビルドツール(推奨)、appcfg
ツール、または gcloud app
deploy
コマンドを使用します。
Maven を使用する(推奨)
Maven ビルドツールでアプリをデプロイするには、pom.xml
ファイルがあるプロジェクトの最上位ディレクトリから次のコマンドを実行します。
Cloud SDK ベースの Maven プラグインを使用している場合は、次のコマンドを使用します。
mvn appengine:deploy
App Engine SDK ベースの Maven プラグイン(非推奨)を使用している場合は、次のコマンドを使用します。
mvn appengine:update
appcfg を使用する
アプリをデプロイするには、appcfg
コマンドを update
アクションおよび WAR ファイルのディレクトリ パスを指定して実行します。次に例を示します。
Windows
appengine-java-sdk\bin\appcfg.cmd [options] update [WAR_LOCATION]
Mac / Linux
./appengine-java-sdk/bin/appcfg.sh [options] update [WAR_LOCATION]
HTTP プロキシを使用する場合は、appcfg
の --proxy
引数でそのアドレスを指定します。別のプロキシを HTTPS に使用する場合は、--proxy_https
引数も指定します。詳細については、appcfg
のコマンドライン引数をご覧ください。
Windows
appengine-java-sdk\bin\appcfg.cmd --proxy=10.1.2.3 update [WAR_LOCATION]
Mac / Linux
./appengine-java-sdk/bin/appcfg.sh --proxy=10.1.2.3 update [WAR_LOCATION]
デフォルトでは、そのサービスに対して最初にデプロイされたバージョンが自動的に、トラフィックの 100% を受け取るように構成されます。ただし、同じサービスに対してデプロイされるそれ以降のバージョンはすべて、手動で構成されない限り、トラフィックを受け取ることはありません。
このツールは、appengine-web.xml
ファイル内のアプリケーション ID を自動的に使用します。ただし、サンプル アプリケーションの多くでは appengine-web.xml
ファイルの中の <application>
や <version>
が省略されています。そのため、アプリケーション ID に GCP プロジェクト ID を指定し、適切なバージョン ID も指定する必要があります。次に例を示します。
Windows
appengine-java-sdk\bin\appcfg.cmd -A [YOUR_PROJECT_ID] -V [YOUR_VERSION_ID] update [WAR_LOCATION]
Mac / Linux
./appengine-java-sdk/bin/appcfg.sh -A [YOUR_PROJECT_ID] -V [YOUR_VERSION_ID] update [WAR_LOCATION]
バージョンをデプロイするときに、指定したバージョン ID と同じものがすでに App Engine に存在する場合は、デプロイしたファイルで既存のバージョンが上書きされます。アプリケーションを上書きすると、トラフィックが中断される可能性があります。アプリケーションに一意のバージョン ID を使用してデプロイし、新しいバージョンにトラフィックを移行することをおすすめします。
gcloud コマンドラインを使用する
gcloud app deploy [YOUR_DEPLOYMENTS]
ここで、[YOUR_DEPLOYMENTS]
は 1 つ以上の構成ファイルのパスと名前を 1 つの空白文字で区切って指定します。
オプション フラグ:
- カスタム バージョン ID を指定するには、
--version
フラグを指定します。指定しなければ、ID が自動的に生成されます。 - アプリをデプロイするときに、このバージョンにすべてのトラフィックを自動的にルーティングしない場合には、
--no-promote
フラグを指定します。 gcloud
ツールでデフォルトとして初期設定したものに代わる GCP プロジェクト ID を指定するには、--project
フラグを指定します。
デフォルトでは、デプロイする各バージョンが 100% のトラフィックを受信するように自動的に構成されます。構成オプションについては、gcloud app deploy
リファレンスの --promote
フラグをご覧ください。
ヒント: コマンドラインから gcloud help
を実行すると、引数とフラグの完全なリストを確認できます。
一意のバージョン ID を選択する
手動でスケーリングされるインスタンスの場合は、数値のインスタンス番号と区別するために、バージョン ID の先頭を文字にする必要があります。これによりリクエストが正しい宛先に確実にルーティングされ、URL パターンのあいまいさを回避できます。たとえば、123.my-service.appspot.com
は次の 2 通りの解釈が可能です。
- バージョン
123
が存在する場合は、my-service
サービスのバージョン123
にリクエストをルーティングする。 - バージョン
123
が存在しない場合は、その代わりに、my-service
サービスの各バージョンが実行されているインスタンス ID123
にリクエストをルーティングする。
ただし、自動スケーリングまたは基本スケーリング用に構成されているインスタンスについては、バージョンに名前を付けることができます。これは、そのようなインスタンスをターゲットにすることはできないためです。
複数サービス アプリケーションをデプロイする
アプリケーションが複数のサービスで構成されている場合は、対象のサービスを個別にデプロイして更新することも、すべてのサービスを同時にデプロイすることもできます。更新内容をサービスにデプロイする際は、個々の構成ファイルを更新したり、対応するバージョンのソースコードを更新したりすることもできます。
たとえば、App Engine に 2 つのバージョンをデプロイして作成し、それぞれ専用のサービスで実行されるようにします。最初のバージョンをアプリのフロントエンド サービス、他方をバックエンド サービスとして機能させるとしましょう。この場合、個々の構成ファイルをデプロイすると一方のサービスの設定のみ更新することができます。また、フロントエンドとバックエンドの一方または両方のソースコードを更新するために、特定のサービスの新しいバージョンをデプロイすることもできます。
複数サービスの要件
アプリケーションのサービスが複数の場合も、デプロイと更新のためのコマンドは同じですが、次の要件があります。
最初にアプリのバージョンの 1 つを
default
サービスにデプロイする必要があります。これで、以降のサービスを作成してデプロイできるようになります。サービスの ID を、対応するバージョンの
appengine-web.xml
構成ファイルで指定する必要があります。サービス ID を指定するには、module: [YOUR_SERVICE_ID]
要素定義を各構成ファイルに入れます。デフォルトでは、この要素の定義が構成ファイル内にない場合、バージョンのデプロイ先はdefault
サービスとなります。複数のサービスを同時にデプロイするには、対応するすべての
appengine-web.xml
構成ファイルをデプロイ コマンドの中で指定する必要があります。default
サービスを最初に指定する必要があります。
複数のサービスのデプロイ方法
アプリケーションのルート ディレクトリ(構成ファイルがある場所)で、デプロイ コマンドを実行し、各サービスの appengine-web.xml
ファイルの相対パスとファイル名を指定します。
Maven ビルドツールを使用する
プロジェクトのルート ディレクトリにサービスのみが含まれている場合は、すべてのサービスを 1 つの Maven コマンドでデプロイできます。
Maven のデプロイ コマンドは、プロジェクトの各サービスを繰り返し処理して、サービスの構成ファイルを見つけ、各サービスをデプロイします。
Maven プラグインを使用して複数のサービスをデプロイするには:
- 親の
pom.xml
ファイルに appengine-maven-plugin が追加されていることを確認します。 次のコマンドを実行します。
mvn appengine:deploy
gcloud の使用
gcloud app deploy [DEPLOYMENTS]
[DEPLOYMENTS]
は 1 つ以上の構成ファイルのパスと名前です。各構成ファイルをスペース 1 個で区切って指定します。
appcfg を使用する
Windows
appengine-java-sdk\bin\appcfg.cmd update [DEPLOYMENTS]
Mac / Linux
./appengine-java-sdk/bin/appcfg.sh update [DEPLOYMENTS]
ここで、[DEPLOYMENTS]
は 1 つ以上の構成ファイルのパスと名前を 1 つの空白文字で区切って指定します。次に例を示します。
Windows
appengine-java-sdk\bin\appcfg.cmd update [WAR_LOCATION] [SERVICE1_WAR_LOCATION] [MOD2_WAR_LOCATION]
Mac / Linux
./appengine-java-sdk/bin/appcfg.sh update [WAR_LOCATION] [SERVICE1_WAR_LOCATION] [MOD2_WAR_LOCATION]
各サービスが正常にデプロイされると、その確認がコマンドラインに表示されます。
インデックスの更新
アプリで使用するインデックスを作成または更新するには、datastore-indexes.xml
構成ファイルを Cloud Datastore にアップロードします。この構成ファイルがアップロードされた後に、まだ存在していないインデックスが作成されます。
App Engine によるすべてのインデックスの作成が完了するまでに、しばらく時間がかかることがあるため、このようなインデックスは App Engine ですぐに使用できるようにはなりません。アプリがすでにトラフィックを受け取るように構成されている場合は、まだ作成中のインデックスを必要とするクエリに対して例外が発生する可能性があります。
例外を避けるには、次のように、すべてのインデックスを作成するための時間を確保する必要があります。
index.xml
構成ファイルを Cloud Datastore にアップロードしてから、バージョンをデプロイします。index.xml
ファイルを Cloud Datastore にアップロードします。gcloud gcloud datastore indexes create index.yaml
詳細については、gcloud datastore
リファレンスをご覧ください。appcfg appcfg.sh update_indexes [YOUR_APP_DIR]
GCP Console を使用して、すべてのインデックスのステータスをモニタリングします。
すべてのインデックスが作成されたら、新しいバージョンを App Engine にデプロイします。
インデックスを作成してから、トラフィックをバージョンに移行または分割します。
-
新しいバージョン ID をアプリの
appengine-web.xml
ファイルの中で定義します。 - 新しいバージョンをデプロイします。
- GCP Console を使用して、すべてのインデックスのステータスを監視します。
- すべてのインデックスが作成されたら、GCP Console を使用して、トラフィックをバージョンに移行または分割します。
-
新しいバージョン ID をアプリの
インデックスの詳細については、データストア インデックスの構成をご覧ください。
トラブルシューティング
発生する可能性のあるエラー メッセージのうち主なものを次に示します。
PERMISSION_DENIED: Operation not allowed
The "appengine.applications.create" permission is required.
- 必要な App Engine アプリケーションが GCP プロジェクトに含まれていない場合、
gcloud app deploy
コマンドがgcloud app create
コマンドを実行しようとして失敗する可能性があります。App Engine アプリケーションの作成に必要な権限は、オーナーの役割を持つアカウントのみに付与されています。 Command not found
App Engine SDK(非推奨)をインストールする際に
appcfg.sh
ツールやdev_appserver.sh
ツールのシンボリック リンクを作成しなかった場合、これらのツールを実行する際に完全なディレクトリ パスを指定する必要があります(例:[PATH_TO_APP_ENGINE_SDK]/appcfg.sh
、[PATH_TO_APP_ENGINE_SDK]/dev_appserver.sh
)。Import Error
Cloud SDK と元の App Engine SDK の両方をインストールした場合、PATH のエントリが競合してインポート エラーが発生する可能性があります。Cloud SDK コマンドの実行中にエラーが発生した場合は、元の App Engine SDK を明示的に使用してみてください。PATH で、元の App Engine SDK のエントリを Cloud SDK の前に移動すると、それらのコマンドを優先させることができます。または、完全修飾のディレクトリ パス
[PATH_TO_APP_ENGINE_SDK]/java_dev_appserver.sh
を指定して、コマンドを実行することもできます。
ヒント: Linux または Mac では、which dev_appserver.py
を実行して PATH 内の最初の SDK を判断できます。[400] The first service (module) you upload to a new application must be the 'default' service (module)
アプリケーションの複数のサービスをデプロイして作成するには、その前に
default
サービスをデプロイして作成する必要があります。バージョンをdefault
サービスにデプロイする方法については、複数のサービス アプリケーションのデプロイをご覧ください。Too Many Versions (403)
App Engine では、アプリケーションのデプロイ済みバージョン数の上限が定められています。これは、無料アプリケーションとデプロイ済みアプリケーションとで異なります。GCP Console を使用して以前のバージョンを削除してから、最新のコードをアップロードできます。
You do not have permission to modify this app (403)
このエラーが発生するのは、認証を受けたアカウントに権限がないために、コマンドまたは
appengine-web.xml
で指定されているアプリケーション ID をデプロイできない場合です。アプリケーション ID が正しく、GCP Console プロジェクト ID の値に対応していることを確認してください。次に、コンソールでプロジェクト権限を調べて、アプリをデプロイするのに十分な権限レベルがアカウントに付与されていることを確認してください。アカウントの権限とプロジェクト ID が正しいと思われる場合は、SDK の強制再認証をしてみてください。それには、.appcfg_oauth2_tokens
ファイルをホーム ディレクトリから削除してからデプロイ コマンドをもう一度実行します。
次のステップ
- サービスを使用して大規模なアプリケーションを構築する。
- トラフィックの分割またはトラフィックの移行を使用して、デプロイするバージョンにトラフィックをルーティングする。
gcloud app deploy
コマンドラインの引数とフラグを確認する。