App Engine スタンダード環境での Python 2 と Python 3 の違いについて

<<_local_variables.html>>

App Engine スタンダード環境の Python 3 ランタイムは、第 2 世代のランタイムです。新しいサンドボックス テクノロジーによって、このランタイムでは汎用的な方法で完全な Python 開発を行うことができます。

汎用的な Python 開発

Python 3 ランタイムは、3 つのアイデアを中核に開発されています。

  • アプリでは、Python Software Foundation が提供する最新バージョンのオープンソース Python インタープリタが使用されます。
  • requirements.txt ファイルを使用することで、C コードを使用するものを含む、Python のパッケージとフレームワークの豊富なエコシステムをアプリと合わせてデプロイできます。
  • App Engine での開発では、プラットフォーム固有の特別な知識は不要です。

全体的な目標は、アプリを完全に移植可能にし、標準的な Python 環境で実行できるようにすることにあります。App Engine Python アプリではなく、標準的な Python アプリを作成します。この転換に伴い、アプリの中核的な機能として、独自の App Engine API およびサービスを使用する必要がなくなりました。現時点では、App Engine API は Python 3.7 ランタイムでは使用できません。

App Engine スタンダード環境での Python 2 から Python 3 への移行

App Engine スタンダード環境の Python 3 ランタイムは、Python 2 ランタイムとは大きく異なります。以下のセクションでは、Python 2 ランタイムと Python 3 ランタイムの違いについて、またその違いをアプリケーション開発でどのように扱うべきかを示します。

App Engine スタンダード環境で、アプリケーションを Python 2 から Python 3 に移行する場合には、次のような違いに注意する必要があります。

Google では更新が利用可能になり次第、移行パスの追加の更新を共有します。

Python 2 と Python 3 の互換性の問題

2009 年に Python 3 が最初に発表された時点では、Python に対してさまざまな下位互換性のない変更が行われました。それには、print ステートメントが print() 関数になるような簡単な変更や、テキスト、文字列、バイナリデータの処理など、複雑な変更も含まれます。さらに、Python 標準ライブラリを含む一般的な多くのオープンソース ライブラリでは、Python 2 から Python 3 への移行に伴う変更がありました。

こうした変更を理解するために、オンライン ガイドが豊富に用意されています。Python 2 から Python 3 へのコードの自動移行を管理可能な、各種のツールも利用できます。Python コミュニティは、こうした変更に対応するための豊富なリソースを提供しています。これらの詳細については、このドキュメントでは取り上げていません。

ランタイムにおける制限の低減

Python 3 ランタイムでは、Python 2 ランタイムに比べて制限が少なくなっています。サードパーティの任意の依存関係のインストール、ファイル システムへのアクセス、バックグラウンド スレッドの生成、Google Cloud クライアント ライブラリの使用が可能です。

サードパーティの依存関係とネイティブ コード

ネイティブ コードを使用するものを含め、サードパーティの任意の依存関係をインストールできます。App Engine では pip install コマンドを実行することで、requirements.txt メタデータ ファイルに一覧表示されている依存関係がインストールされます。

ファイル システムへのアクセス

ファイルは一時的に /tmp に書き込むことができます。/tmp に書き込まれたファイルは、アプリに対する後続のリクエストでは利用できない可能性があります。

バックグラウンド スレッド

App Engine スタンダード環境の Python 3 にはサンドボックスの制限がないため、リクエスト環境の外部にスレッドやプロセスを自由に作成できます。スレッドとプロセスは、Python 組み込みのスレッド化機能とマルチプロセッシング機能を使用して生成できます。ただし新しいスレッドやプロセスは、受信リクエストの処理後は実行できません。

Cloud クライアント ライブラリ

このランタイムでは google-cloud-python ライブラリがサポートされています。これらのライブラリを使用して、Cloud Pub/Sub、Cloud Datastore、Cloud Spanner などの Google Cloud Platform サービスにアクセスできます。サポートされているプロダクトの一覧については、リポジトリの README をご覧ください。

App Engine スタンダード環境の変更

App Engine スタンダード環境の Python 3.7 ランタイムでは、Python 2.7 ランタイムとは異なり、サービス機能へのアクセスに App Engine SDK を使用しません。Python 3.7 ランタイムを使用する場合は、必要に応じて Google Cloud マネージド サービスやサードパーティ サービスを使用します。

このセクションに記載されている変更は、Python 3.7 のみに適用されます。Python 2.7 ランタイムは変更されません。

app.yaml

app.yaml 構成ファイル内の一部のフィールドの動作が変更されています。

フィールド変更の種類説明
entrypoint追加App Engine フレキシブル環境から導入されました。このフィールドは、アプリの起動時に実行するコマンドを指定する場合に任意で使用できます。
threadsafe非推奨アプリケーションはすべてスレッドセーフであると推定されます。
api_version非推奨Python 3 ランタイムでは廃止されました。
builtins非推奨
ライブラリ非推奨requirements.txt メタデータ ファイルを使用して、サードパーティの任意の依存関係をインストールできます。
handlers修正
  • script は任意であり、使用可能な値は auto だけです。ウェブ フレームワーク(Flask や Django など)とアプリ内ルーティングを使用して、リクエストが特定のルートを取ったときにスクリプトを実行します。
  • login フィールドはサポートされていません。ユーザー管理には Cloud Identity and Access Management を使用します。

非推奨のフィールドを使用すると、アプリをデプロイするときにエラーが返されます。

デプロイ

Python 3.7 では、appcfg.py を使用したデプロイはサポートされていません。アプリのデプロイには gcloud コマンドライン ツールを使用します。

App Engine API

Python 3 では独自の App Engine API は使用できません。このセクションでは、おすすめの代替サービスを示します。

Blobstore

データを格納および取得するには、Google Cloud クライアント ライブラリを介して Cloud Storage を使用します。開始するには、Cloud Storage の使用をご覧ください。

Datastore

NoSQL Key-Value データベースに代わる、Datastore API と同様のものとして、Cloud Firestore を使用します。新しい Cloud Firestore データベースを作成するときに、Cloud Datastore モードで実行するようにデータベース インスタンスを構成でき、そうすることでデータベースは Cloud Datastore との下位互換性が得られます。

詳細については、ネイティブ モードと Datastore モードの選択をご覧ください。

画像

画像の操作や処理には、Imgix をおすすめします。または、無料枠が必要な場合は Rethumb を使用します。

画像を格納および提供するには、Cloud Storage の使用または静的ファイルの提供をご覧ください。

ロギング

リクエストログは自動的に関連付けられなくなりましたが、Stackdriver Logging には表示されます。Stackdriver Logging クライアント ライブラリを使用して、目的のロギング動作を実装できます。

メール

メールを送信するには、SendGridMailgunMailjet などのサードパーティのメール プロバイダを使用します。これらのサービスはいずれも、アプリケーションからメールを送信するための API を提供しています。

Memcache

アプリケーション キャッシュを構築するには、Cloud Memorystore インスタンスを作成し、サーバーレス VPC アクセスを使用してインスタンスをアプリに接続します。

モジュール

環境変数と App Engine Admin API を組み合わせて使用して、情報を取得し、アプリケーションで実行されているサービスを変更します。

サービス情報 アクセスする方法
現在のサービス名 GAE_SERVICE 環境変数
現在のサービス バージョン GAE_VERSION 環境変数
現在のインスタンス ID GAE_INSTANCE 環境変数
デフォルトのホスト名 Admin API の apps.get メソッド
サービスのリスト Admin API の apps.services.list メソッド
特定のサービスのバージョンのリスト Admin API の apps.services.versions.list メソッド
特定のサービスのデフォルト バージョン(トラフィック分割を含む) Admin API の apps.services.get メソッド
特定のバージョンで実行中インスタンスのリスト Admin API の apps.services.versions.instances.list メソッド

Compute Engine 上で ElasticSearch のような全文検索データベースをホストし、サービスからアクセスします。

タスクキュー

Cloud Tasks REST API、RPC API、Google Cloud クライアント ライブラリを使用して非同期コード実行のためにタスクをキューに入れ、Python 3.7 App Engine 標準サービスを push ターゲットとして使用します。詳細については、タスクキューから Cloud Tasks への移行をご覧ください。

pull キューを使用する多くのケース、たとえば、別個のワーカーによって pull されて処理されるタスクやメッセージをキューに追加する場合などにおいて、機能が類似し、配信が保証される Cloud Pub/Sub は、代替案として適しています。

ユーザー

Users API の代わりに、次のような HTTP ベースの任意の認証メカニズムを使用します。

ローカルでの開発

一般に、dev_appserver に依存するよりも、Python に対して汎用的なテスト方法を使用することをおすすめします。たとえば virtualenv を使用すれば、分離されたローカル Python 3.7 環境を作成できます。標準的な任意の Python テスト フレームワークを使用して、単体テスト、統合テスト、システムテストを作成できます。サービスのデベロッパー版を設定するか、多くの Google Cloud プロダクトで用意されているローカル エミュレータを使用することもできます。

これを使用するためのオプション機能として、Python 3 をサポートする更新された dev_appserver のアルファ版を提供しています。このオプションについて詳しくは、ローカル開発用サーバーの使用をご覧ください。

このページは役立ちましたか?評価をお願いいたします。

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

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