Cloud SDK ベースの Maven プラグインへの移行

Java App Engine SDK ベースのプラグイン(com.google.appengine.appengine-maven)を使用していて、新しい Cloud SDK に移動する場合は、Cloud SDK ベースの(com.google.cloud.tools.appengine-maven)プラグインに移行します。

Cloud SDK ベースのプラグインの利点

新しいプラグインにアップグレードすると、次のような利点があります。

  • 標準の gcloud auth login フローから生成される、その他すべての Cloud SDK ベースのコマンドと同じ認証情報が使用されます。

  • App Engine フレキシブル環境がサポートされます。

  • 標準の Cloud SDK 更新フローの一環として、ローカル開発用サーバーが自動的に更新されます。

  • App Engine サービス(cron、queue、dos、dispatch)構成を、ご使用のサービスとは独立してデプロイできます。

大きな相違点

移行を行う前に、次の大きな相違点に注意してください。

Cloud SDK への依存性
古いプラグインは、Java を除き、特定のローカル環境に依存せずに実行されますが、新しいプラグインでは Cloud SDK をインストールする必要があります。
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 形式はサポートされていません。

新しいプラグインに移行する

新しいプラグインに移行するには、次の手順を行います。

  1. Cloud SDK ベースのプラグインを pom.xml ファイルに追加します。

    <build>
        <plugins>
           [...]
              <plugin>
                <groupId>com.google.cloud.tools</groupId>
                <artifactId>appengine-maven-plugin</artifactId>
                <version>2.2.0</version>
                <configuration>
                    <projectId>your-project-ID-goes-here</projectId>
                    <version>1</version>
                </configuration>
            </plugin>
           [...]
        </plugins>
    </build>
    
  2. プラグイン構成で、ターゲットとする Google Cloud プロジェクト ID およびサービスとバージョンを指定します。新しいツールでは、appengine-web.xml ファイル内のアプリケーション要素とバージョン要素は無視されます。

  3. 次のようにアプリケーションを実行およびデプロイし、新しい構成をテストします。

    1. プラグインの完全修飾名を使用して、アプリを実行します。

        mvn com.google.cloud.tools:appengine-maven-plugin:run
      
    2. プラグインの完全修飾名を使用して、アプリをデプロイします。

        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 にサービスのリストを追加するには:

  1. 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.2.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>
    
  2. デフォルト サービス ディレクトリから次のコマンドを実行して、新しい構成が動作することを確認します。

    mvn package appengine:run
    
  3. デフォルト サービスによりすべてのサービスがローカルで実行されていることを確認したら、EAR パッケージを完全に削除します。

プロジェクトのルート ディレクトリにサービスのみが含まれている場合は、すべてのサービスを 1 つの mvn appengine:deploy コマンドでデプロイできます。まず、親 pom.xml ファイルに appengine-maven-plugin を追加する必要があります。mvn appengine:deploy を実行すると、このコマンドはプロジェクトの各サービスを繰り返し処理して、サービスの構成ファイルを見つけ、各サービスをデプロイします。

App Engine SDK ベースと Cloud SDK ベースでの Maven コマンドの相違

App Engine SDK ベースの Maven プラグインと Cloud SDK ベースの Maven プラグインのどちらを使用するかに応じて、Maven プラグインを呼び出す方法の違いを次の表に示しています。

操作 App Engine SDK ベース Cloud SDK ベース
アプリのローカル実行 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 cleanup-indexes
指定バージョンの開始 appengine:start_module_version gcloud app versions start
指定バージョンの停止 appengine:stop_module_version gcloud app versions stop
進行中の更新のロールバック appengine:rollback
トラフィックを古いバージョンに戻すこともできます
gcloud app versions startgcloud app versions stop。トラフィックを古いバージョンに戻すには、gcloud app services set-traffic を使用します。