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

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

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 エンハンスメントの手動構成が必要
プロジェクトで gradle-appengine-plugin の JPA / JDO Datanucleus エンハンスメントを使用している場合は、Cloud SDK ベースのプラグインへの切り替え後に、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 ベースと Cloud SDK ベースの Gradle コマンド

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

操作 App Engine SDK ベース Cloud SDK ベース
アプリのローカル実行 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 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

次のステップ

  • 新しいプラグインへの移行が正常に終了したので、次にアプリケーションをテストしてデプロイします。
このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...

Java 8 の App Engine スタンダード環境