com.google.appengine.appengine-maven
)を使用したことがあり、新しい Google Cloud CLI に移行する場合は、gcloud CLI ベース(com.google.cloud.tools.appengine-maven
)のプラグインに移行します。
gcloud CLI ベースのプラグインのメリット
新しいプラグインにアップグレードすると、次のような利点があります。
他のすべての gcloud CLI ベースのコマンドと同じ、標準の
gcloud auth login
フローから生成される認証情報が使用されます。App Engine フレキシブル環境がサポートされます。
標準の gcloud CLI 更新フローの一環として、ローカル開発用サーバーが自動的に更新されます。
App Engine サービス(cron、queue、dos、dispatch)構成を、ご使用のサービスとは独立してデプロイできます。
大きな相違点
移行を行う前に、次の大きな相違点に注意してください。
- gcloud CLI の依存関係
- 古いプラグインは、Java を除き、特定のローカル環境に依存せずに実行されますが、新しいプラグインでは gcloud CLI をインストールする必要があります。
- Endpoints のディスカバリ ドキュメントが生成されない
- 新しいプラグインでは、Endpoints のディスカバリ ドキュメントが生成されません。この機能は別のプラグインで提供されます。Endpoints をバックエンドで実行する際、ビルドステップでこのファイルを生成する必要はなくなりました。このファイルは、ランタイムにサーバーによって生成されます。新しいプラグインは、iOS や Android などのクライアント ライブラリを生成する必要がある場合にのみ使用する必要があります。新しいプラグインの詳細については、App Engine 用 Endpoints Frameworks への移行をご覧ください。
- EAR ファイル形式のサポート終了
- 新しいプラグインでは、複数のサービスを同時に実行およびデプロイするための EAR ファイル形式がサポートされなくなりました。
- 新しいデプロイ コマンド
- 古いプラグインでは、アプリケーションをデプロイするために
appcfg
コマンドを呼び出しますが、新しいプラグインでは、新しい gcloud CLI を使用してデプロイします。
- JPA / JDO Datanucleus エンハンスメント タスクの廃止
- 新しいプラグインは、どのようなタイプの Datanucleus エンハンスメントもサポートしません。プロジェクトで古いプラグインによる Datanucleus JDO または JPA エンハンスメント サポートを使用している場合は、移行する際に、サードパーティの Datanucleus(JDO の手順、JPA の手順)と Maven プラグインを個別に構成する必要があります。
YAML 構成ファイルの使用はサポートされていますが、XML 形式はサポートされていません。
新しいプラグインに移行する
新しいプラグインに移行するには、次の手順を行います。
gcloud CLI ベースのプラグインを
pom.xml
ファイルに追加します。<build> <plugins> [...] <plugin> <groupId>com.google.cloud.tools</groupId> <artifactId>appengine-maven-plugin</artifactId> <version>2.7.0</version> <configuration> <projectId>your-project-ID-goes-here</projectId> <version>1</version> </configuration> </plugin> [...] </plugins> </build>
プラグイン構成で、ターゲットとする Google Cloud プロジェクト ID を指定し、サービスとバージョンを指定します。新しいツールでは、
appengine-web.xml
ファイル内のアプリケーション要素とバージョン要素は無視されます。次のようにアプリケーションを実行およびデプロイし、新しい構成をテストします。
プラグインの完全修飾名を使用して、アプリを実行します。
mvn com.google.cloud.tools:appengine-maven-plugin:run
プラグインの完全修飾名を使用して、アプリをデプロイします。
mvn com.google.cloud.tools:appengine-maven-plugin:deploy
pom.xml
にまだ古い appengine プラグインが残っている場合は、必ずプラグインのゴール呼び出しに名前空間を設定してください。
よりカスタマイズされた構成を使用している場合は、新しいプラグインで同等のステージング、ローカル実行、デプロイフラグを確認してください。
すべてが予期したとおりに動作していることを確認したら、pom.xml
から com.google.appengine appengine-maven-plugin
を削除し、appengine-web.xml
ファイルからアプリケーション要素とバージョン要素を削除します。
これで、短縮表記を使用して、新しいプラグインのゴールを呼び出すことができるようになりました。
mvn package appengine:deploy
EAR ベースの複数サービス構成を移行する
新しいプラグインでは、EAR パッケージにご使用のサービスを集約しません。代わりに、ローカルでサービスをテストする場合は、各サービスを個別に実行することも、複数のコマンドを 1 つのコマンドで実行することもできます。サービスをデプロイする準備ができたら、個別にデプロイするか、プロジェクトの整理方法に応じて、すべてのサービスを 1 つのコマンドでデプロイできます。
複数のサービスをローカルで実行するには、実行するサービスのリストで appengine-maven-plugin
を更新します。サービスが親 POM を共有している場合、このリストを親 POM の appengine-maven-plugin
に追加できます。それ以外の場合は、デフォルトのサービスの POM の appengine-maven-plugin
にリストを追加します。
appengine-maven-plugin
にサービスのリストを追加するには:
EAR パッケージの
application.xml
内にあるcontext-root
ごとに、service
要素をappengine-maven-plugin
に追加します。各
service
要素で、サービスの爆発的な WAR を含むtarget
サブディレクトリを指定します。例:
<plugin> <groupId>com.google.cloud.tools</groupId> <artifactId>appengine-maven-plugin</artifactId> <version>2.7.0</version> <configuration> <deploy.projectId>your-project-name</deploy.projectId> <deploy.version>your-project-version</deploy.version> <services> <!-- for each service in your EARs application.xml --> <service> ${project.parent.basedir}/service-name/target/service-name-${project.version} </service> <service> ${project.parent.basedir}/another-service/target/another-service-${project.version} </service> </services> </configuration> </plugin>
ディレクトリ構造は、次のようになります。
~/my-ear/default-service/ ~/my-ear/another-service/
次に、
service
要素のパス名は、次のようにレンダリングする必要があります。<service>~/my-ear/default-service/target/default-service-1.0-SNAPSHOT</service> <service>~/my-ear/another-service/target/another-service-1.0-SNAPSHOT</service>
デフォルト サービス ディレクトリから次のコマンドを実行して、新しい構成が動作することを確認します。
mvn package appengine:run
デフォルト サービスによりすべてのサービスがローカルで実行されていることを確認したら、EAR パッケージを完全に削除します。
プロジェクトのルート ディレクトリにサービスのみが含まれている場合は、すべてのサービスを 1 つの mvn appengine:deploy
コマンドでデプロイできます。まず、親 pom.xml
ファイルに appengine-maven-plugin を追加する必要があります。mvn appengine:deploy
を実行すると、このコマンドはプロジェクトの各サービスを繰り返し処理して、サービスの構成ファイルを見つけ、各サービスをデプロイします。
App Engine SDK ベースと gcloud CLI ベースの Maven コマンドの相違
App Engine SDK ベースの Maven プラグインと gcloud CLI ベースの Maven プラグインのどちらを使用するかに応じて Maven プラグインの呼び出し方法が異なります。次の表に、その違いを示します。
アクション | App Engine SDK ベース | gcloud CLI ベース |
---|---|---|
アプリのローカル実行 | appengine:devserver |
appengine:run |
新しいアプリ、バージョン、またはサービスのデプロイ | appengine:update |
appengine:deploy または appengine:deployAll |
デフォルトのアプリケーション バージョンの設定 | appengine:set_default_version |
gcloud app services set-traffic または gcloud app versions migrate |
アプリケーションの cron ジョブの更新 | appengine:update_cron |
appengine:deployCron |
アプリケーションのディスパッチ構成の更新 | appengine:update_dispatch |
appengine:deployDispatch |
アプリケーションの DoS 保護構成の更新 | appengine:update_dos |
appengine:deployDos |
アプリケーションのタスクキュー定義の更新 | appengine:update_queues |
appengine:deployQueue |
データストア インデックスの更新 | appengine:update_indexes |
appengine:deployIndex |
使用されていないインデックスのアプリケーションからの削除 | appengine:vacuum_indexes |
gcloud datastore indexes cleanup |
指定バージョンの開始 | appengine:start_module_version |
gcloud app versions start |
指定バージョンの停止 | appengine:stop_module_version |
gcloud app versions stop |
進行中の更新のロールバック | appengine:rollback トラフィックを古いバージョンに戻すこともできます |
gcloud app versions start、gcloud app versions stop。トラフィックを古いバージョンに戻すには、gcloud app services set-traffic を使用します。 |