バックエンドからサービスへの変換

Backend API は 2014 年 3 月 13 日をもって非推奨となっており、2019 年 3 月 13 日に終了します。デベロッパーはすべてのバックエンド インスタンスをサービスに移行する必要があります。移行しないと、インスタンスを管理できなくなり、トラフィックの配信が停止されます。

App Engine の基本的な構造は、1 つのフロントエンド インスタンスにオプションのバックエンド インスタンスが付属する形をベースにしています。バックエンドを使用するアプリケーションでは、バックエンドをサービス形式に変換することにより、そのサービスが提供する付加的な機能(バックエンドのバージョン管理など)を十分に活用できます。

App Engine は既存のバックエンドを、デフォルトではない新しいバージョンのデフォルト サービスとして自動的に実行します。常駐バックエンドには手動スケーリングが、ダイナミック バックエンドには基本スケーリングが割り当てられます。

バックエンド インスタンスは、バージョン付けされ、明示的なスケーリング タイプとインスタンス クラスを持つ名前付きのサービスに変換できます。元の backends.yaml ファイルを複数の .yaml ファイルに置き換える必要があります(下記参照)。

たとえば、次の .yaml ファイルのフラグメントでは、3 つのバックエンド(memdbworkercmdline)を定義しています。

backends:
- name: memdb
  class: B8
  instances: 5
- name: worker
  start: worker.app
  options: failfast
- name: cmdline
  options: dynamic

これらのバックエンドをサービスに変換するには、それぞれ個別の .yaml ファイルを作成します。

memdb.yaml の場合:

service: memdb
version: uno
instance_class: B8
manual_scaling:
  instances: 5

worker.yaml の場合:

service: worker
version: uno
# For failfast functionality, please use the ‘X-AppEngine-FailFast’ header on requests made to this service.
manual_scaling:
  instances: 1
handlers:
# If a service has an _ah/start handler, it should be listed first.
- url: /_ah/start
  script: worker.app

ワーカー バックエンドの元の定義では、スクリプト worker.app_ah/start パスにバインドするのに start: タグを使用していたことに注意してください。サービスの場合、このバインディングは明示的な _ah/start パスによってハンドラとして定義されます。さらに、複数のハンドラがある場合、_ah/start ハンドラはリストの先頭にある必要があります。

cmdline.yaml の場合:

service: cmdline
version: uno
basic_scaling:
  max_instances: 1

Python SDK には、次の変換を実行できるスクリプトが含まれています。アプリとそのバックエンド用にそれぞれ 1 つずつ、つまり 2 つの .yaml ファイルがあり、各バックエンドのサービスを定義する新しい .yaml ファイルが作成されます。上記の移行例を使用する場合、3 つのバックエンドを定義する元のファイルの名前を backends.yaml、メインアプリを定義するファイルの名前を app.yaml にするとします。スクリプトにより、新たに 3 つの .yaml ファイル(memdb.yamlworker.yamlcmdline.yaml)が生成されます。次にスクリプトの呼び出し方法を示します。

[PATH_TO_SDK]/google-cloud-sdk/platform/google_appengine/backends_conversion.py backends.yaml app.yaml
このページは役立ちましたか?評価をお願いいたします。

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

Python 2 の App Engine スタンダード環境