app.yaml リファレンス

App Engine アプリの設定は app.yaml ファイルで構成します。このファイルでは、アプリのインスタンスを起動することなく、提供される静的アセットへの URL パスを指定できます。app.yaml ファイルには、アプリのコード、Python のランタイム、エントリポイント、環境変数に関する情報も含まれています。

アプリ内の各サービスには、それぞれに固有の app.yaml ファイルがあり、デプロイの際にデプロイ記述子として機能します。アプリ内にサービスを追加する際には、app.yaml ファイルを作成してデプロイする前に、デフォルト サービス用の app.yaml ファイルを作成する必要があります。

サービスの app.yaml ファイルは、そのサービスのルート ディレクトリにある必要があります。アプリ内の複数のサービスの構造化については、App Engine でのウェブサービスの構造化をご覧ください。Python の場合は、app.yaml ファイルには runtime: python3 エントリのみを含める必要があります。概要については、ランタイム設定の定義を参照してください。

Python アプリケーションの app.yaml ファイルの例を次に示します。

runtime: python37

instance_class: F2

env_variables:
  BUCKET_NAME: "example-gcs-bucket"

handlers:
# Matches requests to /images/... to files in static/images/...
- url: /images
  static_dir: static/images

- url: /.*
  secure: always
  redirect_http_response_code: 301
  script: auto

構文

app.yaml の構文は YAML 形式です。

YAML 形式ではコメントがサポートされています。ハッシュ(#)記号で始まる行は無視されます。

# This is a comment.

URL とファイルパスのパターンは、要素照合とクラス照合を除き、POSIX 拡張正規表現構文を使用します。グループ化した一致への後方参照(例: \1)は、Perl 拡張(\w \W \s \S \d \D)と同様にサポートされます。

ランタイムとアプリの要素

要素 説明
application

application 要素は app.yaml ファイルから削除し、代わりにコマンドライン フラグを使用してアプリケーション ID を指定することをおすすめします。

  • gcloud app deploy コマンドを使用するには、--project フラグを指定する必要があります。
    
    gcloud app deploy --project [YOUR_PROJECT_ID]

これらのコマンドの詳細については、アプリのテストおよびデプロイをご覧ください。

アプリケーション ID は、Google Cloud Platform Console でアプリケーションを作成したときに指定した GCP Console プロジェクト ID です。

default_expiration

省略可。アプリケーションのすべての静的ファイル ハンドラにグローバルなデフォルト キャッシュ期間を設定します。特定の静的ファイル ハンドラを対象にキャッシュ期間を構成することもできます。設定する値は、数値と単位の文字列をスペースで区切ったものです。単位には、日数を表す d、時間数を表す h、分数を表す m、秒数を表す s を指定できます。たとえば、"4d 5h" は、ファイルが最初に要求された後のキャッシュの有効期限を 4 日と 5 時間後に設定します。省略すると、本番環境のサーバーは有効期限を 10 分に設定します。

例:

runtime: python37

default_expiration: "4d 5h"

handlers:
# ...
            

詳細については、静的キャッシュの有効期限をご覧ください。

entrypoint

省略可。アプリの起動時に実行されるコマンドです。アプリケーションで HTTP リクエストを受信するには、entrypoint にウェブサーバーを起動させるコマンドが含まれており、その際、PORT 環境変数で指定されたポートでリッスンするように指定されている必要があります。entrypoint を指定しない場合、App Engine は Gunicorn ウェブサーバーを構成して起動します。

env_variables

省略可。アプリで使用できるように、app.yaml ファイルで環境変数を定義できます。

GAE という接頭辞が付いた環境変数はシステム用に予約されており、app.yaml ファイルでは使用できません。

これらの変数は os.environ 辞書で利用できます。

env_variables:
  MY_VAR: 'my value'
error_handlers

省略可。 エラータイプごとに表示されるカスタム エラーページを設定します。

この要素には次の要素を設定できます。

error_code
省略可。error_code は、以下のいずれかになります。
over_quota
アプリがリソース割り当ての上限を超えていることを示します。
dos_api_denial
リクエストがアプリの DoS 防止構成でブロックされたことを示します。
timeout
アプリからレスポンスが返される前に時間切れとなった場合に使用されます。

エラーコードは省略可能です。省略すると、指定したファイルがアプリのデフォルトのエラー レスポンスになります。

file
file エントリには、汎用的なエラー レスポンスの代わりに表示される静的ファイルを指定します。対応する error_code 要素を使用せずに file 要素を指定すると、静的ファイルがアプリのデフォルトのエラーページになります。 カスタム エラーデータは 10 KB 未満にする必要があります。

error_handlers:
  - file: default_error.html

  - error_code: over_quota
    file: over_quota.html
  
handlers

省略可。URL パターンの一覧と静的ファイルの説明が提供される必要があります。App Engine は、画像、CSS、JavaScript などの静的ファイルが提供されることで、URL を処理できるようになります。静的ハンドラを指定すると、ユーザーのリクエストでアプリの新しいインスタンスを起動させないようにできます。

ハンドラとサブ要素の構文をご覧ください。

inbound_services

省略可。このサービスを Python 3 アプリで有効にするには、app.yaml ファイルに inbound_services セクションを追加します。

以下のインバウンド サービスが使用できます。

warmup
アプリのパフォーマンスを向上させるために、ウォームアップ リクエストを発行するインバウンド サービスを有効にできます。Python 3 アプリケーション用にサービスを有効にするには、app.yaml ファイルに inbound_services セクションを含めます。ウォームアップ リクエストの構成をご覧ください。
例:

inbound_services:
- warmup
instance_class

省略可。 このサービスのインスタンス クラス

サービスのスケーリングに応じて、次の値を使用できます。

自動スケーリング
F1F2F4F4_1G
デフォルト: automatic_scaling 要素とともにインスタンス クラスを指定していない場合は、F1 が割り当てられます。
基本スケーリングと手動スケーリング
B1B2B4B4_1GB8
デフォルト: basic_scaling 要素または manual_scaling 要素とともにインスタンス クラスを指定しない場合は、B2 が割り当てられます。

: B1、B2、B4、B4_1G、B8 の instance_class を指定するアプリは、現在、既知の問題の影響を受けます。Python 3.7 のランタイムを使用している場合、アプリでトラフィックが処理できなくなります。app.yaml ファイルに次のコードを追加すると、この問題を一時的に回避できます。

runtime: python37
instance_class: B1

# and add the following lines to the handlers element:
handlers:
 - url: '/.*'
   script: auto
runtime

必須。アプリで使用されるランタイム環境の名前です。Python 3.7 を指定する場合には、python37 を使用します。


runtime: python37
service

サービスを作成する場合には必須です。default サービスでは省略できます。サービスとバージョンには名前を付ける必要があります。名前には、数字、英字、ハイフンを使用できます。名前は 63 文字以下にする必要があります。また、名前の先頭または最後にハイフンは使用できません。各サービスとバージョンには一意の名前を付ける必要があります。サービスとバージョンに同じ名前を使うことはできません。

例:

service: service_name
skip_files

skip_files 要素は、スタンダード環境の Python 3.7 ではサポートされていません。代わりに、app.yaml があるルート ディレクトリに .gcloudignore ファイルを作成します。詳細については、.gcloudignore のリファレンスを参照してください。

threadsafe

threadsafe 要素は、スタンダード環境の Python 3 ではサポートされていません。デフォルトでは、スタンダード環境のすべての Python 3 アプリが同時リクエストを処理します。

vpc_access_connector

省略可。Serverless VPC Access コネクタを使用するようにアプリケーションを構成して、アプリケーションが VPC ネットワークの内部リソースにリクエストを送信できるようにします。name フィールドにコネクタの完全修飾名を指定します。


vpc_access_connector:
  name: "projects/[PROJECT_ID]/locations/[REGION]/connectors/[CONNECTOR_NAME]"

詳細については、VPC ネットワーク内の内部リソースへの接続をご覧ください。

handlers 要素

handlers 要素はオプションです。URL パターンの一覧と処理方法に関する説明を提供します。App Engine は、画像、CSS、JavaScript などの静的ファイルが提供されることで、URL を処理できるようになります。一般に、アプリはアプリ内ルーティングを介してアプリケーション コードへのリクエストを処理する必要があります。アプリケーション コードを解決する URL では、handlers を使用する必要はありません。

パターンは、app.yaml ファイルの上から下へ順に評価されます。URL とパターンが一致する最初の組み合わせが、リクエストの処理に使用されます。

以下の表に、静的ファイル、静的ディレクトリ、その他の設定の動作を制御する、handlers 要素のサブ要素を示します。

要素 説明
expiration 省略可。このハンドラで処理する静的ファイルがウェブプロキシとウェブブラウザでキャッシュに保存される有効期限。値は、数値と単位の文字列をスペースで区切ったものです。単位には、日数を表す d、時間数を表す h、分数を表す m、秒数を表す s を指定できます。たとえば、"4d 5h" は、ファイルが最初に要求された後のキャッシュの有効期限を 4 日と 5 時間後に設定します。省略した場合は、アプリケーションの default_expiration が使用されます。詳細については、静的キャッシュの有効期限をご覧ください。
http_headers

省略可。静的ファイル ハンドラまたはディレクトリ ハンドラのレスポンスに HTTP ヘッダーを設定できます。Python 3 では、アプリのコードを使用して HTTP ヘッダーを設定します。


handlers:
- url: /images
  static_dir: static/images
  http_headers:
    X-Foo-Header: foo
    X-Bar-Header: bar value

CORS サポート

この機能の重要な用途の 1 つは、別の App Engine アプリでホストされているファイルへのアクセスなど、クロスオリジン リソース シェアリング(CORS)をサポートすることです。

たとえば、ゲームアプリ mygame.appspot.com から myassets.appspot.com でホストされているアセットにアクセスするとします。ところが、mygamemyassets に対して JavaScript の XMLHttpRequest を実行する場合、myassets のハンドラが値 http://mygame.appspot.com を含む Access-Control-Allow-Origin: レスポンス ヘッダーを返さない限り、その処理は成功しません。

以下の例では、静的ファイル ハンドラが必要なレスポンス ヘッダー値を返しています。


handlers:
- url: /images
  static_dir: static/images
  http_headers:
    Access-Control-Allow-Origin: http://mygame.appspot.com

注: すべてのユーザーにアセットに対するアクセスを許可するには、http://mygame.appspot.com ではなく、ワイルドカード '*' を使用します。

login

login 要素は、スタンダード環境の Python 3 ではサポートされていません。ユーザー管理のために、Cloud Identity とアクセス管理を使用できます。詳しくは、アクセス制御についてを参照してください。

mime_type

省略可。指定した場合、このハンドラで処理するすべてのファイルが、指定した MIME タイプを使用して処理されます。指定しない場合、ファイル名の拡張子からファイルの MIME タイプが決定されます。

使用可能な MIME メディアタイプについては、IANA MIME メディアタイプのウェブサイトをご覧ください。

redirect_http_response_code

省略可。redirect_http_response_codesecure 設定とともに使用され、secure 設定の構成によってリダイレクトが実行される際に返される HTTP レスポンス コードを設定します。 redirect_http_response_code 要素には次の値を使用できます。

301
恒久移動のレスポンス コード。
302
検出のレスポンス コード。
303
他の参照を求めるレスポンス コード。
307
一時的リダイレクトのレスポンス コード。

ユーザーのリクエストがリダイレクトされると、HTTP ステータス コードが redirect_http_response_code パラメータの値に設定されます。パラメータが存在しない場合には、302 が返されます。

script

省略可。特定のハンドラへのリクエストでアプリを対象とする必要があることを指定します。script 要素で取ることのできる値は auto のみです。


handlers:
- url: /images
  static_dir: static/images

- url: /.*
  secure: always
  redirect_http_response_code: 301
  script: auto

secure 省略可。静的ファイル ハンドラを含むすべての URL ハンドラで、secure 設定を使用できます。secure 要素には次の値を使用できます。
optional
リクエストが HTTP か HTTPS を問わず、URL がハンドラと一致すれば成功し、リダイレクトは行われません。アプリケーションは、リクエストを調べてどちらのプロトコルが使われたか確認し、それに従って適切に応答できます。ハンドラで secure が指定されていない場合、これがデフォルトです。
never
リクエストの URL がこのハンドラと一致し、かつ HTTPS を使用している場合、リクエストを対応する HTTP URL に自動的にリダイレクトします。ユーザーの HTTPS リクエストがリダイレクトされて HTTP リクエストになると、クエリ パラメータはリクエストから削除されます。これにより、ユーザーが誤って、保護された接続用のクエリデータを保護されていない接続で送信することを防ぎます。
always
リクエストの URL がこのハンドラと一致し、かつ HTTPS を使用していない場合、リクエストを同じパスの HTTPS URL に自動的にリダイレクトします。クエリ パラメータはリダイレクトされても維持されます。

handlers:
- url: /youraccount/.*
  secure: always
  script: auto

appspot.com ドメインを使用している特定のバージョンのアプリを対象とするには、通常、URL のサブドメイン コンポーネントを区切るピリオドを、文字列「-dot-」に置き換えます。次に例を示します。


https://[VERSION_ID]-dot-[YOUR_PROJECT_ID].appspot.com

HTTPS でカスタム ドメインを使用するには、そのドメインで SSL 証明書を有効にして構成する必要があります。

Google アカウントのログインとログアウトは常に保護された接続を使用して実行されます。アプリケーションの URL の構成方法とは関係ありません。

static_dir

省略可。アプリケーションのルート ディレクトリから、静的ファイルを含むディレクトリへのパス。static_dir の後に、一致する url パターンより後ろの部分を追加すると、リクエストされたファイルへのフルパスとなります。

各ファイルは、ディレクトリの mime_type の設定で上書きしない限り、ファイル名の拡張子に対応する MIME タイプを使用して処理されます。指定したディレクトリ内のすべてのファイルは静的ファイルとしてアップロードされ、これらのファイルはいずれもスクリプトとして実行することはできません。

このディレクトリ内のすべてのファイルは、静的ファイルとしてアプリと一緒にアップロードされます。

例:

handlers:
# All URLs beginning with /stylesheets are treated as paths to
# static files in the stylesheets/ directory.
- url: /stylesheets
  static_dir: stylesheets
static_files

省略可。静的ファイル ハンドラを使用して、URL パターンと、アプリケーションとともにアップロードされる静的ファイルへのパスを関連付けます。URL パターンの正規表現を使用して、ファイルパスの構成で使用する正規表現のグループを定義できます。static_dir ではなくこのハンドラを使用すると、ディレクトリ全体にマッピングするのではなく、ディレクトリ構造内の特定のファイルにマッピングできます。

例:

handlers:
# All URLs ending in .gif .png or .jpg are treated as paths to
# static files in the static/ directory. The URL pattern is a
# regular expression, with a grouping that is inserted into the
# path to the file.
- url: /(.*\.(gif|png|jpg))$
  static_files: static/\1
  upload: static/.*\.(gif|png|jpg)$
upload

省略可。このハンドラによって参照されるすべてのファイルのファイルパスと一致する正規表現。ハンドラでは、アプリケーション ディレクトリ内のどのファイルが、指定した urlstatic_files パターンに対応するのかを特定できないため、この定義が必要になります。静的ファイルは、アプリケーション ファイルと分けてアップロード、処理されます。上のでは、次の upload パターンを使用できます。archives/(.*)/items/(.*)

url

handlers で必要な要素。グループ化を含めることができる正規表現を使用した URL パターンです。たとえば、/profile/(.*)/(.*) は、URL /profile/edit/manager に一致し、editmanager を最初と 2 番目のグループとして使用します。

以下の要素と一緒に使用すると、URL パターンの動作の一部が変わります。

static_dir
URL 接頭辞を使用します。static_dir 要素を使用する場合には、正規表現のパターンにグループ化を使用することはできません。この接頭辞で始まるすべての URL は、このハンドラで処理され、URL の接頭辞より後ろの部分がファイルパスの一部として使用されます。
static_files
静的ファイル ハンドラを使用して、URL パターンと、アプリケーションとともにアップロードされる静的ファイルへのパスを関連付けます。URL パターンの正規表現を使用して、ファイルパスの構成で使用する正規表現のグループ化を定義できます。static_dir ではなくこのハンドラを使用すると、ディレクトリ全体にマッピングするのではなく、ディレクトリ構造内の特定のファイルにマッピングできます。

スケーリングの要素

App Engine アプリのスケーリングの詳細については、動的インスタンスのスケーリングをご覧ください。

次の表では、アプリケーションのスケーリングを指定する場合のオプションについて説明します。

要素 説明
automatic_scaling

省略可。特に指定のない限り、自動スケーリングが適用され、デフォルトのインスタンス クラス F1 が使用されます。

automatic_scaling 要素には、サービスのインスタンス、レイテンシ、同時接続の最小数と最大数を設定します。

この要素には次の要素を設定できます。

target_cpu_utilization
省略可。0.5〜0.95 の値を指定します。デフォルトは 0.6 です。

このパラメータは、トラフィックを処理する新しいインスタンスを起動するための CPU 使用率のしきい値を指定します。これにより、パフォーマンスとコストのバランスをとることができます。値を小さくするほど、パフォーマンスが向上してコストは増加し、値を大きくするほどパフォーマンスは低下してコストが削減される傾向があります。たとえば、値を 0.7 にすると、CPU 使用率が 70% に達した後に新しいインスタンスが起動されます。

target_throughput_utilization
省略可。0.5〜0.95 の値を指定します。デフォルトは 0.6 です。

max_concurrent_requests とともに使用して、同時リクエストによって新しいインスタンスが起動されるタイミングを指定します。同時リクエストの数が max_concurrent_requeststarget_throughput_utilization の積に等しい値に達すると、スケジューラは新しいインスタンスを起動します。

max_instances
省略可。0〜2147483647 の値を指定します。0 にするとこの設定が無効になります。

このパラメータは、App Engine がこのモジュール バージョンに対して作成するインスタンスの最大数を指定します。これはモジュールのコストを制限する場合に役立ちます。

min_instances
省略可。App Engine によってこのモジュール バージョンに作成されるインスタンスの最小数。これらのインスタンスは、リクエストが届いたときにトラフィックを処理し、トラフィックを処理するために必要な追加インスタンスが起動されてもトラフィックを処理し続けます。

0〜1000 の値を指定します。このパラメータを 0 に設定すると、リクエストが処理されていないときにインスタンス数を 0 にスケーリングしてコストを削減できます。ただし、トラフィックを受信しているかどうかにかかわらず、指定されたインスタンス数分の料金が請求される点に注意してください。

max_concurrent_requests

省略可。自動スケーリング インスタンスが受け入れることのできる同時リクエスト数。この数を超えると、スケジューラから新しいインスタンスが生成されます(デフォルト: 8、最大: 80)。

max_concurrent_requests とともに使用して、同時リクエストによって新しいインスタンスが起動されるタイミングを指定します。同時リクエストの数が max_concurrent_requeststarget_throughput_utilization の積に等しい値に達すると、スケジューラは新しいインスタンスを起動します。

この値を大きくすると、API のレイテンシが増加する場合があります。リクエストの最大数に達する前にスケジューラが新しいインスタンスを生成する場合もあります。

max_idle_instances

省略可。App Engine がこのバージョンに保持できるアイドル状態のインスタンスの最大数。0〜1000 の値、または automatic を指定します。デフォルト値は automatic です。以下のことに注意してください。

  • 最大数を大きく設定すると、負荷レベルの急増後に通常のレベルに戻る際に、アイドル インスタンスの数がより緩やかに減っていきます。その結果、アプリケーションがリクエスト負荷変動の前後を通じて安定したパフォーマンスを維持しやすくなる一方で、そのような負荷の高い期間のアイドル インスタンスの数(その結果としてランニング コスト)も増えます。
  • 最大数を小さく設定すると、ランニング コストは低く抑えられますが、負荷レベルの変動があったときにパフォーマンスが低下する可能性があります。

注: 負荷の急増後に通常のレベルに戻るときに、アイドル インスタンスの数が指定した最大数を一時的に超える可能性があります。この場合、指定した最大数を超える分について料金が請求されることはありません。

max_pending_latency

App Engine がリクエストを保留キューで待機させることができる最長時間。この時間が経過すると、保留待ち時間を短縮できるように、リクエストを処理する新しいインスタンスが起動されます。このしきい値に達すると、それがスケールアップの信号となり、インスタンス数の増加につながります。デフォルト値は「30 ms」です。

App Engine は、「min_pending_latency」と「max_pending_latency」で指定された時間内であればいつでもインスタンスを作成できます。つまり、App Engine が「min_pending_latency」で指定された時間より前に、保留中のリクエストを処理するためのインスタンスを作成することはありません。「max_pending_latency」の時間になるとインスタンスが作成されます。

  • 最大時間を短く設定すると、App Engine が保留中のリクエストに対処するための新しいインスタンスを作成するタイミングが早くなり、パフォーマンスは向上しますがランニング コストも高くなります。
  • 最大時間を長く設定すると、ユーザーがリクエストの処理を待つ時間は長くなる可能性があります(保留中のリクエストがありそれらに対処するアイドル インスタンスがない場合)が、アプリケーションのランニング コストは低くなります。
min_idle_instances

動作中でトラフィックを処理する準備ができているインスタンスの数。ただし、トラフィックを受信しているかどうかにかかわらず、指定されたインスタンス数分の料金が請求される点に注意してください。この設定は、トラフィックの大半を受信するバージョンにのみ適用されます。以下のことに注意してください。

  • 最小数を小さく設定すると、アイドル時間にかかるランニング コストは低く抑えられますが、負荷の急増があった場合にすぐに対処できるインスタンスの数が少ないということになります。
  • 最小数を大きく設定すると、アプリケーションがリクエスト負荷の急増に対応できるようになります。App Engine では、最小数のインスタンスを常に実行して、受信したリクエストの処理に当たります。インスタンスがリクエストを処理しているかどうかにかかわらず、指定されたインスタンス数分の料金が請求されます。この機能を適正に機能させるには、ウォームアップ リクエストが有効であること、およびアプリケーションでウォームアップ リクエストが処理されることを確認する必要があります。

    アイドル インスタンスの最小数を設定すると、保留レイテンシがアプリケーションのパフォーマンスに与える影響は小さくなります。App Engine では一定数のアイドル インスタンスが常に確保されるため、異常なほど負荷が急増した場合を除き、リクエストが保留中のキューに入る可能性は低くなります。どれくらいの数のインスタンスを確保するのが理想的かを判断するには、アプリケーションと予想されるトラフィック量をテストする必要があります。

min_pending_latency

App Engine でリクエストが保留キューで待機する最短時間。この時間が経過すると、リクエストを処理するために新しいインスタンスが起動されます。このしきい値に達すると、それがスケールダウンのきっかけとなり、インスタンス数の減少につながります。デフォルト値は「30 ms」です。

  • 最小待ち時間を短く設定すると、既存のインスタンスがすべて稼働中のときにリクエストが保留中のキューにとどまる時間が短くなります。パフォーマンスは向上しますが、アプリケーションのランニング コストも高くなります。
  • 最小時間を長く設定すると、既存のインスタンスがすべて稼動中のときにリクエストが保留中のキューにとどまる時間が長くなります。ランニング コストは低くなりますが、ユーザーがリクエストの処理を待つ時間は長くなります。

service: my-service
runtime: python37
instance_class: F2
automatic_scaling:
  target_cpu_utilization: 0.65
  min_instances: 5
  max_instances: 100
  min_pending_latency: 30ms  # default value
  max_pending_latency: automatic
  max_concurrent_requests: 50
basic_scaling

省略可。basic_scaling 要素には、サービスのインスタンス数を設定します。

この要素には次の要素を設定できます。

idle_timeout
省略可。最後のリクエストを受信した後、この時間が経過すると、インスタンスはシャットダウンされます。デフォルトは 5 分です。
max_instances
必須。App Engine によってこのサービスのバージョンに対して作成されるインスタンスの最大数。これはサービスのコストを制限する場合に役立ちます。

service: my-service
runtime: python37
instance_class: B8
basic_scaling:
  max_instances: 11
  idle_timeout: 10m
manual_scaling

省略可。manual_scaling 要素を使用すると、サービスで手動スケーリングを有効にし、サービスのインスタンス数を設定できます。

この要素には次の要素を設定できます。

instances
モジュール起動時にモジュールに割り当てるインスタンスの数。

service: my-service
runtime: python37
instance_class: B8
manual_scaling:
  instances: 5

静的キャッシュの有効期限

特に指定のない限り、ウェブプロキシとブラウザは、ウェブサイトから読み込んだファイルを一定期間保持します。

アプリケーションのすべての静的ファイル ハンドラにグローバルなデフォルト キャッシュ期間を定義するには、最上位の default_expiration 要素を追加します。特定の静的ファイル ハンドラにキャッシュ期間を設定することもできます。

有効期限は Cache-ControlExpires HTTP レスポンスで送信されます。ファイルは、ユーザーのブラウザ キャッシュだけでなく、インターネット サービス プロバイダなど、中間のプロキシ サーバーのキャッシュにも保存されます。有効期限付きでファイルが転送された場合、ユーザーは自身のブラウザ キャッシュから消去できますが、中間キャッシュからファイルを消去する方法はありません。アプリの新しいバージョンを再度デプロイしても、キャッシュはリセットされません。静的ファイルを変更する場合には、有効期限は短く(1 時間未満)設定してください。多くの場合、デフォルトの 10 分で十分です。

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

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

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