app.yaml 設定檔

app.yaml 檔案定義執行階段的配置設定，以及一般應用程式、網路和其他資源設定。

請勿將 app.yaml 新增至 .gcloudignore 檔案。部署作業可能需要 app.yaml，如果將其新增至 .gcloudignore，部署作業就會失敗。

語法

app.yaml 檔案的語法採用 YAML 格式。YAML 格式支援註解，因此系統會忽略以井字符號 (#) 字元開頭的行列，例如：

# This is a comment.

網址和檔案路徑模式會使用 POSIX 擴充規則運算式語法，但不包括對照元素和對照類別。系統支援對分組相符項目 (例如 \1) 的反向參照，也支援下列擴充項目：\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 容器。此流量能夠通過任何通訊協定。您在需要附加偵錯工具或分析器時，通訊埠轉送就能派上用場。流量必須直接指定為目標執行個體的 IP 位址，而不是透過 appspot.com 網域或您的自訂網域。

根據預設，系統不會允許網路外部的連入流量通過 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 和記憶體大小來指派機器類型。機器保證會具備您指定的資源層級 (可能會更高)。

您在資源設定中最多可指定八個 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 執行個體，以及檢查執行中的執行個體是否維持健康狀態。每項健康狀態檢查都必須在指定的時間間隔內回應。

執行個體無法回應指定次數的連續健康狀態檢查要求時，即表示該執行個體的健康狀態不良。如果執行個體並未執行，則會重新啟動。如果執行個體尚未準備就緒，則不會收到任何用戶端要求。如果沒有可用的磁碟空間，健康狀態檢查要求也會失敗。

健康狀態檢查有兩種類型：

• 有效性檢查可確認 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 元素下方並縮排兩個空格。

使用環境變數