app.yaml 構成ファイル

app.yaml ファイルでは、ランタイムの構成設定や、一般的なアプリ、ネットワーク、その他のリソース設定を定義します。

.gcloudignore ファイルに app.yaml を追加しないでください。デプロイに app.yaml が必要になる場合があります。また、.gcloudignore に追加すると、デプロイが失敗します。

構文

app.yaml ファイルの構文は YAML 形式です。YAML 形式はコメントをサポートしており、ハッシュ記号（#）で始まる行は無視されます。次に例を示します。

# This is a comment.

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

全般設定

app.yaml ファイルには、次に示す全般的な設定を記述できます。ただし、いくつかの設定は必須です。

service_account: [SERVICE_ACCOUNT_NAME]@[PROJECT_ID].iam.gserviceaccount.com

skip_files:
- ^.*\.bak$

ネットワークの設定

app.yaml 構成ファイルでは、ネットワークの設定は、たとえば次のように指定できます。

network:
  name: NETWORK_NAME
  instance_ip_mode: INSTANCE_IP_MODE
  instance_tag: TAG_NAME
  subnetwork_name: SUBNETWORK_NAME
  session_affinity: true
  forwarded_ports:
    - PORT
    - HOST_PORT:CONTAINER_PORT
    - PORT/tcp
    - HOST_PORT:CONTAINER_PORT/udp

ネットワーク設定を構成する際には、次のオプションを使用できます。

高度なネットワーク構成

Compute Engine のネットワークはサブネットワークに分割できます。これにより、VPN を有効にして、企業ネットワーク内のデータベースにアクセスできます。

App Engine アプリケーションでサブネットワークを有効にするには:

1. カスタム サブネット ネットワークを作成します。

2. 上記のように、ネットワーク名とサブネットワーク名を app.yaml ファイルに追加します。

3. 静的ルーティングに基づいて簡単な VPN を確立する場合は、カスタム サブネット ネットワークにゲートウェイとトンネルを作成します。それ以外の場合は、その他の種類の VPN の作成方法をご覧ください。

ポート転送

ポート転送を行うと、インスタンス上の Docker コンテナに直接接続できます。このトラフィックはどのプロトコルでも転送されます。ポート転送は、デバッガまたはプロファイラを接続する必要がある場合に役立ちます。トラフィックは、appspot.com ドメインまたはカスタム ドメイン経由で送信するのではなく、ターゲット インスタンスの IP アドレスに直接送信する必要があります。

デフォルトでは、ネットワークの外部からの受信トラフィックは、Google Cloud Platform のファイアウォール経由では許可されません。app.yaml ファイルにポート転送を指定した後、使用するポートからのトラフィックを許可するファイアウォール ルールを追加する必要があります。

ファイアウォール ルールは、Google Cloud コンソールの [ネットワーキング] の [ファイアウォール ルール] ページか gcloud コマンドで指定できます。

たとえば、ポート 2222 から TCP トラフィックを転送する場合は、次のようにします。

1. app.yaml のネットワーク設定に次の項目を追加します。

   network:
     forwarded_ports:
       - 2222/tcp
   

   1. Python ランタイムを使用する場合は、app.yaml を変更して以下を追加します。

      entrypoint: gunicorn -b :$PORT -b :2222 main:app
      

2. Google Cloud コンソールまたは gcloud compute firewall-rules create を使用してファイアウォール ルールを指定し、すべての送信元（0.0.0.0/0）と tcp:2222 からのトラフィックを許可します。

リソースの設定

これらの設定は、コンピューティング リソースを制御します。App Engine は、指定した CPU とメモリの量に基づいて、マシンタイプを割り当てます。マシンは少なくとも指定したリソースレベルは確実に満たし、それ以上のリソースを持つこともあります。

リソースの設定では、最大 8 ボリュームの tmpfs を指定できます。tmpfs により、共有メモリを必要とするワークロードを有効化することができ、ファイル システム I/O を改善することができます。

次に例を示します。

resources:
  cpu: 2
  memory_gb: 2.3
  disk_size_gb: 10
  volumes:
  - name: ramdisk1
    volume_type: tmpfs
    size_gb: 0.5

リソースの設定を構成する際には、次のオプションを使用できます。

スプリット ヘルスチェック

デフォルトでは、スプリット ヘルスチェックが有効になっています。定期的なヘルスチェック リクエストを使用すると、VM インスタンスが正常にデプロイされたことを確認できます。また、実行中のインスタンスが正常な状態を維持していることも確認できます。個々のヘルスチェックでは、指定された時間内にレスポンスが返される必要があります。

ヘルスチェック リクエストに対して、指定された回数連続してレスポンスがない場合、インスタンスは異常な状態と見なされます。インスタンスが実行されていない場合、再起動されます。インスタンスが準備できていない場合、クライアント リクエストは処理されません。ディスク容量に空きがない場合も、ヘルスチェックが失敗する場合があります。

次の 2 種類のヘルスチェックを使用できます。

• 実行チェックでは、VM と Docker コンテナが実行中かどうかを確認します。App Engine は異常なインスタンスを再起動します。
• 準備チェックでは、インスタンスが受信リクエストを処理する準備ができているかどうかを確認します。準備チェックに失敗したインスタンスは、使用可能なインスタンスのプールに追加されません。

デフォルトでは、ヘルスチェックからの HTTP リクエストはアプリケーション コンテナに転送されません。ヘルスチェックをアプリケーションにまで拡張するには、実行チェックまたは準備チェックのパスを指定します。アプリケーション用にカスタマイズされたヘルスチェックが 200 OK レスポンス コードを返した場合、正常な状態とみなされます。

実行チェック

実行チェックでは、VM と Docker コンテナが実行中かどうかを確認します。異常と見なされたインスタンスは再起動されます。

オプションの liveness_check セクションを app.yaml ファイルに追加することで、実行チェック リクエストをカスタマイズできます。次に例を示します。

liveness_check:
  path: "/liveness_check"
  check_interval_sec: 30
  timeout_sec: 4
  failure_threshold: 2
  success_threshold: 2

実行チェックでは次の設定を使用できます。

準備チェック

準備チェックでは、インスタンスが受信リクエストを処理できる状態かどうかを確認します。準備チェックに合格していないインスタンスは、使用可能なインスタンスのプールに追加されません。

オプションの readiness_check セクションを app.yaml ファイルに追加することで、ヘルスチェック リクエストをカスタマイズできます。次に例を示します。

readiness_check:
  path: "/readiness_check"
  check_interval_sec: 5
  timeout_sec: 4
  failure_threshold: 2
  success_threshold: 2
  app_start_timeout_sec: 300

準備チェックでは次の設定を使用できます。

ヘルスチェックの頻度

高可用性を確保するため、App Engine は個々のヘルス チェッカーの冗長コピーを作成します。失敗したヘルス チェッカーがあると、遅延なしで冗長ヘルス チェッカーが引き継ぎます。

アプリケーションの nginx.health_check ログを調べると、構成した設定より頻繁にヘルスチェックのポーリングが発生していることがあります。これは、冗長ヘルス チェッカーも設定に従うため発生します。これらの冗長ヘルス チェッカーは自動的に作成され、ユーザーが構成することはできません。

サービス スケーリング設定

サービスのスケーリングを制御するために使用されるキーは、サービスに割り当てるスケーリングのタイプによって異なります。

自動スケーリングか手動スケーリングのいずれかを使用できます。デフォルトは自動スケーリングです。

自動スケーリング

自動スケーリングは、app.yaml ファイルに automatic_scaling セクションを追加することで構成できます。次に例を示します。

automatic_scaling:
  min_num_instances: 1
  max_num_instances: 15
  cool_down_period_sec: 180
  cpu_utilization:
    target_utilization: 0.6
  target_concurrent_requests: 100

次の表には、自動スケーリングで使用できる設定が記載されています。

手動スケーリング

手動スケーリングは、app.yaml ファイルに manual_scaling セクションを追加することで構成できます。次に例を示します。

manual_scaling:
  instances: 5

次の表は、手動スケーリングで使用できる設定を示しています。

環境変数の定義

たとえば、次のように環境変数を app.yaml に定義すると、それをアプリで使用できます。

env_variables:
  MY_VAR: "my value"

ここで、MY_VAR と my value は定義する環境変数の名前と値です。環境変数の各エントリは、env_variables 要素の下でスペース 2 つ分インデントされています。

環境変数の使用