App Engine バンドル サービスのサポートの拡張: パート 1（モジュール 17）

1. 概要

Serverless Migration Station の Codelab シリーズ（セルフペース型のハンズオン チュートリアル）と関連動画は、Google Cloud サーバーレス デベロッパーが主にレガシー サービスからの移行を 1 つ以上の移行を通じてガイドし、アプリをモダナイズできるようにすることを目的としています。これにより、アプリのポータビリティが高まり、選択肢と柔軟性が増し、より広範な Cloud プロダクトと統合してアクセスできるようになり、より新しい言語リリースに簡単にアップグレードできるようになります。当初は初期の Cloud ユーザー、主に App Engine（スタンダード環境）のデベロッパーを対象としていますが、Cloud Functions や Cloud Run など、その他のサーバーレス プラットフォーム（該当する場合）まで幅広くカバーしています。

これまで、デベロッパーは App Engine の以前の「バンドル サービス」から移行する必要がありました。データストアや Memcache などの言語バージョンをアップグレードするよりも前に、このような 2 つの課題に直面していました。主要なバンドル サービスの多くを第 2 世代の App Engine サービスで利用できるようにすることで、（大部分の）バンドル サービスを使用しながら、アプリを最新のランタイムに移行できるようになりました。この Codelab では、（App Engine NDB ライブラリを介して）Datastore バンドル サービスを使用しながら、サンプルアプリを Python 2 から Python 3 にアップグレードする手順について説明します。ほとんどのバンドル サービスは、このチュートリアルで説明するようにコードの軽微な更新で十分ですが、より広範な変更が必要なものもあります。次の「パート 2」で説明しますフォローアップモジュールと Codelab の 演習も行います

GCP コンソールの

  • サンプル App Engine アプリを Python 2 から 3 に移植する
  • アプリの構成を更新して App Engine SDK を追加する
  • Python 3 などの第 2 世代ランタイムでバンドル サービスをサポートするアプリに SDK コードを追加する

必要なもの

アンケート

このチュートリアルをどのように使用されますか？

通読のみ 通読して演習を行う

Python のご利用経験はどの程度ありますか？

初心者 中級者 上級者

Google Cloud サービスの使用経験はどの程度ありますか？

<ph type="x-smartling-placeholder"></ph> 初心者 中級 上達 をご覧ください。

2. 背景情報

元の App Engine サービスは 2008 年にリリースされ、一連のレガシー API（現在はバンドル サービス）が付属していたため、デベロッパーはグローバルにアプリケーションを構築してデプロイするのに便利です。これらのサービスには、Datastore、Memcache、タスクキューなどがあります。利便性は高いものの、独自の API を使用して App Engine と連携させる場合、ユーザーはアプリのポータビリティを懸念するようになり、アプリのポータビリティを高めたいと考えました。これに加え、バンドル サービスの多くが独自のスタンドアロン クラウド プロダクトに成熟したため、App Engine チームは 2018 年に次世代プラットフォームをリリースすることになりました。

Python 3 へのアップグレードに意欲的な Python 2 開発者とともに、今すぐ始めましょう。バンドル サービスを使用する 2.x アプリは、アプリを 3.x に移植する前にこれらのサービスから移行する必要があり、2 つの強制移行を連続して行うことになりますが、やはり困難な移行となる可能性があります。この移行を支援するため、App Engine チームは 2021 年秋に「ワームホール」機能を導入しました。次世代ランタイムで実行されるアプリがバンドル サービスの多くにアクセスできるようになります。このリリースには元のランタイムで使用可能なすべてのサービスが含まれているわけではありませんが、Datastore、タスクキュー、Memcache などの主要ベンダーは利用できます。

この Codelab では、バンドル サービスの使用を維持しながらアプリを Python 3 にアップグレードするために必要な変更について説明します。目標は、アプリを最新のランタイムで実行し、バンドル サービスから Cloud のスタンドアロン サービスまたはサードパーティの代替サービスに移行できるようにすることです。3.x へのアップグレードを阻害することはありません。バンドル サービスから移行しなくても、アプリをホストできる場所に関するポータビリティと柔軟性が得られます。たとえば、ワークロードにより適切に処理できるプラットフォームに移行したり、前述のように最新の言語リリースにアップグレードしながら App Engine を使い続けることができます。

モジュール 1 の Python 2 サンプルアプリは、App Engine NDB を介して Datastore バンドル サービスを利用しています。このアプリではフレームワークをすでに webapp2 から Flask に移行しています。これはモジュール 1 の Codelab で完了していますが、Datastore の使用方法は変わりません。

このチュートリアルでは、次の手順について説明します。

  1. セットアップ / 事前作業
  2. 構成の更新
  3. アプリケーション コードを変更する

3. 設定/事前作業

このセクションでは、次の方法を説明します。

  1. Cloud プロジェクトを設定する
  2. ベースラインのサンプルアプリを取得する
  3. （再）ベースライン アプリをデプロイして検証する

この手順により、コードを確実に稼働させることができます。

1. プロジェクトをセットアップする

モジュール 1 の Codelab を完了したら、同じプロジェクト（およびコード）を再利用することをおすすめします。または、新しい Cloud プロジェクトを作成するか、別の既存のプロジェクトを再利用します。プロジェクトに、App Engine サービスが有効になっている有効な請求先アカウントがあることを確認します。

2. ベースラインのサンプルアプリを取得する

この Codelab の前提条件の 1 つは、モジュール 1 の App Engine アプリを準備しておくことです。モジュール 1 の Codelab を完了するか（推奨）、リポジトリからモジュール 1 アプリをコピーします。皆さんのコードであれ私たちのものであれ、モジュール 1 のコードが「開始」となります。この Codelab では各ステップについて説明します。最後に、モジュール 7 のリポジトリ フォルダ「FINISH」にあるコードに似たコードを使用して締めくくります。

使用するモジュール 1 アプリに関係なく、フォルダは次のようになります。lib フォルダもある可能性があります。

$ ls
README.md               appengine_config.py     requirements.txt
app.yaml                main.py                 templates

3. ベースライン アプリを（再）デプロイする

次の手順でモジュール 1 アプリを（再）デプロイします。

  1. lib フォルダがある場合は削除し、pip install -t lib -r requirements.txt を実行して lib を再設定します。Python 2 と Python 3 の両方がインストールされている場合は、代わりに pip2 コマンドを使用する必要があります。
  2. gcloud コマンドライン ツールをインストールして初期化し、使用方法を確認したことを確認します。
  3. gcloud コマンドを発行するたびに PROJECT_ID を入力しない場合は、Cloud プロジェクトに gcloud config set project PROJECT_ID を設定します。
  4. gcloud app deploy を使用してサンプルアプリをデプロイする
  5. モジュール 1 のアプリが想定どおりに動作し、最近のアクセスの表示に問題がないことを確認します（以下の図を参照）。

a7a9d2b80d706a2b.png

4. 構成の更新

これらのステップを正常に実行し、ウェブアプリが機能することを確認したら、このアプリを Python 3 に移植できます。まずは config から始めます。

SDK を requirements.txt に追加する

App Engine Python 3 ランタイムでは、サードパーティ ライブラリを使用するオーバーヘッドが大幅に削減されます。必要な手順は、それらを requirements.txt にリストすることだけです。Python 3 でバンドル サービスを使用するには、App Engine SDK パッケージ appengine-python-standard を追加します。この SDK パッケージは、モジュール 1:

flask
appengine-python-standard

app.yaml を更新する

app.yaml ファイルに構成の変更を適用する手順は次のとおりです。

  1. runtime ディレクティブを、サポートされている Python 3 リリースに置き換えます。たとえば、Python 3.10 の場合は python310 を指定します。
  2. Python 3 ではどちらも使用されていないため、threadsafe ディレクティブと api_version ディレクティブの両方を削除します。
  3. このアプリにはスクリプト ハンドラしかないため、handlers セクションを完全に削除します。アプリに静的ファイル ハンドラがある場合は、handlers でそのままにします。
  4. Python 3 ランタイムは、Python 2 ランタイムとは異なり、組み込みサードパーティ ライブラリをサポートしていません。アプリの app.yaml に libraries セクションがある場合は、セクション全体を削除します。（必要なパッケージは、非組み込みライブラリと同様に、requirements.txt にリストする必要があります）。このサンプルアプリには libraries セクションがないため、次のステップに進みます。
  5. 使用するには、true に設定した app_engine_apis ディレクティブを作成します。これは、App Engine SDK パッケージを上記の requirements.txt に追加する場合に対応します。

app.yaml に加える必要がある変更の概要:

変更前:

runtime: python27
threadsafe: yes
api_version: 1

handlers:
- url: /.*
  script: main.app

変更後:

runtime: python310
app_engine_apis: true

その他の構成ファイル

すべてのサードパーティ パッケージは requirements.txt にリストするだけでよいため、appengine_config.py に特別なパッケージがない限り、不要なため削除します。同様に、すべてのサードパーティ ライブラリはビルドプロセス中に自動的にインストールされるため、ライブラリをコピーまたはベンダリングする必要がありません。つまり、pip install コマンドや lib フォルダは必要ないので、削除します。要約:

  • appengine_config.py 個のファイルを削除
  • lib 個のフォルダを削除

これで、必要な構成の変更はすべて完了です。

5. アプリケーション コードを変更する

Python 3 ランタイム環境で利用可能なバンドル サービスの大部分にアクセスするには、Web Server Gateway Interface（WSGI）アプリケーション オブジェクトを main.py でラップする短いコードが必要です。ラッパー関数は google.appengine.api.wrap_wsgi_app() です。これをインポートして、WSGI オブジェクトをラップして使用します。main.py の Flask に必要なアップデートを反映するために、以下の変更を行います。

変更前:

from flask import Flask, render_template, request
from google.appengine.ext import ndb

app = Flask(__name__)

変更後:

from flask import Flask, render_template, request
from google.appengine.api import wrap_wsgi_app
from google.appengine.ext import ndb

app = Flask(__name__)
app.wsgi_app = wrap_wsgi_app(app.wsgi_app)

他の Python フレームワークの WSGI ラッピングの例については、ドキュメントをご覧ください。

この例は Python 3 のほとんどのバンドル サービスにアプリからアクセスできるようにするためのものですが、Blobstore や Mail などその他のサービスには追加のコードが必要です。これらのサンプルについては、別の移行モジュールで説明します。

これで、App Engine バンドル サービスの使用をモジュール 1 のサンプルアプリに追加するために必要な変更はすべて完了です。このアプリケーションにはすでに Python 2 と Python 3 との互換性があるため、構成ですでに行ったこと以外に、Python 3 に移行するための追加の変更はありません。最後のステップ: この変更されたアプリを次世代の App Engine Python 3 ランタイムにデプロイし、更新が成功したことを確認します。

6. 概要/クリーンアップ

このセクションでは、この Codelab の締めくくりとして、アプリをデプロイし、意図したとおりに動作することを確認し、反映された出力を確認します。アプリの検証後、クリーンアップを行い、次のステップを検討します。

アプリケーションのデプロイと検証

gcloud app deploy を使用して Python 3 アプリをデプロイし、アプリが Python 2 と同じように動作することを確認します。どの機能も変更されないため、出力はモジュール 1 のアプリの場合と同じになるはずです。

a7a9d2b80d706a2b.png

最終情報

現時点でバンドル サービスを使用しながら、Python 2 App Engine アプリを Python 3 に移行する第一歩を踏み出していただき、ありがとうございます。

クリーンアップ

全般

現時点で完了したら、課金が発生しないように App Engine アプリを無効にすることをおすすめします。さらにテストや実験を行う場合は、App Engine プラットフォームに無料の割り当てが用意されています。この使用量ティアを超えない限り、料金は発生しません。これはコンピューティングに関するものですが、関連する App Engine サービスに対して料金が発生する場合もあります。詳細については、料金ページをご覧ください。この移行に他のクラウド サービスが含まれる場合、それらは別途請求されます。いずれの場合も、該当する場合は「この Codelab に固有の情報」をご覧ください。セクションをご覧ください。

App Engine のような Google Cloud サーバーレス コンピューティング プラットフォームにデプロイすると、わずかなビルドとストレージの費用が発生します。Cloud Build には、Cloud Storage と同様に無料の割り当てがあります。イメージのストレージが割り当ての一部を使い果たします。ただし、このような無料枠がない地域に住んでいる可能性もあるため、潜在的な費用を最小限に抑えるためにストレージの使用量に注意してください。特定の Cloud Storage「フォルダ」確認すべき項目には

  • console.cloud.google.com/storage/browser/LOC.artifacts.PROJECT_ID.appspot.com/containers/images
  • console.cloud.google.com/storage/browser/staging.PROJECT_ID.appspot.com
  • 上記のストレージ リンクは、ご利用の PROJECT_ID と *LOC*に依存します（例: 「us」）アプリが米国でホストされている場合は、

一方、このアプリケーションや他の関連する移行 Codelab を続行せず、すべてを完全に削除したい場合は、プロジェクトをシャットダウンします。

この Codelab のみ

以下に示すサービスは、この Codelab に固有のものです。詳細については、各プロダクトのドキュメントをご覧ください。

次のステップ

ここからは、次のような操作を行います。

  1. バンドル サービスを使用してコードを更新すると、より多くのコード変更が必要
  2. バンドル サービスから Cloud スタンドアロン プロダクトに移行する
  3. App Engine から別の Cloud サーバーレス プラットフォームに移行する

Blobstore、Mail、Deferred など、他のバンドル サービスにアクセスするには、さらにコードを変更する必要があります。以前の App Engine バンドル サービスからの移行に重点を置いた移行モジュールには、次のものがあります。

App Engine はもはや Google Cloud の唯一のサーバーレス プラットフォームではありません。小規模な App Engine アプリまたは機能が限られているアプリをスタンドアロンのマイクロサービスに変換したい場合、またはモノリシック アプリを複数の再利用可能なコンポーネントに分割する必要がある場合は、こうした理由から Cloud Functions への移行を検討することをおすすめします。コンテナ化がアプリケーション開発ワークフローの一部になっている場合、特に CI/CD（継続的インテグレーション/継続的デリバリーまたはデプロイ）パイプラインで構成されている場合は、Cloud Run への移行を検討してください。これらのシナリオについては、次のモジュールで説明します。

  • App Engine から Cloud Functions への移行: モジュール 11 を参照
  • App Engine から Cloud Run への移行: モジュール 4 を参照して、Docker を使用してアプリをコンテナ化するか、モジュール 5 を参照して、コンテナ、Docker の知識、または Dockerfile を使用せずに

別のサーバーレス プラットフォームへの切り替えは任意です。変更を行う前に、アプリやユースケースに最適なオプションを検討することをおすすめします。

次に検討する移行モジュールに関係なく、Serverless Migration Station のすべてのコンテンツ（Codelab、動画、ソースコード（利用可能な場合））には、オープンソース リポジトリからアクセスできます。リポジトリの README には、検討すべき移行や関連する「順序」に関するガイダンスも用意されています。概要をまとめたものです

7. 参考情報

以下に、本モジュールや関連する移行モジュールと関連プロダクトについて詳しく学ぶデベロッパー向けの追加リソースを示します。これには、このコンテンツに関するフィードバックを提供する場所、コードへのリンク、役立つさまざまなドキュメントが含まれます。

Codelab の問題/フィードバック

この Codelab に問題が見つかった場合は、提出する前にまず問題を検索してください。新しい問題の検索と登録を行うためのリンク:

移行に関するリソース

以下の表に、モジュール 1（START）とモジュール 1b（FINISH）のリポジトリ フォルダへのリンクを示します。また、すべての App Engine Codelab 移行のリポジトリからもアクセスできます。

Codelab

Python 2

Python 3

モジュール 1

コード

なし

モジュール 17（この Codelab）

なし

code（mod1b-flask）

オンライン リソース

このチュートリアルに関連する可能性のあるオンライン リソースは次のとおりです。

App Engine のバンドル サービス

App Engine の一般的なドキュメント

Cloud のその他の情報

動画

ライセンス

この作業はクリエイティブ・コモンズの表示 2.0 汎用ライセンスにより使用許諾されています。