gcloud CLI ベースの Gradle プラグインへの移行

以前に Java App Engine SDK ベースのプラグイン(com.google.appengine.appengine-gradle)を使用したことがあり、新しい Google Cloud CLI に移行する場合は、gcloud CLI ベース(com.google.cloud.tools.appengine-gradle)のプラグインに移行します。

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 エンハンスメントの手動構成が必要
プロジェクトで gradle-appengine-plugin の JPA / JDO Datanucleus エンハンスメントを使用している場合は、gcloud CLI ベースのプラグインに切り替えた後に Datanucleus エンハンスメントを手動で構成する必要があります。Stack Overflow の例をご覧ください。
Android Studio が未サポート
Android Studio プロジェクトで新しいプラグインを使用するように切り替えることは可能ですが、Android Studio App Engine 開発用サーバーおよびデプロイは新しいプラグインではサポートされていません。アプリを実行してデプロイするには、Gradle を直接呼び出す必要があります。

XML 構成ファイルの使用はサポートされていますが、YAML 形式はサポートされていません。

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

  1. 古い gradle-appengine-plugin 構成とインポートを build.gradle ファイルから削除します。

  2. build.gradle ファイルの buildscript セクションの classpath に新しいプラグインを追加します。

    buildscript {
        repositories {
            mavenCentral()
        }
    
        dependencies {
            classpath 'com.google.cloud.tools:appengine-gradle-plugin:2.0.1'
        }
    }
    
  3. サービスのルートで、次のコマンドを実行して、アプリをローカルに実行できるかどうかを確認します。

    gradle appengineRun
    
  4. build.gradle ファイルの buildscript セクションで、プロジェクト ID とバージョンを指定してデプロイを構成します。

    appengine {
        deploy {
            version = 'v1'
            project = "your GCP project ID"
        }
    }
    

    新しいツールでは、appengine-web.xml ファイル内のアプリケーション要素とバージョン要素は無視されます。

  5. サービスのルートで、次のコマンドを実行して、アプリケーションをデプロイできるかどうかを確認します。

    gradle appengineDeploy
    

EAR ベースの複数サービス構成を移行する

新しいプラグインは EAR パッケージに対応していません。代わりに、特別なパッケージング手順を踏まなくても、複数のサービスをローカルで実行できるようになっています。

EAR ベースの Gradle プロジェクトを移行するには:

  1. プライマリ サービスを選択して、そのサービスによって残りのサービスが実行されるようにします。デフォルト サービスを選択する必要がありますが、一緒に実行されるサービスであればどのサービスを選択してもかまいません。

  2. appengine 構成で、run.services エントリを変更して、ローカル開発用サーバーで実行する必要があるすべてのサービスを追加します。

    プロジェクト構造の例:

    ../{projectRoot}/
      build.gradle
      settings.gradle (includes default-service & secondary-service)
           {your-default-service}/build.gradle {includes appengine-gradle-plugin}
              ….
           {your-default-service}/src/main/webapp/WEB-INF/appengine-web.xml
           {your-secondary-service}build.gradle {includes appengine-gradle-plugin}
              ….
           {your-secondary-service}/src/main/webapp/WEB-INF/appengine-web.xml
    

    build.gradle buildscript の例:

    appengine {
        run {
            // configure the app to point to the right service directories
            services = [
                    projectAsService(project),
                    projectAsService(":another-module")
            ]
        }
    }
    
    // helper method to obtain correct directory and set up dependencies
    def getExplodedAppDir(Project serverProject) {
        // if not 'this' module, then do some setup.
        if (serverProject != project) {
            // make sure we evaluate other modules first so we get the right value
            evaluationDependsOn(serverProject.path)
            // make sure we build "run" depends on the other modules exploding wars
            project.tasks.appengineRun.dependsOn serverProject.tasks.explodeWar
        }
        return serverProject.tasks.explodeWar.explodedAppDirectory
    }
    

App Engine SDK ベースと gcloud CLI ベースの Gradle コマンドの相違

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

アクション App Engine SDK ベース gcloud CLI ベース
アプリのローカル実行 appengine:devserver appengineRun
新しいアプリ、バージョン、またはサービスのデプロイ appengine:update appengineDeploy
デフォルトのアプリケーション バージョンの設定 appengine:set_default_version gcloud app services set-traffic または gcloud app versions migrate
アプリケーションの cron ジョブの更新 appengine:update_cron appengineDeployCron
アプリケーションのディスパッチ構成の更新 appengine:update_dispatch appengineDeployDispatch
アプリケーションの DoS 保護構成の更新 appengine:update_dos appengineDeployDos
アプリケーションのタスクキュー定義の更新 appengine:update_queues appengineDeployQueue
データストア インデックスの更新 appengine:update_indexes appengineDeployIndex
使用されていないインデックスのアプリケーションからの削除 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 startgcloud app versions stop

次のステップ

  • 新しいプラグインへの移行が正常に終了したので、次にアプリケーションをテストしてデプロイします。