Python 3 ランタイム環境

Python 3 ランタイムは、ウェブサービスのコードとその依存関係をインストールして App Engine サービスを実行する役割を果たすソフトウェア スタックです。

スタンダード環境の App Engine 用 Python 3 ランタイムは、app.yaml ファイル内で次のように宣言されています。

runtime: pythonVERSION

ここで、VERSION は Python MAJORMINOR のバージョンです。たとえば、Python 3.12 の場合は 312 になります。

サポートされている他の Python バージョンと、お使いの Python バージョンに対応する Ubuntu のバージョンについては、ランタイム サポート スケジュールをご覧ください。

Python 3 のバージョン

Python 3 ランタイムは、app.yaml ファイルで指定されているバージョンの最新の安定版を使用します。App Engine では、パッチ バージョンは新しいものに自動更新されますが、マイナー バージョンの更新は自動的には行われません。

たとえば、Python 3.7.0 にデプロイしたアプリケーションが Python 3.7.1 に自動的に更新されることはありますが、次のマイナー バージョンである Python 3.8.0 には自動更新されません。

使ってみる

Google Cloud を初めて使用される方は、アカウントを作成して、実際のシナリオでの App Engine のパフォーマンスを評価してください。新規のお客様には、ワークロードの実行、テスト、デプロイができる無料クレジット $300 分を差し上げます。

App Engine 無料トライアル

App Engine は、gVisor によって保護されたコンテナで、最新の Ubuntu Linux ディストリビューションを使用して Python 3 アプリを実行します。

依存関係

デプロイ時に、App Engine は Python パッケージ マネージャー pip を使用して、プロジェクトのルート ディレクトリにある requirements.txt メタデータ ファイルで定義された依存関係をインストールします。依存関係は App Engine によって新しくインストールされるため、アップロードする必要はありません。

Pipfile / Pipfile.lock スタンダードを使用した依存関係の指定は現在サポートされていないため、プロジェクトではこれらのファイルを使用できません。

アプリケーションの起動

ランタイムは、app.yaml ファイル内の entrypoint フィールドで指定したコマンドを実行してアプリを起動します。app.yaml ファイルで Gunicorn ウェブサーバーのエントリポイントを構成している場合は、requirements.txt ファイルに gunicorn も追加する必要があります。

エントリポイントは、PORT 環境変数で指定されたポートをリッスンするウェブサーバーを起動します。次に例を示します。

entrypoint: gunicorn -b :$PORT main:app

アプリで使用するウェブ フレームワークは、アプリ内の適切なハンドラにリクエストをルーティングします。

アプリが次の要件を満たしている場合、entrypoint フィールドを指定しないと、App Engine は gunicorn ウェブサーバーでアプリを起動します。

  • アプリのディレクトリのルートに、app という WSGI 準拠のオブジェクトを含む main.py ファイルが格納されている。

  • アプリに Pipfile ファイルまたは Pipfile.lock ファイルが含まれていない。

Python 3 ランタイムのエントリポイントを指定しない場合、App Engine はデフォルトの Gunicorn ウェブサーバーを構成して起動します。

エントリポイントのベスト プラクティス

  • app.yaml で指定したエントリポイントの実行に必要な Python モジュールが requirements.txt ファイルに存在することを確認します。app.yaml ファイルで gunicorn エンドポイントが明示的に指定されている場合にのみ、gunicornrequirements.txt ファイルに追加します。

  • パフォーマンスの観点から、エントリポイントを軽量化することが重要です。エントリポイントはアプリケーションの新しいインスタンスが作成されるたびに実行されるからです。

  • エントリポイント フィールドを使用して、アプリのパフォーマンスを調整できます。たとえば、gunicorn をウェブサーバーとして使用する場合は、エントリポイント フィールドで --workers フラグを使用して、アプリを処理するワーカーの数を構成できます。

    指定するワーカーの数は、App Engine アプリのインスタンス クラスと一致する必要があります。

    インスタンス クラス ワーカー
    F1 2
    F2 4
    F4 8
    F4_1G 8
    B1 2
    B2 4
    B4 8
    B4_1G 8
    B8 8

    このガイダンスは、ワーカー数を選択するための出発点として役立ちます。アプリのパフォーマンス特性によっては、上記とは異なる数のワーカーを使用しなければならない場合もあります。次の例は、2 つの gunicorn ワーカーを使用してアプリを処理する App Engine デプロイメントを示しています。

    entrypoint: gunicorn -b :$PORT -w 2 main:app
    
  • $PORT 環境変数で指定されたポートで、ウェブサーバーが HTTP リクエストをリッスンして応答するように構成することをおすすめします。デフォルト ポート 8080 を使用すると、App Engine は NGINX レイヤを使用して HTTP レスポンスを圧縮できなくなります。ポート 8080 を使用すると、ポート 8080 と NGINX に関する警告がアプリのログファイルに表示されます。

その他のウェブ フレームワーク

Django や Flask に加えて、App Engine で uwsgiTornado などの他のウェブ フレームワークも使用できます。次の例は、App Engine で uwsgi を使用する方法を示しています。

runtime: python39
entrypoint: uwsgi --http-socket :$PORT --wsgi-file main.py --callable app --master --processes 1 --threads 2
uwsgi==2.0.22
Flask==3.0.0

環境変数

ランタイムは以下の環境変数を設定します。

環境変数 説明
GAE_APPLICATION App Engine アプリケーションの ID。この ID の先頭には「region code~」が付きます。たとえば、ヨーロッパでデプロイされたアプリケーションの場合は「e~」となります。
GAE_DEPLOYMENT_ID 現在のデプロイの ID。
GAE_ENV App Engine の環境。standard に設定します。
GAE_INSTANCE 現在サービスが実行されているインスタンスの ID。
GAE_MEMORY_MB アプリケーション プロセスで使用可能なメモリ量(MB)。
GAE_RUNTIME app.yaml ファイル内で指定したランタイム。
GAE_SERVICE app.yaml ファイル内で指定したサービス名。サービス名が指定されていない場合は、default に設定されます。
GAE_VERSION サービスの現在のバージョン ラベル。
GOOGLE_CLOUD_PROJECT アプリケーションに関連付けられた Google Cloud プロジェクト ID。
PORT HTTP リクエストを受信するポート。
NODE_ENV(Node.js ランタイムでのみ使用可能) サービスがデプロイされたとき production に設定。

app.yaml ファイル内で追加の環境変数を定義できますが、上記の値は NODE_ENV を除きオーバーライドできません。

HTTPS プロキシと転送プロキシ

App Engine は、ロードバランサにおいて HTTPS 接続を終了し、リクエストをアプリケーションに転送します。アプリケーションによっては、元のリクエストの IP とプロトコルが何か確認する必要があります。ユーザーの IP アドレスは、標準の X-Forwarded-For ヘッダーで確認できます。この情報が必要なアプリケーションでは、プロキシを信頼するようにウェブ フレームワークを構成してください。

ファイル システム

このランタイムには完全なファイル システムが含まれています。このファイル システムの /tmp(App Engine インスタンスの RAM 内のデータを格納する仮想ディスク)以外の場所は読み取り専用です。

メタデータ サーバー

アプリケーションの各インスタンスは、App Engine メタデータ サーバーを使用してインスタンスとプロジェクトに関する情報を照会できます。

次のエンドポイントを介してメタデータ サーバーにアクセスできます。

  • http://metadata
  • http://metadata.google.internal

メタデータ サーバーに送信されるリクエストには、リクエスト ヘッダー Metadata-Flavor: Google を挿入する必要があります。このヘッダーは、メタデータ値を取得する目的でリクエストが送信されたことを示します。

次の表に、特定のメタデータを取得するための HTTP リクエストの各エンドポイントを示します。

メタデータ エンドポイント 説明
/computeMetadata/v1/project/numeric-project-id プロジェクトに割り当てられているプロジェクト番号。
/computeMetadata/v1/project/project-id プロジェクトに割り当てられているプロジェクト ID。
/computeMetadata/v1/instance/region インスタンスが実行されているリージョン。
/computeMetadata/v1/instance/service-accounts/default/aliases
/computeMetadata/v1/instance/service-accounts/default/email プロジェクトに割り当てられているデフォルトのサービス アカウントのメール。
/computeMetadata/v1/instance/service-accounts/default/ プロジェクトのすべてのデフォルトのサービス アカウントを一覧表示します。
/computeMetadata/v1/instance/service-accounts/default/scopes デフォルトのサービス アカウントでサポートされているすべてのスコープを一覧表示します。
/computeMetadata/v1/instance/service-accounts/default/token アプリケーションを他の Google Cloud APIs に認証させるための認証トークンを返します。

たとえば、プロジェクト ID を取得するには、リクエストを http://metadata.google.internal/computeMetadata/v1/project/project-id に送信します。