本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# Amazon ECS 服務
<a name="ecs_services"></a>

您可以利用 Amazon ECS 服務在 Amazon ECS 叢集中同時執行並維持指定數目的任務定義執行個體。如果您有任務產生故障或停止，Amazon ECS 服務排程器就會根據您的任務定義啟動另一個執行個體來取而代之。這有助於維持服務中所需的任務數量。

您也可以在負載平衡器後方選擇性地執行您的服務。負載平衡器可將流量分散到與服務關聯的任務。

我們建議將服務排程器用於長時間執行的無狀態服務及應用程式。服務排程器可確保遵循您指定的排程策略，並在任務失敗時重新排程任務。例如，若基本的基礎設施發生故障，服務排程器會重新排程任務。您可以利用任務置放策略和限制條件來自訂排程器如何放置和終止任務。若服務中的任務停止，排程器會啟動新任務進行取代。此流程會根據您服務使用的排程策略持續進行，直至服務執行的任務達到您所需的數量為止。

在容器運作狀態檢查或負載平衡器目標群組運作狀態檢查失敗後，服務排程器也會取代判定為狀況不佳的任務。此取代取決於 `maximumPercent` 和 `desiredCount` 服務定義參數。如果任務標記為運作狀態不佳，服務排程器會先啟動替代任務。然後會發生下列情況。
+ 如果替代任務的運作狀態為 `HEALTHY`，服務排程器會停止運作狀態不良的任務
+ 如果替代任務的運作狀態為 `UNHEALTHY`，排程器會停止運作狀態不佳的替代任務或現有運作狀態不佳的任務，以使任務總計數等於 `desiredCount`。

如果 `maximumPercent` 參數限制排程器先啟動替代任務，排程器會隨機停止運作狀態不佳的任務，以釋放容量，然後啟動替代任務。開始和停止程序會繼續進行，直到所有運作狀態不佳的任務都會取代為運作狀態良好的 一旦已取代了所有運作狀態不佳的任務，而且只執行運作狀態良好的任務，如果任務總數超過 `desiredCount`，則運作良好的任務會隨機停止，直到任務總計數等於 `desiredCount` 為止。如需有關 `maximumPercent` 和 `desiredCount` 的詳細資訊，請參閱[服務定義參數](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service_definition_parameters.html)。

服務排程器包含的邏輯，可在任務重複啟動失敗的情況下，針對任務重新啟動的頻率進行調節。如果任務在未進入 `RUNNING` 的狀態下停止，服務排程器會減少啟動嘗試並傳送出服務事件訊息。此行為可以讓您在問題解決前，避免失敗的任務占用不必要的資源。在服務更新之後，服務排程器就會恢復正常的排程行為。如需詳細資訊，請參閱[Amazon ECS 服務限流邏輯](service-throttle-logic.md)及[檢視 Amazon ECS 服務事件訊息](service-event-messages.md)。

## 基礎結構運算選項
<a name="service-conmpute-options"></a>

分發任務有兩種運算選項。
+ capacity provider strategy (容量供應商策略)，使 Amazon ECS 將您的任務分發至一個或多個容量供應商。

  如果想要在 Amazon ECS 受管執行個體上執行工作負載，必須使用容量提供者策略選項。

  針對**容量提供者策略**，主控台預設會選取運算選項。以下說明主控台用來選擇預設值的順序：
  + 若您的叢集定義了預設容量提供者策略，則會選取該叢集。
  + 如果叢集未定義預設容量提供者策略，但您已將 Fargate 容量提供者新增至叢集，則系統會選取使用 `FARGATE` 容量提供者的自訂容量提供者策略。
  + 如果叢集未定義預設容量提供者策略，但您已將一個或多個 Auto Scaling 群組容量提供者新增至叢集，則系統會選取**使用自訂 (進階)** 選項，並且您需要手動定義策略。
  + 若您的叢集未定義預設容量提供者策略，也沒有為叢集新增容量提供者，則會選擇 Fargate 啟動類型。
+ 啟動類型便於 Amazon ECS 直接在 Fargate 或註冊至叢集的 EC2 執行個體上啟動任務。

  如果想要在 Amazon ECS 受管執行個體上執行工作負載，必須使用容量提供者策略選項。

  依預設，服務會在叢集 VPC 的子網路中啟動。

## 服務自動擴展
<a name="service-auto-scaling-options"></a>

服務自動擴展是一項自動增加或減少 Amazon ECS 服務中所需任務數量的功能。Amazon ECS 利用 Application Auto Scaling 服務來提供此功能。

如需詳細資訊，請參閱[自動擴展您的 Amazon ECS 服務](service-auto-scaling.md)。

## 服務負載平衡
<a name="service-load-balancing-options"></a>

在 上託管的 Amazon ECS 服務 AWS Fargate 支援 Application Load Balancer、Network Load Balancer 和 Gateway Load Balancer。使用下表了解要使用的負載平衡器類型。


| 負載平衡器類型 | 在下列情況下使用 | 
| --- | --- | 
|  Application Load Balancer  | 路由 HTTP/HTTPS (或第 7 層) 流量。Application Load Balancer 提供數種功能，非常適合與 Amazon ECS 服務搭配使用： [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/AmazonECS/latest/developerguide/ecs_services.html) | 
| Network Load Balancer | 路由 TCP 或 UDP (或第 4 層) 流量。 | 
| Gateway Load Balancer | 路由 TCP 或 UDP (或第 4 層) 流量。 使用虛擬應用裝置，如防火牆、入侵偵測與預防系統，以及深層封包檢查系統。 | 

如需詳細資訊，請參閱[使用負載平衡分佈 Amazon ECS 服務流量](service-load-balancing.md)。

## 互連服務
<a name="service-connecting-options"></a>

如果您需要應用程式連線至以 Amazon ECS 服務形式執行的其他應用程式，Amazon ECS 提供以下無需負載平衡器的方法來執行此動作：
+ Service Connect – 允許使用簡短名稱與標準連接埠，實現與自動探索的服務間通訊。
+ 服務探索 – 服務探索使用 Route 53 為服務建立命名空間，以便透過 DNS 進行探索。
+ Amazon VPC Lattice – VPC Lattice 是一種全受管應用程式聯網服務，可用於連線、保護與監控多個帳戶與 VPC 中的服務。使用該服務需要付費。

如需詳細資訊，請參閱[互連 Amazon ECS 服務](interconnecting-services.md)。

# Amazon ECS 服務部署控制器與策略
<a name="ecs_service-options"></a>

部署服務之前，請先確定其部署選項以及服務所使用的功能。

## 排程策略
<a name="service-strategy"></a>

現已推出兩個服務排程器策略概念：
+ `REPLICA` - 複本排程策略會置放並在整個叢集中維持所需的任務數量。根據預設，服務排程器會將任務分散至各個可用區域。您可以使用任務置放策略和限制條件，來自訂任務置放決策。如需詳細資訊，請參閱[複本排程策略](#service_scheduler_replica)。
+ `DAEMON` - 常駐程式排程策略會在每個符合您於叢集中所指定所有任務置放限制條件的作用中容器執行個體上，準確地部署一個任務。使用這項策略時，不需指定所需的任務數量、任務置放策略或使用 Service Auto Scaling 政策。如需詳細資訊，請參閱[常駐程式排程策略](#service_scheduler_daemon)。
**注意**  
Fargate 任務不支援 `DAEMON` 排程策略。

### 複本排程策略
<a name="service_scheduler_replica"></a>

*複本*排程策略會在叢集中放置並維持所需的任務數量。

對於在 Fargate 上執行任務的服務，當服務排程器啟動新任務或停止執行任務時，服務排程器會盡力嘗試在可用區域之間維持平衡。您無須指定任務置放策略或限制條件。

當您在 EC2 執行個體上建立執行任務的服務時，您可以選擇性地指定任務置放策略和限制條件，以自訂任務置放決策。如果未指定任務置放策略或限制，預設情況下，服務排程器會將任務分散到可用區域。服務排程器使用以下邏輯：
+ 決定您叢集中的哪些容器執行個體可支援服務的任務定義 (例如，必要的 CPU、記憶體、連接埠和容器執行個體屬性)。
+ 決定哪些容器執行個體可滿足針對服務所定義的任何置放限制。
+ 當您有取決於常駐程式服務的複本服務時 (例如，必須先執行常駐程式日誌路由器任務，才能使用記錄)，請建立任務置放限制，以確保常駐程式服務任務在複本服務任務之前置放在 EC2 執行個體上。如需詳細資訊，請參閱[Amazon ECS 任務置放限制條件範例](constraint-examples.md)。
+ 如已定義置放策略，請使用該策略從剩餘的待選項目中選取執行個體。
+ 如未定義任何置放策略，請使用下列邏輯平衡您叢集中可用區域的任務：
  + 排序有效的容器執行個體。優先考慮在此服務的個別可用區域中，執行中任務數量最少的執行個體。例如，如果區域 A 有一項執行中的服務任務，而區域 B 和 C 都沒有，則最適合置放的即為區域 B 或 C 中的有效容器執行個體。
  + 根據先前的步驟，將新的服務任務置放在最佳可用區域的有效容器執行個體。偏好此服務執行中任務數量最少的容器執行個體。

建議在使用 `REPLICA` 策略時使用服務重新平衡功能，因為該功能有助於確保服務的高可用性。

### 常駐程式排程策略
<a name="service_scheduler_daemon"></a>

*常駐程式*排程策略會在每個活動容器執行個體上準確部署一個任務，其可滿足叢集中所有指定的任務置放限制條件。服務排程器會評估執行中任務的任務置放限制條件，並會停止不符合置放限制條件的任務。使用此策略時，無需指定所需的任務數量、任務置放策略或使用服務自動擴展政策。

Amazon ECS 會為常駐程式任務保留容器執行個體運算資源，包括 CPU、記憶體和網路介面。當您在具有其他複本服務的叢集上啟動常駐程式服務時，Amazon ECS 會將常駐程式任務設為最優先。這表示常駐程式任務是執行個體上啟動的第一項任務，也是停止所有複本任務後停止的最後一項任務。此策略可確保資源不會被擱置的複本任務使用，且可供常駐程式任務使用。

常駐程式服務排程器不會將任何任務置放於具有 `DRAINING` 狀態的執行個體上。如果容器執行個體轉換為 `DRAINING` 狀態，常駐程式會停止運作。新的容器執行個體加入叢集時，服務排程器也會加以監控，並將常駐程式任務新增到這些執行個體。

指定部署組態時，`maximumPercent` 參數的值必須為 `100` (以百分比形式指定)，如果未設定，則會使用該預設值。`minimumHealthyPercent` 參數的預設值為 `0` (以百分比形式指定)。

當您變更常駐程式服務的置放限制條件時，您必須重新啟動服務。Amazon ECS 會為常駐程式任務動態更新合格執行個體上保留的資源。對於現有執行個體，排程器會嘗試將任務放置在執行個體上。

當任務定義中的任務大小或容器資源保留改變時，會啟動一個新的部署。更新服務或設定任務定義的不同修訂版時，也會啟動新的部署。Amazon ECS 會為常駐程式挑選更新的 CPU 和記憶體保留，然後為常駐程式任務封鎖容量。

若上述任一情境的資源不足，將發生下列情況：
+ 任務置放失敗。
+ 會產生 CloudWatch 事件。
+ Amazon ECS 透過等待資源轉為可用以繼續嘗試與排程執行個體上的任務。
+ Amazon ECS 會釋放任何不再符合置放限制標準的預留執行個體，並且停止對應的常駐程式任務。

常駐程式排程策略可被用於下列情況：
+ 執行應用程式容器
+ 執行支援容器以記錄、監控和追蹤任務

使用 Fargate 或 `CODE_DEPLOY` 或 `EXTERNAL` 部署控制器類型的任務，不支援常駐程式排程策略。

當服務排程器停止執行中的任務時，會嘗試維護叢集中之可用區域間的平衡。排程器使用以下邏輯：
+ 如已定義置放策略，請使用該策略選取要終止的任務。例如，如果服務已定義可用區域分佈策略，則會選取能讓剩餘任務完美分佈的任務。
+ 如未定義任何置放策略，請使用下列邏輯維護叢集中之可用區域的平衡：
  + 排序有效的容器執行個體。優先考慮在此服務的個別可用區域中，擁有最多執行中任務數量的執行個體。例如，如果區域 A 有一項執行中的服務任務，而區域 B 和 C 各有兩項執行中的服務任務，則最適合終止的即為區域 B 或 C 中的容器執行個體。
  + 根據先前的步驟，停止最佳可用區域中容器執行個體上的任務。偏好此服務執行中任務數量最多的容器執行個體。

## 部署控制器
<a name="service_deployment-controllers"></a>

部署控制器是決定服務任務部署方式的機制。有效選項為：
+ ECS

  建立使用 `ECS` 部署控制器的服務時，可以選擇下列部署策略：
  + `ROLLING`：如果建立的服務使用的是*滾動更新* (`ROLLING`) 部署策略，Amazon ECS 服務排程器會使用新任務取代目前執行中的任務。Amazon ECS 在滾動更新期間從服務新增或移除的任務數量是由服務部署組態控制。

    滾動更新部署最適合下列案例：
    + 逐步服務更新：您需要以遞增的方式更新服務，而不要一次讓整個服務離線。
    + 有限資源需求：您希望避免同時執行兩個完整環境的額外資源成本 (藍/綠部署時所需)。
    + 可接受的部署時間：應用程式可接受較長的部署程序，因為滾動更新會逐一取代任務。
    + 無需即時復原：服務可接受復原程序需耗時幾分鐘完成，而非幾秒鐘就完成。
    + 簡單的部署程序：您傾向採取直接的部署方法，省去管理多個環境、目標群組與接聽程式的麻煩。
    + 無需負載平衡器：服務不使用或不需要負載平衡器、Application Load Balancer、Network Load Balancer 或 Service Connect (此為藍/綠部署所需)。
    + 有狀態應用程式：應用程式處於難以執行兩個平行環境的狀態。
    + 成本敏感度：您想要藉由在部署期間不執行重複的環境，盡量減少部署成本。

    滾動更新是服務的預設部署策略，能夠在許多常見的應用程式案例中，於部署安全性與資源效率之間取得平衡。
  + `BLUE_GREEN`：*藍/綠*部署策略 (`BLUE_GREEN`) 是一種發布方法，可透過執行兩個稱為藍色與綠色的相同生產環境來縮短停機時間並降低風險。藉助 Amazon ECS 藍/綠部署，您可以先驗證新的服務修訂版，再將生產流量導向這些修訂版。這種方法提供了一種更安全的變更部署方式，並且能在需要時快速復原。

    Amazon ECS 藍/綠部署最適合下列案例：
    + 服務驗證：需要先驗證新的服務修訂版，再將生產流量導向這些修訂版時
    + 零停機時間：當服務需要零停機時間部署時
    + 即時復原：當您需要能夠在偵測到問題時快速復原時
    + 負載平衡器需求：當服務使用 Application Load Balancer、Network Load Balancer 或 Service Connect 時
  + `LINEAR`：*線性*部署策略 (`LINEAR`) 會逐漸將流量從目前的生產環境轉移到新的環境，在指定的期間內以相等百分比遞增。透過 Amazon ECS 線性部署，您可以控制流量轉移的速度，並透過增加的生產流量來驗證新的服務修訂。

    Amazon ECS 線性部署最適合下列案例：
    + 逐步驗證：當您想要隨著流量增加逐步驗證新的服務版本時
    + 效能監控：當您需要時間在部署期間監控指標和效能時
    + 風險最小化：當您想要透過逐步向生產流量公開新版本來將風險降至最低時
    + 負載平衡器需求：當服務使用 Application Load Balancer、Network Load Balancer 或 Service Connect 時
  + `CANARY`：*Canary* 部署策略 (`CANARY`) 會先將一小部分的流量轉移到新的服務修訂版，然後在指定的時段之後一次轉移剩餘的流量。這可讓您在完全部署之前，使用使用者子集測試新版本。

    Amazon ECS Canary 部署最適合下列案例：
    + 功能測試：當您想要在完全推出前測試一小部分使用者的新功能時
    + 生產驗證：當您需要使用實際生產流量驗證效能和功能時
    + 爆量半徑控制：如果在新版本中發現問題，則您想要將爆量半徑降至最低
    + 負載平衡器需求：當服務使用 Application Load Balancer、Network Load Balancer 或 Service Connect 時
+ 外部

  使用第三方部署控制器。
+ 藍/綠部署 （採用 技術 AWS CodeDeploy)

  CodeDeploy 會將應用程式的更新版本安裝為新的替代任務集，並將生產流量從原始應用程式任務集重新路由至替代任務集。原始任務集會在成功部署後終止。使用此部署控制器在傳送生產流量到服務的新部署之前驗證新部署。

# Amazon ECS 部署失敗偵測
<a name="deployment-failure-detection"></a>

Amazon ECS 提供兩種偵測部署失敗的方法：
+ 部署斷路器
+ CloudWatch 警示

這兩種方法都可以設定為自動將失敗的部署復原至上一個已知的良好狀態。

考慮下列各項：
+ 兩種方法都僅支援滾動更新部署與藍/綠部署類型。
+ 使用這兩種方法時，任一方法都可能觸發部署失敗。
+ 復原方法需要先前處於 COMPLETED 狀態的部署。
+ 系統會針對部署狀態變更產生 EventBridge 事件。

# Amazon ECS 部署斷路器如何偵測失敗
<a name="deployment-circuit-breaker"></a>

部署斷路器是可確定任務是否達到穩定狀態的滾動式更新機制。部署斷路器邏輯有一個選項，可將失敗的部署自動復原至處於 `COMPLETED` 狀態的部署。

當開始服務部署變更狀態時，Amazon ECS 會傳送服務部署狀態變更事件至 EventBridge。這提供一種程式設計方式來監控您的服務部署的狀態。如需詳細資訊，請參閱[Amazon ECS 服務部署狀態變更事件](ecs_service_deployment_events.md)。建議您使用 `SERVICE_DEPLOYMENT_FAILED` 的 `eventName` 建立和監控 EventBridge 規則，以便您可以採取手動動作來啟動部署。如需詳細資訊，請參閱 *Amazon EventBridge User Guide* 中的 [Getting started with EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-get-started.html)。

當部署斷路器判斷部署失敗時，會尋找處於 `COMPLETED` 狀態的最新部署。這是部署斷路器用來做為復原部署的部署。復原開始時，部署會從 `COMPLETED` 變更為 `IN_PROGRESS`。這表示在部署達到 `COMPLETED` 狀態之前，不符合另一個復原的資格。當部署斷路器找不到處於 `COMPLETED` 狀態的部署時，斷路器不會啟動新任務，且會阻礙部署。

建立服務時，排程器會追蹤兩個階段中啟動失敗的任務。
+ 階段 1 – 排程器會監控任務，檢查其是否轉換為 RUNNING 狀態。
  + 成功 – 部署有機會轉換為 COMPLETED 狀態，因為有多項任務已轉換為 RUNNING 狀態。系統會略過失敗條件，且斷路器會移至階段 2。
  + 失敗 – 有連續任務未能轉換為 RUNNING 狀態，且部署可能會轉換為 FAILED 狀態。
+ 階段 2 – 當至少有一項任務處於 RUNNING 狀態時，部署會進入此階段。斷路器會檢查目前部署中正在評估的任務的運作狀態檢查。驗證的運作狀態檢查為 Elastic Load Balancing、 AWS Cloud Map 服務運作狀態檢查和容器運作狀態檢查。
  + 成功 – 至少有一項處於執行中狀態的任務通過了運作狀態檢查。
  + 失敗 – 因運作狀態檢查失敗而被取代的任務達到了失敗閾值。

當您對服務使用部署斷路器方法時，請考量下列事項。EventBridge 產生規則。
+ `DescribeServices` 回應可提供部署狀態洞察，`rolloutState` 和 `rolloutStateReason`。當啟動新的部署時，推展狀態從 `IN_PROGRESS` 狀態開始。當服務到達穩定狀態時，推展狀態轉移到 `COMPLETED`。若服務無法達到穩定狀態，而斷路器已開啟，則部署將轉換為 `FAILED` 狀態。處於 `FAILED` 狀態的部署不會啟動任何新任務。
+ 除 Amazon ECS 為已開始和已完成的部署傳送服務部署狀態變更事件以外，Amazon ECS 還會在開啟的斷路器部署失敗時傳送事件。這些事件提供有關部署失敗原因的詳細資訊，或者部署是否因為回復而開始。如需詳細資訊，請參閱[Amazon ECS 服務部署狀態變更事件](ecs_service_deployment_events.md)。
+ 如果新的部署因為先前的部署失敗並發生復原而開始，服務部署狀態變更事件的 `reason` 欄位將指示部署因為復原而開始。
+ 部署斷路器僅支援使用滾動更新 (`ECS`) 部署控制器的 Amazon ECS 服務。
+ 當您搭配 CloudWatch 選項使用部署斷路器 AWS CLI 時，必須使用 Amazon ECS 主控台或 。如需詳細資訊，請參閱《AWS Command Line Interface 參考》**中的 [使用定義的參數建立服務](create-service-console-v2.md#create-custom-service) 和 [create-service](https://docs.aws.amazon.com/cli/latest/reference/ecs/create-service.html)。

下列`create-service` AWS CLI 範例顯示當部署斷路器與復原選項搭配使用時，如何建立 Linux 服務。

```
aws ecs create-service \
     --service-name MyService \
     --deployment-controller type=ECS \
     --desired-count 3 \
     --deployment-configuration "deploymentCircuitBreaker={enable=true,rollback=true}" \
     --task-definition sample-fargate:1 \
     --launch-type FARGATE \
     --platform-family LINUX \
     --platform-version 1.4.0 \
     --network-configuration "awsvpcConfiguration={subnets=[subnet-12344321],securityGroups=[sg-12344321],assignPublicIp=ENABLED}"
```

範例：

部署 1 處於 `COMPLETED` 狀態。

部署 2 無法啟動，因此斷路器會復原至部署 1。部署 1 會轉換至 `IN_PROGRESS` 狀態。

部署 3 會啟動，且 `COMPLETED` 狀態中沒有部署，因此部署 3 無法復原或啟動任務。

## Failure threshold
<a name="failure-threshold"></a>

部署斷路器會計算閾值，然後使用該值判斷何時將部署移動到 `FAILED` 狀態。

部署斷路器的最小閾值為 3，最大閾值為 200。 會使用下列公式中的值來判斷部署失敗。

```
Minimum threshold <= 0.5 * desired task count => maximum threshold
```

當計算結果大於最小值 3，但小於最大值 200 時，失敗閾值會設定為計算閾值 （四捨五入）。

**注意**  
您不能更改任何一個閾值。

部署狀態檢查有兩個階段。

1. 部署斷路器監視部署過程中的任務，並檢查處於 `RUNNING` 狀態的任務。當目前部署中的任務處於 `RUNNING` 狀態時，排程器會忽略故障條件，並繼續進行到下一個階段。當任務無法到達 `RUNNING` 狀態時，部署斷路器會在故障計數上增加一。當故障計數等於閾值時，部署將標記為 `FAILED`。

1. 如果一項或多項任務處於 `RUNNING` 狀態，則會進入此階段。部署斷路器對目前部署中的任務，針對以下資源執行運作狀態檢查：
   + Elastic Load Balancing 負載平衡器
   + AWS Cloud Map 服務
   + Amazon ECS 容器運作狀態檢查

   當任務的運作狀態檢查失敗時，部署斷路器會在故障計數上增加一。當故障計數等於閾值時，部署將標記為 `FAILED`。

下表提供一些範例。


| 所需的任務計數 | 計算 | Threshold | 
| --- | --- | --- | 
|  1  |  <pre>3 <= 0.5 * 1 => 200</pre>  | 3 （計算值小於最小值） | 
|  25  |  <pre>3 <= 0.5 * 25 => 200</pre>  | 13 (值會無條件進位) | 
|  400  |  <pre>3 <= 0.5 * 400 => 200</pre>  | 200 | 
|  800  |  <pre>3 <= 0.5 * 800 => 200</pre>  | 200 (計算值大於最大值) | 

例如，當閾值為 3 時，斷路器會從失敗計數設定為 0 開始。當任務未能達到 `RUNNING` 狀態時，部署斷路器會在失敗計數上增加一。當失敗計數等於 3 時，部署將標記為 `FAILED`。

如需有關使用復原選項的其他範例，請參閱 [Announcing Amazon ECS deployment circuit breaker](https://aws.amazon.com/blogs/containers/announcing-amazon-ecs-deployment-circuit-breaker/) (推出 Amazon ECS 部署斷路器)。

# CloudWatch 警示如何偵測 Amazon ECS 部署失敗
<a name="deployment-alarm-failure"></a>

您可以設定 Amazon ECS，以便在其偵測到指定的 CloudWatch 警示已進入 `ALARM` 狀態時，將部署設定為失敗。

您可以選擇性地設定組態，將失敗的部署復原至上次完成的部署。

下列`create-service` AWS CLI 範例顯示當部署警示與復原選項搭配使用時，如何建立 Linux 服務。

```
aws ecs create-service \
     --service-name MyService \
     --deployment-controller type=ECS \
     --desired-count 3 \
     --deployment-configuration "alarms={alarmNames=[alarm1Name,alarm2Name],enable=true,rollback=true}" \
     --task-definition sample-fargate:1 \
     --launch-type FARGATE \
     --platform-family LINUX \
     --platform-version 1.4.0 \
     --network-configuration "awsvpcConfiguration={subnets=[subnet-12344321],securityGroups=[sg-12344321],assignPublicIp=ENABLED}"
```

當您對服務使用 Amazon CloudWatch 警示方式時，請考量下列事項。
+ 在生產流量轉移後，藍色與綠色服務修訂版同時執行的持續時間。Amazon ECS 會根據與部署相關聯的警示組態來計算此時段。您無法設定此值。
+ `deploymentConfiguration` 請求參數現在包含 `alarms` 資料類型。您可以指定警示名稱、是否使用該方法，以及是否在警示指出部署失敗時初始化復原。如需詳細資訊，請參閱《Amazon Elastic Container Service API 參考》**中的 [CreateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateService.html)。
+ `DescribeServices` 回應可提供部署狀態洞察，`rolloutState` 和 `rolloutStateReason`。當啟動新的部署時，推展狀態從 `IN_PROGRESS` 狀態開始。當服務達到穩定狀態且封裝時間完成時，推展狀態轉換為 `COMPLETED`。若服務無法達到穩定狀態，而警示已進入 `ALARM` 狀態，部署將轉換為 `FAILED` 狀態。處於 `FAILED` 狀態的部署不會啟動任何新任務。
+ 除 Amazon ECS 為已開始和已完成的部署傳送服務部署狀態變更事件以外，Amazon ECS 還會在使用警示的部署失敗時傳送事件。這些事件提供有關部署失敗原因的詳細資訊，或者部署是否因為回復而開始。如需詳細資訊，請參閱[Amazon ECS 服務部署狀態變更事件](ecs_service_deployment_events.md)。
+ 如果新的部署因為先前的部署失敗並已開啟復原而開始，服務部署狀態變更事件的 `reason` 欄位將指示部署因為復原而開始。
+ 如果您使用部署斷路器和 Amazon CloudWatch 警示來偵測失敗，則任何一種方法都可以在符合任一方法的條件後立即初始化部署失敗。當您對初始化部署失敗的方法使用復原選項時，就會發生復原。
+ Amazon CloudWatch 警示僅支援使用滾動更新 (`ECS`) 部署控制器的 Amazon ECS 服務。
+ 您可以使用 Amazon ECS 主控台或 AWS CLI來設定此選項。如需詳細資訊，請參閱《AWS Command Line Interface 參考》**中的 [使用定義的參數建立服務](create-service-console-v2.md#create-custom-service) 和 [create-service](https://docs.aws.amazon.com/cli/latest/reference/ecs/create-service.html)。
+ 您可能會注意到，部署狀態會維持 `IN_PROGRESS` 較長的時間。其原因是 Amazon ECS 在刪除作用中的部署之前不會變更狀態，並且直到封裝時間過後才會發生這種情況。視警示組態而定，部署需要的時間可能比您不使用警示多幾分鐘 (即使新的主要任務集已縱向擴展，而舊的部署也縮減規模)。如果您使用 CloudFormation 逾時，請考慮增加逾時。如需詳細資訊，請參閱《AWS CloudFormation 使用者指南》**中的[在範本中建立等待條件](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-waitcondition.html)。
+ Amazon ECS 呼叫 `DescribeAlarms` 以輪詢警示。對 `DescribeAlarms` 的呼叫會計入與您帳戶相關聯的 CloudWatch 服務配額。如果您有其他呼叫 AWS 的服務`DescribeAlarms`，可能會對 Amazon ECS 輪詢警示造成影響。例如，如果其他服務發出的 `DescribeAlarms` 呼叫數量足以達到配額，則該服務會受到限流，Amazon ECS 也會受到限流，而且無法輪詢警示。如果在限流期間產生警示，Amazon ECS 可能會遺漏警示，且可能不會發生復原。針對部署沒有其他影響。如需 CloudWatch 服務配額的詳細資訊，請參閱《CloudWatch 使用者指南》**中的 [CloudWatch 服務配額](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_limits.htm)。
+ 如果警示在部署開始時處於 `ALARM` 狀態，Amazon ECS 將不會在部署期間監控警示 (Amazon ECS 會忽略警示組態)。此行為可處理您要啟動新部署以修正初始部署失敗的情況。

## 建議的警示
<a name="ecs-deployment-alarms"></a>

我們建議您使用下列警示指標：
+ 如果您使用 Application Load Balancer，請使用 `HTTPCode_ELB_5XX_Count` 和 `HTTPCode_ELB_4XX_Count` Application Load Balancer 指標。這些指標會檢查 HTTP 峰值。如需有關 Application Load Balancer 指標的詳細資訊，請參閱《Application Load Balancer 使用者指南》**中的 [Application Load Balancer 的 CloudWatch 指標](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-cloudwatch-metrics.html)。
+ 如果您有現有的應用程式，請使用 `CPUUtilization` 和 `MemoryUtilization` 指標。這些指標會檢查叢集或服務使用的 CPU 和記憶體的百分比。如需詳細資訊，請參閱[考量事項](cloudwatch-metrics.md#enable_cloudwatch)。
+ 如果您在任務中使用 Amazon Simple Queue Service 佇列，請使用 `ApproximateNumberOfMessagesNotVisible` Amazon SQS 指標。此指標會檢查佇列中延遲且無法立即讀取的訊息數量。如需有關 Amazon SQS 指標的詳細資訊，請參閱《Amazon Simple Queue Service 開發人員指南》**中的[適用於 Amazon SQS 的 CloudWatch 指標](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-available-cloudwatch-metrics.html)。

## 封裝時間
<a name="deployment-bake-time"></a>

為服務部署使用復原選項時，Amazon ECS 會在目標服務修訂版部署完成後，多等待一段時間，然後才傳送 CloudWatch 警示。這段時間稱為封裝時間。此時間將於下列情況之後開始：
+ 目標服務修訂版的所有任務都在執行中，且運作狀態良好
+ 來源服務修訂版規模縮減至 0%

預設的封裝時間少於 5 分鐘。封裝時間過期後，服務部署會標示為完成。

您可以為滾動部署設定封裝時間。使用 CloudWatch 警示來偵測失敗時，如果變更了封裝時間，之後卻希望使用 Amazon ECS 預設值，則必須手動設定封裝時間。

# Amazon ECS 服務部署的 lifecycle hook
<a name="deployment-lifecycle-hooks"></a>

部署開始後，會經歷多個生命週期階段。這些階段可能處於 IN\$1PROGRESS 或成功等狀態。您可以使用 lifecycle hook，這是 Amazon ECS 在指定生命週期階段代表您執行的 Lambda 函式。這些函式可以是下列其中一項：
+ 非同步 API，可在 15 分鐘內驗證運作狀態檢查。
+ 輪詢 API，會啟動另一個非同步程序來評估 lifecycle hook 完成情況。

函式執行完成後，必須傳回 `hookStatus`，部署才能繼續。如果未傳回 `hookStatus`，或函式執行失敗，部署將會復原。以下為 `hookStatus` 的值：
+ `SUCCEEDED` – 部署會繼續進入下一個生命週期階段
+ `FAILED` – 部署會復原至上次成功的部署。
+ `IN_PROGRESS` – Amazon ECS 會在短時間內再次執行函式。預設時間間隔為 30 秒，但此值可透過在傳回 `hookStatus` 時同時傳回 `callBackDelay` 進行自訂。

下列範例說明如何傳回具有自訂復原延遲的 `hookStatus`。在此範例中，Amazon ECS 會在 60 秒 (而不是預設的 30 秒) 內重試此勾點：

```
{
    "hookStatus": "IN_PROGRESS",
    "callBackDelay": 60
}
```

發生復原時，Amazon ECS 會為下列生命週期階段執行 lifecycle hook：
+ PRODUCTION\$1TRAFFIC\$1SHIFT
+ TEST\$1TRAFFIC\$1SHIFT

## 生命週期承載
<a name="service-deployment-lifecycle-payloads"></a>

 為 ECS 服務部署設定 lifecycle hook 時，Amazon ECS 會在部署程序的特定階段調用這些勾點。每個生命週期階段都會提供 JSON 承載，其中包含有關目前部署狀態的資訊。本文件主要介紹每個生命週期階段的承載結構。

### 常見的承載結構
<a name="common-payload-structure"></a>

 所有生命週期階段承載都包含下列常見欄位：
+  `serviceArn` – 服務的 Amazon Resource Name (ARN)。
+  `targetServiceRevisionArn` – 正在部署的目標服務修訂版的 ARN。
+  `testTrafficWeights` – 服務修訂版 ARN 對其對應測試流量權重百分比的映射。
+  `productionTrafficWeights` – 服務修訂版 ARN 對其對應生產流量權重百分比的映射。

### 生命週期階段承載
<a name="lifecycle-stage-payloads"></a>

#### RECONCILE\$1SERVICE
<a name="reconcile-service"></a>

 此階段發生在部署程序開始時 (即正在協調服務時)。下列顯示此生命週期階段的範例承載。

```
{
  "serviceArn": "arn:aws:ecs:us-west-2:1234567890:service/myCluster/myService",
  "targetServiceRevisionArn": "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892",
  "testTrafficWeights": {
    "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892": 100,
    "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/78652123": 0
  },
  "productionTrafficWeights": {
    "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892": 100,
    "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/78652123": 0
  }
}
```

 **此階段的預期狀態：**
+ 主要任務集規模為 0%

#### PRE\$1SCALE\$1UP
<a name="pre-scale-up"></a>

 此階段發生在新任務向上擴展之前。下列顯示此生命週期階段的範例承載。

```
{
  "serviceArn": "arn:aws:ecs:us-west-2:1234567890:service/myCluster/myService",
  "targetServiceRevisionArn": "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892",
  "testTrafficWeights": {},
  "productionTrafficWeights": {}
}
```

 **此階段的預期狀態：**
+ 綠色服務修訂版任務規模為 0%

#### POST\$1SCALE\$1UP
<a name="post-scale-up"></a>

 此階段發生在新任務向上擴展且運作狀態良好之後。下列顯示此生命週期階段的範例承載。

```
{
  "serviceArn": "arn:aws:ecs:us-west-2:1234567890:service/myCluster/myService",
  "targetServiceRevisionArn": "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892",
  "testTrafficWeights": {},
  "productionTrafficWeights": {}
}
```

 **此階段的預期狀態：**
+ 綠色服務修訂版任務規模為 100%
+ 綠色服務修訂版中的任務運作狀態良好

#### TEST\$1TRAFFIC\$1SHIFT
<a name="test-traffic-shift"></a>

 此階段發生在測試流量在轉移到綠色服務修訂版任務時。

下列顯示此生命週期階段的範例承載。

```
{
  "serviceArn": "arn:aws:ecs:us-west-2:1234567890:service/myCluster/myService",
  "targetServiceRevisionArn": "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892",
  "testTrafficWeights": {
    "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892": 100,
    "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/78652123": 0
  },
  "productionTrafficWeights": {}
}
```

 **此階段的預期狀態：**
+ 測試流量正在流向綠色服務修訂版任務。

#### POST\$1TEST\$1TRAFFIC\$1SHIFT
<a name="post-test-traffic-shift"></a>

 此階段發生在測試流量完全轉移到新任務之後。

下列顯示此生命週期階段的範例承載。

```
{
  "serviceArn": "arn:aws:ecs:us-west-2:1234567890:service/myCluster/myService",
  "targetServiceRevisionArn": "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892",
  "testTrafficWeights": {},
  "productionTrafficWeights": {}
}
```

 **此階段的預期狀態：**
+ 100% 的測試流量已流向綠色服務修訂版任務。

#### PRODUCTION\$1TRAFFIC\$1SHIFT
<a name="production-traffic-shift"></a>

 此階段發生在生產流量轉在移到綠色服務修訂版任務時。

```
{
  "serviceArn": "arn:aws:ecs:us-west-2:1234567890:service/myCluster/myService",
  "targetServiceRevisionArn": "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892",
  "testTrafficWeights": {},
  "productionTrafficWeights": {
    "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892": 100,
    "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/78652123": 0
  }
}
```

 **此階段的預期狀態：**
+ 生產流量正在流向綠色服務修訂版。

#### POST\$1PRODUCTION\$1TRAFFIC\$1SHIFT
<a name="post-production-traffic-shift"></a>

 此階段發生在生產流量完全轉移到綠色服務修訂版任務之後。

```
{
  "serviceArn": "arn:aws:ecs:us-west-2:1234567890:service/myCluster/myService",
  "targetServiceRevisionArn": "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892",
  "testTrafficWeights": {},
  "productionTrafficWeights": {}
}
```

 **此階段的預期狀態：**
+ 100% 的生產流量已流向綠色服務修訂版任務。

### 生命週期階段類別
<a name="lifecycle-stage-categories"></a>

 生命週期階段分為兩個類別：

1.  **單次調用階段** – 這些階段在服務部署期間僅調用一次：
   + PRE\$1SCALE\$1UP
   + POST\$1SCALE\$1UP
   + POST\$1TEST\$1TRAFFIC\$1SHIFT
   + POST\$1PRODUCTION\$1TRAFFIC\$1SHIFT

1.  **重複調用階段** – 這些階段在服務部署期間可能會多次調用，例如發生復原操作時：
   + TEST\$1TRAFFIC\$1SHIFT
   + PRODUCTION\$1TRAFFIC\$1SHIFT

### Lifecycle hook 期間的部署狀態
<a name="deployment-status-during-lifecycle-hooks"></a>

 Lifecycle hook 執行期間，所有生命週期階段的部署狀態都將是 `IN_PROGRESS`。


| 生命週期狀態 | 部署狀態 | 
| --- | --- | 
| RECONCILE\$1SERVICE | IN\$1PROGRESS | 
| PRE\$1SCALE\$1UP | IN\$1PROGRESS | 
| POST\$1SCALE\$1UP | IN\$1PROGRESS | 
| TEST\$1TRAFFIC\$1SHIFT | IN\$1PROGRESS | 
| POST\$1TEST\$1TRAFFIC\$1SHIFT | IN\$1PROGRESS | 
| PRODUCTION\$1TRAFFIC\$1SHIFT | IN\$1PROGRESS | 
| POST\$1PRODUCTION\$1TRAFFIC\$1SHIFT | IN\$1PROGRESS | 

# 停止 Amazon ECS 服務部署
<a name="stop-service-deployment"></a>

當斷路器或 CloudWatch 警示未偵測到失敗的部署時，可以手動停止部署。以下為可用的停止類型：
+ 復原 – 此選項會將服務部署復原至先前的服務修訂版。

  即使您未將服務部署設定為使用復原選項，仍可使用此選項。

您可以停止處於下列任何狀態的部署。如需有關服務部署狀態的詳細資訊，請參閱[使用 Amazon ECS 服務部署檢視服務歷史記錄](service-deployment.md)。
+ PENDING – 服務部署會移至 ROLLBACK\$1REQUESTED 狀態，然後開始復原操作。
+ IN\$1PROGRESS – 服務部署會移至 ROLLBACK\$1REQUESTED 狀態，然後開始復原操作。
+ STOP\$1REQUESTED – 服務部署會繼續停止。
+ ROLLBACK\$1REQUESTED – 服務部署會繼續復原操作。
+ ROLLBACK\$1IN\$1PROGRESS – 服務部署會繼續復原操作。

## 程序
<a name="stop-service-deployment-procedure"></a>

開始之前，請先設定檢視服務部署所需的許可。如需詳細資訊，請參閱[檢視 Amazon ECS 服務部署所需的許可](service-deployment-permissions.md)。

------
#### [ Amazon ECS Console ]

1. 開啟主控台，網址為 [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)。

1. 在**叢集**頁面上，選擇叢集。

1. 在「叢集詳細資訊」頁面上的**服務**區段中，選擇所需服務。

   服務詳細資訊頁面隨即顯示。

1. 在服務詳細資訊頁面上，選擇**部署**。

   部署頁面隨即顯示。

1. 在**正在進行的部署**下，選擇**復原**。然後在確認視窗中，選擇**復原**。

------
#### [ AWS CLI ]

1. 執行 `list-service-deployments` 以擷取服務部署 ARN。

   將 *user-input* 取代為實際值。

   ```
   aws ecs list-service-deployments --cluster cluster-name --service service-name
   ```

   記下要停止的部署的 `serviceDeploymentArn`。

   ```
   {
       "serviceDeployments": [
           {
               "serviceDeploymentArn": "arn:aws:ecs:us-west-2:123456789012:service-deployment/cluster-name/service-name/NCWGC2ZR-taawPAYrIaU5",
               "serviceArn": "arn:aws:ecs:us-west-2:123456789012:service/cluster-name/service-name",
               "clusterArn": "arn:aws:ecs:us-west-2:123456789012:cluster/cluster-name",
               "targetServiceRevisionArn": "arn:aws:ecs:us-west-2:123456789012:service-revision/cluster-name/service-name/4980306466373577095",
               "status": "SUCCESSFUL"
           }
       ]
   }
   ```

1. 執行 `stop-service-deployments`。使用從 `list-service-deployments` 傳回的 `serviceDeploymentArn`。

   將 *user-input* 取代為實際值。

   ```
   aws ecs stop-service-deployment --service-deployment-arn arn:aws:ecs:region:123456789012:service-deployment/cluster-name/service-name/NCWGC2ZR-taawPAYrIaU5 --stop-type ROLLBACK
   ```

------

## 後續步驟
<a name="stop-service-deployment-next-step"></a>

決定需要對服務進行哪些變更，然後更新服務。如需詳細資訊，請參閱[更新 Amazon ECS 服務](update-service-console-v2.md)。

# 透過取代任務來部署 Amazon ECS 服務
<a name="deployment-type-ecs"></a>

如果建立的服務使用的是*滾動更新* (`ECS`) 部署類型，Amazon ECS 服務排程器會使用新任務取代目前執行中的任務。Amazon ECS 在滾動更新期間從服務新增或移除的任務數量是由服務部署組態控制。

Amazon ECS 使用下列參數來決定任務數量：
+ `minimumHealthyPercent` 代表在滾動部署期間或容器執行個體耗盡時，應為服務執行且運作狀態良好的任務數量下限，以服務所需任務數量的百分比表示。此值會向上捨入。例如，如果最小運作狀態良好的百分比為 `50`，且所需的任務計數為 4，則排程器可以先停止兩項現有的任務，再開始兩項新的任務。同樣地，如果最小運作狀態良好的百分比為 75%，而所需的任務計數為 2，則排程器無法停止任何任務，因為產生的值也是 2。
+ `maximumPercent` 代表在滾動部署期間或容器執行個體耗盡時，應為服務執行的任務數量上限，以服務所需任務數量的百分比表示。此值會向下捨去。例如，如果最大百分比為 ，`200`而所需的任務計數為 4，則排程器可以在停止四個現有任務之前啟動四個新任務。同樣地，如果最大百分比為 `125`，且所需的任務計數為 3，則排程器無法停止任何任務，因為產生的值也是 3。

在滾動部署期間，當任務運作狀態不佳時，Amazon ECS 會取代它們，以維護您服務的 `minimumHealthyPercent` 並保護可用性。運作狀態不佳的任務會使用其所屬的相同服務修訂來取代。這可確保來源修訂版中運作狀態不佳的任務替換與目標修訂版中的任務失敗無關。當`maximumPercent`設定允許時，排程器會在停止運作狀態不佳的任務之前啟動替代任務。如果 `maximumPercent` 參數限制排程器先啟動取代任務，排程器會一次停止一個運作狀態不佳的任務，以在啟動取代任務之前釋放容量。

**重要**  
設定最小運作狀態良好的百分比或最大百分比時，您應確定排程器在部署初始化時，可以停止或啟動至少一項任務。如果您的服務部署因無效的部署組態而停滯，將傳送服務事件簡訊。如需詳細資訊，請參閱[服務 (*service-name*) 在部署期間因服務部署組態而無法停止或啟動任務。更新 minimumHealthyPercent 或 maximumPercent 值，然後再試一次。](service-event-messages-list.md#service-event-messages-7)。

滾動部署有兩種方法，有助於快速識別服務部署何時失敗：
+ [Amazon ECS 部署斷路器如何偵測失敗](deployment-circuit-breaker.md)
+ [CloudWatch 警示如何偵測 Amazon ECS 部署失敗](deployment-alarm-failure.md)

可以單獨使用或一起使用這些方法。同時使用兩種方法時，只要符合任一失敗方法的失敗條件，就會將部署設定為失敗。

請遵循下列準則來協助判斷要使用的方法：
+ 斷路器 – 當您想要在任務無法啟動而停止部署時，請使用此方法。
+ CloudWatch 警示 – 當您想要根據應用程式指標停止部署時，請使用此方法。

這兩種方法都支援復原至先前的服務修訂版。

## 容器映像解析
<a name="deployment-container-image-stability"></a>

依預設，Amazon ECS 會將任務定義中指定的容器映像標籤解析為容器映像摘要。如果您建立的服務執行並維護單一任務，則該任務將用於建立任務中容器的映像摘要。如果您建立的服務執行並維護多項任務，則服務排程器在部署期間啟動的第一項任務將用於建立這些任務中容器的映像摘要。

如果三次或多次嘗試建立容器映像摘要失敗，則部署將在不進行映像摘要解析的情況下繼續。如果啟用了部署斷路器，則部署將額外標記為失敗並得到復原。

建立容器映像摘要之後，Amazon ECS 會使用摘要來啟動任何其他所需的任務，以及進行任何未來的服務更新。這會導致服務中的所有任務始終執行相同的容器映像，從而確保軟體的版本一致性。

您可以使用容器定義中的 `versionConsistency` 參數，為任務中的每個容器設定此行為。如需詳細資訊，請參閱[versionConsistency](task_definition_parameters.md#ContainerDefinition-versionconsistency)。

**注意**  
低於 `1.31.0` 的 Amazon ECS 代理程式版本不支援映像摘要解析。`1.31.0` 至 `1.69.0` 的代理程式版本僅支援解析推送至 Amazon ECR 儲存庫之映像的摘要。`1.70.0` 或更高版本的代理程式版本支援解析所有映像的摘要。
用於映像摘要解析的最低 Fargate Linux 平台版本為 `1.3.0`。用於映像摘要解析的最低 Fargate Windows 平台版本為 `1.0.0`。
Amazon ECS 不會擷取 Amazon ECS 管理的邊車容器摘要，例如 Amazon GuardDuty 安全代理程式或 Service Connect Proxy。
若要在具有多項任務的服務中降低與容器映像解析相關聯的潛在延遲，請在 EC2 容器執行個體上執行 Amazon ECS 代理程式 `1.83.0` 或更高版本。若要避免潛在延遲，請在任務定義中指定容器映像摘要。
如果您建立所需任務計數為零的服務，則在您觸發另一次所需任務計數大於零的服務部署之前，Amazon ECS 無法建立容器摘要。
若要建立更新後的映像摘要，您可以強制執行新部署。更新後的摘要將用於啟動新任務，不會影響已在執行的任務。如需有關強制執行新部署的詳細資訊，請參閱 *Amazon ECS API reference* 中的 [forceNewDeployment](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html#ECS-UpdateService-request-forceNewDeployment)。
使用 EC2 容量提供者時，如果在初始部署期間沒有足夠的容量來啟動任務，軟體版本一致性可能會失敗。為確保即使容量有限也能維持版本一致性，請在任務定義容器組態中明確設定 `versionConsistency: "enabled"`，而不是依賴預設行為。這會導致 Amazon ECS 等待容量變為可用，然後再繼續部署。

# Amazon ECS 服務參數最佳實務
<a name="service-options"></a>

為確保應用程式零停機時間，部署程序如下：

1. 啟動新的應用程式容器，同時讓現有容器保持執行狀態。

1. 檢查新容器是否正常運作。

1. 停止舊容器。

 根據部署組態與叢集中可用、未預留的空間量，可能需要多次重複此程序才能完成以新任務取代所有舊任務的工作。

可以使用下列兩種服務組態選項來修改任務數量：
+ `minimumHealthyPercent`：100% (預設)

  服務在部署期間必須保持在 `RUNNING` 狀態的任務數量下限。此值是無條件進位到最接近整數的 `desiredCount` 的百分比。此參數可讓您不使用額外的叢集容量進行部署。
+ `maximumPercent`：200% (預設)

   服務在部署期間允許保持在 `RUNNING` 或 `PENDING` 狀態的任務數量上限。此值是無條件捨去到最接近整數的 `desiredCount` 的百分比。

**範例：預設組態選項**

假設下列服務具有六項任務，部署在總共可容納八項任務的叢集中。預設服務組態選項不允許部署低於六個所需任務的 100%。

部署程序如下：

1. 目標是取代六項任務。

1. 排程器會啟動兩項新任務，因為預設設定要求必須有六項執行中任務。

   現在有六項現有任務與兩項新任務。

1. 排程器會停止兩項現有任務。

   現在有四項現有任務與兩項新任務。

1. 排程器會再啟動兩項新任務。

   現在有四項現有任務與四項新任務。

1. 排程器會關閉兩項現有任務。

   現在有兩項現有任務與四項新任務。

1. 排程器會再啟動兩項新任務。

   現在有兩項現有任務與六項新任務

1. 排程器會關閉最後兩項現有任務。

   現在有六項新任務。

在上述範例中，如果使用選項的預設值，則需要等待 2.5 分鐘，才能啟動每項新任務。此外，負載平衡器可能必須等待 5 分鐘，舊任務才能停止。

**範例：修改 `minimumHealthyPercent`**

您可以將 `minimumHealthyPercent` 值設定為 50%，以加速部署。

假設下列服務具有六項任務，部署在總共可容納八項任務的叢集中。部署程序如下：

1. 目標是取代六項任務。

1. 排程器會停止三項現有任務。

   仍有三項現有任務在執行中，符合 `minimumHealthyPercent` 值。

1. 排程器會啟動五項新任務。

   現在有三項現有任務與五項新任務。

1. 排程器會停止剩餘的三項現有任務。

   現在有五項新任務

1. 排程器會啟動最後一項新任務。

   現在有六項新任務。

**範例：修改叢集可用空間**

您也可以新增額外的可用空間，以便執行更多任務。

假設下列服務具有六項任務，部署在總共可容納十項任務的叢集中。部署程序如下：

1. 目標是取代現有任務。

1. 排程器會停止三項現有任務，

   現在有三項現有任務。

1. 排程器會啟動六項新任務。

   現在有三項現有任務與六項新任務

1. 排程器會停止三項現有任務。

   現在有六項新任務。

**建議**

如果任務閒置一段時間且使用率不高，請針對服務組態選項使用下列值。
+ `minimumHealthyPercent`：50%
+ `maximumPercent`：200% 

# 建立 Amazon ECS 滾動更新部署
<a name="create-service-console-v2"></a>

建立服務，以在叢集中同時執行並維持指定數量的任務定義執行個體。如果您有任務產生故障或停止，Amazon ECS 服務排程器就會根據您的任務定義啟動另一個執行個體來取而代之。這有助於維持服務中所需的任務數量。

建立服務之前，請先決定下列組態參數：
+ 分發任務有兩種運算選項。
  + **capacity provider strategy** (容量供應商策略)，使 Amazon ECS 將您的任務分發至一個或多個容量供應商。

    如果想要在 Amazon ECS 受管執行個體上執行工作負載，必須使用容量提供者策略選項。
  + **啟動類型**便於 Amazon ECS 直接在 Fargate 或註冊至叢集的 EC2 執行個體上啟動任務。

    如果想要在 Amazon ECS 受管執行個體上執行工作負載，必須使用容量提供者策略選項。
+ 使用 `awsvpc` 網路模式的任務定義或被設定使用負載平衡器的服務必須有聯網組態。根據預設，主控台會在預設的 Amazon VPC 中選擇預設的 Amazon VPC，以及全部子網路和預設安全群組。
+ 置放策略，預設任務置放策略會將任務均勻分佈到可用區域。

  建議使用可用區域重新平衡，以協助確保服務的高可用性。如需詳細資訊，請參閱[在可用區域之間平衡 Amazon ECS 服務](service-rebalancing.md)。
+ 當您使用 **Launch Type** (啟動類型) 進行服務部署時，服務預設會在叢集 VPC 的子網路中啟動。
+ 針對 **capacity provider strategy** (容量提供者策略)，主控台預設會選取運算選項。以下說明主控台用來選擇預設值的順序：
  + 若您的叢集定義了預設容量提供者策略，則會選取該叢集。
  + 如果叢集未定義預設容量提供者策略，但您已將 Fargate 容量提供者新增至叢集，則系統會選取使用 `FARGATE` 容量提供者的自訂容量提供者策略。
  + 如果叢集未定義預設容量提供者策略，但您已將一個或多個 Auto Scaling 群組容量提供者新增至叢集，則系統會選取**使用自訂 (進階)** 選項，並且您需要手動定義策略。
  + 若您的叢集未定義預設容量提供者策略，也沒有為叢集新增容量提供者，則會選擇 Fargate 啟動類型。
+ 部署失敗偵測的預設選項是搭配**失敗時復原**選項使用 **Amazon ECS 部署斷路器**選項。

  如需詳細資訊，請參閱[Amazon ECS 部署斷路器如何偵測失敗](deployment-circuit-breaker.md)。
+ 決定是否希望 Amazon ECS 自動增加或減少服務中所需的任務數量。如需相關資訊，請參閱[自動擴展您的 Amazon ECS 服務](service-auto-scaling.md)。
+ 如果您需要應用程式連線到在 Amazon ECS 中執行的其他應用程式，請確定適合您架構的選項。如需詳細資訊，請參閱[互連 Amazon ECS 服務](interconnecting-services.md)。
+ 建立使用 Amazon ECS 斷路器的服務時，Amazon ECS 會建立服務部署與服務修訂版。這些資源可用於檢視服務歷史記錄的詳細資訊。如需詳細資訊，請參閱[使用 Amazon ECS 服務部署檢視服務歷史記錄](service-deployment.md)。

  如需有關如何使用 建立服務的資訊 AWS CLI，請參閱《 *AWS Command Line Interface 參考*[https://docs.aws.amazon.com/cli/latest/reference/ecs/create-service.html](https://docs.aws.amazon.com/cli/latest/reference/ecs/create-service.html)》中的 。

  如需有關如何使用 建立服務的資訊 AWS CloudFormation，請參閱*AWS CloudFormation 《 使用者指南*[https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ecs-service.html](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ecs-service.html)》中的 。

## 使用預設選項建立服務
<a name="create-default-service"></a>

您可以使用主控台來快速建立並部署服務。服務具有下列組態：
+ 在與叢集關聯的 VPC 和子網路中部署
+ 部署一項任務
+ 使用滾動部署
+ 搭配預設容量供應商使用容量供應商策略
+ 使用部署斷路器偵測故障，並將選項設定為在失敗時自動回復部署

若要使用預設參數部署服務，請遵循下列步驟。

**建立服務 (Amazon ECS 主控台)**

1. 開啟主控台，網址為 [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)。

1. 在導覽頁面中，選擇**叢集**)。

1. 在**叢集**頁面上，選擇要建立服務的叢集。

1. 在 **Services** (服務) 索引標籤上，選擇 **Create** (建立)。

   **建立服務**頁面隨即顯示。

1. 在**服務詳細資訊**下，執行下列動作：

   1. 在**任務定義**欄位中，選擇要使用的任務定義系列與修訂版。

   1. 針對 **Service name** (服務名稱)，輸入服務的名稱。

1. 若要使用 ECS Exec 來偵錯服務，請在**對組態進行疑難排解**下，選取**開啟 ECS Exec**。

1. 在**部署組態**下，執行下列動作：

   1. 針對 **Desired tasks** (所需任務)，輸入要在服務中啟動並維護的任務數。

1. (選用) 為協助識別您的服務和任務，請展開 **Tags** (標籤) 區段，然後設定標籤。

   若要讓 Amazon ECS 使用叢集名稱和任務定義標籤，自動標記所有新啟動的任務，請選取 **Turn on Amazon ECS managed tags** (開啟 Amazon ECS 受管標籤)，然後選取 **Task definitions** (任務定義)。

   若要讓 Amazon ECS 使用叢集名稱和服務標籤，自動標記所有新啟動的任務，請選取 **Turn on Amazon ECS managed tags** (開啟 Amazon ECS 受管標籤)，然後選取 **Service** (服務)。

   新增或移除標籤。
   + [新增標籤] 選擇**新增標籤**，然後執行下列操作︰
     + 在**索引鍵**中，輸入索引鍵名稱。
     + 在**值**中，進入索引鍵值。
   + [移除標籤] 在標籤旁邊，選擇 **移除標籤**。

## 使用定義的參數建立服務
<a name="create-custom-service"></a>

若要使用定義的參數建立服務，請遵循下列步驟。

**建立服務 (Amazon ECS 主控台)**

1. 開啟主控台，網址為 [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)。

1. 決定您要從中啟動服務的資源。    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/AmazonECS/latest/developerguide/create-service-console-v2.html)

   **建立服務**頁面隨即顯示。

1. 在服務詳細資訊下，執行下列動作：

   1. 在**任務定義**欄位中輸入要使用的任務定義。然後，在**修訂版**欄位中選擇要使用的修訂版。

   1. 針對 **Service name** (服務名稱)，輸入服務的名稱。

1. 在**現有叢集**欄位中選擇叢集。

   選擇**建立叢集**以在新叢集上執行任務

1. 選擇任務在叢集基礎結構中的分佈方式。在**運算組態**下選擇選項。    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/AmazonECS/latest/developerguide/create-service-console-v2.html)

1. 若要使用 ECS Exec 來偵錯服務，請在**對組態進行疑難排解**下，選取**開啟 ECS Exec**。

1. 在**部署組態**下，執行下列動作：

   1. 針對 **Service type** (服務類型)，選擇服務排程策略。
      + 若要讓排程器在每個活動容器執行個體上準確部署一個任務，且滿足所有任務置放限制條件，請選擇 **Daemon** (常駐程式)。
      + 若要讓排程器在叢集中置放並維持所需的任務數量，請選擇 **Replica** (複寫)。

   1. 如果您選擇 **Replica** (複寫)，針對 **Desired tasks** (所需任務)，輸入要在服務中啟動並維護的任務數。

   1. 如果選擇**複本**，若要讓 Amazon ECS 監控可用區域間的任務分佈，並在出現不平衡時重新分佈，請在**可用區域服務重新平衡**下，選取**可用區域服務重新平衡**。

   1. 在**運作狀態檢查寬限期**欄位中輸入時間量 (以秒為單位)，這是服務排程器在任務首次啟動後忽略運作狀態不良的 Elastic Load Balancing、VPC Lattice 與容器運作狀態檢查的時間。如果您未指定運作狀態檢查寬限期間值，則會使用預設值 0。

   1. 決定服務的部署類型。展開**部署選項**區段，然後指定下列參數。    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/AmazonECS/latest/developerguide/create-service-console-v2.html)

   1. 若要設定 Amazon ECS 如何偵測並處理部署失敗，請展開 **Deployment failure detection** (部署失敗偵測)，然後選擇您的選項。

      1. 若要在任務無法啟動時停止部署，請選取 **Use the Amazon ECS deployment circuit breaker** (使用 Amazon ECS 部署斷路器)。

         在部署斷路器將部署設定為失敗狀態時，若要讓軟體自動將部署復原至上次完成的部署狀態，請選取**失敗時復原**。

      1. 若要根據應用程式指標停止部署，請選取**使用 CloudWatch 警示**。然後，從**CloudWatch 警示名稱**欄位中選擇警示。要建立新的警示，請前往 CloudWatch 主控台。

         在 CloudWatch 警示將部署設定為失敗狀態時，若要讓軟體自動將部署復原至上次完成的部署狀態，請選取**失敗時復原**。

1. 如果任務定義使用 `awsvpc` 網路模式，可展開**聯網**區段以指定自訂網路組態，然後執行下列動作：

   1. 針對 **VPC**，選擇要使用的 VPC。

   1. 針對**子網路**，在 VPC 中選擇一個或多個子網路，而任務排程器在放置任務時會考慮該 VPC。

   1. 針對 **Security groups** (安全群組)，您可以選取現有的安全群組，或建立新的安全群組。若要使用現有的安全群組，選擇該安全群組並移至下一個步驟。若要建立新的安全群組，請選擇 **建立新安全群組**。您必須指定安全群組名稱、描述，然後為該安全群組新增一條或更多傳入規則。

   1. 針對 **Public IP** (公有 IP)，選擇是否為任務的彈性網路界面 (ENI) 自動指派公有 IP 地址。

      AWS Fargate 在公有子網路中執行時，任務可以指派公有 IP 地址，以便他們有網際網路的路由。無法使用此欄位將公有 IP 指派給 EC2 任務。如需詳細資訊，請參閱 [Fargate 的 Amazon ECS 任務聯網選項](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/fargate-task-networking.html)，以及[為 Amazon ECS 任務配置網路介面](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-networking-awsvpc.html)。

1. (選用) 若要使用 Service Connect 與服務互連，請展開 **Service Connect** 區段，然後指定下列項目：

   1.  選取**開啟 Service Connect**。

   1. 在 **Service Connect configuration** (Service Connect 組態) 下，指定用戶端模式。
      + 如果服務執行的網路用戶端應用程式只需要連線至命名空間中的其他服務，請選擇**僅用戶端**。
      + 如果服務執行的是網路或 Web 服務應用程式，且需要為此服務提供端點，並連線至命名空間中的其他服務，請選擇 **Client and server** (用戶端和伺服器)。

   1. 若要使用非預設叢集命名空間的命名空間，請在 **Namespace** (命名空間) 欄位中選擇服務命名空間。這可以是在您的 中在相同 AWS 區域 中分別建立的命名空間， AWS 帳戶 或是使用 AWS Resource Access Manager () 與您的帳戶共用的相同區域中的命名空間AWS RAM。如需共用 AWS Cloud Map 命名空間的詳細資訊，請參閱《 *AWS Cloud Map 開發人員指南*》中的[跨帳戶 AWS Cloud Map 命名空間共用](https://docs.aws.amazon.com/cloud-map/latest/dg/sharing-namespaces.html)。

   1. (選用) 指定日誌組態。選取**使用日誌收集**。預設選項會將容器日誌傳送至 CloudWatch 日誌。其他日誌驅動程式選項是使用 AWS FireLens 設定。如需詳細資訊，請參閱[將 Amazon ECS 日誌傳送至 AWS 服務或 AWS Partner](using_firelens.md)。

      下方更詳細地描述了每個容器日誌目的地。
      + **Amazon CloudWatch** – 將任務設定為將容器日誌傳送至 CloudWatch Logs。系統會提供預設日誌驅動程式選項，用來代表您建立 CloudWatch 日誌群組。若要指定不同的日誌群組名稱，請變更驅動程式選項值。
      + **Amazon Data Firehose** – 將任務設定為將容器日誌傳送至 Firehose。系統會提供預設日誌驅動程式選項，用來將日誌傳送至 Firehose 傳送串流。若要指定不同的交付串流名稱，請變更驅動程式選項值。
      + **Amazon Kinesis Data Streams** – 將任務設定為將容器日誌傳送至 Amazon Kinesis Data Streams。系統會提供預設日誌驅動程式選項，用來將日誌傳送至 Kinesis Data Streams 串流。若要指定不同的串流名稱，請變更驅動程式選項值。
      + **Amazon OpenSearch Service** – 將任務設定為將容器日誌傳送至 OpenSearch Service 網域。務必提供日誌驅動程式選項。
      + **Amazon S3**：將任務設定為將容器日誌傳送至 Amazon S3 儲存貯體。系統會提供預設日誌驅動程式選項，但您必須指定有效的 Amazon S3 儲存貯體名稱。

   1. （選用） 若要啟用存取日誌，請遵循下列步驟：

      1. 展開**存取日誌組態**。針對**格式**，選擇 **JSON** 或 `TEXT`。

      1. 若要在存取日誌中包含查詢參數，請選取**包含查詢參數**。

1. (選用) 若要使用服務探索與服務互連，請展開**服務探索**區段，然後執行下列動作。

   1. 選取**使用服務探索**。

   1. 若要使用新的命名空間，請在**設定命名空間**下選擇**建立新的命名空間**，然後提供命名空間名稱與描述。若要使用現有命名空間，請選擇**選取現有的命名空間**，然後選擇要使用的命名空間。

   1. 提供服務探索服務資訊，例如服務的名稱與描述。

   1. 若要讓 Amazon ECS 定期執行容器層級運作狀態檢查，請選取**啟用 Amazon ECS 任務運作狀態傳播**。

   1. 針對 **DNS record type** (DNS 紀錄類型)，選擇您要為服務建立的 DNS 紀錄類型。Amazon ECS 服務探索僅支援 **A** 與 **SRV** 記錄，這取決於任務定義指定的網路模式。如需有關此類記錄類型的詳細資訊，請參閱 *Amazon Route 53 開發人員指南*中的[支援的 DNS 紀錄類型](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/ResourceRecordTypes.html)。
      + 如果服務任務指定的任務定義使用的是 `bridge` 或 `host` 網路模式，僅支援類型 **SRV** 記錄。選擇容器名稱和連接埠組合以與該紀錄建立關聯。
      + 如果服務任務指定的任務定義使用的是 `awsvpc` 網路模式，選取 **A** 或 **SRV** 紀錄類型。如果選擇 **A**，請跳到下一步驟。如果選取 **SRV**，指定可找到該服務的連接埠，或是容器名稱和連接埠組合，以與該記錄建立關聯。

      針對 **TTL**，輸入 DNS 解析器和網頁瀏覽器快取記錄集的時間 (以秒為單位)。

1. (選用) 若要使用 VPC Lattice，請展開 **VPC Lattice** 與服務互連，然後執行下列動作：

   1. 選取**開啟 VPC Lattice**

   1. 在**基礎結構角色**欄位中，選擇對應的基礎結構角色。

      如果尚未建立角色，請選擇**建立基礎結構角色**。

   1. 在**目標群組**下，選擇一個或多個目標群組。您需要選擇至少一個目標群組，最多可以選擇五個。選擇**新增目標群組**以新增額外的目標群組。針對選擇的每個目標群組，選擇**連接埠名稱**、**通訊協定**與**連接埠**。

      若要刪除目標群組，請選擇**移除**。
**注意**  
若要新增現有的目標群組，需要使用 AWS CLI。如需如何使用 新增目標群組的指示 AWS CLI，請參閱《* AWS Command Line Interface 參考*》中的 [register-targets](https://docs.aws.amazon.com/cli/latest/reference/vpc-lattice/register-targets.html)。
雖然 VPC Lattice 服務可以有多個目標群組，但每個目標群組只能新增至一項服務。

   1. 若要完成 VPC Lattice 組態，請在接聽程式預設動作中或在 VPC Lattice 主控台的現有 VPC Lattice 服務的規則中包含新目標群組。如需詳細資訊，請參閱 [VPC Lattice 服務的接聽程式規則](https://docs.aws.amazon.com/vpc-lattice/latest/ug/listener-rules.html)。

1. (選用) 若要設定服務的負載平衡器，請展開 **Load balancing** (負載平衡) 區段。

   選擇負載平衡器。    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/AmazonECS/latest/developerguide/create-service-console-v2.html)

1. (選用) 若要設定服務自動擴展功能，請展開**服務自動擴展**區段，然後指定下列參數。若要使用預測自動擴展功能 (該功能可查看過去從流量流程載入的資料)，請在建立服務後進行設定。如需詳細資訊，請參閱[使用歷史模式透過預測擴展來擴展 Amazon ECS 服務](predictive-auto-scaling.md)。

   1. 若要使用服務自動擴展，請選取 **Service auto scaling** (服務自動擴展)。

   1. 在**任務數量下限**欄位中，輸入供服務自動擴展功能使用的任務數量下限。所需的計數不會低於此計數。

   1. 在**任務數量上限**中，輸入供服務自動擴展功能使用的任務數量上限。所需的計數不會高於此計數。

   1. 選擇政策類型。在**擴展政策類型**下，選擇下列其中一個選項。    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/AmazonECS/latest/developerguide/create-service-console-v2.html)

1. (選用) 若要使用預設以外的任務置放策略，請展開**任務置放**，然後從下列選項中選擇。

    如需詳細資訊，請參閱[Amazon ECS 如何在容器執行個體上置放任務](task-placement.md)。
   + **AZ 平衡分散** - 在可用區域及可用區域中的容器執行個體之間分散任務。
   + **AZ 平衡 BinPack** - 使用最低可用記憶體，在可用區域及可用區域中的容器執行個體之間分散任務。
   + **BinPack** - 根據最低可用的 CPU 或記憶體數分散任務。
   + **每個主機一個任務** - 在每個容器執行個體上最多置放一個服務的任務。
   + **自訂** – 定義自己的任務置放策略。

   如果選擇**自訂**，則請定義置放任務的演算法，以及在任務置放期間考慮的規則。
   + 在**策略**下，針對**類型**和**欄位**，選擇演算法以及要用於演算法的實體。

     您最多可新增 5 項策略。
   + 在 **Constraint** (限制條件)，針對 **Type** (類型) 和 **Expression** (運算式)，選擇要用於限制條件的規則與屬性。

     例如，若要設定限制條件，以將任務置放在 T2 執行個體上，針對**運算式**，請輸入 **attribute:ecs.instance-type =\$1 t2.\$1**。

     您最多可新增 10 個限制條件。

1. 如果任務使用的資料磁碟區與部署時的組態相容，則可透過展開**磁碟區**區段對磁碟區進行設定。

   磁碟區名稱與磁碟區類型會在建立任務定義修訂版時設定，且無法在服務建立期間變更。若要更新磁碟區名稱與類型，必須建立新的任務定義修訂版，並使用新修訂版建立服務。    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/AmazonECS/latest/developerguide/create-service-console-v2.html)

1. 若要使用 ECS Exec 來偵錯服務，請在**對組態進行疑難排解**下，選取**開啟 ECS Exec**。

1. (選用) 為協助識別您的服務和任務，請展開 **Tags** (標籤) 區段，然後設定標籤。

   若要讓 Amazon ECS 使用叢集名稱和任務定義標籤，自動標記所有新啟動的任務，請選取 **Turn on Amazon ECS managed tags** (開啟 Amazon ECS 受管標籤)，然後針對 **Propagate tags from** (傳播標籤來源)，選取 **Task definitions** (任務定義)。

   若要讓 Amazon ECS 使用叢集名稱和服務標籤，自動標記所有新啟動的任務，請選取 **Turn on Amazon ECS managed tags** (開啟 Amazon ECS 受管標籤)，然後針對 **Propagate tags from** (傳播標籤來源)，選取 **Service** (服務)。

   新增或移除標籤。
   + [新增標籤] 選擇**新增標籤**，然後執行下列操作︰
     + 在**索引鍵**中，輸入索引鍵名稱。
     + 在**值**中，進入索引鍵值。
   + [移除標籤] 在標籤旁邊，選擇**移除標籤**。

1. 選擇**建立**。

## 後續步驟
<a name="create-service-next-steps"></a>

下列是建立服務後的其他動作。
+ 設定預測自動擴展功能，該功能可查看過去從流量流程載入的資料。如需詳細資訊，請參閱[使用歷史模式透過預測擴展來擴展 Amazon ECS 服務](predictive-auto-scaling.md)。
+ 追蹤部署，並檢視 Amazon ECS 斷路器服務的服務歷史記錄。如需詳細資訊，請參閱[使用 Amazon ECS 服務部署檢視服務歷史記錄](service-deployment.md)。

# Amazon ECS 藍/綠部署
<a name="deployment-type-blue-green"></a>

藍/綠部署是一種發行方法，可透過執行兩個稱為藍和綠的相同生產環境來減少停機時間和風險。藉助 Amazon ECS 藍/綠部署，您可以先驗證新的服務修訂版，再將生產流量導向這些修訂版。這種方法提供了一種更安全的變更部署方式，並且能在需要時快速復原。

## 優勢
<a name="blue-green-deployment-benefits"></a>

使用藍/綠部署具有以下優勢：
+ 在切換生產之前，透過使用生產流量進行測試來降低風險。您可以在將生產流量導向新部署之前，使用測試流量對部署進行驗證。
+ 零停機時間部署。在整個部署程序中，生產環境仍然可用，以確保持續的服務可用性。
+ 如果偵測到問題，可輕鬆復原。如果綠色部署發生問題，您可以快速還原至藍色部署，而不會造成長時間的服務中斷。
+ 受控的測試環境。綠色環境提供隔離的空間，可在完全部署之前使用實際流量模式測試新功能。
+ 可預測的部署程序。具有定義的生命週期階段的結構化方法，可讓部署更加一致且可靠。
+ 透過 lifecycle hook 實現自動化驗證。您可以在部署的各個階段實作自動化測試，以驗證功能。

## 術語
<a name="blue-green-deployment-terms"></a>

下列是 Amazon ECS 藍/綠部署術語：
+ 封裝時間 – 在生產流量轉移後，藍色與綠色服務修訂版同時執行的持續時間。
+ 藍色部署 – 要取代的目前生產服務修訂版。
+ 綠色部署 – 要部署的新服務修訂版。
+ 生命週期階段 – 部署操作中的一系列事件，例如「生產流量轉移後」。
+ Lifecycle hook – 在特定生命週期階段驗證部署的 Lambda 函式。
+ 接聽程式 – 一種 Elastic Load Balancing 資源，用於透過已設定的通訊協定與連接埠檢查連線請求。您為接聽程式定義的規則決定了 Amazon ECS 如何將請求路由至已註冊的目標。
+ 規則 – 與接聽程式相關聯的 Elastic Load Balancing 資源。規則定義了請求的路由方式，包含動作、條件與優先順序。
+ 目標群組 – 一種 Elastic Load Balancing 資源，用於將請求路由至一個或多個已註冊的目標 (例如 EC2 執行個體)。當您建立接聽程式時，可以為其預設動作指定一個目標群組。流量會轉送至接聽程式規則中指定的目標群組。
+ 流量轉移 – Amazon ECS 用於將流量從藍色部署轉移到綠色部署的程序。對於 Amazon ECS 藍/綠部署，所有流量都會一次從藍色服務轉移到綠色服務。

## 考量事項
<a name="blue-green-deployment-considerations"></a>

選擇部署類型時，請考量下列事項：
+ 資源用量 – 藍/綠部署會暫時同時執行藍色與綠色服務修訂版，這可能會在部署期間使資源用量加倍。
+ 部署監控 – 藍/綠部署會提供更詳細的部署狀態資訊，便於您監控部署程序的每個階段。
+ 復原 – 藍/綠部署會在偵測到問題時更輕鬆地復原至先前的版本，因為藍色修訂版會持續執行，直到封裝時間過期為止。
+ Network Load Balancer 生命週期掛鉤：如果您使用 Network Load Balancer 進行藍/綠部署，則 TEST\$1TRAFFIC\$1SHIFT 和 PRODUCTION\$1TRAFFIC\$1SHIFT 生命週期階段會有額外的 10 分鐘。這是因為 Amazon ECS 可確保轉移流量是安全的。

# Amazon ECS 藍/綠服務部署工作流程
<a name="blue-green-deployment-how-it-works"></a>

Amazon ECS 藍/綠部署程序採用結構化方法，包含六個不同階段，以確保安全可靠的應用程式更新。每個階段都有特定用途，以驗證應用程式，並將其從目前版本 (藍色) 轉換為新版本 (綠色)。

1. **準備階段** – 在現有的藍色環境旁建立綠色環境。這包括佈建新的服務修訂版以及準備目標群組。

1. **部署階段**：將新的服務修訂版部署到綠色環境。Amazon ECS 會使用更新後的服務修訂版啟動新任務，同時藍色環境會繼續處理生產流量。

1. **測試階段**：使用測試流量路由驗證綠色環境。Application Load Balancer 會將測試請求導向綠色環境，同時生產流量仍保留在藍色環境中。

1. **流量轉移階段**：根據設定的部署策略，將生產流量從藍色環境轉移到綠色環境。此階段包含監控與驗證檢查點。

1. **監控階段**：在封裝時間段內監控應用程式運作狀態、效能指標與警示狀態。偵測到問題時，會啟動復原操作。

1. **完成階段**：視組態而定，透過終止藍色環境或者為潛在復原案例維持該環境來完成最終部署。

## 工作流程
<a name="blue-green-deployment-workflow"></a>

下圖說明完整的藍/綠部署工作流程，顯示了 Amazon ECS 與 Application Load Balancer 之間的互動：

![\[完整圖表，顯示了 Amazon ECS 中的藍/綠部署程序，其中包含詳細的元件互動、流量轉移階段與監控檢查點\]](http://docs.aws.amazon.com/zh_tw/AmazonECS/latest/developerguide/images/blue-green.png)


增強型部署工作流程包含下列詳細步驟：

1. **初始狀態**：藍色服務 (目前生產環境) 處理 100% 的生產流量。Application Load Balancer 具有一個接聽程式，其規則會將所有請求路由至包含運作狀態良好之藍色任務的藍色目標群組。

1. **綠色環境佈建**：Amazon ECS 會使用更新後的任務定義建立新任務。這些任務已向新的綠色目標群組註冊，但最初不會接收任何流量。

1. **運作狀態檢查驗證**：Application Load Balancer 會對綠色任務執行運作狀態檢查。只有在綠色任務通過運作狀態檢查時，部署才會進入下一階段。

1. **測試流量路由**：如果已設定，Application Load Balancer 的接聽程式規則會將特定流量模式 (例如具有測試標頭的請求) 路由至綠色環境進行驗證，而生產流量仍保留在藍色環境中。這由處理生產流量的同一接聽程式控制，並根據請求屬性使用不同的規則。

1. **生產流量轉移**：根據部署組態，流量會從藍色環境轉移到綠色環境。在 ECS 藍/綠部署中，這是即時 (一次全部) 轉移，其中 100% 的流量會從藍色環境移至綠色環境。Application Load Balancer 搭配接聽程式規則使用單一接聽程式，根據權重控制藍色與綠色目標群組之間的流量分佈。

1. **監控與驗證**：在整個流量轉移期間，Amazon ECS 會監控 CloudWatch 指標、警示狀態與部署運作狀態。如果偵測到問題，就會觸發自動復原。

1. **封裝時間段**：在生產流量轉移後，藍色與綠色服務修訂版同時執行的持續時間。

1. **藍色環境終止**：在成功的流量轉移與驗證之後，藍色環境會終止以釋放叢集資源，或者會保留以實現快速復原功能。

1. **最終狀態**：綠色環境會成為新的生產環境，處理 100% 的流量。部署會標記為成功。

## 部署生命週期階段
<a name="blue-green-deployment-stages"></a>

藍/綠部署程序會經歷不同的生命週期階段 (部署操作中的一系列事件，例如「生產流量轉移後」)，每個事件都有特定的責任與驗證檢查點。了解這些階段有助於監控部署進度並對問題進行有效的疑難排解。

 每個生命週期階段最多可持續 24 小時。建議將該值保持在 24 小時標記以內。這是因為非同步程序需要時間來觸發勾點。系統逾時、部署失敗，然後在階段達到 24 小時後啟動轉返。 CloudFormation 部署有額外的逾時限制。雖然 24 小時階段限制仍然有效，但 對整個部署 CloudFormation 強制執行 36 小時限制。 部署 CloudFormation 失敗，然後在程序未在 36 小時內完成時啟動轉返。


| 生命週期階段 | Description | 是否將此階段用於 lifecycle hook？ | 
| --- | --- | --- | 
| RECONCILE\$1SERVICE | 僅當啟動新的服務部署且存在多個處於 ACTIVE 狀態的服務修訂版時，此階段才會發生。 | 是 | 
| PRE\$1SCALE\$1UP | 綠色服務修訂版尚未啟動。藍色服務修訂版正在處理 100% 的生產流量。沒有測試流量。 | 是 | 
| SCALE\$1UP | 綠色服務修訂版向上擴展到 100% 並啟動新任務的時間。此時綠色服務修訂版不處理任何流量。 | 否 | 
| POST\$1SCALE\$1UP | 綠色服務修訂版已啟動。藍色服務修訂版正在處理 100% 的生產流量。沒有測試流量。 | 是 | 
| TEST\$1TRAFFIC\$1SHIFT | 藍色與綠色服務修訂版均在執行中。藍色服務修訂版處理 100% 的生產流量。綠色服務修訂版正在從 0% 遷移至 100% 的測試流量。 | 是 | 
| POST\$1TEST\$1TRAFFIC\$1SHIFT | 測試流量轉移已完成。綠色服務修訂版處理 100% 的生產流量。 | 是 | 
| PRODUCTION\$1TRAFFIC\$1SHIFT | 生產流量正在轉移至綠色服務修訂版。綠色服務修訂版正在從 0% 遷移至 100% 的生產流量。 | 是 | 
| POST\$1PRODUCTION\$1TRAFFIC\$1SHIFT | 生產流量轉移已完成。 | 是 | 
| BAKE\$1TIME | 藍色與綠色服務修訂版同時執行的持續時間。 | 否 | 
| CLEAN\$1UP | 藍色服務修訂已完全縮減至 0 項執行中任務。在此階段之後，綠色服務修訂版現在是生產服務修訂版。 | 否 | 

每個生命週期階段都包含內建的驗證檢查點，必須通過這些檢查點才能進入下一階段。如果有任何驗證失敗，部署可以自動復原，以維持服務可用性與可靠性。

當您使用 Lambda 函式時，該函式必須在 15 分鐘內完成工作或傳回 IN\$1PROGRESS。您可以使用 `callBackDelaySeconds` 來延遲對 Lambda 的呼叫。如需詳細資訊，請參閱 GitHub 上 sample-amazon-ecs-blue-green-deployment-patterns 中的 [app.py function](https://github.com/aws-samples/sample-amazon-ecs-blue-green-deployment-patterns/blob/main/ecs-bluegreen-lifecycle-hooks/src/approvalFunction/app.py#L20-L25)。

# Amazon ECS 藍/綠部署所需資源
<a name="blue-green-deployment-implementation"></a>

若要搭配受管流量轉移使用藍/綠部署，服務必須使用下列其中一項功能：
+ Elastic Load Balancing
+ Service Connect

未使用服務探索、Service Connect、VPC Lattice 或 Elastic Load Balancing 的服務也可以使用藍/綠部署，但不會獲得任何受管流量轉移優勢。

下列清單提供了設定 Amazon ECS 藍/綠部署所需資源的高階概觀：
+ 服務會使用 Application Load Balancer、Network Load Balancer 或 Service Connect。設定相應的資源。
  + Application Load Balancer – 如需詳細資訊，請參閱[藍/綠、線性和金絲雀部署的 Application Load Balancer 資源](alb-resources-for-blue-green.md)。
  + Network Load Balancer – 如需詳細資訊，請參閱[Amazon ECS 藍/綠、線性和 Canary 部署的 Network Load Balancer 資源](nlb-resources-for-blue-green.md)。
  + Service Connect – 如需詳細資訊，請參閱[Amazon ECS 藍色/綠色、線性和 Canary 部署的 Service Connect 資源](service-connect-blue-green.md)。
+ 將服務部署控制器設定為 `ECS`。
+ 在服務定義中，將部署策略設定為 `blue/green`。
+ 或者設定其他參數，例如：
  + 新部署的封裝時間
  + 自動復原的 CloudWatch 警示
  + 用於測試的部署 lifecycle hook (這些是在指定部署階段執行的 Lambda 函式)

## 最佳實務
<a name="blue-green-deployment-best-practices"></a>

請遵循以下最佳實務，以成功實現 Amazon ECS 藍/綠部署：
+ 設定相應的運作狀態檢查，以準確反映應用程式的運作狀態。
+ 設定封裝時間，以對綠色部署進行充分測試。
+ 實作 CloudWatch 警示，以自動偵測問題並觸發復原。
+ 使用 lifecycle hook，在每個部署階段執行自動化測試。
+ 確保您的應用程式可以同時處理藍色和綠色服務修訂。
+ 規劃足夠的叢集容量，以在部署期間處理這兩個服務修訂。
+ 在生產環境中實作復原程序之前，先對這些程序進行測試。

# 藍/綠、線性和金絲雀部署的 Application Load Balancer 資源
<a name="alb-resources-for-blue-green"></a>

若要搭配 Amazon ECS 藍/綠部署使用 Application Load Balancer，需要設定特定資源，以允許藍色與綠色服務修訂版之間的流量路由。

## 目標群組
<a name="alb-target-groups"></a>

若要搭配 Elastic Load Balancing 使用藍/綠部署，需要建立兩個目標群組：
+ 用於藍色服務修訂版的主要目標群組 (目前生產流量)
+ 用於綠色服務修訂版的替代目標群組 (新版本)

兩個目標群組都應使用下列設定進行設定：
+ 目標類型：`IP` (適用於 Fargate 或使用 `awsvpc` 網路模式的 EC2)
+ 通訊協定：`HTTP` (或應用程式使用的通訊協定)
+ 連接埠：應用程式監聽的連接埠 (對於 HTTP 通常為 `80`)
+ VPC：與 Amazon ECS 任務相同的 VPC
+ 運作狀態檢查設定：設定為正確檢查應用程式的運作狀態

在藍/綠部署期間，Amazon ECS 會根據部署階段，自動向相應的目標群組註冊任務。

**Example 為 Application Load Balancer 建立目標群組**  
下列 CLI 命令會建立兩個目標群組，用於藍/綠部署中的 Application Load Balancer：  

```
aws elbv2 create-target-group \
    --name blue-target-group \
    --protocol HTTP \
    --port 80 \
    --vpc-id vpc-abcd1234 \
    --target-type ip \
    --health-check-path / \
    --health-check-protocol HTTP \
    --health-check-interval-seconds 30 \
    --health-check-timeout-seconds 5 \
    --healthy-threshold-count 2 \
    --unhealthy-threshold-count 2

aws elbv2 create-target-group \
    --name green-target-group \
    --protocol HTTP \
    --port 80 \
    --vpc-id vpc-abcd1234 \
    --target-type ip \
    --health-check-path / \
    --health-check-protocol HTTP \
    --health-check-interval-seconds 30 \
    --health-check-timeout-seconds 5 \
    --healthy-threshold-count 2 \
    --unhealthy-threshold-count 2
```

## Application Load Balancer
<a name="alb-load-balancer"></a>

您需要建立包含下列組態的 Application Load Balancer：
+ 結構描述：面向網際網路或內部，視要求而定
+ IP 位址類型：IPv4
+ VPC：與 Amazon ECS 任務相同的 VPC
+ 子網路：至少兩個位於不同可用區域的子網路
+ 安全群組：允許接聽程式連接埠流量的安全群組

連接至 Application Load Balancer 的安全群組必須具有傳出規則，允許流量傳送至連接至 Amazon ECS 任務的安全群組。

**Example 建立 Application Load Balancer**  
下列 CLI 命令會建立用於藍綠部署的 Application Load Balancer：  

```
aws elbv2 create-load-balancer \
    --name my-application-load-balancer \
    --type application \
    --security-groups sg-abcd1234 \
    --subnets subnet-12345678 subnet-87654321
```

## 接聽程式和規則
<a name="alb-listeners"></a>

對於藍/綠部署，您需要在 Application Load Balancer 上設定接聽程式：
+ 生產接聽程式：處理生產流量 (通常位於連接埠 80 或 443)
  + 最初將流量轉送至主要目標群組 (藍色服務修訂版)
  + 部署之後，將流量轉送至替代目標群組 (綠色服務修訂版)
+ 測試接聽程式 (選用)：處理測試流量，以在轉移生產流量之前驗證綠色服務修訂版
  + 可以在不同的連接埠上設定 (例如 8080 或 8443)
  + 在測試期間將流量轉送至替代目標群組 (綠色服務修訂版)

在藍/綠部署期間，Amazon ECS 會根據部署階段自動更新接聽程式規則，將流量路由至相應的目標群組。

**Example 建立生產接聽程式**  
下列 CLI 命令會在連接埠 80 上建立生產接聽程式，將流量轉送至主要 (藍色) 目標群組：  

```
aws elbv2 create-listener \
    --load-balancer-arn arn:aws:elasticloadbalancing:region:123456789012:loadbalancer/app/my-application-load-balancer/abcdef123456 \
    --protocol HTTP \
    --port 80 \
    --default-actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:region:123456789012:targetgroup/blue-target-group/abcdef123456
```

**Example 建立測試接聽程式**  
下列 CLI 命令會在連接埠 8080 上建立測試接聽程式，將流量轉送至替代 (綠色) 目標群組：  

```
aws elbv2 create-listener \
    --load-balancer-arn arn:aws:elasticloadbalancing:region:123456789012:loadbalancer/app/my-application-load-balancer/abcdef123456 \
    --protocol HTTP \
    --port 8080 \
    --default-actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:region:123456789012:targetgroup/green-target-group/ghijkl789012
```

**Example 為以路徑為基礎的路由建立接聽程式規則**  
下列 CLI 命令會建立規則，將特定路徑的流量轉送至綠色目標群組進行測試：  

```
aws elbv2 create-rule \
    --listener-arn arn:aws:elasticloadbalancing:region:123456789012:listener/app/my-application-load-balancer/abcdef123456/ghijkl789012 \
    --priority 10 \
    --conditions Field=path-pattern,Values='/test/*' \
    --actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:region:123456789012:targetgroup/green-target-group/ghijkl789012
```

**Example 為以標頭為基礎的路由建立接聽程式規則**  
下列 CLI 命令會建立規則，將包含特定標頭的流量轉送至綠色目標群組進行測試：  

```
aws elbv2 create-rule \
    --listener-arn arn:aws:elasticloadbalancing:region:123456789012:listener/app/my-application-load-balancer/abcdef123456/ghijkl789012 \
    --priority 20 \
    --conditions Field=http-header,HttpHeaderConfig='{Name=X-Environment,Values=[test]}' \
    --actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:region:123456789012:targetgroup/green-target-group/ghijkl789012
```

## 服務組態
<a name="alb-service-configuration"></a>

您必須擁有許可，才能允許 Amazon ECS 代表您管理叢集中的負載平衡器資源。如需詳細資訊，請參閱[負載平衡器的 Amazon ECS 基礎結構 IAM 角色](AmazonECSInfrastructureRolePolicyForLoadBalancers.md)。

為搭配 Elastic Load Balancing 使用的藍/綠部署建立或更新 Amazon ECS 服務時，需要指定下列組態。

將 *user-input* 取代為實際值。

此組態中的關鍵元件包括：
+ `targetGroupArn`：主要目標群組的 ARN (藍色服務修訂版)。
+ `alternateTargetGroupArn`：替代目標群組的 ARN (綠色服務修訂版)。
+ `productionListenerRule`：用於生產流量的接聽程式規則 ARN。
+ `roleArn`：允許 Amazon ECS 管理 Elastic Load Balancing 資源的角色 ARN。
+ `strategy`：設定為 `BLUE_GREEN` 以啟用藍/綠部署。
+ `bakeTimeInMinutes`：在生產流量轉移後，藍色與綠色服務修訂版同時執行的持續時間。
+ `TestListenerRule`：用於測試流量的接聽程式規則 ARN。這是選擇性的參數。

```
{
    "loadBalancers": [
        {
            "targetGroupArn": "arn:aws:elasticloadbalancing:region:123456789012:targetgroup/primary-target-group/abcdef123456",
            "containerName": "container-name",
            "containerPort": 80,
            "advancedConfiguration": {
                "alternateTargetGroupArn": "arn:aws:elasticloadbalancing:region:account-id:targetgroup/alternate-target-group/ghijkl789012",
                "productionListenerRule": "arn:aws:elasticloadbalancing:region:account-id:listener-rule/app/load-balancer-name/abcdef123456/listener/ghijkl789012/rule/mnopqr345678",
                "roleArn": "arn:aws:iam::123456789012:role/ecs-elb-role"
            }
        }
    ],
    "deploymentConfiguration": {
        "strategy": "BLUE_GREEN",
        "maximumPercent": 200,
        "minimumHealthyPercent": 100,
        "bakeTimeInMinutes": 5
    }
}
```

## 部署期間的流量流程
<a name="alb-traffic-flow"></a>

在搭配 Elastic Load Balancing 使用藍/綠部署期間，流量會流經系統，如下所示：

1. *初始狀態*：所有生產流量都會路由至主要目標群組 (藍色服務修訂版)。

1. *綠色服務修訂版部署*：Amazon ECS 會部署新任務，並向替代目標群組註冊新任務。

1. *測試流量*：如果已設定測試接聽程式，則測試流量會路由至替代目標群組，以驗證綠色服務修訂版。

1. *生產流量轉移*：Amazon ECS 會更新生產接聽程式規則，將流量路由至替代目標群組 (綠色服務修訂版)。

1. *封裝時間*：在生產流量轉移後，藍色與綠色服務修訂版同時執行的持續時間。

1. *完成*：成功部署後，藍色服務修訂版會終止。

如果在部署期間偵測到問題，Amazon ECS 可以透過將流量路由回主要目標群組 (藍色服務修訂版) 實現自動復原。

# Amazon ECS 藍/綠、線性和 Canary 部署的 Network Load Balancer 資源
<a name="nlb-resources-for-blue-green"></a>

若要搭配 Amazon ECS 藍/綠部署使用 Network Load Balancer，需要設定特定資源，以啟用藍色與綠色服務修訂版之間的流量路由。本節說明必要的元件及其組態。

如果組態包含 Network Load Balancer，Amazon ECS 會向下列生命週期階段新增 10 分鐘延遲：
+ TEST\$1TRAFFIC\$1SHIFT
+ PRODUCTION\$1TRAFFIC\$1SHIFT

此延遲旨在應對 Network Load Balancer 的計時問題，這些問題可能導致設定的流量權重與資料平面中的實際流量路由不相符。

## 目標群組
<a name="nlb-target-groups"></a>

對於搭配 Network Load Balancer 使用的藍/綠部署，您需要建立兩個目標群組：
+ 用於藍色服務修訂版的主要目標群組 (目前生產流量)
+ 用於綠色服務修訂版的替代目標群組 (新服務修訂版)

兩個目標群組都應使用下列設定進行設定：
+ 目標類型：`ip` (適用於 Fargate 或使用 `awsvpc` 網路模式的 EC2)
+ 通訊協定：`TCP` (或應用程式使用的通訊協定)
+ 連接埠：應用程式監聽的連接埠 (對於 HTTP 通常為 `80`)
+ VPC：與 Amazon ECS 任務相同的 VPC
+ 運作狀態檢查設定：設定為正確檢查應用程式的運作狀態

  對於 TCP 運作狀態檢查，Network Load Balancer 會與目標建立 TCP 連線。如果連線成功，則目標會視為運作狀態良好。

  對於 HTTP/HTTPS 運作狀態檢查，Network Load Balancer 會將 HTTP/HTTPS 請求傳送至目標，並驗證回應。

在藍/綠部署期間，Amazon ECS 會根據部署階段，自動向相應的目標群組註冊任務。

**Example 為 Network Load Balancer 建立目標群組**  
下列 AWS CLI 命令會建立兩個目標群組，以便在藍/綠部署中與 Network Load Balancer 搭配使用：  

```
aws elbv2 create-target-group \
    --name blue-target-group \
    --protocol TCP \
    --port 80 \
    --vpc-id vpc-abcd1234 \
    --target-type ip \
    --health-check-protocol TCP

aws elbv2 create-target-group \
    --name green-target-group \
    --protocol TCP \
    --port 80 \
    --vpc-id vpc-abcd1234 \
    --target-type ip \
    --health-check-protocol TCP
```

## Network Load Balancer
<a name="nlb-load-balancer"></a>

您需要建立包含下列組態的 Network Load Balancer：
+ 結構描述：面向網際網路或內部，視要求而定
+ IP 位址類型：IPv4
+ VPC：與 Amazon ECS 任務相同的 VPC
+ 子網路：至少兩個位於不同可用區域的子網路

與 Application Load Balancer 不同，Network Load Balancer 會在傳輸層 (第 4 層) 運作，並且不會使用安全群組。反之，您需要確保與 Amazon ECS 任務相關聯的安全群組允許來自接聽程式連接埠上 Network Load Balancer 的流量。

**Example 建立 Network Load Balancer**  
下列 AWS CLI 命令會建立 Network Load Balancer 以用於藍/綠部署：  

```
aws elbv2 create-load-balancer \
    --name my-network-load-balancer \
    --type network \
    --subnets subnet-12345678 subnet-87654321
```

## 搭配藍/綠部署使用 NLB 的考量
<a name="nlb-considerations"></a>

搭配藍/綠部署使用 Network Load Balancer 時，請考量下列事項：
+ **第 4 層運作**：Network Load Balancer 會在傳輸層 (第 4 層) 運作，且不會檢查應用程式層 (第 7 層) 的內容。這表示您無法使用 HTTP 標頭或路徑作出路由決策。
+ **運作狀態檢查**：Network Load Balancer 運作狀態檢查僅限於 TCP、HTTP 或 HTTPS 通訊協定。對於 TCP 運作狀態檢查，Network Load Balancer 僅會驗證是否可以建立連線。
+ **連線保留**：Network Load Balancer 會保留用戶端的來源 IP 位址，這對於安全與記錄用途非常有用。
+ **靜態 IP 位址**：Network Load Balancer 會為每個子網路提供靜態 IP 位址，這在需要列入允許清單或用戶端需要連線至固定 IP 位址時非常有用。
+ **測試流量**：由於 Network Load Balancer 不支援以內容為基礎的路由，測試流量必須傳送至與生產流量不同的連接埠。

## 接聽程式和規則
<a name="nlb-listeners"></a>

對於搭配 Network Load Balancer 使用的藍/綠部署，您需要設定接聽程式：
+ 生產接聽程式：處理生產流量 (通常位於連接埠 80 或 443)
  + 最初將流量轉送至主要目標群組 (藍色服務修訂版)
  + 部署之後，將流量轉送至替代目標群組 (綠色服務修訂版)
+ 測試接聽程式 (選用)：處理測試流量，以在轉移生產流量之前驗證綠色服務修訂版
  + 可以在不同的連接埠上設定 (例如 8080 或 8443)
  + 在測試期間將流量轉送至替代目標群組 (綠色服務修訂版)

與 Application Load Balancer 不同，Network Load Balancer 不支援以內容為基礎的路由規則。反之，流量會根據接聽程式連接埠與通訊協定進行路由。

下列 AWS CLI 命令會建立 Network Load Balancer 的生產和測試接聽程式：

將 *user-input* 取代為實際值。

```
aws elbv2 create-listener \
    --load-balancer-arn arn:aws:elasticloadbalancing:region:123456789012:loadbalancer/net/my-network-lb/1234567890123456 \
    --protocol TCP \
    --port 80 \
    --default-actions Type=forward, TargetGroupArn=arn:aws:elasticloadbalancing:region:123456789012:targetgroup/blue-target-group/1234567890123456

aws elbv2 create-listener \
    --load-balancer-arn arn:aws:elasticloadbalancing:region:123456789012:loadbalancer/net/my-network-lb/1234567890123456 \
    --protocol TCP \
    --port 8080 \
    --default-actions Type=forward, TargetGroupArn=arn:aws:elasticloadbalancing:region:123456789012:targetgroup/green-target-group/1234567890123456
```

## 服務組態
<a name="nlb-service-configuration"></a>

您必須擁有許可，才能允許 Amazon ECS 代表您管理叢集中的負載平衡器資源。如需詳細資訊，請參閱[負載平衡器的 Amazon ECS 基礎結構 IAM 角色](AmazonECSInfrastructureRolePolicyForLoadBalancers.md)。

為搭配 Network Load Balancer 使用的藍/綠部署建立或更新 Amazon ECS 服務時，需要指定下列組態：

將 *user-input* 取代為實際值。

此組態中的關鍵元件包括：
+ `targetGroupArn`：主要目標群組的 ARN (藍色服務修訂版)
+ `alternateTargetGroupArn`：替代目標群組的 ARN (綠色服務修訂版)
+ `productionListenerRule`：用於生產流量的接聽程式 ARN
+ `testListenerRule`：(選用) 用於測試流量的接聽程式 ARN
+ `roleArn`：允許 Amazon ECS 管理 Network Load Balancer 資源的角色 ARN
+ `strategy`：設定為 `BLUE_GREEN` 以啟用藍/綠部署
+ `bakeTimeInMinutes`：生產流量轉移後，藍色和綠色服務修訂同時執行的持續時間

```
{
    "loadBalancers": [
        {
            "targetGroupArn": "arn:aws:elasticloadbalancing:region:123456789012:targetgroup/blue-target-group/1234567890123456",
            "containerName": "container-name",
            "containerPort": 80,
            "advancedConfiguration": {
                "alternateTargetGroupArn": "arn:aws:elasticloadbalancing:region:123456789012:targetgroup/green-target-group/1234567890123456",
                "productionListenerRule": "arn:aws:elasticloadbalancing:region:123456789012:listener/net/my-network-lb/1234567890123456/1234567890123456",
                "testListenerRule": "arn:aws:elasticloadbalancing:region:123456789012:listener/net/my-network-lb/1234567890123456/2345678901234567",
                "roleArn": "arn:aws:iam::123456789012:role/ecs-nlb-role"
            }
        }
    ],
    "deploymentConfiguration": {
        "strategy": "BLUE_GREEN",
        "maximumPercent": 200,
        "minimumHealthyPercent": 100,
        "bakeTimeInMinutes": 5
    }
}
```

## 部署期間的流量流程
<a name="nlb-traffic-flow"></a>

在搭配 Network Load Balancer 使用藍/綠部署期間，流量會流經系統，如下所示：

1. *初始狀態*：所有生產流量都會路由至主要目標群組 (藍色服務修訂版)。

1. *綠色服務修訂版部署*：Amazon ECS 會部署新任務，並向替代目標群組註冊新任務。

1. *測試流量*：如果已設定測試接聽程式，則測試流量會路由至替代目標群組，以驗證綠色服務修訂版。

1. *生產流量轉移*：Amazon ECS 會更新生產接聽程式，將流量路由至替代目標群組 (綠色服務修訂版)。

1. *封裝時間*：在生產流量轉移後，藍色與綠色服務修訂版同時執行的持續時間。

1. *完成*：成功部署後，藍色服務修訂版會終止。

如果在部署期間偵測到問題，Amazon ECS 可以透過將流量路由回主要目標群組 (藍色服務修訂版) 實現自動復原。

# Amazon ECS 藍色/綠色、線性和 Canary 部署的 Service Connect 資源
<a name="service-connect-blue-green"></a>

搭配藍/綠部署使用 Service Connect 時，您需要設定特定元件，才能啟用藍色與綠色服務修訂版之間適當的流量路由。本節說明必要的元件及其組態。

## 架構概觀
<a name="service-connect-blue-green-architecture"></a>

Service Connect 透過自動注入 Amazon ECS 任務的受管邊車代理，建置服務探索與服務網格功能。這些代理處理路由決策、重試和指標收集，同時 AWS Cloud Map 提供 服務登錄後端。當您在啟用 Service Connect 的情況下部署服務時，服務會自行註冊 AWS Cloud Map，而用戶端服務會透過 命名空間探索該服務。

在標準 Service Connect 實作中，用戶端服務會連線至邏輯服務名稱，而邊車代理則會處理路由至實際服務執行個體的作業。在藍/綠部署中，此模型會透過 `testTrafficRules` 組態擴展為包含測試流量路由。

在藍/綠部署期間，下列關鍵元件可搭配運作：
+ **Service Connect Proxy**：服務之間的所有流量都會通過 Service Connect Proxy，這會根據組態作出路由決策。
+ **AWS Cloud Map 註冊**：藍色和綠色部署都會向 註冊 AWS Cloud Map，但綠色部署最初會註冊為「測試」端點。
+ **測試流量路由**：Service Connect 組態中的 `testTrafficRules` 決定了如何識別測試流量並將其路由至綠色部署。這是透過**以標頭為基礎的路由**實現，請求中的特定 HTTP 標頭會將流量導向測試修訂版。依預設，當未指定自訂規則時，Service Connect 會識別以 HTTP 為基礎的通訊協定的 `x-amzn-ecs-blue-green-test` 標頭。
+ **用戶端組態**：命名空間中的所有用戶端都會自動接收生產與測試路由，但只有符合測試規則的請求才會傳送至綠色部署。

這種方法的強大之處在於，它處理了轉移期間複雜的服務探索問題。隨著流量從藍色部署轉移到綠色部署，所有連線與探索機制都會自動更新。無需單獨更新 DNS 記錄、重新設定負載平衡器或部署服務探索變更，因為服務網格會處理所有工作。

## 流量路由與測試
<a name="service-connect-blue-green-traffic-routing"></a>

Service Connect 為藍/綠部署提供進階的流量路由功能，包括以標頭為基礎的路由與用於測試案例的用戶端別名組態。

### 測試流量標頭規則
<a name="service-connect-test-traffic-header-rules"></a>

在藍/綠部署期間，您可以設定測試流量標頭規則，將特定請求路由至綠色 (新) 服務修訂版以供測試之用。這可讓您在完成部署之前，使用受控流量驗證新版本。

Service Connect 使用**以標頭為基礎的路由**來識別測試流量。依預設，當未指定自訂規則時，Service Connect 會識別以 HTTP 為基礎的通訊協定的 `x-amzn-ecs-blue-green-test` 標頭。當請求中出現此標頭時，Service Connect Proxy 會自動將請求路由至綠色部署進行測試。

測試流量標頭規則可讓您：
+ 將具有特定標頭的請求路由至綠服務修訂版
+ 使用流量子集測試新功能
+ 在流量完全切換之前驗證服務行為
+ 實作 Canary 測試策略
+ 在類似生產的環境中執行整合測試

以標頭為基礎的路由機制可與現有應用程式架構無縫搭配運作。用戶端服務無需了解藍綠部署程序，只需在傳送測試請求時包含相應的標頭，Service Connect Proxy 就會自動處理路由邏輯。

如需有關設定測試流量標頭規則的詳細資訊，請參閱 *Amazon Elastic Container Service API Reference* 中的 [ServiceConnectTestTrafficHeaderRules](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ServiceConnectTestTrafficHeaderRules.html)。

### 標頭比對規則
<a name="service-connect-header-match-rules"></a>

標頭比對規則定義了藍/綠部署期間路由測試流量的準則。您可以設定多個比對條件，以精確控制哪些請求要路由至綠服務修訂版。

標頭比對支援：
+ 精確標頭值比對
+ 檢查標頭是否存在
+ 模式型比對
+ 多個標頭組合

範例使用案例包括將具有特定使用者代理字串、API 版本或功能旗標的請求路由至綠服務，以進行測試。

如需有關標頭比對組態的詳細資訊，請參閱 *Amazon Elastic Container Service API Reference* 中的 [ServiceConnectTestTrafficHeaderMatchRules](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ServiceConnectTestTrafficHeaderMatchRules.html)。

### 用於藍/綠部署的用戶端別名
<a name="service-connect-client-alias-blue-green"></a>

用戶端別名可在藍/綠部署期間為服務提供穩定的 DNS 端點。這些別名可在藍色與綠色服務修訂版之間實現無縫流量路由，而無需用戶端應用程式變更其連線端點。

在藍/綠部署期間，用戶端別名會：
+ 為用戶端連線維持一致的 DNS 名稱
+ 啟用服務修訂版之間的自動流量切換
+ 支援漸進式流量遷移策略
+ 透過將流量重新導向至藍色修訂版，提供復原功能

您可以為不同的連接埠或通訊協定設定多個用戶端別名，讓複雜的服務架構在部署期間維持連線能力。

如需有關用戶端別名組態的詳細資訊，請參閱 *Amazon Elastic Container Service API Reference* 中的 [ServiceConnectClientAlias](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ServiceConnectClientAlias.html)。

### 流量路由最佳實務
<a name="service-connect-blue-green-best-practices"></a>

使用 Service Connect 實作藍/綠部署的流量路由時，請考量下列最佳實務：
+ **從標頭型測試開始著手**：先使用測試流量標頭規則透過受控流量來驗證綠服務，再切換所有流量。
+ **設定運作狀態檢查**：確保藍色與綠色服務均已設定相應的運作狀態檢查，防止將流量路由至運作狀態不良的執行個體。
+ **監控服務指標**：在部署期間追蹤兩個服務修訂版的關鍵績效指標，以及早識別問題。
+ **規劃復原策略**：設定用戶端別名與路由規則，以便在偵測到問題時能夠快速復原至藍色服務。
+ **測試標頭比對邏輯**：先在非生產環境中驗證您的標頭比對規則，再將規則套用至生產部署。

## Service Connect 藍/綠部署工作流程
<a name="service-connect-blue-green-workflow"></a>

了解 Service Connect 如何管理藍/綠部署程序，可協助有效地實作部署並對其進行疑難排解。下列工作流程展示了不同元件如何在部署的每個階段互動。

### 部署階段
<a name="service-connect-deployment-phases"></a>

Service Connect 藍/綠部署會經歷數個不同的階段：

1. **初始狀態**：藍色服務處理 100% 的生產流量。命名空間中的所有用戶端服務會透過 Service Connect 中設定的邏輯服務名稱連線至藍色服務。

1. **Green Service Registration**：當綠色部署開始時，它會向 註冊 AWS Cloud Map 為「測試」端點。用戶端服務中的 Service Connect Proxy 會自動接收生產與測試路由組態。

1. **測試流量路由**：包含測試流量標頭 (例如 `x-amzn-ecs-blue-green-test`) 的請求會由 Service Connect Proxy 自動路由至綠色服務。生產流量會繼續流向藍色服務。

1. **流量轉移準備**：成功測試後，部署程序會準備進行生產流量轉移。藍色與綠色服務都會保持註冊狀態且運作狀態良好。

1. **生產流量轉移**：Service Connect 組態會更新，將生產流量路由至綠色服務。此動作會自動發生，無需更新用戶端服務或變更 DNS。

1. **封裝時間段**：在生產流量轉移後，藍色與綠色服務修訂版同時執行的持續時間。

1. **藍色服務取消註冊**：在成功的流量轉移和驗證之後，藍色服務會從 取消註冊 AWS Cloud Map 並終止，完成部署。

### Service Connect Proxy 行為
<a name="service-connect-proxy-behavior"></a>

Service Connect Proxy 在管理藍/綠部署期間的流量方面起著重要作用。了解其行為可協助您設計有效的測試與部署策略。

藍/綠部署期間的關鍵代理行為：
+ **自動路由探索**：代理會自動探索來自 的生產和測試路由 AWS Cloud Map ，而不需要重新啟動應用程式或變更組態。
+ **以標頭為基礎的路由**：代理會檢查傳入的請求標頭，並根據設定的測試流量規則將流量路由至相應的服務修訂版。
+ **運作狀態檢查整合**：代理僅會將流量路由至運作狀態良好的服務執行個體，自動從路由集區中排除運作狀態不良的任務。
+ **重試與斷路器**：代理會提供內建的重試邏輯與斷路器功能，從而改善部署期間的恢復能力。
+ **指標收集**：代理會收集藍色與綠色服務的詳細指標，以便在部署期間進行全面監控。

### 服務探索更新
<a name="service-connect-service-discovery-updates"></a>

使用 Service Connect 進行藍/綠部署的其中一個主要優勢是自動處理服務探索更新。傳統的藍/綠部署通常需要複雜的 DNS 更新或負載平衡器重新設定，但 Service Connect 會透明地管理這些變更。

在部署期間，Service Connect 會處理：
+ **命名空間更新**：Service Connect 命名空間會自動包含藍色與綠色服務端點，並具有相應的路由規則。
+ **用戶端組態**：命名空間中的所有用戶端服務會自動接收更新後的路由資訊，無需重新啟動或重新部署。
+ **逐步轉移**：服務探索更新會逐步且安全地進行，確保不會中斷正在進行的請求。
+ **復原支援**：如果需要復原，Service Connect 可以快速還原服務探索組態，將流量路由回藍色服務。

# 建立 Amazon ECS 藍/綠部署
<a name="deploy-blue-green-service"></a>

 透過使用 Amazon ECS 藍/綠部署，您可以進行服務變更並加以測試，然後在生產環境中實作這些變更。

## 先決條件
<a name="deploy-blue-green-service-prerequisites"></a>

開始藍/綠部署之前，請執行下列動作。

1. 設定相應的許可。
   + 如需有關 Elastic Load Balancing 許可的資訊，請參閱[負載平衡器的 Amazon ECS 基礎結構 IAM 角色](AmazonECSInfrastructureRolePolicyForLoadBalancers.md)。
   + 如需有關 Lambda 許可的資訊，請參閱 [Amazon ECS 藍/綠部署中 Lambda 函式所需的許可](blue-green-permissions.md)

1. Amazon ECS 藍/綠部署要求服務使用下列其中一項功能：設定相應的資源。
   + Application Load Balancer – 如需詳細資訊，請參閱[藍/綠、線性和金絲雀部署的 Application Load Balancer 資源](alb-resources-for-blue-green.md)。
   + Network Load Balancer – 如需詳細資訊，請參閱[Amazon ECS 藍/綠、線性和 Canary 部署的 Network Load Balancer 資源](nlb-resources-for-blue-green.md)。
   + Service Connect – 如需詳細資訊，請參閱[Amazon ECS 藍色/綠色、線性和 Canary 部署的 Service Connect 資源](service-connect-blue-green.md)。

1. 決定是否要執行生命週期階段的 Lambda 函數。
   + PRE\$1SCALE\$1UP
   + POST\$1SCALE\$1UP
   + TEST\$1TRAFFIC\$1SHIFT
   + POST\$1TEST\$1TRAFFIC\$1SHIFT
   + PRODUCTION\$1TRAFFIC\$1SHIFT
   + POST\$1PRODUCTION\$1TRAFFIC\$1SHIFT

   如需詳細資訊，請參閱 *AWS Lambda Developer Guide* 中的 [Create a Lambda function with the console](https://docs.aws.amazon.com/lambda/latest/dg/getting-started.html#getting-started-create-function)。

## 程序
<a name="deploy-blue-green-service-procedure"></a>

您可以使用 主控台或 AWS CLI 來建立 Amazon ECS 藍/綠服務。

------
#### [ Console ]

1. 開啟主控台，網址為 [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)。

1. 決定您要從中啟動服務的資源。    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/AmazonECS/latest/developerguide/deploy-blue-green-service.html)

   **建立服務**頁面隨即顯示。

1. 在**服務詳細資訊**下，執行下列動作：

   1. 在**任務定義系列**欄位中選擇要使用的任務定義。然後，在**任務定義修訂版**欄位中輸入要使用的修訂版。

   1. 針對 **Service name** (服務名稱)，輸入服務的名稱。

1. 若要在現有叢集中執行服務，請在**現有叢集**欄位中選擇叢集。若要在新叢集中執行服務，請選擇**建立叢集** 

1. 選擇任務在叢集基礎結構中的分佈方式。在**運算組態**下選擇選項。    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/AmazonECS/latest/developerguide/deploy-blue-green-service.html)

1. 在**部署組態**下，執行下列動作：

   1. 在**服務類型**欄位中選擇**複本**。

   1. 針對 **Desired tasks** (所需任務)，輸入要在服務中啟動並維護的任務數。

   1. 若要讓 Amazon ECS 監控可用區域間的任務分佈，並在出現不平衡時重新分佈，請在**可用區域服務重新平衡**下，選取**可用區域服務重新平衡**。

   1. 在**運作狀態檢查寬限期**欄位中，輸入時間 (以秒為單位)，這是服務排程器在任務首次啟動後忽略運作狀態不良的 Elastic Load Balancing、VPC Lattice 與容器運作狀態檢查的時間。如果您未指定運作狀態檢查寬限期間值，則會使用預設值 0。

1. 

   1. 在**封裝時間**欄位中，輸入在藍色修訂版終止之前，藍色與綠色服務修訂版將同時執行的分鐘數。這為驗證與測試提供了時間。

   1. (選用) 執行要在部署的特定階段執行的 Lambda 函式。在**部署 lifecycle hook** 下，選取要執行 lifecycle hook 的階段。

      若要新增 lifecycle hook：

      1. 選擇**新增**。

      1. 在 **Lambda 函式**欄位中，輸入函式名稱或 ARN。

      1. 在**角色**欄位中，選取具有調用 Lambda 函式許可的 IAM 角色。

      1. 在**生命週期階段**欄位中，選取 Lambda 函式應執行的階段。

1. 若要設定 Amazon ECS 如何偵測並處理部署失敗，請展開 **Deployment failure detection** (部署失敗偵測)，然後選擇您的選項。

   1. 若要在任務無法啟動時停止部署，請選取 **Use the Amazon ECS deployment circuit breaker** (使用 Amazon ECS 部署斷路器)。

      在部署斷路器將部署設定為失敗狀態時，若要讓軟體自動將部署復原至上次完成的部署狀態，請選取**失敗時復原**。

   1. 若要根據應用程式指標停止部署，請選取**使用 CloudWatch 警示**。然後，從**CloudWatch 警示名稱**欄位中選擇警示。要建立新的警示，請前往 CloudWatch 主控台。

      在 CloudWatch 警示將部署設定為失敗狀態時，若要讓軟體自動將部署復原至上次完成的部署狀態，請選取**失敗時復原**。

1. (選用) 若要使用 Service Connect 與服務互連，請展開 **Service Connect** 區段，然後指定下列項目：

   1.  選取**開啟 Service Connect**。

   1. 在 **Service Connect configuration** (Service Connect 組態) 下，指定用戶端模式。
      + 如果服務執行的網路用戶端應用程式只需要連線至命名空間中的其他服務，請選擇**僅用戶端**。
      + 如果服務執行的是網路或 Web 服務應用程式，且需要為此服務提供端點，並連線至命名空間中的其他服務，請選擇 **Client and server** (用戶端和伺服器)。

   1. 若要使用非預設叢集命名空間的命名空間，請在 **Namespace** (命名空間) 欄位中選擇服務命名空間。這可以是在您的 中在相同 AWS 區域 中分別建立的命名空間， AWS 帳戶 或是使用 AWS Resource Access Manager () 與您的帳戶共用的相同區域中的命名空間AWS RAM。如需共用 AWS Cloud Map 命名空間的詳細資訊，請參閱《 *AWS Cloud Map 開發人員指南*》中的[跨帳戶 AWS Cloud Map 命名空間共用](https://docs.aws.amazon.com/cloud-map/latest/dg/sharing-namespaces.html)。

   1. (選用) 設定藍/綠部署的測試流量標頭規則。在**測試流量路由**下，指定下列項目：

      1. 選取**啟用測試流量標頭規則**，以在測試期間將特定請求路由至綠色服務修訂版。

      1. 在**標頭比對規則**欄位中，設定路由測試流量的條件：
         + **標頭名稱**：輸入要比對的 HTTP 標頭名稱 (例如 `X-Test-Version` 或 `User-Agent`)。
         + **比對類型**：選擇比對條件：
           + **完全相符**：標頭值與指定值完全相符的路由請求
           + **標頭存在**：包含指定標頭的路由請求，無論其值為何
           + **模式比對**：標頭值與指定模式相符的路由請求
         + **標頭值** (如果使用「完全相符」或「模式相符」)：輸入要比對的值或模式。

         您可以新增多個標頭比對規則來建立複雜的路由邏輯。符合任何已設定規則的請求將路由至綠色服務修訂版進行測試。

      1. 選擇**新增標頭規則**以設定其他標頭比對條件。
**注意**  
測試流量標頭規則讓您可以在完成完整部署之前，使用受控流量驗證新功能。這允許您使用特定請求 (例如來自內部測試工具或 Beta 版使用者的請求) 測試綠色服務修訂版，同時維持流向藍色服務修訂版的正常流量流程。

   1. (選用) 指定日誌組態。選取**使用日誌收集**。預設選項會將容器日誌傳送至 CloudWatch 日誌。其他日誌驅動程式選項是使用 AWS FireLens 設定。如需詳細資訊，請參閱[將 Amazon ECS 日誌傳送至 AWS 服務或 AWS Partner](using_firelens.md)。

      下方更詳細地描述了每個容器日誌目的地。
      + **Amazon CloudWatch** – 將任務設定為將容器日誌傳送至 CloudWatch Logs。系統會提供預設日誌驅動程式選項，用來代表您建立 CloudWatch 日誌群組。若要指定不同的日誌群組名稱，請變更驅動程式選項值。
      + **Amazon Data Firehose** – 將任務設定為將容器日誌傳送至 Firehose。系統會提供預設日誌驅動程式選項，用來將日誌傳送至 Firehose 傳送串流。若要指定不同的交付串流名稱，請變更驅動程式選項值。
      + **Amazon Kinesis Data Streams** – 將任務設定為將容器日誌傳送至 Amazon Kinesis Data Streams。系統會提供預設日誌驅動程式選項，用來將日誌傳送至 Kinesis Data Streams 串流。若要指定不同的串流名稱，請變更驅動程式選項值。
      + **Amazon OpenSearch Service** – 將任務設定為將容器日誌傳送至 OpenSearch Service 網域。務必提供日誌驅動程式選項。
      + **Amazon S3**：將任務設定為將容器日誌傳送至 Amazon S3 儲存貯體。系統會提供預設日誌驅動程式選項，但您必須指定有效的 Amazon S3 儲存貯體名稱。

1. (選用) 設定藍/綠部署的**負載平衡**。    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/AmazonECS/latest/developerguide/deploy-blue-green-service.html)

1. (選用) 為協助識別您的服務和任務，請展開 **Tags** (標籤) 區段，然後設定標籤。

   若要讓 Amazon ECS 使用叢集名稱和任務定義標籤，自動標記所有新啟動的任務，請選取 **Turn on Amazon ECS managed tags** (開啟 Amazon ECS 受管標籤)，然後針對 **Propagate tags from** (傳播標籤來源)，選取 **Task definitions** (任務定義)。

   若要讓 Amazon ECS 使用叢集名稱和服務標籤，自動標記所有新啟動的任務，請選取 **Turn on Amazon ECS managed tags** (開啟 Amazon ECS 受管標籤)，然後針對 **Propagate tags from** (傳播標籤來源)，選取 **Service** (服務)。

   新增或移除標籤。
   + [新增標籤] 選擇**新增標籤**，然後執行下列操作︰
     + 在**索引鍵**中，輸入索引鍵名稱。
     + 在**值**中，進入索引鍵值。
   + [移除標籤] 在標籤旁邊，選擇**移除標籤**。

1. 選擇**建立**。

------
#### [ AWS CLI ]

1. 建立名為 `service-definition.json` 且具有下列內容的檔案。

   將 *user-input* 取代為實際值。

   ```
   {
     "serviceName": "myBlueGreenService",
     "cluster": "arn:aws:ecs:us-west-2:123456789012:cluster/sample-fargate-cluster",
     "taskDefinition": "sample-fargate:1",
     "desiredCount": 5,
     "launchType": "FARGATE",
     "networkConfiguration": {
       "awsvpcConfiguration": {
         "subnets": [
           "subnet-09ce6e74c116a2299",
           "subnet-00bb3bd7a73526788",
           "subnet-0048a611aaec65477"
         ],
         "securityGroups": [
           "sg-09d45005497daa123"
         ],
         "assignPublicIp": "ENABLED"
       }
     },
     "deploymentController": {
       "type": "ECS"
     },
     "deploymentConfiguration": {
       "strategy": "BLUE_GREEN",
       "maximumPercent": 200,
       "minimumHealthyPercent": 100,
       "bakeTimeInMinutes": 2,
       "alarms": {
         "alarmNames": [
           "myAlarm"
         ],
         "rollback": true,
         "enable": true
       },
       "lifecycleHooks": [
         {
           "hookTargetArn": "arn:aws:lambda:us-west-2:7123456789012:function:checkExample",
           "roleArn": "arn:aws:iam::123456789012:role/ECSLifecycleHookInvoke",
           "lifecycleStages": [
             "PRE_SCALE_UP"
           ]
         }
       ]
     },
     "loadBalancers": [
       {
         "targetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/blue-target-group/54402ff563af1197",
         "containerName": "fargate-app",
         "containerPort": 80,
         "advancedConfiguration": {
           "alternateTargetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/green-target-group/cad10a56f5843199",
           "productionListenerRule": "arn:aws:elasticloadbalancing:us-west-2:123456789012:listener-rule/app/my-blue-green-demo/32e0e4f946c3c05b/9cfa8c482e204f7d/831dbaf72edb911",
           "roleArn": "arn:aws:iam::123456789012:role/LoadBalancerManagementforECS"
         }
       }
     ]
   }
   ```

1. 執行 `create-service`。

   將 *user-input* 取代為實際值。

   ```
   aws ecs create-service --cli-input-json file://service-definition.json
   ```

   或者，您可以使用下列範例來建立具有負載平衡器組態的藍/綠部署服務：

   ```
   aws ecs create-service \
      --cluster "arn:aws:ecs:us-west-2:123456789012:cluster/MyCluster" \
      --service-name "blue-green-example-service" \
      --task-definition "nginxServer:1" \
      --launch-type "FARGATE" \
      --network-configuration "awsvpcConfiguration={subnets=[subnet-12345,subnet-67890,subnet-abcdef,subnet-fedcba],securityGroups=[sg-12345],assignPublicIp=ENABLED}" \
      --desired-count 3 \
      --deployment-controller "type=ECS" \
      --deployment-configuration "strategy=BLUE_GREEN,maximumPercent=200,minimumHealthyPercent=100,bakeTimeInMinutes=0" \
      --load-balancers "targetGroupArn=arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/MyBGtg1/abcdef1234567890,containerName=nginx,containerPort=80,advancedConfiguration={alternateTargetGroupArn=arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/MyBGtg2/0987654321fedcba,productionListenerRule=arn:aws:elasticloadbalancing:us-west-2:123456789012:listener-rule/app/MyLB/1234567890abcdef/1234567890abcdef,roleArn=arn:aws:iam::123456789012:role/ELBManagementRole}"
   ```

------

## 後續步驟
<a name="deploy-blue-green-service-next-steps"></a>
+ 更新服務以開始部署。如需詳細資訊，請參閱[更新 Amazon ECS 服務](update-service-console-v2.md)。
+ 監控部署程序，確保其遵循藍/綠模式：
  + 綠色服務修訂版已建立並向上擴展
  + 測試流量會路由至綠色修訂版 (若已設定)
  + 生產流量會轉移至綠色修訂版
  + 封裝時間過期後，藍色修訂版會終止

# 對 Amazon ECS 藍/綠部署進行疑難排解
<a name="troubleshooting-blue-green"></a>

下列內容提供搭配 Amazon ECS 使用藍/綠部署時可能遇到的常見問題的解決方案。藍/綠部署錯誤可能會發生在下列階段：
+ *同步路徑*：在回應 `CreateService` 或 `UpdateService` API 呼叫時立即出現的錯誤。
+ *非同步路徑*：出現在 `DescribeServiceDeployments` 的 `statusReason` 欄位中並導致部署復原的錯誤

**提示**  
您可以[Amazon ECS MCP 伺服器](ecs-mcp-introduction.md)搭配 AI 助理使用 來監控部署，並使用自然語言疑難排解部署問題。

## 負載平衡器組態問題
<a name="troubleshooting-blue-green-load-balancer"></a>

負載平衡器組態是 Amazon ECS 中藍/綠部署的關鍵元件。正確設定接聽程式規則、目標群組與負載平衡器類型，對於成功部署至關重要。本節涵蓋可能導致藍/綠部署失敗的常見負載平衡器組態問題。

對負載平衡器問題進行疑難排解時，務必了解接聽程式規則與目標群組之間的關係。在藍/綠部署中：
+ 生產接聽程式規則會將流量導向目前作用中的 (藍色) 服務修訂版
+ 測試接聽程式規則可用於在轉移生產流量之前驗證新的 (綠色) 服務修訂版
+ 目標群組用於註冊每個服務修訂版中的容器執行個體
+ 部署期間，流量會透過調整接聽程式規則中目標群組的權重，逐漸從藍色服務修訂版轉移至綠色服務修訂版

### 接聽程式規則組態錯誤
<a name="troubleshooting-blue-green-listener-rules"></a>

下列問題與藍/綠部署的接聽程式規則組態不正確有關。

使用 Application Load Balancer 接聽程式 ARN 而非接聽程式規則 ARN  
*錯誤訊息*：`productionListenerRule has an invalid ARN format. Must be RuleArn for ALB or ListenerArn for NLB. Got: arn:aws:elasticloadbalancing:us-west-2:123456789012:listener/app/my-alb/abc123/def456`  
*解決方案*：使用 Application Load Balancer 時，必須為 `productionListenerRule` 與 `testListenerRule` 指定接聽程式規則 ARN，而不是接聽程式 ARN。對於 Network Load Balancer，必須使用接聽程式 ARN。  
 如需有關如何查找接聽程式 ARN 的資訊，請參閱 *Application Load Balancer User Guide* 中的 [Listeners for your Application Load Balancers](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-https-listener.html)。規則的 ARN 格式為 `arn:aws:elasticloadbalancing:region:account-id:listener-rule/app/...`。

為生產與測試接聽程式使用相同的規則  
*錯誤訊息*：`The following rules cannot be used as both production and test listener rules: arn:aws:elasticloadbalancing:us-west-2:123456789012:listener-rule/app/my-alb/abc123/def456/ghi789`  
*解決方案*：生產流量與測試流量必須使用不同的接聽程式規則。為路由至測試目標群組的測試流量建立單獨的接聽程式規則。

目標群組未與接聽程式規則建立關聯  
*錯誤訊息*：`Service deployment rolled back because of invalid networking configuration: Target group arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/myAlternateTG/abc123 is not associated with either productionListenerRule or testListenerRule.`  
*解決方案*：主要目標群組與替代目標群組都必須與生產接聽程式規則或測試接聽程式規則建立關聯。更新負載平衡器組態，確保兩個目標群組皆與接聽程式規則正確建立關聯。

Application Load Balancer 缺少測試接聽程式規則  
*錯誤訊息*：`For Application LoadBalancer, testListenerRule is required when productionListenerRule is not associated with both targetGroup and alternateTargetGroup`  
*解決方案*：使用 Application Load Balancer 時，如果兩個目標群組都未與生產接聽程式規則建立關聯，則必須指定測試接聽程式規則。將 `testListenerRule` 新增至組態，並確保兩個目標群組皆與生產或測試接聽程式規則建立關聯。如需詳細資訊，請參閱 *Application Load Balancer User Guide* 中的 [Listeners for your Application Load Balancers](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-https-listener.html)。

### 目標群組組態錯誤
<a name="troubleshooting-blue-green-target-groups"></a>

下列問題與藍/綠部署的目標群組組態不正確有關。

接聽程式規則中存在多個具有流量的目標群組  
*錯誤訊息*：`Service deployment rolled back because of invalid networking configuration. productionListenerRule arn:aws:elasticloadbalancing:us-west-2:123456789012:listener-rule/app/my-alb/abc123/def456/ghi789 should have exactly one target group serving traffic but found 2 target groups which are serving traffic`  
*解決方案*：在開始藍/綠部署之前，請確保接聽程式規則中只有一個目標群組正在接收流量 (具有非零權重)。更新接聽程式規則組態，將不應接收流量的任何目標群組的權重設定為零。

負載平衡器項目中的重複目標群組  
*錯誤訊息*：`Duplicate targetGroupArn found: arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/myecs-targetgroup/abc123`  
*解決方案*：每個目標群組 ARN 在服務定義的所有負載平衡器項目中必須是唯一的。檢閱組態，並確保為每個負載平衡器項目使用不同的目標群組。

生產接聽程式規則中存在未預期的目標群組  
*錯誤訊息*：`Service deployment rolled back because of invalid networking configuration. Production listener rule is forwarding traffic to unexpected target group arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/random-nlb-tg/abc123. Expected traffic to be forwarded to either targetGroupArn: arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/nlb-targetgroup/def456 or alternateTargetGroupArn: arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/nlb-tg-alternate/ghi789`  
*解決方案*：生產接聽程式規則正在將流量轉送至服務定義中未指定的目標群組。確保將接聽程式規則設定為僅將流量轉送至服務定義中指定的目標群組。  
如需詳細資訊，請參閱 *Application Load Balancer User Guide* 中的 [forward actions](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-listeners.html#forward-actions)。

### 負載平衡器類型組態錯誤
<a name="troubleshooting-blue-green-load-balancer-types"></a>

下列問題與藍/綠部署的負載平衡器類型組態不正確有關。

混合使用 Classic Load Balancer 與 Application Load Balancer 或 Network Load Balancer 組態  
*錯誤訊息*：`All loadBalancers must be strictly either ELBv1 (defining loadBalancerName) or ELBv2 (defining targetGroupArn)`  
Classic Load Balancer 是 Elastic Load Balancing 的上一代負載平衡器。建議遷移至目前一代的負載平衡器。如需詳細資訊，請參閱 [Migrate your Classic Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/migrate-classic-load-balancer.html)。
*解決方案*：。使用所有 Classic Load Balancer 或所有 Application Load Balancer 與 Network Load Balancer。  
對於 Application Load Balancer 與 Network Load Balancer，僅指定 `targetGroupArn` 欄位。

搭配 Classic Load Balancer 使用進階組態  
*錯誤訊息*：`advancedConfiguration field is not allowed with ELBv1 loadBalancers`  
*解決方案*：只有 Application Load Balancer 與 Network Load Balancer 支援藍/綠部署的進階組態。如果使用 Classic Load Balancer (透過 `loadBalancerName` 指定)，則無法使用 `advancedConfiguration` 欄位。請切換到 Application Load Balancer，或移除 `advancedConfiguration` 欄位。

負載平衡器之間的進階組態不一致  
*錯誤訊息*：`Either all or none of the provided loadBalancers must have advancedConfiguration defined`  
*解決方案*：如果使用多個負載平衡器，則必須為所有負載平衡器定義 `advancedConfiguration`，或者都不定義。更新組態，確保所有負載平衡器項目的一致性。

藍/綠部署缺少進階組態  
*錯誤訊息*：`advancedConfiguration field is required for all loadBalancers when using a non-ROLLING deployment strategy`  
*解決方案*：搭配 Application Load Balancer 使用藍/綠部署策略時，必須為所有負載平衡器項目指定 `advancedConfiguration` 欄位。將所需的 `advancedConfiguration` 新增至負載平衡器組態。

## 許可問題
<a name="troubleshooting-blue-green-permissions"></a>

下列問題與藍/綠部署的許可不足有關。

基礎結構角色缺少信任政策  
*錯誤訊息*：`Service deployment rolled back because of invalid networking configuration. ECS was unable to manage the ELB resources due to missing permissions on ECS Infrastructure Role 'arn:aws:iam::123456789012:role/Admin'.`  
*解決方案*：指定用於管理負載平衡器資源的 IAM 角色沒有正確的信任政策。更新角色的信任政策，以允許服務擔任角色。信任政策必須包含：    
****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "ecs.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
```

負載平衡器角色缺少讀取許可  
*錯誤訊息*：`service myService failed to describe target health on target-group myTargetGroup with (error User: arn:aws:sts::123456789012:assumed-role/myELBRole/ecs-service-scheduler is not authorized to perform: elasticloadbalancing:DescribeTargetHealth because no identity-based policy allows the elasticloadbalancing:DescribeTargetHealth action)`  
*解決方案*：用於管理負載平衡器資源的 IAM 角色沒有讀取目標運作狀態資訊的許可。將 `elasticloadbalancing:DescribeTargetHealth` 許可新增至角色的政策。如需有關 Elastic Load Balancing 許可的資訊，請參閱[負載平衡器的 Amazon ECS 基礎結構 IAM 角色](AmazonECSInfrastructureRolePolicyForLoadBalancers.md)。

負載平衡器角色缺少寫入許可  
*錯誤訊息*：`service myService failed to register targets in target-group myTargetGroup with (error User: arn:aws:sts::123456789012:assumed-role/myELBRole/ecs-service-scheduler is not authorized to perform: elasticloadbalancing:RegisterTargets on resource: arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/myTargetGroup/abc123 because no identity-based policy allows the elasticloadbalancing:RegisterTargets action)`  
*解決方案*：用於管理負載平衡器資源的 IAM 角色沒有註冊目標的許可。將 `elasticloadbalancing:RegisterTargets` 許可新增至角色的政策。如需有關 Elastic Load Balancing 許可的資訊，請參閱[負載平衡器的 Amazon ECS 基礎結構 IAM 角色](AmazonECSInfrastructureRolePolicyForLoadBalancers.md)。

缺少修改接聽程式規則的許可  
*錯誤訊息*：`Service deployment rolled back because TEST_TRAFFIC_SHIFT lifecycle hook(s) failed. User: arn:aws:sts::123456789012:assumed-role/myELBRole/ECSNetworkingWithELB is not authorized to perform: elasticloadbalancing:ModifyListener on resource: arn:aws:elasticloadbalancing:us-west-2:123456789012:listener/app/my-alb/abc123/def456 because no identity-based policy allows the elasticloadbalancing:ModifyListener action`  
*解決方案*：用於管理負載平衡器資源的 IAM 角色沒有修改接聽程式的許可。將 `elasticloadbalancing:ModifyListener` 許可新增至角色的政策。如需有關 Elastic Load Balancing 許可的資訊，請參閱[負載平衡器的 Amazon ECS 基礎結構 IAM 角色](AmazonECSInfrastructureRolePolicyForLoadBalancers.md)。

對於藍/綠部署，建議將 `AmazonECS-ServiceLinkedRolePolicy` 受管政策連接至基礎結構角色，該角色包含管理負載平衡器資源的所有必要許可。

## Lifecycle hook 問題
<a name="troubleshooting-blue-green-lifecycle-hooks"></a>

下列問題與藍/綠部署中的 lifecycle hook 有關。

Lambda 勾點角色上的信任政策不正確  
*錯誤訊息*：`Service deployment rolled back because TEST_TRAFFIC_SHIFT lifecycle hook(s) failed. ECS was unable to assume role arn:aws:iam::123456789012:role/Admin`  
*解決方案*：為 Lambda lifecycle hook 指定的 IAM 角色沒有正確的信任政策。更新角色的信任政策，以允許服務擔任角色。信任政策必須包含：    
****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "ecs.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
```

Lambda 勾點傳回 FAILED 狀態  
*錯誤訊息*：`Service deployment rolled back because TEST_TRAFFIC_SHIFT lifecycle hook(s) failed. Lifecycle hook target arn:aws:lambda:us-west-2:123456789012:function:myHook returned FAILED status.`  
*解決方案*：指定為 lifecycle hook 的 Lambda 函式傳回了 FAILED 狀態。檢查 Amazon CloudWatch Logs 中的 Lambda 函式日誌以確定失敗原因，並更新函式以正確處理部署事件。

缺少調用 Lambda 函式的許可  
*錯誤訊息*：`Service deployment rolled back because TEST_TRAFFIC_SHIFT lifecycle hook(s) failed. ECS was unable to invoke hook target arn:aws:lambda:us-west-2:123456789012:function:myHook due to User: arn:aws:sts::123456789012:assumed-role/myLambdaRole/ECS-Lambda-Execution is not authorized to perform: lambda:InvokeFunction on resource: arn:aws:lambda:us-west-2:123456789012:function:myHook because no identity-based policy allows the lambda:InvokeFunction action`  
*解決方案*：用於 Lambda lifecycle hook 的 IAM 角色沒有調用 Lambda 函式的許可。將針對特定 Lambda 函式 ARN 的 `lambda:InvokeFunction` 許可新增至角色政策。如需有關 Lambda 許可的資訊，請參閱 [Amazon ECS 藍/綠部署中 Lambda 函式所需的許可](blue-green-permissions.md)。

Lambda 函式逾時或回應無效  
*錯誤訊息*：`Service deployment rolled back because TEST_TRAFFIC_SHIFT lifecycle hook(s) failed. ECS was unable to parse the response from arn:aws:lambda:us-west-2:123456789012:function:myHook due to HookStatus must not be null`  
*解決方案*：Lambda 函式逾時或傳回了無效的回應。確保 Lambda 函式傳回有效的回應，其中 `hookStatus` 欄位設定為 `SUCCEEDED` 或 `FAILED`。此外，檢查 Lambda 函式逾時是否已針對驗證邏輯適當設定。如需詳細資訊，請參閱[Amazon ECS 服務部署的 lifecycle hook](deployment-lifecycle-hooks.md)。  
有效 Lambda 回應範例：  

```
{
  "hookStatus": "SUCCEEDED",
  "reason": "Validation passed"
}
```

# Amazon ECS 線性部署
<a name="deployment-type-linear"></a>

線性部署會逐漸將流量從舊服務修訂版轉移到新的服務修訂版，隨著時間的推移以相等遞增，允許您監控每個步驟，然後再繼續進行下一個步驟。透過 Amazon ECS 線性部署，控制流量轉移的速度，並隨著生產流量的增加來驗證新的服務修訂。此方法提供一種可控制的方式來部署變更，並能夠監控每個增量的效能。

## 線性部署中涉及的資源
<a name="linear-deployment-resources"></a>

以下是 Amazon ECS 線性部署中涉及的資源：
+ 流量轉移 - Amazon ECS 用來轉移生產流量的程序。對於 Amazon ECS 線性部署，流量會以相等百分比增量轉移，每個增量之間的可設定等待時間。
+ 步驟百分比 - 線性部署期間每個增量移動的流量百分比。此欄位採用 Double 作為值，有效值介於 3.0 到 100.0 之間。
+ 步驟製作時間 - 在線性部署期間，每個流量轉移增量之間的等待時間。有效值為 0 - 1440 分鐘。
+ 部署製作時間 - 在將所有生產流量轉移到新服務修訂版之後，Amazon ECS 會在終止舊服務修訂版之前等待的時間，以分鐘為單位。這是生產流量轉移後，藍色和綠色服務修訂同時執行的持續時間。
+ 生命週期階段 – 部署操作中的一系列事件，例如「生產流量轉移後」。
+ 生命週期掛鉤 - 在特定生命週期階段執行的 Lambda 函數。您可以建立可驗證部署的 函數。為每個生產流量轉移步驟調用為 PRODUCTION\$1TRAFFIC\$1SHIFT 設定的 Lambda 函數或生命週期掛鉤。
+ 目標群組 – 一種 Elastic Load Balancing 資源，用於將請求路由至一個或多個已註冊的目標 (例如 EC2 執行個體)。當您建立接聽程式時，可以為其預設動作指定一個目標群組。流量會轉送至接聽程式規則中指定的目標群組。
+ 接聽程式 – 一種 Elastic Load Balancing 資源，用於透過已設定的通訊協定與連接埠檢查連線請求。您為接聽程式定義的規則決定了 Amazon ECS 如何將請求路由至已註冊的目標。
+ 規則 – 與接聽程式相關聯的 Elastic Load Balancing 資源。規則定義了請求的路由方式，包含動作、條件與優先順序。

## 考量事項
<a name="linear-deployment-considerations"></a>

選擇部署類型時，請考量下列事項：
+ 資源用量：線性部署會同時暫時執行藍色和綠色服務修訂，這可能會在部署期間將您的資源用量加倍。
+ 部署監控：線性部署提供詳細的部署狀態資訊，可讓您監控部署程序的每個階段和每個流量轉移增量。
+ 回復：線性部署可讓您在偵測到問題時更輕鬆地回復到先前的版本，因為藍色修訂會持續執行，直到製作時間過期為止。
+ 漸進式驗證：線性部署可讓您使用增加的生產流量來驗證新修訂版，從而提高部署的可信度。
+ 部署持續時間：由於步驟之間的增量流量轉移和等待時間，線性部署的完成時間比all-at-once部署更長。

## 線性部署的運作方式
<a name="linear-deployment-how-works"></a>

Amazon ECS 線性部署程序遵循具有六個不同階段的結構化方法，以確保安全可靠的應用程式更新。每個階段都有特定用途，以驗證應用程式，並將其從目前版本 (藍色) 轉換為新版本 (綠色)。

1. 準備階段 – 在現有的藍色環境旁建立綠色環境。

1. 部署階段：將新的服務修訂版部署到綠色環境。Amazon ECS 會使用更新後的服務修訂版啟動新任務，同時藍色環境會繼續處理生產流量。

1. 測試階段：使用測試流量路由驗證綠色環境。Application Load Balancer 會將測試請求導向綠色環境，同時生產流量仍保留在藍色環境中。

1. 線性流量轉移階段：根據您設定的部署策略，以相等的百分比增量逐漸將生產流量從藍色轉移到綠色。

1. 監控階段：在封裝時間段內監控應用程式運作狀態、效能指標與警示狀態。偵測到問題時，會啟動復原操作。

1. 完成階段：終止藍色環境以完成部署。

線性流量轉移階段遵循下列步驟：
+ 初始 - 部署從 100% 路由到藍色 （目前） 服務修訂版的流量開始。綠色 （新） 服務修訂最初會接收測試流量，但不會接收生產流量。
+ 增量流量轉移 - 流量會以相等百分比增量逐漸從藍色轉換為綠色。例如，使用 10.0% 步驟組態時，流量轉移會如下所示：
  + 步驟 1：10.0% 到綠色，90.0% 到藍色
  + 步驟 2：20.0% 到綠色，80.0% 到藍色
  + 步驟 3：30.0% 到綠色，70.0% 到藍色
  + 因此，直到 100% 達到綠色
+ 步驟製作時間 - 在每個流量轉移增量之間，部署會等待可設定的持續時間 （步驟製作時間），以允許在流量負載增加的情況下監控和驗證新修訂版的效能。請注意，當流量轉移 100.0% 時，會略過最後一個步驟的製作時間。
+ 生命週期關聯 - 選用 Lambda 函數可以在部署期間的不同生命週期階段執行，以執行自動驗證、監控或自訂邏輯。為每個生產流量轉移步驟調用為 PRODUCTION\$1TRAFFIC\$1SHIFT 設定的 Lambda 函數或生命週期掛鉤。

## 部署生命週期階段
<a name="linear-deployment-lifecycle-stages"></a>

線性部署程序會經過不同的生命週期階段，每個階段都有特定的責任和驗證檢查點。了解這些階段有助於監控部署進度並對問題進行有效的疑難排解。

每個生命週期階段最多可持續 24 小時，此外，ProductION\$1TRAFFIC\$1SHIFT 中的每個流量轉移步驟最多可持續 24 小時。建議將該值保持在 24 小時標記以內。這是因為非同步程序需要時間來觸發勾點。系統逾時、部署失敗，然後在階段達到 24 小時後啟動復原。

CloudFormation 部署有額外的逾時限制。雖然 24 小時階段限制仍然有效，但 對整個部署 CloudFormation 強制執行 36 小時限制。 部署 CloudFormation 失敗，然後在程序未在 36 小時內完成時啟動轉返。


| 生命週期階段 | Description | 生命週期掛鉤支援 | 
| --- | --- | --- | 
| RECONCILE\$1SERVICE | 僅當啟動新的服務部署且存在多個處於 ACTIVE 狀態的服務修訂版時，此階段才會發生。 | 是 | 
| PRE\$1SCALE\$1UP | 綠色服務修訂版尚未啟動。藍色服務修訂版正在處理 100% 的生產流量。沒有測試流量。 | 是 | 
| SCALE\$1UP | 綠色服務修訂版向上擴展到 100% 並啟動新任務的時間。此時綠色服務修訂版不處理任何流量。 | 否 | 
| POST\$1SCALE\$1UP | 綠色服務修訂版已啟動。藍色服務修訂版正在處理 100% 的生產流量。沒有測試流量。 | 是 | 
| TEST\$1TRAFFIC\$1SHIFT | 藍色與綠色服務修訂版均在執行中。藍色服務修訂版處理 100% 的生產流量。綠色服務修訂版正在從 0% 遷移至 100% 的測試流量。 | 是 | 
| POST\$1TEST\$1TRAFFIC\$1SHIFT | 測試流量轉移已完成。綠色服務修訂版處理 100% 的生產流量。 | 是 | 
| PRODUCTION\$1TRAFFIC\$1SHIFT | 流量會從藍色逐漸轉換為綠色，並以相等百分比遞增，直到綠色接收到 100% 的流量。每個流量轉移都會調用具有 24 小時逾時的生命週期關聯。 | 
| POST\$1PRODUCTION\$1TRAFFIC\$1SHIFT | 生產流量轉移已完成。 | 是 | 
| BAKE\$1TIME | 藍色與綠色服務修訂版同時執行的持續時間。 | 否 | 
| CLEAN\$1UP | 藍色服務修訂已完全縮減至 0 項執行中任務。在此階段之後，綠色服務修訂版現在是生產服務修訂版。 | 否 | 

# Amazon ECS 線性部署所需的資源
<a name="linear-deployment-implementation"></a>

若要搭配受管流量轉移使用線性部署，您的服務必須使用下列其中一項功能：
+ Elastic Load Balancing
+ Service Connect

以下清單提供您需要為 Amazon ECS 線性部署設定哪些項目的高階概觀：
+ 服務會使用 Application Load Balancer、Network Load Balancer 或 Service Connect。設定相應的資源。
  + Application Load Balancer – 如需詳細資訊，請參閱[藍/綠、線性和金絲雀部署的 Application Load Balancer 資源](alb-resources-for-blue-green.md)。
  + Network Load Balancer – 如需詳細資訊，請參閱[Amazon ECS 藍/綠、線性和 Canary 部署的 Network Load Balancer 資源](nlb-resources-for-blue-green.md)。
  + Service Connect – 如需詳細資訊，請參閱[Amazon ECS 藍色/綠色、線性和 Canary 部署的 Service Connect 資源](service-connect-blue-green.md)。
+ 將服務部署控制器設定為 `ECS`。
+ 在服務定義中，將部署策略設定為 `linear`。
+ 或者設定其他參數，例如：
  + 新部署的封裝時間
  + 每個增量中要轉移的流量百分比。
  + 每個流量轉移增量之間等待的持續時間，以分鐘為單位。
  + 自動復原的 CloudWatch 警示
  + 部署生命週期掛鉤 （這些是在指定的部署階段執行的 Lambda 函數，例如 BEFORE\$1INSTALL、Production\$1TRAFFIC\$1SHIFT 或 POST\$1PRODUCTION\$1TRAFFIC\$1SHIFT)

## 最佳實務
<a name="linear-deployment-best-practices"></a>

針對成功的 Amazon ECS 線性部署，請遵循下列最佳實務：
+ **確保您的應用程式可以同時處理兩個服務修訂。**
+ **規劃足夠的叢集容量，以在部署期間處理這兩個服務修訂。**
+ **在生產環境中實作復原程序之前，請先測試復原程序。**
+ 設定相應的運作狀態檢查，以準確反映應用程式的運作狀態。
+ 設定可充分測試新服務修訂的製作時間。
+ 實作 CloudWatch 警示，以自動偵測問題並觸發復原。
+ 選擇步驟百分比和製作時間，以平衡部署速度與驗證需求。
+ 針對關鍵應用程式使用較小的步驟百分比 (5-10%)，將風險暴露降至最低。
+ 為需要時間暖機或穩定的應用程式設定較長的步驟製作時間。
+ 實作 CloudWatch 警示，以自動偵測問題，並以任何流量增量觸發轉返。
+ 在每次流量轉移期間密切監控應用程式指標，以提早偵測效能降低。
+ 確保您的應用程式可以同時處理兩個服務修訂。
+ 在生產環境中實作復原程序之前，以不同的流量百分比測試復原程序。

# 建立 Amazon ECS 線性部署
<a name="deploy-linear-service"></a>

透過使用 Amazon ECS 線性部署，您可以在指定的時間間隔內以相同的增量逐步轉移流量。這會在部署程序的每個步驟提供受控驗證。

## 先決條件
<a name="deploy-linear-service-prerequisites"></a>

開始線性部署之前，請執行下列操作。

1. 設定相應的許可。
   + 如需有關 Elastic Load Balancing 許可的資訊，請參閱[負載平衡器的 Amazon ECS 基礎結構 IAM 角色](AmazonECSInfrastructureRolePolicyForLoadBalancers.md)。
   + 如需有關 Lambda 許可的資訊，請參閱 [Amazon ECS 藍/綠部署中 Lambda 函式所需的許可](blue-green-permissions.md)。

1. Amazon ECS 線性部署需要您的服務使用下列其中一項功能：設定適當的資源。
   + Application Load Balancer – 如需詳細資訊，請參閱[藍/綠、線性和金絲雀部署的 Application Load Balancer 資源](alb-resources-for-blue-green.md)。
   + Network Load Balancer – 如需詳細資訊，請參閱[Amazon ECS 藍/綠、線性和 Canary 部署的 Network Load Balancer 資源](nlb-resources-for-blue-green.md)。
   + Service Connect – 如需詳細資訊，請參閱[Amazon ECS 藍色/綠色、線性和 Canary 部署的 Service Connect 資源](service-connect-blue-green.md)。

## 程序
<a name="deploy-linear-service-procedure"></a>

您可以使用 主控台或 AWS CLI 來建立 Amazon ECS 線性部署服務。

------
#### [ Console ]

1. 開啟主控台，網址為 [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)。

1. 決定您要從中啟動服務的資源。    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/AmazonECS/latest/developerguide/deploy-linear-service.html)

   **建立服務**頁面隨即顯示。

1. 在**服務詳細資訊**下，執行下列動作：

   1. 在**任務定義系列**欄位中選擇要使用的任務定義。然後，在**任務定義修訂版**欄位中輸入要使用的修訂版。

   1. 針對 **Service name** (服務名稱)，輸入服務的名稱。

1. 若要在現有叢集中執行服務，請在**現有叢集**欄位中選擇叢集。若要在新叢集中執行服務，請選擇**建立叢集** 

1. 選擇任務在叢集基礎結構中的分佈方式。在**運算組態**下選擇選項。    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/AmazonECS/latest/developerguide/deploy-linear-service.html)

1. 在**部署組態**下，執行下列動作：

   1. 在**服務類型**欄位中選擇**複本**。

   1. 針對 **Desired tasks** (所需任務)，輸入要在服務中啟動並維護的任務數。

   1. 若要讓 Amazon ECS 監控可用區域間的任務分佈，並在出現不平衡時重新分佈，請在**可用區域服務重新平衡**下，選取**可用區域服務重新平衡**。

   1. 在**運作狀態檢查寬限期**欄位中，輸入時間 (以秒為單位)，這是服務排程器在任務首次啟動後忽略運作狀態不良的 Elastic Load Balancing、VPC Lattice 與容器運作狀態檢查的時間。如果您未指定運作狀態檢查寬限期間值，則會使用預設值 0。

1. 在**部署組態**下，設定線性部署設定：

   1. 針對**部署策略**，選擇**線性**。

   1. 對於**流量增量百分比**，輸入每個增量要轉移的流量百分比 （例如，10% 以 10% 增量轉移流量）。

   1. 對於**增量之間的間隔**，輸入每個流量轉移增量之間等待的時間，以分鐘為單位。

   1. 針對**製作時間**，輸入藍色和綠色服務修訂在終止藍色修訂之前，在最終流量轉移後同時執行的分鐘數。

   1. (選用) 執行要在部署的特定階段執行的 Lambda 函式。在**部署 lifecycle hook** 下，選取要執行 lifecycle hook 的階段。

      若要新增 lifecycle hook：

      1. 選擇**新增**。

      1. 在 **Lambda 函式**欄位中，輸入函式名稱或 ARN。

      1. 在**角色**欄位中，選取具有調用 Lambda 函式許可的 IAM 角色。

      1. 在**生命週期階段**欄位中，選取 Lambda 函式應執行的階段。

1. 若要設定 Amazon ECS 如何偵測並處理部署失敗，請展開 **Deployment failure detection** (部署失敗偵測)，然後選擇您的選項。

   1. 若要在任務無法啟動時停止部署，請選取 **Use the Amazon ECS deployment circuit breaker** (使用 Amazon ECS 部署斷路器)。

      在部署斷路器將部署設定為失敗狀態時，若要讓軟體自動將部署復原至上次完成的部署狀態，請選取**失敗時復原**。

   1. 若要根據應用程式指標停止部署，請選取**使用 CloudWatch 警示**。然後，從**CloudWatch 警示名稱**欄位中選擇警示。要建立新的警示，請前往 CloudWatch 主控台。

      在 CloudWatch 警示將部署設定為失敗狀態時，若要讓軟體自動將部署復原至上次完成的部署狀態，請選取**失敗時復原**。

1. (選用) 若要使用 Service Connect 與服務互連，請展開 **Service Connect** 區段，然後指定下列項目：

   1.  選取**開啟 Service Connect**。

   1. 在 **Service Connect configuration** (Service Connect 組態) 下，指定用戶端模式。
      + 如果服務執行的網路用戶端應用程式只需要連線至命名空間中的其他服務，請選擇**僅用戶端**。
      + 如果服務執行的是網路或 Web 服務應用程式，且需要為此服務提供端點，並連線至命名空間中的其他服務，請選擇 **Client and server** (用戶端和伺服器)。

   1. 若要使用非預設叢集命名空間的命名空間，請在 **Namespace** (命名空間) 欄位中選擇服務命名空間。這可以是在您的 中在相同 AWS 區域 中分別建立的命名空間， AWS 帳戶 或是使用 AWS Resource Access Manager () 與您的帳戶共用的相同區域中的命名空間AWS RAM。如需共用 AWS Cloud Map 命名空間的詳細資訊，請參閱《 *AWS Cloud Map 開發人員指南*》中的[跨帳戶 AWS Cloud Map 命名空間共用](https://docs.aws.amazon.com/cloud-map/latest/dg/sharing-namespaces.html)。

   1. （選用） 設定線性部署的測試流量標頭規則。在**測試流量路由**下，指定下列項目：

      1. 選取**啟用測試流量標頭規則**，以在測試期間將特定請求路由至綠色服務修訂版。

      1. 在**標頭比對規則**欄位中，設定路由測試流量的條件：
         + **標頭名稱**：輸入要比對的 HTTP 標頭名稱 (例如 `X-Test-Version` 或 `User-Agent`)。
         + **比對類型**：選擇比對條件：
           + **完全相符**：標頭值與指定值完全相符的路由請求
           + **標頭存在**：包含指定標頭的路由請求，無論其值為何
           + **模式比對**：標頭值與指定模式相符的路由請求
         + **標頭值** (如果使用「完全相符」或「模式相符」)：輸入要比對的值或模式。

         您可以新增多個標頭比對規則來建立複雜的路由邏輯。符合任何已設定規則的請求將路由至綠色服務修訂版進行測試。

      1. 選擇**新增標頭規則**以設定其他標頭比對條件。
**注意**  
測試流量標頭規則讓您可以在完成完整部署之前，使用受控流量驗證新功能。這允許您使用特定請求 (例如來自內部測試工具或 Beta 版使用者的請求) 測試綠色服務修訂版，同時維持流向藍色服務修訂版的正常流量流程。

   1. (選用) 指定日誌組態。選取**使用日誌收集**。預設選項會將容器日誌傳送至 CloudWatch 日誌。其他日誌驅動程式選項是使用 AWS FireLens 設定。如需詳細資訊，請參閱[將 Amazon ECS 日誌傳送至 AWS 服務或 AWS Partner](using_firelens.md)。

      下方更詳細地描述了每個容器日誌目的地。
      + **Amazon CloudWatch** – 將任務設定為將容器日誌傳送至 CloudWatch Logs。系統會提供預設日誌驅動程式選項，用來代表您建立 CloudWatch 日誌群組。若要指定不同的日誌群組名稱，請變更驅動程式選項值。
      + **Amazon Data Firehose** – 將任務設定為將容器日誌傳送至 Firehose。系統會提供預設日誌驅動程式選項，用來將日誌傳送至 Firehose 傳送串流。若要指定不同的交付串流名稱，請變更驅動程式選項值。
      + **Amazon Kinesis Data Streams** – 將任務設定為將容器日誌傳送至 Amazon Kinesis Data Streams。系統會提供預設日誌驅動程式選項，用來將日誌傳送至 Kinesis Data Streams 串流。若要指定不同的串流名稱，請變更驅動程式選項值。
      + **Amazon OpenSearch Service** – 將任務設定為將容器日誌傳送至 OpenSearch Service 網域。務必提供日誌驅動程式選項。
      + **Amazon S3**：將任務設定為將容器日誌傳送至 Amazon S3 儲存貯體。系統會提供預設日誌驅動程式選項，但您必須指定有效的 Amazon S3 儲存貯體名稱。

1. （選用） 設定**線性部署的負載平衡**。    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/AmazonECS/latest/developerguide/deploy-linear-service.html)

1. (選用) 為協助識別您的服務和任務，請展開 **Tags** (標籤) 區段，然後設定標籤。

   若要讓 Amazon ECS 使用叢集名稱和任務定義標籤，自動標記所有新啟動的任務，請選取 **Turn on Amazon ECS managed tags** (開啟 Amazon ECS 受管標籤)，然後針對 **Propagate tags from** (傳播標籤來源)，選取 **Task definitions** (任務定義)。

   若要讓 Amazon ECS 使用叢集名稱和服務標籤，自動標記所有新啟動的任務，請選取 **Turn on Amazon ECS managed tags** (開啟 Amazon ECS 受管標籤)，然後針對 **Propagate tags from** (傳播標籤來源)，選取 **Service** (服務)。

   新增或移除標籤。
   + [新增標籤] 選擇**新增標籤**，然後執行下列操作︰
     + 在**索引鍵**中，輸入索引鍵名稱。
     + 在**值**中，進入索引鍵值。
   + [移除標籤] 在標籤旁邊，選擇**移除標籤**。

1. 選擇**建立**。

------
#### [ AWS CLI ]

1. 建立名為 `linear-service-definition.json` 且具有下列內容的檔案。

   將 *user-input* 取代為實際值。

   ```
   {
     "serviceName": "myLinearService",
     "cluster": "arn:aws:ecs:us-west-2:123456789012:cluster/sample-fargate-cluster",
     "taskDefinition": "sample-fargate:1",
     "desiredCount": 5,
     "launchType": "FARGATE",
     "networkConfiguration": {
       "awsvpcConfiguration": {
         "subnets": [
           "subnet-09ce6e74c116a2299",
           "subnet-00bb3bd7a73526788",
           "subnet-0048a611aaec65477"
         ],
         "securityGroups": [
           "sg-09d45005497daa123"
         ],
         "assignPublicIp": "ENABLED"
       }
     },
     "deploymentController": {
       "type": "ECS"
     },
     "deploymentConfiguration": {
       "strategy": "LINEAR",
       "maximumPercent": 200,
       "minimumHealthyPercent": 100,
       "linearConfiguration": {
         "stepPercentage": 10.0,
         "stepBakeTimeInMinutes":6
       },
       "bakeTimeInMinutes": 10,
       "alarms": {
         "alarmNames": [
           "myAlarm"
         ],
         "rollback": true,
         "enable": true
       }
     },
     "loadBalancers": [
       {
         "targetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/blue-target-group/54402ff563af1197",
         "containerName": "fargate-app",
         "containerPort": 80,
         "advancedConfiguration": {
           "alternateTargetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/green-target-group/cad10a56f5843199",
           "productionListenerRule": "arn:aws:elasticloadbalancing:us-west-2:123456789012:listener-rule/app/my-linear-demo/32e0e4f946c3c05b/9cfa8c482e204f7d/831dbaf72edb911",
           "roleArn": "arn:aws:iam::123456789012:role/LoadBalancerManagementforECS"
         }
       }
     ]
   }
   ```

1. 執行 `create-service`。

   ```
   aws ecs create-service --cli-input-json file://linear-service-definition.json
   ```

------

## 後續步驟
<a name="deploy-linear-service-next-steps"></a>
+ 更新服務以開始部署。如需詳細資訊，請參閱[更新 Amazon ECS 服務](update-service-console-v2.md)。
+ 監控部署程序，以確保其遵循線性模式：
  + 綠色服務修訂版已建立並向上擴展
  + 流量會以指定的間隔遞增轉移
  + 每個增量在下一次輪班之前等待指定的間隔
  + 轉移所有流量後，製作時間開始
  + 封裝時間過期後，藍色修訂版會終止

# Amazon ECS Canary 部署
<a name="canary-deployment"></a>

Canary 部署會先將一小部分的流量路由到新修訂版以進行初始測試，然後在 Canary 階段成功完成後一次轉移所有剩餘的流量。透過 Amazon ECS Canary 部署，使用實際使用者流量驗證新的服務修訂，同時將暴露風險降至最低。此方法提供一種可控制的方式來部署變更，並能夠監控效能，並在偵測到問題時快速復原。

## Canary 部署中涉及的資源
<a name="canary-deployment-resources"></a>

以下是 Amazon ECS Canary 部署中涉及的資源：
+ 流量轉移 - Amazon ECS 用來轉移生產流量的程序。對於 Amazon ECS Canary 部署，流量會分兩個階段轉移：先到 Canary 百分比，然後完成部署。
+ Canary 百分比 - 在評估期間路由至新版本的流量百分比。
+ Canary 製作時間 - 在繼續完整部署之前監控 Canary 版本的持續時間。
+ 部署製作時間 - 在將所有生產流量轉移到新服務修訂版之後，Amazon ECS 會在終止舊服務修訂版之前等待的時間，以分鐘為單位。這是生產流量轉移後，藍色和綠色服務修訂同時執行的持續時間。
+ 生命週期階段 – 部署操作中的一系列事件，例如「生產流量轉移後」。
+ 生命週期掛鉤 - 在特定生命週期階段執行的 Lambda 函數。您可以建立驗證部署的 函數。
+ 目標群組 – 一種 Elastic Load Balancing 資源，用於將請求路由至一個或多個已註冊的目標 (例如 EC2 執行個體)。當您建立接聽程式時，可以為其預設動作指定一個目標群組。流量會轉送至接聽程式規則中指定的目標群組。
+ 接聽程式 – 一種 Elastic Load Balancing 資源，用於透過已設定的通訊協定與連接埠檢查連線請求。您為接聽程式定義的規則決定了 Amazon ECS 如何將請求路由至已註冊的目標。
+ 規則 – 與接聽程式相關聯的 Elastic Load Balancing 資源。規則定義了請求的路由方式，包含動作、條件與優先順序。

## 考量事項
<a name="canary-deployment-considerations"></a>

選擇部署類型時，請考量下列事項：
+ 資源用量：Canary 部署會在評估期間同時執行原始任務集和 Canary 任務集，進而增加資源用量。
+ 流量：確保 Canary 百分比產生足夠的流量，以便對新版本進行有意義的驗證。
+ 監控複雜性：Canary 部署需要同時監控和比較兩個不同版本之間的指標。
+ 回復速度：Canary 部署可透過將流量移回原始任務集來啟用快速回復。
+ 風險緩解：Canary 部署透過將暴露限制在少數百分比的使用者，提供絕佳的風險緩解能力。
+ 部署持續時間：Canary 部署包含延長整體部署時間但提供驗證機會的評估期間。

## Canary 部署的運作方式
<a name="canary-how-it-works"></a>

Amazon ECS Canary 部署程序遵循具有六個不同階段的結構化方法，以確保安全可靠的應用程式更新。每個階段都有特定用途，以驗證應用程式，並將其從目前版本 (藍色) 轉換為新版本 (綠色)。

1. 準備階段 – 在現有的藍色環境旁建立綠色環境。

1. 部署階段：將新的服務修訂版部署到綠色環境。Amazon ECS 會使用更新後的服務修訂版啟動新任務，同時藍色環境會繼續處理生產流量。

1. 測試階段：使用測試流量路由驗證綠色環境。Application Load Balancer 會將測試請求導向綠色環境，同時生產流量仍保留在藍色環境中。

1. Canary 流量轉移階段：在 Canary 階段將流量設定百分比轉移至新的綠色服務修訂版本，接著將 100.0% 的流量轉移至 Green 服務修訂版本

1. 監控階段：在封裝時間段內監控應用程式運作狀態、效能指標與警示狀態。偵測到問題時，會啟動復原操作。

1. 完成階段：終止藍色環境以完成部署。

Canary 流量轉移階段遵循下列步驟：
+ 初始 - 部署從 100% 路由至藍色 （目前） 服務修訂版的流量開始。綠色 （新） 服務修訂最初會接收測試流量，但不會接收生產流量。
+ Canary 流量轉移 - 這是兩步驟流量轉移策略。
  + 步驟 1：10.0% 到綠色，90.0% 到藍色
  + 步驟 2：100.0% 到綠色，0.0% 到藍色
+ Canary 製作時間 - 在 Canary 流量轉移後等待可設定的持續時間 (Canary 製作時間），以允許在流量負載增加時監控和驗證新修訂版的效能。
+ 生命週期關聯 - 選用 Lambda 函數可以在部署期間的不同生命週期階段執行，以執行自動驗證、監控或自訂邏輯。為每個生產流量轉移步驟調用為 PRODUCTION\$1TRAFFIC\$1SHIFT 設定的 Lambda 函數或生命週期掛鉤。

### 部署生命週期階段
<a name="canary-deployment-lifecycle-stages"></a>

Canary 部署程序會經過不同的生命週期階段，每個階段都有特定的責任和驗證檢查點。了解這些階段有助於監控部署進度並對問題進行有效的疑難排解。

每個生命週期階段最多可持續 24 小時，此外，ProductION\$1TRAFFIC\$1SHIFT 中的每個流量轉移步驟最多可持續 24 小時。建議將該值保持在 24 小時標記以內。這是因為非同步程序需要時間來觸發勾點。系統逾時、部署失敗，然後在階段達到 24 小時後啟動轉返。

CloudFormation 部署有額外的逾時限制。雖然 24 小時階段限制仍然有效，但 會 CloudFormation 強制執行整個部署的 36 小時限制。 會 CloudFormation 失敗部署，然後在程序未在 36 小時內完成時啟動轉返。


**生命週期階段**  

| 生命週期階段 | Description | 生命週期掛鉤支援 | 
| --- | --- | --- | 
| RECONCILE\$1SERVICE | 僅當啟動新的服務部署且存在多個處於 ACTIVE 狀態的服務修訂版時，此階段才會發生。 | 是 | 
| PRE\$1SCALE\$1UP | 綠色服務修訂版尚未啟動。藍色服務修訂版正在處理 100% 的生產流量。沒有測試流量。 | 是 | 
| SCALE\$1UP | 綠色服務修訂版向上擴展到 100% 並啟動新任務的時間。此時綠色服務修訂版不處理任何流量。 | 否 | 
| POST\$1SCALE\$1UP | 綠色服務修訂版已啟動。藍色服務修訂版正在處理 100% 的生產流量。沒有測試流量。 | 是 | 
| TEST\$1TRAFFIC\$1SHIFT | 藍色與綠色服務修訂版均在執行中。藍色服務修訂版處理 100% 的生產流量。綠色服務修訂版正在從 0% 遷移至 100% 的測試流量。 | 是 | 
| POST\$1TEST\$1TRAFFIC\$1SHIFT | 測試流量轉移已完成。綠色服務修訂版處理 100% 的生產流量。 | 是 | 
| PRODUCTION\$1TRAFFIC\$1SHIFT | Canary 生產流量會路由至綠色修訂版，並使用 24 小時逾時叫用生命週期掛鉤。第二個步驟會將剩餘的生產流量轉移到綠色修訂版。 | 是 | 
| POST\$1PRODUCTION\$1TRAFFIC\$1SHIFT | 生產流量轉移已完成。 | 是 | 
| BAKE\$1TIME | 藍色與綠色服務修訂版同時執行的持續時間。 | 否 | 
| CLEAN\$1UP | 藍色服務修訂已完全縮減至 0 項執行中任務。在此階段之後，綠色服務修訂版現在是生產服務修訂版。 | 否 | 

### 組態參數
<a name="canary-configuration-parameters"></a>

Canary 部署需要下列組態參數：
+ Canary 百分比 - 在 Canary 階段期間路由至新服務修訂的流量百分比。這允許使用受控的生產流量子集進行測試。
+ Canary 製作時間 - 在 Canary 階段期間等待的持續時間，然後再將剩餘的流量轉移到新的服務修訂版。這提供了監控和驗證新版本的時間。

### 流量管理
<a name="canary-traffic-management"></a>

Canary 部署使用負載平衡器目標群組來管理流量分佈：
+ 原始目標群組 - 包含目前穩定版本的任務，並接收大部分流量。
+ Canary 目標群組 - 包含新版本的任務，並接收一小部分的流量進行測試。
+ 加權路由 - 負載平衡器使用加權路由規則，根據設定的 Canary 百分比在目標群組之間分配流量。

### 監控和驗證
<a name="canary-monitoring-validation"></a>

有效的 Canary 部署依賴於全面監控：
+ 運作狀態檢查 - 在接收流量之前，兩個任務集都必須通過運作狀態檢查。
+ 指標比較 - 比較原始版本和 Canary 版本之間的關鍵效能指標，例如回應時間、錯誤率和輸送量。
+ 自動化轉返 - 如果 Canary 版本顯示效能降低，將 CloudWatch 警示設定為自動觸發轉返。
+ 手動驗證 - 在繼續之前，使用評估期間手動檢閱日誌、指標和使用者意見回饋。

### Canary 部署的最佳實務
<a name="canary-best-practices"></a>

遵循這些最佳實務，以確保使用 服務成功部署 Canary。

#### 選擇適當的流量百分比
<a name="canary-traffic-percentage"></a>

選取 Canary 流量百分比時，請考慮下列因素：
+ 啟動小型 - 從 5-10% 的流量開始，在發生問題時將影響降至最低。
+ 考慮應用程式關鍵性 - 對關鍵任務應用程式使用較小的百分比，對較不重要的服務使用較大的百分比。
+ 流量帳戶 - 確保 Canary 百分比產生足夠的流量以進行有意義的驗證。

#### 設定適當的評估期間
<a name="canary-evaluation-time"></a>

根據下列考量設定評估期間：
+ 允許足夠的時間 - 設定足夠長的評估期間以擷取有意義的效能資料，通常為 10-30 分鐘。
+ 考慮流量模式 - 考慮應用程式的流量模式和尖峰使用時間。
+ 平衡速度和安全性 - 較長的評估期間提供更多資料，但部署速度緩慢。

#### 實作全方位監控
<a name="canary-monitoring-setup"></a>

設定監控以追蹤 Canary 部署效能：
+ 關鍵指標 - 監控兩個任務集的回應時間、錯誤率、輸送量和資源使用率。
+ 警示型回復 - 設定 CloudWatch 警示，以在指標超過閾值時自動觸發回復。
+ 比較分析 - 設定儀表板來side-by-side比較原始版本和 Canary 版本之間的指標。
+ 業務指標 - 包括業務特定的指標，例如轉換率或使用者參與度以及技術指標。

#### 規劃復原策略
<a name="canary-rollback-strategy"></a>

使用以下策略準備潛在的回復案例：
+ 自動化轉返 - 根據運作狀態檢查和效能指標設定自動轉返觸發條件。
+ 手動轉返程序 - 當自動觸發未擷取所有問題時，記錄手動轉返的清除程序。
+ 回復測試 - 定期測試回復程序，以確保在需要時正常運作。

#### 在部署之前徹底驗證
<a name="canary-testing-validation"></a>

在繼續 Canary 部署之前，請確保徹底驗證：
+ 部署前測試 - 在 Canary 部署之前，徹底測試預備環境中的變更。
+ 運作狀態檢查組態 - 確保運作狀態檢查準確反映應用程式準備程度和功能。
+ 相依性驗證 - 確認新版本與下游和上游服務相容。
+ 資料一致性 - 確保資料庫結構描述變更和資料遷移回溯相容。

#### 協調團隊參與
<a name="canary-team-coordination"></a>

在 Canary 部署期間確保有效的團隊協調：
+ 部署時段 - 當團隊可以監控和回應時，在上班時間排程 Canary 部署。
+ 通訊管道 - 為部署狀態和問題升級建立明確的通訊管道。
+ 角色指派 - 定義監控、決策和復原執行的角色和責任。

# Amazon ECS Canary 部署所需的資源
<a name="canary-deployment-implementation"></a>

若要搭配受管流量轉移使用 Canary 部署，您的服務必須使用下列其中一項功能：
+ Elastic Load Balancing
+ Service Connect

以下清單提供您需要為 Amazon ECS Canary 部署設定哪些項目的高階概觀：
+ 服務會使用 Application Load Balancer、Network Load Balancer 或 Service Connect。設定相應的資源。
  + Application Load Balancer – 如需詳細資訊，請參閱[藍/綠、線性和金絲雀部署的 Application Load Balancer 資源](alb-resources-for-blue-green.md)。
  + Network Load Balancer – 如需詳細資訊，請參閱[Amazon ECS 藍/綠、線性和 Canary 部署的 Network Load Balancer 資源](nlb-resources-for-blue-green.md)。
  + Service Connect – 如需詳細資訊，請參閱[Amazon ECS 藍色/綠色、線性和 Canary 部署的 Service Connect 資源](service-connect-blue-green.md)。
+ 將服務部署控制器設定為 `ECS`。
+ 在服務定義中，將部署策略設定為 `canary`。
+ 或者設定其他參數，例如：
  + 新部署的封裝時間
  + 在 Canary 階段期間路由至新服務修訂的流量百分比。
  + 在 Canary 階段等待的持續時間，然後再將剩餘的流量轉移到新的服務修訂版。
  + 自動復原的 CloudWatch 警示
  + 部署生命週期掛鉤 （這些是在指定部署階段執行的 Lambda 函數）

## 最佳實務
<a name="canary-deployment-best-practices"></a>

針對成功的 Amazon ECS 程式庫部署，請遵循下列最佳實務：
+ **確保您的應用程式可以同時處理兩個服務修訂。**
+ **規劃足夠的叢集容量，以在部署期間處理這兩個服務修訂。**
+ **在生產環境中實作復原程序之前，請先測試復原程序。**
+ 設定相應的運作狀態檢查，以準確反映應用程式的運作狀態。
+ 設定封裝時間，以對綠色部署進行充分測試。
+ 實作 CloudWatch 警示，以自動偵測問題並觸發復原。
+ 使用 lifecycle hook，在每個部署階段執行自動化測試。
+ 從小 Canary 百分比 (5-10%) 開始，在發生問題時將影響降至最低。
+ 設定適當的評估期間，以允許足夠的時間進行有意義的效能資料收集。
+ 使用 CloudWatch 警示實作自動化轉返觸發的全面監控。
+ 設定可準確反映應用程式整備和功能的運作狀態檢查。
+ 在評估期間監控技術指標 （回應時間、錯誤率） 和業務指標。
+ 確保您的應用程式可以處理流量分割，而不會發生工作階段或狀態問題。
+ 規劃轉返程序並定期測試，以確保它們在需要時有效。
+ 在團隊可以監控和回應的上班時間排程 Canary 部署。
+ 在 Canary 部署之前，在預備環境中徹底驗證變更。
+ 記錄手動介入和回復決策的明確程序。

# 建立 Amazon ECS Canary 部署
<a name="deploy-canary-service"></a>

透過使用 Amazon ECS Canary 部署，您可以將一小部分的流量轉移到新的服務修訂版 (「Canary」)。驗證部署，然後在指定的間隔之後一次轉移剩餘的流量。此方法可讓您在完全部署之前，以最低風險測試新功能。

## 先決條件
<a name="deploy-canary-service-prerequisites"></a>

在啟動 Canary 部署之前，請執行下列操作。

1. 設定相應的許可。
   + 如需有關 Elastic Load Balancing 許可的資訊，請參閱[負載平衡器的 Amazon ECS 基礎結構 IAM 角色](AmazonECSInfrastructureRolePolicyForLoadBalancers.md)。
   + 如需有關 Lambda 許可的資訊，請參閱 [Amazon ECS 藍/綠部署中 Lambda 函式所需的許可](blue-green-permissions.md)。

1. Amazon ECS Canary 部署要求您的服務使用下列其中一項功能：設定適當的資源。
   + Application Load Balancer – 如需詳細資訊，請參閱[藍/綠、線性和金絲雀部署的 Application Load Balancer 資源](alb-resources-for-blue-green.md)。
   + Network Load Balancer – 如需詳細資訊，請參閱[Amazon ECS 藍/綠、線性和 Canary 部署的 Network Load Balancer 資源](nlb-resources-for-blue-green.md)。
   + Service Connect – 如需詳細資訊，請參閱[Amazon ECS 藍色/綠色、線性和 Canary 部署的 Service Connect 資源](service-connect-blue-green.md)。

## 程序
<a name="deploy-canary-service-procedure"></a>

您可以使用 主控台或 AWS CLI 來建立 Amazon ECS Canary 部署服務。

------
#### [ Console ]

1. 開啟主控台，網址為 [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)。

1. 決定您要從中啟動服務的資源。    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/AmazonECS/latest/developerguide/deploy-canary-service.html)

   **建立服務**頁面隨即顯示。

1. 在**服務詳細資訊**下，執行下列動作：

   1. 在**任務定義系列**欄位中選擇要使用的任務定義。然後，在**任務定義修訂版**欄位中輸入要使用的修訂版。

   1. 針對 **Service name** (服務名稱)，輸入服務的名稱。

1. 若要在現有叢集中執行服務，請在**現有叢集**欄位中選擇叢集。若要在新叢集中執行服務，請選擇**建立叢集** 

1. 選擇任務在叢集基礎結構中的分佈方式。在**運算組態**下選擇選項。    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/AmazonECS/latest/developerguide/deploy-canary-service.html)

1. 在**部署組態**下，執行下列動作：

   1. 在**服務類型**欄位中選擇**複本**。

   1. 針對 **Desired tasks** (所需任務)，輸入要在服務中啟動並維護的任務數。

   1. 若要讓 Amazon ECS 監控可用區域間的任務分佈，並在出現不平衡時重新分佈，請在**可用區域服務重新平衡**下，選取**可用區域服務重新平衡**。

   1. 在**運作狀態檢查寬限期**欄位中，輸入時間 (以秒為單位)，這是服務排程器在任務首次啟動後忽略運作狀態不良的 Elastic Load Balancing、VPC Lattice 與容器運作狀態檢查的時間。如果您未指定運作狀態檢查寬限期間值，則會使用預設值 0。

1. 在**部署組態**下，設定 Canary 部署設定：

   1. 針對**部署策略**，選擇 **Canary**。

   1. 針對 **Canary 百分比**，輸入要在第一階段轉移到綠色服務修訂的流量百分比 （例如，初始 Canary 流量為 10%)。

   1. 針對 **Canary 製作時間**，輸入在將剩餘的流量轉移到綠色服務修訂版之前等待的時間，以分鐘為單位。

   1. 針對**製作時間**，輸入藍色和綠色服務修訂在終止藍色修訂之前，在最終流量轉移後同時執行的分鐘數。

   1. (選用) 執行要在部署的特定階段執行的 Lambda 函式。在**部署 lifecycle hook** 下，選取要執行 lifecycle hook 的階段。

      若要新增 lifecycle hook：

      1. 選擇**新增**。

      1. 在 **Lambda 函式**欄位中，輸入函式名稱或 ARN。

      1. 在**角色**欄位中，選取具有調用 Lambda 函式許可的 IAM 角色。

      1. 在**生命週期階段**欄位中，選取 Lambda 函式應執行的階段。

1. 若要設定 Amazon ECS 如何偵測並處理部署失敗，請展開 **Deployment failure detection** (部署失敗偵測)，然後選擇您的選項。

   1. 若要在任務無法啟動時停止部署，請選取 **Use the Amazon ECS deployment circuit breaker** (使用 Amazon ECS 部署斷路器)。

      在部署斷路器將部署設定為失敗狀態時，若要讓軟體自動將部署復原至上次完成的部署狀態，請選取**失敗時復原**。

   1. 若要根據應用程式指標停止部署，請選取**使用 CloudWatch 警示**。然後，從**CloudWatch 警示名稱**欄位中選擇警示。要建立新的警示，請前往 CloudWatch 主控台。

      在 CloudWatch 警示將部署設定為失敗狀態時，若要讓軟體自動將部署復原至上次完成的部署狀態，請選取**失敗時復原**。

1. (選用) 若要使用 Service Connect 與服務互連，請展開 **Service Connect** 區段，然後指定下列項目：

   1.  選取**開啟 Service Connect**。

   1. 在 **Service Connect configuration** (Service Connect 組態) 下，指定用戶端模式。
      + 如果服務執行的網路用戶端應用程式只需要連線至命名空間中的其他服務，請選擇**僅用戶端**。
      + 如果服務執行的是網路或 Web 服務應用程式，且需要為此服務提供端點，並連線至命名空間中的其他服務，請選擇 **Client and server** (用戶端和伺服器)。

   1. 若要使用非預設叢集命名空間的命名空間，請在 **Namespace** (命名空間) 欄位中選擇服務命名空間。這可以是 AWS 區域 在您的相同 中分別建立的命名空間， AWS 帳戶 或是使用 AWS Resource Access Manager () 與您的帳戶共用的相同區域中的命名空間AWS RAM。如需共用 AWS Cloud Map 命名空間的詳細資訊，請參閱《 *AWS Cloud Map 開發人員指南*》中的[跨帳戶 AWS Cloud Map 命名空間共用](https://docs.aws.amazon.com/cloud-map/latest/dg/sharing-namespaces.html)。

   1. （選用） 設定 Canary 部署的測試流量標頭規則。在**測試流量路由**下，指定下列項目：

      1. 選取**啟用測試流量標頭規則**，以在測試期間將特定請求路由至綠色服務修訂版。

      1. 在**標頭比對規則**欄位中，設定路由測試流量的條件：
         + **標頭名稱**：輸入要比對的 HTTP 標頭名稱 (例如 `X-Test-Version` 或 `User-Agent`)。
         + **比對類型**：選擇比對條件：
           + **完全相符**：標頭值與指定值完全相符的路由請求
           + **標頭存在**：包含指定標頭的路由請求，無論其值為何
           + **模式比對**：標頭值與指定模式相符的路由請求
         + **標頭值** (如果使用「完全相符」或「模式相符」)：輸入要比對的值或模式。

         您可以新增多個標頭比對規則來建立複雜的路由邏輯。符合任何已設定規則的請求將路由至綠色服務修訂版進行測試。

      1. 選擇**新增標頭規則**以設定其他標頭比對條件。
**注意**  
測試流量標頭規則讓您可以在完成完整部署之前，使用受控流量驗證新功能。這允許您使用特定請求 (例如來自內部測試工具或 Beta 版使用者的請求) 測試綠色服務修訂版，同時維持流向藍色服務修訂版的正常流量流程。

   1. (選用) 指定日誌組態。選取**使用日誌收集**。預設選項會將容器日誌傳送至 CloudWatch 日誌。其他日誌驅動程式選項是使用 AWS FireLens 設定。如需詳細資訊，請參閱[將 Amazon ECS 日誌傳送至 AWS 服務或 AWS Partner](using_firelens.md)。

      下方更詳細地描述了每個容器日誌目的地。
      + **Amazon CloudWatch** – 將任務設定為將容器日誌傳送至 CloudWatch Logs。系統會提供預設日誌驅動程式選項，用來代表您建立 CloudWatch 日誌群組。若要指定不同的日誌群組名稱，請變更驅動程式選項值。
      + **Amazon Data Firehose** – 將任務設定為將容器日誌傳送至 Firehose。系統會提供預設日誌驅動程式選項，用來將日誌傳送至 Firehose 傳送串流。若要指定不同的交付串流名稱，請變更驅動程式選項值。
      + **Amazon Kinesis Data Streams** – 將任務設定為將容器日誌傳送至 Amazon Kinesis Data Streams。系統會提供預設日誌驅動程式選項，用來將日誌傳送至 Kinesis Data Streams 串流。若要指定不同的串流名稱，請變更驅動程式選項值。
      + **Amazon OpenSearch Service** – 將任務設定為將容器日誌傳送至 OpenSearch Service 網域。務必提供日誌驅動程式選項。
      + **Amazon S3**：將任務設定為將容器日誌傳送至 Amazon S3 儲存貯體。系統會提供預設日誌驅動程式選項，但您必須指定有效的 Amazon S3 儲存貯體名稱。

1. （選用） 設定 **Canary 部署的負載平衡**。    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/AmazonECS/latest/developerguide/deploy-canary-service.html)

1. (選用) 為協助識別您的服務和任務，請展開 **Tags** (標籤) 區段，然後設定標籤。

   若要讓 Amazon ECS 使用叢集名稱和任務定義標籤，自動標記所有新啟動的任務，請選取 **Turn on Amazon ECS managed tags** (開啟 Amazon ECS 受管標籤)，然後針對 **Propagate tags from** (傳播標籤來源)，選取 **Task definitions** (任務定義)。

   若要讓 Amazon ECS 使用叢集名稱和服務標籤，自動標記所有新啟動的任務，請選取 **Turn on Amazon ECS managed tags** (開啟 Amazon ECS 受管標籤)，然後針對 **Propagate tags from** (傳播標籤來源)，選取 **Service** (服務)。

   新增或移除標籤。
   + [新增標籤] 選擇**新增標籤**，然後執行下列操作︰
     + 在**索引鍵**中，輸入索引鍵名稱。
     + 在**值**中，進入索引鍵值。
   + [移除標籤] 在標籤旁邊，選擇**移除標籤**。

1. 選擇**建立**。

------
#### [ AWS CLI ]

1. 建立名為 `canary-service-definition.json` 且具有下列內容的檔案。

   將 *user-input* 取代為實際值。

   ```
   {
     "serviceName": "myCanaryService",
     "cluster": "arn:aws:ecs:us-west-2:123456789012:cluster/sample-fargate-cluster",
     "taskDefinition": "sample-fargate:1",
     "desiredCount": 5,
     "launchType": "FARGATE",
     "networkConfiguration": {
       "awsvpcConfiguration": {
         "subnets": [
           "subnet-09ce6e74c116a2299",
           "subnet-00bb3bd7a73526788",
           "subnet-0048a611aaec65477"
         ],
         "securityGroups": [
           "sg-09d45005497daa123"
         ],
         "assignPublicIp": "ENABLED"
       }
     },
     "deploymentController": {
       "type": "ECS"
     },
     "deploymentConfiguration": {
       "strategy": "CANARY",
       "maximumPercent": 200,
       "minimumHealthyPercent": 100,
       "canaryConfiguration" : {
           "canaryPercent" : 5.0,
           "canaryBakeTime" : 10
       },
       "bakeTimeInMinutes": 10,
       "alarms": {
         "alarmNames": [
           "myAlarm"
         ],
         "rollback": true,
         "enable": true
       }
     },
     "loadBalancers": [
       {
         "targetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/blue-target-group/54402ff563af1197",
         "containerName": "fargate-app",
         "containerPort": 80,
         "advancedConfiguration": {
           "alternateTargetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/green-target-group/cad10a56f5843199",
           "productionListenerRule": "arn:aws:elasticloadbalancing:us-west-2:123456789012:listener-rule/app/my-canary-demo/32e0e4f946c3c05b/9cfa8c482e204f7d/831dbaf72edb911",
           "roleArn": "arn:aws:iam::123456789012:role/LoadBalancerManagementforECS"
         }
       }
     ]
   }
   ```

1. 執行 `create-service`。

   ```
   aws ecs create-service --cli-input-json file://canary-service-definition.json
   ```

------

## 後續步驟
<a name="deploy-canary-service-next-steps"></a>

設定 Canary 部署之後，請完成下列步驟：
+ 更新服務以開始部署。如需詳細資訊，請參閱[更新 Amazon ECS 服務](update-service-console-v2.md)。
+ 監控部署程序，以確保其遵循 Canary 模式：
  + 綠色服務修訂版已建立並向上擴展
  + 一小部分的流量 (Canary) 會轉移到綠色修訂版
  + 系統會等待指定的 Canary 間隔
  + 剩餘的流量會一次全部轉移到綠色修訂版
  + 封裝時間過期後，藍色修訂版會終止

## 部署術語
<a name="deployment-terminology"></a>

下列術語用於 Amazon ECS 部署文件：

藍綠部署  
與現有環境 （藍色） 一起建立新環境 （綠色） 的部署策略，然後在驗證後將流量從藍色切換到綠色。

Canary 部署  
一種部署策略，可將一小部分的流量路由到新版本，同時將大多數流量維持在穩定版本上進行驗證。

線性部署  
一種部署策略，隨著時間的推移，逐漸將流量從舊版本轉移到新版本。

滾動部署  
一種部署策略，可將舊版本的執行個體一次取代為新版本的執行個體。

任務集  
部署期間在服務內執行相同任務定義的任務集合。

目標群組  
部署期間從負載平衡器接收流量的目標邏輯分組。

部署控制器  
用來部署新版本服務的方法，例如 Amazon ECS、CodeDeploy 或外部控制器。

轉返  
在部署期間偵測到問題時，還原至舊版應用程式的程序。

# 使用第三方控制器部署 Amazon ECS 服務
<a name="deployment-type-external"></a>

*外部*部署類型可讓您使用任何第三方部署控制器，以完全控制 Amazon ECS 服務的部署程序。服務的詳細資訊是由服務管理 API 動作 (`CreateService`、`UpdateService` 和 `DeleteService`) 或任務設定管理 API 動作 (`CreateTaskSet`、`UpdateTaskSet`、`UpdateServicePrimaryTaskSet` 和 `DeleteTaskSet`) 所管理。每個 API 動作會管理服務定義參數的子集。

`UpdateService` API 動作更新服務的所需計數和運作狀態檢查寬限期參數。如果需要更新運算選項、平台版本、負載平衡器詳細資訊、網路組態或任務定義，必須建立新的任務集。

`UpdateTaskSet` API 動作只更新任務集的擴展參數。

`UpdateServicePrimaryTaskSet` API 動作修改服務中哪個任務集是主要任務集。當您呼叫 `DescribeServices` API 動作時，它會傳回主要任務集指定的所有欄位。如果更新服務的主要任務集，當定義新的主要任務時，存在於新主要任務集的任何任務集參數值 (不同於服務中的舊主要任務集) 將會更新為新的值。如果沒有為服務定義主要任務集，則描述服務時，任務集欄位是 null。

## 外部部署考量
<a name="deployment-type-external-considerations"></a>

使用外部部署類型時，請考慮下列各項：
+ 支援的負載平衡器類型可為 Application Load Balancer 或 Network Load Balancer。
+ Fargate 或 `EXTERNAL` 部署控制器類型不支援 `DAEMON` 排程策略。
+ 應用程式自動擴展功能與 Amazon ECS 的整合僅支援將 Amazon ECS 服務作為目標。Amazon ECS 支援的可擴展維度為 `ecs:service:DesiredCount` (Amazon ECS 服務的任務計數)。應用程式自動擴展功能與 Amazon ECS 任務集之間沒有直接整合。Amazon ECS 任務集會根據 Amazon ECS 服務的 `DesiredCount` 計算 `ComputedDesiredCount`。

## 外部部署工作流程
<a name="deployment-type-external-workflow"></a>

下列是在 Amazon ECS 上管理外部部署的基本工作流程。

**使用外部部署控制器管理 Amazon ECS 服務**

1. 建立 Amazon ECS 服務。唯一的必要參數是服務名稱。使用外部部署控制器建立服務時，您可以指定以下參數。在服務內建立任務集時，指定所有其他服務參數。  
`serviceName`  
類型：字串  
必要：是  
您的服務名稱。最多允許 255 個字母 （大寫和小寫）、數字、連字號和底線。叢集中不得有相同的服務名稱，但一個區域內或多個區域間的多個叢集中可以有類似的服務名稱。  
`desiredCount`  
指定的任務集任務定義的執行個體化數量，將放在服務內保持執行。  
`deploymentConfiguration`  
選用的部署參數，可控制在部署期間執行多少任務以及停止和啟動任務的順序。  
`tags`  
類型： 物件陣列  
必要：否  
您套用到服務以協助您分類和組織的中繼資料。每個標籤皆包含由您定義的一個金鑰與一個選用值。刪除服務時，也會一併刪除標籤。服務最多可套用 50 個標籤。如需詳細資訊，請參閱[標記 Amazon ECS 資源](ecs-using-tags.md)。  
更新服務時，此參數不會觸發新的服務部署。    
`key`  
類型：字串  
長度限制：長度下限為 1。長度上限為 128。  
必要：否  
組成標籤的鍵值組的一部分。索引鍵是一般標籤，作用就像更特定標籤值的類別。  
`value`  
類型：字串  
長度限制：長度下限為 0。長度上限為 256。  
必要：否  
組成標籤的鍵值組的選用部分。值就像標籤類別 (索引鍵) 內的描述項。  
`enableECSManagedTags`  
指定是否對服務內的使用 Amazon ECS 受管標籤。如需詳細資訊，請參閱[將標籤用於計費](ecs-using-tags.md#tag-resources-for-billing)。  
`propagateTags`  
類型：字串  
有效值：`TASK_DEFINITION` \$1 `SERVICE`  
必要：否  
指定是否將標籤從任務定義或服務複製到服務中的任務。如果沒有指定值，則不會複製標籤。標籤只能在建立服務期間複製到服務內的任務。若要在建立服務或任務後對任務新增標籤，請使用 `TagResource` API 動作。  
更新服務時，此參數不會觸發新的服務部署。  
`schedulingStrategy`  
使用的排程策略。使用外部部署控制器的服務僅支援 `REPLICA` 排程策略。  
`placementConstraints`  
您服務的任務要使用的置放限制物件陣列。每項任務您最多可以指定 10 項限制 (此限制包含任務定義中的限制以及執行時間指定的限制)。若使用的是 Fargate，則不支援任務置放限制條件。  
`placementStrategy`  
您服務的任務要使用的置放策略物件。每項服務您最多可以指定四項策略規則。

   以下是使用外部部署控制器建立服務的服務定義範例。

   ```
   {
       "cluster": "",
       "serviceName": "",
       "desiredCount": 0,
       "role": "",
       "deploymentConfiguration": {
           "maximumPercent": 0,
           "minimumHealthyPercent": 0
       },
       "placementConstraints": [
           {
               "type": "distinctInstance",
               "expression": ""
           }
       ],
       "placementStrategy": [
           {
               "type": "binpack",
               "field": ""
           }
       ],
       "schedulingStrategy": "REPLICA",
       "deploymentController": {
           "type": "EXTERNAL"
       },
       "tags": [
           {
               "key": "",
               "value": ""
           }
       ],
       "enableECSManagedTags": true,
       "propagateTags": "TASK_DEFINITION"
   }
   ```

1. 建立初始任務集。任務集包含以下關於服務的詳細資訊：  
`taskDefinition`  
供任務集的任務使用的任務定義。  
`launchType`  
類型：字串  
有效值：`EC2` \$1 `FARGATE` \$1 `EXTERNAL`  
必要：否  
您服務執行所在的啟動類型。如果未指定啟動類型，預設會使用預設的 `capacityProviderStrategy`。  
更新服務時，此參數會觸發新的服務部署。  
若有指定 `launchType`，則必須省略 `capacityProviderStrategy` 參數。  
`platformVersion`  
類型：字串  
必要：否  
您服務中任務正在其上執行的平台版本。平台版本僅會為使用 Fargate 啟動類型的任務指定。如果尚未指定，預設會使用最新版本 (`LATEST`)。  
更新服務時，此參數會觸發新的服務部署。  
AWS Fargate 平台版本用於參考 Fargate 任務基礎設施的特定執行期環境。在您執行任務或建立服務時指定 `LATEST` 平台版本，即可取得任務所能使用的最新平台版本。當您擴展服務規模時，這些任務會收到於服務的目前部署上所指定的平台版本。如需詳細資訊，請參閱[適用於 Amazon ECS 的 Fargate 平台版本](platform-fargate.md)。  
並未針對使用 EC2 啟動類型的任務指定平台版本。  
`loadBalancers`  
用來代表您的服務所使用之負載平衡器的負載平衡器物件。當使用外部部署控制器時，僅支援 Application Load Balancer 和 Network Load Balancer。如果您使用 Application Load Balancer，每個任務集僅允許一個 Application Load Balancer 目標群組。  
以下程式碼片段顯示要使用的 `loadBalancer` 物件範例。  

   ```
   "loadBalancers": [
           {
               "targetGroupArn": "",
               "containerName": "",
               "containerPort": 0
           }
   ]
   ```
指定 `loadBalancer` 物件時，您必須指定 `targetGroupArn` 並省略 `loadBalancerName` 參數。  
`networkConfiguration`  
服務的網路組態。使用 `awsvpc` 網路模式的任務定義需要此參數，才能接收其自己的彈性網路介面，其他網路模式不支援此參數。如需有關 Fargate 聯網的詳細資訊，請參閱 [Fargate 的 Amazon ECS 任務聯網選項](fargate-task-networking.md)。  
`serviceRegistries`  
要指派給此服務的服務探索登錄檔詳細資訊。如需詳細資訊，請參閱[使用服務探索以利用 DNS 名稱連接 Amazon ECS 服務](service-discovery.md)。  
`scale`  
需要放在任務集來保持執行的任務數的浮點百分比。值是以服務的 `desiredCount` 的百分比總計指定。接受的值為 0 到 100 之間的數字。

   以下是為外部部署控制器建立任務集的 JSON 範例。

   ```
   {
       "service": "",
       "cluster": "",
       "externalId": "",
       "taskDefinition": "",
       "networkConfiguration": {
           "awsvpcConfiguration": {
               "subnets": [
                   ""
               ],
               "securityGroups": [
                   ""
               ],
               "assignPublicIp": "DISABLED"
           }
       },
       "loadBalancers": [
           {
               "targetGroupArn": "",
               "containerName": "",
               "containerPort": 0
           }
       ],
       "serviceRegistries": [
           {
               "registryArn": "",
               "port": 0,
               "containerName": "",
               "containerPort": 0
           }
       ],
       "launchType": "EC2",
       "capacityProviderStrategy": [
           {
               "capacityProvider": "",
               "weight": 0,
               "base": 0
           }
       ],
       "platformVersion": "",
       "scale": {
           "value": null,
           "unit": "PERCENT"
       },
       "clientToken": ""
   }
   ```

1. 需要服務變更時，請根據您更新哪些參數，使用 `UpdateService`、`UpdateTaskSet` 或 `CreateTaskSet` API 動作。如果您建立任務集，請對服務中的每個任務集使用 `scale` 參數，以決定在服務中要保持執行多少個任務。例如，如果您有一個服務包含 `tasksetA` 並建立 `tasksetB`，您可能想要先測試 `tasksetB` 的有效性，然後才將生產流量轉移給它。您可以將這兩個任務集的 `scale` 都設為 `100`，而當您準備好將所有生產流量轉移至 `tasksetB` 時，您可以將 `tasksetA` 的 `scale` 更新為 `0` 以縮減它。

# 適用於 Amazon ECS 的 CodeDeploy 藍/綠部署
<a name="deployment-type-bluegreen"></a>

建議使用 Amazon ECS 藍/綠部署。如需詳細資訊，請參閱[建立 Amazon ECS 藍/綠部署](deploy-blue-green-service.md)。

*藍/綠*部署類型使用由 CodeDeploy 控制的藍/綠部署模式。使用此部署類型在傳送生產流量到服務之前，先驗證服務的新部署。如需詳細資訊，請參閱 *AWS CodeDeploy User Guide* 中的 [What Is CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html)。在部署之前，驗證 Amazon ECS 服務的狀態

在藍/綠部署期間，有三種流量轉移方式：
+ **Canary**：流量以兩個增量轉移。您可以從預先定義的 canary 選項中選擇，這會指定流量轉移至您於第一次增量時更新之任務集的百分比，以及在剩餘流量於第二次增量前轉移的間隔 (以分鐘計)。
+ **線性**：流量以每個增量之間的相等分鐘數按同等增量轉移。您可從預先指定的線性選項中指定每次增量的流量轉移百分比例，以及在每個增量之間的分鐘數。
+ **一次全部**：所有流量從原始任務集一次全部轉移至更新後的任務集。

以下是當在服務使用藍/綠部署類型時，Amazon ECS 使用的 CodeDeploy 的元件：

**CodeDeploy 應用程式**  
CodeDeploy 資源的集合。這包含一或多個部署群組。

**CodeDeploy 部署群組**  
部署設定。這包含下列各項：  
+ Amazon ECS 叢集和服務
+ 負載平衡器目標群組和接聽程式資訊
+ 部署復原策略
+ 流量重新路由設定
+ 原始修訂版終止設定
+ Deployment configuration (部署組態)
+ 可以設定為停止部署的 CloudWatch 警示組態
+ 通知的 SNS 或 CloudWatch Events 設定
如需詳細資訊，請參閱 *AWS CodeDeploy 使用者指南*中的[使用部署群組](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-groups.html)。

**CodeDeploy 部署組態**  
指定 CodeDeploy 在部署期間將生產流量路由到您替代任務集的方式。以下預先定義的線性與 Canary 部署組態可供使用。您也可以建立自訂定義的線性與 Canary 部署部署。如需詳細資訊，請參閱 *AWS CodeDeploy 使用者指南*中的[使用部署組態](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-configurations.html)。  
+ **CodeDeployDefault.ECSAllAtOnce**：將所有流量一次轉移至更新的 Amazon ECS 容器
+ **CodeDeployDefault.ECSLinear10PercentEvery1Minutes**：每分鐘轉移 10% 的流量，直到轉移所有流量為止。
+ **CodeDeployDefault.ECSLinear10PercentEvery3Minutes**：每 3 分鐘轉移 10% 的流量，直到轉移所有流量為止。
+ **CodeDeployDefault.ECSCanary10Percent5Minutes**：在第一次增量中轉移 10% 的流量。剩餘的 90% 會在五分鐘之後部署。
+ **CodeDeployDefault.ECSCanary10Percent15Minutes**：在第一次增量中轉移 10% 的流量。剩餘的 90% 會在 15 分鐘後部署。

**修訂**  
修訂是 CodeDeploy 應用程式規格檔案 (AppSpec 檔案)。在 AppSpec 檔案中，您會指定任務定義的完整 ARN 和建立新部署時要路由流量到其中的替代任務集的容器和連接埠。容器名稱必須是在您的任務定義中參考的其中一個容器名稱。如果已在服務定義中更新網路組態或平台版本，您還必須在 AppSpec 檔案中指定這些詳細資訊。您也可以指定要在部署生命週期事件期間執行的 Lambda 函數。Lambda 函數可讓您在部署期間執行測試和傳回指標。如需詳細資訊，請參閱 *AWS CodeDeploy 使用者指南*中的 [AppSpec 檔案參考](https://docs.aws.amazon.com/codedeploy/latest/userguide/reference-appspec-file.html)。

## 考量事項
<a name="deployment-type-bluegreen-considerations"></a>

使用藍/綠部署類型時，請考慮下列各項：
+ 一開始建立使用藍/綠部署類型的 Amazon ECS 服務時，會建立 Amazon ECS 任務集。
+ 您必須設定服務，以使用 Application Load Balancer 或 Network Load Balancer。以下是負載平衡器需求：
  + 您必須將生產接聽器新增到負載平衡器 (用於路由傳送生產流量)。
  + 可以將選用的測試接聽器新增到負載平衡器，後者用於路由測試流量。如果您指定測試接聽程式，CodeDeploy 會在部署期間將您的測試流量路由到替代任務集。
  + 生產和測試接聽器必須屬於相同的負載平衡器。
  + 您必須為負載平衡器定義目標群組。目標群組會將流量透過生產接聽器路由到服務中的原始任務集。
  + 當使用 Network Load Balancer 時，僅支援 `CodeDeployDefault.ECSAllAtOnce` 部署組態。
+ 對於被設定為使用服務自動擴展和藍/綠部署類型的服務，自動擴展不會在部署期間被封鎖，但部署可能在某些情況下失敗。以下詳細說明此行為。
  + 若服務在擴展而部署開始，綠任務集被建立，CodeDeploy 將最長等待一個小時並且不會轉移任何流量，直至綠任務集達到穩定狀態。
  + 如果服務正在進行藍/綠部署而發生擴展事件，流量將持續轉移 5 分鐘。若服務未在 5 分鐘內達到穩定狀態，CodeDeploy 將停止部署並將其標記為失敗。
+ 使用 Fargate 或 `CODE_DEPLOY` 部署控制器類型的任務，不支援 `DAEMON` 排程策略。
+ 當您一開始建立 CodeDeploy 應用程式和部署群組時，必須指定下列項目：
  + 您必須為負載平衡器定義兩個目標群組。一個目標群組必須是建立 Amazon ECS 服務時為負載平衡器定義的初始目標群組。第二個目標群組的唯一要求是，它無法與服務所使用的負載平衡器以外的其他負載平衡器相關聯。
+ 當您為 Amazon ECS 服務建立 CodeDeploy 部署時，CodeDeploy 會在部署中建立*替代任務集* (或*綠任務集*)。如果您將測試接聽程式新增至負載平衡器，CodeDeploy 會將您的測試流量路由到替代任務集。此時您可以執行任何驗證測試。然後，CodeDeploy 會根據部署群組的流量重新路由設定，將生產流量從原始任務集重新路由到替代任務集。

## 所需的 IAM 許可
<a name="deployment-type-bluegreen-IAM"></a>

透過結合 Amazon ECS 與 CodeDeploy API 可實現藍/綠部署。使用者必須擁有這些服務的適當許可，才能在 或 AWS 管理主控台 或 AWS CLI SDKs 中使用 Amazon ECS 藍/綠部署。

除了建立和更新服務的標準 IAM 許可之外，Amazon ECS 也需要下列許可。已將這些權限新增至 `AmazonECS_FullAccess` IAM 政策。如需詳細資訊，請參閱[AmazonECS\$1FullAccess](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonECS_FullAccess)。
+ `codedeploy:CreateApplication`
+ `codedeploy:CreateDeployment`
+ `codedeploy:CreateDeploymentGroup`
+ `codedeploy:GetApplication`
+ `codedeploy:GetDeployment`
+ `codedeploy:GetDeploymentGroup`
+ `codedeploy:ListApplications`
+ `codedeploy:ListDeploymentGroups`
+ `codedeploy:ListDeployments`
+ `codedeploy:StopDeployment`
+ `codedeploy:GetDeploymentTarget`
+ `codedeploy:ListDeploymentTargets`
+ `codedeploy:GetDeploymentConfig`
+ `codedeploy:GetApplicationRevision`
+ `codedeploy:RegisterApplicationRevision`
+ `codedeploy:BatchGetApplicationRevisions`
+ `codedeploy:BatchGetDeploymentGroups`
+ `codedeploy:BatchGetDeployments`
+ `codedeploy:BatchGetApplications`
+ `codedeploy:ListApplicationRevisions`
+ `codedeploy:ListDeploymentConfigs`
+ `codedeploy:ContinueDeployment`
+ `sns:ListTopics`
+ `cloudwatch:DescribeAlarms`
+ `lambda:ListFunctions`

**注意**  
除了執行任務和服務所需的標準 Amazon ECS 許可之外，使用者還需要 `iam:PassRole` 許可，才能使用任務的 IAM 角色。

CodeDeploy 需要許可來呼叫 Amazon ECS API、修改 Elastic Load Balancing、叫用 Lambda 函數和說明 CloudWatch 警示，以及代表您修改服務所需計數的許可。建立使用藍/綠部署類型的 Amazon ECS 服務之前，您必須建立一個 IAM 角色 (`ecsCodeDeployRole`)。如需詳細資訊，請參閱[Amazon ECS CodeDeploy IAM 角色](codedeploy_IAM_role.md)。

# 將 CodeDeploy 藍/綠部署遷移至 Amazon ECS 藍/綠部署
<a name="migrate-codedeploy-to-ecs-bluegreen"></a>

CodeDeploy 藍/綠部署與 Amazon ECS 藍/綠部署提供類似的功能，但兩者在設定與管理方式上有所不同。

## CodeDeploy 藍/綠部署概觀
<a name="codedeploy-bluegreen-overview"></a>

使用 CodeDeploy 建立 Amazon ECS 服務時，您需要：

1. 建立具有生產接聽程式與測試接聽程式 (選用) 的負載平衡器。每個接聽程式都會設定單一 (預設) 規則，將所有流量路由至單一目標群組 (主要目標群組)。

1. 建立 Amazon ECS 服務，設定為使用該接聽程式與目標群組，並將 `deploymentController` 類型設定為 `CODE_DEPLOY`。建立服務後，會建立已向指定目標群組註冊的 (藍色) 任務集。

1. 建立 CodeDeploy 部署群組 (作為 CodeDeploy 應用程式的一部分)，並使用 Amazon ECS 叢集、服務名稱、負載平衡器接聽程式、兩個目標群組 (用於生產接聽程式規則的主要目標群組，以及用於替代任務的次要目標群組)、服務角色 (向 CodeDeploy 授予操作 Amazon ECS 與 Elastic Load Balancing 資源的許可) 以及用於控制部署行為之各種參數的詳細資訊對該部署群組進行設定。

使用 CodeDeploy 時，會指定 CodeDeploy 應用程式名稱、部署群組名稱與 AppSpec 檔案 (該檔案提供有關新修訂版與選用 lifecycle hook 的詳細資訊)，透過 `CreateDeployment()` 部署新版本的服務。CodeDeploy 部署會建立替代 (綠色) 任務集，並向次要目標群組註冊其任務。當運作狀態良好時，即可進行測試 (選用) 與生產。在這兩種情況下，會透過將個別接聽程式規則變更為指向與綠色任務集關聯的次要目標群組來實現重新路由。透過將生產接聽程式規則變更回主要目標群組來實現復原。

## Amazon ECS 藍/綠部署概觀
<a name="ecs-bluegreen-overview"></a>

使用 Amazon ECS 藍/綠部署時，部署組態是 Amazon ECS 服務本身的一部分：

1. 必須預先設定負載平衡器生產接聽程式，並使其具備的規則包含兩個權重分別為 1 與 0 的目標群組。

1. 您需要指定下列資源，或更新服務資源：
   + 此接聽程式規則的 ARN 
   + 兩個目標群組
   + IAM 角色，用於授予 Amazon ECS 呼叫 Elastic Load Balancing API 的許可
   + 選用 IAM 角色，用於執行 Lambda 函式
   + 將 `deploymentController` 類型設定為 `ECS`，並將 `deploymentConfiguration.strategy` 設定為 `BLUE_GREEN`。這會建立 (藍色) 服務部署，並向主要目標群組註冊其任務。

使用 Amazon ECS 藍/綠部署時，會透過呼叫 Amazon ECS `UpdateService()` 建立新的服務修訂版，並傳遞新修訂版的詳細資訊。服務部署會建立新的 (綠色) 服務修訂版任務，並向次要目標群組註冊任務。Amazon ECS 透過切換接聽程式規則上的權重來處理重新路由與復原操作。

## 關鍵實作差異
<a name="implementation-differences"></a>

雖然這兩種方法都會建立初始任務集，但基礎實作有所不同：
+ CodeDeploy 使用任務集，而 Amazon ECS 使用服務修訂版。Amazon ECS 任務集是較舊的建構模組，已由 Amazon ECS 服務修訂版與部署取代。後者提供了對部署程序以及服務部署與服務修訂版歷史記錄的更高可見性。
+ 對於 CodeDeploy，lifecycle hook 會指定為提供給 `CreateDeployment()` 之 AppSpec 檔案的一部分。這表示勾點可以在不同的部署之間變更。對於 Amazon ECS 藍/綠部署，勾點會指定為服務組態的一部分，進行任何更新都需要呼叫 `UpdateService()`。
+ CodeDeploy 與 Amazon ECS 藍/綠部署都使用 Lambda 進行勾點實作，但預期的輸入與輸出有所不同。

  對於 CodeDeploy，函式必須呼叫 `PutLifecycleEventHookExecutionStatus()` 才能傳回勾點狀態，狀態可以是 `SUCCEEDED` 或 `FAILED`。對於 Amazon ECS，Lambda 回應用於指示勾點狀態。
+ CodeDeploy 會調用每個勾點作為一次性呼叫，且預期會在一小時內傳回最終執行狀態。Amazon ECS 勾點則更具彈性，因為它們可以傳回 `IN_PROGRESS` 指標，這表示必須反复重新調用勾點，直到狀態為 `SUCCEEDED` 或 `FAILED`。如需詳細資訊，請參閱[Amazon ECS 服務部署的 lifecycle hook](deployment-lifecycle-hooks.md)。

## 遷移方法
<a name="migration-paths"></a>

從 CodeDeploy 藍/綠部署遷移到 Amazon ECS 藍/綠部署主要有三種方法。每種方法在複雜性、風險、復原功能與潛在停機時間方面都有不同的特性。

### 重複使用用於 CodeDeploy 的相同 Elastic Load Balancing 資源
<a name="inplace-update"></a>

您可以更新現有的 Amazon ECS 服務，以搭配藍/綠部署策略使用 Amazon ECS 部署控制器，而不是 CodeDeploy 部署控制器。採取此方法時，請考量下列事項：
+ 遷移程序更為簡單，因為您正在更新現有的 Amazon ECS 服務部署控制器與部署策略。
+ 正確設定與遷移時，不會有停機時間。
+ 復原需要您還原服務修訂版。
+ 風險較高，因為沒有平行的藍/綠組態。

您可以使用與用於 CodeDeploy 的相同負載平衡器接聽程式及目標群組。如果您使用的是 CloudFormation，請參閱 [將 CloudFormation CodeDeploy 藍/綠部署範本遷移至 Amazon ECS 藍/綠 CloudFormation 範本](migrate-codedeploy-to-ecs-bluegreen-cloudformation-template.md)。

1. 修改生產/測試接聽程式的預設規則，以包含替代目標群組，並將主要目標群組的權重設定為 1，將替代目標群組設定為 0。

   對於 CodeDeploy，必須為連接至服務的負載平衡器接聽程式設定單一 (預設) 規則，將所有流量路由至單一目標群組。對於 Amazon ECS 藍/綠部署，負載平衡器接聽程式必須預先設定規則，其中包含兩個具有權重的目標群組。主要目標群組的權重必須為 1，替代目標群組的權重必須為 0。

1. 透過呼叫 `UpdateService` API 並將參數 `deploymentController` 設定為 `ECS`，將參數 `deploymentStrategy` 設定為 `BLUE_GREEN`，來更新現有的 Amazon ECS 服務。指定目標群組、替代目標群組、生產接聽程式以及選用的測試接聽程式的 ARN。

1. 驗證服務是否如預期般運作。

1. 刪除此 Amazon ECS 服務的 CodeDeploy 設定，因為您現在使用的是 Amazon ECS 藍/綠部署。

### 使用現有負載平衡器的新服務
<a name="new-service-existing-lb"></a>

此方法使用藍/綠策略進行遷移。

採取此方法時，請考量下列事項：
+ 干擾最少。僅在 Elastic Load Balancing 連接埠交換期間發生。
+ 復原需要還原 Elastic Load Balancing 連接埠交換。
+ 風險較低，因為存在平行組態。因此，您可以在流量轉移之前進行測試。

1. 保持 CodeDeploy 設定的接聽程式、目標群組與 Amazon ECS 服務不變，以便您可以視需要輕鬆復原至此設定。

1. 在現有負載平衡器下建立新的目標群組與新的接聽程式 (使用與原始接聽程式不同的連接埠)。然後，建立一個符合現有 Amazon ECS 服務的新 Amazon ECS 服務，不同之處在於使用 `ECS` 作為部署控制器，`BLUE_GREEN` 作為部署策略，並傳遞新目標群組與新接聽程式規則的 ARN。

1. 透過向服務手動傳送 HTTP 流量來驗證新設定。如果一切順利，請交換原始接聽程式與新接聽程式的連接埠，將流量路由至新設定。

1. 驗證新設定，如果一切繼續如預期般運作，則刪除 CodeDeploy 設定。

### 使用新負載平衡器的新服務
<a name="new-service-new-lb"></a>

與前一種方法類似，此方法使用藍/綠策略進行遷移。關鍵差異在於從 CodeDeploy 設定切換到 Amazon ECS 藍/綠設定發生於負載平衡器上方的反向代理層。反向代理層的範例實作是 Route 53 與 CloudFront。

此方法適用於已經擁有此反向代理層的客戶，並且所有與服務的通訊都透過該代理層進行的情況 (例如，負載平衡器層級沒有直接通訊)。

採取此方法時，請考量下列事項：
+ 這需要反向代理層。
+ 遷移程序更為複雜，因為您需要更新現有的 Amazon ECS 服務部署控制器與部署策略。
+ 干擾最少。僅在 Elastic Load Balancing 連接埠交換期間發生。
+ 復原需要您反轉代理組態變更。
+ 風險較低，因為存在平行組態。因此，您可以在流量轉移之前進行測試。

1. 請勿完全修改現有的 CodeDeploy 設定 (負載平衡器、接聽程式、目標群組、Amazon ECS 服務與 CodeDeploy 部署群組)。

1. 建立針對 Amazon ECS 藍/綠部署設定的新負載平衡器、目標群組與接聽程式。

   設定相應的資源。
   + Application Load Balancer – 如需詳細資訊，請參閱[藍/綠、線性和金絲雀部署的 Application Load Balancer 資源](alb-resources-for-blue-green.md)。
   + Network Load Balancer – 如需詳細資訊，請參閱[Amazon ECS 藍/綠、線性和 Canary 部署的 Network Load Balancer 資源](nlb-resources-for-blue-green.md)。

1. 建立新服務，將 `ECS` 作為部署控制器，`BLUE_GREEN` 作為部署策略，並指向新的負載平衡器資源。

1. 透過新的負載平衡器測試新設定，以驗證設定。

1. 更新反向代理組態，將流量路由至新的負載平衡器。

1. 觀測新的服務修訂版，如果一切繼續如預期般運作，則刪除 CodeDeploy 設定。

## 後續步驟
<a name="post-migration-considerations"></a>

遷移至 Amazon ECS 藍/綠部署之後：
+ 更新部署指令碼與 CI/CD 管道，以使用 Amazon ECS `UpdateService` API 而不是 CodeDeploy `CreateDeployment` API。
+ 更新監控與提醒，以追蹤 Amazon ECS 服務部署，而不是 CodeDeploy 部署。
+ 請考慮實作新部署程序的自動化測試，確保其如預期般運作。

# 從 CodeDeploy 藍/綠部署遷移至 Amazon ECS 藍/綠服務部署
<a name="migrate-code-deploy-to-ecs-blue-green"></a>

 透過使用 Amazon ECS 藍/綠部署，您可以進行服務變更並加以測試，然後在生產環境中實作這些變更。

必須為 Amazon ECS 藍/綠部署建立新的 lifecycle hook。

## 先決條件
<a name="migrate-code-deploy-to-ecs-blue-green-prerequisites"></a>

開始藍/綠部署之前，請執行下列動作。

1. 將 Amazon ECS CodeDeploy IAM 角色取代為下列許可。
   + 如需有關 Elastic Load Balancing 許可的資訊，請參閱[負載平衡器的 Amazon ECS 基礎結構 IAM 角色](AmazonECSInfrastructureRolePolicyForLoadBalancers.md)。
   + 如需有關 Lambda 許可的資訊，請參閱 [Amazon ECS 藍/綠部署中 Lambda 函式所需的許可](blue-green-permissions.md)。

1. 關閉 CodeDeploy 自動化。如需詳細資訊，請參閱 *CodeDeploy User Guide* 中的 [Working with deployment groups in CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-groups.html)。

1. 確定擁有 CodeDeploy 藍/綠部署中的下列資訊。您可以重複使用這些資訊進行 Amazon ECS 藍/綠部署：
   + 生產目標群組
   + 生產接聽程式
   + 生產規則
   + 測試目標群組

     這是綠色服務修訂版的目標群組，

1. 確保 Application Load Balancer 目標群組與接聽程式規則正確建立關聯：
   + 如果您未使用測試接聽程式，則兩個目標群組 (生產與測試) 都必須與生產接聽程式規則建立關聯。
   + 如果您使用的是測試接聽程式，一個目標群組必須連結至生產接聽程式規則，另一個目標群組則必須連結至測試接聽程式規則。

   如果不符合此需求，服務部署將會失敗，並出現下列錯誤：`Service deployment rolled back because of invalid networking configuration. Both targetGroup and alternateTargetGroup must be associated with the productionListenerRule or testListenerRule.`

1. 確認服務沒有正在進行的服務部署。如需詳細資訊，請參閱[使用 Amazon ECS 服務部署檢視服務歷史記錄](service-deployment.md)。

1. Amazon ECS 藍/綠部署要求服務使用下列其中一項功能：設定相應的資源。
   + Application Load Balancer – 如需詳細資訊，請參閱[藍/綠、線性和金絲雀部署的 Application Load Balancer 資源](alb-resources-for-blue-green.md)。
   + Network Load Balancer – 如需詳細資訊，請參閱[Amazon ECS 藍/綠、線性和 Canary 部署的 Network Load Balancer 資源](nlb-resources-for-blue-green.md)。
   + Service Connect – 如需詳細資訊，請參閱[Amazon ECS 藍色/綠色、線性和 Canary 部署的 Service Connect 資源](service-connect-blue-green.md)。

1. 決定是否要為 Amazon ECS 藍/綠部署中的生命週期階段執行 Lambda 函式。
   + 向上擴展前
   + 向上擴展後
   + 測試流量轉移
   + 測試流量轉移後
   + 生產流量轉移
   + 生產流量轉移後

   為每個生命週期階段建立 Lambda 函式。如需詳細資訊，請參閱 *AWS Lambda Developer Guide* 中的 [Create a Lambda function with the console](https://docs.aws.amazon.com/lambda/latest/dg/getting-started.html#getting-started-create-function)。

如需有關更新服務部署控制器的詳細資訊，請參閱[更新 Amazon ECS 服務參數](update-service-parameters.md)。

## 程序
<a name="migrate-code-deploy-to-ecs-procedure"></a>

1. 開啟主控台，網址為 [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)。

1. 在**叢集**頁面上，選擇叢集。

   「叢集詳細資訊」頁面隨即顯示。

1. 從**服務**索引標籤中選擇服務。

   服務詳細資訊頁面隨即顯示。

1. 在橫幅中，選擇**更新部署控制器類型**。

   **遷移部署控制器類型**頁面隨即顯示。

1. 展開**新增**區段，然後指定下列參數。

   1. 在**部署控制器類型**欄位中選擇 **ECS**。

   1. 在**部署策略**欄位中選擇**藍/綠部署**。

   1. 在**封裝時間**欄位中，輸入藍色與綠色服務修訂版同時執行的時間。

   1. 若要為生命週期階段執行 Lambda 函式，請在**部署 lifecycle hook** 下為每個唯一的 Lambda 函式執行下列動作：

      1. 選擇**新增**。

         針對每個要執行的唯一函式重複此步驟。

      1. 在 **Lambda 函式**欄位中輸入函式名稱。

      1. 在**角色**欄位中，選擇您在先決條件中建立的具有藍/綠部署許可的角色。

         如需詳細資訊，請參閱[Amazon ECS 藍/綠部署中 Lambda 函式所需的許可](blue-green-permissions.md)。

      1. 在**生命週期階段**欄位中選取 Lambda 函式執行的階段。

      1.  (選用) 在**勾點詳細資訊**欄位中，輸入提供勾點相關資訊的鍵值對。

1. 展開**負載平衡**區段，並設定下列項目：

   1. 在**角色**欄位中，選擇您在先決條件中建立的具有藍/綠部署許可的角色。

      如需詳細資訊，請參閱[Amazon ECS 藍/綠部署中 Lambda 函式所需的許可](blue-green-permissions.md)。

   1. 在**接聽程式**欄位中，從 CodeDeploy 藍/綠部署中選擇生產接聽程式。

   1. 在**生產規則**欄位中，從 CodeDeploy 藍/綠部署中選擇生產規則。

   1. 在**測試規則**欄位中，從 CodeDeploy 藍/綠部署中選擇測試規則。

   1. 在**目標群組**欄位中，從 CodeDeploy 藍/綠部署中選擇生產目標群組。

   1. 在**替代目標群組**欄位中，從 CodeDeploy 藍/綠部署中選擇測試目標群組。

1. 選擇**更新**。

## 後續步驟
<a name="migrate-code-deploy-to-ecs-blue-green-next-steps"></a>
+ 更新服務以開始部署。如需詳細資訊，請參閱[更新 Amazon ECS 服務](update-service-console-v2.md)。
+ 監控部署程序，確保其遵循藍/綠模式：
  + 綠色服務修訂版已建立並向上擴展
  + 測試流量會路由至綠色修訂版 (若已設定)
  + 生產流量會轉移至綠色修訂版
  + 封裝時間過期後，藍色修訂版會終止

# 將 CloudFormation CodeDeploy 藍/綠部署範本遷移至 Amazon ECS 藍/綠 CloudFormation 範本
<a name="migrate-codedeploy-to-ecs-bluegreen-cloudformation-template"></a>

將針對 Amazon ECS 服務使用 CodeDeploy 藍/綠部署的 CloudFormation 範本遷移至使用原生 Amazon ECS 藍/綠部署策略的範本。遷移遵循「重複使用用於 CodeDeploy 的相同 Elastic Load Balancing 資源」方法。如需詳細資訊，請參閱[將 CodeDeploy 藍/綠部署遷移至 Amazon ECS 藍/綠部署](migrate-codedeploy-to-ecs-bluegreen.md)。

## 來源範本
<a name="source-template"></a>

此範本使用 `AWS::CodeDeployBlueGreen` 轉換與 `AWS::CodeDeploy::BlueGreen` 勾點為 Amazon ECS 服務實作藍/綠部署。

### 來源
<a name="code-deploy-source"></a>

這是使用 CodeDeploy 藍/綠部署的完整 CloudFormation 範本。如需詳細資訊，請參閱* AWS CloudFormation 《 使用者指南*》中的[藍/綠部署範本範例](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/blue-green-template-example.html#blue-green-template-example.json)：

```
{
  "AWSTemplateFormatVersion": "2010-09-09",
  "Parameters": {
    "Vpc": {
      "Type": "AWS::EC2::VPC::Id"
    },
    "Subnet1": {
      "Type": "AWS::EC2::Subnet::Id"
    },
    "Subnet2": {
      "Type": "AWS::EC2::Subnet::Id"
    }
  },
  "Transform": [
    "AWS::CodeDeployBlueGreen"
  ],
  "Hooks": {
    "CodeDeployBlueGreenHook": {
      "Type": "AWS::CodeDeploy::BlueGreen",
      "Properties": {
        "TrafficRoutingConfig": {
          "Type": "TimeBasedCanary",
          "TimeBasedCanary": {
            "StepPercentage": 15,
            "BakeTimeMins": 5
          }
        },
        "Applications": [
          {
            "Target": {
              "Type": "AWS::ECS::Service",
              "LogicalID": "ECSDemoService"
            },
            "ECSAttributes": {
              "TaskDefinitions": [
                "BlueTaskDefinition",
                "GreenTaskDefinition"
              ],
              "TaskSets": [
                "BlueTaskSet",
                "GreenTaskSet"
              ],
              "TrafficRouting": {
                "ProdTrafficRoute": {
                  "Type": "AWS::ElasticLoadBalancingV2::Listener",
                  "LogicalID": "ALBListenerProdTraffic"
                },
                "TargetGroups": [
                  "ALBTargetGroupBlue",
                  "ALBTargetGroupGreen"
                ]
              }
            }
          }
        ]
      }
    }
  },
  "Resources": {
    "ExampleSecurityGroup": {
      "Type": "AWS::EC2::SecurityGroup",
      "Properties": {
        "GroupDescription": "Security group for ec2 access",
        "VpcId": {"Ref": "Vpc"},
        "SecurityGroupIngress": [
          {
            "IpProtocol": "tcp",
            "FromPort": 80,
            "ToPort": 80,
            "CidrIp": "0.0.0.0/0"
          },
          {
            "IpProtocol": "tcp",
            "FromPort": 8080,
            "ToPort": 8080,
            "CidrIp": "0.0.0.0/0"
          },
          {
            "IpProtocol": "tcp",
            "FromPort": 22,
            "ToPort": 22,
            "CidrIp": "0.0.0.0/0"
          }
        ]
      }
    },
    "ALBTargetGroupBlue": {
      "Type": "AWS::ElasticLoadBalancingV2::TargetGroup",
      "Properties": {
        "HealthCheckIntervalSeconds": 5,
        "HealthCheckPath": "/",
        "HealthCheckPort": "80",
        "HealthCheckProtocol": "HTTP",
        "HealthCheckTimeoutSeconds": 2,
        "HealthyThresholdCount": 2,
        "Matcher": {
          "HttpCode": "200"
        },
        "Port": 80,
        "Protocol": "HTTP",
        "Tags": [
          {
            "Key": "Group",
            "Value": "Example"
          }
        ],
        "TargetType": "ip",
        "UnhealthyThresholdCount": 4,
        "VpcId": {"Ref": "Vpc"}
      }
    },
    "ALBTargetGroupGreen": {
      "Type": "AWS::ElasticLoadBalancingV2::TargetGroup",
      "Properties": {
        "HealthCheckIntervalSeconds": 5,
        "HealthCheckPath": "/",
        "HealthCheckPort": "80",
        "HealthCheckProtocol": "HTTP",
        "HealthCheckTimeoutSeconds": 2,
        "HealthyThresholdCount": 2,
        "Matcher": {
          "HttpCode": "200"
        },
        "Port": 80,
        "Protocol": "HTTP",
        "Tags": [
          {
            "Key": "Group",
            "Value": "Example"
          }
        ],
        "TargetType": "ip",
        "UnhealthyThresholdCount": 4,
        "VpcId": {"Ref": "Vpc"}
      }
    },
    "ExampleALB": {
      "Type": "AWS::ElasticLoadBalancingV2::LoadBalancer",
      "Properties": {
        "Scheme": "internet-facing",
        "SecurityGroups": [
          {"Ref": "ExampleSecurityGroup"}
        ],
        "Subnets": [
          {"Ref": "Subnet1"},
          {"Ref": "Subnet2"}
        ],
        "Tags": [
          {
            "Key": "Group",
            "Value": "Example"
          }
        ],
        "Type": "application",
        "IpAddressType": "ipv4"
      }
    },
    "ALBListenerProdTraffic": {
      "Type": "AWS::ElasticLoadBalancingV2::Listener",
      "Properties": {
        "DefaultActions": [
          {
            "Type": "forward",
            "ForwardConfig": {
              "TargetGroups": [
                {
                  "TargetGroupArn": {"Ref": "ALBTargetGroupBlue"},
                  "Weight": 1
                }
              ]
            }
          }
        ],
        "LoadBalancerArn": {"Ref": "ExampleALB"},
        "Port": 80,
        "Protocol": "HTTP"
      }
    },
    "ALBListenerProdRule": {
      "Type": "AWS::ElasticLoadBalancingV2::ListenerRule",
      "Properties": {
        "Actions": [
          {
            "Type": "forward",
            "ForwardConfig": {
              "TargetGroups": [
                {
                  "TargetGroupArn": {"Ref": "ALBTargetGroupBlue"},
                  "Weight": 1
                }
              ]
            }
          }
        ],
        "Conditions": [
          {
            "Field": "http-header",
            "HttpHeaderConfig": {
              "HttpHeaderName": "User-Agent",
              "Values": [
                "Mozilla"
              ]
            }
          }
        ],
        "ListenerArn": {"Ref": "ALBListenerProdTraffic"},
        "Priority": 1
      }
    },
    "ECSTaskExecutionRole": {
      "Type": "AWS::IAM::Role",
      "Properties": {
        "AssumeRolePolicyDocument": {
          "Version": "2012-10-17",		 	 	 
          "Statement": [
            {
              "Sid": "",
              "Effect": "Allow",
              "Principal": {
                "Service": "ecs-tasks.amazonaws.com"
              },
              "Action": "sts:AssumeRole"
            }
          ]
        },
        "ManagedPolicyArns": [
          "arn:aws:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy"
        ]
      }
    },
    "BlueTaskDefinition": {
      "Type": "AWS::ECS::TaskDefinition",
      "Properties": {
        "ExecutionRoleArn": {"Fn::GetAtt": ["ECSTaskExecutionRole", "Arn"]},
        "ContainerDefinitions": [
          {
            "Name": "DemoApp",
            "Image": "nginxdemos/hello:latest",
            "Essential": true,
            "PortMappings": [
              {
                "HostPort": 80,
                "Protocol": "tcp",
                "ContainerPort": 80
              }
            ]
          }
        ],
        "RequiresCompatibilities": [
          "FARGATE"
        ],
        "NetworkMode": "awsvpc",
        "Cpu": "256",
        "Memory": "512",
        "Family": "ecs-demo"
      }
    },
    "ECSDemoCluster": {
      "Type": "AWS::ECS::Cluster",
      "Properties": {}
    },
    "ECSDemoService": {
      "Type": "AWS::ECS::Service",
      "Properties": {
        "Cluster": {"Ref": "ECSDemoCluster"},
        "DesiredCount": 1,
        "DeploymentController": {
          "Type": "EXTERNAL"
        }
      }
    },
    "BlueTaskSet": {
      "Type": "AWS::ECS::TaskSet",
      "Properties": {
        "Cluster": {"Ref": "ECSDemoCluster"},
        "LaunchType": "FARGATE",
        "NetworkConfiguration": {
          "AwsVpcConfiguration": {
            "AssignPublicIp": "ENABLED",
            "SecurityGroups": [
              {"Ref": "ExampleSecurityGroup"}
            ],
            "Subnets": [
              {"Ref": "Subnet1"},
              {"Ref": "Subnet2"}
            ]
          }
        },
        "PlatformVersion": "1.4.0",
        "Scale": {
          "Unit": "PERCENT",
          "Value": 100
        },
        "Service": {"Ref": "ECSDemoService"},
        "TaskDefinition": {"Ref": "BlueTaskDefinition"},
        "LoadBalancers": [
          {
            "ContainerName": "DemoApp",
            "ContainerPort": 80,
            "TargetGroupArn": {"Ref": "ALBTargetGroupBlue"}
          }
        ]
      }
    },
    "PrimaryTaskSet": {
      "Type": "AWS::ECS::PrimaryTaskSet",
      "Properties": {
        "Cluster": {"Ref": "ECSDemoCluster"},
        "Service": {"Ref": "ECSDemoService"},
        "TaskSetId": {"Fn::GetAtt": ["BlueTaskSet", "Id"]}
      }
    }
  }
}
```

## 移轉步驟
<a name="migration-steps"></a>

### 移除 CodeDeploy 特定資源
<a name="remove-codedeploy-resources"></a>

不再需要下列屬性：
+ `AWS::CodeDeployBlueGreen` 轉換
+ `CodeDeployBlueGreenHook` 勾點
+ `GreenTaskDefinition` 與 `GreenTaskSet` 資源 (這些資源將由 Amazon ECS 管理)
+ `PrimaryTaskSet` 資源 (Amazon ECS 將在內部管理任務集)

### 重新設定負載平衡器接聽程式
<a name="reconfigure-load-balancer"></a>

修改 `ALBListenerProdTraffic` 資源以使用具有兩個目標群組的轉送動作：

```
{
  "DefaultActions": [
    {
      "Type": "forward",
      "ForwardConfig": {
        "TargetGroups": [
          {
            "TargetGroupArn": {"Ref": "ALBTargetGroupBlue"},
            "Weight": 1
          },
          {
            "TargetGroupArn": {"Ref": "ALBTargetGroupGreen"},
            "Weight": 0
          }
        ]
      }
    }
  ]
}
```

### 更新部署屬性
<a name="update-ecs-service"></a>

更新並新增下列項目：
+ 將 `DeploymentController` 屬性從 `EXTERNAL` 變更為 `ECS`。
+ 新增 `Strategy` 屬性，並將其設定為 BLUE\$1GREEN。
+ 新增 `BakeTimeInMinutes` 屬性。

  ```
  {
    "DeploymentConfiguration": {
      "MaximumPercent": 200,
      "MinimumHealthyPercent": 100,
      "DeploymentCircuitBreaker": {
        "Enable": true,
        "Rollback": true
      },
      "BakeTimeInMinutes": 5,
      "Strategy": "BLUE_GREEN"
    }
  }
  ```
+ 將負載平衡器組態新增至服務：

  ```
  {
    "LoadBalancers": [
      {
        "ContainerName": "DemoApp",
        "ContainerPort": 80,
        "TargetGroupArn": {"Ref": "ALBTargetGroupBlue"},
        "AdvancedConfiguration": {
          "AlternateTargetGroupArn": {"Ref": "ALBTargetGroupGreen"},
          "ProductionListenerRule": {"Ref": "ALBListenerProdRule"},
          "RoleArn": {"Fn::GetAtt": ["ECSInfrastructureRoleForLoadBalancers", "Arn"]}
        }
      }
    ]
  }
  ```
+ 將任務定義參考新增至服務：

  ```
  {
    "TaskDefinition": {"Ref": "BlueTaskDefinition"}
  }
  ```

### 建立 AmazonECSInfrastructureRolePolicyForLoadBalancers 角色
<a name="create-ecs-service-role"></a>

新增允許 Amazon ECS 管理負載平衡器資源的新 IAM 角色。如需詳細資訊，請參閱[負載平衡器的 Amazon ECS 基礎結構 IAM 角色](AmazonECSInfrastructureRolePolicyForLoadBalancers.md)

## 測試建議
<a name="testing-recommendations"></a>

1. 將遷移後的範本部署至非生產環境。

1. 確認服務已使用初始組態正確部署。

1. 透過更新任務定義並觀測藍/綠部署程序來測試部署。

1. 確認流量在藍色與綠色部署之間正確轉移。

1. 透過強制執行部署失敗來測試復原功能。

## 遷移後的範本
<a name="migrated-template"></a>

### 最終範本
<a name="ecs-bluegreen-template"></a>

這是使用 Amazon ECS 藍/綠部署的完整 CloudFormation 範本：

```
{
  "AWSTemplateFormatVersion": "2010-09-09",
  "Parameters": {
    "Vpc": {
      "Type": "AWS::EC2::VPC::Id"
    },
    "Subnet1": {
      "Type": "AWS::EC2::Subnet::Id"
    },
    "Subnet2": {
      "Type": "AWS::EC2::Subnet::Id"
    }
  },
  "Resources": {
    "ExampleSecurityGroup": {
      "Type": "AWS::EC2::SecurityGroup",
      "Properties": {
        "GroupDescription": "Security group for ec2 access",
        "VpcId": {"Ref": "Vpc"},
        "SecurityGroupIngress": [
          {
            "IpProtocol": "tcp",
            "FromPort": 80,
            "ToPort": 80,
            "CidrIp": "0.0.0.0/0"
          },
          {
            "IpProtocol": "tcp",
            "FromPort": 8080,
            "ToPort": 8080,
            "CidrIp": "0.0.0.0/0"
          },
          {
            "IpProtocol": "tcp",
            "FromPort": 22,
            "ToPort": 22,
            "CidrIp": "0.0.0.0/0"
          }
        ]
      }
    },
    "ALBTargetGroupBlue": {
      "Type": "AWS::ElasticLoadBalancingV2::TargetGroup",
      "Properties": {
        "HealthCheckIntervalSeconds": 5,
        "HealthCheckPath": "/",
        "HealthCheckPort": "80",
        "HealthCheckProtocol": "HTTP",
        "HealthCheckTimeoutSeconds": 2,
        "HealthyThresholdCount": 2,
        "Matcher": {
          "HttpCode": "200"
        },
        "Port": 80,
        "Protocol": "HTTP",
        "Tags": [
          {
            "Key": "Group",
            "Value": "Example"
          }
        ],
        "TargetType": "ip",
        "UnhealthyThresholdCount": 4,
        "VpcId": {"Ref": "Vpc"}
      }
    },
    "ALBTargetGroupGreen": {
      "Type": "AWS::ElasticLoadBalancingV2::TargetGroup",
      "Properties": {
        "HealthCheckIntervalSeconds": 5,
        "HealthCheckPath": "/",
        "HealthCheckPort": "80",
        "HealthCheckProtocol": "HTTP",
        "HealthCheckTimeoutSeconds": 2,
        "HealthyThresholdCount": 2,
        "Matcher": {
          "HttpCode": "200"
        },
        "Port": 80,
        "Protocol": "HTTP",
        "Tags": [
          {
            "Key": "Group",
            "Value": "Example"
          }
        ],
        "TargetType": "ip",
        "UnhealthyThresholdCount": 4,
        "VpcId": {"Ref": "Vpc"}
      }
    },
    "ExampleALB": {
      "Type": "AWS::ElasticLoadBalancingV2::LoadBalancer",
      "Properties": {
        "Scheme": "internet-facing",
        "SecurityGroups": [
          {"Ref": "ExampleSecurityGroup"}
        ],
        "Subnets": [
          {"Ref": "Subnet1"},
          {"Ref": "Subnet2"}
        ],
        "Tags": [
          {
            "Key": "Group",
            "Value": "Example"
          }
        ],
        "Type": "application",
        "IpAddressType": "ipv4"
      }
    },
    "ALBListenerProdTraffic": {
      "Type": "AWS::ElasticLoadBalancingV2::Listener",
      "Properties": {
        "DefaultActions": [
          {
            "Type": "forward",
            "ForwardConfig": {
              "TargetGroups": [
                {
                  "TargetGroupArn": {"Ref": "ALBTargetGroupBlue"},
                  "Weight": 1
                },
                {
                  "TargetGroupArn": {"Ref": "ALBTargetGroupGreen"},
                  "Weight": 0
                }
              ]
            }
          }
        ],
        "LoadBalancerArn": {"Ref": "ExampleALB"},
        "Port": 80,
        "Protocol": "HTTP"
      }
    },
    "ALBListenerProdRule": {
      "Type": "AWS::ElasticLoadBalancingV2::ListenerRule",
      "Properties": {
        "Actions": [
          {
            "Type": "forward",
            "ForwardConfig": {
              "TargetGroups": [
                {
                  "TargetGroupArn": {"Ref": "ALBTargetGroupBlue"},
                  "Weight": 1
                },
                {
                  "TargetGroupArn": {"Ref": "ALBTargetGroupGreen"},
                  "Weight": 0
                }
              ]
            }
          }
        ],
        "Conditions": [
          {
            "Field": "http-header",
            "HttpHeaderConfig": {
              "HttpHeaderName": "User-Agent",
              "Values": [
                "Mozilla"
              ]
            }
          }
        ],
        "ListenerArn": {"Ref": "ALBListenerProdTraffic"},
        "Priority": 1
      }
    },
    "ECSTaskExecutionRole": {
      "Type": "AWS::IAM::Role",
      "Properties": {
        "AssumeRolePolicyDocument": {
          "Version": "2012-10-17",		 	 	 
          "Statement": [
            {
              "Sid": "",
              "Effect": "Allow",
              "Principal": {
                "Service": "ecs-tasks.amazonaws.com"
              },
              "Action": "sts:AssumeRole"
            }
          ]
        },
        "ManagedPolicyArns": [
          "arn:aws:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy"
        ]
      }
    },
    "ECSInfrastructureRoleForLoadBalancers": {
      "Type": "AWS::IAM::Role",
      "Properties": {
        "AssumeRolePolicyDocument": {
          "Version": "2012-10-17",		 	 	 
          "Statement": [
            {
              "Sid": "AllowAccessToECSForInfrastructureManagement",
              "Effect": "Allow",
              "Principal": {
                "Service": "ecs.amazonaws.com"
              },
              "Action": "sts:AssumeRole"
            }
          ]
        },
        "ManagedPolicyArns": [
          "arn:aws:iam::aws:policy/AmazonECSInfrastructureRolePolicyForLoadBalancers"
        ]
      }
    },
    "BlueTaskDefinition": {
      "Type": "AWS::ECS::TaskDefinition",
      "Properties": {
        "ExecutionRoleArn": {"Fn::GetAtt": ["ECSTaskExecutionRole", "Arn"]},
        "ContainerDefinitions": [
          {
            "Name": "DemoApp",
            "Image": "nginxdemos/hello:latest",
            "Essential": true,
            "PortMappings": [
              {
                "HostPort": 80,
                "Protocol": "tcp",
                "ContainerPort": 80
              }
            ]
          }
        ],
        "RequiresCompatibilities": [
          "FARGATE"
        ],
        "NetworkMode": "awsvpc",
        "Cpu": "256",
        "Memory": "512",
        "Family": "ecs-demo"
      }
    },
    "ECSDemoCluster": {
      "Type": "AWS::ECS::Cluster",
      "Properties": {}
    },
    "ECSDemoService": {
      "Type": "AWS::ECS::Service",
      "Properties": {
        "Cluster": {"Ref": "ECSDemoCluster"},
        "DesiredCount": 1,
        "DeploymentController": {
          "Type": "ECS"
        },
        "DeploymentConfiguration": {
          "MaximumPercent": 200,
          "MinimumHealthyPercent": 100,
          "DeploymentCircuitBreaker": {
            "Enable": true,
            "Rollback": true
          },
          "BakeTimeInMinutes": 5,
          "Strategy": "BLUE_GREEN"
        },
        "NetworkConfiguration": {
          "AwsvpcConfiguration": {
            "AssignPublicIp": "ENABLED",
            "SecurityGroups": [
              {"Ref": "ExampleSecurityGroup"}
            ],
            "Subnets": [
              {"Ref": "Subnet1"},
              {"Ref": "Subnet2"}
            ]
          }
        },
        "LaunchType": "FARGATE",
        "PlatformVersion": "1.4.0",
        "TaskDefinition": {"Ref": "BlueTaskDefinition"},
        "LoadBalancers": [
          {
            "ContainerName": "DemoApp",
            "ContainerPort": 80,
            "TargetGroupArn": {"Ref": "ALBTargetGroupBlue"},
            "AdvancedConfiguration": {
              "AlternateTargetGroupArn": {"Ref": "ALBTargetGroupGreen"},
              "ProductionListenerRule": {"Ref": "ALBListenerProdRule"},
              "RoleArn": {"Fn::GetAtt": ["ECSInfrastructureRoleForLoadBalancers", "Arn"]}
            }
          }
        ]
      }
    }
  }
}
```

# 從 CodeDeploy 藍/綠部署遷移至 Amazon ECS 滾動更新服務部署
<a name="migrate-code-deploy-to-ecs-rolling"></a>

 您可以將服務部署從 CodeDeploy 藍/綠部署遷移至 Amazon ECS 滾動更新部署。這將使您擺脫 CodeDeploy 相依性，轉而使用整合式部署。

Amazon ECS 服務排程器會將目前執行的任務取代為新任務。Amazon ECS 在滾動更新期間從服務新增或移除的任務數量是由服務部署組態控制。

## 先決條件
<a name="migrate-code-deploy-to-ecs-rolling-prerequisites"></a>

開始藍/綠部署之前，請執行下列動作。

1. 您不再需要 Amazon ECS CodeDeploy IAM 角色。

1. 關閉 CodeDeploy 自動化。如需詳細資訊，請參閱 *CodeDeploy User Guide* 中的 [Working with deployment groups in CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-groups.html)。

1. 確認服務沒有正在進行的服務部署。如需詳細資訊，請參閱[使用 Amazon ECS 服務部署檢視服務歷史記錄](service-deployment.md)。

如需有關更新服務部署控制器的詳細資訊，請參閱[更新 Amazon ECS 服務參數](update-service-parameters.md)。

## 程序
<a name="migrate-code-deploy-to-ecs-rolling-procedure"></a>

1. 開啟主控台，網址為 [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)。

1. 在**叢集**頁面上，選擇叢集。

   「叢集詳細資訊」頁面隨即顯示。

1. 從**服務**索引標籤中選擇服務。

   服務詳細資訊頁面隨即顯示。

1. 在橫幅中，選擇**遷移**。

   **更新部署組態**頁面隨即顯示。

1. 展開**部署選項**區段，然後指定下列參數。

   1. 在**部署控制器類型**欄位中選擇 **ECS**。

   1. 在**部署策略**欄位中選擇**滾動更新**。

   1. 針對 **Min running tasks** (執行中任務下限)，輸入部署期間必須維持在 `RUNNING` 狀態的服務任務數量下限，它是所需任務數量的百分比 (無條件進位到最接近的整數)。如需詳細資訊，請參閱[部署組態](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service_definition_parameters.html#sd-deploymentconfiguration)。

   1. 針對 **Max running tasks** (執行中任務上限)，輸入部署期間允許的處於 `RUNNING` 或 `PENDING` 狀態的服務任務數目上限，它是所需任務數量的百分比 (無條件捨去到最接近的整數)。

1. 展開**負載平衡**區段，然後設定下列項目：

   1. 在**角色**欄位中，選擇您在先決條件中建立的具有藍/綠部署許可的角色。

      如需詳細資訊，請參閱[Amazon ECS 藍/綠部署中 Lambda 函式所需的許可](blue-green-permissions.md)。

   1. 在**接聽程式**欄位中，從 CodeDeploy 藍/綠部署中選擇生產接聽程式。

   1. 在**目標群組**欄位中，從 CodeDeploy 藍/綠部署中選擇生產目標群組。

1. 選擇**更新**。

## 後續步驟
<a name="migrate-code-deploy-to-ecs-rolling-next-steps"></a>

您必須更新服務，變更才會生效。如需詳細資訊，請參閱[更新 Amazon ECS 服務](update-service-console-v2.md)。

# 更新 Amazon ECS 部署策略
<a name="migrate-deployment-strategies"></a>

Amazon ECS 支援多種部署策略來更新服務。您可以根據應用程式需求在這些策略之間遷移。本主題說明如何在滾動部署與藍/綠部署之間遷移。

## 了解 Amazon ECS 部署策略
<a name="deployment-strategies-overview"></a>

在部署策略之間進行遷移之前，務必了解每種策略的運作方式及其主要差異：

**滾動部署**  
在滾動部署中，Amazon ECS 會將應用程式目前執行的版本取代為新版本。服務排程器會使用運作狀態百分比下限與運作狀態百分比上限參數來決定部署策略。  
滾動部署更容易設定，但對部署程序與流量路由的控制較少。

**藍/綠部署**  
在藍/綠部署中，Amazon ECS 會與現有版本 (藍色) 一起建立新的服務版本 (綠色)。這可讓您在將生產流量路由至新版本之前先驗證新版本。  
藍/綠部署提供對部署程序的更多控制，包括流量轉移、測試與復原功能。

## 最佳實務
<a name="migration-best-practices"></a>

在部署策略之間進行遷移時，請遵循下列最佳實務：
+ **在非生產環境中測試**：一律先在非生產環境中測試更新，然後再將變更套用至生產服務。
+ **制定復原計畫**：制定復原計畫，以防更新無法如預期般運作。
+ **在轉移期間進行監控**：在遷移期間與遷移之後密切監控服務，確保其繼續正常運作。
+ **更新文件**：更新部署文件以反映新的部署策略。
+ **考量流量影響**：了解更新可能如何影響服務的流量，並據此進行規劃。

# 將部署策略從滾動更新更新為 Amazon ECS 藍/綠部署
<a name="update-rolling-to-bluegreen"></a>

若要在生產環境中實作服務變更之前，先進行變更與測試，可以從滾動更新部署遷移至 Amazon ECS 藍/綠部署。

## 先決條件
<a name="update-rolling-to-bluegreen-prerequisites"></a>

在將服務從滾動部署遷移至藍/綠部署之前，請確定您已滿足下列條件：
+  等待任何目前的部署完成。
+ 現有 Amazon ECS 服務使用滾動部署策略。
+ 如果您有多個服務修訂版正在處理流量，Amazon ECS 會嘗試在遷移期間將流量合併為單一修訂版。如果失敗，您可能需要在遷移之前手動更新服務，以使用單一修訂版。
+ 設定相應的許可。
  + 如需有關 Elastic Load Balancing 許可的資訊，請參閱[負載平衡器的 Amazon ECS 基礎結構 IAM 角色](AmazonECSInfrastructureRolePolicyForLoadBalancers.md)。
  + 如需有關 Lambda 許可的資訊，請參閱 [Amazon ECS 藍/綠部署中 Lambda 函式所需的許可](blue-green-permissions.md)。
+ 根據組態，您需要執行下列其中一項動作：
  + 如果服務使用 Elastic Load Balancing，請使用新的 `advancedConfiguration` 更新服務並啟動滾動部署。
  + 如果服務使用 Service Connect，請更新服務並啟動滾動部署。
  + 如果服務同時使用 Elastic Load Balancing 與 Service Connect，請執行上述兩個步驟 (可以使用單一 UpdateService 請求)。
  + 如果服務不使用上述任何一項，則無需執行其他操作。
+ Amazon ECS 藍/綠部署要求服務使用下列其中一項功能。設定相應的資源。
  + Application Load Balancer – 如需詳細資訊，請參閱[藍/綠、線性和金絲雀部署的 Application Load Balancer 資源](alb-resources-for-blue-green.md)。
  + Network Load Balancer – 如需詳細資訊，請參閱[Amazon ECS 藍/綠、線性和 Canary 部署的 Network Load Balancer 資源](nlb-resources-for-blue-green.md)。
  + Service Connect – 如需詳細資訊，請參閱[Amazon ECS 藍色/綠色、線性和 Canary 部署的 Service Connect 資源](service-connect-blue-green.md)。

## 程序
<a name="update-rolling-to-bluegreen-procedure"></a>

1. 在 [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2) 開啟 Amazon ECS 主控台。

1. 在導覽窗格中，選擇**叢集**。

1. 在**叢集**頁面上，選擇包含要遷移之服務的叢集。

   「叢集詳細資訊」頁面隨即顯示。

1. 在**叢集詳細資訊**頁面中，選擇**服務**索引標籤。

1. 選擇服務，然後選擇**更新**。

   「更新服務」頁面隨即顯示

1. 展開**部署選項**區段，然後執行下列動作：

1. 在**部署策略**欄位中選擇**藍/綠部署**。

1. 進行藍/綠部署設定：

   1. 在**封裝時間**欄位中，輸入在藍色修訂版終止之前，藍色與綠色服務修訂版將同時執行的分鐘數。

      這為驗證與測試提供了時間。

   1. (選用) 設定要在部署的特定階段執行的 Lambda 函式。在**部署 lifecycle hook** 下，為下列階段設定 Lambda 函式：
      + **向上擴展前**：在向上擴展綠色服務修訂版之前執行
      + **向上擴展後**：在向上擴展綠色服務修訂版之後執行
      + **測試流量轉移**：在測試流量路由至綠色服務修訂版期間執行
      + **測試流量轉移後**：在測試流量路由至綠色服務修訂版之後執行
      + **生產流量轉移**：在生產流量路由至綠色服務修訂版期間執行
      + **生產流量轉移後**：在生產流量路由至綠色服務修訂版之後執行

      若要新增 lifecycle hook：

      1. 選擇**新增**。

      1. 在 **Lambda 函式**欄位中，輸入函式名稱或 ARN。

      1. 在**角色**欄位中，選擇具有調用 Lambda 函式之許可的 IAM 角色。

      1. 在**生命週期階段**欄位中，選取 Lambda 函式應執行的階段。

      1. 選用：在**勾點詳細資訊**欄位中，輸入鍵值對，為勾點提供其他資訊。

1. 進行負載平衡器設定：

   1. 在**負載平衡**下，確認服務已設定為使用負載平衡器。

   1. 在**目標群組**欄位中，選擇用於生產 (藍色) 環境的主要目標群組。

   1. 在**替代目標群組**欄位中，選擇用於測試 (綠色) 環境的目標群組。

   1. 在**生產接聽程式規則**欄位中，選擇用於路由生產流量的接聽程式規則。

   1. 選用：在**測試接聽程式規則**欄位中，選擇用於將測試流量路由至綠色環境的接聽程式規則。

   1. 在**角色**欄位中，選擇允許 Amazon ECS 管理負載平衡器的 IAM 角色。

1. 檢閱組態變更，然後選擇**更新**。

## 後續步驟
<a name="update-rolling-to-bluegreen-next-steps"></a>
+ 更新服務以開始部署。如需詳細資訊，請參閱[更新 Amazon ECS 服務](update-service-console-v2.md)。
+ 監控部署程序，確保其遵循藍/綠模式：
  + 綠色服務修訂版已建立並向上擴展
  + 測試流量會路由至綠色修訂版 (若已設定)
  + 生產流量會轉移至綠色修訂版
  + 封裝時間過期後，藍色修訂版會終止

# 將部署策略從 Amazon ECS 藍/綠部署更新為滾動更新
<a name="update-bluegreen-to-rolling"></a>

您可以將藍/綠部署遷移至滾動更新部署。

遷移至滾動部署時，請記住下列考量事項：
+ **流量處理**：使用滾動部署時，新任務會在通過運作狀態檢查後立即開始接收流量。與藍/綠部署不同，此方式沒有單獨的測試階段。
+ **資源效率**：滾動部署通常會使用比藍/綠部署更少的資源，因為這種部署會逐漸取代任務，而不是建立完整的重複環境。
+ **復原複雜性**：與藍/綠部署相比，滾動部署使復原操作更為複雜。如果需要復原，必須使用先前的任務定義啟動新的部署。
+ **部署速度**：滾動部署可能需要比藍/綠部署更長的時間才能完成，特別是對於具有許多任務的服務。
+ **負載平衡器組態**：現有的負載平衡器組態仍然適用於滾動部署，但流量轉移行為會有所不同。

## 先決條件
<a name="update-bluegreen-to-rolling-prerequisites"></a>

在將服務從藍/綠部署遷移至滾動部署之前，請確定您已滿足下列條件：
+ 現有 Amazon ECS 服務使用藍/綠部署策略
+ 服務沒有正在進行的部署 (等待任何目前部署完成)
+ 清楚了解服務在滾動部署下的行為方式

**注意**  
如果服務有正在進行的部署，則無法將其遷移至滾動部署。等待任何目前的部署完成，然後再繼續操作。

## 遷移程序
<a name="update-bluegreen-to-rolling-procedure"></a>

請遵循下列步驟，將 Amazon ECS 服務從藍/綠部署遷移至滾動部署：

1. 在 [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2) 開啟 Amazon ECS 主控台。

1. 在導覽窗格中，選擇**叢集**。

1. 在**叢集**頁面上，選擇包含要遷移之服務的叢集。

1. 在**叢集詳細資訊**頁面中，選擇**服務**索引標籤。

1. 選取要遷移的服務，然後選擇**更新**。

1. 在**更新服務**頁面上，導覽至**部署選項**區段，並視需要展開該區段。

1. 在**部署策略**欄位中選擇**滾動更新**。

1. 對滾動部署進行設定：

   1. 在**運作狀態百分比下限**欄位中，輸入部署期間必須保持在 `RUNNING` 狀態的任務百分比下限。此值指定為服務所需任務數量的百分比。

   1. 在**百分比上限**欄位中，輸入部署期間允許處於 `RUNNING` 或 `PENDING` 狀態的任務百分比上限。此值指定為服務所需任務數量的百分比。

1. 選用：在**部署失敗偵測**下，設定 Amazon ECS 如何偵測與處理部署失敗：

   1. 若要啟用部署斷路器，請選擇**使用部署斷路器**。

   1. 若要自動復原失敗的部署，請選擇**失敗時復原**。

1. 檢閱組態變更，然後選擇**更新**以儲存變更，並將服務遷移至滾動部署。

Amazon ECS 會更新服務組態，以使用滾動部署策略。下次更新服務時，將會使用滾動部署程序。

**注意**  
從藍/綠部署遷移至滾動部署時，Amazon ECS 會透過下列方式處理轉移：  
識別正在處理流量的目前作用中服務修訂版。
維護現有的負載平衡器組態，但變更新部署的處理方式。
為未來的滾動部署準備服務。

## 後續步驟
<a name="update-bluegreen-to-rolling-next-steps"></a>
+ 更新服務以開始部署。如需詳細資訊，請參閱[更新 Amazon ECS 服務](update-service-console-v2.md)。

# 對 Amazon ECS 部署策略更新進行疑難排解
<a name="troubleshooting-deployment-controller-migration"></a>

本節提供遷移部署策略時可能遇到的常見問題的解決方案。

## 多個服務修訂版或任務集
<a name="troubleshooting-multiple-task-sets"></a>

下列問題與部署時存在多個服務修訂版有關。

更新 ECS 部署控制器時存在多項任務集  
*錯誤訊息*：`Updating the deployment controller is not supported when there are multiple tasksets in the service. Please ensure your service has only one taskset and try again.`  
*解決方案*：嘗試變更具有多個作用中任務集之服務的部署控制器類型時，會發生此錯誤。若要為 `CODE_DEPLOY` 或 `EXTERNAL` 部署控制器解決此問題，請執行下列動作：  

1. 檢查目前的任務集：

   ```
   aws ecs describe-services --cluster your-cluster-name --services your-service-name --query "services[0].taskSets"
   ```

1. 等待任何進行中的部署完成。

1. 強制執行新部署以清理任務集：

   ```
   aws ecs update-service --cluster your-cluster-name --service your-service-name --force-new-deployment
   ```

1. 如有必要，手動刪除額外的任務集：

   ```
   aws ecs delete-task-set --cluster your-cluster-name --service your-service-name --task-set task-set-id
   ```

1. 在僅剩一個任務集後，重試更新部署控制器。
如需詳細資訊，請參閱[Amazon ECS 服務部署控制器與策略](ecs_service-options.md)。

更新 `ECS` 部署控制器時缺少主要任務集  
*錯誤訊息*：`Updating the deployment controller requires a primary taskset in the service. Please ensure your service has a primary taskset and try again.`  
*解決方案*：嘗試變更沒有主要任務集之服務的部署控制器類型時，會發生此錯誤。若要解決此問題：  

1. 驗證服務狀態與任務集。如果服務中存在任務集，則應標記為 `ACTIVE`。

   ```
   aws ecs describe-services --cluster your-cluster-name --services your-service-name --query "services[0].taskSets[*].[status,id]
   ```

   如果沒有處於 `ACTIVE` 狀態的任務集，請遷移部署。如需詳細資訊，請參閱[遷移方法](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/migrate-codedeploy-to-ecs-bluegreen.html#migration-paths)。

1. 如果服務沒有執行中的任務，請更新服務，以部署至少一項任務：

   ```
   aws ecs update-service-primary-task-set --cluster your-cluster-name --service your-service-name --primary-task-set your-taskset-id
   ```

   這會將服務中 (先前為 `ACTIVE` 的) 任務集標記為 `PRIMARY` 狀態。

1. 等待任務達到穩定的執行狀態。您可以使用下列命令檢查狀態：

   ```
   aws ecs describe-services --cluster your-cluster-name --services your-service-name --query "services[0].deployments"
   ```

1. 在服務的主要任務集存在執行中任務後，重試更新部署控制器。
如需詳細資訊，請參閱[Amazon ECS 服務部署控制器與策略](ecs_service-options.md)。

## 部署失敗偵測類型與部署控制器不相符
<a name="troubleshooting-failure-detection"></a>

下列問題和部署失敗偵測類型與部署控制器不相符有關。

使用非 ECS 控制器的部署斷路器  
*錯誤訊息*：`Deployment circuit breaker feature is only supported with ECS deployment controller. Update to ECS deployment controller and try again.`  
*解決方案*：嘗試在未使用 `ECS` 部署控制器的服務上啟用部署斷路器功能時，會發生此錯誤。部署斷路器僅與 `ECS` 部署控制器相容。  

1. 檢視服務目前的部署控制器：

   ```
   aws ecs describe-services --cluster your-cluster-name --services your-service-name --query "services[0].deploymentController"
   ```

1. 更新服務以使用 `ECS` 部署控制器：

   ```
   aws ecs update-service --cluster your-cluster-name --service your-service-name --deployment-controller type=ECS
   ```

1. 服務使用 `ECS` 部署控制器後，啟用部署斷路器：

   ```
   aws ecs update-service --cluster your-cluster-name --service your-service-name --deployment-configuration "deploymentCircuitBreaker={enable=true,rollback=true}"
   ```
如需詳細資訊，請參閱[Amazon ECS 部署斷路器如何偵測失敗](deployment-circuit-breaker.md)。

使用非 ECS 控制器的警示型復原  
*錯誤訊息*：`Alarm based rollback feature is only supported with ECS deployment controller. Update to ECS deployment controller and try again.`  
*解決方案*：嘗試在未使用 `ECS` 部署控制器的服務上設定警示型復原時，會發生此錯誤。警示型復原功能僅與 `ECS` 部署控制器相容。  

1. 檢視服務目前的部署控制器：

   ```
   aws ecs describe-services --cluster your-cluster-name --services your-service-name --query "services[0].deploymentController"
   ```

1. 更新服務以使用 `ECS` 部署控制器：

   ```
   aws ecs update-service --cluster your-cluster-name --service your-service-name --deployment-controller type=ECS
   ```

1. 服務使用 `ECS` 部署控制器後，設定警示型復原：

   ```
   aws ecs update-service --cluster your-cluster-name --services your-service-name --deployment-configuration "alarms={alarmNames=[your-alarm-name],enable=true,rollback=true}"
   ```
如需詳細資訊，請參閱[CloudWatch 警示如何偵測 Amazon ECS 部署失敗](deployment-alarm-failure.md)。

## Service Connect 與部署控制器不相符
<a name="troubleshooting-service-connect-mismatch"></a>

下列問題和 Service Connect 與部署控制器不相符有關。

使用 Service Connect 的 `EXTERNAL` 控制器  
*錯誤訊息*：`The EXTERNAL deployment controller type is not supported for services using Service Connect.`  
*解決方案*：嘗試搭配已啟用 Service Connect 的服務使用 `EXTERNAL` 部署控制器時，會發生此錯誤。`EXTERNAL` 控制器與 Service Connect 不相容。  

1. 檢查服務是否啟用了 Service Connect：

   ```
   aws ecs describe-services --cluster your-cluster-name --services your-service-name --query "services[0].serviceConnectConfiguration"
   ```

1. 如果需要使用 `EXTERNAL` 部署控制器，請更新服務以停用 Service Connect：

   ```
   aws ecs update-service --cluster your-cluster-name --service your-service-name --service-connect-configuration "{}"
   ```

1. 或者，如果必須使用 Service Connect，請改用 `ECS` 部署控制器：

   ```
   aws ecs update-service --cluster your-cluster-name --service your-service-name --deployment-controller type=ECS
   ```
如需詳細資訊，請參閱[Amazon ECS 服務部署控制器與策略](ecs_service-options.md)。

使用非 ECS 控制器的 Service Connect  
*錯誤訊息*：`Service Connect feature is only supported with ECS (rolling update) deployment controller. Update to ECS deployment controller and try again.`  
*解決方案*：嘗試在未使用 `ECS` 部署控制器的服務上啟用 Service Connect 時，會發生此錯誤。Service Connect 功能僅與 `ECS` 部署控制器相容。  

1. 檢視服務目前的部署控制器：

   ```
   aws ecs describe-services --cluster your-cluster-name --services your-service-name --query "services[0].deploymentController"
   ```

1. 更新服務以使用 ECS 部署控制器：

   ```
   aws ecs update-service --cluster your-cluster-name --service your-service-name --deployment-controller type=ECS
   ```

1. 服務使用 ECS 部署控制器後，即可啟用 Service Connect：

   ```
   aws ecs update-service --cluster your-cluster-name --service your-service-name --service-connect-configuration "enabled=true,namespace=your-namespace"
   ```
如需詳細資訊，請參閱[Amazon ECS 服務部署控制器與策略](ecs_service-options.md)。

## 控制器類型與排程策略不相符
<a name="troubleshooting-controller-type-scheduling"></a>

下列問題和控制器類型與排程策略不相符有關。

使用 `DAEMON` 排程策略的 `CODE_DEPLOY` 控制器  
*錯誤訊息*：`The CODE_DEPLOY deployment controller type is not supported for services using the DAEMON scheduling strategy.`  
*解決方案*：嘗試搭配使用了 `DAEMON` 排程策略的服務使用 CODE\$1DEPLOY 部署控制器時，會發生此錯誤。`CODE_DEPLOY` 控制器僅與 `REPLICA` 排程策略相容。  

1. 檢查服務目前的排程策略：

   ```
   aws ecs describe-services --cluster your-cluster-name --services your-service-name --query "services[0].schedulingStrategy"
   ```

1. 如果需要使用藍/綠部署，請將服務變更為使用 `REPLICA` 排程策略：

   ```
   aws ecs update-service --cluster your-cluster-name --service your-service-name --scheduling-strategy REPLICA
   ```

1. 或者，如果必須使用 `DAEMON` 排程策略，請改用 `ECS` 部署控制器：

   ```
   aws ecs update-service --cluster your-cluster-name --service your-service-name --deployment-controller type=ECS
   ```
如需詳細資訊，請參閱[Amazon ECS 服務部署控制器與策略](ecs_service-options.md)。

使用 DAEMON 排程策略的 EXTERNAL 控制器  
*錯誤訊息*：`The EXTERNAL deployment controller type is not supported for services using the DAEMON scheduling strategy.`  
*解決方案*：嘗試搭配使用了 DAEMON 排程策略的 ECS 服務使用 EXTERNAL 部署控制器時，會發生此錯誤。EXTERNAL 控制器僅與 REPLICA 排程策略相容。  

1. 檢查服務目前的排程策略：

   ```
   aws ecs describe-services --cluster your-cluster-name --services your-service-name --query "services[0].schedulingStrategy"
   ```

1. 如果需要使用 `EXTERNAL` 部署控制器，請將服務變更為使用 `REPLICA` 排程策略：

   ```
   aws ecs update-service --cluster your-cluster-name --service your-service-name --scheduling-strategy REPLICA
   ```

1. 或者，如果必須使用 `DAEMON` 排程策略，請改用 `ECS` 部署控制器：

   ```
   aws ecs update-service --cluster your-cluster-name --service your-service-name --deployment-controller type=ECS
   ```
如需詳細資訊，請參閱[Amazon ECS 服務部署控制器與策略](ecs_service-options.md)。

使用外部啟動類型的服務登錄檔  
*錯誤訊息*：`Service registries are not supported for external launch type.`  
*解決方案*：嘗試為使用 `EXTERNAL` 啟動類型的服務設定服務探索 (服務登錄檔) 時，會發生此錯誤。服務探索與 `EXTERNAL` 啟動類型不相容。  

1. 檢查服務目前的啟動類型：

   ```
   aws ecs describe-services --cluster your-cluster-name --services your-service-name --query "services[0].launchType"
   ```

1. 如果需要使用服務探索，請將服務變更為使用 `EC2` 或 `FARGATE` 啟動類型：

   ```
   aws ecs update-service --cluster your-cluster-name --service your-service-name --launch-type FARGATE
   ```

1. 或者，如果必須使用 `EXTERNAL` 啟動類型，請移除服務登錄檔組態：

   ```
   aws ecs update-service --cluster your-cluster-name --service your-service-name --service-registries "[]"
   ```
如需詳細資訊，請參閱[Amazon ECS 服務部署控制器與策略](ecs_service-options.md)。

## 還原部署控制器更新
<a name="troubleshooting-revert"></a>

如果決定要返回先前的部署控制器，可以執行下列其中一項動作：
+ 如果您使用 CloudFormation，則可以使用先前的範本來建立新的堆疊。如需詳細資訊，請參閱 *CloudFormation User Guide* 中的 [Create a stack from](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-create-stack.html)。
+ 如果您使用 Amazon ECS 主控台或 AWS CLI，則可以更新服務。如需詳細資訊，請參閱[更新 Amazon ECS 服務](update-service-console-v2.md)。

  如果您使用 update-service 命令，請使用 `--deployment-controller` 選項，並將其設定為先前的部署控制器。

# 使用 Amazon ECS 服務部署檢視服務歷史記錄
<a name="service-deployment"></a>

服務部署可用於全面檢視部署。服務部署提供下列服務相關資訊：
+ 目前部署的工作負載組態 (來源服務修訂版)
+ 正在部署的工作負載組態 (目標服務修訂版)
+ 部署狀態
+ 斷路器偵測到的失敗任務數量
+ 處於警示狀態的 CloudWatch 警示
+ 服務部署開始與完成的時間
+ 已發生之復原的詳細資訊

如需有關服務部署屬性的資訊，請參閱 [Amazon ECS 服務部署中包含的屬性](service-deployment-property.md)。

服務部署是唯讀的，每個都有唯一的 ID。

服務部署分為三個階段：


| 階段 | 定義 | 相關狀態 | 
| --- | --- | --- | 
| 待定 | 已建立服務部署，但尚未啟動 | 待定 | 
| 持續性 | 服務部署正在進行中 |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/AmazonECS/latest/developerguide/service-deployment.html)  | 
| 已完成  | 服務部署已完成 (成功或失敗) |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/AmazonECS/latest/developerguide/service-deployment.html)  | 

您可以使用服務部署來了解服務的生命週期，並判斷是否需要採取任何動作。例如，如果發生復原，您可能需要調查服務部署並查看服務事件。

您可以使用主控台、API 與 AWS CLI，檢視 2024 年 10 月 25 日當天或之後建立之部署的最近 90 天歷史記錄。

您可以停止尚未完成的部署。如需詳細資訊，請參閱[停止 Amazon ECS 服務部署](stop-service-deployment.md)。

## 服務部署生命週期
<a name="service-deployments-lifecycle"></a>

發生下列任何動作時，Amazon ECS 會自動建立新的服務部署：
+ 使用者建立服務。
+ 使用者更新服務並使用「強制執行新部署」選項。
+ 使用者更新一個或多個需要部署的服務屬性。

在部署進行期間，Amazon ECS 會更新下列服務部署屬性，以反映服務部署進度：
+ 狀態
+ 執行中任務數量

  服務修訂版中指示的執行中任務數量，可能不等於實際的執行中任務數量。此數字代表部署完成時的執行中任務數量。例如，若您啟動獨立於服務部署的任務，則這些任務不會包含在服務修訂版的執行中任務計數中。
+ 斷路器失敗偵測：
  + 啟動失敗的任務數量
+ CloudWatch 警示失敗偵測
  + 處於作用中狀態的警示
+ 復原資訊：
  + 啟動時間
  + 復原原因
  + 用於復原之服務修訂版的 ARN
+ 狀態原因

當您刪除服務時，Amazon ECS 會刪除服務部署。

## 服務部署狀態
<a name="service-deployments-states"></a>

服務部署從 `PENDING` 狀態啟動。

下圖展示了在 `PENDING` 狀態之後可能發生的服務部署狀態：`IN_PROGRESS`、`ROLLBACK_REQUESTED`、`SUCCESSFUL`、`STOP_REQUESTED`、`ROLLBACK_IN_PROGRESSS`、`ROLLBACK_FAILED`、`ROLLBACK_SUCCESSFUL` 與 `STOPPED`。

![\[在 IN_PROGRESS 狀態之後可能發生的服務部署狀態包括：STOP_REQUESTED、SUCCESSFUL 與 ROLLBACK_IN_PROGRESS。\]](http://docs.aws.amazon.com/zh_tw/AmazonECS/latest/developerguide/images/service-deployment-states.png)


下列資訊提供有關服務部署狀態的詳細資訊：
+ `PENDING`：已建立服務部署，但尚未啟動。

  該狀態可以移至 `IN_PROGRESS`、`ROLLBACK_REQUESTED`、`STOP_REQUESTED` 或 `STOPPED`。
+ `IN_PROGRESS`：服務部署正在進行中。

  該狀態可以移至 `SUCCESSFUL`、`STOP_REQUESTED`、`ROLLBACK_REQUESTED`、`ROLLBACK_IN_PROGRESS` 與 `STOPPED`。
+ `STOP_REQUESTED`：發生下列任何情況時，服務部署狀態會移至 `STOP_REQUESTED`：
  + 使用者啟動新的服務部署。
  + 失敗偵測機制 (斷路器或警示類型) 未使用復原選項，且服務未達到 `SUCCESSFUL` 狀態。

  該狀態會移至 `STOPPED`。
+  `ROLLBACK_REQUESTED`：當使用者透過主控台、API 或 CLI 請求復原時，服務部署狀態會移至 `ROLLBACK_REQUESTED`。

  該狀態可以移至 `SUCCESSFUL`、`ROLLBACK_IN_PROGRESS` 與 `STOPPED`。
+ `SUCCESSFUL`：當服務部署成功完成後，服務部署狀態會移至 `SUCCESSFUL`。
+  `ROLLBACK_IN_PROGRESS`：當失敗偵測機制 (斷路器或警示型) 使用了復原選項且服務失敗時，服務部署狀態會移至 `ROLLBACK_IN_PROGRESS`。

   該狀態可以移至 `ROLLBACK_SUCCESSFUL` 或 `ROLLBACK_FAILED`。

# Amazon ECS 服務部署中包含的屬性
<a name="service-deployment-property"></a>

服務部署中包含下列屬性。


| 屬性 | Description | 
| --- | --- | 
|  服務部署 ARN  |  服務部署的 ARN。  | 
| 服務 ARN |  此服務部署所屬服務的 ARN。  | 
|  叢集 ARN  |  託管服務的叢集 ARN。  | 
| 服務部署建立時間 | 服務部署建立的時間。 | 
| 服務部署開始時間 | 服務部署開始的時間。 | 
|  服務部署完成時間  | 服務部署完成的時間。 | 
| 服務部署停止時間 | 服務部署停止的時間。 | 
| 服務部署更新時間 | 服務部署上次更新的時間。 | 
| 來源服務修訂版 |  目前執行中的服務修訂版。 如需有關包含的屬性的資訊，請參閱 [Amazon ECS 服務修訂版中包含的屬性](service-revision-property.md)。  | 
| Deployment configuration (部署組態) | 部署參數，包括斷路器組態、用於判斷的警示。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/AmazonECS/latest/developerguide/service-deployment-property.html) | 
| 目標服務修訂版 | 要部署的服務修訂版。部署成功完成後，目標服務修訂版即為執行中的服務修訂版。 | 
| 服務部署狀態 | 服務部署狀態。有效值為 PENDING、SUCCESSFUL、STOPPED、STOP\$1REQUESTED、STOP\$1IN\$1PROGRESS、IN\$1PROGRESS、ROLLBACK\$1IN\$1PROGRESS、ROLLBACK\$1SUCCESSFUL 與 ROLLBACK\$1FAILED。 | 
| 服務部署狀態資訊 | 有關服務部署為何處於目前狀態的資訊。例如，斷路器偵測到失敗。 | 
|  復原資訊 | 部署失敗時，服務部署使用的復原選項。 | 
| 服務部署斷路器選項 | 用於判斷服務部署失敗的斷路器。 | 
| 服務部署的 CloudWatch 警示 | 用於判斷服務部署失敗的 CloudWatch 警示。 | 

# 檢視 Amazon ECS 服務部署所需的許可
<a name="service-deployment-permissions"></a>

 當您遵循授予最低權限的最佳實務時，必須新增額外許可，才能在主控台中檢視服務部署。

您需要存取下列動作：
+ ListServiceDeployments
+ DescribeServiceDeployments
+ DescribeServiceRevisions

您需要存取下列資源：
+ 服務
+ 服務部署
+ 服務修訂版

下列範例政策包含必要的許可，並將動作限制於指定的服務。

將 `account`、`cluster-name` 與 `service-name` 取代為實際值。

------
#### [ JSON ]

****  

```
{
"Statement": [
    {
        "Effect": "Allow",
        "Action": [
            "ecs:ListServiceDeployments",
            "ecs:DescribeServiceDeployments",
            "ecs:DescribeServiceRevisions"
        ],
        "Resource": [
            "arn:aws:ecs:us-east-1:123456789012:service/cluster-name/service-name",
            "arn:aws:ecs:us-east-1:123456789012:service-deployment/cluster-name/service-name/*",
            "arn:aws:ecs:us-east-1:123456789012:service-revision/cluster-name/service-name/*"
            ]
        }
   ]
}
```

------

# 檢視 Amazon ECS 服務部署
<a name="view-service-deployment"></a>

您可以檢視 2024 年 10 月 25 日當天或之後建立的部署的最近 90 天歷史記錄。服務部署可以處於下列任何狀態：
+ 進行中 
+ 待定
+ 已完成

 您可以使用此資訊來判斷是否需要更新服務的部署方式或服務修訂版。如需有關包含的屬性的資訊，請參閱 [Amazon ECS 服務部署中包含的屬性](service-deployment-property.md)。

開始之前，請先設定檢視服務部署所需的許可。如需詳細資訊，請參閱[檢視 Amazon ECS 服務部署所需的許可](service-deployment-permissions.md)。

------
#### [ Amazon ECS Console ]

1. 開啟主控台，網址為 [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)。

1. 在**叢集**頁面上，選擇叢集。

1. 在「叢集詳細資訊」頁面上的**服務**區段中，選擇所需服務。

   服務詳細資訊頁面隨即顯示。

1. 在服務詳細資訊頁面上，選擇**部署**。

1. 選擇要檢視的服務部署。    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/AmazonECS/latest/developerguide/view-service-deployment.html)

   服務部署詳細資訊頁面隨即顯示。

1. (選用) 比較服務修訂版以檢視差異。

   在**服務修訂版**下，選擇**比較修訂版**，然後選取 2 個要比較的修訂版。

   服務修訂版會並排顯示，並反白顯示差異。

------
#### [ AWS CLI ]

1. 執行 `list-service-deployments` 以擷取服務部署 ARN。

   將變數取代為您的值。

   ```
   aws ecs list-service-deployments --cluster cluster-name --service service-name
   ```

   記下要檢視之部署的 serviceDeploymentArn。

   ```
   {
       "serviceDeployments": [
           {
               "serviceDeploymentArn": "arn:aws:ecs:us-west-2:123456789012:service-deployment/example/sd-example/NCWGC2ZR-taawPAYrIaU5",
               "serviceArn": "arn:aws:ecs:us-west-2:123456789012:service/example/sd-example",
               "clusterArn": "arn:aws:ecs:us-west-2:123456789012:cluster/example",
               "targetServiceRevisionArn": "arn:aws:ecs:us-west-2:123456789012:service-revision/example/sd-example/4980306466373577095",
               "status": "SUCCESSFUL"
           }
       ]
   }
   ```

1. 執行 `describe-service-deployments`。使用從 `list-service-deployments` 傳回的 `serviceDeploymentArn`。

   將變數取代為您的值。

   ```
   aws ecs describe-service-deployments --service-deployment-arns arn:aws:ecs:region:123456789012:service-deployment/cluster-name/service-name/NCWGC2ZR-taawPAYrIaU5
   ```

------

## 後續步驟
<a name="view-service-deployment-next-step"></a>

您可以在部署中檢視服務修訂版的詳細資訊。如需詳細資訊，請參閱[檢視 Amazon ECS 服務修訂版詳細資訊](view-service-revision.md)

# Amazon ECS 服務修訂版
<a name="service-revision"></a>

服務修訂版包含 Amazon ECS 嘗試部署的工作負載組態記錄。每當您建立或部署服務時，Amazon ECS 就會自動建立並擷取您嘗試在服務修訂版中部署的組態。

 服務修訂版為唯讀且具有唯一識別碼。如需有關包含的屬性的資訊，請參閱 [Amazon ECS 服務修訂版中包含的屬性](service-revision-property.md)。

 服務修訂版提供下列優勢：
+ 在服務部署期間，您可以將目前部署的服務修訂版 (來源) 與正在部署的服務修訂版 (目標) 進行比較。
+ 當您為服務部署使用復原選項時，Amazon ECS 會自動將服務部署復原至上次成功部署的服務修訂版。
+ 服務修訂版會將工作負載組態的記錄集中在一個資源中。

## 服務修訂版生命週期
<a name="service-revisions-lifecycle"></a>

當您建立服務，或更新啟動部署的服務屬性時，Amazon ECS 會自動建立新的服務修訂版。

 Amazon ECS 不會為復原操作建立新的服務修訂版。Amazon ECS 會使用上次成功的服務修訂版進行復原。

服務修訂版不可變。

您刪除服務時，Amazon ECS 會刪除服務修訂版。

您可以使用主控台、API 與 CLI，檢視 2024 年 10 月 25 日當天或之後建立的服務修訂版。

# Amazon ECS 服務修訂版中包含的屬性
<a name="service-revision-property"></a>

服務修訂版中包含下列屬性。


| 資源 | Description | 
| --- | --- | 
|  服務 ARN  |  用於識別用戶端的 ARN。  | 
|  叢集 ARN  |  託管服務的叢集 ARN。  | 
|  任務定義 ARN  |  用於服務任務的任務定義 ARN。  | 
|  服務登錄檔  |  用於服務探索之服務登錄檔的詳細資訊。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/AmazonECS/latest/developerguide/service-revision-property.html)  | 
| 容量提供者 |  容量提供者策略詳細資訊。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/AmazonECS/latest/developerguide/service-revision-property.html)  | 
| 容器映像 |  有關容器映像的詳細資訊。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/AmazonECS/latest/developerguide/service-revision-property.html)  | 
| 聯網 |  服務的網路組態。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/AmazonECS/latest/developerguide/service-revision-property.html)  | 
| 啟動類型 | 用於服務的運算選項。 | 
| Fargate 特定屬性 |  使用 Fargate 時，此為有關 Fargate 版本的資訊。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/AmazonECS/latest/developerguide/service-revision-property.html)  | 
| 部署時設定的 Amazon EBS 磁碟區 |  在任務定義中指定為啟動時設定的磁碟區的組態。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/AmazonECS/latest/developerguide/service-revision-property.html)  | 
|  Service Connect |  Service Connect 組態。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/AmazonECS/latest/developerguide/service-revision-property.html)  | 
| 服務負載平衡器 |  路由服務流量的負載平衡器。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/AmazonECS/latest/developerguide/service-revision-property.html)  | 
| 執行時期監控 | 指示是否開啟執行時期監控。 | 
| Creation (建立) 日期 |  服務修訂版建立的日期。  | 
| VPC Lattice |  服務修訂版的 VPC Lattice 組態。  | 

# 檢視 Amazon ECS 服務修訂版詳細資訊
<a name="view-service-revision"></a>

您可以檢視 2024 年 10 月 25 日當天或之後建立的下列服務修訂版類型的相關資訊：
+ 來源 – 目前部署的工作負載組態
+ 目標 – 正在部署的工作負載組態

------
#### [ Amazon ECS Console ]

1. 開啟主控台，網址為 [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)。

1. 在**叢集**頁面上，選擇叢集。

1. 在「叢集詳細資訊」頁面上的**服務**區段中，選擇所需服務。

   服務詳細資訊頁面隨即顯示。

1. 在服務詳細資訊頁面上，選擇**部署**。

1. 選擇要檢視的服務修訂版。    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/AmazonECS/latest/developerguide/view-service-revision.html)

------
#### [ AWS CLI ]

1. 執行 `describe-service-deployments` 以擷取服務修訂版 ARN。

   將變數取代為您的值。

   ```
   aws ecs describe-service-deployments --service-deployment-arns arn:aws:ecs:region:account-id:service/cluster-name/service-name/NCWGC2ZR-taawPAYrIaU5
   ```

   記下 `sourceServiceRevisions` 或 `targetServiceRevisions` 的 `arn`。

   ```
   {
       "serviceDeployments": [
           {
               "serviceDeploymentArn": "arn:aws:ecs:us-west-2:123456789012:service-deployment/example/sd-example/NCWGC2ZR-taawPAYrIaU5",
               "serviceArn": "arn:aws:ecs:us-west-2:123456789012:service/example/sd-example",
               "clusterArn": "arn:aws:ecs:us-west-2:123456789012:cluster/example",
               "updatedAt": "2024-09-10T16:49:35.572000+00:00",
               "sourceServiceRevision": {
                   "arn": "arn:aws:ecs:us-west-2:123456789012:service-revision/example/sd-example/4980306466373578954",
                   "requestedTaskCount": 0,
                   "runningTaskCount": 0,
                   "pendingTaskCount": 0
               },
               "targetServiceRevision": {
                   "arn": "arn:aws:ecs:us-west-2:123456789012:service-revision/example/sd-example/4980306466373577095",
                   "requestedTaskCount": 0,
                   "runningTaskCount": 0,
                   "pendingTaskCount": 0
               },
               "status": "IN_PROGRESS",
               "deploymentConfiguration": {
                   "deploymentCircuitBreaker": {
                       "enable": false,
                       "rollback": false
                   },
                   "maximumPercent": 200,
                   "minimumHealthyPercent": 100
               }
           }
       ],
       "failures": []
   }
   ```

1. 執行 `describe-service-revisions`。使用從 `describe-service-deployments` 傳回的 `arn`。

   將變數取代為您的值。

   ```
   aws ecs describe-service-revisions --service-revision-arns arn:aws:ecs:region:123456789012:service-revision/cluster-name/service-name/4980306466373577095
   ```

------

# 在可用區域之間平衡 Amazon ECS 服務
<a name="service-rebalancing"></a>

自 2025 年 9 月 5 日起，Amazon ECS 會為所有符合功能資格的服務啟用可用區域重新平衡。當可用區域分佈是第一項任務置放策略，或者沒有置放策略時，服務即符合資格。

為了協助讓應用程式達到高可用性，建議您將多任務服務設定為在多個可用區域中執行。對於將第一個置放策略指定為可用區域分散的服務， AWS 會盡最大努力跨可用區域平均分配服務任務。

但是，在某個可用區域中執行的任務數目，有時可能會與其他可用區域中執行的任務數目不相同，例如在可用區域中斷之後。若要解決此任務不平衡情況，您可以啟用可用區域重新平衡功能。

Amazon ECS 會利用可用區域重新平衡功能，持續監控您每項服務的可用區域之間的任務分佈。當 Amazon ECS 偵測到任務分佈不均勻時，便會自動採取行動來重新平衡可用區域之間的工作負載。這包括在任務最少的可用區域中啟動新任務，以及終止超載的可用區域中的任務。

這種重新分佈可確保不會有單一可用區域成為失敗點，有助於維持容器化應用程式的整體可用性。有了自動重新平衡程序，就不需手動介入操作，且能加快事件後復原的時間。

下列是可用區域重新平衡程序的概觀：

1. Amazon ECS 會在服務達到穩定狀態後開始監控服務，並查看每個可用區域中的執行中任務數量。

1. 當 Amazon ECS 偵測到每個可用區域中執行的任務數量不平衡時，會執行下列操作：
   + 傳送指示可用區域重新平衡即將啟動的服務事件。
   + 在執行中任務數量最少的可用區域中啟動任務
   + 在執行中任務數量最多的可用區域中停止任務。
   + 排程器會等待新啟動的任務變為 `HEALTHY` 與 `RUNNING`，然後在過度擴展的可用區域中停止任務。
   + 傳送具有可用區域重新平衡結果的服務事件。

## Amazon ECS 如何偵測任務分佈不均問題
<a name="service-rebalancing-imbalance"></a>

Amazon ECS 透過將服務所需的任務計數除以設定的可用區域數量，來判斷每個可用區域中的執行中任務數量是否不平衡。如果所需任務計數不能整除，Amazon ECS 會將剩餘的任務均勻分佈到設定的可用區域。每個可用區域必須有至少一項任務。

例如，假設 Amazon ECS 服務所需計數為針對兩個可用區域設定的兩項任務。在這種情況下，所需任務計數可以整除。平衡分佈應為每個可用區域一項任務。如果可用區域 1 中有兩項任務，可用區域 2 中有零項任務，則 Amazon ECS 將透過在可用區域 2 中啟動任務，然後在可用區域 1 中停止任務來啟動重新平衡。

現在，假設 Amazon ECS 服務所需計數為針對兩個可用區域設定的三項任務。在這種情況下，所需任務計數不能整除。平衡分佈應為可用區域 1 中一項任務，可用區域 2 中兩項任務，因為每個可用區域有至少一項任務，且剩餘的任務會置放在可用區域 2 中。

假設 Amazon ECS 服務所需計數為針對三個可用區域設定的五項任務。在這種情況下，所需任務計數不能整除。平衡分佈應為可用區域 1 中一項任務，可用區域 2 與 3 中各兩項任務。在確保每個可用區域都有一項任務後，剩餘的兩項任務會均勻分佈到各可用區域。

## 設定可用區域重新平衡的考量
<a name="service-rebalancing-configurations"></a>

若要設定可用區域重新平衡，請考量下列事項：
+ 可用區域重新平衡支援 Fargate 與 EC2 容量提供者，並在 Amazon ECS 受管執行個體上受支援。對於 Fargate，Amazon ECS 會自動在可用區域中重新分佈任務，以維持平衡。對於 EC2 容量提供者，Amazon ECS 會盡力重新平衡現有容器執行個體間的任務，同時遵循您定義的置放策略與限制條件。但是，在重新平衡程序中，Amazon ECS 無法在使用率不足的可用區域中啟動新的執行個體，這會將重新平衡限制在現有容器執行個體的範圍內。
+ 可用區域重新平衡適用於下列組態：
  + 使用 `Replica` 策略的服務
  + 將可用區域分佈指定為第一項任務置放策略，或未指定置放策略的服務。
+ 您無法搭配符合下列任一條件的服務使用可用區域重新平衡：
  + 使用 `Daemon` 策略
  + 使用 `EXTERNAL` 啟動類型 (ECS Anywhere)
  + 對 `maximumPercent` 值使用 100%
  + 使用 Classic Load Balancer
  + 使用 `attribute:ecs.availability-zone` 作為任務置放限制條件

## 使用可用區域重新平衡的置放策略與置放限制條件
<a name="service-rebalancing-placement-constraints"></a>

置放策略決定了 Amazon ECS 如何選取容器執行個體與可用區域來終止任務置放。任務置放限制條件是判斷是否允許任務在特定容器執行個體上執行的規則。

對於 EC2，您可以搭配可用區域重新平衡使用置放策略與置放限制條件。不過，為了讓可用區域重新平衡正常運作，可用區域分佈置放策略必須是第一項指定的策略。

可用區域重新平衡與各種置放策略組合相容。例如，您可以建立一項策略，先將任務均勻分佈到各個可用區域，然後根據每個可用區域內的記憶體對任務進行分箱封裝。在這種情況下，可用區域重新平衡能夠運作，因為會先指定可用區域分佈策略。

請務必注意，如果置放策略陣列中的第一項策略不是可用區域分佈元件，可用區域重新平衡將無法運作。此需求可確保任務分佈的主要重點是維持可用區域之間的平衡，這對高可用性至關重要。

如需有關任務置放策略與限制條件的詳細資訊，請參閱 [Amazon ECS 如何在容器執行個體上置放任務](task-placement.md)。

使用 Fargate 的任務不支援任務置放策略與限制條件。Fargate 將盡力將任務分散至可存取的可用區域。如果容量提供者同時包含 Fargate 和 Fargate Spot，則每個容量提供者的分散行為均各自獨立。

下列範例策略會將任務均勻分佈到各個可用區域，然後根據每個可用區域內的記憶體對任務進行分箱封裝。由於 `spread` 策略是第一項策略，可用區域重新平衡與該服務相容。

```
"placementStrategy": [
    {
        "field": "attribute:ecs.availability-zone",
        "type": "spread"
    },
    {
        "field": "memory",
        "type": "binpack"
    }
]
```

## 開啟可用區域重新平衡功能
<a name="service-rebalancing-use"></a>

您需要為新服務與現有服務啟用可用區域重新平衡功能。

您可以使用主控台 AWS CLI、APIs 和 來啟用和停用可用區域重新平衡 CloudFormation。

`AvailabilityZoneRebalancing` 的預設行為在建立與更新請求之間有所不同：
+ 對於建立服務請求，如果未為 `AvailabilityZoneRebalancing` 指定值，Amazon ECS 會將該值預設為 `ENABLED`。
+ 對於更新服務請求，如果未為 `AvailabilityZoneRebalancing` 指定值，Amazon ECS 預設會使用現有服務的 `AvailabilityZoneRebalancing` 值。如果服務從未設定 `AvailabilityZoneRebalancing` 值，Amazon ECS 會將其視為 `DISABLED`。


| 服務類型 | API | 主控台 | CLI | 
| --- | --- | --- | --- | 
| 現有 | [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html) |  [更新 Amazon ECS 服務](update-service-console-v2.md)  | [update-service](https://docs.aws.amazon.com/cli/latest/reference/ecs/update-service.html) | 
| 新增 | [CreateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateService.html) |  [建立 Amazon ECS 滾動更新部署](create-service-console-v2.md)  | [create-service](https://docs.aws.amazon.com/cli/latest/reference/ecs/create-service.html) | 

下列範例說明如何在建立新服務時啟用服務重新平衡：

```
aws ecs create-service \
    --cluster my-cluster \
    --service-name my-service \
    --task-definition my-task-definition:1 \
    --desired-count 6 \
    --availability-zone-rebalancing ENABLED
```

# 追蹤 Amazon ECS 可用區域重新平衡
<a name="track-service-rebalancing"></a>

您可以透過主控台或呼叫 `describe-services` 來驗證服務是否已啟用可用區域重新平衡。下列範例可用來查看 CLI 的狀態。

回應將為 `ENABLED` 或 `DISABLED`。

```
aws ecs describe-services \
    --services service-name \
    --cluster cluster-name \
    --query services[0].availabilityZoneRebalancing
```

## 服務事件
<a name="service-info-events"></a>

Amazon ECS 會傳送服務動作事件，協助您了解可用區域重新平衡生命週期。


| 事件 | 案例 | Type | 進一步了解 | 
| --- | --- | --- | --- | 
| SERVICE\$1REBALANCING\$1STARTED | Amazon ECS 啟動可用區域重新平衡操作 | INFO | [service (*service-name*) is not AZ balanced with *number-tasks* tasks in *Availability Zone 1*, *number-tasks* in *Availability Zone 2*, and *number-tasks* in *Availability Zone 3*. AZ Rebalancing in progress.](service-rebalancing-event-messages-list.md#service-rebalancing-started) | 
| SERVICE\$1REBALANCING\$1COMPLETED | 可用區域重新平衡操作完成 |  INFO | [service (*service-name*) is AZ balanced with *number-tasks* tasks in *Availability Zone 1*, *number-tasks* tasks in *Availability Zone 2*, and *number-tasks* tasks in *Availability Zone 3*.](service-rebalancing-event-messages-list.md#service-rebalancing-completed) | 
| TASKS\$1STARTED | Amazon ECS 在可用區域重新平衡操作中成功啟動任務 | INFO | [*service-name* has started *number-tasks* tasks in *Availability Zone* to AZ Rebalance: *task-ids*.](service-rebalancing-event-messages-list.md#service-rebalancing-tasks-started) | 
| TASKS\$1STOPPED | Amazon ECS 在可用區域重新平衡操作中成功停止任務 | INFO | [*service-name* has stopped *number-tasks* running tasks in *Availability Zone* due to AZ rebalancing: *task-id*.](service-rebalancing-event-messages-list.md#service-rebalancing-tasks-stopped) | 
| SERVICE\$1TASK\$1PLACEMENT\$1FAILURE | Amazon ECS 在可用區域重新平衡操作中啟動任務失敗 | ERROR | 對於 EC2，請參閱[service (*service-name*) is unable to place a task in *Availability Zone* because no container instance met all of its requirements.](service-rebalancing-event-messages-list.md#service-rebalancing-placement-failure-instance) 對於 Fargate，請參閱[service (*service-name*) is unable to place a task in *Availability Zone*.](service-rebalancing-event-messages-list.md#service-rebalancing-placement-failure) | 
| TASKSET\$1SCALE\$1IN\$1FAILURE\$1BY\$1TASK\$1PROTECTION | 由於任務保護正在使用中，因此會封鎖可用區域重新平衡操作。 | INFO | [service (*service-name*) was unable to AZ Rebalance because *task-set-name* was unable to scale in due to *reason*.](service-rebalancing-event-messages-list.md#service-rebalancing-task-protection-failure) | 
| SERVICE\$1REBALANCING\$1STOPPED | 可用區域重新平衡操作停止。Amazon ECS 會傳送提供詳細資訊的額外事件。 | INFO | [service (*service-name*) stopped AZ Rebalancing.](service-rebalancing-event-messages-list.md#service-rebalancing-operation-stopped) | 

## 任務狀態變更事件
<a name="task-state-change-events"></a>

Amazon ECS 會針對在重新平衡程序中啟動的每項任務傳送任務狀態變更事件 (`START`)。

Amazon ECS 會針對在重新平衡程序中停止的每項任務傳送任務狀態變更事件 (`STOPPED`)。原因設定為 `Availability-zone rebalancing initiated by (deployment ecs-svc/deployment-id)`。

如需有關事件的詳細資訊，請參閱 [Amazon ECS 任務狀態變更事件](ecs_task_events.md)。

## 對服務重新平衡進行疑難排解
<a name="service-rebalancing-troubleshooting"></a>

如果您在重新平衡服務時遇到問題，請考慮下列疑難排解步驟：

重新平衡未啟動  
請驗證：  
+ 服務已啟用服務重新平衡
+ 服務使用支援組態 (請參閱[設定可用區域重新平衡的考量](#service-rebalancing-configurations))
+ 服務已達到穩定狀態

重新平衡期間任務置放失敗  
如果您看到 `SERVICE_TASK_PLACEMENT_FAILURE` 事件：  
+ 對於 EC2：檢查目標可用區域中是否有可用的容器執行個體
+ 對於 Fargate：檢查是否存在資源限制條件或服務配額限制了任務置放
+ 檢閱任務置放限制條件，確保它們不會阻止適當的任務分佈

重新平衡意外停止  
如果您看到 `SERVICE_REBALANCING_STOPPED` 事件：  
+ 檢查是否存在可能封鎖操作的任務保護
+ 尋找可能中斷重新平衡的並行服務部署
+ 檢閱服務事件，以取得有關為何停止重新平衡的其他資訊

## 服務重新平衡的最佳實務
<a name="service-rebalancing-best-practices"></a>

遵循以下最佳實務以充分利用服務重新平衡：
+ **監控重新平衡操作** – 設定 CloudWatch 警示來監控與重新平衡相關的服務事件，以便快速識別任何問題。
+ **考慮效能影響** – 重新平衡操作可能會暫時增加資源使用量，因為新任務會在舊任務停止之前啟動。
+ **策略性使用任務保護** – 如果有關鍵任務不應在重新平衡期間終止，請考慮使用任務保護。
+ **制定 EC2 容量計畫** – 對於 EC2，請確保所有可用區域中擁有足夠的容器執行個體，能夠支援重新平衡有效運作。
+ **測試重新平衡行為** – 在生產環境中依賴重新平衡之前，請在非生產環境中測試服務在重新平衡操作期間的行為。

# 使用負載平衡分佈 Amazon ECS 服務流量
<a name="service-load-balancing"></a>

服務可以選擇性地設定為使用 Elastic Load Balancing，以將流量均勻分佈到服務中的各項任務。

**注意**  
使用任務集時，集中的所有任務必須全部設定為使用 Elastic Load Balancing 或不使用 Elastic Load Balancing。

在 上託管的 Amazon ECS 服務 AWS Fargate 支援 Application Load Balancer、Network Load Balancer 和 Gateway Load Balancer。使用下表了解要使用的負載平衡器類型。


| 負載平衡器類型 | 在下列情況下使用 | 
| --- | --- | 
|  Application Load Balancer  | 路由 HTTP/HTTPS (或第 7 層) 流量。Application Load Balancer 提供數種功能，非常適合與 Amazon ECS 服務搭配使用： [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/AmazonECS/latest/developerguide/service-load-balancing.html) | 
| Network Load Balancer | 路由 TCP 或 UDP (或第 4 層) 流量。 | 
| Gateway Load Balancer | 路由 TCP 或 UDP (或第 4 層) 流量。 使用虛擬應用裝置，如防火牆、入侵偵測與預防系統，以及深層封包檢查系統。 | 

除非服務需要僅 Network Load Balancer 或 Gateway Load Balancer 才能使用的功能，否則建議您針對 Amazon ECS 服務使用 Application Load Balancer，以利用這些最新功能。如需有關 Elastic Load Balancing 和負載平衡器類型區別的詳細資訊，請參閱 [Elastic Load Balancing 使用者指南](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/)。

使用負載平衡器時，您只需按實際用量付費。如需詳細資訊，請參閱 [Elastic Load Balancing 定價](https://aws.amazon.com/elasticloadbalancing/pricing/)。

# 針對 Amazon ECS 最佳化負載平衡器運作狀態檢查參數
<a name="load-balancer-healthcheck"></a>

負載平衡器僅會將請求路由至其所屬可用區域中運作狀態良好的目標。每個目標都會註冊至目標群組。負載平衡器會使用目標群組的運作狀態檢查設定，檢查每個目標的運作狀態。目標註冊後，必須通過一次運作狀態檢查，才會視為運作狀態良好。Amazon ECS 會監控負載平衡器。負載平衡器會定期向 Amazon ECS 容器傳送運作狀態檢查。Amazon ECS 代理程式會監控並等待負載平衡器報告容器運作狀態。代理程式必須執行此操作，才會將容器視為運作狀態良好。

有兩個 Elastic Load Balancing 運作狀態檢查參數會影響部署速度：
+ 運作狀態檢查間隔：決定個別容器各運作狀態檢查之間的約略間隔時間 (以秒為單位)。依預設，負載平衡器會每 30 秒檢查一次。

  此參數名稱為：
  + Elastic Load Balancing API 中的 `HealthCheckIntervalSeconds`
  + Amazon EC2 主控台上的**時間間隔**
+ 運作良好閾值計數：決定在將運作狀態不良的容器視為運作狀態良好之前，所需的連續成功的運作狀態檢查次數。依預設，負載平衡器需要五次通過運作狀態檢查，才會報告目標容器運作狀態良好。

  此參數名稱為：
  + Elastic Load Balancing API 中的 `HealthyThresholdCount`
  + Amazon EC2 主控台上的**運作良好閾值**

**重要提示：**對於新註冊的目標，無論運作良好閾值計數設定為何，只需一次成功的運作狀態檢查，即可將目標視為運作狀態良好。運作良好閾值計數僅適用於目標從運作狀態不良轉換回運作狀態良好的情況。

使用預設設定時，如果目標運作狀態不良，然後復原，則判定容器運作狀態的總時間為 2 分鐘 30 秒 (`30 seconds * 5 = 150 seconds`)。

如果服務在 10 秒內啟動並穩定下來，您可以加速運作狀態檢查程序。若要加速程序，請縮短運作狀態檢查間隔並減少運作良好閾值計數。
+ `HealthCheckIntervalSeconds` (Elastic Load Balancing API 名稱) 或**間隔** (Amazon EC2 主控台名稱)：5
+ `HealthyThresholdCount` (Elastic Load Balancing API 名稱) 或**運作良好閾值** (Amazon EC2 主控台名稱)：2

使用此設定後，運作狀態檢查程序僅需 10 秒，而預設值需要 2 分鐘 30 秒。

如需有關 Elastic Load Balancing 運作狀態檢查參數的詳細資訊，請參閱 *Elastic Load Balancing User Guide* 中的 [Health checks for your target groups](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/target-group-health-checks.html)。

# 針對 Amazon ECS 最佳化負載平衡器連接耗盡參數
<a name="load-balancer-connection-draining"></a>

為了實現最佳化，用戶端會維持與容器服務的持續連線。這允許該用戶端的後續請求重複使用現有連線。若要停止流向容器的流量，需要通知負載平衡器。負載平衡器會定期檢查用戶端是否關閉持續連線。Amazon ECS 會監控負載平衡器，並等待負載平衡器報告持續連線已關閉 (目標處於 `UNUSED` 狀態)。

負載平衡器等待將目標移至 `UNUSED` 狀態的時間即為取消註冊延遲。您可以設定下列負載平衡器參數來加速部署。
+ `deregistration_delay.timeout_seconds`：300 (預設值)

如果服務回應時間低於 1 秒，請將參數設定為下列值，使負載平衡器僅等待 5 秒就中斷用戶端與後端服務之間的連線：
+ `deregistration_delay.timeout_seconds`：5 

**注意**  
如果服務涉及長效請求(例如慢速檔案上傳或串流連線)，請勿將此值設定為 5 秒。

## SIGTERM 回應能力
<a name="sigterm"></a>

Amazon ECS 會先傳送停止訊號給任務，以通知應用程式需要完成並關閉。此訊號可以使用 STOPSIGNAL 指令在您的容器映像中定義，並預設為 SIGTERM。然後，Amazon ECS 會傳送 SIGKILL 訊息。當應用程式忽略 SIGTERM 時，Amazon ECS 服務必須等待一段時間才能傳送 SIGKILL 訊號來終止程序。

Amazon ECS 等待傳送 SIGKILL 訊息的時間取決於下列 Amazon ECS 代理程式選項：
+ `ECS_CONTAINER_STOP_TIMEOUT`：30 (預設值)

  如需有關容器代理程式參數的詳細資訊，請參閱 GitHub 上的 [Amazon ECS Container Agent](https://github.com/aws/amazon-ecs-agent/blob/master/README.md)。

若要縮短等待期間，請將 Amazon ECS 代理程式參數設定為下列值：
+ `ECS_CONTAINER_STOP_TIMEOUT`: 2

  如果應用程式需要超過 1 秒的時間，請將該值乘以 2，並將該數字用作設定值。

在這種情況下，Amazon ECS 會等待 2 秒讓容器關閉，如果應用程式沒有停止，Amazon ECS 會傳送 SIGKILL 訊息。

您也可以修改應用程式程式碼來捕捉 SIGTERM 訊號並對其作出反應。以下是 JavaScript 中的範例：

```
process.on('SIGTERM', function() { 
  server.close(); 
})
```

此程式碼會導致 HTTP 伺服器停止監聽任何新請求、完成回應所有傳輸中請求，然後 Node.js 程序會終止，因為事件迴圈沒有執行任何動作。有鑑於此，如果程序僅需 500 毫秒就能完成其傳輸中請求，它就會提早終止，而無需等待停止逾時並收到 SIGKILL。

# 搭配 Amazon ECS 使用 Application Load Balancer
<a name="alb"></a>

Application Load Balancer 在應用程式層 (HTTP/HTTPS) 進行路由決策、支援以路徑為基礎的路由，並可將請求路由到您叢集中每個容器執行個體的一或多個連接埠。Application Load Balancer 支援動態主機連接埠映射。例如，如果您的任務的容器定義指定 NGINX 容器連接埠使用連接埠 80，主機連接埠使用連接埠 0，則會從容器執行個體的暫時性連接埠範圍 (例如最新的 Amazon ECS 最佳化 AMI 為 32768 至 61000) 動態選擇主機連接埠。任務啟動時，NGINX 容器會以執行個體 ID 與連接埠組合向 Application Load Balancer 註冊，而流量將分佈到與該容器對應的執行個體 ID 與連接埠。這個動態映射可讓您在同一個容器執行個體中的單一服務擁有多項任務。如需詳細資訊，請參閱 [Application Load Balancer 使用者指南](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/)。

如需有關設定參數以加速部署的最佳實務資訊，請參閱：
+ [針對 Amazon ECS 最佳化負載平衡器運作狀態檢查參數](load-balancer-healthcheck.md)
+ [針對 Amazon ECS 最佳化負載平衡器連接耗盡參數](load-balancer-connection-draining.md)

搭配 Amazon ECS 使用 Application Load Balancer 時，請考量下列事項：
+ Amazon ECS 需要服務連結 IAM 角色，該角色會在任務建立和停止時提供向您的負載平衡器註冊與取消註冊目標所需的許可。如需詳細資訊，請參閱[使用 Amazon ECS 的服務連結角色](using-service-linked-roles.md)。
+ 對於純 IPv6 組態的服務，必須將 Application Load Balancer 的目標群組 IP 位址類型設定為 `dualstack` 或 `dualstack-without-public-ipv4`。
+ 對於任務使用 `awsvpc` 網路模式的服務，當您為服務建立目標群組時，必須選擇 `ip` 做為目標類型，而非 `instance`。這是由於採用 `awsvpc` 網路模式的任務是與彈性網路介面相關聯，而非與 Amazon EC2 執行個體相關聯。
+ 如果服務需要存取多個負載平衡連接埠 (例如適用於 HTTP/HTTPS 服務的連接埠 80 與連接埠 443)，您可以設定兩個接聽程式。一個接聽程式負責將請求轉送至服務的 HTTPS，另一個接聽程式負責將 HTTP 請求重新導向至適當的 HTTPS 連接埠。如需詳細資訊，請參閱 *Application Load Balancer 使用者指南*中的[為您的 Application Load Balancer 建立接聽程式](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-listener.html)。
+ 負載平衡器子網路組態必須包含您容器執行個體所在的所有可用區域。
+ 建立服務之後，負載平衡器組態無法從 AWS 管理主控台變更。您可以使用 AWS Copilot AWS CloudFormation AWS CLI 或 SDK，僅修改`ECS`滾動部署控制器的負載平衡器組態，而不是 AWS CodeDeploy 藍/綠或外部。當您新增、更新或移除負載平衡器組態時，Amazon ECS 會使用更新後的 Elastic Load Balancing 組態啟動新的部署。這會導致任務向負載平衡器註冊和取消註冊。我們建議您在更新 Elastic Load Balancing 組態之前，先在測試環境中驗證。如需有關如何修改組態的資訊，請參閱 *Amazon Elastic Container Service API 參考* 中的 [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)。
+ 如果服務任務未能通過負載平衡器運作狀態檢查條件，則會停止並重新啟動任務。此程序會持續到您的服務達到所需的執行任務數量為止。
+ 如果您遇上啟用負載平衡器功能之服務的問題，請參閱[對 Amazon ECS 中的服務負載平衡器進行疑難排解](troubleshoot-service-load-balancers.md)。
+ 使用 `instance` 目標類型時，任務與負載平衡器必須位於同一 VPC 中。使用 `ip` 目標類型時，支援跨 VPC 連線。
+ 針對每項服務使用唯一目標群組。

  針對多項服務使用同一目標群組可能會在服務部署期間導致問題。
+ 您必須指定與 Application Load Balancer 相關聯的目標群組。

如需有關如何建立 Application Load Balancer 的資訊，請參閱 *Application Load Balancers* 中的 [Create an Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-application-load-balancer.html)

# 搭配 Amazon ECS 使用 Network Load Balancer
<a name="nlb"></a>

Network Load Balancer 會在傳輸層做出路由決策 (TCP/SSL)。每秒可以處理數百萬個請求。在負載平衡器收到連線後，會使用流程雜湊路由演算法從目標群組選取預設規則的目標。負載平衡器會嘗試開啟接聽程式設定中指定之連接埠上所選目標的 TCP 連線。負載平衡器會轉送此請求，且不會修改標頭。Network Load Balancer 支援動態主機連接埠映射。例如，如果您的任務的容器定義指定 NGINX 容器連接埠使用連接埠 80，主機連接埠使用連接埠 0，則會從容器執行個體的暫時性連接埠範圍 (例如最新的 Amazon ECS 最佳化 AMI 為 32768 至 61000) 動態選擇主機連接埠。啟動此任務時，NGINX 容器會以執行個體 ID 和連接埠組合在 Network Load Balancer 註冊，而流量將分散到與該容器對應的執行個體 ID 和連接埠。這個動態映射可讓您在同一個容器執行個體中的單一服務擁有多項任務。如需詳細資訊，請參閱 [Network Load Balancer 使用者指南](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/)。

如需有關設定參數以加速部署的最佳實務資訊，請參閱：
+ [針對 Amazon ECS 最佳化負載平衡器運作狀態檢查參數](load-balancer-healthcheck.md)
+ [針對 Amazon ECS 最佳化負載平衡器連接耗盡參數](load-balancer-connection-draining.md)

搭配 Amazon ECS 使用 Network Load Balancer 時，請考量下列事項：
+ Amazon ECS 需要服務連結 IAM 角色，該角色會在任務建立和停止時提供向您的負載平衡器註冊與取消註冊目標所需的許可。如需詳細資訊，請參閱[使用 Amazon ECS 的服務連結角色](using-service-linked-roles.md)。
+ 一項服務最多只能連接五個目標群組。
+ 對於純 IPv6 組態的服務，必須將 Network Load Balancer 的目標群組 IP 位址類型設定為 `dualstack`。
+ 對於任務使用 `awsvpc` 網路模式的服務，當您為服務建立目標群組時，必須選擇 `ip` 做為目標類型，而非 `instance`。這是由於採用 `awsvpc` 網路模式的任務是與彈性網絡介面相關聯，而非與 Amazon EC2 執行個體相關聯。
+ 負載平衡器子網路組態必須包含您容器執行個體所在的所有可用區域。
+ 建立服務之後，負載平衡器組態無法從 AWS 管理主控台變更。您可以使用 AWS Copilot AWS CloudFormation AWS CLI 或 SDK，僅修改`ECS`滾動部署控制器的負載平衡器組態，而不是 AWS CodeDeploy 藍/綠或外部。當您新增、更新或移除負載平衡器組態時，Amazon ECS 會使用更新後的 Elastic Load Balancing 組態啟動新的部署。這會導致任務向負載平衡器註冊和取消註冊。我們建議您在更新 Elastic Load Balancing 組態之前，先在測試環境中驗證。如需有關如何修改組態的資訊，請參閱 *Amazon Elastic Container Service API 參考* 中的 [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)。
+ 如果服務任務未能通過負載平衡器運作狀態檢查條件，則會停止並重新啟動任務。此程序會持續到您的服務達到所需的執行任務數量為止。
+ 當您使用以 IP 位址作為目標設定的且關閉了用戶端 IP 保留功能的 Gateway Load Balancer 時，請求會視為來自 Gateway Load Balancer 私有 IP 位址。也就是說，當您在目標安全群組中允許傳入請求與運作狀態檢查時，Gateway Load Balancer 後端的服務就會立即對外開放。
+ 對於 Fargate 任務，必須使用平台版本 `1.4.0` (Linux) 或 `1.0.0` (Windows)。
+ 如果您遇上啟用負載平衡器功能之服務的問題，請參閱[對 Amazon ECS 中的服務負載平衡器進行疑難排解](troubleshoot-service-load-balancers.md)。
+ 使用 `instance` 目標類型時，任務與負載平衡器必須位於同一 VPC 中。使用 `ip` 目標類型時，支援跨 VPC 連線。
+ Network Load Balancer 用戶端 IP 位址保留與 Fargate 目標相容。
+ 針對每項服務使用唯一目標群組。

  針對多項服務使用同一目標群組可能會在服務部署期間導致問題。
+ 您必須指定與 Network Load Balancer 相關聯的目標群組。

如需有關如何建立 Network Load Balancer 的資訊，請參閱 *Network Load Balancers* 中的 [Create a Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/create-network-load-balancer.html)

**重要**  
若服務的任務定義採用 Fargate 所需的 `awsvpc` 網路模式，則您必須選擇 `ip` 作為目標類型，而不是選擇 `instance`。因為採用 `awsvpc` 網路模式的任務是與彈性網路界面相關聯，而非與 Amazon EC2 執行個體相關聯。  
如果執行個體類型如下：C1、CC1、CC2、CG1、CG2、CR1、G1、G2、HI1、HS1、M1、M2、M3 和 T1，就不能以執行個體 ID 來登錄執行個體。您可以使用 IP 地址來登錄這些執行個體。

# 搭配 Amazon ECS 使用 Gateway Load Balancer
<a name="glb"></a>

Gateway Load Balancer 在開放系統互相連線 (OSI) 模型的第三層，網路層運作。它會接聽所有連接埠的全部 IP 封包，並轉送流量至接聽程式規則中指定的目標群組。它使用 5 元組 (針對 TCP/UDP 流) 或 3 元組 (針對非 TCP/UDP 流) 維護特定目標應用裝置的流量黏性。例如，如果您的任務的容器定義指定 NGINX 容器連接埠使用連接埠 80，主機連接埠使用連接埠 0，則會從容器執行個體的暫時性連接埠範圍 (例如最新的 Amazon ECS 最佳化 AMI 為 32768 至 61000) 動態選擇主機連接埠。任務啟動時，NGINX 容器會以執行個體 ID 與連接埠組合向 Gateway Load Balancer 註冊，而流量將分佈到與該容器對應的執行個體 ID 與連接埠。這個動態映射可讓您在同一個容器執行個體中的單一服務擁有多項任務。如需詳細資訊，請參閱 *Gateway Load Balancers* 中的 [What is a Gateway Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/gateway/introduction.html)。

如需有關設定參數以加速部署的最佳實務資訊，請參閱：
+ [針對 Amazon ECS 最佳化負載平衡器運作狀態檢查參數](load-balancer-healthcheck.md)
+ [針對 Amazon ECS 最佳化負載平衡器連接耗盡參數](load-balancer-connection-draining.md)

搭配 Amazon ECS 使用 Gateway Load Balancer 時，請考量下列事項：
+ Amazon ECS 需要服務連結 IAM 角色，該角色會在任務建立和停止時提供向您的負載平衡器註冊與取消註冊目標所需的許可。如需詳細資訊，請參閱[使用 Amazon ECS 的服務連結角色](using-service-linked-roles.md)。
+ 對於純 IPv6 組態的服務，必須將 Gateway Load Balancer 的目標群組 IP 位址類型設定為 `dualstack`。
+ 對於任務使用 `awsvpc` 以外網路模式的服務，不支援 Gateway Load Balancer。
+ 負載平衡器子網路組態必須包含您容器執行個體所在的所有可用區域。
+ 建立服務之後，負載平衡器組態無法從 AWS 管理主控台變更。您可以使用 AWS Copilot AWS CloudFormation AWS CLI 或 SDK，僅修改`ECS`滾動部署控制器的負載平衡器組態，而不是 AWS CodeDeploy 藍/綠或外部。當您新增、更新或移除負載平衡器組態時，Amazon ECS 會使用更新後的 Elastic Load Balancing 組態啟動新的部署。這會導致任務向負載平衡器註冊和取消註冊。我們建議您在更新 Elastic Load Balancing 組態之前，先在測試環境中驗證。如需有關如何修改組態的資訊，請參閱 *Amazon Elastic Container Service API 參考* 中的 [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)。
+ 如果服務任務未能通過負載平衡器運作狀態檢查條件，則會停止並重新啟動任務。此程序會持續到您的服務達到所需的執行任務數量為止。
+ 當您使用以 IP 位址作為目標設定的 Gateway Load Balancer 時，請求會視為來自 Gateway Load Balancer 私有 IP 位址。也就是說，當您在目標安全群組中允許傳入請求與運作狀態檢查時，Gateway Load Balancer 後端的服務就會立即對外開放。
+ 對於 Fargate 任務，必須使用平台版本 `1.4.0` (Linux) 或 `1.0.0` (Windows)。
+ 如果您遇上啟用負載平衡器功能之服務的問題，請參閱[對 Amazon ECS 中的服務負載平衡器進行疑難排解](troubleshoot-service-load-balancers.md)。
+ 使用 `instance` 目標類型時，任務與負載平衡器必須位於同一 VPC 中。使用 `ip` 目標類型時，支援跨 VPC 連線。
+ 針對每項服務使用唯一目標群組。

  針對多項服務使用同一目標群組可能會在服務部署期間導致問題。
+ 您必須指定與 Gateway Load Balancer 相關聯的目標群組。

如需有關如何建立 Gateway Load Balancer 的資訊，請參閱 *Gateway Load Balancers* 中的 [Getting started with Gateway Load Balancers](https://docs.aws.amazon.com/elasticloadbalancing/latest/gateway/getting-started.html)

**重要**  
若服務的任務定義採用 Fargate 所需的 `awsvpc` 網路模式，則您必須選擇 `ip` 作為目標類型，而不是選擇 `instance`。因為採用 `awsvpc` 網路模式的任務是與彈性網路界面相關聯，而非與 Amazon EC2 執行個體相關聯。  
如果執行個體類型如下：C1、CC1、CC2、CG1、CG2、CR1、G1、G2、HI1、HS1、M1、M2、M3 和 T1，就不能以執行個體 ID 來登錄執行個體。您可以使用 IP 地址來登錄這些執行個體。

# 透過 Amazon ECS 服務註冊多個目標群組
<a name="register-multiple-targetgroups"></a>

當您在服務定義中指定多個目標群組時，您的 Amazon ECS 服務可以為來自多個負載平衡器的流量提供服務，以及公開多個負載平衡的連接埠。

若要建立指定多個目標群組的服務，您必須使用 Amazon ECS API AWS CLI、 SDK 或 CloudFormation 範本建立服務。建立服務之後，您可以使用 AWS 管理主控台檢視該服務以及向其註冊的目標群組。您必須使用 `[UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)` 來修改現有服務的負載平衡器組態。

您可以使用以下格式在服務定義中指定多個目標群組。如需服務定義的完整語法，請參閱[服務定義範本](sd-template.md)。

```
"loadBalancers":[
   {  
      "targetGroupArn":"arn:aws:elasticloadbalancing:region:123456789012:targetgroup/target_group_name_1/1234567890123456",
      "containerName":"container_name",
      "containerPort":container_port
   },
   {  
      "targetGroupArn":"arn:aws:elasticloadbalancing:region:123456789012:targetgroup/target_group_name_2/6543210987654321",
      "containerName":"container_name",
      "containerPort":container_port
   }
]
```

## 考量事項
<a name="multiple-targetgroups-considerations"></a>

當您在服務定義中指定多個目標群組時，應該考慮下列事項。
+ 對於使用 Application Load Balancer 或 Network Load Balancer 的服務，您無法連接超過五個目標群組到一個服務。
+ 只有在下列情況下支援在服務定義中指定多個目標群組：
  + 服務必須使用 Application Load Balancer 或 Network Load Balancer。
  + 服務必須使用 (`ECS`) 部署控制器類型。這可以是 Amazon ECS 原生/藍綠部署或滾動更新部署。
+ 若服務同時包含使用 Fargate 和 EC2 啟動類型的任務，則該服務支援指定多個目標群組。
+ 當建立指定多個目標群組的服務時，必須建立 Amazon ECS 服務連結角色。透過省略 API 請求中的 `role` 參數，或 CloudFormation中的 `Role` 屬性來建立角色。如需詳細資訊，請參閱[使用 Amazon ECS 的服務連結角色](using-service-linked-roles.md)。

## 範例服務定義
<a name="multiple-targetgroups-examples"></a>

以下是在服務定義中指定多個目標群組的一些使用案例範例。如需服務定義的完整語法，請參閱[服務定義範本](sd-template.md)。

### 具有可供內部與外部流量使用的個別負載平衡器
<a name="multiple-targetgroups-example1"></a>

在以下的使用案例中，服務會對相同的容器和連接埠使用兩個不同的負載平衡器，一個用於內部流量，另一個用於面向網際網路的流量。

```
"loadBalancers":[
   //Internal ELB
   {  
      "targetGroupArn":"arn:aws:elasticloadbalancing:region:123456789012:targetgroup/target_group_name_1/1234567890123456",
      "containerName":"nginx",
      "containerPort":8080
   },
   //Internet-facing ELB
   {  
      "targetGroupArn":"arn:aws:elasticloadbalancing:region:123456789012:targetgroup/target_group_name_2/6543210987654321",
      "containerName":"nginx",
      "containerPort":8080
   }
]
```

### 公開相同容器中的多個連接埠
<a name="multiple-targetgroups-example1"></a>

在以下的使用案例中，服務會使用一個負載平衡器，但公開相同容器中的多個連接埠。例如，Jenkins 容器可公開適用於 Jenkins Web 界面的連接埠 8080，以及公開適用於 API 的連接埠 50000。

```
"loadBalancers":[
   {  
      "targetGroupArn":"arn:aws:elasticloadbalancing:region:123456789012:targetgroup/target_group_name_1/1234567890123456",
      "containerName":"jenkins",
      "containerPort":8080
   },
   {  
      "targetGroupArn":"arn:aws:elasticloadbalancing:region:123456789012:targetgroup/target_group_name_2/6543210987654321",
      "containerName":"jenkins",
      "containerPort":50000
   }
]
```

### 公開多個容器中的連接埠
<a name="multiple-targetgroups-example3"></a>

在以下的使用案例，服務會使用一個負載平衡器和兩個目標群組，以公開不同容器中的連接埠。

```
"loadBalancers":[
   {  
      "targetGroupArn":"arn:aws:elasticloadbalancing:region:123456789012:targetgroup/target_group_name_1/1234567890123456",
      "containerName":"webserver",
      "containerPort":80
   },
   {  
      "targetGroupArn":"arn:aws:elasticloadbalancing:region:123456789012:targetgroup/target_group_name_2/6543210987654321",
      "containerName":"database",
      "containerPort":3306
   }
]
```

# 自動擴展您的 Amazon ECS 服務
<a name="service-auto-scaling"></a>

*自動擴展*是自動增加或減少 Amazon ECS 服務中所需任務數量的功能。Amazon ECS 利用 Application Auto Scaling 服務來提供此功能。如需詳細資訊，請參閱 [Application Auto Scaling 使用者指南](https://docs.aws.amazon.com/autoscaling/application/userguide/what-is-application-auto-scaling.html)。

Amazon ECS 會發佈具有您的服務平均 CPU 和記憶體用量的 CloudWatch 指標。如需詳細資訊，請參閱[Amazon ECS 服務使用率指標](service_utilization.md)。您可以使用這些指標和其他 CloudWatch 指標來向外擴展服務 (新增更多任務) 來處理尖峰時段的高需求量，以及將服務向內縮減 (執行較少任務) 以減少低使用率期間的成本。

Amazon ECS Service Auto Scaling 支援下列自動擴展類型：
+ [使用目標指標擴展 Amazon ECS 服務](service-autoscaling-targettracking.md)–根據特定指標的目標值，增加或減少您服務執行的任務數目。這與您運用電熱器維持家中溫度的方式很類似。您只要選取溫度，電熱器會自行執行其餘操作。
+ [根據 CloudWatch 警示使用預先定義的增量來擴展 Amazon ECS 服務](service-autoscaling-stepscaling.md)–根據一組依警示違規大小而變動的擴展調整 (稱為步驟調整)，增加或減少您服務執行的任務數目。
+ [使用排程動作來擴展 Amazon ECS 服務](service-autoscaling-schedulescaling.md)：根據日期與時間增加或減少服務執行的任務數量。
+ [使用歷史模式透過預測擴展來擴展 Amazon ECS 服務](predictive-auto-scaling.md)：根據歷史負載資料分析增加或減少服務執行的任務數量，以偵測每日或每週流量流程模式。

   

## 考量事項
<a name="auto-scaling-concepts"></a>

使用擴展策略時，考慮下列事項：
+ Amazon ECS 每隔 1 分鐘會將指標傳送至 CloudWatch。在叢集和服務將指標傳送至 CloudWatch 前，指標皆無法使用，而且您也無法建立不存在之指標的 CloudWatch 警示。
+ 擴展政策支援冷卻時間。等待先前擴展活動生效的秒數。
  + 對於向外擴展事件，其目的是連續的規模擴展 (但並非過度)。在 Service Auto Scaling 使用擴展政策成功擴展之後，就會開始計算冷卻時間。除非初始化較大的橫向擴展或冷卻時間結束，否則擴展政策不會再次增加所需的容量。在向外擴展冷卻期間有效時，由起始冷卻的向外擴展活動所增加的容量，將計入下次向外擴展活動所需的容量。
  + 對於向內縮減事件，其用意在於保守縮減以保護應用程式的可用性，所以冷卻時間過後才會開放縮減活動。不過，若在向內縮減冷卻時間另有警示起始了橫向擴展活動，Service Auto Scaling 則會立即橫向擴展目標。在這種情況下，向內擴展冷卻期間隨即停止，且不會完成。
+ 服務排程器隨時會使用所需的計數，但只要您具有服務的有效擴展政策和警示，Service Auto Scaling 就可以變更您手動設定的所需計數。
+ 如果設定的服務所需計數低於其容量值下限，且警示啟動橫向擴充活動，服務自動擴展功能會將所需計數擴展到容量值下限，然後視需要根據與警示相關聯的擴展政策來持續橫向擴充。不過，向內擴展活動不會調整所需的計數，因為它已低於最小容量值。
+ 如果設定的服務所需計數高於其容量值上限，且警示啟動縮減活動，服務自動擴展功能會將所需計數橫向擴充到容量值上限，然後視需要根據與警示相關聯的擴展政策來持續縮減。不過，向外擴展活動不會調整所需的計數，因為它已高於最大容量值。
+ 在擴展活動期間，服務中實際執行的任務計數是 Service Auto Scaling 用作起始點的值，而不是所需的計數。這應為處理容量。這可防止無法滿足的過度且失控的擴展，例如，有可能因容器執行個體資源不足而無法放置其他任務。如果容器執行個體容量稍後可用，則擱置的擴展活動可能會成功，接著在冷卻時間之後進行後續的擴展活動。
+ 若希望您的任務計數在沒有待完成工作時縮減到零，將最小容量設定為 0。使用目標追蹤擴展政策，當實際容量為 0 而指標顯示有工作負載需求時，Service Auto Scaling 會在擴展前等待一個待傳送的資料點。在此情況下，它會向外擴展可能的數量下限做為起始點，然後以實際執行的任務計數為基礎繼續擴展。
+ Application Auto Scaling 會在 Amazon ECS 部署正在進行時關閉縮減程序。不過，除非在部署期間暫停，否則向外擴展程序會繼續發生。此行為不適用於使用外部部署控制器的 Amazon ECS 服務。如需詳細資訊，請參閱[服務自動擴展和部署](#service-auto-scaling-deployments)。
+ 您有多個適用於 Amazon ECS 任務的 Application Auto Scaling 選項。目標追蹤是最容易使用的模式。這樣一來，您僅需要為指標設定目標值，例如 CPU 平均使用率。然後，自動縮放器會自動管理獲得該值所需的任務數量。使用步驟擴展，您可以更快對需求變化做出反應，因為您定義了擴展指標的特定閾值，以及超越閾值時要新增或刪除的任務數量。而且，更重要的是，您可以透過最大限度減少閾值警報違反的時間來對需求變化做出非常快速的反應。

如需有關服務自動擴展最佳實務的詳細資訊，請參閱[最佳化 Amazon ECS 服務自動擴展](capacity-autoscaling-best-practice.md)。

## 服務自動擴展和部署
<a name="service-auto-scaling-deployments"></a>

Application Auto Scaling 會在 Amazon ECS 部署正在進行時關閉縮減程序。不過，除非在部署期間暫停，否則向外擴展程序會繼續發生。此行為不適用於使用外部部署控制器的 Amazon ECS 服務。如果您想要在部署正在進行時暫停向外擴展程序，請執行下列步驟。

1. 呼叫 [describe-scalable-targets](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/describe-scalable-targets.html) 命令，指定在 Application Auto Scaling 中與可擴展目標關聯的服務資源 ID (範例：`service/default/sample-webapp`)。記錄輸出。您將在呼叫下一個命令時用到它。

1. 呼叫 [register-scalable-target](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/register-scalable-target.html) 命令，指定資源 ID、命名空間和可擴展維度。同時為 `DynamicScalingInSuspended` 和 `DynamicScalingOutSuspended` 指定 `true`。

1. 部署完成後，您可以呼叫 [register-scalable-target](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/register-scalable-target.html) 命令以繼續擴展。

如需詳細資訊，請參閱[暫停和繼續擴展 Application Auto Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-suspend-resume-scaling.html)。

# 使用目標指標擴展 Amazon ECS 服務
<a name="service-autoscaling-targettracking"></a>

使用目標追蹤擴展政策，您可以選取指標並設定目標值。Amazon ECS Service Auto Scaling 會建立和管理可控制擴展政策的 CloudWatch 警示，並根據指標和目標值來計算擴展調整。擴展政策會視需要新增或移除服務任務，讓指標保持在或接近指定的目標值。除了將指標保持在接近目標值之外，目標追蹤擴展政策也會根據由於負載模式波動而導致的指標波動進行調整，並將服務中執行的任務數量快速波動降至最低。

目標追蹤政策無需手動定義 CloudWatch 警示和擴展調整內容，Amazon ECS 會根據您設定的目標自動處理此問題。

使用目標追蹤政策時，請考慮下列事項：
+ 目標追蹤擴展政策假設在指定的指標超過目標值時，應執行向外擴展。您無法使用目標追蹤擴展政策在指定的指標低於目標值時執行向外擴展。
+ 所指定指標的資料不足時，目標追蹤擴展政策不會執行擴展。政策不會執行向內擴展，因為向內擴展不會將資料不足解釋為低使用率。
+ 您可能會看到目標值與實際指標資料點之間有些差距。原因是 Service Auto Scaling 在決定新增或移除多少容量時，一律以四捨五入來保守處理。這樣可防止新增不足的容量，或移除過多的容量。
+ 為了確保應用程式可用性，服務可以按比例快速地向外擴展到指標，但需漸漸地逐步向內擴展。
+ Application Auto Scaling 會在 Amazon ECS 部署正在進行時關閉縮減程序。不過，除非在部署期間暫停，否則向外擴展程序會繼續發生。此行為不適用於使用外部部署控制器的 Amazon ECS 服務。如需詳細資訊，請參閱[服務自動擴展和部署](service-auto-scaling.md#service-auto-scaling-deployments)。
+ 您可以擁有 Amazon ECS 服務的多個目標追蹤擴展政策，但前提是每個政策都使用不同的指標。Service Auto Scaling 的用意一律以可用性為優先，因此其行為視目標追蹤政策是準備水平擴展或縮減而有所不同。如果任何目標追蹤政策已準備好橫向擴展，其就會將服務橫向擴展，但只有在所有目標追蹤政策 (已開啟縮減部分) 都已準備好要縮減時才會縮減。
+ 請勿編輯或刪除 CloudWatch 警示，Service Auto Scaling 管理它們用於目標追蹤擴展政策。當您刪除擴展政策時，Service Auto Scaling 會自動刪除警示。
+ 藍/綠部署類型不支援目標追蹤擴展政策的 `ALBRequestCountPerTarget` 指標。

如需有關目標追蹤擴展政策的詳細資訊，請參閱《Application Auto Scaling 使用者指南》中的[目標追蹤擴展政策](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-target-tracking.html)。

# 為 Amazon ECS 服務自動擴展功能建立目標追蹤擴展政策
<a name="target-tracking-create-policy"></a>

建立目標追蹤擴展政策，以便 Amazon ECS 自動增加或減少服務中所需的任務計數。目標追蹤根據目標指標值運作。

## 主控台
<a name="target-tracking-create-policy-aws-console"></a>

1. 除了建立與更新服務所需的標準 IAM 許可外，您還需要其他許可。如需詳細資訊，請參閱[Amazon ECS 服務自動擴展所需的 IAM 許可](auto-scaling-IAM.md)。

1. 決定用於政策的指標。下列指標可供使用：
   +  **ECSServiceAverageCPUUtilization** – 服務應使用的平均 CPU 使用率。
   + **ECSServiceAverageMemoryUtilization** – 服務應使用的平均記憶體使用率。
   + **ALBRequestCountPerTarget** – 任務理想情況下，任務每分鐘應接收的平均請求數。

1. 開啟主控台，網址為 [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)。

1. 在**叢集**頁面上，選擇叢集。

1. 在「叢集詳細資訊」頁面上的**服務**區段中選擇服務。

   服務資訊頁面隨即顯示。

1. 選擇**設定任務數量**。

1. 在 **Amazon ECS 服務任務計數**下，選擇**使用自動擴展**。

   **任務計數**區段隨即顯示。

   1. 在**任務數量下限**欄位中，輸入供服務自動擴展功能使用的任務數量下限。所需的計數不會低於此計數。

   1. 在**上限**欄位中，輸入供服務自動擴展功能使用的任務數量上限。所需的計數不會高於此計數。

   1. 選擇**儲存**。

      政策頁面隨即顯示。

1. 選擇**建立擴展政策**。

   **建立政策**頁面隨即顯示。

1. 針對 **Scaling policy type** (擴展政策類型)，選擇 **Target tracking** (目標追蹤)。

1. 針對 **Policy name** (政策名稱)，輸入政策的名稱。

1. 在**指標類型**欄位中，從選項清單中選擇指標。

1. 在**目標使用率**欄位中，輸入 Amazon ECS 應維護之任務的百分比目標值。服務自動擴展功能會橫向擴充容量，直到平均使用率達到目標使用率，或達到所指定的任務數量上限。

1. 在**其他設定**下，執行下列動作

   1. 在**縮減冷卻時間**欄位中，輸入一個縮減活動完成之後、另一個縮減活動開始之前的時間 (以秒為單位)。

   1. 在**橫向擴充冷卻時間**欄位中，輸入等待上一個橫向擴充活動生效的時間 (以秒為單位)。

   1. 若要僅建立橫向擴充政策，請選取**停用縮減**。

1. 選擇**建立擴展政策**。

## AWS CLI
<a name="target-tracking-create-policy-aws-cli"></a>

1. 使用 [register-scalable-target](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/register-scalable-target.html) 命令，將 Amazon ECS 服務註冊為可擴展性目標。

1. 使用 [put-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/put-scaling-policy.html) 命令，來建立擴展政策。

# 根據 CloudWatch 警示使用預先定義的增量來擴展 Amazon ECS 服務
<a name="service-autoscaling-stepscaling"></a>

如果使用步進擴展政策，您可以建立及管理觸發擴展程序的 CloudWatch 警示。違反警示時，Amazon ECS 會啟動與該警示相關聯的擴展政策。步進擴展政策會根據一組調整 (稱為步進調整) 來擴展任務。調整幅度會依流量達到警示閾值的程度而有所不同。
+ 如果違規程度超過第一個閾值，Amazon ECS 會套用第一個步進調整。
+ 如果違規程度超過第二個閾值，Amazon ECS 會套用第二個步進調整，以此類推。

強烈建議使用目標追蹤擴展政策，根據平均 CPU 使用率或每個目標的平均請求計數等指標進行擴展。容量增加時減少的指標與容量減少時增加的指標，可用於使用目標追蹤依比例橫向擴充或縮減任務數量。這有助於確保 Amazon ECS 緊密地遵循應用程式的需求曲線。

# 為 Amazon ECS 服務自動擴展建立步進擴展政策
<a name="step-scaling-create-policy"></a>

建立步進擴展政策，以便 Amazon ECS 自動增加或減少服務中所需的任務數量。步進擴展根據一組擴展調整 (稱為步進調整) 來執行，這些調整會依警示違規程度而變動。

## 主控台
<a name="step-scaling-create-policy-aws-console"></a>

1. 除了建立與更新服務所需的標準 IAM 許可外，您還需要其他許可。如需詳細資訊，請參閱[Amazon ECS 服務自動擴展所需的 IAM 許可](auto-scaling-IAM.md)。

1. 決定用於政策的指標。下列指標可供使用：
   +  **ECSServiceAverageCPUUtilization** – 服務應使用的平均 CPU 使用率。
   + **ECSServiceAverageMemoryUtilization** – 服務應使用的平均記憶體使用率。
   + **ALBRequestCountPerTarget** – 任務理想情況下，任務每分鐘應接收的平均請求數。

1. 為指標建立 CloudWatch 警示。如需詳細資訊，請參閱 *Amazon CloudWatch 使用者指南*中的[建立以靜態閾值為基礎的 CloudWatch 警示](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ConsoleAlarms.html)。

1. 開啟主控台，網址為 [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)。

1. 在**叢集**頁面上，選擇叢集。

1. 在「叢集詳細資訊」頁面上的**服務**區段中選擇服務。

   服務資訊頁面隨即顯示。

1. 選擇**設定任務數量**。

1. 在 **Amazon ECS 服務任務計數**下，選擇**使用自動擴展**。

   **任務計數**區段隨即顯示。

   1. 在**任務數量下限**欄位中，輸入供服務自動擴展功能使用的任務數量下限。所需的計數不會低於此計數。

   1. 在**上限**欄位中，輸入供服務自動擴展功能使用的任務數量上限。所需的計數不會高於此計數。

   1. 選擇**儲存**。

      政策頁面隨即顯示。

1. 選擇**建立擴展政策**。

   **建立政策**頁面隨即顯示。

1. 在**擴展政策類型**欄位中選擇**步進擴展**。

1. 設定橫向擴充屬性。在**新增任務的步驟**下，執行下列動作：

   1. 針對 **Policy name** (政策名稱)，輸入政策的名稱。

   1. 在 **CloudWatch 警示名稱**欄位中選擇 CloudWatch 警示。

   1. 在**指標彙總類型**欄位中，選擇如何將所選指標與定義的閾值進行比較。

   1. 在**調整類型**欄位中，選擇是根據任務數量的變更進行調整，還是根據任務百分比的變更進行調整。

   1. 在**要採取的動作**欄位中，輸入要採取的動作值。

      選擇**新增步驟**以新增其他動作。

1. 設定縮減屬性。在**移除任務的步驟**下，執行下列動作：

   1. 針對 **Policy name** (政策名稱)，輸入政策的名稱。

   1. 在 **CloudWatch 警示名稱**欄位中選擇 CloudWatch 警示。

   1. 在**指標彙總類型**欄位中，選擇如何將所選指標與定義的閾值進行比較。

   1. 在**調整類型**欄位中，選擇是根據任務數量的變更進行調整，還是根據任務百分比的變更進行調整。

   1. 在**要採取的動作**欄位中，輸入要採取的動作值。

      選擇**新增步驟**以新增其他動作。

1. 在**冷卻時間**欄位中，輸入等待上一個擴展活動生效的時間 (以秒為單位)。對於新增政策，這是橫向擴充活動結束之後，擴展政策封鎖縮減活動並限制一次可以橫向擴充多少項任務的時間。對於移除政策，這是一個縮減活動結束之後、另一個縮減活動開始之前必須經過的時間。

1. 選擇**建立擴展政策**。

## AWS CLI
<a name="step-scaling-create-policy-aws-cli"></a>

1. 使用 [register-scalable-target](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/register-scalable-target.html) 命令，將 Amazon ECS 服務註冊為可擴展性目標。

1. 使用 [put-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/put-scaling-policy.html) 命令，來建立擴展政策。

# 使用排程動作來擴展 Amazon ECS 服務
<a name="service-autoscaling-schedulescaling"></a>

透過排程擴展，您可以建立排程動作，根據所預測的負載變動，在特定時間增加或減少任務數量，針對應用程式設定自動擴展。如此一來，您便能主動調整應用程式規模，以符合負載變動預測。

藉由這些排定的擴展動作，您可將費用和效能調整到最佳狀態。應用程式將擁有足夠數量的任務來處理週間的流量高峰，但在其他時段不會過度佈建任務數量。

您可以搭配利用排程擴展和擴展政策，以主動和被動的方式處理規模擴展作業，同時享有這兩種方法的好處。執行排定的擴展動作後，擴展政策可以繼續決定是否進一步擴展任務數量。這有助於確保您擁有足夠數量的任務來處理應用程式負載。當應用程式擴展以滿足需求時，目前的容量必須處於排程動作所設定的任務數量上下限之內。

可以使用 AWS CLI設定排程擴展。如需有關排程擴展的詳細資訊，請參閱 *Application Auto Scaling User Guide* 中的 [Scheduled Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-scheduled-scaling.html)。

# 為 Amazon ECS 服務自動擴展功能建立排程動作
<a name="scheduled-action-create-policy"></a>

您建立排程動作時，Amazon ECS 會根據日期與時間增加或減少服務執行的任務數量。

## 主控台
<a name="scheduled-action-policy-aws-console"></a>

1. 開啟主控台，網址為 [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)。

1. 在**叢集**頁面上，選擇叢集。

1. 在「叢集詳細資訊」頁面上的**服務**區段中，選擇所需服務。

   服務資訊頁面隨即顯示。

1. 選擇**服務自動擴展**。

   服務自動擴展頁面隨即顯示。

1. 如果您尚未設定服務自動擴展功能，請選擇**設定任務數量**。

   **Amazon ECS 服務任務計數**區段隨即顯示。

   在 **Amazon ECS 服務任務計數**下，選擇**使用服務自動擴展來調整服務所需的任務計數**。

   **任務計數**區段隨即顯示。

   1. 在**任務數量下限**欄位中，輸入供服務自動擴展功能使用的任務數量下限。所需的計數不會低於此計數。

   1. 在**上限**欄位中，輸入供服務自動擴展功能使用的任務數量上限。所需的計數不會高於此計數。

   1. 選擇**儲存**。

      政策頁面隨即顯示。

1. 選擇**排程動作**，然後選擇**建立**。

   **建立排程動作**頁面隨即顯示。

1. 在**名稱**欄位中輸入唯一的名稱。

1. 對於 **Time zone** (時區)，選擇時區。

   所有列出的時區都來自 IANA 時區資料庫。如需詳細資訊，請參閱 [List of tz database time zones](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones)。

1. 在**開始時間**欄位中，輸入動作開始的**日期**與**時間**。

   如果選擇週期性排程，開始時間會定義週期性序列中第一個排程作業的執行時間。

1. 針對 **Recurrence** (週期)，選擇其中一個可用選項。
   + 若要依週期性排程進行擴展，請選擇 Amazon ECS 執行排程動作的頻率。
     + 如果選擇以**速率**開始的選項，則會為您建立 Cron 表達式。
     + 如果選擇 **Cron**，請輸入指定何時執行動作的 Cron 表達式。
   + 若僅擴展一次，請選擇**一次**。

1. 在**任務調整**下，執行下列動作：
   + 在**下限**欄位中，輸入服務應執行的任務數量下限。
   + 在**上限**欄位中，輸入服務應執行的任務數量上限。

1. 選擇**建立排程動作**。

## CLI
<a name="scheduled-action-aws-cli"></a>

使用 設定服務的排程擴展政策 AWS CLI ，如下所示。將每個*使用者輸入預留位置*替換為自己的資訊。

**範例：僅擴展一次**  
搭配 `--start-time "YYYY-MM-DDThh:mm:ssZ"` 以及 `--MinCapacity` 與 `--MaxCapacity` 選項之一或兩者，使用下列 [put-scheduled-action](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/put-scheduled-action.html) 命令。

```
aws application-autoscaling put-scheduled-action --service-namespace ecs \
  --resource-id service/my-cluster/my-service \
  --scheduled-action-name my-one-time-schedule \
  --start-time 2021-01-30T12:00:00 \
  --scalable-target-action MinCapacity=3,MaxCapacity=10
```

**範例：依據週期性排程排定擴展**  
使用下列 [put-scheduled-action](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/put-scheduled-action.html) 命令。將 *user input* 取代為實際值。

```
aws application-autoscaling put-scheduled-action --service-namespace ecs \
  --resource-id service/my-cluster/my-service \
  --scheduled-action-name my-recurring-action \
  --schedule "rate(5 hours)" \
  --start-time 2021-01-30T12:00:00 \
  --end-time 2021-01-31T22:00:00 \
  --scalable-target-action MinCapacity=3,MaxCapacity=10
```

指定的週期性排程會根據 UTC 時區執行。若要指定不同的時區，請包含 `--time-zone` 選項與 IANA 時區的名稱，如下列範例所示。

```
--time-zone "America/New_York"
```

如需詳細資訊，請參閱 [List of tz database time zones](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones)。

# 使用歷史模式透過預測擴展來擴展 Amazon ECS 服務
<a name="predictive-auto-scaling"></a>

預測性擴展會檢視過去從流量流程載入的資料，以分析每日或每週模式。然後利用此分析來預測未來需求，並根據需要主動增加服務中的任務。

預測性自動擴展在下列情況中最為有用。
+ 周期性流量 – 在常規工作時間資源使用量增加，而在夜間與週末資源使用量減少。
+ 重複間歇工作負載模式 – 例如批次處理、測試或週期性資料分析。
+ 需要長時間才能初始化的應用程式 – 這可能會在橫向擴充事件期間影響應用程式效能，造成明顯延遲。

如果應用程式需要長時間才能初始化，並且流量以常規模式增加，您應該考慮使用預測性擴展。此功能透過為預測負載主動增加任務數量來協助您更快地擴展，而不是僅使用動態擴展政策，例如目標追蹤或步進擴展。透過協助您避免出現過度佈建任務數量的可能性，預測性擴展也可能會為您節省成本。

例如，考量應用程式在營業時間內具有高使用率而在夜間具有低使用率。在每個工作日開始時，預測性擴展可以在第一次流量湧入之前橫向擴充任務。在從較低的使用率期間到較高的使用率期間時，這可協助您的應用程式維持高可用性和效能。您不必等待動態擴展來對不斷變化的流量做出反應。您也無需花時間檢閱應用程式的負載模式並嘗試使用排程擴展來排程適量的任務。

預測性擴展是一項服務層級功能，可獨立於基礎運算容量 (例如 EC2 或 Fargate) 的擴展來擴展服務任務。對於 Fargate， 會根據任務需求 AWS 管理和自動擴展基礎容量。對於 EC2 容量，您可以使用 Auto Scaling 群組容量提供者，根據任務的擴展需求自動擴展基礎 EC2 執行個體。

**Topics**
+ [預測性擴展概觀](#predictive-auto-scaling-overview)
+ [建立預測性擴展政策](predictive-scaling-create-policy.md)
+ [評估您的預測擴展政策](predictive-scaling-graphs.md)
+ [覆寫預測](predictive-scaling-overriding-forecast-capacity.md)
+ [使用自訂指標](predictive-scaling-custom-metrics.md)

## 預測性擴展在 Amazon ECS 中的運作方式
<a name="predictive-auto-scaling-overview"></a>

您可以在此處了解使用預測性擴展的考量、其運作方式以及相關限制。

### 使用預測性擴展的考量
<a name="predictive-auto-scaling-considerations"></a>
+ 您需要確保預測性擴展適合工作負載。可以透過在**僅預測**模式下設定擴展政策對此進行檢查，並查看主控台的建議。在開始使用預測性擴展之前，您應該先評估預測與建議。
+ 預測性擴展需要至少 24 小時的歷史資料才能開始預測。可用的歷史資料越多，預測效果越好，兩週的歷史資料最為理想。您刪除 Amazon ECS 服務並建立新服務時，還需要等待 24 小時，預測性擴展才能產生新的預測。加快此程序的一種方法是使用自訂指標，以彙總新舊 Amazon ECS 服務的指標。
+ 選擇能準確代表應用程式完整負載，且是應用程式最重要擴展方面的負載指標。
+ 結合預測性擴展的動態擴展可協助您密切遵循應用程式的需求，因此您可以在低落期間進行縮減，並在流量意外增加期間進行橫向擴充。當多個擴展政策處於作用中狀態時，每個政策會獨立決定所需的任務數量，並將所需任務數量設定為其中的上限。
+ 您可以使用預測性擴展搭配動態擴展政策，例如目標追蹤或步進擴展，以便應用程式根據即時模式與歷史模式進行擴展。預測性擴展本身不會縮減任務。
+ 如果您在呼叫 `register-scalable-target` API 時使用自訂角色，可能會收到錯誤，指出預測性擴展政策只能在啟用 SLR 的情況下運作。在這種情況下，您應該再次呼叫 `register-scalable-target`，但不使用 role-arn。在註冊可擴展的目標時，請使用 SLR，並呼叫 `put-scaling-policy` API。

### 預測擴展的運作方式
<a name="predictive-auto-scaling-details"></a>

您可以透過建立指定要監控與分析之 CloudWatch 指標的預測性擴展政策，來使用預測性擴展。預測性擴展需要至少 24 小時的資料，才能開始預測未來的值。

建立政策後，預測性擴展會開始分析過去最多 14 天內的指標資料，以識別模式。此分析用於產生接下來 48 小時每小時的需求預測。最新的 CloudWatch 資料用於每六小時更新一次預測。隨著新資料傳入，預測性擴展會不斷提高未來預測的準確性。

當您首次啟用預測性擴展時，它會以*僅預測*模式執行。它會在此模式下產生預測，但不會根據這些預測擴展 Amazon ECS 服務。這表示您可以評估預測的準確性與適用性。您可以透過使用 `GetPredictiveScalingForecast` API 操作或 AWS 管理主控台來檢視預測資料。

您決定開始使用預測性擴展時，請將擴展政策切換至*預測與擴展*模式。在此模式下會發生下列情況。

依預設，Amazon ECS 服務會在每小時開始時根據該小時的預測進行擴展。您可以透過在 `PutScalingPolicy` API 操作中使用 `SchedulingBufferTime` 屬性，選擇提早開始。這使得新任務在預測需求之前啟動，並給予其時間開機並準備好處理流量。

### 任務數量上限
<a name="predictive-scaling-maximum-tasks-limit"></a>

您註冊 Amazon ECS 服務進行擴展時，需要定義每項服務可以啟動的任務數量上限。依預設，當設定擴展政策時，它們無法增加高於其上限的任務數量。

或者，如果預測接近或超過 Amazon ECS 服務的任務數量上限，您可以允許自動增加服務的任務數量上限。

**警告**  
允許自動增加任務數量上限時請小心謹慎。如果沒有監控與管理增加的任務數量上限，這可能會導致啟動的任務數量超出預期。增加的任務數量上限會成為 Amazon ECS 服務新的常規任務數量上限，直到您進行手動更新。任務數量上限不會自動減少回原始上限。

### 支援的 區域
<a name="predictive-auto-scaling-supported-regions"></a>
+ 美國東部 (維吉尼亞北部)
+ 美國東部 (俄亥俄)
+ 美國西部 (加利佛尼亞北部)
+ 美國西部 (奧勒岡)
+ 非洲 (開普敦)
+ 亞太地區 (香港)
+ 亞太地區 (雅加達)
+ 亞太地區 (孟買)
+ 亞太區域 (大阪)
+ 亞太區域 (首爾)
+ 亞太區域 (新加坡)
+ 亞太地區 (雪梨)
+ 亞太區域 (東京)
+ 加拿大 (中部)
+ 中國 (北京)
+ 中國 (寧夏)
+ 歐洲 (法蘭克福)
+ 歐洲 (愛爾蘭)
+ 歐洲 (倫敦)
+ 歐洲 (米蘭)
+ 歐洲 (巴黎)
+ 歐洲 (斯德哥爾摩)
+ 中東 (巴林)
+ 南美洲 (聖保羅)
+ AWS GovCloud （美國東部）
+ AWS GovCloud （美國西部）

# 為 Amazon ECS 服務自動擴展建立預測性擴展政策
<a name="predictive-scaling-create-policy"></a>

建立預測性擴展政策，以便 Amazon ECS 根據歷史資料增加或減少服務執行的任務數量。

**注意**  
新服務需要提供至少 24 小時的資料，才能產生預測結果。

## 主控台
<a name="predictive-scaling-policy-aws-console"></a>

1. 除了建立與更新服務所需的標準 IAM 許可外，您還需要其他許可。如需詳細資訊，請參閱[Amazon ECS 服務自動擴展所需的 IAM 許可](auto-scaling-IAM.md)。

1. 決定用於政策的指標。下列指標可供使用：
   +  **ECSServiceAverageCPUUtilization** – 服務應使用的平均 CPU 使用率。
   + **ECSServiceAverageMemoryUtilization** – 服務應使用的平均記憶體使用率。
   + **ALBRequestCountPerTarget** – 任務理想情況下，任務每分鐘應接收的平均請求數。

   您也可以使用自訂指標。需要定義下列值：
   + 負載 – 可準確代表應用程式完整負載，且是應用程式最重要擴展方面的指標。
   + 擴展指標 – 最能預測多少使用率最適合應用程式的指標。

1. 開啟主控台，網址為 [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)。

1. 在**叢集**頁面上，選擇叢集。

1. 在「叢集詳細資訊」頁面上的**服務**區段中，選擇所需服務。

   服務資訊頁面隨即顯示。

1. 選擇**服務自動擴展**，然後選擇**設定任務數量**。

1. 在 **Amazon ECS 服務任務計數**下，選擇**使用自動擴展**。

   **任務計數**區段隨即顯示。

   1. 在**任務數量下限**欄位中，輸入供服務自動擴展功能使用的任務數量下限。所需的計數不會低於此計數。

   1. 在**上限**欄位中，輸入供服務自動擴展功能使用的任務數量上限。所需的計數不會高於此計數。

   1. 選擇**儲存**。

      政策頁面隨即顯示。

1. 選擇**建立擴展政策**。

   **建立政策**頁面隨即顯示。

1. 在**擴展政策類型**欄位中選擇**預測性擴展**。

1. 針對 **Policy name** (政策名稱)，輸入政策的名稱。

1. 在**指標對**欄位中，從選項清單中選擇指標。

   如果選擇了 **Application Load Balancer request count per target** (每個目標的 Application Load Balancer 請求計數)，則在 **Target group** (目標群組) 中選擇目標群組。只有將 Application Load Balancer 目標群組連接至服務後，才支援**每個目標的 Application Load Balancer 請求計數**。

   如果選擇了**自訂指標對**，則從**負載指標**與**擴展指標**清單中選擇個別指標。

1. 在**目標使用率**欄位中，輸入 Amazon ECS 應維護之任務的百分比目標值。服務自動擴展功能會橫向擴充容量，直到平均使用率達到目標使用率，或達到所指定的任務數量上限。

1. 選擇**建立擴展政策**。

## AWS CLI
<a name="predictive-scaling-policy-aws-cli"></a>

使用 AWS CLI 設定 Amazon ECS 服務的預測擴展政策，如下所示。將每個*使用者輸入預留位置*替換為自己的資訊。

如需有關可指定之 CloudWatch 指標的詳細資訊，請參閱 *Amazon EC2 Auto Scaling API Reference* 中的 [PredictiveScalingMetricSpecification](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_PredictiveScalingMetricSpecification.html)。

### 範例 1：具有預先定義記憶體的預測性擴展政策。
<a name="predictive-scaling-cli-example-one"></a>

以下是具有預先定義記憶體組態的政策範例。

```
cat policy.json
{
    "MetricSpecifications": [
        {
            "TargetValue": 40,
            "PredefinedMetricPairSpecification": {
                "PredefinedMetricType": "ECSServiceMemoryUtilization"
            }
        }
    ],
    "SchedulingBufferTime": 3600,
    "MaxCapacityBreachBehavior": "HonorMaxCapacity",
    "Mode": "ForecastOnly"
}
```

下列範例示範了透過執行帶有指定組態檔案的 [put-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/put-scaling-policy.html) 命令來建立政策。

```
aws application-autoscaling put-scaling-policy \
--service-namespace ecs \
--region us-east-1 \
--policy-name predictive-scaling-policy-example \
--resource-id service/MyCluster/test \
--policy-type PredictiveScaling \
--scalable-dimension ecs:service:DesiredCount \
--predictive-scaling-policy-configuration file://policy.json
```

如果成功，此命令會傳回政策的 ARN。

```
{
    "PolicyARN": "arn:aws:autoscaling:us-east-1:012345678912:scalingPolicy:d1d72dfe-5fd3-464f-83cf-824f16cb88b7:resource/ecs/service/MyCluster/test:policyName/predictive-scaling-policy-example",
    "Alarms": []
}
```

### 範例 2：具有預先定義 CPU 的預測性擴展政策。
<a name="predictive-scaling-cli-example-two"></a>

以下是具有預先定義 CPU 組態的政策範例。

```
cat policy.json
{
    "MetricSpecifications": [
        {
            "TargetValue": 0.00000004,
            "PredefinedMetricPairSpecification": {
                "PredefinedMetricType": "ECSServiceCPUUtilization"
            }
        }
    ],
    "SchedulingBufferTime": 3600,
    "MaxCapacityBreachBehavior": "HonorMaxCapacity",
    "Mode": "ForecastOnly"
}
```

下列範例示範了透過執行帶有指定組態檔案的 [put-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/put-scaling-policy.html) 命令來建立政策。

```
aws aas put-scaling-policy \
--service-namespace ecs \
--region us-east-1 \
--policy-name predictive-scaling-policy-example \
--resource-id service/MyCluster/test \
--policy-type PredictiveScaling \
--scalable-dimension ecs:service:DesiredCount \
--predictive-scaling-policy-configuration file://policy.json
```

如果成功，此命令會傳回政策的 ARN。

```
{
    "PolicyARN": "arn:aws:autoscaling:us-east-1:012345678912:scalingPolicy:d1d72dfe-5fd3-464f-83cf-824f16cb88b7:resource/ecs/service/MyCluster/test:policyName/predictive-scaling-policy-example",
    "Alarms": []
}
```

# 為 Amazon ECS 評估預測性擴展政策
<a name="predictive-scaling-graphs"></a>

使用預測性擴展政策來擴展服務之前，請先在 Amazon ECS 主控台中檢閱建議及政策的其他資料。這很重要，因為您不希望預測擴展政策在您知道其預測準確之前擴展實際容量。

如果是新服務，需要 24 小時才能建立第一個預測。

 AWS 建立預測時，會使用歷史資料。如果服務尚無足夠的最新歷史資料，預測性擴展可能會使用從目前可用的歷史彙總資料建立的彙總資料來暫時回填預測。預測會在政策建立日期前的兩週內回填。

## 檢視您的預測擴展建議
<a name="view-predictive-scaling-recommendations"></a>

為了獲得有效的分析，服務自動擴展功能應具有至少兩個可進行比較的預測性擴展政策。(不過，您仍然可以檢閱單一政策的問題清單。) 建立多個政策時，您可以根據使用不同指標的政策，評估使用一個指標的政策。您也可以評估不同目標值和指標組合的影響。建立預測性擴展政策之後，Amazon ECS 會立即開始評估哪些政策可以更好地擴展群組。

**在 Amazon ECS 主控台中檢視建議**

1. 開啟主控台，網址為 [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)。

1. 在**叢集**頁面上，選擇叢集。

1. 在「叢集詳細資訊」頁面上的**服務**區段中，選擇所需服務。

   服務資訊頁面隨即顯示。

1. 選擇**服務自動擴展**。

1. 選擇預測性擴展政策，然後選擇**動作**、**預測性擴展**、**檢視建議**。

   您可以檢視政策的詳細資訊以及我們的建議。該建議會告訴您使用預測擴展政策的結果是否優於不使用它。

   如果您不確定預測擴展政策是否適合您的群組，請檢閱**可用性影響**和**成本影響**欄，以選擇正確的政策。每一欄的資訊都會說明政策的影響。
   + **可用性影響**：說明政策是否會佈建足夠的任務來處理工作負載，以避免對可用性造成負面影響 (相較於不使用該政策)。
   + **成本影響**：說明政策是否不會過度佈建任務，以避免對成本造成負面影響 (相較於不使用該政策)。如果過度佈建比較嚴重，服務就會出現使用率過低或閒置情況，這只會增加成本影響。

   如果您有多個政策，則以較低成本提供最多可用性優勢的政策名稱旁會顯示**最佳預測**標籤。可用性影響會獲得更多加權。

1. (選用) 若要選取建議結果所需的期間，請從**評估期間**下拉式清單中選擇您偏好的值：**2 天**、**1 週**或 **2 週**。根據預設，評估期間是最近兩週。較長的評估期間會為建議結果提供更多資料點。不過，如果負載模式發生變更 (例如在一段異常需求期間後)，新增更多資料點可能無法改善結果。在這種情況下，您可以查看最新資料以獲得更有針對性的建議。

**注意**  
只會針對處於**僅預測**模式的政策產生建議。當政策在整個評估期間都處於**僅預測**模式時，建議功能的效果會更好。如果您在**預測和擴展**模式中啟動政策，並於稍後將其切換至**僅預測**模式，則該政策的問題清單可能會有偏差。這是因為該政策已經為實際容量做出了貢獻。

## 檢閱預測擴展監控圖表
<a name="review-predictive-scaling-monitoring-graphs"></a>

在主控台中，您可以檢閱前幾天、前幾週或前幾個月的預測，以視覺化方式呈現政策在一段時間內的表現。在決定是否允許政策擴展實際任務數量時，您也可以使用這些資訊來評估預測的準確性。

**在 Amazon ECS 主控台中檢閱預測性擴展監控圖表**

1. 開啟主控台，網址為 [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)。

1. 在**叢集**頁面上，選擇叢集。

1. 在「叢集詳細資訊」頁面上的**服務**區段中，選擇所需服務。

   服務資訊頁面隨即顯示。

1. 選擇**服務自動擴展**。

1. 選擇預測性擴展政策，然後選擇**動作**、**預測性擴展**、**檢視圖表**。

1. 在**監控**區段中，您可以根據實際值檢視政策在過去和未來的負載和容量預測。**負載**圖表會顯示所選負載指標的負載預測與實際值。**容量**圖表會顯示政策預測的任務數量。它還包括實際啟動的任務數量。垂直線會將歷史值與未來預測隔開。建立政策後，這些圖表很快就可以使用。

1. (選用) 若要變更圖表中顯示的歷史資料量，請從頁面頂端的**評估期間**下拉式清單中選擇您偏好的值。評估期間不會以任何方式轉換此頁面上的資料。它只會變更顯示的歷史資料量。

**比較**負載**圖表中的資料**  
每條水平線代表每間隔一小時報告的一組不同資料點：

1. **實際觀察到的負載**會使用所選負載指標的 SUM 統計資料來顯示過去的每小時總負載。

1. **政策預測的負載**會顯示每小時的負載預測。此預測是基於前兩週的實際負載觀察結果。

**比較**容量**圖表中的資料**  
每條水平線代表每間隔一小時報告的一組不同資料點：

1. **實際觀察到的任務數量**會顯示 Amazon ECS 服務過去的實際容量，這取決於其他擴展政策與所選時段內有效的群組大小下限。

1. **政策預測的容量**會顯示政策處於**預測和擴展**模式時，可預期在每小時開始時獲得的基準容量。

1. **推斷的所需任務數量**會顯示服務中的理想任務數量，以將擴展指標維持在所選目標值。

1. **任務數量下限**會顯示服務中的任務數量下限。

1. **容量上限**會顯示服務中的任務數量上限。

為了計算推斷的所需容量，我們首先假設以指定的目標值平均使用每項任務。實際上，並不會平均使用任務數量。但是，假設使用率均勻地分佈在任務之間，我們就可以對所需容量進行可能的估算。然後，所需任務數量的計算結果會與用於預測性擴展政策的擴展指標成反比。換句話說，隨著任務數量增加，擴展指標會以相同的速率減少。例如，如果任務數量加倍，擴展指標必定會減半。

推斷的所需容量公式：

 `sum of (actualServiceUnits*scalingMetricValue)/(targetUtilization)`

例如，我們使用特定一小時的 `actualServiceUnits` (`10`) 和 `scalingMetricValue` (`30`)。然後，我們會使用您在預測擴展政策中指定的 `targetUtilization` (`60`)，並計算同一小時內推斷的所需容量。這會傳回值 `5`。這表示 5 是維持容量與擴展指標目標值正好成反比所需的推斷容量。

**注意**  
您可以使用各種控制桿來調整和改善應用程式的成本節省效益和可用性。  
您可以針對基準容量使用預測擴展，並使用動態擴展來處理額外的容量。動態擴展會與預測擴展分開運作，可根據目前的使用率進行縮減和擴增。首先，Amazon ECS 會為每個非排程擴展政策計算建議的任務數量。然後，它會根據提供最多任務數量的政策進行擴展。
為了在負載減少時允許進行縮減，服務應一律至少具有一個動態擴展政策，並啟用縮減部分。
您可以確保您的最小和最大容量沒有太大限制，以提高擴展效能。如果政策的建議任務數量不在容量下限與上限範圍內，將無法進行縮減與橫向擴充。

# 使用 CloudWatch 監控 Amazon ECS 的預測性擴展指標
<a name="predictive-scaling-monitoring"></a>

您可以使用 Amazon CloudWatch 監控資料以進行預測性擴展。預測性擴展政策會收集用於預測未來負載的資料。收集的資料會定期自動儲存在 CloudWatch 中，並可用於視覺化政策隨時間執行的表現。您還可以建立 CloudWatch 警示，以便在效能指標變更超出您定義的限制時通知您。

## 視覺化歷史預測資料
<a name="visualize-historical-forecast-data"></a>

您可以在 CloudWatch 中檢視預測性擴展政策的負載預測資料，這些資料有助於在單一圖表中根據其他 CloudWatch 指標視覺化預測。透過檢視更廣泛的時間範圍，還可以看到隨時間變化的趨勢。您可以存取長達 15 個月的歷史指標，以更加了解政策的執行狀況。

**使用 CloudWatch 主控台檢視歷史預測資料**

1. 透過 [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) 開啟 CloudWatch 主控台。

1. 在導覽窗格中，選擇 **Metrics** (指標)，然後選擇 **All metrics** (所有指標)。

1. 選擇**應用程式自動擴展**指標命名空間。

1. 選擇**預測性擴展負載預測**。

1. 在搜尋欄位中，輸入預測性擴展政策的名稱或者 Amazon ECS 服務群組的名稱，然後按 Enter 篩選結果。

1. 若要將指標圖形化，請勾選指標旁的核取方塊。若要變更圖形的名稱，請選擇鉛筆圖示。若要變更時間範圍，請選取一個預先定義的值，或選擇 **custom (自訂)**。如需詳細資訊，請參閱《Amazon CloudWatch 使用者指南》中的[建立指標圖表](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/graph_a_metric.html)。

1. 若要變更統計數字，請選擇 **Graphed metrics** (圖表化指標) 索引標籤。選擇欄位標題或個別的值，然後選擇不同的統計資料。儘管您可以為每個指標選擇任何統計資料，但並非所有統計資料都適用於 **PredictiveScalingLoadForecast** 指標。例如，**Average** (平均值)、**Minimum** (最小值) 和 **Maximum** (最大值) 統計資料有用，但是 **Sum** (總和) 統計資料無用。

1. 若要將其他指標新增到圖表，請在 **Browse** (瀏覽) 下，選擇 **All** (所有)，找到特定指標，然後選取旁邊的核取方塊。您最多可新增 10 個指標。

1. (選用) 若要將圖表新增至 CloudWatch 儀表板，請選擇 **Actions** (動作)、**Add to dashboard** (新增至儀表板)。

## 使用指標數學建立準確度指標
<a name="create-accuracy-metrics"></a>

利用指標數學，可查詢多個 CloudWatch 指標，並使用數學表達式根據這些指標來建立新的時間序列。您可以在 CloudWatch 主控台視覺化產生的時間序列，並將其新增至儀表板。如需有關指標數學的詳細資訊，請參閱《Amazon CloudWatch 使用者指南》中的[使用指標數學](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html)。

使用指標數學，您可以透過不同的方式繪製服務自動擴展功能為預測性擴展而產生的資料圖表。這可協助您監控一段時間內的政策績效，並協助您瞭解是否可以改善指標組合。

例如，您可以使用指標數學表達式來監控[平均絕對誤差百分比](https://en.wikipedia.org/wiki/Mean_absolute_percentage_error) (MAPE)。MAPE 指標有助於監控預測值與指定預測期間觀察到的實際值之間的差異。MAPE 值的變化可指示政策的績效是否隨著應用程式性質的變化在一段時間內而降低。MAPE 的增加表示預測值與實際值之間的差距更大。

**範例：指標數學表達式**

如果要開始使用此類圖表，您可以建立類似於以下範例中所示的指標數學表達式。



`MetricDataQueries` 有一個指標資料查詢結構陣列,而不是單一的指標。`MetricDataQueries` 中的每個項目都會取得指標或執行數學表達式。第一項，`e1`，是數學表達式。指定的表達式將 `ReturnData` 參數設定為 `true`，最終產生單一時間序列。對於所有其他指標，`ReturnData` 值為 `false`。

在此範例中，指定的表達式會使用實際值和預測值作為輸入值，並傳回新指標 (MAPE)。`m1` 是包含實際負載值的 CloudWatch 指標 (假設 CPU 使用率是針對名為 `my-predictive-scaling-policy` 的政策最初指定的負載指標)。`m2` 是包含預測負載值的 CloudWatch 指標。MAPE 指標的數學語法如下：

*Average of (abs ((Actual - Forecast)/(Actual)))*

### 視覺化您的準確度指標並設定警示
<a name="visualize-accuracy-metrics-set-alarms"></a>

若要視覺化準確度指標資料，請選取 CloudWatch 主控台中的 **Metrics** (指標) 索引標籤。您可以從那裡繪製資料圖表。如需詳細資訊，請參閱《Amazon CloudWatch 使用者指南》中的[將數學表達式新增到 CloudWatch 圖表](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html#adding-metrics-expression-console)。

您也可以在 **Metrics** (指標) 區段中，對您監控的指標設定警示。在 **Graphed metrics** (圖表化指標) 索引標籤上，選取 **Actions** (動作) 資料欄下的 **Create alarm** (建立警示) 圖示。**Create alarm** (建立警示) 圖示表示為一個小鐘。如需詳細資訊與通知選項，請參閱 *Amazon CloudWatch User Guide* 中的 [Creating a CloudWatch alarm based on a metric math expression](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create-alarm-on-metric-math-expression.html) 與 [Notifying users on alarm changes](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Notify_Users_Alarm_Changes.html)。

或者，您可以使用 [GetMetricData](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html) 和 [PutMetricAlarm](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_PutMetricAlarm.html) 利用指標數學來執行計算，並根據輸出建立警示。

# 使用排程動作覆寫 Amazon ECS 的預測值
<a name="predictive-scaling-overriding-forecast-capacity"></a>

有時候，您可能會有未來應用程式需求的其他資訊，但預測計算無法考量該資訊。例如，預測計算可能會低估即將到來的行銷活動所需的任務。您可以使用排程動作，在未來時段暫時覆寫預測。排程動作可以週期性執行，或在一次性需求波動的特定日期與時間執行。

例如，您可以建立任務數量高於預測值的排程動作。在執行時期，Amazon ECS 會更新服務中的任務數量下限。由於預測性擴展會針對任務數量進行最佳化，因此會接受任務數量下限高於預測值的排程動作。這可防止任務數量低於預期。若要停止複寫預測，請使用第二個排程動作，讓任務數量下限恢復至其原始設定。

下列程序概述在未來時段覆寫預測的步驟。

**Topics**
+ [步驟 1：(選用) 分析時間序列資料](#analyzing-time-series-data)
+ [步驟 2：建立兩個排程動作](#scheduling-capacity)

**重要**  
本主題假設您正嘗試覆寫預測，以擴展至高於預測值的容量。如果需要暫時減少任務數量，而不受預測性擴展政策的干擾，請改用*僅預測*模式。在僅預測模式下，預測性擴展將繼續產生預測，但不會自動增加任務數量。然後，您可以監控資源使用率，並視需要手動減少任務數量。

## 步驟 1：(選用) 分析時間序列資料
<a name="analyzing-time-series-data"></a>

從分析預測時間序列資料開始。這是選用步驟，但是如果您想要了解預測的詳細資訊，這會很有幫助。

1. **擷取預測**

   建立預測之後，您可以查詢預測中的特定時段。查詢的目標是取得特定時段的時間序列資料的完整檢視。

   查詢最多可包含未來兩天的預測資料。如果已經使用預測擴展一段時間，您也可以存取過去的預測資料。不過，開始和結束時間之間的最大持續時間是 30 天。

   若要使用 [get-predictive-scaling-forecast](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/get-predictive-scaling-forecast.html) AWS CLI 命令取得預測，請在 命令中提供下列參數：
   + 在 `resource-id` 參數中輸入叢集名稱。
   + 在 `--policy-name` 參數中輸入政策名稱。
   + 在 `--start-time` 參數中輸入開始時間，以便僅將指定時間之時或之後的預測資料傳回。
   + 在 `--end-time` 參數中輸入結束時間，以便僅將指定時間之前的預測資料傳回。

   ```
   aws application-autoscaling get-predictive-scaling-forecast \
       --service-namespace ecs \
       --resource-id service/MyCluster/test \
       --policy-name cpu40-predictive-scaling-policy \
       --scalable-dimension ecs:service:DesiredCount \
       --start-time "2021-05-19T17:00:00Z" \
       --end-time "2021-05-19T23:00:00Z"
   ```

   如果成功，此命令會傳回類似下方範例的資料。

   ```
   {
       "LoadForecast": [
           {
               "Timestamps": [
                   "2021-05-19T17:00:00+00:00",
                   "2021-05-19T18:00:00+00:00",
                   "2021-05-19T19:00:00+00:00",
                   "2021-05-19T20:00:00+00:00",
                   "2021-05-19T21:00:00+00:00",
                   "2021-05-19T22:00:00+00:00",
                   "2021-05-19T23:00:00+00:00"
               ],
               "Values": [
                   153.0655799339254,
                   128.8288551285919,
                   107.1179447150675,
                   197.3601844551528,
                   626.4039934516954,
                   596.9441277518481,
                   677.9675713779869
               ],
               "MetricSpecification": {
                   "TargetValue": 40.0,
                   "PredefinedMetricPairSpecification": {
                       "PredefinedMetricType": "ASGCPUUtilization"
                   }
               }
           }
       ],
       "CapacityForecast": {
           "Timestamps": [
               "2021-05-19T17:00:00+00:00",
               "2021-05-19T18:00:00+00:00",
               "2021-05-19T19:00:00+00:00",
               "2021-05-19T20:00:00+00:00",
               "2021-05-19T21:00:00+00:00",
               "2021-05-19T22:00:00+00:00",
               "2021-05-19T23:00:00+00:00"
           ],
           "Values": [
               2.0,
               2.0,
               2.0,
               2.0,
               4.0,
               4.0,
               4.0
           ]
       },
       "UpdateTime": "2021-05-19T01:52:50.118000+00:00"
   }
   ```

   回應包含兩種預測：`LoadForecast` 和 `CapacityForecast`。`LoadForecast` 顯示每小時負載預測。`CapacityForecast` 顯示每小時處理預測負載時所需的容量預測值，同時維持 `TargetValue` 為 40.0 (40% 的 CPU 平均使用率)。

1. **確定目標時段**

   確定應發生一次性需求波動時的一個小時或數個小時。請記住，預測中顯示的日期和時間為 UTC 格式。

## 步驟 2：建立兩個排程動作
<a name="scheduling-capacity"></a>

接下來，在應用程式具有高於預測的負載時，為特定時段建立兩個排程動作。舉例來說，如果行銷活動會在特定時段為網站帶來流量，您可以排程一次性動作，在它開始時更新最小容量。然後，排程另一個動作，以便在事件結束時將最小容量恢復至原始設定。

1. 開啟主控台，網址為 [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)。

1. 在**叢集**頁面上，選擇叢集。

1. 在「叢集詳細資訊」頁面上的**服務**區段中選擇服務。

   服務資訊頁面隨即顯示。

1. 選擇**服務自動擴展**。

   政策頁面隨即顯示。

1. 選擇**排程動作**，然後選擇**建立**。

   **建立排程動作**頁面隨即顯示。

1. 在**名稱**欄位中輸入唯一的名稱。

1. 對於 **Time zone** (時區)，選擇時區。

   所有列出的時區都來自 IANA 時區資料庫。如需詳細資訊，請參閱 [List of tz database time zones](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones)。

1. 在**開始時間**欄位中，輸入動作開始的**日期**與**時間**。

1. 針對 **Recurrence** (重複)，選擇 **Once** (一次)。

1. 在**任務調整**下的「下限」欄位中，輸入小於或等於任務數量上限的值。

1. 選擇**建立排程動作**。

   政策頁面隨即顯示。

1. 設定第二個排程動作，以便在事件結束時將任務數量下限恢復至原始設定。僅當為**下限**設定的值低於預測值時，預測性擴展才能擴展任務數量。

**為一次性事件建立兩個排程動作 (AWS CLI)**  
若要使用 AWS CLI 建立排程動作，請使用 [put-scheduled-update-group-action](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/put-scheduled-update-group-action.html) 命令。

例如，我們定義一個排程，在 5 月 19 日下午 5 點維持三個執行個體的最小容量，持續 8 小時。下列命令顯示如何實作此案例。

第一個 [put-scheduled-update-group-action](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/put-scheduled-update-group-action.html) 命令會指示 Amazon EC2 Auto Scaling 在 2021 年 5 月 19 日下午 5 點 (UTC) 更新 Auto Scaling 群組的最小容量。

```
aws autoscaling put-scheduled-update-group-action --scheduled-action-name my-event-start \
  --auto-scaling-group-name my-asg --start-time "2021-05-19T17:00:00Z" --minimum-capacity 3
```

第二個命令指示 Amazon EC2 Auto Scaling 在 2021 年 5 月 20 日上午 1 點 (UTC)，將群組的最小容量設定為 1。

```
aws autoscaling put-scheduled-update-group-action --scheduled-action-name my-event-end \
  --auto-scaling-group-name my-asg --start-time "2021-05-20T01:00:00Z" --minimum-capacity 1
```

再將這些排程動作新增到 Auto Scaling 群組後，Amazon EC2 Auto Scaling 會執行下列動作：
+ 在 2021 年 5 月 19 日下午 5 點 (UTC)，第一個排程動作會執行。如果群組目前擁有少於 3 個執行個體，群組則會擴增至 3 個執行個體。在此時間和接下來的八個小時內，如果預測容量高於實際容量，或者如果動態擴展政策生效，則 Amazon EC2 Auto Scaling 可以繼續擴增。
+ 在 2021 年 5 月 20 日上午 1 點 (UTC)，第二個排程動作會執行。這會在事件結束時將最小容量恢復至原始設定。

### 根據週期性排程擴展
<a name="scheduling-recurring-actions"></a>

若要每週覆寫相同時段的預測，請建立兩個排程動作，並使用 Cron 表達式提供時間與日期邏輯。

Cron 表達式格式由 5 個以空格分隔的欄位組成：[分鐘] [小時] [一個月的第幾日] [一年的第幾個月] [一週的第幾日]。欄位可以包含任何允許的數值，包括特殊字元。

例如，以下 Cron 表達式會在每周二上午 6:30 執行動作。使用星號作為萬用字元，以比對欄位的所有數值。

```
30 6 * * 2
```

### 另請參閱
<a name="scheduling-scaling-see-also"></a>

如需有關如何管理排程動作的的詳細資訊，請參閱[使用排程動作來擴展 Amazon ECS 服務](service-autoscaling-schedulescaling.md)。

# 使用自訂指標的 Amazon ECS 進階預測性擴展政策
<a name="predictive-scaling-custom-metrics"></a>

您可以在預測性擴展政策中使用預先定義或自訂的指標。當預先定義的指標 (例如 CPU、記憶體等) 不足以充分描述應用程式負載時，自訂指標會非常有用。

使用自訂指標建立預測性擴展政策時，您可以指定由 AWS提供的其他 CloudWatch 指標。或者，您也可以指定自行定義與發布的指標。您也可以使用指標數學來彙總現有指標，並將其轉換為 AWS 不會自動追蹤的新時間序列。例如，透過計算新的總和或平均值 (稱為*彙總*) 來合併資料中的值。產生的資料稱為*彙總*。

下一節包含如何建構政策的 JSON 結構的最佳實務和範例。

## 先決條件
<a name="predictive-scaling-custom-metrics-prerequisites"></a>

若要在預測擴展政策中新增自訂指標，您必須擁有 `cloudwatch:GetMetricData` 許可。

若要指定自己的指標，而不是 AWS 提供的指標，您必須先將指標發佈至 CloudWatch。如需詳細資訊，請參閱《Amazon CloudWatch 使用者指南》**中的[發佈自訂指標](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)。

如果您發佈自己的指標，應確保以至少五分鐘的頻率發佈資料點。系統會根據需要的時段長度從 CloudWatch 擷取資料點。例如，負載指標規範使用每小時指標來衡量應用程式的負載。CloudWatch 使用您發佈的指標資料，透過將時間戳記落於同一小時週期內的所有資料點彙總，為任何一小時週期提供單一資料值。

## 最佳實務
<a name="predictive-scaling-custom-metrics-best-practices"></a>

以下最佳實務可協助您更有效地使用自訂指標：
+ 對於負載指標規格，最實用的指標是以 Auto Scaling 群組作為整體來表示負載的指標。
+ 對於擴展指標規格，最實用的擴展指標是每項任務指標的平均輸送量或使用率。
+ 目標使用率必須與擴展指標的類型相符。例如，對於使用 CPU 使用率的政策組態，這是一個目標百分比。
+ 如果不遵循這些建議，則時間序列的預測未來值可能不正確。要驗證資料是否正確，您可以在 主控台中檢視預測值。或者，在建立預測性擴展政策後，檢查 [GetPredictiveScalingForecast](https://docs.aws.amazon.com/autoscaling/application/APIReference/API_GetPredictiveScalingForecast.html) API 呼叫傳回的 `LoadForecast` 物件。
+ 強烈建議在僅預測模式下設定預測性擴展，以便在預測性擴展開始主動擴展之前評估預測。

## 限制
<a name="predicitve-scaling-custom-metrics-limitations"></a>
+ 您可以在一個指標規範中查詢最多 10 個指標的資料點。
+ 在此限制之下，一個表達式計為一個指標。

## 對使用自訂指標的預測性擴展政策進行疑難排解
<a name="predictive-scaling-custom-metrics-troubleshooting"></a>

如果使用自訂指標時出現問題，建議您執行以下操作：
+ 如果您在使用搜尋表達式時在藍/綠部署中遇到問題，請確定所建立的搜尋表達式是在查找部分相符，而不是完全相符。此外，還應檢查查詢是否僅尋找在特定應用程式中執行的 Auto Scaling 群組。如需搜尋表達式語法的詳細資訊，請參閱《Amazon CloudWatch 使用者指南》**中的 [CloudWatch 搜尋表達式語法](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/search-expression-syntax.html)。
+ [put-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/put-scaling-policy.html) 命令會在您建立擴展政策時驗證表達式。但是，此命令可能無法識別偵測到之錯誤的確切原因。若要修正這些問題，請對您收到之 [get-metric-data](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/get-metric-data.html) 命令請求回應中的錯誤進行疑難排解。您也可以從 CloudWatch 主控台對表達式進行疑難排解。
+ 如果 `MetricDataQueries` 自己指定了 SEARCH() 函數 (在無需 SUM() 等數學函數的狀況下)，則您必須為 `ReturnData` 指定 `false`。這是因為搜尋表達式可能會傳回多個時間序列，並且基於表達式的指標規範只能傳回一個時間序列。
+ 搜尋表達式中涉及的所有指標均應具有相同的解析度。

# 透過 Amazon ECS 為預測性擴展自訂指標建構 JSON
<a name="predictive-scaling-custom-metrics-example"></a>

下一節包含如何設定預測擴展以查詢來自 CloudWatch 的資料的範例。設定此選項有兩種不同的方法，而您選擇的方法會影響您用來建構預測擴展政策的 JSON 的格式。使用指標數學時，JSON 的格式會根據所執行的指標數學而進一步變化。

1. 若要建立直接從 AWS 您發佈至 CloudWatch 的其他 CloudWatch 指標取得資料的政策，請參閱 [使用 搭配自訂負載和擴展指標的預測擴展政策範例 AWS CLI](#predictive-scaling-custom-metrics-example1)。

## 使用 搭配自訂負載和擴展指標的預測擴展政策範例 AWS CLI
<a name="predictive-scaling-custom-metrics-example1"></a>

若要使用 建立具有自訂負載和擴展指標的預測擴展政策 AWS CLI，請將 的引數存放在名為 `--predictive-scaling-configuration`的 JSON 檔案中`config.json`。

您可以藉由將以下範例中的可替換值換成您的指標和目標使用率的值，開始新增自訂指標。

```
{
  "MetricSpecifications": [
    {
      "TargetValue": 50,
      "CustomizedScalingMetricSpecification": {
        "MetricDataQueries": [
          {
            "Id": "scaling_metric",
            "MetricStat": {
              "Metric": {
                "MetricName": "MyUtilizationMetric",
                "Namespace": "MyNameSpace",
                "Dimensions": [
                  {
                    "Name": "MyOptionalMetricDimensionName",
                    "Value": "MyOptionalMetricDimensionValue"
                  }
                ]
              },
              "Stat": "Average"
            }
          }
        ]
      },
      "CustomizedLoadMetricSpecification": {
        "MetricDataQueries": [
          {
            "Id": "load_metric",
            "MetricStat": {
              "Metric": {
                "MetricName": "MyLoadMetric",
                "Namespace": "MyNameSpace",
                "Dimensions": [
                  {
                    "Name": "MyOptionalMetricDimensionName",
                    "Value": "MyOptionalMetricDimensionValue"
                  }
                ]
              },
              "Stat": "Sum"
            }
          }
        ]
      }
    }
  ]
}
```

如需詳細資訊，請參閱*《Amazon EC2 Auto Scaling API 參考》*中的 [MetricDataQuery](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_MetricDataQuery.html)。

**注意**  
以下是一些其他資源，可協助您尋找 CloudWatch 指標的指標名稱、命名空間、維度和統計資料：  
如需 AWS 服務可用指標的相關資訊，請參閱《Amazon [AWS CloudWatch 使用者指南》中的發佈 CloudWatch 指標](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/aws-services-cloudwatch-metrics.html)的 服務。 *Amazon CloudWatch *
若要使用 取得 CloudWatch 指標的確切指標名稱、命名空間和維度 （如適用） AWS CLI，請參閱 [list-metrics](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/list-metrics.html)。

若要建立此政策，執行使用 JSON 檔案作為輸入 [put-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/put-scaling-policy.html) 命令，如以下範例所示。

```
aws application-autoscaling put-scaling-policy --policy-name my-predictive-scaling-policy \
  --auto-scaling-group-name my-asg --policy-type PredictiveScaling \
  --predictive-scaling-configuration file://config.json
```

如果成功，此命令會傳回政策的 Amazon Resource Name (ARN)。

```
{
  "PolicyARN": "arn:aws:autoscaling:region:account-id:scalingPolicy:2f4f5048-d8a8-4d14-b13a-d1905620f345:autoScalingGroupName/my-asg:policyName/my-predictive-scaling-policy",
  "Alarms": []
}
```

# 使用指標數學表達式
<a name="predictive-scaling-math-expression"></a>

下一節將提供有關在政策中搭配預測性擴展政策使用指標數學的資訊。

## 了解指標數學
<a name="predictive-scaling-custom-metrics-math"></a>

如果您只想彙總現有指標資料，則 CloudWatch 指標數學可以節省將另一個指標發佈至 CloudWatch 的工作量和成本。您可以使用 AWS 提供的任何指標，也可以使用您在應用程式中定義的指標。

如需詳細資訊，請參閱《Amazon CloudWatch 使用者指南》**中的[使用指標數學](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html)。

如果選擇在預測擴展政策中使用指標數學表達式，則請考慮以下幾點：
+ 指標數學運算會使用指標名稱、命名空間和指標維度鍵/值對之唯一組合的資料點。
+ 您可以使用任何算術運算子 (\$1-\$1/^)、統計函數 (如 AVG 或 SUM) 或 CloudWatch 支援的其他函數。
+ 您可以在數學表達式的公式中同時使用其他數學表達式的指標和結果。
+ 您的指標數學表達式可以由不同的彙總組成。但是，最終彙總結果的最佳實務是將 `Average` 用於擴展指標，`Sum` 用於負載指標。
+ 在指標規範中使用的任何表達式都必須最終傳回單一的時間序列。

若要使用指標數學，請執行以下操作：
+ 選擇一或多個 CloudWatch 指標。然後，建立表達式。如需詳細資訊，請參閱《Amazon CloudWatch 使用者指南》**中的[使用指標數學](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html)。
+ 透過使用 CloudWatch 主控台或 CloudWatch [GetMetricData](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html) API 驗證指標數學表達式是否有效。

## 使用指標數學組合指標的預測擴展政策範例 (AWS CLI)
<a name="custom-metrics-ex2"></a>

有時，您可能需要首先以某種方式處理其資料，而不是直接指定指標。例如，您可能有一個從 Amazon SQS 佇列中提取工作的應用程式，並且您可能想要使用佇列中的項目數量作為預測擴展的條件。佇列中的訊息數量並不僅僅定義所需的執行個體數量。因此，需要更多的工作來建立可用於計算每個執行個體待處理項目的指標。

以下是此案例的預測擴展政策範例。它指定了基於 Amazon SQS `ApproximateNumberOfMessagesVisible` 指標的擴展和負載指標，即可從佇列中擷取的訊息數量。它還使用 Amazon EC2 Auto Scaling `GroupInServiceInstances` 指標和數學表達式來計算每個執行個體的待處理項目，以擴展指標。

```
aws application-autoscaling put-scaling-policy --policy-name my-sqs-custom-metrics-policy \
  --policy-type PredictiveScaling \
  --predictive-scaling-configuration file://config.json
  --service-namespace ecs \
  --resource-id service/MyCluster/test \
  "MetricSpecifications": [
    {
      "TargetValue": 100,
      "CustomizedScalingMetricSpecification": {
        "MetricDataQueries": [
          {
            "Label": "Get the queue size (the number of messages waiting to be processed)",
            "Id": "queue_size",
            "MetricStat": {
              "Metric": {
                "MetricName": "ApproximateNumberOfMessagesVisible",
                "Namespace": "AWS/SQS",
                "Dimensions": [
                  {
                    "Name": "QueueName",
                    "Value": "my-queue"
                  }
                ]
              },
              "Stat": "Sum"
            },
            "ReturnData": false
          },
          {
            "Label": "Get the group size (the number of running instances)",
            "Id": "running_capacity",
            "MetricStat": {
              "Metric": {
                "MetricName": "GroupInServiceInstances",
                "Namespace": "AWS/AutoScaling",
                "Dimensions": [
                  {
                    "Name": "AutoScalingGroupName",
                    "Value": "my-asg"
                  }
                ]
              },
              "Stat": "Sum"
            },
            "ReturnData": false
          },
          {
            "Label": "Calculate the backlog per instance",
            "Id": "scaling_metric",
            "Expression": "queue_size / running_capacity",
            "ReturnData": true
          }
        ]
      },
      "CustomizedLoadMetricSpecification": {
        "MetricDataQueries": [
          {
            "Id": "load_metric",
            "MetricStat": {
              "Metric": {
                "MetricName": "ApproximateNumberOfMessagesVisible",
                "Namespace": "AWS/SQS",
                "Dimensions": [
                  {
                    "Name": "QueueName",
                    "Value": "my-queue"
                  }
                ],
              },
              "Stat": "Sum"
            },
            "ReturnData": true
          }
        ]
      }
    }
  ]
}
```

該範例會傳回政策的 ARN。

```
{
  "PolicyARN": "arn:aws:autoscaling:region:account-id:scalingPolicy:2f4f5048-d8a8-4d14-b13a-d1905620f345:autoScalingGroupName/my-asg:policyName/my-sqs-custom-metrics-policy",
  "Alarms": []
}
```

# 互連 Amazon ECS 服務
<a name="interconnecting-services"></a>

在 Amazon ECS 任務中執行的應用程式通常需要接收來自網際網路的連線，或通常需要連線到在 Amazon ECS 服務中執行的其他應用程式。如果需要來自網際網路的外部連線，建議您使用 Elastic Load Balancing。如需有關整合負載平衡的詳細資訊，請參閱[使用負載平衡分佈 Amazon ECS 服務流量](service-load-balancing.md)。

如果您需要應用程式連線到在 Amazon ECS 服務中執行的其他應用程式，Amazon ECS 提供以下無需負載平衡器的方法：
+ *Amazon ECS Service Connect*

  建議使用 Service Connect，其可提供 Amazon ECS 組態，用於服務探索、連線與流量監控。透過 Service Connect，應用程式可以使用簡短名稱與標準連接埠，連線至同一叢集、其他叢集中的 Amazon ECS 服務，包括同一 AWS 區域內跨 VPC 的服務。

  當您使用 Service Connect 時，Amazon ECS 將管理服務探索的所有環節：建立可被探索的名稱、在任務啟動與停止時動態管理每個任務的項目、在每個已設定為可探索這些名稱的任務中執行代理程式。應用程式可透過 DNS 名稱的標準功能查詢這些名稱並建立連線。若應用程式已具備此能力，則您無需修改應用程式即可使用 Service Connect。

  您需在每個服務與任務定義內提供完整的組態。Amazon ECS 會在每次服務部署時管理此組態的變更，確保統一部署中的所有任務行為一致。例如，使用 DNS 作為服務探索機制時，常見問題在於遷移過程難以控制。若變更 DNS 名稱指向的新替代 IP 位址，可能需要等待最長 TTL 時間，所有用戶端才會開始使用新服務。而透過 Service Connect，用戶端部署會透過取代用戶端任務來更新組態。您可以設定部署斷路器及其他部署組態，使 Service Connect 的變更與任何其他部署一樣受到同等管控。

  如需詳細資訊，請參閱[使用 Service Connect 以利用簡稱連線 Amazon ECS 服務](service-connect.md)。
+ *Amazon ECS 服務探索*

  服務間通訊的另一種方法是使用服務探索進行直接通訊。透過此方法，您可使用 AWS Cloud Map 服務探索與 Amazon ECS 的整合功能。使用服務探索，Amazon ECS 會將啟動任務的清單同步至 AWS Cloud Map，這會維護 DNS 主機名稱，以解析該特定服務中一或多個任務的內部 IP 地址。Amazon VPC 中的其他服務可使用此 DNS 主機名稱，透過容器的內部 IP 位址直接向另一個容器傳送流量。

  這種服務間通訊方法的延遲較低。容器之間沒有額外的元件。流量會從一個容器直接傳送至另一個容器。

  此方法適用於採用 `awsvpc` 網路模式的場景，該模式下每個任務都有專屬的唯一 IP 位址。大多數軟體僅支援使用 DNS `A` 記錄，這些記錄會直接解析為 IP 位址。使用 `awsvpc` 網路模式時，每個任務的 IP 位址都是 `A` 記錄。不過，如果您使用 `bridge` 網路模式，多個容器可能會共用同一個 IP 位址。此外，動態連接埠映射會導致容器在該單一 IP 位址上隨機指派連接埠號碼。至此，僅靠 `A` 記錄已不足以滿足服務探索需求。您必須同時使用 `SRV` 記錄。這種類型的記錄可以追蹤 IP 位址與連接埠號碼，但要求對應用程式進行相應設定。您使用的某些預先建置的應用程式可能不支援 `SRV` 記錄。

  `awsvpc` 網路模式的另一項優勢，是每個服務都會擁有唯一的安全群組。您可以設定此安全群組，使其僅允許需要與該服務通訊的特定上游服務建立連入連線。

  使用服務探索實現服務間直接通訊的主要劣勢在於，您必須實作額外邏輯來處理重試機制與連線失敗問題。DNS 記錄具有存留時間 (TTL) 設定，可控制記錄的快取存留時長。DNS 記錄的更新與快取失效需要一定時間，才能讓應用程式取得最新版本的 DNS 記錄。因此，應用程式最終可能會將 DNS 記錄解析至已不存在的另一個容器。應用程式需要處理重試，並具有忽略不良後端的邏輯。

  如需詳細資訊，請參閱[使用服務探索以利用 DNS 名稱連接 Amazon ECS 服務](service-discovery.md)
+ *Amazon VPC Lattice*

  Amazon VPC Lattice 是一種受管應用程式聯網服務，Amazon ECS 客戶可用來觀察、保護和監控跨 AWS 運算服務、VPCs 和帳戶建置的應用程式，而無需修改其程式碼。

  VPC Lattice 使用目標群組，這是運算資源的集合。這些目標會執行您的應用程式或服務，可以是 Amazon EC2 執行個體、IP 地址、Lambda 函數和 Application Load Balancer。透過將其 Amazon ECS 服務與 VPC Lattice 目標群組建立關聯，客戶現在可以在 VPC Lattice 中將 Amazon ECS 任務啟用為 IP 目標。當已註冊服務的任務啟動時，Amazon ECS 會自動將任務註冊到 VPC Lattice 目標群組。

  如需詳細資訊，請參閱[使用 Amazon VPC Lattice 連接、觀察和保護您的 Amazon ECS 服務](ecs-vpc-lattice.md)。

## 網路模式相容性資料表
<a name="interconnect-network-mode-compatibility-table"></a>

下表說明這些選項與任務網路模式之間的相容性。在資料表中，「用戶端」是指從 Amazon ECS 任務內部建立連線的應用程式。


****  

| 互連線選項 | 橋接 | `awsvpc` | 主機 | 
| --- | --- | --- | --- | 
| 服務探索 | 是的，但用戶端需要知道在 DNS 中不含 hostPort 的 SRV 記錄。 | 是 | 是的，但用戶端需要知道在 DNS 中不含 hostPort 的 SRV 記錄。 | 
| Service Connect  | 是 | 是 | 否 | 
| VPC Lattice | 是 | 是 | 是 | 

# 使用 Service Connect 以利用簡稱連線 Amazon ECS 服務
<a name="service-connect"></a>

Amazon ECS Service Connect 提供服務對服務通訊的管理作為 Amazon ECS 組態。其會在 Amazon ECS 中同時建置服務探索和服務網格。這會提供：您透過服務部署管理的每個服務內的完整組態、統一參考未根據 VPC DNS 組態之命名空間內的服務的方式，以及可監控所有應用程式的標準化指標和日誌。Service Connect 僅讓服務互連。

下圖顯示 VPC 和 2 個服務中具有 2 個子網路的 Service Connect 網路範例。一種用戶端服務，在每個子網路中執行具有 1 項任務的 WordPress。一種伺服器服務，在每個子網路中執行具有 1 項任務的 MySQL。這兩種服務都具有高度可用性，並且對任務和可用區域問題具有彈性，因為每個服務都會執行分散在 2 個子網路上的多個任務。實心箭頭顯示從 WordPress 到 MySQL 的連線。例如，從具有 IP 地址 `172.31.16.1` 任務中的 WordPress 容器內執行的 `mysql --host=mysql` CLI 命令。該命令在 MySQL 預設連接埠上使用簡短名稱 `mysql`。此名稱和連接埠會在相同任務中連線至 Service Connect Proxy。WordPress 任務中的 Proxy 會在異常值偵測中使用循環配置負載平衡，以及任何先前的失敗資訊，以挑選要連接的 MySQL 任務。如圖中的實心箭頭所示，Proxy 連線至具 IP 地址 `172.31.16.2` MySQL 任務中的第二個 Proxy。在同一任務中，第二個 Proxy 連線至本機 MySQL 伺服器。這兩個 Proxy 都會回報在 Amazon ECS 和 Amazon CloudWatch 主控台中以圖形顯示的連線效能，讓您以相同的方式從各種應用程式取得效能指標。

![\[顯示最低 HA 服務的範例 Service Connect 網路\]](http://docs.aws.amazon.com/zh_tw/AmazonECS/latest/developerguide/images/serviceconnect.png)


以下術語會與 Service Connect 搭配使用。

**連接埠名稱**  
將名稱指派給特定連接埠映射的 Amazon ECS 任務定義組態。此組態僅供 Amazon ECS Service Connect 使用。

**用戶端別名**  
Amazon ECS 服務組態，用於指派端點中使用的連接埠號碼。此外，用戶端別名可以指派端點的 DNS 名稱，以覆寫探索名稱。如果 Amazon ECS 服務中未提供探索名稱，則用戶端別名會覆寫連接埠名稱作為端點名稱。如需端點範例，請參閱*端點*的定義。您可以將多個用戶端別名指派給 Amazon ECS 服務。此組態僅供 Amazon ECS Service Connect 使用。

**探索名稱**  
此為選用的中繼名稱，您可以從任務定義為指定的連接埠建立此名稱。此名稱用於建立 AWS Cloud Map 服務。如果未提供此名稱，則會使用任務定義中的連接埠名稱。您可以將多個探索名稱指派給 Amazon ECS 服務的特定連接埠。此組態僅供 Amazon ECS Service Connect 使用。  
AWS Cloud Map 服務名稱在命名空間中必須是唯一的。由於此限制，對於每個命名空間中的特定任務定義，如果未提供探索名稱，您只能有一個 Service Connect 組態。

**端點**  
連線到 API 或網站的 URL。URL 包含協定、DNS 名稱和連接埠。如需一般端點的更多資訊，請參閱 Amazon Web Services 一般參考內*AWS 詞彙表*中的[端點](https://docs.aws.amazon.com/glossary/latest/reference/glos-chap.html#endpoint)。  
Service Connect 可建立與 Amazon ECS 服務連線的端點，並將 Amazon ECS 服務中的任務設定為連線到端點。URL 包含協定、DNS 名稱和連接埠。您可以在任務定義中選取協定和連接埠名稱，因為連接埠必須比對容器映像內的應用程式。在服務中，您可以依名稱選取每個連接埠，並且可以指派 DNS 名稱。如果您未在 Amazon ECS 服務組態中指定 DNS 名稱，則會依預設使用任務定義中的連接埠名稱。例如，Service Connect 端點可以是 `http://blog:80`、`grpc://checkout:8080` 或 `http://_db.production.internal:99`。

**Service Connect 服務**  
Amazon ECS 服務中單一端點的組態。這是 Service Connect 組態的一部分，包含主控台中 **Service Connect and discovery name configuration** (Service Connect 和探索名稱組態) 中的單一列，或是 Amazon ECS 服務 JSON 組態內 `services` 清單中的某個物件。此組態僅供 Amazon ECS Service Connect 使用。  
如需詳細資訊，請參閱 Amazon Elastic Container Service API Reference (《Amazon Elastic Container Service API 參考》) 中的 [ServiceConnectService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ServiceConnectService.html)。

**命名空間**  
用於 Service Connect 之 AWS Cloud Map 命名空間的簡短名稱或完整 Amazon Resource Name (ARN)。命名空間必須與 Amazon ECS 服務和叢集位於相同的 AWS 區域 中。中的命名空間類型 AWS Cloud Map 不會影響 Service Connect。命名空間可以是與 中可用 AWS 帳戶 之 using AWS Resource Access Manager (AWS RAM) AWS RAM 共用 AWS 區域 的命名空間。如需有關共用命名空間的詳細資訊，請參閱 *AWS Cloud Map Developer Guide* 中的 [Cross-account AWS Cloud Map namespace sharing](https://docs.aws.amazon.com/cloud-map/latest/dg/sharing-namespaces.html)。  
Service Connect 使用 AWS Cloud Map 命名空間做為彼此通訊的 Amazon ECS 任務邏輯分組。每個 Amazon ECS 服務只能屬於一個命名空間。命名空間內的服務可以分佈到同一 AWS 區域內的不同 Amazon ECS 叢集。如果命名空間是共用命名空間，則服務可以分佈到命名空間擁有者與命名空間取用者 AWS 帳戶。您可以根據任何條件隨意組織服務。

**用戶端服務**  
執行網路用戶端應用程式的服務。此服務必須設定命名空間。服務中的每個任務都可以透過 Service Connect Proxy 容器探索，並連線到命名空間中的所有端點。  
如果任務中任何容器需要從命名空間中的服務連線到端點，請選擇用戶端服務。如果前端、反向 Proxy 或負載平衡器應用程式透過其他方法 (例如 Elastic Load Balancing) 接收外部流量，則可使用此類型的 Service Connect 組態。

**用戶端-伺服器服務**  
執行網路或 Web 服務應用程式的 Amazon ECS 服務。此服務必須具有命名空間，並且至少已設定一個端點。您可以使用端點連上服務中的每項任務。Service Connect Proxy 容器會接聽端點名稱和連接埠，以將流量引導至任務中的應用程式容器。  
如果有任何容器在連接埠上公開並接聽網路流量，請選擇用戶端-伺服器服務。這些應用程式不需要連線至同一命名空間中的其他用戶端-伺服器服務，但仍需設定用戶端組態。後端、中介軟體、業務層或大多數微服務都可以使用這種類型的 Service Connect 組態。如果您希望前端、反向 Proxy 或負載平衡器應用程式接收來自相同命名空間中使用 Service Connect 設定的其他服務流量，則這些服務應使用此類型的 Service Connect 組態。

Service Connect 功能會建立相關服務的虛擬網路。您可以跨多個不同的命名空間使用相同的服務組態，以執行獨立但相同的應用程式集合。Service Connect 會定義 Amazon ECS 服務中的 Proxy 容器。如此一來，您可以使用相同的任務定義，在具有不同 Service Connect 組態的不同命名空間中執行相同的應用程式。服務執行的每項任務都會在任務中執行代理容器。

Service Connect 適用於相同命名空間內 Amazon ECS 服務之間的連線。對於下列應用程式，您需要使用額外的互連線方法，才能連線到使用 Service Connect 設定的 Amazon ECS 服務：
+ 在其他命名空間中設定的任務
+ 未針對 Service Connect 設定的任務
+ Amazon ECS 以外的其他應用程式

這些應用程式可以透過 Service Connect Proxy 連線，但無法解析 Service Connect 端點名稱。

若要讓這些應用程式解析 Amazon ECS 任務的 IP 位址，則需使用其他互連方法。

**Topics**
+ [定價](#service-connect-pricing)
+ [Amazon ECS Service Connect 元件](service-connect-concepts-deploy.md)
+ [Amazon ECS Service Connect 組態概觀](service-connect-concepts.md)
+ [具有共用 AWS Cloud Map 命名空間的 Amazon ECS Service Connect](service-connect-shared-namespaces.md)
+ [Amazon ECS Service Connect 存取日誌](service-connect-envoy-access-logs.md)
+ [加密 Amazon ECS Service Connect 流量](service-connect-tls.md)
+ [使用 設定 Amazon ECS Service Connect AWS CLI](create-service-connect.md)

## 定價
<a name="service-connect-pricing"></a>
+ Amazon ECS Service Connect 定價取決於您使用 AWS Fargate 或 Amazon EC2 基礎設施來託管容器化工作負載。在 AWS Outposts上使用 Amazon ECS 時，定價直接採用與您使用 Amazon EC2 時所用的相同模型。如需詳細資訊，請參閱 [Amazon ECS 定價](https://aws.amazon.com/ecs/pricing)。
+ 使用 Amazon ECS Service Connect 無需額外付費。
+ Service Connect 使用 AWS Cloud Map 時，用量不收取額外費用。
+ 客戶需支付 Amazon ECS Service Connect 使用的運算資源費用，包括 vCPU 與記憶體。由於 Amazon ECS Service Connect 代理程式在客戶任務內執行，因此執行無需額外費用。任務資源會在客戶工作負載與 Amazon ECS Service Connect 代理程式之間共用。
+ 搭配 使用 Amazon ECS Service Connect 流量加密功能時 AWS 私有 CA，客戶會為他們建立的私有憑證授權機構和每個發行的 TLS 憑證付費。如需更多詳細資訊，請參閱 [AWS 私有憑證授權單位 定價](https://aws.amazon.com/private-ca/pricing/)。若要預估 TLS 憑證的每月成本，客戶需要知道已啟用 TLS 的 Amazon ECS 服務數量，將其乘以憑證成本，然後再乘以六。由於 Amazon ECS Service Connect 每五天自動輪換 TLS 憑證，因此每項 Amazon ECS 服務平均每月會發行六個憑證。

# Amazon ECS Service Connect 元件
<a name="service-connect-concepts-deploy"></a>

使用 Amazon ECS Service Connect 時，可以將每項 Amazon ECS 服務設定為執行接收網路請求 (用戶端-伺服器服務) 的伺服器應用程式，或執行發出請求的用戶端應用程式 (用戶端服務)。

當您準備開始使用 Service Connect 時，請先從用戶端-伺服器服務開始。您可以將 Service Connect 組態新增至新服務或現有服務。Amazon ECS 會在命名空間中建立 Service Connect 端點。此外，Amazon ECS 會在服務中建立新部署來取代目前正在執行的任務。

現有任務和其他應用程式可以繼續連線到現有端點和外部應用程式。如果用戶端-伺服器服務透過橫向擴充來新增任務，則將在所有任務之間對來自用戶端的新連線進行平衡。如果已更新用戶端-伺服器服務，則將在所有新版本的任務之間對來自用戶端的新連線進行平衡。

現有任務無法解析並連線到新端點。只有在同一命名空間中具有 Service Connect 組態且在此部署後開始執行的新任務，才能解析並連線至此端點。

這意味著用戶端應用程式的運算子會判斷其應用程式的組態何時變更，即使伺服器應用程式的運算子可以隨時變更其組態也是如此。每次部署命名空間中的任何服務後，命名空間中的端點清單都可能變更。現有任務與替代任務的行為會繼續保持與最近一次部署後相同的行為。

請考慮下列範例。

首先，假設您正在單一 AWS CloudFormation 範本和單一 CloudFormation 堆疊中建立公有網際網路可用的應用程式。公有探索和連線能力應由 建立 CloudFormation，包括前端用戶端服務。需要按照此順序建立該服務，以防止在一段時間內，前端用戶端服務正在執行並可公開使用，但後端用戶端服務不是。如此可避免在該期間向大眾傳送錯誤訊息。在 中 AWS CloudFormation，您必須使用 `dependsOn` 來指示多個 CloudFormation Amazon ECS 服務無法平行或同時進行。您應該為用戶端任務連線的每個後端用戶端-伺服器服務，將 `dependsOn` 新增至前端用戶端服務。

其次，假設前端服務存在，但沒有 Service Connect 組態。任務正在連線到現有的後端服務。請先使用 **DNS** 中或前端使用的 `clientAlias` 相同名稱，將用戶端-伺服器 Service Connect 組態新增至後端服務。這會建立新的部署，因此所有部署轉返偵測 AWS 管理主控台或 AWS SDKs AWS CLI和其他方法來轉返，並將後端服務還原至先前的部署和組態。如果您對後端服務的效能和行為感到滿意，請將用戶端或用戶端-伺服器 Service Connect 組態新增至前端服務。只有新部署中的任務會使用在這些新任務中新增的 Service Connect Proxy。如果此組態發生問題，您可以使用部署復原偵測或 AWS 管理主控台、 AWS CLI、 AWS SDKs和其他方法來復原和還原至先前的組態，並將後端服務還原至先前的部署和組態。如果您使用另一個以 DNS 為基礎的服務探索系統，而非 Service Connect，則任何前端或用戶端應用程式會在本機 DNS 快取到期後開始使用新端點和變更的端點組態，該過程通常需要數小時。

## 聯網
<a name="service-connect-concepts-network"></a>

依預設，Service Connect Proxy 會監聽任務定義連接埠映射中的 `containerPort`。安全群組規則必須允許來自用戶端將執行之子網路的傳入流量到達此連接埠。

即使您在 Service Connect 服務組態中設定連接埠號碼，也不會變更 Service Connect Proxy 所接聽用戶端-伺服器服務的連接埠。當您設定此連接埠號碼時，Amazon ECS 會在這些任務內的 Service Connect Proxy 上變更用戶端服務連線到其中的端點連接埠。用戶端服務中的 Proxy 會使用 `containerPort` 連線至用戶端-伺服器服務中的 Proxy。

如果您想要變更 Service Connect Proxy 接聽的連接埠，請變更用戶端-伺服器服務 Service Connect 組態中的 `ingressPortOverride`。如果變更此連接埠號碼，則必須允許此連接埠的傳入流量，此服務的流量會使用該連接埠。

應用程式傳送到針對 Service Connect 設定的 Amazon ECS 服務的流量，會要求 Amazon VPC 和子網路具有路由表規則和網路 ACL 規則，以允許您正在使用的 `containerPort` 和 `ingressPortOverride` 連接埠號碼。

 您可以使用 Service Connect 在 VPC 之間傳送流量。路由表規則、網路 ACL 與安全群組的相同需求適用於這兩種 VPC。

例如，兩個叢集會在不同的 VPC 中建立任務。每個叢集中的服務會設定為使用相同的命名空間。這兩個服務中的應用程式無需任何 VPC DNS 組態，即可解析命名空間中的每個端點。不過，除非 VPC 對等互連、VPC 或子網路路由表以及 VPC 網路 ACL 允許 `containerPort` 與 `ingressPortOverride` 連接埠號碼上的流量，否則 Proxy 無法連線。

對於使用 `bridge` 聯網模式的任務，您必須建立安全群組，其傳入規則需允許上層動態連接埠範圍的流量。然後，將該安全群組指派給 Service Connect 叢集中的所有 EC2 執行個體。

## Service Connect Proxy
<a name="service-connect-concepts-proxy"></a>

如果使用 Service Connect 組態建立或更新服務，Amazon ECS 會在每個新任務啟動時新增新的容器。這種使用單獨容器的模式稱為 `sidecar`。此容器在任務定義中不存在，您無法對其進行設定。Amazon ECS 會在服務中管理容器組態。因此，您可以在沒有 Service Connect 的情況下，於多項服務、命名空間與任務之間重複使用相同的任務定義。

**Proxy 資源**
+ 對於任務定義，必須設定 CPU 與記憶體參數。

  建議在 Service Connect Proxy 容器的任務 CPU 與記憶體中，額外新增 256 個 CPU 單元與至少 64 MiB 記憶體。在 AWS Fargate 上，您可以設定的最低記憶體容量為 512 MiB。在 Amazon EC2 上，任務定義記憶體是必要的。
+ 對於服務，您需要在 Service Connect 組態中進行日誌設定。
+ 如果您希望此服務中的任務在尖峰負載時每秒接收的請求數超過 500 個，建議在此 Service Connect Proxy 容器的任務定義中，將 512 個 CPU 單元新增至任務 CPU。
+ 如果您希望在命名空間中建立超過 100 個 Service Connect 服務，或在命名空間內所有 Amazon ECS 服務中建立總共 2000 個任務，建議在 Service Connect Proxy 容器的任務記憶體中新增 128 MiB 記憶體。您應該在命名空間中所有 Amazon ECS 服務使用的每個任務定義中執行此操作。

**代理組態**  
您的應用程式會以與應用程式所在的相同任務連線至附屬容器中的 Proxy。Amazon ECS 會設定任務與容器，以便應用程式僅在應用程式連線至同一命名空間中的端點名稱時才連線至 Proxy。所有其他流量都不會使用 Proxy。其他流量包含相同 VPC 中的 IP 地址、 AWS 服務端點和外部流量。

**Load balancing**  
服務連線會將 Proxy 設定為使用循環配置策略，在 Service Connect 端點中的任務之間進行負載平衡。位於連線來源任務中的本機 Proxy，會挑選提供端點之用戶端-伺服器服務中的其中一項任務。  
例如，假設在服務中執行 WordPress 的任務，該服務在名為*本機*的命名空間中設定為*用戶端服務*。有另一個包含具有執行 MySQL 資料庫 2 個任務的服務。此服務設定為在相同命名空間中透過 Service Connect 提供名為 `mysql` 的端點。在 WordPress 任務中，WordPress 應用程式使用端點名稱連線至資料庫。此名稱的連線會移至在相同任務的邊車容器中執行的 Proxy。然後，Proxy 可以使用循環配置策略連線至任一 MySQL 任務。  
負載平衡策略：循環配置

**異常值偵測**  
此功能會使用 Proxy 先前連線失敗的相關資料，以避免傳送新的連線至連線失敗的主機。Service Connect 會設定 Proxy 的異常值偵測功能，以提供被動運作狀態檢查。  
使用之前的範例，該 Proxy 可以連線至任一 MySQL 任務。如果 Proxy 與特定 MySQL 任務進行了多個連線，並且在過去的 30 秒內有 5 次以上的連線失敗，那麼 Proxy 會在 30 到 300 秒內避免該 MySQL 任務。

**重試**  
Service Connect 會將 Proxy 設定為重試透過 Proxy 傳遞且失敗的連線，而第二次嘗試則避免使用先前連線的主機。這可確保透過 Service Connect 的每個連線都不會因為一次性原因而失敗。  
重試次數：2

**Timeout (逾時)**  
Service Connect 會設定 Proxy 等待用戶端-伺服器應用程式回應的最長時間。預設逾時值為 15 秒，但可以更新。  
選用的參數：  
**idleTimeout** – 連線在閒置時保持作用中狀態的時間 (以秒為單位)。值為 `0` 會停用 `idleTimeout`。  
`HTTP`/`HTTP2`/`GRPC` 的 `idleTimeout` 預設值為 5 分鐘。  
`TCP` 的 `idleTimeout` 預設值為 1 小時。  
**perRequestTimeout** – 等待上游對每個請求發出完整回應的時間。值為 `0` 會關閉 `perRequestTimeout`。這僅能在應用程式容器的 `appProtocol` 為 `HTTP`/`HTTP2`/`GRPC` 時設定。預設值為 15 秒。  
如果 `idleTimeout` 設定為小於 `perRequestTimeout` 的時間，則連線將在達到 `idleTimeout` 而不是 `perRequestTimeout` 的時候關閉。

## 考量事項
<a name="service-connect-considerations"></a>

使用 Service Connect，請考量下列事項：
+ 在 Fargate 中執行的任務必須使用 Fargate Linux 平台版本 `1.4.0` 或更高版本，才能使用 Service Connect。
+ 容器執行個體上的 Amazon ECS 代理程式版本必須是 `1.67.2` 或更高版本。
+ 容器執行個體必須執行 Amazon ECS 最佳化 Amazon Linux 2023 AMI 版本 `20230428` 或更高版本，或 Amazon ECS 最佳化 Amazon Linux 2 AMI 版本 `2.0.20221115`，才能使用 Service Connect。除 Amazon ECS 容器代理程式外，這些版本也具有 Service Connect 代理程式。如需有關 Service Connect 代理程式的更多資訊，請參閱 GitHub 上的 [Amazon ECS Service Connect 代理程式](https://github.com/aws/amazon-ecs-service-connect-agent)。
+ 容器執行個體必須具有資源 `arn:aws:ecs:region:0123456789012:task-set/cluster/*` 的 `ecs:Poll` 許可。如果您使用的是 `ecsInstanceRole`，則不需要新增其他許可。`AmazonEC2ContainerServiceforEC2Role` 受管政策具有必要的許可。如需詳細資訊，請參閱[Amazon ECS 容器執行個體 IAM 角色](instance_IAM_role.md)。
+ 使用 `bridge` 網路模式且使用 Service Connect 的任務不支援 `hostname` 容器定義參數。
+ 任務定義必須設定任務記憶體限制，才能使用 Service Connect。如需詳細資訊，請參閱[Service Connect Proxy](#service-connect-concepts-proxy)。
+ 不支援設定容器記憶體限制的任務定義。

  您可以在容器上設定容器記憶體限制，但是您必須將任務記憶體限制設為大於容器記憶體限制總和的數字。任務限制中未在容器限制中配置的其他 CPU 和記憶體，會由 Service Connect Proxy 容器和其他未設定容器限制的容器使用。如需詳細資訊，請參閱[Service Connect Proxy](#service-connect-concepts-proxy)。
+ 您可以設定 Service Connect 在相同 區域中使用任何 AWS Cloud Map 命名空間，這些命名空間位於相同 或 AWS 帳戶 與您的 AWS 帳戶 共用 AWS Resource Access Manager。如需有關使用共用命名空間的詳細資訊，請參閱 [具有共用 AWS Cloud Map 命名空間的 Amazon ECS Service Connect](service-connect-shared-namespaces.md)。
+ 每一項服務只能屬於一個命名空間。
+ 僅支援服務建立的任務。
+ 所有端點在命名空間內必須不重複。
+ 所有探索名稱在命名空間內必須不重複。
+ 必須重新部署現有服務，應用程式才能解析新的端點。不會將最近部署後新增至命名空間的新端點新增至任務組態。如需詳細資訊，請參閱[Amazon ECS Service Connect 元件](#service-connect-concepts-deploy)。
+ 刪除叢集時，Service Connect 不會刪除命名空間。您必須在 中刪除命名空間 AWS Cloud Map。
+ Application Load Balancer 流量預設為在 `awsvpc` 網路模式下透過 Service Connect 代理程式進行路由。如果您希望非服務流量繞過 Service Connect 代理程式，請在 Service Connect 服務組態中使用 `[ingressPortOverride](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ServiceConnectService.html)` 參數。
+ 使用 TLS 的 Service Connect 不支援 `bridge` 聯網模式。僅支援 `awsvpc` 聯網模式。
+ 在 `awsvpc` 模式下，對於純 IPv4 與雙堆疊組態的服務，Service Connect Proxy 會將流量轉送至 IPv4 localhost `127.0.0.1`。對於純 IPv6 組態的服務，Proxy 會將流量轉送至 IPv6 localhost `::1`。建議將應用程式設定為監聽兩個 localhost，以便在服務從純 IPv4 或雙堆疊組態更新為純 IPv6 組態時實現無縫體驗。如需詳細資訊，請參閱[EC2 的 Amazon ECS 任務聯網選項](task-networking.md)及[Fargate 的 Amazon ECS 任務聯網選項](fargate-task-networking.md)。

**Service Connect 不支援下列項目：**
+ Windows 容器
+ HTTP 1.0
+ 獨立任務
+ 使用由 CodeDeploy 提供支援的藍/綠部署與外部部署類型的服務
+ Service Connect 不支援 Amazon ECS Anywhere 的 `External` 容器執行個體。
+ PPv2
+ FIPS 模式

# Amazon ECS Service Connect 組態概觀
<a name="service-connect-concepts"></a>

當您使用 Service Connect 時，需要在資源中設定參數。

下表說明了 Amazon ECS 資源的組態參數。


| 參數位置 | 應用程式類型 | Description | 必要 | 
| --- | --- | --- | --- | 
| 任務定義 | 用戶端 | 用戶端任務定義中的 Service Connect 沒有可用的變更。 | N/A | 
| 任務定義 | 用戶端-伺服器 | 伺服器必須將 name 欄位新增至容器 portMappings 中的連接埠。如需詳細資訊，請參閱[portMappings](task_definition_parameters.md#ContainerDefinition-portMappings) | 是 | 
| 任務定義 | 用戶端-伺服器 | 伺服器可以選擇性地提供應用程式協定 (例如 HTTP)，以接收其伺服器應用程式 (例如 HTTP 5xx) 的協定特定指標。 | 否 | 
| 服務定義 | 用戶端 | 用戶端服務必須新增 serviceConnectConfiguration，才能設定要加入的命名空間。此命名空間必須包含此服務需要探索的所有伺服器服務。如需詳細資訊，請參閱[serviceConnectConfiguration](service_definition_parameters.md#Service-serviceConnectConfiguration)。 | 是 | 
| 服務定義 | 用戶端-伺服器 | 伺服器服務必須新增 serviceConnectConfiguration，才能設定可從中使用服務的 DNS 名稱、連接埠號碼和命名空間。如需詳細資訊，請參閱[serviceConnectConfiguration](service_definition_parameters.md#Service-serviceConnectConfiguration)。 | 是 | 
| 叢集 | 用戶端 | 叢集可以新增預設的 Service Connect 命名空間。在服務中設定 Service Connect 時，叢集中的新服務會繼承命名空間。 | 否 | 
| 叢集 | 用戶端-伺服器 | 在套用至伺服器服務的叢集中，Service Connect 沒有可用的變更。伺服器任務定義和服務必須設定相應的組態。 | N/A | 

**Service Connect 的設定步驟概觀**  
下列步驟概述了如何設定 Service Connect。

**重要**  
 Service Connect 會在您的帳戶中建立 AWS Cloud Map 服務。透過手動註冊/取消註冊執行個體、變更執行個體屬性或刪除服務來修改這些 AWS Cloud Map 資源，可能會導致應用程式流量或後續部署產生非預期的行為。
 Service Connect 不支援任務定義中的連結。

1. 將連接埠名稱新增至任務定義中的連接埠對映。此外，您可以識別應用程式的第 7 層協定，以取得其他指標。

1. 建立具有 AWS Cloud Map 命名空間的叢集、使用共用命名空間，或分別建立命名空間。為簡化組織管理，請建立具有您所需命名空間名稱的叢集，並為該命名空間指定相同的名稱。在這種情況下，Amazon ECS 會使用必要的組態建立新的 HTTP 命名空間。Service Connect 不會使用或建立 Amazon Route 53 中的 DNS 託管區域。

1. 設定服務以在命名空間內建立 Service Connect 端點。

1. 部署服務以建立端點。Amazon ECS 會將 Service Connect Proxy 容器新增至每項任務，並在 AWS Cloud Map中建立 Service Connect 端點。此容器未在任務定義中設定，而且任務定義可以重複使用而不需要修改，以在相同的命名空間或多個命名空間中建立多個服務。

1. 將用戶端應用程式部署為服務，以連線到端點。Amazon ECS 會在每項任務中透過 Service Connect Proxy，將這些應用程式連線至 Service Connect 端點。

   應用程式僅使用 Proxy 來連線至 Service Connect 端點。沒有其他設定可使用 Proxy。Proxy 會執行循環配置負載平衡、異常值偵測和重試。如需 Proxy 的詳細資訊，請參閱 [Service Connect Proxy](service-connect-concepts-deploy.md#service-connect-concepts-proxy)。

1. 透過 Amazon CloudWatch 中的 Service Connect Proxy 監控流量。

## 叢集組態
<a name="service-connect-concepts-cluster-defaults"></a>

您可以在建立或更新叢集時為 Service Connect 設定預設命名空間。您指定為預設的命名空間名稱可以位於相同的 AWS 區域 和 帳戶中，也可以位於相同的 中 AWS 區域 ，並由另一個 AWS 帳戶 使用 共用 AWS Resource Access Manager。

如果您建立叢集並指定預設的 Service Connect 命名空間，則叢集會在 Amazon ECS 建立命名空間時在 `PROVISIONING` 狀態中等待。您可以看到 `attachment` 所處的叢集狀態顯示命名空間的狀態。根據預設，附件不會顯示在 中 AWS CLI，您必須新增 `--include ATTACHMENTS`才能查看。

如果您想要使用 與 AWS 帳戶 共用的命名空間 AWS RAM，請在叢集組態中指定命名空間的 Amazon Resource Name (ARN)。如需共用 AWS Cloud Map 命名空間的詳細資訊，請參閱 [具有共用 AWS Cloud Map 命名空間的 Amazon ECS Service Connect](service-connect-shared-namespaces.md)。

## 服務組態
<a name="service-connect-concepts-config"></a>

Service Connect 針對最低組態要求而設計。您必須為要在任務定義中與 Service Connect 搭配使用的每個連接埠映射設定名稱。在 服務中，您需要開啟 Service Connect，然後選取 中的命名空間 AWS 帳戶 或共用命名空間，以建立用戶端服務。若要建立用戶端-伺服器服務，您需要新增符合其中一個連接埠映射名稱的單一 Service Connect 服務組態。Amazon ECS 會重複使用任務定義中的連接埠號碼和連接埠名稱，以定義 Service Connect 服務和端點。若要覆寫這些值，您可以在主控台中使用 **Discovery** (探索)、**DNS** 和 **Port** (連接埠) 等其他參數，或分別在 Amazon ECS API 中使用 `discoveryName` 和 `clientAliases`。

## 初始運作狀態檢查組態
<a name="service-connect-concepts-health-check"></a>

Service Connect 可確保將流量路由至任務之前，任務的運作狀態良好。當任務啟動時 （在部署、擴展或取代期間），Service Connect 會監控任務的運作狀態，以確保已準備好接受流量。您必須定義任務定義中必要容器的運作狀態檢查，才能啟用此行為。

當任務準備好接受流量時，初始運作狀態檢查的行為會考量達到 狀態的潛在延遲：
+ 如果任務是 `HEALTHY`，則立即可供流量使用。
+ 如果任務的運作狀態為 `UNKNOWN`，則 Service Connect 會遵循任務基本容器的容器運作狀態檢查組態 （請參閱 [運作狀態檢查](task_definition_parameters.md#container_definition_healthcheck)) 來計算逾時，最多可達 `8 minutes`，再將其提供給流量使用，即使它仍為 `UNKNOWN`。
+ 如果任務是 `UNHEALTHY`，Amazon ECS 可能會啟動替代任務。如果沒有運作狀態良好的任務，您的部署可能會根據服務的組態復原。

對於所有持續的流量，Service Connect 會根據極端值偵測使用被動運作狀態檢查，以有效率地路由流量。

# 具有共用 AWS Cloud Map 命名空間的 Amazon ECS Service Connect
<a name="service-connect-shared-namespaces"></a>

Amazon ECS Service Connect 支援在同一 AWS 帳戶 內跨多個 使用共用 AWS Cloud Map 命名空間 AWS 區域。此功能可讓您建立分散式應用程式，其中在不同的 中執行的服務 AWS 帳戶 可以透過 Service Connect 彼此探索和通訊。共用命名空間使用 AWS Resource Access Manager (AWS RAM) 進行管理，允許安全的跨帳戶資源共用。如需共用命名空間的詳細資訊，請參閱《 *AWS Cloud Map 開發人員指南*》中的[跨帳戶 AWS Cloud Map 命名空間共用](https://docs.aws.amazon.com/cloud-map/latest/dg/sharing-namespaces.html)。

**重要**  
必須使用 `AWSRAMPermissionCloudMapECSFullPermission` 受管許可來共用命名空間，Service Connect 才能在命名空間正常運作。

當您搭配 Service Connect 使用共用 AWS Cloud Map 命名空間時，來自多個 的服務 AWS 帳戶 可以參與相同的服務命名空間。這對於具有多個 的組織特別有用 AWS 帳戶 ，這些組織需要維持跨帳戶邊界service-to-service通訊，同時保持安全和隔離。

**注意**  
若要與位於不同 VPC 中的服務通訊，您需要設定 VPC 間連線功能。這可以使用 VPC 對等互連來實現。如需詳細資訊，請參閱 *Amazon Virtual Private Cloud VPC Peering Guide* 中的 [Create or delete a VPC Peering connection](https://docs.aws.amazon.com/vpc/latest/peering/create-vpc-peering-connection.html)。

# 搭配 Amazon ECS Service Connect 使用共用 AWS Cloud Map 命名空間
<a name="service-connect-shared-namespaces-setup"></a>

設定 Service Connect 的共用 AWS Cloud Map 命名空間包含下列步驟：建立命名空間的命名空間擁有者、透過 AWS Resource Access Manager (AWS RAM) 共用的擁有者、接受資源共用的取用者，以及設定 Service Connect 使用共用命名空間的取用者。

## 步驟 1：建立 AWS Cloud Map 命名空間
<a name="service-connect-shared-namespaces-create"></a>

命名空間擁有者會建立將與其他 帳戶共用的 AWS Cloud Map 命名空間。

**使用 建立共用的命名空間 AWS 管理主控台**

1. 在 https：//[https://console.aws.amazon.com/cloudmap/](https://console.aws.amazon.com/cloudmap/) 開啟 AWS Cloud Map 主控台。

1. 選擇 **Create namespace (建立命名空間)**。

1. 輸入**命名空間名稱**。所有參與帳戶中的服務都會使用此名稱。

1. 在**命名空間類型**欄位中，根據使用案例選擇適當的類型：
   + **API 呼叫** – HTTP 命名空間，用於不使用 DNS 功能進行服務探索。
   + **VPC 中的 API 呼叫與 DNS 查詢** – 私有 DNS 命名空間，用於在 VPC 中使用私有 DNS 查詢進行服務探索。
   + **API 呼叫與公有 DNS 查詢** – 公有 DNS 命名空間，用於使用公有 DNS 查詢進行服務探索。

1.  選擇 **Create namespace (建立命名空間)**。

## 步驟 2：使用 共用命名空間 AWS RAM
<a name="service-connect-shared-namespaces-share"></a>

命名空間擁有者使用 與其他 AWS RAM 共用命名空間 AWS 帳戶。

**使用 AWS RAM 主控台共用命名空間**

1. 在 https：//[https://console.aws.amazon.com/ram/](https://console.aws.amazon.com/ram/) 開啟 AWS RAM 主控台。

1. 選擇 **Create resource share (建立資源共用)**。

1. 在**名稱**欄位中，輸入資源共用的描述性名稱。

1. 在**資源**區段中：

   1. 在**資源類型**欄位中，選擇 **Cloud Map 命名空間**。

   1. 選取您在前一步驟中建立的命名空間。

1. 在**受管許可**區段中，指定 **AWSRAMPermissionCloudMapECSFullPermission**。
**重要**  
必須使用 `AWSRAMPermissionCloudMapECSFullPermission` 受管許可來共用命名空間，Service Connect 才能在命名空間正常運作。

1. 在**主體**區段中，指定要與之共用命名空間的 AWS 帳戶 。您可以輸入帳戶 ID 或組織單位 ID。

1. 選擇 **Create resource share (建立資源共用)**。

## 步驟 3：接受資源共用
<a name="service-connect-shared-namespaces-accept"></a>

命名空間取用者帳戶必須接受資源共用邀請，才能使用共用命名空間。

**使用 AWS RAM 主控台接受資源共享邀請**

1. 在消費者帳戶中，開啟位於 https：//[https://console.aws.amazon.com/ram/](https://console.aws.amazon.com/ram/) 的 AWS RAM 主控台。

1. 在導覽窗格中，依次選擇**與我共用**、**資源共用**。

1. 選取資源共用邀請，然後選擇**接受資源共用**。

1. 接受後，請記下資源詳細資訊中的共用命名空間 ARN。設定 Service Connect 服務時，您將使用此 ARN。

## 步驟 4：使用共用命名空間設定 Amazon ECS 服務
<a name="service-connect-shared-namespaces-configure"></a>

接受共用命名空間後，命名空間取用者可以將 Amazon ECS 服務設定為使用共用命名空間。組態與使用一般命名空間類似，但您必須指定命名空間 ARN 而不是名稱。如需詳細的服務建立程序，請參閱[建立 Amazon ECS 滾動更新部署](create-service-console-v2.md)。

**使用 建立具有共用命名空間的服務 AWS 管理主控台**

1. 開啟主控台，網址為 [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)。

1. 在**叢集**頁面上，選擇要在其中建立服務的叢集。

1. 在**服務**下選擇**建立**。

1. 根據工作負載填入其他詳細資訊後，在 **Service Connect** 區段中，選擇**使用 Service Connect**。

1. 在**命名空間**欄位中，輸入共用命名空間的完整 ARN。

   ARN 格式為：`arn:aws:servicediscovery:region:account-id:namespace/namespace-id`

1. 視需要針對服務類型 (用戶端或用戶端-伺服器) 進行剩餘的 Service Connect 設定。

1. 完成服務建立程序。

您也可以使用 AWS CLI AWS SDKs設定服務，方法是在 的 `namespace` 參數中指定共用命名空間 ARN`serviceConnectConfiguration`。

```
aws ecs create-service \
    --cluster my-cluster \
    --service-name my-service \
    --task-definition my-task-def \
    --service-connect-configuration '{
        "enabled": true,
        "namespace": "arn:aws:servicediscovery:us-west-2:123456789012:namespace/ns-abcdef1234567890",
        "services": [{
            "portName": "web",
            "discoveryName": "my-service",
            "clientAliases": [{
                "port": 80,
                "dnsName": "my-service"
            }]
        }]
    }'
```

## 考量事項
<a name="service-connect-shared-namespaces-considerations"></a>

搭配 Service Connect 使用共用 AWS Cloud Map 命名空間時，請考慮下列事項：
+ AWS RAM 必須在 AWS 區域 您要使用共用命名空間的 中可用。
+ 共用命名空間必須與 AWS 區域 Amazon ECS 服務和叢集位於相同的 中。
+ 使用共用命名空間設定 Service Connect 時，必須使用命名空間 ARN，而不是 ID。
+ 支援所有命名空間類型：HTTP、私有 DNS 與公有 DNS 命名空間。
+ 如果撤銷共用命名空間的存取權，則需要與命名空間互動的 Amazon ECS 操作 (例如 `CreateService`、`UpdateService` 與 `ListServicesByNamespace`) 將會失敗。如需有關對共用命名空間許可問題進行疑難排解的詳細資訊，請參閱[使用共用 AWS Cloud Map 命名空間對 Amazon ECS Service Connect 進行故障診斷](service-connect-shared-namespaces-troubleshooting.md)。
+ 若在共用私有 DNS 命名空間中使用 DNS 查詢進行服務探索：
  + 命名空間擁有者需要呼叫 `create-vpc-association-authorization`，並指定與命名空間關聯的私有託管區域的 ID 以及取用者的 VPC。

    ```
    aws route53 create-vpc-association-authorization --hosted-zone-id Z1234567890ABC --vpc VPCRegion=us-east-1,VPCId=vpc-12345678
    ```
  + 命名空間取用者需要呼叫 `associate-vpc-with-hosted-zone`，並指定私有託管區域的 ID。

    ```
    aws route53 associate-vpc-with-hosted-zone --hosted-zone-id Z1234567890ABC --vpc VPCRegion=us-east-1,VPCId=vpc-12345678
    ```
+ 只有命名空間擁有者可以管理資源共用。
+ 命名空間取用者可以在共用命名空間內建立與管理服務，但無法修改命名空間本身。
+ 無論是哪個帳戶建立服務，探索名稱在共用命名空間內都必須是唯一的。
+ 共用命名空間中的服務可以探索和連線到其他可存取命名空間之 AWS 帳戶的 服務。
+ 為 Service Connect 啟用 TLS 並使用共用命名空間時， AWS 私有 CA 憑證認證機構 (CA) 的範圍僅限於該命名空間。撤銷共用命名空間的存取權時，CA 的存取權也會停止。
+ 使用共用命名空間時，命名空間擁有者和取用者預設無法存取跨帳戶 Amazon CloudWatch 指標。目標指標只會發佈至擁有用戶端服務的帳戶。擁有用戶端服務的帳戶無法存取擁有用戶端伺服器服務的帳戶接收的指標，反之亦然。若要允許跨帳戶存取指標，請設定 CloudWatch 跨帳戶可觀測性。如需設定跨帳戶可觀測性的詳細資訊，請參閱《Amazon [CloudWatch 使用者指南》中的 CloudWatch 跨帳戶可觀測性](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Unified-Cross-Account.html)。 *Amazon CloudWatch * 如需 Service Connect CloudWatch 指標的詳細資訊，請參閱 [Amazon ECS CloudWatch 指標](available-metrics.md)。

# 使用共用 AWS Cloud Map 命名空間對 Amazon ECS Service Connect 進行故障診斷
<a name="service-connect-shared-namespaces-troubleshooting"></a>

使用以下資訊對共用 AWS Cloud Map 命名空間和 Service Connect 的問題進行故障診斷。如需有關尋找錯誤訊息的詳細資訊，請參閱 [Amazon ECS 疑難排解](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/troubleshooting.html)。

因缺少許可或撤銷命名空間存取權，会顯示與許可問題相關的錯誤訊息。

**重要**  
必須使用 `AWSRAMPermissionCloudMapECSFullPermission` 受管許可來共用命名空間，Service Connect 才能在命名空間正常運作。

錯誤訊息會以下列其中一種格式顯示：

An error occurred (ClientException) when calling the <OperationName> operation: User: arn:aws:iam::<account-id>:user/<user-name> is not authorized to perform: <ActionName> on resource: <ResourceArn> because no resource-based policy allows the <ActionName> action

下列案例可能會導致此格式的錯誤訊息：

**叢集建立或更新失敗**  
當 Amazon ECS 操作如 `CreateCluster`或 因缺少 AWS Cloud Map 許可而`UpdateCluster`失敗時，就會發生這些問題。這些操作需要下列 AWS Cloud Map 動作的許可：  
+ `servicediscovery:GetNamespace`
確保取用者帳戶已接受資源共用邀請，且在 Service Connect 組態中使用了正確的命名空間 ARN。

**服務建立或更新失敗**  
當 Amazon ECS 操作如 `CreateService`或 因缺少 AWS Cloud Map 許可而`UpdateService`失敗時，就會發生這些問題。這些操作需要下列 AWS Cloud Map 動作的許可：  
+ `servicediscovery:CreateService`
+ `servicediscovery:GetNamespace`
+ `servicediscovery:GetOperation` (用於建立新的 AWS Cloud Map 服務)
+ `servicediscovery:GetService` (用於 AWS Cloud Map 服務已存在時)
確保取用者帳戶已接受資源共用邀請，且在 Service Connect 組態中使用了正確的命名空間 ARN。

**`ListServicesByNamespace` 操作失敗**  
當 Amazon ECS `ListServicesByNamespace` 操作失敗時，會發生此問題。此操作需要下列 AWS Cloud Map 動作的許可：  
+ `servicediscovery:GetNamespace`
若要解決此問題：  
+ 確認取用者帳戶具有 `servicediscovery:GetNamespace` 許可。
+ 呼叫 API 時使用命名空間 ARN，而不是名稱。
+ 確保資源共用處於作用中狀態，且已接受邀請。

User: <iam-user> is not authorized to perform: <ActionName> on resource: <ResourceArn> with an explicit deny in an identity-based policy.

下列案例可能會導致此格式的錯誤訊息：

**服務刪除失敗並停滯在 `DRAINING` 狀態**  
當 Amazon ECS `DeleteService` 操作因撤銷命名空間存取權而缺少 `servicediscovery:DeleteService` 許可時，會發生此問題。服務最初可能看起來已成功刪除，但會停滯在 `DRAINING` 狀態。錯誤訊息會顯示為 Amazon ECS 服務事件。  
若要解決此問題，命名空間擁有者必須與取用者帳戶共用命名空間，才能完成服務刪除。

**服務中的任務執行失敗**  
當任務因缺少許可而啟動失敗時，會發生此問題。錯誤訊息會顯示為已停止的任務錯誤。如需詳細資訊，請參閱[解決 Amazon ECS 已停止任務錯誤](resolve-stopped-errors.md)。  
執行任務需要下列 AWS Cloud Map 動作：  
+ `servicediscovery:GetOperation`
+ `servicediscovery:RegisterInstance`
確保取用者帳戶具有所需許可，並且可以存取共用命名空間。

**任務無法完全停止或停滯在 `DEACTIVATING` 或 `DEPROVISIONING` 狀態**  
當任務在關閉期間因為缺少許可而無法從 AWS Cloud Map 服務取消註冊時，就會發生此問題。錯誤會在任務附件中顯示為 `statusReason`，可使用 `DescribeTasks` API 擷取附件。如需詳細資訊，請參閱 *Amazon Elastic Container Service API Reference* 中的 [DescribeTasks](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DescribeTasks.html)。  
停止任務需要下列 AWS Cloud Map 動作：  
+ `servicediscovery:DeregisterInstance`
+ `servicediscovery:GetOperation`
如果撤銷共用命名空間存取權，任務可能會保持 `DEACTIVATING` 或 `DEPROVISIONING` 狀態，直到命名空間存取權還原。需請求命名空間擁有者還原命名空間的存取權。

# Amazon ECS Service Connect 存取日誌
<a name="service-connect-envoy-access-logs"></a>

Amazon ECS Service Connect 支援存取日誌，以提供 Service Connect Proxy 處理之個別請求的詳細遙測。存取日誌透過擷取每個請求流量中繼資料來補充現有的應用程式日誌，例如 HTTP 方法、路徑、回應碼、旗標和時間資訊。這可讓對請求層級流量模式和服務互動進行更深入的可觀測性，以有效地進行故障診斷和監控。

若要啟用存取日誌，請在 `serviceConnectConfiguration` 物件中指定 `logConfiguration`和 `accessLogConfiguration` 物件。您可以設定日誌的格式，以及日誌是否應該在 中包含查詢參數`accessLogConfiguration`。日誌會由 中指定的日誌驅動程式交付至目的地日誌群組`logConfiguration`。

```
{
    "serviceConnectConfiguration": {
        "enabled": true,
        "namespace": "myapp.namespace",
        "services": [
            ...
        ],
        "logConfiguration": {
            "logDriver": "awslogs",
            "options": {
                "awslogs-group": "my-envoy-log-group",
                "awslogs-region": "us-west-2",
                "awslogs-stream-prefix": "myapp-envoy-logs"
            }
        },
         "accessLogConfiguration": {
            "format": "TEXT",
            "includeQueryParameters": "ENABLED" 
        }
    }
}
```

## 考量事項
<a name="service-connect-envoy-access-logs-considerations"></a>

當您啟用存取日誌的存取權時，請考慮下列事項
+ 存取日誌和應用程式日誌都會寫入 `/dev/stdout`。若要將存取日誌與應用程式日誌分開，建議使用具有自訂Fluent Bit或Fluentd組態的`awsfirelens`日誌驅動程式。
+  建議使用 `awslogs` 日誌驅動程式將應用程式和存取日誌傳送至相同的 CloudWatch 目的地。
+ 使用平台版本 `1.4.0` 和更高版本的 Fargate 服務支援存取日誌。
+ 根據預設，請求 ID 和字符等查詢參數會從存取日誌中排除。若要在存取日誌中包含查詢參數，請將 `includeQueryParameters`設定為 `"ENABLED"`。

## 存取日誌格式
<a name="service-connect-envoy-access-logs-formats"></a>

存取日誌可以使用 JSON 格式字典或文字格式字串進行格式化，不同類型存取日誌的支援命令運算子不同。

### HTTP 存取日誌
<a name="service-connect-envoy-access-logs-formats-http"></a>

HTTP 日誌預設包含下列命令運算子：

------
#### [ Text ]

```
[%START_TIME%] "%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%"
%RESPONSE_CODE% %BYTES_RECEIVED% %BYTES_SENT% %DURATION%
%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)% "%REQ(X-FORWARDED-FOR)%" "%REQ(USER-AGENT)%"
"%REQ(X-REQUEST-ID)%" "%REQ(:AUTHORITY)%" "%UPSTREAM_HOST%"\n
```

------
#### [ JSON ]

```
{
  "start_time": "%START_TIME%",
  "method": "%REQ(:METHOD)%",
  "path": "%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%",
  "protocol": "%PROTOCOL%",
  "response_code": "%RESPONSE_CODE%",
  "bytes_received": "%BYTES_RECEIVED%",
  "bytes_sent": "%BYTES_SENT%",
  "duration_ms": "%DURATION%",
  "upstream_service_time": "%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%",
  "forwarded_for": "%REQ(X-FORWARDED-FOR)%",
  "user_agent": "%REQ(USER-AGENT)%",
  "request_id": "%REQ(X-REQUEST-ID)%",
  "authority": "%REQ(:AUTHORITY)%",
  "upstream_host": "%UPSTREAM_HOST%"
}
```

------

### HTTP2 存取日誌
<a name="service-connect-envoy-access-logs-formats-http2"></a>

除了 HTTP 日誌包含的命令運算子之外，HTTP2 日誌預設還包含 `%STREAM_ID%`運算子。

------
#### [ Text ]

```
[%START_TIME%] "%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%"
%RESPONSE_CODE% %BYTES_RECEIVED% %BYTES_SENT% %DURATION%
%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)% "%REQ(X-FORWARDED-FOR)%" "%REQ(USER-AGENT)%"
"%REQ(X-REQUEST-ID)%" "%REQ(:AUTHORITY)%" "%UPSTREAM_HOST%" "%STREAM_ID%"\n
```

------
#### [ JSON ]

```
{
  "start_time": "%START_TIME%",
  "method": "%REQ(:METHOD)%",
  "path": "%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%",
  "protocol": "%PROTOCOL%",
  "response_code": "%RESPONSE_CODE%",
  "bytes_received": "%BYTES_RECEIVED%",
  "bytes_sent": "%BYTES_SENT%",
  "duration": "%DURATION%",
  "upstream_service_time": "%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%",
  "forwarded_for": "%REQ(X-FORWARDED-FOR)%",
  "user_agent": "%REQ(USER-AGENT)%",
  "request_id": "%REQ(X-REQUEST-ID)%",
  "authority": "%REQ(:AUTHORITY)%",
  "upstream_host": "%UPSTREAM_HOST%",
  "stream_id": "%STREAM_ID%"
}
```

------

### gRPC 存取日誌
<a name="service-connect-envoy-access-logs-formats-grpc"></a>

除了 HTTP 日誌包含的命令運算子之外，gRPC 存取日誌預設還包含 `%STREAM_ID%`和 `%GRPC_STATUS()%`運算子。

------
#### [ Text ]

```
[%START_TIME%] "%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%"
%RESPONSE_CODE% %GRPC_STATUS()% %BYTES_RECEIVED% %BYTES_SENT% %DURATION%
%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)% "%REQ(X-FORWARDED-FOR)%" "%REQ(USER-AGENT)%"
"%REQ(X-REQUEST-ID)%" "%REQ(:AUTHORITY)%" "%UPSTREAM_HOST%" "%STREAM_ID%"\n
```

------
#### [ JSON ]

```
{
  "start_time": "%START_TIME%",
  "method": "%REQ(:METHOD)%",
  "path": "%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%",
  "protocol": "%PROTOCOL%",
  "response_code": "%RESPONSE_CODE%",
  "grpc_status": "%GRPC_STATUS()%",
  "bytes_received": "%BYTES_RECEIVED%",
  "bytes_sent": "%BYTES_SENT%",
  "duration": "%DURATION%",
  "upstream_service_time": "%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%",
  "forwarded_for": "%REQ(X-FORWARDED-FOR)%",
  "user_agent": "%REQ(USER-AGENT)%",
  "request_id": "%REQ(X-REQUEST-ID)%",
  "authority": "%REQ(:AUTHORITY)%",
  "upstream_host": "%UPSTREAM_HOST%",
  "stream_id": "%STREAM_ID%"
}
```

------

### TCP 存取日誌
<a name="service-connect-envoy-access-logs-formats-tcp"></a>

根據預設，TCP 存取日誌中會包含下列命令運算子：

------
#### [ Text ]

```
[%START_TIME%] %DOWNSTREAM_REMOTE_ADDRESS% %DOWNSTREAM_REMOTE_PORT% 
%BYTES_RECEIVED% %BYTES_SENT% %DURATION%  
%CONNECTION_TERMINATION_DETAILS% %CONNECTION_ID%\n
```

------
#### [ JSON ]

```
{
  "start_time": "%START_TIME%",
  "downstream_remote_address": "%DOWNSTREAM_REMOTE_ADDRESS%",
  "downstream_remote_port": "%DOWNSTREAM_REMOTE_PORT%",s
  "bytes_received": "%BYTES_RECEIVED%",
  "bytes_sent": "%BYTES_SENT%",
  "duration": "%DURATION%",
  "connection_termination_details": "%CONNECTION_TERMINATION_DETAILS%",
  "connection_id": %CONNECTION_ID%
}
```

------

如需這些命令運算子的詳細資訊，請參閱 Envoy 文件中的[命令運算](https://www.envoyproxy.io/docs/envoy/latest/configuration/observability/access_log/usage#command-operators)子。

# 啟用 Amazon ECS Service Connect 的存取日誌
<a name="service-connect-access-logs-configuration"></a>

使用 Service Connect 的 Amazon ECS 服務預設不會啟用存取日誌。您可以透過下列方式啟用存取日誌。

## 使用 啟用存取日誌 AWS CLI
<a name="service-connect-access-logs-configure-cli"></a>

下列命令顯示如何在建立服務`accessLogConfiguration`時指定 AWS CLI ，以使用 啟用 Amazon ECS 服務的存取日誌：

```
aws ecs create-service \
    --cluster my-cluster \
    --service-name my-service \
    --task-definition my-task-def \
    --service-connect-configuration '{
        "enabled": true,
        "namespace": "arn:aws:servicediscovery:us-west-2:123456789012:namespace/ns-abcdef1234567890",
        "services": [{
            "portName": "web",
            "discoveryName": "my-service",
            "clientAliases": [{
                "port": 80,
                "dnsName": "my-service"
            }]
        }],
        "logConfiguration": {
            "logDriver": "awslogs",
            "options": {
                "awslogs-group": "my-envoy-log-group",
                "awslogs-region": "us-west-2",
                "awslogs-stream-prefix": "myapp-envoy-logs"
            }
        },
         "accessLogConfiguration": {
            "format": "TEXT",
            "includeQueryParameters": "ENABLED" 
        }
    }'
```

## 使用主控台啟用存取日誌
<a name="service-connect-access-logs-configure-console"></a>

如需詳細的服務建立程序，請參閱[建立 Amazon ECS 滾動更新部署](create-service-console-v2.md)。

**使用 建立具有共用命名空間的服務 AWS 管理主控台**

1. 開啟主控台，網址為 [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)。

1. 在**叢集**頁面上，選擇要在其中建立服務的叢集。

1. 在**服務**下選擇**建立**。

1. 根據工作負載填入其他詳細資訊後，在 **Service Connect** 區段中，選擇**使用 Service Connect**。

1. 根據您的服務類型 （用戶端或用戶端伺服器） 視需要設定 Service Connect 設定。

1. 展開**存取日誌組態**。針對**格式**，選擇 **JSON** 或 `TEXT`。

1. 若要在存取日誌中包含查詢參數，請選取**包含查詢參數**。

1. 完成服務建立程序。

# 加密 Amazon ECS Service Connect 流量
<a name="service-connect-tls"></a>

Amazon ECS Service Connect 支援使用 Transport Layer Security (TLS) 憑證，為 Amazon ECS 服務自動加密流量。當您將 Amazon ECS 服務指向 [AWS 私有憑證授權單位 (AWS 私有 CA)](https://docs.aws.amazon.com/privateca/latest/userguide/PcaWelcome.html) 時，Amazon ECS 會自動佈建 TLS 憑證，以加密 Amazon ECS Service Connect 服務之間的流量。Amazon ECS 會產生、輪換與分發用於流量加密的 TLS 憑證。

Service Connect 的自動流量加密使用業界領先的加密功能來保護服務間通訊，協助您滿足安全需求。它支援使用 AWS 私有憑證授權單位 `256-bit ECDSA`和 `2048-bit RSA`加密的 TLS 憑證。您還可以完全控制私有憑證與簽署金鑰，協助您滿足合規需求。依預設，支援 TLS 1.3，但不支援 TLS 1.0 - 1.2。Service Connect 支援具有下列密碼的 TLS 1.3：
+ `TLS_AES_128_GCM_SHA256`
+ `TLS_AES_256_GCM_SHA384`
+ `TLS_CHACHA20_POLY1305_SHA256`

**注意**  
若要使用 TLS 1.3，必須在目標的接聽程式上將其啟用。  
只有透過 Amazon ECS 代理程式傳遞的傳入與傳出流量才會加密。

## Service Connect 與 Application Load Balancer 運作狀態檢查
<a name="service-connect-tls-alb-healthchecks"></a>

您可以搭配 Application Load Balancer 運作狀態檢查與 TLS 1.3 加密使用 Service Connect。

### Application Load Balancer 組態
<a name="service-connect-tls-alb-config"></a>

使用下列設定來設定 Application Load Balancer：
+ 使用 TLS 1.3 安全政策 (例如 `ELBSecurityPolicy-TLS13-1-2-2021-06`) 設定 TLS 接聽程式。如需詳細資訊，請參閱 [Security policies for your Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/describe-ssl-policies.html)。
+ 使用下列設定來建立目標群組：
  + 將通訊協定設定為 HTTPS
  + 將目標群組連接至 TLS 接聽程式
  + 將運作狀態檢查連接埠設定為符合 Service Connect 服務的容器連接埠需求

### Service Connect 組態
<a name="service-connect-tls-sc-config"></a>

使用下列設定來設定服務：
+ 將服務設定為使用 `awsvpc` 網路模式，因為不支援 `bridge` 網路模式。
+ 為服務啟用 Service Connect。
+ 使用下列設定來設定負載平衡器組態：
  + 指定為 Application Load Balancer 設定的目標群組
  + 將容器連接埠設定為符合 Service Connect TLS 服務的容器連接埠需求
+ 避免為服務設定 `ingressPortOverride`。如需詳細資訊，請參閱 *Amazon Elastic Container Service API Reference* 中的 [ServiceConnectService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ServiceConnectService.html)。

### 考量事項
<a name="service-connect-tls-alb-considerations"></a>

使用 Application Load Balancer、TLS 與 Service Connect 時，請考量下列事項：
+ 搭配 TLS 加密使用 Service Connect 時，需使用 `awsvpc` 網路模式 (而不是 `bridge` 網路模式) 進行 HTTPS 運作狀態檢查。HTTP 運作狀態檢查將繼續使用 `bridge` 模式。
+ 將目標群組運作狀態檢查連接埠設定為符合 Service Connect 服務的容器連接埠 (而不是預設的 HTTPS 連接埠 (443)) 需求。

## AWS 私有憑證授權單位 憑證和 Service Connect
<a name="service-connect-tls-certificates"></a>

您需要擁有基礎結構 IAM 角色。如需有關此角色的詳細資訊，請參閱 [Amazon ECS 基礎結構 IAM 角色](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/infrastructure_IAM_role.html                     )。

**AWS 私有憑證授權單位 適用於 Service Connect 的 模式**

AWS 私有憑證授權單位 可以兩種模式執行：一般用途和短期。
+ 一般用途 – 可設定任何過期日期的憑證。
+ 短期 – 有效性上限為七天的憑證。

儘管 Amazon ECS 支援這兩種模式，但建議使用短期憑證。依預設，憑證每五天輪換一次，相較於一般用途模式，在短期模式下執行可大幅節省成本。

Service Connect 不支援撤銷憑證，而是改為利用會頻繁輪換的短期憑證。您有權使用 [Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) 中的[受管輪換](https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotate-secrets_managed.html)來修改輪換頻率、停用或刪除秘密，但這樣做可能會產生下列後果。
+ 較短的輪換頻率 - 由於 AWS KMS Secrets Manager AWS 私有 CA和 Auto Scaling 的輪換工作負載增加，較短的輪換頻率會產生更高的成本。
+ 較長的輪換頻率 – 如果輪換頻率超過**七天**，應用程式通訊將會失敗。
+ 刪除秘密 – 刪除秘密會導致輪換失敗並影響客戶應用程式通訊。

如果秘密輪換失敗，會在 [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html) 中發布 `RotationFailed` 事件。您還可以為 `RotationFailed` 設定 [CloudWatch 警示](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)。

**重要**  
請勿將複本區域新增至秘密。這樣做會阻止 Amazon ECS 刪除秘密，因為 Amazon ECS 沒有從複寫中移除區域的許可。若已新增複寫，請執行下列命令。  

```
aws secretsmanager remove-regions-from-replication \
 --secret-id SecretId \
 --remove-replica-regions region-name
```

**次級憑證授權機構**  
您可以將任何 AWS 私有 CA根憑證或次級憑證帶到 Service Connect TLS，以發行服務的終端實體憑證。提供的發行者會視為各地的簽署者與信任根。您可以從不同的次級 CA 為應用程式的不同部分發行終端實體憑證。使用 時 AWS CLI，請提供 CA 的 Amazon Resource Name (ARN) 來建立信任鏈。

**內部部署憑證授權機構**  
若要使用內部部署 CA，需要在 AWS 私有憑證授權單位中建立與設定次級 CA。這可確保為 Amazon ECS 工作負載發行的所有 TLS 憑證與在內部部署執行的工作負載共用信任鏈，並且能夠安全地連線。

**重要**  
在 `AmazonECSManaged : true`中新增**必要的**標籤 AWS 私有 CA。

**基礎設施即程式碼**  
搭配基礎結構即程式碼 (IaC) 工具使用 Service Connect TLS 時，務必正確設定相依性以避免問題，例如服務停滯在耗盡狀態。如果 AWS KMS 提供金鑰，則應在 Amazon ECS 服務之後刪除 IAM 角色和 AWS 私有 CA 相依性。

如果用於 Service Connect 的命名空間是共用命名空間，您可以選擇使用共用 AWS 私有 CA 資源。如需詳細資訊，請參閱 *AWS 私有憑證授權單位 User Guide* 中的 [Attach a policy for cross-account access](https://docs.aws.amazon.com/privateca/latest/userguide/pca-ram.html)。

## Service Connect 與 Secrets Manager
<a name="service-connect-asm"></a>

**搭配 TLS 加密使用 Amazon ECS Service Connect 時，服務會透過下列方式與 Secrets Manager 互動：**  
Service Connect 會利用提供的基礎結構角色，在 Secrets Manager 中建立秘密。這些秘密用於儲存 TLS 憑證的關聯私有金鑰，以加密 Service Connect 服務之間的流量。

**警告**  
Service Connect 會自動建立與管理這些秘密，從而簡化為服務實作 TLS 加密的程序。但是，務必注意潛在的安全隱患。具有 Secrets Manager 讀取存取權的其他 IAM 角色可能可以存取這些自動建立的秘密。如果未正確設定存取控制，這可能會向未經授權的一方公開敏感的加密資料。  
若要降低此風險，請遵循下列最佳實務：  
小心管理與限制 Secrets Manager 存取權，尤其是 Service Connect 建立的秘密。
定期稽核 IAM 角色及其許可，確保遵循最低權限原則。

授予 Secrets Manager 讀取存取權時，請考慮排除 Service Connect 建立的 TLS 私有金鑰。為此，您可以透過在 IAM 政策中使用條件，來排除具備符合下列模式之 ARN 的秘密：

```
"arn:aws:secretsmanager:::secret:ecs-sc!"
```

以下是一個 IAM 政策範例，該政策拒絕對所有以 `GetSecretValue` 為字首的秘密執行 `ecs-sc!` 動作：

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Deny",
            "Action": "secretsmanager:GetSecretValue",
            "Resource": "arn:aws:secretsmanager:*:*:secret:ecs-sc!*"
        }
    ]
}
```

------

**注意**  
這是一般範例，可能需要根據您的特定使用案例和 AWS 帳戶組態進行調整。務必全面測試 IAM 政策，確保它們在維護安全性的同時提供預期的存取權。

透過了解 Service Connect 如何與 Secrets Manager 互動，您可以更好地管理 Amazon ECS 服務的安全性，同時利用自動 TLS 加密的優勢。

## Service Connect 和 AWS Key Management Service
<a name="service-connect-kms"></a>

您可以使用 [AWS Key Management Service](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html) 來加密和解密 Service Connect 資源。 AWS KMS 是一項由 管理的服務，您可以在 AWS 其中建立和管理加密金鑰來保護您的資料。

 AWS KMS 搭配 Service Connect 使用 時，您可以選擇使用 AWS 為您 AWS 管理的 擁有金鑰，也可以選擇現有的 AWS KMS 金鑰。您也可以[建立要使用的新 AWS KMS 金鑰](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html#create-symmetric-cmk)。

**提供自己的加密金鑰**  
您可以提供自己的金鑰材料，也可以透過將自己的金鑰 AWS Key Management Service 匯入 來使用外部金鑰存放區 AWS KMS，然後在 Amazon ECS Service Connect 中指定該金鑰的 Amazon Resource Name (ARN)。

以下是範例 AWS KMS 政策。將 *user-input* 值取代實際值。

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Sid": "id",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111122223333:role/role-name"
      },
      "Action": [
        "kms:Encrypt",
        "kms:Decrypt",
        "kms:GenerateDataKey",
        "kms:GenerateDataKeyPair"
      ],
      "Resource": "*"
    }
  ]
}
```

------

如需有關金鑰政策的詳細資訊，請參閱 *AWS Key Management Service Developer Guide* 中的 [Creating a key policy](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-overview.html)。

**注意**  
Service Connect 僅支援對稱加密 AWS KMS 金鑰。您無法使用任何其他類型的 AWS KMS 金鑰來加密 Service Connect 資源。如需判斷 AWS KMS 金鑰是否為對稱加密金鑰的說明，請參閱[識別非對稱 KMS 金鑰](https://docs.aws.amazon.com/kms/latest/developerguide/identify-key-types.html#identify-asymm-keys)。

如需 AWS Key Management Service 對稱加密金鑰的詳細資訊，請參閱《 *AWS Key Management Service 開發人員指南*》中的[對稱加密 AWS KMS 金鑰](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#symmetric-cmks)。

# 為 Amazon ECS Service Connect 啟用 TLS
<a name="enable-service-connect-tls"></a>

您可以在建立或更新 Service Connect 服務時啟用流量加密。

**使用 啟用現有命名空間中服務的流量加密 AWS 管理主控台**

1. 您需要擁有基礎結構 IAM 角色。如需有關此角色的詳細資訊，請參閱 [Amazon ECS 基礎結構 IAM 角色](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/infrastructure_IAM_role.html                     )。

1. 開啟主控台，網址為 [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)。

1. 在導覽窗格中，選擇 **Namespaces (命名空間)**。

1. 選擇要為其啟用流量加密之**服務**所在的**命名空間**。

1. 選擇要啟用流量加密的**服務**。

1. 選擇右上角的**更新服務**，然後向下捲動至「Service Connect」區段。

1. 在服務資訊下方，選擇**開啟流量加密**以啟用 TLS。

1. 在 **Service Connect TLS 角色**欄位中，選擇現有的基礎結構 IAM 角色或建立一個新角色。

1. 在**簽署者憑證授權機構**欄位中，選擇現有的憑證授權機構或建立一個新的憑證授權機構。

   如需詳細資訊，請參閱[AWS 私有憑證授權單位 憑證和 Service Connect](service-connect-tls.md#service-connect-tls-certificates)。

1. 針對**選擇 AWS KMS key**，選擇 AWS 擁有和管理的金鑰，或者您可以選擇不同的金鑰。您也可以選擇建立一個新金輪。

如需使用 AWS CLI 為您的服務設定 TLS 的範例，請參閱[使用 設定 Amazon ECS Service Connect AWS CLI](create-service-connect.md)。

# 驗證 Amazon ECS Service Connect 是否啟用 TLS
<a name="verify-tls-enabled"></a>

Service Connect 會在 Service Connect 代理程式啟動 TLS，並在目的地代理程式將其終止。因此，應用程式程式碼絕不會看到 TLS 互動。使用下列步驟來驗證 TLS 是否已啟用。

1. 在應用程式映像中包含 `openssl` CLI。

1. 在服務上啟用 [ECS Exec](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-exec.html)，以透過 SSM 連線至任務。或者，您也可以在與服務相同的 Amazon VPC 中啟動 Amazon EC2 執行個體。

1. 從要驗證的服務中擷取任務的 IP 與連接埠。您可以在 AWS Cloud Map 主控台中擷取任務 IP 地址。該資訊位於命名空間的服務詳細資訊頁面上。

1. 使用 `execute-command` 登入任何任務，如下列範例所示。或者，登入在**步驟 2** 中建立的 Amazon EC2 執行個體。

   ```
   $ aws ecs execute-command --cluster cluster-name \
       --task task-id  \
       --container container-name \
       --interactive \
       --command "/bin/sh"
   ```
**注意**  
直接呼叫 DNS 名稱不會顯示憑證。

1. 在已連線的 Shell 中，使用 `openssl` CLI 來驗證與檢視連接至任務的憑證。

   範例：

   ```
   openssl s_client -connect 10.0.147.43:6379 < /dev/null 2> /dev/null \ 
   | openssl x509 -noout -text
   ```

   回應範例：

   ```
   Certificate:
       Data:
           Version: 3 (0x2)
           Serial Number:
               <serial-number>
           Signature Algorithm: ecdsa-with-SHA256
           Issuer: <issuer>
           Validity
               Not Before: Jan 23 21:38:12 2024 GMT
               Not After : Jan 30 22:38:12 2024 GMT
           Subject: <subject>
           Subject Public Key Info:
               Public Key Algorithm: id-ecPublicKey
                   Public-Key: (256 bit)
                   pub:
                       <pub>
                   ASN1 OID: prime256v1
                   NIST CURVE: P-256
           X509v3 extensions:
               X509v3 Subject Alternative Name:
                   DNS:redis.yelb-cftc
               X509v3 Basic Constraints:
                   CA:FALSE
               X509v3 Authority Key Identifier:
                   keyid:<key-id>
   
               X509v3 Subject Key Identifier:
                   1D:<id>
               X509v3 Key Usage: critical
                   Digital Signature, Key Encipherment
               X509v3 Extended Key Usage:
                   TLS Web Server Authentication, TLS Web Client Authentication
       Signature Algorithm: ecdsa-with-SHA256
           <hash>
   ```

# 使用 設定 Amazon ECS Service Connect AWS CLI
<a name="create-service-connect"></a>

您可以搭配 AWS CLI使用 Service Connect，來建立包含 Fargate 任務的 Amazon ECS 服務。

**注意**  
您可以使用雙堆疊服務端點，透過 IPv4 和 IPv6 AWS CLI從 、 SDKs 和 Amazon ECS API 與 Amazon ECS 互動。如需詳細資訊，請參閱[使用 Amazon ECS 雙堆疊端點](dual-stack-endpoint.md)。

## 先決條件
<a name="create-service-connect-prereqs"></a>

下列是使用 Service Connect 的先決條件：
+ 確認 AWS CLI 已安裝並設定最新版本的 。如需詳細資訊，請參閱 [Installing or updating to the latest version of the AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)。
+ 您的 IAM 使用者擁有 [AmazonECS\$1FullAccess](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonECS_FullAccess) IAM 政策範例中指定的所需許可。
+ 您已建立要使用的 VPC、子網路、路由表和安全群組。如需詳細資訊，請參閱[建立 Virtual Private Cloud](get-set-up-for-amazon-ecs.md#create-a-vpc)。
+ 您具有名為 `ecsTaskExecutionRole` 的任務執行角色，且 `AmazonECSTaskExecutionRolePolicy` 受管政策已附加至該角色。此角色允許 Fargate 將 NGINX 應用程式日誌和 Service Connect Proxy 日誌寫入 Amazon CloudWatch Logs。如需詳細資訊，請參閱[建立任務執行角色](task_execution_IAM_role.md#create-task-execution-role)。

## 步驟 1：建立叢集
<a name="create-service-connect-cluster"></a>

使用下列步驟建立 Amazon ECS 叢集和命名空間。

**建立 Amazon ECS 叢集和 AWS Cloud Map 命名空間**

1. 建立要使用的名為 `tutorial` 的 Amazon ECS 叢集。參數 `--service-connect-defaults` 會設定叢集的預設命名空間。在範例輸出中，名稱的 AWS Cloud Map 命名空間`service-connect`不存在於此帳戶中 AWS 區域，因此命名空間是由 Amazon ECS 建立。該命名空間是在帳戶的 AWS Cloud Map 中建立，並且對所有其他命名空間都可見，因此請使用可指示此用途的名稱。

   ```
   aws ecs create-cluster --cluster-name tutorial --service-connect-defaults namespace=service-connect
   ```

   輸出：

   ```
   {
       "cluster": {
           "clusterArn": "arn:aws:ecs:us-west-2:123456789012:cluster/tutorial",
           "clusterName": "tutorial",
           "serviceConnectDefaults": {
               "namespace": "arn:aws:servicediscovery:us-west-2:123456789012:namespace/ns-EXAMPLE"
           },
           "status": "PROVISIONING",
           "registeredContainerInstancesCount": 0,
           "runningTasksCount": 0,
           "pendingTasksCount": 0,
           "activeServicesCount": 0,
           "statistics": [],
           "tags": [],
           "settings": [
               {
                   "name": "containerInsights",
                   "value": "disabled"
               }
           ],
           "capacityProviders": [],
           "defaultCapacityProviderStrategy": [],
           "attachments": [
               {
                   "id": "a1b2c3d4-5678-90ab-cdef-EXAMPLE11111",
                   "type": "sc",
                   "status": "ATTACHING",
                   "details": []
               }
           ],
           "attachmentsStatus": "UPDATE_IN_PROGRESS"
       }
   }
   }
   ```

1. 確認已建立叢集：

   ```
   aws ecs describe-clusters --clusters tutorial
   ```

   輸出：

   ```
   {
       "clusters": [
           {
               "clusterArn": "arn:aws:ecs:us-west-2:123456789012:cluster/tutorial",
               "clusterName": "tutorial",
               "serviceConnectDefaults": {
                   "namespace": "arn:aws:servicediscovery:us-west-2:123456789012:namespace/ns-EXAMPLE"
               },
               "status": "ACTIVE",
               "registeredContainerInstancesCount": 0,
               "runningTasksCount": 0,
               "pendingTasksCount": 0,
               "activeServicesCount": 0,
               "statistics": [],
               "tags": [],
               "settings": [],
               "capacityProviders": [],
               "defaultCapacityProviderStrategy": []
           }
       ],
       "failures": []
   }
   ```

1. （選用） 確認已在其中建立命名空間 AWS Cloud Map。您可以在建立時，使用 AWS 管理主控台 或正常 AWS CLI 組態 AWS Cloud Map。

   例如，使用 AWS CLI：

   ```
   aws servicediscovery get-namespace --id ns-EXAMPLE
   ```

   輸出：

   ```
   {
       "Namespace": {
           "Id": "ns-EXAMPLE",
           "Arn": "arn:aws:servicediscovery:us-west-2:123456789012:namespace/ns-EXAMPLE",
           "Name": "service-connect",
           "Type": "HTTP",
           "Properties": {
               "DnsProperties": {
                   "SOA": {}
               },
               "HttpProperties": {
                   "HttpName": "service-connect"
               }
           },
           "CreateDate": 1661749852.422,
           "CreatorRequestId": "service-connect"
       }
   }
   ```

## 步驟 2：為伺服器建立服務
<a name="create-service-connect-nginx-server"></a>

Service Connect 功能適用於在 Amazon ECS 上進行多個應用程式的互連線。這些應用程式中至少有一個需要提供要連線的 Web 服務。在此步驟中，您要建立如下項目：
+ 會使用未修改的官方 NGINX 容器映像且包含 Service Connect 組態的任務定義。
+ Amazon ECS 服務定義，將 Service Connect 設定為針對此服務的流量提供服務探索與服務網格代理。此組態會重複使用叢集組態中的預設命名空間，以減少您為每個服務所做的服務組態數量。
+ Amazon ECS 服務。該服務會使用任務定義執行一項任務，並為 Service Connect Proxy 插入額外的容器。Proxy 會在任務定義中容器連接埠映射的連接埠上接聽。在 Amazon ECS 中執行的用戶端應用程式中，用戶端任務中的 Proxy 會接聽任務定義連接埠名稱、服務探索名稱或服務用戶端別名名稱的輸出連線，以及來自用戶端別名的連接埠號碼。

**使用 Service Connect 建立 Web 服務**

1. 註冊與 Fargate 相容的任務定義，並使用 `awsvpc` 網路模式。請遵循下列步驟：

   1. 使用以下任務定義的內容，建立名為 `service-connect-nginx.json` 的檔案：

      此任務定義透過將 `name` 和 `appProtocol` 參數新增至連接埠映射來設定 Service Connect。使用多個連接埠時，連接埠名稱有助於您識別服務組態中的此連接埠。依預設，連接埠名稱也會用作可探索的名稱，以供命名空間中的其他應用程式使用。

      任務定義包含任務 IAM 角色，因為服務已啟用 ECS Exec。
**重要**  
此任務定義使用 `logConfiguration`，將 nginx 輸出從 `stdout` 和 `stderr` 傳送到 Amazon CloudWatch Logs。此任務執行角色沒有所需的額外許可，無法建立 CloudWatch Logs 日誌群組。使用 AWS 管理主控台 或 在 CloudWatch Logs 中建立日誌群組 AWS CLI。如果不想將 nginx 日誌傳送到 CloudWatch Logs，您可以移除 `logConfiguration`。  
將任務執行角色中的 AWS 帳戶 ID 取代為您的 AWS 帳戶 ID。

      ```
      {
          "family": "service-connect-nginx",
          "executionRoleArn": "arn:aws:iam::123456789012:role/ecsTaskExecutionRole",
          "taskRoleArn": "arn:aws:iam::123456789012:role/ecsTaskRole",
          "networkMode": "awsvpc",
          "containerDefinitions": [
              {
              "name": "webserver",
              "image": "public.ecr.aws/docker/library/nginx:latest",
              "cpu": 100,
              "portMappings": [
                  {
                      "name": "nginx",
                      "containerPort": 80,
                      "protocol": "tcp", 
                      "appProtocol": "http"
                  }
              ],
              "essential": true,
              "logConfiguration": {
                  "logDriver": "awslogs",
                  "options": {
                      "awslogs-group": "/ecs/service-connect-nginx",
                      "awslogs-region": "region", 
                      "awslogs-stream-prefix": "nginx"
                  }
              }
              }
          ],
          "cpu": "256",
          "memory": "512"
      }
      ```

   1. 使用 `service-connect-nginx.json` 檔案註冊任務定義：

      ```
      aws ecs register-task-definition --cli-input-json file://service-connect-nginx.json
      ```

1. 建立服務：

   1. 使用您要建立的 Amazon ECS 服務的內容，建立名為 `service-connect-nginx-service.json` 的檔案。此範例使用上個步驟中建立的任務定義。需要 `awsvpcConfiguration`，因為任務定義範例使用 `awsvpc` 網路模式。

      建立 ECS 服務時，請指定 Fargate 以及支援 Service Connect 的 `LATEST` 平台版本。`securityGroups` 和 `subnets` 所屬的 VPC 必須具有使用 Amazon ECS 的需求。您可以從 Amazon VPC 主控台取得安全群組和子網路識別碼。

      此服務透過新增 `serviceConnectConfiguration` 參數來設定 Service Connect。不需要命名空間，因為叢集已設定預設命名空間。在命名空間的 ECS 中執行的用戶端應用程式使用 `portName` 和 `clientAliases` 中的連接埠連線至此服務。例如，由於 nginx 在根位置 `/` 提供歡迎頁面，因此可以使用 `http://nginx:80/` 連上此服務。未在 Amazon ECS 中執行或不在相同命名空間中的外部應用程式，可以使用任務的 IP 地址和任務定義中的連接埠號碼，透過 Service Connect Proxy 連上此應用程式。對於 `tls` 組態，請為 `awsPcaAuthorityArn`、`kmsKey` 與 IAM 角色的 `roleArn` 新增憑證 `arn`。

      此服務會使用 `logConfiguration`，將 Service Connect Proxy 輸出從 `stdout` 和 `stderr` 傳送至 Amazon CloudWatch Logs。此任務執行角色沒有所需的額外許可，無法建立 CloudWatch Logs 日誌群組。使用 AWS 管理主控台 或 在 CloudWatch Logs 中建立日誌群組 AWS CLI。我們建議您建立此日誌群組，並將 Proxy 日誌儲存在 CloudWatch Logs 中。如果不想將 Proxy 日誌傳送到 CloudWatch Logs，您可以移除 `logConfiguration`。

      ```
      {
          "cluster": "tutorial",
          "deploymentConfiguration": {
              "maximumPercent": 200,
              "minimumHealthyPercent": 0
          },
          "deploymentController": {
              "type": "ECS"
          },
          "desiredCount": 1,
          "enableECSManagedTags": true,
          "enableExecuteCommand": true,
          "launchType": "FARGATE",
          "networkConfiguration": {
              "awsvpcConfiguration": {
                  "assignPublicIp": "ENABLED",
                  "securityGroups": [
                      "sg-EXAMPLE"
                  ],
                  "subnets": [
                      "subnet-EXAMPLE",
                      "subnet-EXAMPLE",
                      "subnet-EXAMPLE"
                  ]
                 }
          },
          "platformVersion": "LATEST",
          "propagateTags": "SERVICE",
          "serviceName": "service-connect-nginx-service",
          "serviceConnectConfiguration": {
              "enabled": true,
              "services": [
                  {
                      "portName": "nginx",
                      "clientAliases": [
                          {
                              "port": 80
                          }
                      ],
                      "tls": {
                         "issuerCertificateAuthority": {
                            "awsPcaAuthorityArn": "certificateArn"
                         }, 
                         "kmsKey": "kmsKey", 
                         "roleArn": "iamRoleArn"
                      }
                  }
              ],
              "logConfiguration": {
                  "logDriver": "awslogs",
                  "options": {
                      "awslogs-group": "/ecs/service-connect-proxy",
                      "awslogs-region": "region",
                      "awslogs-stream-prefix": "service-connect-proxy"
                  }
              }
          },
          "taskDefinition": "service-connect-nginx"
      }
      ```

   1. 使用 `service-connect-nginx-service.json` 檔案建立服務：

      ```
      aws ecs create-service --cluster tutorial --cli-input-json file://service-connect-nginx-service.json
      ```

      輸出：

      ```
      {
          "service": {
              "serviceArn": "arn:aws:ecs:us-west-2:123456789012:service/tutorial/service-connect-nginx-service",
              "serviceName": "service-connect-nginx-service",
              "clusterArn": "arn:aws:ecs:us-west-2:123456789012:cluster/tutorial",
              "loadBalancers": [],
              "serviceRegistries": [],
              "status": "ACTIVE",
              "desiredCount": 1,
              "runningCount": 0,
              "pendingCount": 0,
              "launchType": "FARGATE",
              "platformVersion": "LATEST",
              "platformFamily": "Linux",
              "taskDefinition": "arn:aws:ecs:us-west-2:123456789012:task-definition/service-connect-nginx:1",
              "deploymentConfiguration": {
                  "deploymentCircuitBreaker": {
                      "enable": false,
                      "rollback": false
                  },
                  "maximumPercent": 200,
                  "minimumHealthyPercent": 0
              },
              "deployments": [
                  {
                      "id": "ecs-svc/3763308422771520962",
                      "status": "PRIMARY",
                      "taskDefinition": "arn:aws:ecs:us-west-2:123456789012:task-definition/service-connect-nginx:1",
                      "desiredCount": 1,
                      "pendingCount": 0,
                      "runningCount": 0,
                      "failedTasks": 0,
                      "createdAt": 1661210032.602,
                      "updatedAt": 1661210032.602,
                      "launchType": "FARGATE",
                      "platformVersion": "1.4.0",
                      "platformFamily": "Linux",
                      "networkConfiguration": {
                          "awsvpcConfiguration": {
                              "assignPublicIp": "ENABLED",
                              "securityGroups": [
                                  "sg-EXAMPLE"
                              ],
                              "subnets": [
                                  "subnet-EXAMPLEf",
                                  "subnet-EXAMPLE",
                                  "subnet-EXAMPLE"
                              ]
                          }
                      },
                      "rolloutState": "IN_PROGRESS",
                      "rolloutStateReason": "ECS deployment ecs-svc/3763308422771520962 in progress.",
                      "failedLaunchTaskCount": 0,
                      "replacedTaskCount": 0,
                      "serviceConnectConfiguration": {
                          "enabled": true,
                          "namespace": "service-connect",
                          "services": [
                              {
                                  "portName": "nginx",
                                  "clientAliases": [
                                      {
                                          "port": 80
                                      }
                                  ]
                              }
                          ],
                          "logConfiguration": {
                              "logDriver": "awslogs",
                              "options": {
                                  "awslogs-group": "/ecs/service-connect-proxy",
                                  "awslogs-region": "us-west-2",
                                  "awslogs-stream-prefix": "service-connect-proxy"
                              },
                              "secretOptions": []
                          }
                      },
                      "serviceConnectResources": [
                          {
                              "discoveryName": "nginx",
                              "discoveryArn": "arn:aws:servicediscovery:us-west-2:123456789012:service/srv-EXAMPLE"
                          }
                      ]
                  }
              ],
              "roleArn": "arn:aws:iam::123456789012:role/aws-service-role/ecs.amazonaws.com/AWSServiceRoleForECS",
              "version": 0,
              "events": [],
              "createdAt": 1661210032.602,
              "placementConstraints": [],
              "placementStrategy": [],
              "networkConfiguration": {
                  "awsvpcConfiguration": {
                      "assignPublicIp": "ENABLED",
                      "securityGroups": [
                          "sg-EXAMPLE"
                      ],
                      "subnets": [
                          "subnet-EXAMPLE",
                          "subnet-EXAMPLE",
                          "subnet-EXAMPLE"
                      ]
                  }
              },
              "schedulingStrategy": "REPLICA",
              "enableECSManagedTags": true,
              "propagateTags": "SERVICE",
              "enableExecuteCommand": true
          }
      }
      ```

      您提供的 `serviceConnectConfiguration` 會出現在輸出的第一個*部署*中。當您以需要對任務進行變更的方式對 ECS 服務進行變更時，Amazon ECS 會建立新的部署。

## 步驟 3：確認您是否可以連線
<a name="create-service-connect-verify"></a>

若要確認 Service Connect 已設定且正常運作，請依照下列步驟從外部應用程式連線至 Web 服務。然後，查看 CloudWatch 中由 Service Connect Proxy 建立的其他指標。

**從外部應用程式連線至 Web 服務**
+ 使用任務 IP 地址連線至任務 IP 地址和容器連接埠

  使用 AWS CLI 取得任務 ID，方法是使用 `aws ecs list-tasks --cluster tutorial`。

  如果子網路和安全群組允許任務定義的連接埠上來自公用網際網路的流量，您可以從電腦連線到公用 IP。不過，公有 IP 無法從 `describe-tasks` 取得，因此這些步驟涉及前往 Amazon EC2 AWS 管理主控台 或 AWS CLI 以取得彈性網路界面的詳細資訊。

  在此範例中，相同 VPC 中的 Amazon EC2 執行個體使用的是任務的私有 IP。該應用程式是 nginx，但 `server: envoy` 標題顯示使用的是 Service Connect Proxy。Service Connect Proxy 正在任務定義中容器連接埠上接聽。

  ```
  $ curl -v 10.0.19.50:80/
  *   Trying 10.0.19.50:80...
  * Connected to 10.0.19.50 (10.0.19.50) port 80 (#0)
  > GET / HTTP/1.1
  > Host: 10.0.19.50
  > User-Agent: curl/7.79.1
  > Accept: */*
  >
  * Mark bundle as not supporting multiuse
  < HTTP/1.1 200 OK
  < server: envoy
  < date: Tue, 23 Aug 2022 03:53:06 GMT
  < content-type: text/html
  < content-length: 612
  < last-modified: Tue, 16 Apr 2019 13:08:19 GMT
  < etag: "5cb5d3c3-264"
  < accept-ranges: bytes
  < x-envoy-upstream-service-time: 0
  <
  <!DOCTYPE html>
  <html>
  <head>
  <title>Welcome to nginx!</title>
  <style>
      body {
          width: 35em;
          margin: 0 auto;
          font-family: Tahoma, Verdana, Arial, sans-serif;
      }
  </style>
  </head>
  <body>
  <h1>Welcome to nginx!</h1>
  <p>If you see this page, the nginx web server is successfully installed and
  working. Further configuration is required.</p>
  
  <p>For online documentation and support please refer to
  <a href="http://nginx.org/">nginx.org</a>.<br/>
  Commercial support is available at
  <a href="http://nginx.com/">nginx.com</a>.</p>
  
  <p><em>Thank you for using nginx.</em></p>
  </body>
  </html>
  ```

**檢視 Service Connect 指標**  
Service Connect Proxy 會在 CloudWatch 指標中建立應用程式 (HTTP、HTTP2、gRPC 或 TCP 連線) 指標。使用 CloudWatch 主控台時，請參閱 Amazon ECS 命名空間下的 **DiscoveryName**、(**DiscoveryName、ServiceName、ClusterName**)、**TargetDiscoveryName** 與 (**TargetDiscoveryName、ServiceName、ClusterName**) 的其他指標維度。如需有關這些指標與維度的詳細資訊，請參閱 Amazon CloudWatch Logs User Guide 中的 [View Available Metrics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/viewing_metrics_with_cloudwatch.html)。

# 使用服務探索以利用 DNS 名稱連接 Amazon ECS 服務
<a name="service-discovery"></a>

您可以選擇性地設定 Amazon ECS 服務，以使用 Amazon ECS 服務探索。服務探索使用 AWS Cloud Map API 動作來管理 Amazon ECS 服務的 HTTP 和 DNS 命名空間。如需詳細資訊，請參閱 *AWS Cloud Map Developer Guide* 中的 [What Is AWS Cloud Map](https://docs.aws.amazon.com/cloud-map/latest/dg/Welcome.html)。

服務探索可在下列 AWS 區域使用：


| 區域名稱 | 區域 | 
| --- | --- | 
|  美國東部 (維吉尼亞北部)  |  us-east-1  | 
|  美國東部 (俄亥俄)  |  us-east-2  | 
|  美國西部 (加州北部)  |  us-west-1  | 
|  美國西部 (奧勒岡)  |  us-west-2  | 
|  Africa (Cape Town)  |  af-south-1  | 
|  亞太地區 (香港)  |  ap-east-1  | 
|  亞太區域 (台北)  |  ap-east-2  | 
|  亞太區域 (孟買)  |  ap-south-1  | 
|  亞太地區 (海德拉巴)  |  ap-south-2  | 
|  亞太區域 (東京)  |  ap-northeast-1  | 
|  亞太區域 (首爾)  |  ap-northeast-2  | 
|  亞太地區 (大阪)  |  ap-northeast-3  | 
|  亞太區域 (新加坡)  |  ap-southeast-1  | 
|  亞太區域 (雪梨)  |  ap-southeast-2  | 
|  亞太地區 (雅加達)  |  ap-southeast-3  | 
|  亞太地區 (墨爾本)  |  ap-southeast-4  | 
|  亞太地區 (馬來西亞)  |  ap-southeast-5  | 
|  亞太區域 (紐西蘭)  |  ap-southeast-6  | 
|  亞太區域 (泰國)  |  ap-southeast-7  | 
|  加拿大 (中部)  |  ca-central-1  | 
|  加拿大西部 (卡加利)  |  ca-west-1  | 
|  中國 (北京)  |  cn-north-1  | 
|  中國 (寧夏)  |  cn-northwest-1  | 
|  歐洲 (法蘭克福)  |  eu-central-1  | 
|  歐洲 (蘇黎世)  |  eu-central-2  | 
|  歐洲 (愛爾蘭)  |  eu-west-1  | 
|  歐洲 (倫敦)  |  eu-west-2  | 
|  歐洲 (巴黎)  |  eu-west-3  | 
|  歐洲 (米蘭)  |  eu-south-1  | 
|  Europe (Stockholm)  |  eu-north-1  | 
|  以色列 (特拉維夫)  |  il-central-1  | 
|  歐洲 (西班牙)  |  eu-south-2  | 
|  中東 (阿拉伯聯合大公國)  |  me-central-1  | 
|  墨西哥 (中部)  |  mx-central-1  | 
|  Middle East (Bahrain)  |  me-south-1  | 
|  南美洲 (聖保羅)  |  sa-east-1  | 
|  AWS GovCloud （美國東部）  |  us-gov-east-1  | 
|  AWS GovCloud （美國西部）  |  us-gov-west-1  | 

## 服務探索概念
<a name="service-discovery-concepts"></a>

服務探索包含下列元件：
+ **服務探索命名空間**：擁有相同網域名稱 (例如 `example.com`) 的服務探索服務的邏輯群組，這是要路由流量的位置。您可以透過呼叫 `aws servicediscovery create-private-dns-namespace` 命令或 Amazon ECS 主控台建立命名空間。您可以使用 `aws servicediscovery list-namespaces` 命令來檢視由目前帳戶所建立的命名空間摘要資訊。如需服務探索命令的詳細資訊，請參閱《 *AWS Cloud Map （服務探索） AWS CLI 參考指南*`[list-namespaces](https://docs.aws.amazon.com/cli/latest/reference/servicediscovery/list-namespaces.html)`》中的 `[create-private-dns-namespace](https://docs.aws.amazon.com/cli/latest/reference/servicediscovery/create-private-dns-namespace.html)`和 。
+ **服務探索服務**：存在於服務探索命名空間中，由命名空間的服務名稱和 DNS 設定組成。它提供以下核心元件：
  + **服務登錄**檔：可讓您透過 DNS 或 AWS Cloud Map API 動作查詢服務，並取得一或多個可用來連線至服務的可用端點。
+ **服務探索執行個體**：存在於服務探索服務內，由服務目錄中每個 Amazon ECS 服務相關聯的屬性組成。
  + **執行個體屬性**：針對每個設定為使用的服務探索的 Amazon ECS 服務，以下中繼資料會新增為自訂屬性：
    + **`AWS_INSTANCE_IPV4`** – 對於 `A`記錄，Route 53 傳回以回應 DNS 查詢的 IPv4 地址，並在探索執行個體詳細資訊時 AWS Cloud Map 傳回 ，例如 `192.0.2.44`。
    + **`AWS_INSTANCE_IPV6`**– 針對 `AAAA`記錄，Route 53 傳回以回應 DNS 查詢的 IPv6 地址，並在探索執行個體詳細資訊時 AWS Cloud Map 傳回 ，例如 ` 2001:0db8:85a3:0000:0000:abcd:0001:2345`。對於 Amazon ECS 雙堆疊服務，會同時新增 `AWS_INSTANCE_IPv4` 與 `AWS_INSTANCE_IPv6`。對於 Amazon ECS 純 IPv6 服務，僅會新增 `AWS_INSTANCE_IPv6`。
    + **`AWS_INSTANCE_PORT`**：與服務探索服務相關聯的連接埠值。
    + **`AVAILABILITY_ZONE`**：在其中啟動任務的可用區域。對於使用 EC2 的任務，這是容器執行個體所在的可用區域。對於使用 Fargate 的任務，這是彈性網路介面所在的可用區域。
    + **`REGION`**：任務所在的區域。
    + **`ECS_SERVICE_NAME`**：任務所屬的 Amazon ECS 服務名稱。
    + **`ECS_CLUSTER_NAME`**：任務所屬的 Amazon ECS 叢集名稱。
    + **`EC2_INSTANCE_ID`**：放置任務的容器執行個體的 ID。如果任務使用 Fargate，則不會新增此自訂屬性。
    + **`ECS_TASK_DEFINITION_FAMILY`**：任務使用的任務定義系列。
    + **`ECS_TASK_SET_EXTERNAL_ID`**：如果任務集合是為外部部署建立，並與服務探索登錄關聯，則 `ECS_TASK_SET_EXTERNAL_ID` 屬性將包含任務集合的外部 ID。
+ **Amazon ECS 運作狀態檢查**：Amazon ECS 會定期執行容器層級的運作狀態檢查。端點若未通過運作狀態檢查，則會從 DNS 路由中移除並標記為運作狀態不佳。

## 服務探索考量
<a name="service-discovery-considerations"></a>

使用服務探索時應考慮以下事項：
+ 服務探索支援在 Fargate 上使用 1.1.0 或更新平台版本的任務。如需詳細資訊，請參閱[適用於 Amazon ECS 的 Fargate 平台版本](platform-fargate.md)。
+ 被設定為使用服務探索的服務有每個服務 1,000 項任務的限制。這是由於 Route 53 服務配額所致。
+ Amazon ECS 主控台的建立服務工作流程僅支援將服務註冊到私有 DNS 命名空間。建立 AWS Cloud Map 私有 DNS 命名空間時，會自動建立 Route 53 私有託管區域。
+ 必須設定 VPC DNS 屬性，以成功進行 DNS 解析。如需有關如何設定屬性的詳細資訊，請參閱 *Amazon VPC 使用者指南*中的 [VPC 中的 DNS 支援](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-dns-support)。
+ Amazon ECS 不支援在共用 AWS Cloud Map 命名空間中註冊服務。
+ 為服務探索服務建立的 DNS 記錄總是會使用任務的私有 IP 地址註冊，而非公有 IP 地址 (即使使用公有命名空間)。
+ 服務探索要求任務指定 `awsvpc`、`bridge` 或 `host` 網路模式 (不支援 `none`)。
+ 如果服務任務定義使用 `awsvpc` 網路模式，您可以為每項服務任務建立任意組合的 `A` 或 `SRV` 記錄。如果使用 `SRV` 記錄，必須具備連接埠。如果服務使用雙堆疊子網路，可以另外建立 `AAAA` 記錄。如果服務使用純 IPv6 子網路，則無法建立 `A` 記錄。
+ 如果服務任務定義使用 `bridge` 或 `host` 網路模式，則 SRV 記錄是唯一受支援的 DNS 記錄類型。為每個服務任務建立 SRV 記錄。SRV 紀錄必須從任務定義中指定容器名稱和容器連接埠組合。
+ 您可以在 VPC 內查詢服務探索服務的 DNS 記錄。其採用的格式為：`<service-discovery-service-name>.<service-discovery-namespace>`。
+ 針對服務名稱執行 DNS 查詢時，`A` 與 `AAAA` 記錄會傳回一組對應至任務的 IP 位址。`SRV` 記錄會為每項任務傳回一組 IP 位址與連接埠。
+ 如果您有八個以下正常運作的記錄，Route 53 會使用所有正常記錄回應所有 DNS 查詢。
+ 當所有記錄都狀況不良，Route 53 會使用最多八個狀況不良的記錄來回應 DNS 查詢。
+ 您可以為負載平衡器後方的服務設定服務探索，但會將服務探索流量一律路由到任務，而不是負載平衡器。
+ 服務探索不支援使用 Classic Load Balancer。
+ 針對您的服務探索服務，我們建議您使用由 Amazon ECS 管理的容器層級運作狀態檢查。
  + **HealthCheckCustomConfig**—Amazon ECS 代替您管理運作狀態檢查。Amazon ECS 利用來自容器和運作狀態檢查的資訊和您的任務狀態，透過 AWS Cloud Map更新運作狀態。當您建立服務探索服務時，會使用 `--health-check-custom-config` 參數來指定。如需詳細資訊，請參閱 *AWS Cloud Map API 參考*中的 [HealthCheckCustomConfig](https://docs.aws.amazon.com/cloud-map/latest/api/API_HealthCheckCustomConfig.html)。
+ 使用服務探索時建立 AWS Cloud Map 的資源必須手動清除。
+ 任務與執行個體會註冊為 `UNHEALTHY`，直到容器運作狀態檢查傳回值。如果運作狀態檢查通過，狀態會更新為 `HEALTHY`。如果容器運作狀態檢查失敗，則會取消註冊服務探索執行個體。

## 服務探索定價
<a name="service-discovery-pricing"></a>

使用 Amazon ECS 服務探索的客戶需要支付 Route 53 資源和 AWS Cloud Map 探索 API 操作的費用。其中包括建立 Route 53 託管區域和查詢服務登錄檔的費用。如需詳細資訊，請參閱 *AWS Cloud Map 開發人員指南*中的 [AWS Cloud Map 定價](https://docs.aws.amazon.com/cloud-map/latest/dg/cloud-map-pricing.html)。

Amazon ECS 會執行容器層級的運作狀態檢查，並將其公開給 AWS Cloud Map 自訂的運作狀態檢查 API 操作。這目前提供給客戶免費使用。如果您針對公開的任務設定其他網路運作狀態檢查，則會向您收取其費用。

# 建立使用服務探索的 Amazon ECS 服務
<a name="create-service-discovery"></a>

了解如何使用 AWS CLI建立一項服務，其中包含使用服務探索的 Fargate 任務。

如需 AWS 區域 支援服務探索的清單，請參閱 [使用服務探索以利用 DNS 名稱連接 Amazon ECS 服務](service-discovery.md)。

如需支援 Fargate 的區域的資訊，請參閱[AWS Fargate 上 Amazon ECS 支援的 區域](AWS_Fargate-Regions.md)。

**注意**  
您可以使用雙堆疊服務端點，透過 IPv4 和 IPv6 AWS CLI從 、 SDKs 和 Amazon ECS API 與 Amazon ECS 互動。如需詳細資訊，請參閱[使用 Amazon ECS 雙堆疊端點](dual-stack-endpoint.md)。

## 先決條件
<a name="create-service-discovery-prereqs"></a>

在您開始教學課程之前，請務必先達成以下先決條件：
+  AWS CLI 已安裝並設定最新版本的 。如需詳細資訊，請參閱 [Installing or updating to the latest version of the AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)。
+ [設定以使用 Amazon ECS。](get-set-up-for-amazon-ecs.md) 中所述的步驟已完成。
+ 您的 IAM 使用者擁有 [AmazonECS\$1FullAccess](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonECS_FullAccess) IAM 政策範例中指定的所需許可。
+ 您已建立至少一個 VPC 和一個安全群組。如需詳細資訊，請參閱[建立 Virtual Private Cloud](get-set-up-for-amazon-ecs.md#create-a-vpc)。

## 步驟 1：在 中建立服務探索資源 AWS Cloud Map
<a name="create-service-discovery-namespace"></a>

請依照下列步驟建立服務探索命名空間和服務探索服務。

1. 建立私有雲端資源服務探索命名空間。此範例會建立名為 `tutorial` 的命名空間。將 *vpc-abcd1234* 替換為您現有其中一個 VPC 的識別碼。

   ```
   aws servicediscovery create-private-dns-namespace \
         --name tutorial \
         --vpc vpc-abcd1234
   ```

   以下是此命令的輸出：

   ```
   {
       "OperationId": "h2qe3s6dxftvvt7riu6lfy2f6c3jlhf4-je6chs2e"
   }
   ```

1. 使用上一步輸出的 `OperationId`，驗證私有命名空間是否已成功建立。請記下命名空間 ID，因為您在後續命令中使用它。

   ```
   aws servicediscovery get-operation \
         --operation-id h2qe3s6dxftvvt7riu6lfy2f6c3jlhf4-je6chs2e
   ```

   輸出如下。

   ```
   {
       "Operation": {
           "Id": "h2qe3s6dxftvvt7riu6lfy2f6c3jlhf4-je6chs2e",
           "Type": "CREATE_NAMESPACE",
           "Status": "SUCCESS",
           "CreateDate": 1519777852.502,
           "UpdateDate": 1519777856.086,
           "Targets": {
              "NAMESPACE": "ns-uejictsjen2i4eeg"
           }
       }
   }
   ```

1. 使用上一步輸出中的 `NAMESPACE` ID，建立服務探索服務。此範例會建立名為 `myapplication` 的服務。請記下服務 ID 和 ARN，因為您在後續命令中使用它們。

   ```
   aws servicediscovery create-service \
         --name myapplication \
         --dns-config "NamespaceId="ns-uejictsjen2i4eeg",DnsRecords=[{Type="A",TTL="300"}]" \
         --health-check-custom-config FailureThreshold=1
   ```

   輸出如下。

   ```
   {
       "Service": {
          "Id": "srv-utcrh6wavdkggqtk",
           "Arn": "arn:aws:servicediscovery:region:aws_account_id:service/srv-utcrh6wavdkggqtk",
           "Name": "myapplication",
           "DnsConfig": {
               "NamespaceId": "ns-uejictsjen2i4eeg",
               "DnsRecords": [
                   {
                       "Type": "A",
                       "TTL": 300
                   }
               ]
           },
           "HealthCheckCustomConfig": {
               "FailureThreshold": 1
           },
           "CreatorRequestId": "e49a8797-b735-481b-a657-b74d1d6734eb"
       }
   }
   ```

## 步驟 2：建立 Amazon ECS 資源
<a name="create-service-discovery-cluster"></a>

請依照下列步驟建立您的 Amazon ECS 叢集、任務定義和服務。

1. 建立 Amazon ECS 叢集 此範例會建立名稱為 `tutorial` 的叢集。

   ```
   aws ecs create-cluster \
         --cluster-name tutorial
   ```

1. 註冊與 Fargate 相容的任務定義，並使用 `awsvpc` 網路模式。請遵循下列步驟：

   1. 使用以下任務定義的內容，建立名為 `fargate-task.json` 的檔案：

      ```
      {
          "family": "tutorial-task-def",
              "networkMode": "awsvpc",
              "containerDefinitions": [
                  {
                      "name": "sample-app",
                      "image": "public.ecr.aws/docker/library/httpd:2.4",
                      "portMappings": [
                          {
                              "containerPort": 80,
                              "hostPort": 80,
                              "protocol": "tcp"
                          }
                      ],
                      "essential": true,
                      "entryPoint": [
                          "sh",
                          "-c"
                      ],
                      "command": [
                          "/bin/sh -c \"echo '<html> <head> <title>Amazon ECS Sample App</title> <style>body {margin-top: 40px; background-color: #333;} </style> </head><body> <div style=color:white;text-align:center> <h1>Amazon ECS Sample App</h1> <h2>Congratulations!</h2> <p>Your application is now running on a container in Amazon ECS.</p> </div></body></html>' >  /usr/local/apache2/htdocs/index.html && httpd-foreground\""
                      ]
                  }
              ],
              "requiresCompatibilities": [
                  "FARGATE"
              ],
              "cpu": "256",
              "memory": "512"
      }
      ```

   1. 使用 `fargate-task.json` 註冊任務定義。

      ```
      aws ecs register-task-definition \
            --cli-input-json file://fargate-task.json
      ```

1. 依照下列步驟建立 ECS 服務：

   1. 使用您要建立的 ECS 服務的內容，建立名為 `ecs-service-discovery.json` 的檔案。此範例使用上個步驟中建立的任務定義。需要 `awsvpcConfiguration`，因為任務定義範例使用 `awsvpc` 網路模式。

      建立 ECS 服務時，請指定 Fargate 以及支援服務探索的 `LATEST` 平台版本。在 AWS Cloud Map 中建立服務探索服務時，`registryArn` 是傳回的 ARN。`securityGroups` 和 `subnets` 必須屬於用來建立 Cloud Map 命名空間的 VPC。您可以從 Amazon VPC 主控台取得安全群組和子網路識別碼。

      ```
      {
          "cluster": "tutorial",
          "serviceName": "ecs-service-discovery",
          "taskDefinition": "tutorial-task-def",
          "serviceRegistries": [
             {
                "registryArn": "arn:aws:servicediscovery:region:aws_account_id:service/srv-utcrh6wavdkggqtk"
             }
          ],
          "launchType": "FARGATE",
          "platformVersion": "LATEST",
          "networkConfiguration": {
             "awsvpcConfiguration": {
                "assignPublicIp": "ENABLED",
                "securityGroups": [ "sg-abcd1234" ],
                "subnets": [ "subnet-abcd1234" ]
             }
          },
          "desiredCount": 1
      }
      ```

   1. 使用 `ecs-service-discovery.json` 建立您的 ECS 服務。

      ```
      aws ecs create-service \
            --cli-input-json file://ecs-service-discovery.json
      ```

## 步驟 3：在 中驗證服務探索 AWS Cloud Map
<a name="create-service-discovery-verify"></a>

您可以查詢服務探索資訊，以確認一切都已正確建立。設定服務探索之後，您可以使用 AWS Cloud Map API 操作，或從 VPC `dig` 中的執行個體呼叫 。請遵循下列步驟：

1. 使用服務探索的服務 ID，來列出服務探索執行個體。請記下執行個體 ID (以粗體標示) 以進行資源清理。

   ```
    aws servicediscovery list-instances \
          --service-id srv-utcrh6wavdkggqtk
   ```

   輸出如下。

   ```
   {
       "Instances": [
           {
               "Id": "16becc26-8558-4af1-9fbd-f81be062a266",
               "Attributes": {
                   "AWS_INSTANCE_IPV4": "172.31.87.2"
                   "AWS_INSTANCE_PORT": "80", 
                   "AVAILABILITY_ZONE": "us-east-1a", 
                   "REGION": "us-east-1", 
                   "ECS_SERVICE_NAME": "ecs-service-discovery", 
                   "ECS_CLUSTER_NAME": "tutorial", 
                   "ECS_TASK_DEFINITION_FAMILY": "tutorial-task-def"
               }
           }
       ]
   }
   ```

1. 使用服務探索命名空間、服務和其他參數如 ECS 叢集名稱，來查詢服務探索執行個體的詳細資訊。

   ```
   aws servicediscovery discover-instances \
         --namespace-name tutorial \
         --service-name myapplication \
         --query-parameters ECS_CLUSTER_NAME=tutorial
   ```

1. 在 Route 53 託管區域為服務探索服務建立的 DNS 記錄，可使用以下 AWS CLI 命令查詢：

   1. 使用命名空間 ID 取得命名空間的相關資訊，其中包括 Route 53 託管區域 ID。

      ```
      aws servicediscovery \
            get-namespace --id ns-uejictsjen2i4eeg
      ```

      輸出如下。

      ```
      {
          "Namespace": {
              "Id": "ns-uejictsjen2i4eeg",
              "Arn": "arn:aws:servicediscovery:region:aws_account_id:namespace/ns-uejictsjen2i4eeg",
              "Name": "tutorial",
              "Type": "DNS_PRIVATE",
              "Properties": {
                   "DnsProperties": {
                      "HostedZoneId": "Z35JQ4ZFDRYPLV"
                  }
              },
              "CreateDate": 1519777852.502,
              "CreatorRequestId": "9049a1d5-25e4-4115-8625-96dbda9a6093"
          }
      }
      ```

   1. 使用上一步中的 Route 53 託管區域 ID (請參閱粗體文字)，取得託管區域的資源紀錄集。

      ```
      aws route53 list-resource-record-sets \
            --hosted-zone-id Z35JQ4ZFDRYPLV
      ```

1. 您還可以使用 `dig` 從您的 VPC 內的執行個體查詢 DNS。

   ```
   dig +short myapplication.tutorial
   ```

## 步驟 4：清理
<a name="create-service-discovery-cleanup"></a>

當您完成此教學課程時，清除相關聯的資源以避免未使用的資源產生費用。請遵循下列步驟：

1. 使用您之前提到的服務 ID 和執行個體 ID，取消註冊服務探索服務執行個體。

   ```
   aws servicediscovery deregister-instance \
         --service-id srv-utcrh6wavdkggqtk \
         --instance-id 16becc26-8558-4af1-9fbd-f81be062a266
   ```

   輸出如下。

   ```
   {
       "OperationId": "xhu73bsertlyffhm3faqi7kumsmx274n-jh0zimzv"
   }
   ```

1. 使用來自上一步輸出的 `OperationId`，請驗證已成功取消註冊服務探索服務。

   ```
   aws servicediscovery get-operation \ 
         --operation-id xhu73bsertlyffhm3faqi7kumsmx274n-jh0zimzv
   ```

   ```
   {
     "Operation": {
           "Id": "xhu73bsertlyffhm3faqi7kumsmx274n-jh0zimzv",
           "Type": "DEREGISTER_INSTANCE",
           "Status": "SUCCESS",
           "CreateDate": 1525984073.707,
           "UpdateDate": 1525984076.426,
           "Targets": {
               "INSTANCE": "16becc26-8558-4af1-9fbd-f81be062a266",
               "ROUTE_53_CHANGE_ID": "C5NSRG1J4I1FH",
               "SERVICE": "srv-utcrh6wavdkggqtk"
           }
       }
   }
   ```

1. 使用服務 ID 刪除服務探索服務。

   ```
   aws servicediscovery delete-service \ 
         --id srv-utcrh6wavdkggqtk
   ```

1. 使用命名空間 ID 刪除服務探索命名空間 。

   ```
   aws servicediscovery delete-namespace \ 
         --id ns-uejictsjen2i4eeg
   ```

   輸出如下。

   ```
   {
       "OperationId": "c3ncqglftesw4ibgj5baz6ktaoh6cg4t-jh0ztysj"
   }
   ```

1. 使用上一步輸出的 `OperationId`，確認服務探索命名空間已成功刪除。

   ```
   aws servicediscovery get-operation \ 
         --operation-id c3ncqglftesw4ibgj5baz6ktaoh6cg4t-jh0ztysj
   ```

   輸出如下。

   ```
   {
       "Operation": {
           "Id": "c3ncqglftesw4ibgj5baz6ktaoh6cg4t-jh0ztysj",
           "Type": "DELETE_NAMESPACE",
           "Status": "SUCCESS",
           "CreateDate": 1525984602.211,
           "UpdateDate": 1525984602.558,
           "Targets": {
               "NAMESPACE": "ns-rymlehshst7hhukh",
               "ROUTE_53_CHANGE_ID": "CJP2A2M86XW3O"
           }
       }
   }
   ```

1. 將 Amazon ECS 服務所需的計數更新為 `0`。您必須執行此操作，才能在後續步驟中刪除服務。

   ```
   aws ecs update-service \
         --cluster tutorial \
         --service ecs-service-discovery \
         --desired-count 0
   ```

1. 刪除 Amazon ECS 服務：

   ```
   aws ecs delete-service \
         --cluster tutorial \
         --service ecs-service-discovery
   ```

1. 刪除 Amazon ECS 叢集：

   ```
   aws ecs delete-cluster \
         --cluster tutorial
   ```

# 使用 Amazon VPC Lattice 連接、觀察和保護您的 Amazon ECS 服務
<a name="ecs-vpc-lattice"></a>

Amazon VPC Lattice 是一種全受管應用程式聯網服務，可讓 Amazon ECS 客戶觀察、保護和監控跨 AWS 運算服務、VPCs 和帳戶建置的應用程式，而無需進行任何程式碼變更。

VPC Lattice 使用目標群組，這是運算資源的集合。這些目標會執行您的應用程式或服務，可以是 Amazon EC2 執行個體、IP 地址、Lambda 函數和 Application Load Balancer。透過將其 Amazon ECS 服務與 VPC Lattice 目標群組建立關聯，客戶現在可以在 VPC Lattice 中將 Amazon ECS 任務啟用為 IP 目標。當已註冊服務的任務啟動時，Amazon ECS 會自動將任務註冊到 VPC Lattice 目標群組。

**注意**  
使用五個 VPC Lattice 組態時，部署時間可能會比使用較少組態時稍長。

接聽程式規則用於在符合條件時將流量轉送至指定目標群組。接聽程式会使用所設定之連接埠上的通訊協定來檢查連線請求。服務會根據您在設定接聽程式時定義的規則，將請求路由至其已註冊目標。

Amazon ECS 还會根據 VPC Lattice 運作狀態檢查，自動取代運作狀態不良的任務。一旦與 VPC Lattice 相關聯，Amazon ECS 客戶也可以利用 VPC Lattice 中的許多其他跨運算連線、安全性和可觀測性功能，例如跨叢集、VPCs 和帳戶連線至服務 AWS Resource Access Manager、授權和身分驗證的 IAM 整合，以及進階流量管理功能。

Amazon ECS 客戶可以透過下列方式受益於 VPC Lattice。
+ 提高開發人員生產力 – VPC Lattice 可讓您專注於建置功能，同時由 VPC Lattice 以統一的方式處理所有運算平台上的聯網、安全性與可觀測性挑戰，從而提高開發人員生產力。
+ 強化安全狀態 – VPC Lattice 可讓開發人員輕鬆驗證與保護跨應用程式與運算平台的通訊、強制執行傳輸中加密，並透過 VPC Lattice 驗證政策套用精細存取控制。這可以強化安全狀態，以滿足業界領先的法規與合規需求。
+ 改善應用程式可擴展性與恢復能力 – VPC Lattice 可讓您建立已部署應用程式的網路，並提供以路徑為基礎的路由、以標頭為基礎的路由與以方法為基礎的路由、身分驗證、授權與監控等功能。這些優勢不會對工作負載造成資源負荷，並且可以支援每秒產生數百萬個請求的多叢集部署，而不會增加明顯的延遲。
+ 異質基礎結構的部署彈性 – VPC Lattice 在所有運算服務中提供一致的功能，例如 Amazon ECS、Fargate、Amazon EC2、Amazon EKS 與 Lambda，便於組織彈性地為每個應用程式選擇合適的基礎結構。

## VPC Lattice 如何搭配 Amazon ECS 服務運作
<a name="ecs-lattice-compatibility"></a>

搭配 Amazon ECS 使用 VPC Lattice 時，某些 Amazon ECS 服務的使用方式可能會變更，而某些服務則會保持不變。

**Application Load Balancer**  
您不再需要建立特定的 Application Load Balancer，以用於 VPC Lattice 中的 Application Load Balancer 目標群組類型，然後再連結至 Amazon ECS 服務。只需將 Amazon ECS 服務設定為使用 VPC Lattice 目標群組即可。您也可以選擇同時搭配 Amazon ECS 使用 Application Load Balancer。

**Amazon ECS 滾動部署**  
只有 Amazon ECS 滾動部署能搭配 VPC Lattice 運作，並且 Amazon ECS 會在部署期間安全地將任務引入服務和從服務中移除。不支援 CodeDeploy 與藍/綠部署。

若要進一步了解 VPC Lattice，請參閱 [Amazon VPC Lattice User Guide](https://docs.aws.amazon.com/vpc-lattice/latest/ug/what-is-vpc-lattice.html)。

# 建立使用 VPC Lattice 的服務
<a name="ecs-vpc-lattice-create-service"></a>

您可以使用 AWS 管理主控台 或 AWS CLI 來建立具有 VPC Lattice 的服務。

## 先決條件
<a name="create-ecs-vpc-lattice-prereqs"></a>

在您開始教學課程之前，請務必先達成以下先決條件：
+  AWS CLI 已安裝並設定最新版本的 。如需詳細資訊，請參閱[安裝 AWS Command Line Interface](https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2.html)。
**注意**  
您可以使用雙堆疊服務端點，透過 IPv4 和 IPv6 AWS CLI從 、 SDKs 和 Amazon ECS API 與 Amazon ECS 互動。如需詳細資訊，請參閱[使用 Amazon ECS 雙堆疊端點](dual-stack-endpoint.md)。
+ [設定以使用 Amazon ECS。](get-set-up-for-amazon-ecs.md) 中所述的步驟已完成。
+ 您的 IAM 使用者擁有 [AmazonECS\$1FullAccess](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonECS_FullAccess) IAM 政策範例中指定的所需許可。

## 建立搭配 使用 VPC Lattice 的服務 AWS 管理主控台
<a name="ecs-lattice-create-console"></a>

請遵循下列步驟，透過 AWS 管理主控台建立使用 VPC Lattice 的服務。

1. 開啟主控台，網址為 [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)。

1. 在導覽頁面中，選擇**叢集**)。

1. 在**叢集**頁面上，選擇要建立服務的叢集。

1. 在 **Services** (服務) 索引標籤上，選擇 **Create** (建立)。

   如果您之前從未建立服務，請遵循[使用主控台建立 Amazon ECS 服務](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/create-service-console-v2.html)中的步驟，然後在到達 VPC Lattice 區段時繼續執行這些步驟。

1. 勾選按鈕以選擇**開啟 VPC Lattice**。

1. 若要使用現有角色，請在 **Amazon ECS 的 ECS 基礎結構角色**欄位中，選擇一個已建立的角色，以便在建立 VPC Lattice 目標群組時使用。若要建立新角色，請**建立 ECS 基礎結構角色**。

1. 選擇 **VPC**。

   **VPC** 取決於您在註冊任務定義時選取的聯網模式。如果您搭配 EC2 使用 `host` 或 `network` 模式，請選擇 VPC。

   對於 `awsvpc` 模式，系統會根據您在**聯網**下選擇的 VPC 自動選取 VPC，且無法變更。

1. 在**目標群組**下，選擇一個或多個目標群組。您需要選擇至少一個目標群組，最多可以選擇五個。選擇**新增目標群組**以新增額外的目標群組。針對選擇的每個目標群組，選擇**連接埠名稱**、**通訊協定**與**連接埠**。若要刪除目標群組，請選擇**移除**。
**注意**  
若要新增現有的目標群組，需要使用 AWS CLI。如需如何使用 新增目標群組的說明 AWS CLI，請參閱《 * AWS Command Line Interface 參考*》中的 [register-targets](https://docs.aws.amazon.com/cli/latest/reference/vpc-lattice/register-targets.html)。
雖然 VPC Lattice 服務可以有多個目標群組，但每個目標群組只能新增至一項服務。
若要在純 IPv6 組態中建立服務，請選擇 IP 位址類型為 `IPv6` 的目標群組。

1. 此時，您會導覽至 VPC Lattice 主控台以繼續設定。在這裡，您可以將新的目標群組加入接聽程式的預設動作或現有 VPC Lattice 服務的規則中。

   如需詳細資訊，請參閱 [VPC Lattice 服務的接聽程式規則](https://docs.aws.amazon.com/vpc-lattice/latest/ug/listener-rules.html)。

**重要**  
您需要允許安全群組或任務使用傳入規則 `vpc-lattice` 字首，否則運作狀態檢查可能會失敗。

## 建立搭配 使用 VPC Lattice 的服務 AWS CLI
<a name="ecs-lattice-create-cli"></a>

使用 AWS CLI 建立具有 VPC Lattice 的服務。將每個*使用者輸入預留位置*替換為自己的資訊。

1. 建立目標群組組態檔案。下列範例名為 `tg-config.json`

   ```
   {
       "ipAddressType": "IPV4",
       "port": 443,
       "protocol": "HTTPS",
       "protocolVersion": "HTTP1",
       "vpcIdentifier": "vpc-f1663d9868EXAMPLE"
   }
   ```

1. 使用下列命令來建立 VPC Lattice 目標群組。

   ```
   aws vpc-lattice create-target-group \
       --name my-lattice-target-group-ip \
       --type IP \
       --config file://tg-config.json
   ```
**注意**  
若要在純 IPv6 組態中建立服務，請建立 IP 位址類型為 `IPv6` 的目標群組。如需詳細資訊，請參閱 *AWS CLI Command Reference* 中的 [create-target-group](https://docs.aws.amazon.com/cli/latest/reference/vpc-lattice/create-target-group.html)。

   輸出範例：

   ```
   {
       "arn": "arn:aws:vpc-lattice:us-east-2:123456789012:targetgroup/tg-0eaa4b9ab4EXAMPLE",
       "config": {
           "healthCheck": {
               "enabled": true,
               "healthCheckIntervalSeconds": 30,
               "healthCheckTimeoutSeconds": 5,
               "healthyThresholdCount": 5,
               "matcher": {
                   "httpCode": "200"
               },
               "path": "/",
               "protocol": "HTTPS",
               "protocolVersion": "HTTP1",
               "unhealthyThresholdCount": 2
           },
           "ipAddressType": "IPV4",
           "port": 443,
           "protocol": "HTTPS",
           "protocolVersion": "HTTP1",
           "vpcIdentifier": "vpc-f1663d9868EXAMPLE"
       },
       "id": "tg-0eaa4b9ab4EXAMPLE",
       "name": "my-lattice-target-group-ip",
       "status": "CREATE_IN_PROGRESS",
       "type": "IP"
   }
   ```

1. 下列名為 *ecs-service-vpc-lattice.json* 的 JSON 檔案是一個範例，用來將 Amazon ECS 服務連接至 VPC Lattice 目標群組。以下範例中的 `portName` 與您在任務定義的 `portMappings` 屬性的 `name` 欄位中定義的名稱相同。

   ```
   {
       "serviceName": "ecs-service-vpc-lattice",
       "taskDefinition": "ecs-task-def",
           "vpcLatticeConfigurations": [
           {
               "targetGroupArn": "arn:aws:vpc-lattice:us-west-2:123456789012:targetgroup/tg-0eaa4b9ab4EXAMPLE",
               "portName": "testvpclattice",
               "roleArn": "arn:aws:iam::123456789012:role/ecsInfrastructureRoleVpcLattice"
           }
       ],
       "desiredCount": 5,
       "role": "ecsServiceRole"
   }
   ```

   使用下列命令建立 Amazon ECS 服務，並使用上述 JSON 範例將其連接至 VPC Lattice 目標群組。

   ```
   aws ecs create-service \
       --cluster clusterName \
       --serviceName ecs-service-vpc-lattice \
       --cli-input-json file://ecs-service-vpc-lattice.json
   ```

**注意**  
Amazon ECS Anywhere 不支援 VPC Lattice。

# 保護 Amazon ECS 任務，避免其因縮減事件而終止
<a name="task-scale-in-protection"></a>

您可以使用 Amazon ECS 任務縮減保護來保護任務，避免任務因服務自動擴展或部署的縮減事件而終止。

某些應用程式需要一種機制來保護關鍵任務，避免任務在使用率較低時或服務部署期間因縮減事件終止。例如：
+ 您擁有佇列處理非同步應用程式，例如影片轉碼工作，即使累積服務使用率很低，其中部分任務仍需要執行數小時。
+ 遊戲應用程式會以 Amazon ECS 任務的形式執行遊戲伺服器，即使所有使用者都已登出，也需要繼續執行，以減少伺服器重新開機的啟動延遲。
+ 部署新的程式碼版本時，您需要繼續執行任務，因為重新處理的費用很昂貴。

若要保護屬於服務的任務不會在縮減事件中終止，請將 `ProtectionEnabled` 屬性設定為 `true`。在將 `ProtectionEnabled` 設定為 true 時，任務預設會受到 2 小時保護。您隨後可以使用 `ExpiresInMinutes` 屬性自訂保護期間。任務的保護時間最短可至 1 分鐘，最長可達 2880 分鐘 (48 小時)。如果您使用的是 AWS CLI，您可以指定 `--protection-enabled`選項。

任務完成必要的工作之後，您可以將 `ProtectionEnabled` 屬性設定為 `false`，以便隨後的縮減事件終止任務。如果您使用的是 AWS CLI，您可以指定 `--no-protection-enabled`選項。

## 任務縮減保護機制
<a name="task-scale-in-protection-mechanisms"></a>

您可以使用 Amazon ECS 容器代理程式端點或 Amazon ECS API 來設定和取得任務縮減保護。
+ **Amazon ECS 容器代理程式端點**

  我們建議將 Amazon ECS 容器代理程式端點，用於可自行判斷是否需要保護的任務。針對以佇列為基礎或工作處理的工作負載使用此方法。

  當容器開始處理工作時 (例如使用 SQS 訊息)，您可以從容器內透過任務縮減保護端點路徑 `$ECS_AGENT_URI/task-protection/v1/state` 來設定 `ProtectionEnabled` 屬性。Amazon ECS 不會在縮減事件期間終止此任務。在任務完成工作之後，您可以使用相同的端點清除對 `ProtectionEnabled` 屬性的設定，使任務符合在後續縮減事件期間終止的資格。

  如需有關 Amazon ECS 容器代理程式端點的詳細資訊，請參閱 [Amazon ECS 任務縮減保護端點](task-scale-in-protection-endpoint.md)。
+ **Amazon ECS API**

  如果應用程式具有追蹤作用中任務狀態的元件，則可使用 Amazon ECS API 來設定與擷取任務縮減保護。使用 `UpdateTaskProtection` 將一或多個任務標記為受保護。使用 `GetTaskProtection` 擷取保護狀態。

  如果應用程式以 Amazon ECS 任務的形式託管遊戲伺服器工作階段，則可使用此方法。當使用者登入伺服器 (任務) 上的工作階段時，您可以將任務標示為受保護。使用者登出後，您可以清除專門針對此任務的保護設定，或根據您希望伺服器保持閒置的需求，定期清除不再具有作用中工作階段的類似任務的保護設定。

  如需詳細資訊，請參閱 *Amazon Elastic Container Service API Reference* 中的 [UpdateTaskProtection](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateTaskProtection.html) 與 [GetTaskProtection](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_GetTaskProtection.html)。

您可以將這兩種方法結合起來使用。例如，使用 Amazon ECS 代理程式端點，從容器內設定任務保護，並使用 Amazon ECS API，從外部控制器服務移除對任務保護的設定。

## 考量事項
<a name="task-scale-in-protection-considerations"></a>

使用任務縮減保護之前，請考量下列幾點：
+ 任務縮減保護僅支援從服務部署的任務。
+ 任務縮減保護支援從在 Amazon ECS 受管執行個體上執行的服務部署的任務。
+ 建議使用 Amazon ECS 容器代理程式端點，因為 Amazon ECS 代理程式具有內建的重試機制和更簡單的介面。
+ 您可以為已開啟保護的任務呼叫 `UpdateTaskProtection`，以重設任務縮減保護過期期間。
+ 判斷任務需要多久才能完成其必要的工作，並相應地設定 `expiresInMinutes` 屬性。如果您設定的保護過期期間超過必要的時間，則會產生費用，並會在部署新任務時面臨延遲。
+ Amazon ECS 容器代理程式 `1.65.0` 或更新版本支援任務縮減保護。使用較舊版本的 Amazon ECS 容器代理程式可在 Amazon EC2 執行個體上新增此功能的支援，方法是將代理程式更新為最新版本。如需詳細資訊，請參閱[更新 Amazon ECS 容器代理程式](ecs-agent-update.md)。
+ 部署考量事項：
  + 如果服務使用滾動更新，則會建立新任務，但在 `protectionEnabled` 設定清除或過期之前執行舊版本的任務都不會終止。您可以將部署組態中的 `maximumPercentage` 參數調整為可允許在舊任務受保護時建立新任務的值。
  + 如果套用了藍/綠更新，若任務有 `protectionEnabled`，則不會移除具有受保護任務的藍色部署。流量將轉移至新啟動的任務，而且只有在 `protectionEnabled` 清除或過期時才會移除較舊的任務。視 CodeDeploy 或 CloudFormation 更新的逾時而定，部署可能會逾時，而較舊的藍色任務可能仍會存在。
  + 如果您使用 CloudFormation，則更新堆疊會有 3 小時的逾時。因此，如果您將任務保護設定為 3 小時以上，則 CloudFormation 部署可能會導致失敗和復原。

    在您的舊任務受到保護期間，CloudFormation 堆疊會顯示 `UPDATE_IN_PROGRESS`。如果任務縮減保護遭移除或在 3 小時視窗內過期，部署將會成功並變為 `UPDATE_COMPLETE` 狀態。如果部署停滯在 `UPDATE_IN_PROGRESS` 的時間超過 3 小時，其將失敗並顯示 `UPDATE_FAILED` 狀態，然後會復原至舊任務集。
  + 當受保護的任務導致部署 (滾動或藍/綠) 無法進入穩定狀態，Amazon ECS 會傳送服務事件，以便您採取補救措施。嘗試更新任務的受保護狀態時，如果您收到 `DEPLOYMENT_BLOCKED` 錯誤訊息，則表示該服務的受保護任務比服務所需的任務計數更多。若要解決此錯誤，請執行以下其中一個動作：
    + 等待目前的任務保護過期。然後設定任務保護。
    + 判斷可以停止哪些任務。然後使用 `UpdateTaskProtection`，並將 `protectionEnabled` 選項設為 `false` 來完成這些任務。
    + 將服務的所需任務計數提高到超過受保護任務的數目。

## 任務縮減保護所需的 IAM 許可
<a name="task-scale-in-protection-iam"></a>

任務必須具備具有如下許可的 Amazon ECS 任務角色：
+ `ecs:GetTaskProtection`：允許 Amazon ECS 容器代理程式呼叫 `GetTaskProtection`。
+ `ecs:UpdateTaskProtection`：允許 Amazon ECS 容器代理程式呼叫 `UpdateTaskProtection`。

# Amazon ECS 任務縮減保護端點
<a name="task-scale-in-protection-endpoint"></a>

Amazon ECS 容器代理程式會自動將 `ECS_AGENT_URI` 環境變體注入 Amazon ECS 任務的容器中，以提供與容器代理程式 API 端點互動的方法。

我們建議將 Amazon ECS 容器代理程式端點，用於可自行判斷是否需要保護的任務。

當容器開始處理工作時，您可以從容器內透過任務縮減保護端點路徑 `$ECS_AGENT_URI/task-protection/v1/state` 來設定 `protectionEnabled` 屬性。

從容器內對此 URI 發送 PUT 請求，設定任務縮減保護。對此 URI 的 GET 請求將傳回任務的目前保護狀態。

## 任務縮減保護請求參數
<a name="task-scale-in-protection-request"></a>

您可以使用具有下列請求參數的 `${ECS_AGENT_URI}/task-protection/v1/state` 端點來設定任務縮減保護。

`ProtectionEnabled`  
指定 `true` 來標記任務以實現保護。指定 `false` 以移除保護，並讓任務符合終止資格。  
類型：布林值  
必要：是

`ExpiresInMinutes`  
任務受到保護的分鐘數。您可以指定最短 1 分鐘到最長 2,880 分鐘 (48 小時)。在此期間，您的任務不會因 Service Auto Scaling 或部署中的縮減事件而終止。在此時段過後，將 `protectionEnabled` 參數設為 `false`。  
如果您未指定時間，則會自動保護任務 120 分鐘 (2 小時)。  
類型：整數  
必要：否

下列範例示範如何設定具有不同時段的任務保護。

**如何使用預設時段保護任務的範例**

此範例示範如何保護預設時段為 2 小時的任務。

```
curl --request PUT --header 'Content-Type: application/json' ${ECS_AGENT_URI}/task-protection/v1/state --data '{"ProtectionEnabled":true}'
```

**60 分鐘保護任務的範例**

此範例示範如何使用 `expiresInMinutes` 參數保護任務 60 分鐘。

```
curl --request PUT --header 'Content-Type: application/json' ${ECS_AGENT_URI}/task-protection/v1/state --data '{"ProtectionEnabled":true,"ExpiresInMinutes":60}'      
```

**24 小時保護任務的範例**

此範例示範如何使用 `expiresInMinutes` 參數保護任務 24 小時。

```
curl --request PUT --header 'Content-Type: application/json' ${ECS_AGENT_URI}/task-protection/v1/state --data '{"ProtectionEnabled":true,"ExpiresInMinutes":1440}'      
```

**Windows 容器範例**

對於 Windows 容器，您可以使用 PowerShell 的 `Invoke-RestMethod` cmdlet 而非 curl。下列範例展示了與先前 curl 命令等效的 PowerShell 命令。

**使用預設時段保護 Windows 容器任務的範例**

此範例說明如何使用 PowerShell 以預設的 2 小時時段保護任務。

```
Invoke-RestMethod -Uri $env:ECS_AGENT_URI/task-protection/v1/state -Method Put -Body '{"ProtectionEnabled":true}' -ContentType 'application/json'
```

**60 分鐘保護 Windows 容器任務的範例**

此範例說明如何搭配 PowerShell 使用 `expiresInMinutes` 參數保護任務 60 分鐘。

```
Invoke-RestMethod -Uri $env:ECS_AGENT_URI/task-protection/v1/state -Method Put -Body '{"ProtectionEnabled":true,"ExpiresInMinutes":60}' -ContentType 'application/json'
```

**24 小時保護 Windows 容器任務的範例**

此範例說明如何搭配 PowerShell 使用 `expiresInMinutes` 參數保護任務 24 小時。

```
Invoke-RestMethod -Uri $env:ECS_AGENT_URI/task-protection/v1/state -Method Put -Body '{"ProtectionEnabled":true,"ExpiresInMinutes":1440}' -ContentType 'application/json'
```

PUT 請求將傳回以下回應。

```
{
  "protection": {
    "ExpirationDate": "2023-12-20T21:57:44.837Z",
    "ProtectionEnabled": true,
    "TaskArn": "arn:aws:ecs:us-west-2:111122223333:task/1234567890abcdef0"
  }
}
```

## 任務縮減保護回應參數
<a name="task-scale-in-protection-response"></a>

JSON 回應中的任務縮減保護端點 `${ECS_AGENT_URI}/task-protection/v1/state` 會傳回下列資訊。

`ExpirationDate`  
任務保護將到期的時間 (以 Epoch 時間表示)。如果任務未受到保護，則此值將為空。

`ProtectionEnabled`  
任務的保護狀態。如果已針對任務啟用縮減保護，則值為 `true`。否則為 `false`。

`TaskArn`  
容器所屬任務的完整 Amazon Resource Name (ARN)。

下列範例顯示了為受保護任務傳回的詳細資訊。

```
curl --request GET ${ECS_AGENT_URI}/task-protection/v1/state
```

對於 Windows 容器，請使用下列 PowerShell 命令來取得保護狀態：

```
Invoke-RestMethod -Uri $env:ECS_AGENT_URI/task-protection/v1/state -Method Get
```

```
{
    "protection":{
        "ExpirationDate":"2023-12-20T21:57:44Z",
        "ProtectionEnabled":true,
        "TaskArn":"arn:aws:ecs:us-west-2:111122223333:task/1234567890abcdef0"
    }
}
```

發生失敗時會傳回下列資訊。

`Arn`  
任務的完整 Amazon Resource Name (ARN)。

`Detail`  
與失敗相關的詳細資訊。

`Reason`  
失敗的原因。

下列範例顯示了為未保護任務傳回的詳細資訊。

```
{
    "failure":{
        "Arn":"arn:aws:ecs:us-west-2:111122223333:task/1234567890abcdef0",
        "Detail":null,
        "Reason":"TASK_NOT_VALID"
    }
}
```

發生例外狀況時會傳回下列資訊。

`requestID`  
造成例外狀況的 Amazon ECS API 呼叫 AWS 請求 ID。

`Arn`  
任務或服務的完整 Amazon Resource Name (ARN)。

`Code`  
錯誤代碼。

`Message`  
錯誤訊息。  
如果出現 `RequestError` 或 `RequestTimeout` 錯誤，則可能是聯網問題。嘗試對 Amazon ECS 使用 VPC 端點。

以下範例顯示了發生錯誤時傳回的詳細資訊。

```
{
    "requestID":"12345-abc-6789-0123-abc",
    "error":{
        "Arn":"arn:aws:ecs:us-west-2:555555555555:task/my-cluster-name/1234567890abcdef0",
        "Code":"AccessDeniedException",
        "Message":"User: arn:aws:sts::444455556666:assumed-role/my-ecs-task-role/1234567890abcdef0 is not authorized to perform: ecs:GetTaskProtection on resource: arn:aws:ecs:us-west-2:555555555555:task/test/1234567890abcdef0 because no identity-based policy allows the ecs:GetTaskProtection action"
    }    
}
```

如果 Amazon ECS 代理程式因為網路問題或 Amazon ECS 控制平面關閉等原因而無法從 Amazon ECS 端點獲得回應，則會出現下列錯誤。

```
{
  "error": {
    "Arn": "arn:aws:ecs:us-west-2:555555555555:task/my-cluster-name/1234567890abcdef0",
    "Code": "RequestCanceled",
    "Message": "Timed out calling Amazon ECS Task Protection API"
  }
}
```

當 Amazon ECS 代理程式從 Amazon ECS 中取得限流例外狀況時，會出現下列錯誤。

```
{
  "requestID": "12345-abc-6789-0123-abc",
  "error": {
    "Arn": "arn:aws:ecs:us-west-2:555555555555:task/my-cluster-name/1234567890abcdef0",
    "Code": "ThrottlingException",
    "Message": "Rate exceeded"
  }
}
```

# 搭配 Amazon ECS 與 Fargate 工作負載使用故障注入
<a name="fault-injection"></a>

客戶可以在 Amazon EC2 與 Fargate 上搭配 Amazon ECS 使用故障注入，以測試應用程式在特定受損案例下的應對表現。這些測試提供的資訊可用於最佳化應用程式的效能與恢復能力。

啟用故障注入後，Amazon ECS 容器代理程式會允許任務存取新的故障注入端點。您需要選擇加入，才能透過將 `enableFaultInjection` 任務定義參數值設定為 `true` 來使用故障注入。預設值為 `false`。

```
{
    ...
   "enableFaultInjection": true
}
```

**注意**  
故障注入僅適用於使用 `awsvpc` 或 `host` 網路模式的任務。  
故障注入不適用於 Windows。

如需有關如何在 中啟用錯誤注入的資訊 AWS 管理主控台，請參閱[使用主控台建立 Amazon ECS 任務定義](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/create-task-definition.html)。

您需要在 AWS Fault Injection Service中啟用此功能以進行測試。如需詳細資訊，請參閱[使用 AWS FIS aws：ecs：task 動作](https://docs.aws.amazon.com/fis/latest/userguide/ecs-task-actions.html)。

**注意**  
如果您未使用新的 Amazon ECS 最佳化 AMI，或擁有自訂 AMI，請安裝下列相依項：  
`tc`
`sch_netem` 核心模組

# Amazon ECS 故障注入端點
<a name="fault-injection-endpoints"></a>

Amazon ECS 容器代理程式會自動將 `ECS_AGENT_URI` 環境變體注入 Amazon ECS 任務的容器中，以提供與容器代理程式 API 端點互動的方法。每個端點都包含 `/start`、`/stop` 與 `/status`端點。這些端點僅接受已啟用故障注入之任務的請求，且每個端點的速率限制為每個容器每 **5** 秒 **1** 個請求。超過此限制會導致錯誤。

**注意**  
需要具有 Amazon ECS Agent `version 1.88.0+` 才能使用故障注入端點。

搭配故障注入使用的三個端點為：
+ [網路黑洞連接埠端點](#fis-endpoint-blackhole-ports)
+ [網路封包遺失端點](#fis-endpoint-packet-loss)
+ [網路延遲端點](#fis-endpoint-latency)

成功的請求會產生 `200` 的回應碼，呼叫 `/start` 端點時訊息為 `running`，呼叫 `/stop` 端點時為 `stopped`，呼叫 `/status` 端點時為 `running` 或 `not-running`。

```
{
    "Status": <string>
}
```

失敗的請求會傳回下列其中一個錯誤代碼：
+ `400` – 錯誤的請求
+ `409` – 故障注入請求與另一個執行中的故障衝突
+ `429` – 請求限流
+ `500` – 伺服器發生非預期錯誤

```
{
	"Error":  <string message> 
}
```

**注意**  
一次只能注入一個網路延遲故障或一個網路封包遺失故障。嘗試注入多個故障會導致請求遭拒。

## 網路黑洞連接埠端點
<a name="fis-endpoint-blackhole-ports"></a>

`{ECS_AGENT_URI}/fault/v1/network-blackhole-port` 端點會捨棄任務網路命名空間中特定連接埠與通訊協定的傳入或傳出流量，並與兩種模式相容：
+ **awsvpc** – 變更會套用至任務網路命名空間
+ **主機** – 變更會套用至預設網路命名空間容器執行個體

### \$1ECS\$1AGENT\$1URI\$1/fault/v1/network-blackhole-port/start
<a name="fis-endpoint-blackhole-ports-start"></a>

此端點會啟動網路黑洞連接埠故障注入，並具有下列參數：

**站點**  
用於黑洞連接埠故障注入的指定連接埠。

類型：整數

必要：是

**通訊協定**  
用於黑洞連接埠故障注入的通訊協定。

類型：字串

有效值：`tcp | udp`

必要：是

**TrafficType**  
故障注入使用的流量類型。

類型：字串

有效值：`ingress | egress`

必要：是

**SourcesToFilter**  
受故障保護的 IPv4 或 IPv6 位址或 CIDR 區塊的 JSON 陣列。

類型：字串陣列

必要：否

以下是使用 `start` 端點的請求範例 (將*紅色*值取代為實際值)：

```
Endpoint: ${ECS_AGENT_URI}/fault/v1/network-blackhole-port/start

Http method:POST

Request payload: 
{
    "Port": 1234,
    "Protocol": "tcp|udp",
    "TrafficType": "ingress|egress"
    "SourcesToFilter": ["${IP1}", "${IP2}", ...],
}
```

### \$1ECS\$1AGENT\$1URI\$1/fault/v1/network-blackhole-port/stop
<a name="fis-endpoint-blackhole-ports-stop"></a>

此端點會停止請求中指定的故障。此端點具有下列參數：

**站點**  
應停止之受故障影響的連接埠。

類型：整數

必要：是

**通訊協定**  
用於停止故障的通訊協定。

類型：字串

有效值：`tcp | udp`

必要：是

**TrafficType**  
故障注入使用的流量類型。

類型：字串

有效值：`ingress | egress`

必要：是

以下是使用 `stop` 端點的請求範例 (將*紅色*值取代為實際值)：

```
Endpoint: ${ECS_AGENT_URI}/fault/v1/network-blackhole-port/stop

Http method: POST

Request payload: 
{
    "Port": 1234,
    "Protocol": "tcp|udp",
    "TrafficType": "ingress|egress", 
}
```

### \$1ECS\$1AGENT\$1URI\$1/fault/v1/network-blackhole-port/status
<a name="fis-endpoint-blackhole-ports-status"></a>

此端點用於檢查故障注入的狀態。此端點具有下列參數：

**站點**  
要檢查故障狀態的受影響連接埠。

類型：整數

必要：是

**通訊協定**  
檢查故障狀態時使用的通訊協定。

類型：字串

有效值：`tcp | udp`

必要：是

**TrafficType**  
故障注入使用的流量類型。

類型：字串

有效值：`ingress | egress`

必要：是

以下是使用 `status` 端點的請求範例 (將*紅色*值取代為實際值)：

```
Endpoint: ${ECS_AGENT_URI}/fault/v1/network-blackhole-port/status

Http method: POST

Request payload: 
{
   "Port": 1234,
   "Protocol": "tcp|udp",
   "TrafficType": "ingress|egress",
}
```

## 網路延遲端點
<a name="fis-endpoint-latency"></a>

`{ECS_AGENT_URI}/fault/v1/network-latency` 端點會將延遲與抖動新增至任務的網路介面，以將流量傳送至特定來源。端點與兩種模式相容：
+ **awsvpc** – 變更會套用至任務網路介面
+ **主機** – 變更會套用至預設網路介面

### \$1ECS\$1AGENT\$1URI\$1/fault/v1/network-latency/start
<a name="fis-endpoint-latency-start"></a>

此 `/start` 端點會開始網路延遲故障注入，並具有下列參數：

**DelayMilliseconds**  
要新增至網路介面以用於故障注入的延遲毫秒數。

類型：整數

必要：是

**JitterMilliseconds**  
要新增至網路介面以用於故障注入的抖動毫秒數。

類型：整數

必要：是

**來源**  
IPv4 或 IPv6 位址或 CIDR 區塊的 JSON 陣列，作為用於故障注入的目的地。

類型：字串陣列

必要：是

**SourcesToFilter**  
受故障保護的 IPv4 或 IPv6 位址或 CIDR 區塊的 JSON 陣列。`SourcesToFilter` 的優先級高於 `Sources`。

類型：字串陣列

必要：否

以下是使用 `/start` 端點的請求範例 (將*紅色*值取代為實際值)：

```
Endpoint: ${ECS_AGENT_URI}/fault/v1/network-latency/start

Http method: POST

Request payload: 
{
    "DelayMilliseconds": 123,
    "JitterMilliseconds": 123,
    "Sources": ["${IP1}", "${IP2}", ...],
    "SourcesToFilter": ["${IP1}", "${IP2}", ...],
}
```

### \$1ECS\$1AGENT\$1URI\$1/fault/v1/network-latency/stop and /status
<a name="fis-endpoint-latency-stop-status"></a>

`{ECS_AGENT_URI}/fault/v1/network-latency/stop` 端點會停止故障，`{ECS_AGENT_URI}/fault/v1/network-latency/status` 則會檢查故障的狀態。

以下是使用 `/stop` 與 `/status` 端點的兩個請求範例。兩者都使用 `POST HTTP` 方法。

```
Endpoint: ${ECS_AGENT_URI}/fault/v1/network-latency/stop
```

```
Endpoint: ${ECS_AGENT_URI}/fault/v1/network-latency/status
```

## 網路封包遺失端點
<a name="fis-endpoint-packet-loss"></a>

`{ECS_AGENT_URI}/fault/v1/network-packet-loss` 端點會將封包遺失新增至指定的網路介面。此端點與兩種模式相容：
+ **awsvpc** – 變更會套用至任務網路介面
+ **主機** – 變更會套用至預設網路介面

### \$1ECS\$1AGENT\$1URI\$1/fault/v1/network-packet-loss/start
<a name="fis-endpoint-packet-loss-start"></a>

此 `/start` 端點會開始網路封包遺失故障注入，並具有下列參數：

**LossPercent**  
封包遺失百分比

類型：整數

必要：是

**來源**  
IPv4 或 IPv6 位址或 CIDR 區塊的 JSON 陣列，用於故障注入測試。

類型：字串陣列

必要：是

**SourcesToFilter**  
受故障保護的 IPv4 或 IPv6 位址或 CIDR 區塊的 JSON 陣列。`SourcesToFilter` 的優先級高於 `Sources`。

類型：字串陣列

必要：否

以下是使用 `start` 端點的請求範例 (將*紅色*值取代為實際值)：

```
Endpoint: ${ECS_AGENT_URI}/fault/v1/network-packet-loss/start

Http method: POST

{
    "LossPercent": 6,  
    "Sources": ["${IP1}", "${IP2}", ...],
    "SourcesToFilter": ["${IP1}", "${IP2}", ...],
}
```

### \$1ECS\$1AGENT\$1URI\$1/fault/v1/network-packet-loss/stop and /status
<a name="fis-endpoint-packet-loss-stop-status"></a>

`{ECS_AGENT_URI}/fault/v1/network-packet-loss/stop` 端點會停止故障，`{ECS_AGENT_URI}/fault/v1/network-packet-loss/status` 則會檢查故障的狀態。一次僅支援每種類型的一個故障。

以下是使用 `/stop` 與 `/status` 端點的兩個請求範例。兩者都使用 `POST HTTP` 方法。

```
Endpoint: ${ECS_AGENT_URI}/fault/v1/network-packet-loss/stop
```

```
Endpoint: ${{ECS_AGENT_URI}/fault/v1/network-packet-loss/status
```

# 更新 Amazon ECS 服務參數
<a name="update-service-parameters"></a>

建立服務之後，有時可能需要更新服務參數，例如任務數量。

服務排程器啟動新任務時，會使用下列邏輯來決定叢集中的任務置放。
+ 決定叢集中的哪些容器執行個體可以支援服務的任務定義。例如，它們具有所需的 CPU、記憶體、連接埠與容器執行個體屬性。
+ 依預設，服務排程器會嘗試以這種方式平衡可用區域間的任務，即使您可以選擇不同的置放策略。
  + 在執行個體所在可用區域中，依此服務的執行中任務數量下限，對有效容器執行個體進行排序。例如，如果區域 A 有一項執行中的服務任務，而區域 B 和 C 都沒有，則最適合置放的即為區域 B 或 C 中的有效容器執行個體。
  + 將新的服務任務放置在最佳可用區域的有效容器執行個體 (根據先前的步驟)，且偏好此服務中的執行中任務數量最少的容器執行個體。

當服務排程器停止執行中的任務時，會嘗試使用下列邏輯維護叢集中可用區域間的平衡：
+ 在執行個體所在可用區域中，依此服務的執行中任務數量上限，對容器執行個體進行排序。例如，如果區域 A 有一項執行中的服務任務，而區域 B 和 C 各有兩項，則最適合終止的即為區域 B 或 C 中的容器執行個體。
+ 停止最佳可用區域之容器執行個體中的任務 (根據先前的步驟)，且偏好此服務之執行中任務數量最多的容器執行個體。

使用下列清單來判斷您是否可以變更服務參數。

**可用區域重新平衡**  
指出服務是否使用可用區域重新平衡。  
您可以針對滾動部署變更此參數。

**容量提供者策略**  
容量提供者策略的詳細資料。您可以在建立叢集、執行任務或更新服務時設定容量提供者。  
使用 Fargate 時，容量提供者為 `FARGATE` 或 `FARGATE_SPOT`。  
使用 Amazon EC2 時，容量提供者為 Auto Scaling 群組。  
可以針對滾動部署與藍/綠部署變更容量提供者。  
下列清單可提供有效的轉換：  
+ 將 Fargate 更新為 Auto Scaling 群組容量提供者。
+ 將 EC2 更新為 Fargate 容量提供者。
+ 將 Fargate 容量提供者更新為 Auto Scaling 群組容量提供者。
+ 將 Amazon EC2 容量提供者更新為 Fargate 容量提供者。
+ 將 Auto Scaling 群組或 Fargate 容量提供者更新回啟動類型。使用 CLI 或 API 時，需要在 `capacityProviderStrategy` 參數中傳遞空白清單。

**叢集**  
無法變更叢集名稱。

**Deployment configuration (部署組態)**  
部署組態包括用於偵測失敗的 CloudWatch 警示與斷路器，以及所需的組態。  
如果服務無法達到穩定狀態，部署斷路器會確定服務部署是否會失敗。如果使用部署斷路器，服務部署會轉換為失敗狀態並停止啟動新任務。如果使用復原選項，當服務部署失敗後，服務會復原至上一次成功完成的部署。  
更新使用 Amazon ECS 斷路器的服務時，Amazon ECS 會建立服務部署與服務修訂版。這些資源可用於檢視服務歷史記錄的詳細資訊。如需詳細資訊，請參閱[使用 Amazon ECS 服務部署檢視服務歷史記錄](service-deployment.md)。  
服務排程器 (在服務的部署組態中) 使用運作狀態百分比下限和百分比上限參數，決定部署策略。  
如果服務使用滾動更新 (`ECS`) 部署類型，則**運作狀態百分比下限**代表部署期間，服務中必須保持在 `RUNNING` 狀態的任務數量下限，以所需任務數量百分比表示 (無條件進位到最接近的整數)。如果服務包含使用 EC2 的任務，即使有任何容器執行個體處於 `DRAINING` 狀態，此參數也適用。使用此參數進行部署，無須使用額外的叢集容量。例如，如果您的服務所需任務數量為四項，且運作狀態百分比下限為 50%，則排程器可先停止兩項現有的任務以釋出叢集容量，再啟動兩項新的任務。對於未使用負載平衡器的服務，如果任務處於 `RUNNING` 狀態，則服務會將任務視為運作狀態良好。對於使用負載平衡器的服務，如果任務處於 `RUNNING` 狀態且負載平衡器也回報為運作狀態良好，則服務會將任務視為運作狀態良好。運作狀態百分比下限的預設值為 100%。  
如果服務使用滾動更新 (`ECS`) 部署類型，則**百分比上限**參數代表在部署期間，服務中允許處於 `PENDING`、`RUNNING` 或 `STOPPING` 狀態的任務數量上限，以所需任務數量百分比表示 (無條件捨去到最接近的整數)。如果服務包含使用 EC2 的任務，即使有任何容器執行個體處於 `DRAINING` 狀態，此參數也適用。使用此參數來定義部署批次大小。例如，如果您的服務有所需的四個任務數目及百分比上限值 200%，則排程器可先啟動四項新任務，再停止四項舊任務。前提是有執行此操作所需的叢集資源。百分比上限的預設值為 200%。  
當服務排程器於更新期間取代任務時，服務會先從負載平衡器 (如果使用) 移除任務，並等待連線耗盡。然後，對任務中執行的容器發出相當於 **docker stop** 的命令。這會造成 `SIGTERM` 信號和 30 秒逾時，並在之後傳送 `SIGKILL`，強制停止容器。如果容器在接收到 `SIGTERM` 信號後於 30 秒內從容處理完畢並結束，就不會傳送任何 `SIGKILL` 信號。服務排程器依據您定義的運作狀態百分比下限和百分比上限設定，啟動和停止任務。  
在容器運作狀態檢查或負載平衡器目標群組運作狀態檢查失敗後，服務排程器也會取代判定為狀況不佳的任務。此取代取決於 `maximumPercent` 和 `desiredCount` 服務定義參數。如果任務標記為運作狀態不佳，服務排程器會先啟動替代任務。然後會發生下列情況。  
+ 如果替代任務的運作狀態為 `HEALTHY`，服務排程器會停止運作狀態不良的任務
+ 如果替代任務的運作狀態為 `UNHEALTHY`，排程器會停止運作狀態不佳的替代任務或現有運作狀態不佳的任務，以使任務總計數等於 `desiredCount`。
如果 `maximumPercent` 參數限制排程器先啟動替代任務，排程器會隨機停止運作狀態不佳的任務，以釋放容量，然後啟動替代任務。開始和停止程序會繼續進行，直到所有運作狀態不佳的任務都會取代為運作狀態良好的 一旦已取代了所有運作狀態不佳的任務，而且只執行運作狀態良好的任務，如果任務總數超過 `desiredCount`，則運作良好的任務會隨機停止，直到任務總計數等於 `desiredCount` 為止。如需有關 `maximumPercent` 和 `desiredCount` 的詳細資訊，請參閱[服務定義參數](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service_definition_parameters.html)。

**部署控制器**  
用於服務的部署控制器。部署控制器有三種類型：  
+ `ECS`
+ `EXTERNAL`
+ `CODE_DEPLOY`
更新服務時，可以更新其使用的部署控制器。下列清單可提供有效的轉換：  
+ 將 CodeDeploy 藍/綠部署 (`CODE_DEPLOY`) 更新為 ECS 滾動部署或藍/綠部署 (`ECS`)。
+ 將 CodeDeploy 藍/綠部署 (`CODE_DEPLOY`) 更新為外部部署 (`EXTERNAL`)。
+ 將 ECS 滾動部署或藍/綠部署 (`ECS`) 更新為外部部署 (`EXTERNAL`)。
+ 將外部部署 (`EXTERNAL`) 更新為 ECS 滾動部署或藍/綠部署 (`ECS`)。
更新服務的部署控制器時，請考量下列事項：  
+ 如果服務使用 VPC Lattice 或 Amazon ECS Service Connect，則無法將服務的部署控制器從 `ECS` 部署控制器更新為任何其他控制器。
+ 在正在進行的服務部署期間，無法更新服務的部署控制器。
+ 如果服務上沒有負載平衡器，則無法將服務的部署控制器更新為 `CODE_DEPLOY`。
+ 如果 `deploymentConfiguration` 包含警示、部署斷路器或 `BLUE_GREEN` 部署策略，則無法將服務的部署控制器從 `ECS` 更新為任何其他控制器。如需詳細資訊，請參閱[Amazon ECS 服務部署控制器與策略](ecs_service-options.md)。
+ 如果您將服務的部署控制器從 `ECS` 更新為任何其他控制器，Amazon ECS 將不會使用您在容器定義中為 `versionConsistency` 指定的值。
+ 如果您將服務的部署控制器從 `ECS` 更新為任何其他控制器，`UpdateService` 與 `DescribeService` API 回應仍將傳回 `deployments` 而不是 `taskSets`。如需有關 `UpdateService` 與 `CreateService` 的詳細資訊，請參閱 *Amazon ECS API Reference* 中的 [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_Service.html) 與 [CreateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_Service.html)。
+ 如果服務使用滾動更新部署策略，將部署控制器從 `ECS` 更新為任何其他控制器會變更 `deploymentConfiguration` 中 `maximumPercent` 值的使用方式。`maximumPercent` 不僅僅用作滾動更新部署中的總任務數量上限，還用於取代運作狀態不良的任務。如需有關排程器如何取代運作狀態不良任務的詳細資訊，請參閱 [Amazon ECS 服務](ecs_services.md)。
+ 如果您將服務的部署控制器從 `ECS` 更新為任何其他部署控制器，則系統會忽略使用負載平衡器組態指定的任何 `advancedConfiguration`。如需詳細資訊，請參閱 *Amazon ECS API reference* 中的 [LoadBalancer](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_LoadBalancer.html) 與 [AdvancedConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_AdvancedConfiguration.html)。
使用 CloudFormation 更新服務的部署控制器時，請根據正在執行的遷移類型，考量下列事項。  
+ 如果 CloudFormation 範本包含 `EXTERNAL` 部署控制器資訊以及 `TaskSet` 與 `PrimaryTaskSet` 資源，並且在從 `EXTERNAL` 更新為 `ECS` 時從範本中移除任務集資源，則在部署控制器更新為 `ECS` 後，`DescribeTaskSet` 與 `DeleteTaskSet` API 呼叫會傳回 400 錯誤。這會導致 CloudFormation 刪除任務集資源失敗，即使 CloudFormation 堆疊轉換為 `UPDATE_COMPLETE` 狀態，也是如此。如需詳細資訊，請參閱 AWS CloudFormation User Guide 中的 [Resource removed from stack but not deleted](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/troubleshooting.html#troubleshooting-errors-resource-removed-not-deleted)。若要修正此問題，請使用 Amazon ECS `DeleteTaskSet` API 直接刪除任務集。如需有關如何刪除任務集的詳細資訊，請參閱 *Amazon Elastic Container Service* *API Reference* 中的 [DeleteTaskSet](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DeleteTaskSet.html)。
+ 如果要從 `CODE_DEPLOY` 遷移至 `ECS` 並使用新的任務定義，且 CloudFormation 執行復原操作，則 Amazon ECS `UpdateService` 請求會失敗，並顯示下列錯誤：

  ```
  Resource handler returned message: "Invalid request provided: Unable to update 
  task definition on services with a CODE_DEPLOY deployment controller. Use AWS 
  CodeDeploy to trigger a new deployment. (Service: Ecs, Status Code: 400, 
  Request ID: 0abda1e2-f7b3-4e96-b6e9-c8bc585181ac) (SDK Attempt Count: 1)" 
  (RequestToken: ba8767eb-c99e-efed-6ec8-25011d9473f0, HandlerErrorCode: InvalidRequest)
  ```
+ 從 `ECS` 成功遷移至 `EXTERNAL` 部署控制器後，需要手動移除 `ACTIVE` 任務集，因為 Amazon ECS 不再管理該部署。如需有關如何刪除任務集的資訊，請參閱 Amazon Elastic Container Service *API Reference* 中的 [DeleteTaskSet](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DeleteTaskSet.html)。

**所需的任務計數**  
要在服務中置放並保持執行的任務執行個體數量。  
若要暫時停止服務，請將此值設定為 0。然後，當您準備好啟動服務時，請使用原始值更新服務。  
可以針對滾動部署與藍/綠部署變更此參數。

**啟用受管標籤**  
決定是否為服務中的任務啟用 Amazon ECS 受管標籤。  
只有更新後啟動的任務才會反映更新。若要更新所有任務上的標籤，請使用強制部署選項。  
可以針對滾動部署與藍/綠部署變更此參數。

**啟用 ECS Exec**  
決定是否使用 Amazon ECS Exec。  
如果不想覆寫建立服務時設定的值，可以在執行此動作時將此值設定為 null。  
您可以針對滾動部署變更此參數。

**運作狀態檢查寬限期**  
所謂寬限期是指 Amazon ECS 服務排程器在任務首次啟動後，會在這段期間內 (以秒為單位) 忽略運作狀態不良的 Elastic Load Balancing、VPC Lattice 與容器運作狀態檢查。如果您未指定運作狀態檢查寬限期值，則會使用預設值 `0`。如果未使用任何運作狀態檢查，`healthCheckGracePeriodSeconds` 會處於未使用狀態。  
若服務的任務需要一些時間來啟動及回應運作狀態檢查，您可以指定運作狀態檢查的寬限期，最長為 2,147,483,647 秒 (約 69 年)。在此期間，Amazon ECS 服務排程器會忽略運作狀態檢查情形。此寬限期可防止服務排程器將任務標示為狀況不良並在其來得及標示前加以停止。  
可以針對滾動部署與藍/綠部署變更此參數。

**負載平衡器**  
更新負載平衡器時，必須使用服務連結角色。  
Elastic Load Balancing 負載平衡器物件的清單。該清單包含負載平衡器名稱、容器名稱，以及要從負載平衡器存取的容器連接埠。容器名稱是在容器定義中顯示的名稱。  
Amazon ECS 不會自動更新與 Elastic Load Balancing 負載平衡器或 Amazon ECS 容器執行個體相關聯的安全群組。  
當您新增、更新或移除負載平衡器組態時，Amazon ECS 會使用更新後的 Elastic Load Balancing 組態啟動新任務，然後在新任務執行時停止舊任務。  
對於使用滾動更新的服務，可以新增、更新或移除 Elastic Load Balancing 目標群組。您可以從單一目標群組更新為多個目標群組，也可以從多個目標群組更新為單一目標群組。  
對於使用藍/綠部署的服務，可以透過 CodeDeploy 使用 `[CreateDeployment](https://docs.aws.amazon.com/codedeploy/latest/APIReference/API_CreateDeployment.html)` 來更新 Elastic Load Balancing 目標群組。請注意，藍/綠部署不支援多個目標群組。如需詳細資訊，請參閱[向服務註冊多個目標群組](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/register-multiple-targetgroups.html)。  
對於使用外部部署控制器的服務，可以使用 [CreateTaskSet](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateTaskSet.html) 來新增、更新或移除負載平衡器。請注意，外部部署不支援多個目標群組。如需詳細資訊，請參閱[向服務註冊多個目標群組](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/register-multiple-targetgroups.html)。  
傳遞空白清單以移除負載平衡器。  
您可以針對滾動部署變更此參數。

**網路組態**  
服務網路組態。  
您可以針對滾動部署變更此參數。

**置放限制條件**  
要更新服務以使用的任務置放限制條件物件陣列。如果未指定任何值，則服務的現有置放限制條件將保持不變。如果指定此值，則會覆寫為服務定義的任何現有置放限制條件。若要移除所有現有的置放限制條件，請指定空陣列。  
您最多可以為每項任務指定 10 項限制條件。此限制包含任務定義中的限制條件以及執行時間指定的限制條件。  
可以針對滾動部署與藍/綠部署變更此參數。

**置放策略**  
要更新服務以使用的任務置放策略物件。如果未指定任何值，則服務的現有置放策略將保持不變。如果指定此值，則會覆寫為服務定義的現有置放策略。若要移除現有的置放策略，請指定空白物件。  
可以針對滾動部署與藍/綠部署變更此參數。

**平台版本**  
服務執行所在的 Fargate 平台版本。  
使用 Linux 平台版本的服務無法更新為使用 Windows 平台版本，反之亦然。  
您可以針對滾動部署變更此參數。

**傳播標籤**  
決定是否將標籤從任務定義或服務傳播到任務。如果沒有指定值，則不會傳播標籤。  
只有更新後啟動的任務才會反映更新。若要更新所有任務上的標籤，請將 `forceNewDeployment` 設定為 `true`，以便 Amazon ECS 使用更新後的標籤啟動新任務。  
可以針對滾動部署與藍/綠部署變更此參數。

**Service Connect 組態**  
Amazon ECS Service Connect 的組態。此參數可決定服務如何連線至應用程式中的其他服務。  
您可以針對滾動部署變更此參數。

**服務登錄檔**  
更新服務登錄檔時，必須使用服務連結角色。  
要指派給此服務的服務探索登錄檔的詳細資訊。如需詳細資訊，請參閱[服務探索](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-discovery.html)。  
當您新增、更新或移除服務登錄檔組態時，Amazon ECS 會使用更新後的服務登錄檔組態啟動新任務，然後在新任務執行時停止舊任務。  
傳遞空白清單以移除服務登錄檔。  
您可以針對滾動部署變更此參數。

**任務定義**  
用於服務的任務定義與修訂版。  
如果變更任務定義中容器使用的連接埠，則可能需要更新容器執行個體的安全群組，才能使用更新後的連接埠。  
如果您為服務更新任務定義，則在負載平衡器組態中指定的容器名稱和容器連接埠必須保留在任務定義中。  
容器映像提取行為會因運算選項而有所不同。如需詳細資訊，請參閱下列其中一個項目：  
+ [為 Amazon ECS 規劃 AWS Fargate 架構](AWS_Fargate.md)
+ [為 Amazon ECS 規劃 EC2 容量架構](launch-type-ec2.md)
+ [Amazon ECS 的外部執行個體 (Amazon ECS Anywhere)](launch-type-external.md)
您可以針對滾動部署變更此參數。

**磁碟區組態**  
磁碟區的詳細資訊，即 `configuredAtLaunch`。將任務定義中的 `configuredAtLaunch` 設定為 `true` 時，此服務參數會為服務中的每項任務設定一個 Amazon EBS 磁碟區，以便在部署期間建立與連接。您可以在 [ServiceManagedEBSVolumeConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ServiceManagedEBSVolumeConfiguration.html) 中設定大小、volumeType、IOPS、輸送量、快照與加密。磁碟區的 `name` 必須與任務定義中的 `name` 相符。如果設定為 null，則不會觸發新的部署。否則，如果此組態與現有組態不同，則會觸發新的部署。  
您可以針對滾動部署變更此參數。

**VPC Lattice 組態**  
服務的 VPC Lattice 組態。這會定義服務如何與 VPC Lattice 整合以進行服務間通訊。  
您可以針對滾動部署變更此參數。

## AWS CDK 考量事項
<a name="cdk-considerations"></a>

 AWS CDK 不會追蹤資源狀態。它不知道您是在建立服務還是更新服務。客戶應使用逃生艙直接存取 ecs `Service` L1 建構模組。

如需逃生艙的相關資訊，請參閱《 *AWS Cloud Development Kit (AWS CDK) v2 開發人員指南*》中的[從 AWS 建構程式庫自訂建構](https://docs.aws.amazon.com/cdk/v2/guide/cfn-layer.html#develop-customize-escape)。

若要將現有服務遷移至 `ecs.Service` 建構模組，請執行下列動作：

1. 使用逃生艙存取 `Service` L1 建構模組。

1. 在 `Service` L1 建構模組中手動設定下列屬性。

   如果服務使用 Amazon EC2 容量：
   + `daemon?`
   + `placementConstraints?`
   + `placementStrategies?`
   + 如果使用 `awsvpc` 網路模式，則需要設定 `vpcSubnets?` 與 `securityGroups?` 建構模組。

   如果服務使用 Fargate：
   + `FargatePlatformVersion`
   + `vpcSubnets?` 與 `securityGroups?` 建構。

1. 按如下方式設定 `launchType`：

   ```
   const cfnEcsService = service.node.findChild('Service') as ecs.CfnService;
   cfnEcsService.launchType = "FARGATE";
   ```

若要從啟動類型遷移至容量提供者，請執行下列動作：

1. 使用逃生艙存取 `Service` L1 建構模組。

1. 新增 `capacityProviderStrategies?` 建構模組。

1. 部署服務。

# 更新 Amazon ECS 服務
<a name="update-service-console-v2"></a>

建立服務之後，有時可能需要更新服務參數，例如任務數量。

更新使用 Amazon ECS 斷路器的服務時，Amazon ECS 會建立服務部署與服務修訂版。這些資源可用於檢視服務歷史記錄的詳細資訊。如需詳細資訊，請參閱[使用 Amazon ECS 服務部署檢視服務歷史記錄](service-deployment.md)。

## 先決條件
<a name="update-service-prerequisites"></a>

更新服務之前，請先確認部署類型可以變更哪些服務參數。如需可變更參數的完整清單，請參閱[更新 Amazon ECS 服務參數](update-service-parameters.md)。

## 程序
<a name="update-service-procedure"></a>

------
#### [ Console ]

1. 開啟主控台，網址為 [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)。

1. 在**叢集**頁面上，選擇叢集。

1. 在「叢集詳細資訊」頁面上的**服務**區段中，選取服務旁的核取方塊，然後選擇**更新**。

1. 若要讓服務啟動新部署，請選取 **Force new deployment** (強制執行新部署)。

1. 在**任務定義**中，選擇任務定義系列和修訂。
**重要**  
主控台會驗證所選任務定義系列與修訂版是否與定義的運算組態相容。如果您收到警告，請確認已選取任務定義相容性與運算組態。

1. 如果您選擇 **Replica** (複寫)，針對 **Desired tasks** (所需任務)，輸入要在服務中啟動並維護的任務數。

1. 如果選擇**複本**，若要讓 Amazon ECS 監控可用區域間的任務分佈，並在出現不平衡時重新分佈，請在**可用區域服務重新平衡**下，選取**可用區域服務重新平衡**。

1. 針對 **Min running tasks** (執行中任務下限)，輸入部署期間必須維持在 `RUNNING` 狀態的服務任務數量下限，它是所需任務數量的百分比 (無條件進位到最接近的整數)。如需詳細資訊，請參閱[部署組態](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service_definition_parameters.html#sd-deploymentconfiguration)。

1. 針對 **Max running tasks** (執行中任務上限)，輸入部署期間允許的處於 `RUNNING` 或 `PENDING` 狀態的服務任務數目上限，它是所需任務數量的百分比 (無條件捨去到最接近的整數)。

1. 若要設定服務的任務部署方式，請展開**部署選項**區段，然後設定選項。

   1. 在**部署控制器類型**欄位中，指定服務部署控制器。Amazon ECS 主控台支援下列控制器類型：`ECS`。

   1. 在**部署策略**欄位中，選擇 Amazon ECS 用來部署新版本服務的策略。

   1. 根據**部署策略**的選擇，執行下列動作：    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/AmazonECS/latest/developerguide/update-service-console-v2.html)

   1. 若要為生命週期階段執行 Lambda 函式，請在**部署 lifecycle hook** 下為每個唯一的 Lambda 函式執行下列動作：

      1. 選擇**新增**。

         針對每個要執行的唯一函式重複此步驟。

      1. 在 **Lambda 函式**欄位中輸入函式名稱。

      1. 在**角色**欄位中，選擇您在先決條件中建立的具有藍/綠部署許可的角色。

         如需詳細資訊，請參閱[Amazon ECS 藍/綠部署中 Lambda 函式所需的許可](blue-green-permissions.md)。

      1. 在**生命週期階段**欄位中選取 Lambda 函式執行的階段。

      1.  (選用) 在**勾點詳細資訊**欄位中，輸入提供勾點相關資訊的鍵值對。

1. 若要設定 Amazon ECS 如何偵測並處理部署失敗，請展開 **Deployment failure detection** (部署失敗偵測)，然後選擇您的選項。

   1. 若要在任務無法啟動時停止部署，請選取 **Use the Amazon ECS deployment circuit breaker** (使用 Amazon ECS 部署斷路器)。

      在部署斷路器將部署設定為失敗狀態時，若要讓軟體自動將部署復原至上次完成的部署狀態，請選取**失敗時復原**。

   1. 若要根據應用程式指標停止部署，請選取**使用 CloudWatch 警示**。然後，從**CloudWatch 警示名稱**欄位中選擇警示。要建立新的警示，請前往 CloudWatch 主控台。

      在 CloudWatch 警示將部署設定為失敗狀態時，若要讓軟體自動將部署復原至上次完成的部署狀態，請選取**失敗時復原**。

1. 若要變更運算選項，請展開**運算組態**區段，然後執行下列動作：

   1. 對於 上的服務 AWS Fargate，對於**平台版本**，請選擇新版本。

   1. 對於使用容量提供者策略的服務，請針對**容量提供者策略**，執行下列動作：
      + 若要新增其他容量提供者，請選擇 **Add more** (新增更多)。然後，針對 **Capacity provider** (容量提供者)，選擇容量提供者。
      + 若要移除容量提供者，請選擇容量提供者右側的 **Remove** (移除)。

      使用 Auto Scaling 群組容量提供者的服務無法更新為使用 Fargate 容量提供者。使用 Fargate 容量提供者的服務無法更新為使用 Auto Scaling 群組容量提供者。

1. (選用) 若要設定服務自動擴展功能，請展開**服務自動擴展**區段，然後指定下列參數。若要使用預測自動擴展功能 (該功能可查看過去從流量流程載入的資料)，請在建立服務後進行設定。如需詳細資訊，請參閱[使用歷史模式透過預測擴展來擴展 Amazon ECS 服務](predictive-auto-scaling.md)。

   1. 若要使用服務自動擴展，請選取 **Service auto scaling** (服務自動擴展)。

   1. 在**任務數量下限**欄位中，輸入供服務自動擴展功能使用的任務數量下限。所需的計數不會低於此計數。

   1. 在**任務數量上限**中，輸入供服務自動擴展功能使用的任務數量上限。所需的計數不會高於此計數。

   1. 選擇政策類型。在**擴展政策類型**下，選擇下列其中一個選項。    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/AmazonECS/latest/developerguide/update-service-console-v2.html)

1. (選用) 若要使用 Service Connect，請選取 **Turn on Service Connect** (開啟 Service Connect)，然後指定下列項目：

   1. 在 **Service Connect configuration** (Service Connect 組態) 下，指定用戶端模式。
      + 如果服務執行的網路用戶端應用程式只需要連線至命名空間中的其他服務，請選擇**僅用戶端**。
      + 如果服務執行的是網路或 Web 服務應用程式，且需要為此服務提供端點，並連線至命名空間中的其他服務，請選擇 **Client and server** (用戶端和伺服器)。

   1. 若要使用非預設叢集命名空間的命名空間，請在 **Namespace** (命名空間) 欄位中選擇服務命名空間。這可以是在您的 中在相同 AWS 區域 中分別建立的命名空間， AWS 帳戶 或是使用 AWS Resource Access Manager () 與您的帳戶共用的相同區域中的命名空間AWS RAM。如需共用 AWS Cloud Map 命名空間的詳細資訊，請參閱《 *AWS Cloud Map 開發人員指南*》中的[跨帳戶 AWS Cloud Map 命名空間共用](https://docs.aws.amazon.com/cloud-map/latest/dg/sharing-namespaces.html) 

   1. (選用) 指定日誌組態。選取**使用日誌收集**。預設選項會將容器日誌傳送至 CloudWatch 日誌。其他日誌驅動程式選項是使用 AWS FireLens 設定。如需詳細資訊，請參閱[將 Amazon ECS 日誌傳送至 AWS 服務或 AWS Partner](using_firelens.md)。

      下方更詳細地描述了每個容器日誌目的地。
      + **Amazon CloudWatch** – 將任務設定為將容器日誌傳送至 CloudWatch Logs。系統會提供預設日誌驅動程式選項，用來代表您建立 CloudWatch 日誌群組。若要指定不同的日誌群組名稱，請變更驅動程式選項值。
      + **Amazon Data Firehose** – 將任務設定為將容器日誌傳送至 Firehose。系統會提供預設日誌驅動程式選項，用來將日誌傳送至 Firehose 傳送串流。若要指定不同的交付串流名稱，請變更驅動程式選項值。
      + **Amazon Kinesis Data Streams** – 將任務設定為將容器日誌傳送至 Amazon Kinesis Data Streams。系統會提供預設日誌驅動程式選項，用來將日誌傳送至 Kinesis Data Streams 串流。若要指定不同的串流名稱，請變更驅動程式選項值。
      + **Amazon OpenSearch Service** – 將任務設定為將容器日誌傳送至 OpenSearch Service 網域。務必提供日誌驅動程式選項。
      + **Amazon S3**：將任務設定為將容器日誌傳送至 Amazon S3 儲存貯體。系統會提供預設日誌驅動程式選項，但您必須指定有效的 Amazon S3 儲存貯體名稱。

   1. 若要啟用存取日誌，請遵循下列步驟：

      1. 展開**存取日誌組態**。針對**格式**，選擇 **JSON** 或 `TEXT`。

      1. 若要在存取日誌中包含查詢參數，請選取**包含查詢參數**。
**注意**  
若要停用存取日誌，請在**格式化**中選擇**無**。

1. 如果任務使用的資料磁碟區與部署時的組態相容，則可透過展開**磁碟區**區段對磁碟區進行設定。

   磁碟區名稱與磁碟區類型會在建立任務定義修訂版時設定，且無法在更新服務時變更。若要更新磁碟區名稱與類型，必須建立新的任務定義修訂版，並使用新的修訂版來更新服務。    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/AmazonECS/latest/developerguide/update-service-console-v2.html)

1. (選用) 為協助識別您的服務，請展開 **Tags** (標籤) 區段，然後設定標籤。
   + [新增標籤] 選擇**新增標籤**，並執行下列動作：
     + 在**金鑰**欄位中，輸入金鑰名稱。
     + 在**值**中，進入索引鍵值。
   + [移除標籤] 在標籤旁邊，選擇 **移除標籤**。

1. 選擇**更新**。

------
#### [ AWS CLI ]
+ 執行 `update-service`。如需有關執行 命令的資訊，請參閱《 AWS Command Line Interface 參考》中的 [update-service](https://docs.aws.amazon.com/cli/latest/reference/ecs/update-service.html)。

  下列 `update-service` 範例會將服務 `my-http-service` 所需的任務計數更新為 2。

  將 *user-input* 取代為實際值。

  ```
  aws ecs update-service \
      --cluster MyCluster \
      --service my-http-service \
      --desired-count 2
  ```

------

## 後續步驟
<a name="update-service-next-steps"></a>

追蹤部署，並檢視 Amazon ECS 斷路器服務的服務歷史記錄。如需詳細資訊，請參閱[使用 Amazon ECS 服務部署檢視服務歷史記錄](service-deployment.md)。

# 更新 Amazon ECS 服務以使用容量提供者
<a name="update-service-managed-instances"></a>

如果現有服務使用 Amazon EC2 或 Fargate 啟動類型，並且想要使用 Amazon ECS 受管執行個體，則需要更新服務以使用 Amazon ECS 受管執行個體容量提供者。

## 先決條件
<a name="update-service-managed-instances-prerequisites"></a>

為 Amazon ECS 受管執行個體建立容量提供者。如需詳細資訊，請參閱[為 Amazon ECS 受管執行個體建立容量提供者](create-capacity-provider-managed-instances.md)。

## 程序
<a name="update-service-managed-instances-procedure"></a>

------
#### [ Console ]

1. 開啟主控台，網址為 [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)。

1. 在**叢集**頁面上，選擇叢集。

1. 在「叢集詳細資訊」頁面上的**服務**區段中，選取服務旁的核取方塊，然後選擇**更新**。

1. 選取**強制執行新部署**。

1. 在**運算組態**下，選擇「容量提供者策略」。然後，選擇下列其中一項：
   + 如果 Amazon ECS 受管執行個體容量提供者是預設容量提供者，請選擇**使用叢集預設值**。
   + 如果 Amazon ECS 受管執行個體容量提供者不是預設容量提供者，請選擇**使用自訂 (進階)**。選擇 Amazon ECS 受管執行個體容量提供者，然後在**權重**欄位中選擇「1」。

1. 選擇**更新**。

------
#### [ AWS CLI ]
+ 執行 `update-service`。如需有關執行 命令的資訊，請參閱《 AWS Command Line Interface 參考》中的 [update-service](https://docs.aws.amazon.com/cli/latest/reference/ecs/update-service.html)。

  將 *user-input* 取代為實際值。

  ```
  aws ecs update-service \
      --cluster my-cluster \
      --service my-service \
      --capacity-provider-strategy capacityProvider=my-managed-instance-capacity-provider,weight=1 \
      --force-new-deployment
  ```

------

# 使用主控台刪除 Amazon ECS 服務
<a name="delete-service-v2"></a>

以下是您可能會刪除服務的一些原因：
+ 不再需要應用程式
+ 您正在將服務遷移至新環境
+ 沒有主動使用應用程式
+ 應用程式使用的資源超出所需資源，而您正嘗試最佳化成本

刪除之前，服務會自動將規模縮減至零。與該服務關聯的負載平衡器或服務探索資源，不會受到服務刪除的影響。若要刪除您的 Elastic Load Balancing 資源，請視您的負載平衡器類型，參閱下列任一主題：[刪除 Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-delete.html) 或[刪除 Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-delete.html)。

當您刪除服務時，Amazon ECS 會一併刪除服務的所有服務部署與服務修訂版。

刪除服務時，如果仍有需要清理的執行中任務，則服務狀態會從 `ACTIVE` 移至 `DRAINING` 狀態，且服務將不再顯示於主控台或 `ListServices` API 操作中。在所有任務轉換為 `STOPPING` 或 `STOPPED` 狀態後，服務狀態會從 `DRAINING` 變為 `INACTIVE`。使用 `DescribeServices` API 操作仍可檢視處於 `DRAINING` 或 `INACTIVE` 狀態的服務。

**重要**  
如果嘗試建立的新服務與處於 `ACTIVE` 或 `DRAINING` 狀態的現有服務同名，則會收到錯誤。

**程序**

1. 開啟主控台，網址為 [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)。

1. 在 **Clusters** (叢集) 頁面，為服務選取叢集。

1. 在 **Clusters** (叢集) 頁面上，選擇叢集。

1. 在 **Cluster : *name*** (叢集：名稱) 頁面上，選擇 **Services** (服務) 索引標籤。

1. 選取服務，然後選擇 **Delete** (刪除)。

1. 若要刪除服務，即使該服務並未縮減規模至零任務，請選取 **Force delete service** (強制刪除服務)。

1. 在確認提示中，輸入**刪除**，然後選擇**刪除**。

# 將 Amazon ECS 短服務 ARN 移轉到完整 ARN
<a name="service-arn-migration"></a>

Amazon ECS 會為每項服務指派唯一的 Amazon Resource Name (ARN)。在 2021 年之前建立的服務使用短 ARN 格式：

 `arn:aws:ecs:region:aws_account_id:service/service-name`

Amazon ECS 變更了 ARN 格式以包含叢集名稱。這是長 ARN 格式：

`arn:aws:ecs:region:aws_account_id:service/cluster-name/service-name`

您的服務必須具有完整 ARN 格式，才能標記您的服務。

您可以將使用短 ARN 格式的服務遷移至長 ARN 格式，而無需重新建立服務。可以使用 API、CLI 或主控台。遷移操作無法復原。

遷移程序是無縫的，並可確保服務零停機時間。在遷移期間：
+ **服務可用性**：服務會繼續正常執行，而不會中斷流量或功能。
+ **執行中的任務**：現有任務會繼續執行而不會中斷。如果在啟用 `taskLongArnFormat` 帳戶設定的情況下進行遷移，則遷移後啟動的新任務將使用長 ARN 格式。
+ **容器執行個體**：容器執行個體不受服務 ARN 遷移影響，並繼續正常運作。
+ **服務組態**：所有服務設定，包括任務定義、聯網與負載平衡器組態，均保持不變。

如果您想要使用 CloudFormation 以短 ARN 格式標記服務，則必須使用 API、CLI 或主控台遷移服務。遷移完成後，您可以使用 CloudFormation 來標記服務。

若要使用 Terraform 以短 ARN 格式標記服務，則必須透過 API、CLI 或主控台遷移服務。遷移完成後，可以使用 Terraform 來標記服務。

遷移完成後，服務會發生下列變更：
+ 使用長 ARN 格式

  `arn:aws:ecs:region:aws_account_id:service/cluster-name/service-name`
+ 使用主控台進行遷移時，Amazon ECS 會將標籤新增至服務，並將鍵設定為 "ecs：serviceArnMigratedAt"，值設定為遷移時間戳記 (UTC 格式)。

  此標籤會計入標籤配額。
+ 當 CloudFormation 堆疊`PhysicalResourceId`中的 代表服務 ARN 時，該值不會變更，且會繼續為短期服務 ARN。

## 先決條件
<a name="migrate-service-arn-prerequisite"></a>

在遷移服務 ARN 之前，請執行下列操作。

1. 若要查看是否存在短服務 ARN，請在 Amazon ECS 主控台中檢視服務詳細資訊 (如果服務使用短 ARN 格式，您會看到警告)，或檢視 `describe-services` 傳回的 `serviceARN` 參數。如果 ARN 不包含叢集名稱，您將擁有短 ARN。短 ARN 的格式如下：

    `arn:aws:ecs:region:aws_account_id:service/service-name`

1. 請記下建立日期。

1.  如果您有使用短 ARN 格式的 IAM 政策，請將其更新為長 ARN 格式。

   將每個*使用者輸入預留位置*替換為自己的資訊。

    `arn:aws:ecs:region:aws_account_id:service/cluster-name/service-name`

   如需詳細資訊，請參閱《 * AWS Identity and Access Management 使用者指南*》中的[編輯 IAM 政策](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-edit.html)。

1.  如果您有使用短 ARN 格式的工具，請將其更新為長 ARN 格式。

   將每個*使用者輸入預留位置*替換為自己的資訊。

    `arn:aws:ecs:region:aws_account_id:service/cluster-name/service-name`

1. 啟用服務長 ARN 格式。執行 `put-account-setting` 並將 `serviceLongArnFormat` 選項設定為 `enabled`。如需詳細資訊，請參閱 *Amazon Elastic Container Service API Reference* 中的 [put-account-setting](https://docs.aws.amazon.com/cli/latest/reference/ecs/put-account-setting.html)。

   如果服務的 `createdAt` 日期未知，請以根使用者身分執行命令。

   ```
   aws ecs put-account-setting --name serviceLongArnFormat --value enabled
   ```

   範例輸出

   ```
   {
       "setting": {
           "name": "serviceLongArnFormat",
           "value": "enabled",
           "principalArn": "arn:aws:iam::123456789012:role/your-role",
           "type": user
       }
   }
   ```

1. 啟用任務長 ARN 格式。此帳戶設定會控制服務遷移完成後啟動之新任務的 ARN 格式。執行 `put-account-setting` 並將 `taskLongArnFormat` 選項設定為 `enabled`。如需詳細資訊，請參閱 *Amazon Elastic Container Service API Reference* 中的 [put-account-setting](https://docs.aws.amazon.com/cli/latest/reference/ecs/put-account-setting.html)。

   如果服務的 `createdAt` 日期未知，請以根使用者身分執行命令。

   ```
   aws ecs put-account-setting --name taskLongArnFormat --value enabled
   ```

   範例輸出

   ```
   {
       "setting": {
           "name": "taskLongArnFormat",
           "value": "enabled",
           "principalArn": "arn:aws:iam::123456789012:role/your-role",
           "type": user
       }
   }
   ```
**注意**  
`taskLongArnFormat` 設定不會直接遷移現有任務。該設定只會影響啟用設定後所建立之新任務的 ARN 格式。現有的執行中任務會保留其目前的 ARN 格式，直到透過正常服務操作 (例如部署或擴展活動) 該其取代。

## 程序
<a name="migrate-service-arn-procedure"></a>

使用下列方法遷移服務 ARN。

### 主控台
<a name="migrate-service-arn-procedure-console"></a>

1. 開啟主控台，網址為 [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)。

1. 在**叢集**頁面上，選擇叢集。

1. 在**服務**區段中，選擇 ARN 資料欄中包含警告的服務。

   服務資訊頁面隨即顯示。

1. 選擇**遷移至長 ARN**。

   「遷移服務」對話方塊隨即顯示。

1. 選擇 **Migrate (遷移)**。

### CLI
<a name="migrate-service-arn-procedure-cli"></a>

完成先決條件後，即可標記服務。執行以下命令：

Amazon ECS 會將「針對具有短 ARN 的服務，在 `tag-resource` API 請求中傳遞長 ARN 格式」的行為，視為一種要求將該服務遷移至使用長 ARN 格式的訊號。

```
aws ecs tag-resource \
    --resource-arn arn:aws:ecs:region:aws_account_id:service/cluster-name/service-name
    --tags key=key1,value=value1
```

下列範例將使用標籤標記 MyService，並將鍵設定為 "TestService"，值設定為 "WebServers"：

```
aws ecs tag-resource \
    --resource-arn arn:aws:ecs:us-east-1:123456789012:service/MyCluster/MyService
    --tags key=TestService1,value=WebServers
```

### Terraform
<a name="migrate-service-arn-procedure-terraform"></a>

完成先決條件後，即可標記服務。建立 `aws_ecs_service` 資源並設定 `tags` 參考。如需詳細資訊，請參閱 Terraform 文件中的 [Resource： aws\$1ecs\$1service](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/ecs_service)。

```
resource "aws_ecs_service" "MyService" {
  name    = "example"
  cluster = aws_ecs_cluster.MyService.id

 tags = {
 "Name"  =  "MyService"
 "Environment"  =  "Production"
 "Department"  =  "QualityAssurance"
  }
}
```

### 後續步驟
<a name="tag-next-steps"></a>

您可以將標籤新增至服務。如需詳細資訊，請參閱[將標籤新增至 Amazon ECS 資源](tag-resources-console.md)。

如果希望 Amazon ECS 將標籤從任務定義或服務傳播至任務，請使用 `propagateTags` 參數執行 `update-service`。如需詳細資訊，請參閱《* AWS Command Line Interface 參考*》中的 [update-service](https://docs.aws.amazon.com/cli/latest/reference/ecs/update-service.html)。

## 疑難排解
<a name="troubleshooting-arn-migration"></a>

 某些使用者從短 ARN 格式遷移至長 ARN 格式時，可能會遇到下列錯誤。

`There was an error while migrating the ARN of service service-name. The specified account does not have serviceLongArnFormat or taskLongArnFormat account settings enabled. Add account settings in order to enable tagging.` 

 若已啟用 `serviceLongArnFormat` 帳戶設定，但仍遇到此錯誤，可能是因為尚未為最初建立服務的特定 IAM 主體啟用長 ARN 格式的帳戶設定。

1.  識別建立服務的主體。

   1. 在主控台中，可在 Amazon ECS 主控台的「服務詳細資訊」頁面上的**組態與聯網**索引標籤中的**建立者**欄位中取得此資訊。

   1. 針對 AWS CLI，執行下列命令：

      將 *user-input* 取代為實際值。

      ```
      aws ecs describe-services --cluster cluster-name --services service-name --query 'services[0].{createdBy: createdBy}'
      ```

1. 為該特定主體啟用所需的帳戶設定。您可採用下列其中一種方式來這麼做：

   1.  擔任該主體的 IAM 使用者或角色。然後執行 `put-account-setting`。

   1.  使用根使用者執行命令，同時使用 `principal-arn` 指定建立主體。

      範例。

      將 *principal-arn* 取代為步驟 1 中的值。

      ```
      aws ecs put-account-setting --name serviceLongArnFormat --value enabled --principal-arn arn:aws:iam::123456789012:role/jdoe
      ```

 這兩種方法都會在建立服務的主體上啟用所需的 `serviceLongArnFormat` 帳戶設定，從而允許繼續進行 ARN 遷移。

# Amazon ECS 服務限流邏輯
<a name="service-throttle-logic"></a>

Amazon ECS 服務排程器包含保護性邏輯，當任務重複啟動失敗時，會對任務啟動進行限流。這有助於防止不必要的資源消耗並降低成本。

如果服務中的任務未能從 `PENDING` 狀態轉換為 `RUNNING` 狀態，而是直接移至 `STOPPED` 狀態，排程器會：
+ 遞增重新啟動嘗試之間的間隔時間
+ 持續增加延遲，直至兩次嘗試之間的間隔達到上限 27 分鐘
+ 產生服務事件訊息以通知您問題

**注意**  
27 分鐘的延遲期間上限可能會在未來更新中發生變更。

啟用限流後，您會收到此服務事件訊息：

```
(service service-name) is unable to consistently start tasks successfully.
```

節流邏輯的重要特性：
+ 服務會無限期地繼續重試嘗試
+ 唯一的修改是增加了重新啟動之間的間隔時間
+ 沒有使用者可設定的參數

## 解決限流問題
<a name="resolving-throttling"></a>

若要解決限流問題，您可以：
+ 更新服務以使用新的任務定義，這會立即將服務回復到正常、非限流的運作狀態。如需詳細資訊，請參閱[更新 Amazon ECS 服務](update-service-console-v2.md)。
+ 解決導致任務失敗的根本原因。

觸發限流的常見任務失敗原因包括：
+ 叢集資源不足 (連接埠、記憶體或 CPU)
  + 由[資源不足的服務事件訊息](service-event-messages-list.md#service-event-messages-1)指示
+ 容器映像提取失敗
  + 可能由無效的映像名稱、標籤或許可不足造成
  + 導致 [檢視 Amazon ECS 已停止任務錯誤](stopped-task-errors.md) 中的 `CannotPullContainerError`
+ 磁碟空間不足
  + 導致[已停止任務錯誤](stopped-task-errors.md)中的 `CannotCreateContainerError`
  + 如需解析步驟，請參閱[在 Amazon ECS 中對 Docker `API error (500): devmapper` 進行疑難排解](CannotCreateContainerError.md)

**重要**  
以下情況不會觸發限流邏輯：  
達到 `RUNNING` 狀態後停止的任務
因 Elastic Load Balancing 運作狀態檢查失敗而停止的任務
容器命令在達到 `RUNNING` 狀態後以非零代碼結束的任務

# Amazon ECS 服務定義參數
<a name="service_definition_parameters"></a>

服務定義會定義您的 Amazon ECS 服務的執行方式。下列參數可以在服務定義中指定。

## 啟動類型
<a name="sd-launchtype"></a>

`launchType`  
類型：字串  
有效值：`EC2` \$1 `FARGATE` \$1 `EXTERNAL`  
必要：否  
您服務執行所在的啟動類型。如果未指定啟動類型，預設會使用預設的 `capacityProviderStrategy`。  
更新服務時，此參數會觸發新的服務部署。  
若有指定 `launchType`，則必須省略 `capacityProviderStrategy` 參數。

## 容量提供者策略
<a name="sd-capacityproviderstrategy"></a>

`capacityProviderStrategy`  
類型： 物件陣列  
必要：否  
要用於服務的容量提供者策略。  
更新服務時，此參數不會觸發新的服務部署。  
容量提供者策略包含一個或多個容量提供者，以及指派給這些容量提供者的 `base` 與 `weight`。容量提供者必須與要在容量提供者策略中使用的叢集相關聯。PutClusterCapacityProviders API 是用於將容量提供者與叢集相關聯。只能使用具有 `ACTIVE` 或 `UPDATING` 狀態的容量提供者。  
若有指定 `capacityProviderStrategy`，則必須省略 `launchType` 參數。如果沒有指定 `capacityProviderStrategy` 或 `launchType`，則會使用叢集的 `defaultCapacityProviderStrategy`。  
如果您想要指定使用 Auto Scaling 群組的容量提供者，則必須已經建立該容量提供者。可以使用 CreateCapacityProvider API 操作來建立新的容量提供者。  
若要使用 AWS Fargate 容量提供者，請指定 `FARGATE`或 `FARGATE_SPOT` 容量提供者。 AWS Fargate 容量提供者適用於所有帳戶，且只需要與要使用的叢集建立關聯。  
PutClusterCapacityProviders API 操作是用來在建立叢集之後，更新叢集的可用容量提供者清單。    
`capacityProvider`  <a name="capacityProvider"></a>
類型：字串  
必要：是  
容量提供者的簡短名稱或完整 Amazon Resource Name (ARN)。  
`weight`  <a name="weight"></a>
類型：整數  
有效範圍：介於 0 到 1,000 之間的整數。  
必要：否  
加權值會指定應使用指定容量提供者其已啟動任務總數的相對百分比。  
例如，假設您的策略包含兩個容量提供者，且兩者的加權值都是一。當基本條件符合時，工作會平均分配給兩個容量提供者。以此類推，假設您為 *capacityProviderA* 指定了加權值 1；並為 *capacityProviderB* 指定了加權值 4。那麼，每有一個任務使用 *capacityProviderA* 執行，就會有四個任務是使用 *capacityProviderB* 執行。  
`base`  <a name="base"></a>
類型：整數  
有效範圍：介於 0 到 100,000 之間的整數。  
必要：否  
基礎值指定至少要在指定容量提供者上執行多少任務數量。容量提供者策略中只有一個容量提供者可以定義基礎。

## 任務定義
<a name="sd-taskdefinition"></a>

`taskDefinition`  
類型：字串  
必要：否  
`family` 和 `revision` (`family:revision`) 或在您服務中執行的任務定義完整 Amazon Resource Name (ARN)。如果 `revision` 未指定，則會使用指定系列的最新 `ACTIVE` 修訂版。  
更新服務時，此參數會觸發新的服務部署。  
在使用循環更新 (`ECS`) 部署控制器時，必須指定任務定義。

## 平台作業系統
<a name="platform-os"></a>

`platformFamily`  
類型：字串  
必要：有條件  
預設：Linux  
在 Fargate 上託管的 Amazon ECS 服務需要此參數。  
在 Amazon EC2 上託管的 Amazon ECS 服務會忽略此參數。  
執行服務的容器上的作業系統。有效值為 `LINUX`、`WINDOWS_SERVER_2019_FULL`、`WINDOWS_SERVER_2019_CORE`、`WINDOWS_SERVER_2022_FULL` 與 `WINDOWS_SERVER_2022_CORE`。  
為服務指定的每個任務的 `platformFamily` 值必須與服務 `platformFamily` 值相符。例如，如果您將 `platformFamily` 設定為 `WINDOWS_SERVER_2019_FULL`，則所有任務的 `platformFamily` 值都必須為 `WINDOWS_SERVER_2019_FULL`。

## 平台版本
<a name="sd-platformversion"></a>

`platformVersion`  
類型：字串  
必要：否  
您服務中任務正在其上執行的平台版本。平台版本僅會為使用 Fargate 啟動類型的任務指定。如果尚未指定，預設會使用最新版本 (`LATEST`)。  
更新服務時，此參數會觸發新的服務部署。  
AWS Fargate 平台版本用於參考 Fargate 任務基礎設施的特定執行期環境。在您執行任務或建立服務時指定 `LATEST` 平台版本，即可取得任務所能使用的最新平台版本。當您擴展服務規模時，這些任務會收到於服務的目前部署上所指定的平台版本。如需詳細資訊，請參閱[適用於 Amazon ECS 的 Fargate 平台版本](platform-fargate.md)。  
並未針對使用 EC2 啟動類型的任務指定平台版本。

## 叢集
<a name="sd-cluster"></a>

`cluster`  
類型：字串  
必要：否  
您服務執行所在之叢集的 Amazon Resource Name (ARN) 簡稱或全稱。若您未指定叢集，即假設您會使用 `default` 叢集。

## 服務名稱
<a name="sd-servicename"></a>

`serviceName`  
類型：字串  
必要：是  
您的服務名稱。最多允許 255 個字母 （大寫和小寫）、數字、連字號和底線。叢集中不得有相同的服務名稱，但一個區域內或多個區域間的多個叢集中可以有類似的服務名稱。

## 排程策略
<a name="sd-schedulingstrategy"></a>

`schedulingStrategy`  
類型：字串  
有效值：`REPLICA` \$1 `DAEMON`  
必要：否  
使用的排程策略。如果未指定排程策略，則會使用 `REPLICA` 策略。如需詳細資訊，請參閱[Amazon ECS 服務](ecs_services.md)。  
現已推出兩個服務排程器策略概念：  
+ `REPLICA` - 複本排程策略會置放並在整個叢集中維持所需的任務數量。根據預設，服務排程器會將任務分散至各個可用區域。您可以使用任務置放策略和限制條件，來自訂任務置放決策。如需詳細資訊，請參閱[複本排程策略](ecs_service-options.md#service_scheduler_replica)。
+ `DAEMON` - 常駐程式排程策略會在每個符合您於叢集中所指定所有任務置放限制條件的作用中容器執行個體上，準確地部署一個任務。使用這項策略時，不需指定所需的任務數量、任務置放策略或使用 Service Auto Scaling 政策。如需詳細資訊，請參閱[常駐程式排程策略](ecs_service-options.md#service_scheduler_daemon)。
**注意**  
Fargate 任務不支援 `DAEMON` 排程策略。

## 所需計數
<a name="sd-desiredcount"></a>

`desiredCount`  
類型：整數  
必要：否  
於指定的任務定義中，要放置在您服務上並保持執行的實例數量。  
更新服務時，此參數不會觸發新的服務部署。  
如果使用 `REPLICA` 排程策略，則需要此參數。如果該服務使用 `DAEMON` 排程策略，則此參數是選擇性的。  
當您使用服務自動擴展時，如果以少於目前執行中任務數量的 `desiredCount` 更新目前執行中的服務，該服務會縮減規模至指定的 `desiredCount`。

## Deployment configuration (部署組態)
<a name="sd-deploymentconfiguration"></a>

`deploymentConfiguration`  
類型：物件  
必要：否  
選用的部署參數，可控制在部署期間執行多少任務以及停止和啟動任務的順序。  
更新服務時，此參數不會觸發新的服務部署。    
`maximumPercent`  <a name="maximumPercent"></a>
類型：整數  
必要：否  
如果服務使用滾動更新 (`ECS`) 部署類型，則 `maximumPercent` 參數代表在部署期間，服務中允許處於 `RUNNING`、`STOPPING` 或 `PENDING` 狀態的任務數量上限。以百分比表示 `desiredCount` 即無條件捨去至最接近的整數。您可以使用此參數來定義部署批次大小。例如，如果服務使用 `REPLICA` 服務排程器、`desiredCount` 為 4 項任務，且 `maximumPercent` 值為 200%，則排程器可能會先啟動四項新任務，再停止四項舊任務。前提是有執行此操作所需的叢集資源。使用 `REPLICA` 服務排程器的服務，其預設 `maximumPercent` 值為 200%。  
只要用於啟動替代任務的叢集資源可用，Amazon ECS 排程器就會使用此參數，透過先啟動替代任務然後停止運作狀態不良的任務，來取代運作狀態不良的任務。如需有關排程器如何取代運作狀態不良任務的詳細資訊，請參閱 [Amazon ECS 服務](ecs_services.md)。  
如果您的服務使用 `DAEMON` 服務排程器類型，`maximumPercent` 應該維持 100%。這是預設值。  
部署期間的任務最大數量等於 `desiredCount` 乘以 `maximumPercent`/100，無條件捨去到最接近的整數值。  
如果服務使用藍/綠 (`CODE_DEPLOY`) 或 `EXTERNAL` 部署類型且任務使用 EC2 啟動類型，則**百分比上限**值會設定為預設值。該值用於定義容器執行個體處於 `DRAINING` 狀態時，服務中保持在 `RUNNING` 狀態的任務數量上限。  
對於使用藍/綠 (`CODE_DEPLOY`) 或 `EXTERNAL` 部署類型且任務使用 EC2 的服務，您無法指定自訂的 `maximumPercent` 值。
如果服務使用藍/綠 (`CODE_DEPLOY`) 或 `EXTERNAL` 部署類型，且服務中的任務使用 Fargate，則不會使用百分比上限值。在描述服務時仍會傳回該值。  
`minimumHealthyPercent`  <a name="minimumHealthyPercent"></a>
類型：整數  
必要：否  
如果服務使用滾動更新 (`ECS`) 部署類型，則 `minimumHealthyPercent` 表示部署期間必須保持在 `RUNNING` 狀態的服務任務數量下限。這表示為無條件進位到最接近整數的 `desiredCount` 的百分比。您可以使用此參數，而無須使用額外的叢集容量進行部署。  
例如，如果服務的 `desiredCount` 為 4 項任務，且 `minimumHealthyPercent` 為 50%，`maximumPercent` 為 100%，則服務排程器會先停止兩項現有任務以釋出叢集容量，再啟動兩項新任務。  
 如果任何任務運作狀態不良，並且 `maximumPercent` 不允許 Amazon ECS 排程器啟動替代任務，則排程器會將 `minimumHealthyPercent` 用作限制條件，逐個停止運作狀態不佳的任務，清理容量以啟動替代任務。如需有關排程器如何取代運作狀態不良任務的詳細資訊，請參閱 [Amazon ECS 服務](ecs_services.md)。  
對於*不*使用負載平衡器的服務，請考慮下列事項：  
+ 如果服務中任務內的所有必要容器都通過了運作狀態檢查，則服務就會被視為狀態良好。
+ 如果工作沒有已定義運作狀態檢查的必要容器，則服務排程器會在任務達到 `RUNNING` 狀態時等待 40 秒，然後再將任務計入運作狀態最低百分比總計。
+ 如果任務有一或多個已定義運作狀態檢查的必要容器，服務排程器會等待任務達到正常狀態，然後將其計算為運作狀態最低百分比總計。當任務內的所有必要容器都通過其運作狀態檢查時，工作就會被視為狀態良好。服務排程器可以等待的時間，是由容器運作狀態檢查設定所決定。如需詳細資訊，請參閱[運作狀態檢查](task_definition_parameters.md#container_definition_healthcheck)。
對於*會*使用負載平衡器的服務，請考慮下列事項：  
+ 如果任務沒有定義運作狀態檢查的必要容器，則服務排程器會等待負載平衡器目標群組運作狀態檢查回傳狀況良好狀態，然後將任務計算為良好狀態最低百分比總計。
+ 如果工作具有已定義運作狀態檢查的必要容器，服務排程器會等待工作達到正常狀態，以及負載平衡器目標群組運作狀態檢查回傳狀況良好狀態，然後再將工作計算為最低良好狀態百分比總計。
`minimumHealthyPercent` 的複本服務預設值是 100%。使用服務排程`DAEMON`的服務`minimumHealthyPercent`預設值為 0% AWS CLI、 AWS SDKs 和 APIs，以及 50% AWS 管理主控台。  
部署期間運作良好任務的最低數量等於 `desiredCount` 乘以 `minimumHealthyPercent`/100，無條件進位到最接近的整數值。  
如果服務使用藍/綠 (`CODE_DEPLOY`) 或 `EXTERNAL` 部署類型且使用 EC2 的任務在執行中，則**運作狀態百分比下限**值會設定為預設值。該值用於定義容器執行個體處於 `DRAINING` 狀態時，服務中保持在 `RUNNING` 狀態的任務數量下限。  
對於使用藍/綠 (`CODE_DEPLOY`) 或 `EXTERNAL` 部署類型且任務使用 EC2 的服務，您無法指定自訂的 `maximumPercent` 值。
若服務使用的是藍/綠 (`CODE_DEPLOY`) 或 `EXTERNAL` 部署類型，並且使用 Fargate 的任務在執行中，則不會使用運作狀態百分比下限值，儘管描述服務時會傳回該值。

## 部署控制器
<a name="sd-deploymentcontroller"></a>

`deploymentController`  
類型：物件  
必要：否  
用於服務的部署控制器。如果沒有指定部署控制器，則使用 `ECS` 控制器。如需詳細資訊，請參閱[Amazon ECS 服務](ecs_services.md)。  
更新服務時，此參數不會觸發新的服務部署。    
`type`  
類型：字串  
有效值：`ECS` \$1 `CODE_DEPLOY` \$1 `EXTERNAL`  
必要：是  
要使用的部署控制器類型。部署控制器有三種類型：    
`ECS`  
Amazon ECS 部署控制器支援多種部署策略：滾動更新、藍/綠、線性和金絲雀。滾動更新部署類型涉及將容器的目前執行版本取代為最新版本。藍/綠部署會建立新的環境，並一次轉移流量。線性部署會以相等的百分比增量逐漸轉移流量。Canary 部署會先轉移一小部分的流量，然後轉移剩餘的流量。調整在服務部署期間允許的運作良好任務的最小和最大數量，可以控制 Amazon ECS 在滾動式更新期間新增或移除的容器數量，如同 [deploymentConfiguration](#deploymentConfiguration) 中所指定。  
`CODE_DEPLOY`  
藍/綠部署類型 (`CODE_DEPLOY`) 使用 CodeDeploy 支援的藍/綠部署模式，讓您可以在傳送生產流量之前驗證新部署的服務。  
`EXTERNAL`  
當您想要使用任何第三方部署控制器，以完全控制 Amazon ECS 服務的部署程序時，請使用外部部署類型。

## 任務置放
<a name="sd-taskplacement"></a>

`placementConstraints`  
類型： 物件陣列  
必要：否  
您服務的任務要使用的置放限制物件陣列。每項任務您最多可以指定 10 項限制。此限制包含任務定義中的限制以及執行時間指定的限制。如果使用 Fargate，則不支援任務置放限制條件。  
更新服務時，此參數不會觸發新的服務部署。    
`type`  
類型：字串  
必要：否  
限制類型。使用 `distinctInstance` 以確保特定群組中的每個任務執行於不同的容器執行個體。使用 `memberOf`，以將選擇限制於特定群組或有效的待選項目。任務定義並不支援 `distinctInstance` 值。  
`expression`  
類型：字串  
必要：否  
限制所套用的叢集查詢語言運算式。如果限制條件類型為 `distinctInstance`，則無法指定運算式。如需詳細資訊，請參閱[建立表達式以定義 Amazon ECS 任務的容器執行個體](cluster-query-language.md)。

`placementStrategy`  
類型： 物件陣列  
必要：否  
您服務的任務要使用的置放策略物件。每項服務您最多可以指定四項策略規則。  
更新服務時，此參數不會觸發新的服務部署。    
`type`  
類型：字串  
有效值：`random` \$1 `spread` \$1 `binpack`  
必要：否  
置放策略類型。`random` 置放策略會將任務隨機置放於各個可用的待選項目。`spread` 置放策略根據 `field` 參數，以平均分散的方式置放於各個可用的待選項目。`binpack` 策略會根據以 `field` 參數指定的結果，將任務置放於資源最少的可用待選項目。例如，如果您在記憶體上進行 binpack，任務會放置在剩餘記憶體最少，但仍足以執行任務的執行個體上。  
`field`  
類型：字串  
必要：否  
套用置放策略的欄位。若是 `spread` 置放策略，有效的值為 `instanceId` (或擁有相同效果的 `host`)，或任何平台以及套用至 `attribute:ecs.availability-zone` 等容器執行個體的自訂屬性。若是 `binpack` 置放策略，有效值為 `cpu` 與 `memory`。若是 `random` 置放策略，此欄位並不使用。

## Tags (標籤)
<a name="sd-tags"></a>

`tags`  
類型： 物件陣列  
必要：否  
您套用到服務以協助您分類和組織的中繼資料。每個標籤皆包含由您定義的一個金鑰與一個選用值。刪除服務時，也會一併刪除標籤。服務最多可套用 50 個標籤。如需詳細資訊，請參閱[標記 Amazon ECS 資源](ecs-using-tags.md)。  
更新服務時，此參數不會觸發新的服務部署。    
`key`  
類型：字串  
長度限制：長度下限為 1。長度上限為 128。  
必要：否  
組成標籤的鍵值組的一部分。索引鍵是一般標籤，作用就像更特定標籤值的類別。  
`value`  
類型：字串  
長度限制：長度下限為 0。長度上限為 256。  
必要：否  
組成標籤的鍵值組的選用部分。值就像標籤類別 (索引鍵) 內的描述項。

`enableECSManagedTags`  
類型：布林值  
有效值：`true` \$1 `false`  
必要：否  
指定是否對服務內的任務使用 Amazon ECS 受管標籤。如未指定任何值，則預設值為 `false`。如需詳細資訊，請參閱[將標籤用於計費](ecs-using-tags.md#tag-resources-for-billing)。  
更新服務時，此參數不會觸發新的服務部署。

`propagateTags`  
類型：字串  
有效值：`TASK_DEFINITION` \$1 `SERVICE`  
必要：否  
指定是否將標籤從任務定義或服務複製到服務中的任務。如果沒有指定值，則不會複製標籤。標籤只能在建立服務期間複製到服務內的任務。若要在建立服務或任務後對任務新增標籤，請使用 `TagResource` API 動作。  
更新服務時，此參數不會觸發新的服務部署。

## 網路組態
<a name="sd-networkconfiguration"></a>

`networkConfiguration`  
類型：物件  
必要：否  
服務的網路組態。使用 `awsvpc` 網路模式的任務定義需要此參數，才能接收其自己的彈性網路介面，其他網路模式不支援此參數。如果使用 Fargate，則需要 `awsvpc` 網路模式。如需有關 EC2 聯網的更多資訊，請參閱[EC2 的 Amazon ECS 任務聯網選項](task-networking.md)。如需有關 Fargate 聯網的更多資訊，請參閱 [Fargate 的 Amazon ECS 任務聯網選項](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/fargate-task-networking.html)。  
更新服務時，此參數會觸發新的服務部署。    
`awsvpcConfiguration`  
類型：物件  
必要：否  
代表任務或服務之子網路和安全群組的物件。    
`subnets`  
類型：字串陣列  
必要：是  
與任務或服務相關聯的子網路。根據 `awsvpcConfiguration` 限制僅能指定 16 個子網路。  
`securityGroups`  
類型：字串陣列  
必要：否  
與任務或服務相關聯的安全群組。如果您未指定安全群組，則會使用預設的 VPC 安全群組。根據 `awsvpcConfiguration` 限制僅能指定五個安全群組。  
`assignPublicIP`  
類型：字串  
有效值：`ENABLED` \$1 `DISABLED`  
必要：否  
無論任務的彈性網路介面是否收到公有 IP 地址。如果未指定任何值，則會使用 `DISABLED` 的預設值。

`healthCheckGracePeriodSeconds`  
類型：整數  
必要：否  
所謂寬限期是指 Amazon ECS 服務排程器在任務首次啟動後，會在這段期間內 (以秒為單位) 忽略運作狀態不良的 Elastic Load Balancing、VPC Lattice 與容器運作狀態檢查。如果您未指定運作狀態檢查寬限期間值，則會使用預設值 0。如果您沒有使用任何運作狀態檢查，則 `healthCheckGracePeriodSeconds` 處於未使用狀態。  
若服務的任務需要一些時間來啟動及回應，您可以指定運作狀態檢查的寬限期，最長為 2,147,483,647 秒 (約 69 年)。在此期間，Amazon ECS 服務排程器會忽略運作狀態檢查狀態。此寬限期可防止服務排程器將任務標示為狀況不良並在其來得及標示前加以停止。  
更新服務時，此參數不會觸發新的服務部署。

`loadBalancers`  
類型： 物件陣列  
必要：否  
用來代表您的服務所使用之負載平衡器的負載平衡器物件。針對使用 Application Load Balancer 或 Network Load Balancer 的任務，您最多僅能連接五個目標群組到一個服務。  
更新服務時，此參數會觸發新的服務部署。  
建立服務之後，負載平衡器組態無法從 AWS 管理主控台變更。您可以使用 AWS Copilot AWS CloudFormation AWS CLI 或 SDK 來修改滾動`ECS`部署控制器的負載平衡器組態，而不是 AWS CodeDeploy 藍/綠或外部。當您新增、更新或移除負載平衡器組態時，Amazon ECS 會使用更新後的 Elastic Load Balancing 組態啟動新的部署。這會導致任務向負載平衡器註冊和取消註冊。我們建議您在更新 Elastic Load Balancing 組態之前，先在測試環境中驗證。如需有關如何修改組態的資訊，請參閱 *Amazon Elastic Container Service API 參考* 中的 [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)。  
針對 Application Load Balancer 和 Network Load Balancer，此物件必須包含負載平衡器目標群組 ARN、容器名稱 (這會出現在容器定義中) 和容器連接埠，以從負載平衡器存取。當此服務的任務置於容器執行個體，該容器執行個體和連接埠組合就會註冊為指定之目標群組中的目標。    
`targetGroupArn`  
類型：字串  
必要：否  
與服務相關聯的 Elastic Load Balancing 目標群組的完整 Amazon Resource Name (ARN)。  
僅在使用 Application Load Balancer 或Network Load Balancer時，才指定目標群組 ARN。  
`loadBalancerName`  
類型：字串  
必要：否  
要與服務建立關聯的負載平衡器名稱。  
如果您使用 Application Load Balancer 或 Network Load Balancer，請略去負載平衡器名稱參數。  
`containerName`  
類型：字串  
必要：否  
要與負載平衡器建立關聯的容器 (這會出現在容器定義中) 名稱。  
`containerPort`  
類型：整數  
必要：否  
要與負載平衡器建立關聯之容器的連接埠。此連接埠必須對應至服務中任務所使用之任務定義中的 `containerPort`。針對使用 EC2 的任務，容器執行個體必須允許傳入連接埠映射的 `hostPort` 的流量。

`role`  
類型：字串  
必要：否  
IAM 角色的簡稱或完整 ARN，此角色允許 Amazon ECS 代您呼叫您的負載平衡器。只有在您對服務使用具有單一目標群組的負載平衡器，且您的任務定義沒有使用 `awsvpc` 網路模式時，才允許此參數。如果您指定 `role` 參數，您還必須以 `loadBalancers` 參數指定負載平衡器物件。  
更新服務時，此參數不會觸發新的服務部署。  
如果您指定的角色有 `/` 以外的路徑，則您必須指定完整的角色 ARN (建議項目) 或在角色名稱前加上路徑。例如，如果名稱為 `bar` 的角色有路徑 `/foo/`，則您可指定 `/foo/bar` 為角色名稱。如需詳細資訊，請參閱 *IAM 使用者指南*中的[易記名稱和路徑](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-friendly-names)。  
若您的帳戶已建立 Amazon ECS 服務連結角色，則根據預設會為您的服務使用該角色，除非您在此處另行指定。若您的任務定義使用 awsvpc 網路模式，則服務連結角色為必要項目，此時您便不應在此處指定角色。如需詳細資訊，請參閱[使用 Amazon ECS 的服務連結角色](using-service-linked-roles.md)。

`serviceConnectConfiguration`  
類型：物件  
必要：否  
可讓此服務探索及連線至服務，並可供命名空間內其他服務探索及連線的組態。  
更新服務時，此參數會觸發新的服務部署。  
如需詳細資訊，請參閱[使用 Service Connect 以利用簡稱連線 Amazon ECS 服務](service-connect.md)。    
`enabled`  
類型：布林值  
必要：是  
指定是否要搭配此服務使用 Service Connect。  
`namespace`  
類型：字串  
必要：否  
用於 Service Connect 之 AWS Cloud Map 命名空間的簡短名稱或完整 Amazon Resource Name (ARN)。命名空間必須位於與 Amazon ECS 服務和叢集相同的 AWS 區域 。命名空間的類型不會影響 Service Connect。如需詳細資訊 AWS Cloud Map，請參閱《 *AWS Cloud Map 開發人員指南*》中的[使用 服務](https://docs.aws.amazon.com/cloud-map/latest/dg/working-with-services.html)。  
`services`  
類型： 物件陣列  
必要：否  
Service Connect 服務物件的陣列。這些是其他 Amazon ECS 服務用來連線到此服務的名稱和別名 (又稱為端點)。  
對於屬於命名空間成員且僅連線至命名空間內其他服務的「用戶端」Amazon ECS 服務來說，此欄位不是必要欄位。以接受傳入請求的前端應用程式為例，這些請求由連接到服務的負載平衡器傳入或透過其他方式傳入。  
物件會從任務定義中選取連接埠、指派 AWS Cloud Map 服務的名稱，以及一組別名 （也稱為端點） 和連接埠，供用戶端應用程式參考此服務。    
`portName`  
類型：字串  
必要：是  
`portName` 必須符合此 Amazon ECS 服務任務定義中來自所有容器的其中一個 `portMappings` 的 `name`。  
`discoveryName`  
類型：字串  
必要：否  
`discoveryName` 是 Amazon ECS 為此 Amazon ECS AWS Cloud Map 服務建立的新服務的名稱。此名稱在 AWS Cloud Map 命名空間中必須不重複。  
若沒有指定此欄位，則使用 `portName`。  
`clientAliases`  
類型： 物件陣列  
必要：否  
此 Service Connect 服務的用戶端別名清單。您可以使用這些別名，指派用戶端應用程式可使用的名稱。您可以在此清單中擁有的用戶端別名數量上限為 1。  
每個別名 (「端點」) 都是其他 Amazon ECS 服務 (「用戶端」) 可用來連線至此服務的 DNS 名稱和連接埠號碼。  
每個名稱和連接埠組合在命名空間內必須不重複。  
這些名稱在用戶端服務的每個任務中設定，而不是在 AWS Cloud Map中設定。解析這些名稱的 DNS 請求不會離開任務，也不會計入每個彈性網路介面每秒對 DNS 請求的配額。    
`port`  
類型：整數  
必要：是  
Service Connect Proxy 的接聽連接埠號碼。此連接埠可在相同命名空間內的所有任務中使用。  
若要避免在用戶端 Amazon ECS 服務中變更應用程式，請將此設定為用戶端應用程式預設使用的相同連接埠。  
`dnsName`  
類型：字串  
必要：否  
`dnsName` 是您在用戶端任務應用程式中用來連線到此服務的名稱。名稱必須是有效的 DNS 標籤。  
如果未指定欄位，則預設值為 `discoveryName.namespace`。如果未指定 `discoveryName`，則會使用來自任務定義的 `portName`。  
若要避免在用戶端 Amazon ECS 服務中變更應用程式，請將此設定為用戶端應用程式預設使用的相同名稱。例如，一些常見名稱為 `database`、`db`，或資料庫的小寫名稱，例如 `mysql` 或 `redis`。  
`ingressPortOverride`  
類型：整數  
必要：否  
(選用) Service Connect Proxy 接聽所用的連接埠號碼。  
使用此欄位的值以略過此應用程式任務定義中指定之 `portMapping` 所指定的連接埠號碼上流量的 Proxy，然後在 Amazon VPC 安全群組中使用此值，以允許流量進入此 Amazon ECS 服務的 Proxy。  
在 `awsvpc` 模式中，預設值是在此應用程式任務定義中指定之 `portMapping` 所指定的容器連接埠號碼。在 `bridge` 模式中，預設值是 Service Connect Proxy 的動態暫時性連接埠。  
`logConfiguration`  
類型：[LogConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_LogConfiguration.html) 物件  
必要：否  
這會定義 Service Connect Proxy 日誌的發佈位置。在非預期事件期間使用日誌進行偵錯。此組態會在此 Amazon ECS 服務的每個任務中，設定 Service Connect Proxy 容器中的 `logConfiguration` 參數。未在任務定義中指定 Proxy 容器。  
我們建議您使用與此 Amazon ECS 服務任務定義的應用程式容器相同的日誌組態。對於 FireLens，這是應用程式容器的日誌組態。這不是使用 `fluent-bit` 或 `fluentd ` 容器映像的 FireLens 日誌路由器容器。  
`accessLogConfiguration`  
類型：[ServiceConnectAccessLogConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_LogConfiguration.html) 物件  
必要：否  
Service Connect 存取記錄的組態，包括日誌格式，以及日誌是否應包含查詢字串。存取日誌會擷取對服務提出之請求的詳細資訊，包括請求模式、回應碼和時間資料。若要啟用存取日誌，您還必須在 `logConfiguration`中指定 `serviceConnectConfiguration`。

`serviceRegistries`  
類型： 物件陣列  
必要：否  
您的服務探索組態詳細資訊。如需詳細資訊，請參閱[使用服務探索以利用 DNS 名稱連接 Amazon ECS 服務](service-discovery.md)。  
更新服務時，此參數會觸發新的服務部署。    
`registryArn`  
類型：字串  
必要：否  
服務登錄檔的 Amazon Resource Name (ARN)。目前支援的服務登錄檔為 AWS Cloud Map。如需詳細資訊，請參閱 *AWS Cloud Map 開發人員指南*中的[使用服務](https://docs.aws.amazon.com/cloud-map/latest/dg/working-with-services.html)。  
`port`  
類型：整數  
必要：否  
如果您的服務探索服務指定了 SRV 記錄，則使用該連接埠值。如果已使用 `awsvpc` 網路模式和 SRV 記錄，則此欄位為必要項目。  
`containerName`  
類型：字串  
必要：否  
容器名稱值用於您的「服務探索」服務。該值已於任務定義中指定。如果服務任務指定的任務定義是使用 `bridge` 或 `host` 網路模式，您必須透過任務定義指定 `containerName` 與 `containerPort` 組合。如果服務任務指定的任務定義使用 `awsvpc`網路模式，並已使用類型 SRV DNS 記錄，您必須指定 `containerName` 和 `containerPort` 組合或 `port` 值，但不得同時指定兩者。  
`containerPort`  
類型：整數  
必要：否  
用於您的「服務探索」服務的連接埠值。該值已於任務定義中指定。如果服務任務指定的任務定義是使用 `bridge` 或 `host` 網路模式，您必須透過任務定義指定 `containerName` 與 `containerPort` 組合。如果服務任務指定的任務定義使用 `awsvpc` 網路模式，並已使用類型 SRV DNS 記錄，您必須指定 `containerName` 和 `containerPort` 組合或 `port` 值，但不得同時指定兩者。

## 用戶端字符
<a name="sd-clienttoken"></a>

`clientToken`  
類型：字串  
必要：否  
由您提供的唯一且區分大小寫的識別符，以確保請求的等冪性。長度上限為 32 個 ASCII 字元。

## 可用區域重新平衡
<a name="sd-availability-zone-rebalancing"></a>

`availabilityZoneRebalancing`  
類型：字串  
必要：否  
指出服務是否使用可用區域重新平衡。有效值為 `ENABLED` 和 `DISABLED`。  
更新服務時，此參數不會觸發新的服務部署。  
預設行為：  
+ 對於新服務：如果未指定任何值，則預設值為 `DISABLED`。
+ 對於現有服務：如果未指定任何值，Amazon ECS 會將該值預設為現有值。如果先前未設定任何值，Amazon ECS 會將該值設定為 `DISABLED`。
如需有關可用區域重新平衡的詳細資訊，請參閱[在可用區域之間平衡 Amazon ECS 服務](service-rebalancing.md)。

## 磁碟區組態
<a name="sd-volumeConfigurations"></a>

`volumeConfigurations`  
類型：物件  
必要：否  
用於為由服務管理的任務建立磁碟區的組態。只有任務定義中標記為 `configuredAtLaunch` 的磁碟區才能使用此物件進行設定。  
更新服務時，此參數會觸發新的服務部署。  
將 Amazon EBS 磁碟區連接至由服務管理的任務時，需要此物件。如需詳細資訊，請參閱[將 Amazon EBS 磁碟區與 Amazon ECS 搭配使用](ebs-volumes.md)。    
`name`  
類型：字串  
必要：是  
建立或更新服務時設定的磁碟區名稱。最多允許 255 個字元 (大小寫)、數字、底線 (`_`) 與連字號 (`-`)。此值必須與任務定義中指定的磁碟區名稱相符。  
`managedEBSVolume`  
類型：物件  
必要：否  
用於建立 Amazon EBS 磁碟區的磁碟區組態，這些磁碟區會連接至服務建立或更新時由服務維護的任務。每項任務連接一個磁碟區。    
`encrypted`  
類型：布林值  
必要：否  
有效值：`true`\$1`false`  
指定是否加密每個建立的 Amazon EBS 磁碟區。如果您已為 的特定 開啟 Amazon EBS 加密， AWS 區域 AWS 帳戶 但將此參數設定為 `false`，則會覆寫此參數，而且磁碟區會使用預設為加密指定的 KMS 金鑰進行加密。如需有關 Amazon EBS 預設加密的詳細資訊，請參閱 *Amazon EBS User Guide* 中的 [Enable Amazon EBS encryption by default](https://docs.aws.amazon.com/ebs/latest/userguide/encryption-by-default.html)。如需有關加密連接至 Amazon ECS 任務之 Amazon EBS 磁碟區的詳細資訊，請參閱[加密儲存於連接至 Amazon ECS 任務之 Amazon EBS 磁碟區中的資料](ebs-kms-encryption.md)。  
`kmsKeyId`  
類型：字串  
必要：否  
用於 Amazon EBS 加密的 AWS Key Management Service (AWS KMS) 金鑰識別符。如果指定 `kmsKeyId`，加密狀態必須是 `true`。  
 使用此參數指定的金鑰會覆寫 Amazon EBS 預設金鑰，或可能已指定的任何叢集層級 KMS 金鑰 (用於 Amazon ECS 受管儲存加密)。如需詳細資訊，請參閱[加密儲存於連接至 Amazon ECS 任務之 Amazon EBS 磁碟區中的資料](ebs-kms-encryption.md)。  
您可以使用下列任何方式指定 KMS 金鑰：  
+ **金輪 ID** – 例如 `1234abcd-12ab-34cd-56ef-1234567890ab`。
+ **金鑰別名** – 例如 `alias/ExampleAlias`。
+ **金鑰 ARN** – 例如 `arn:aws:kms:us-east-1:012345678910:key/1234abcd-12ab-34cd-56ef-1234567890ab`。
+ **別名 ARN** – 例如 `arn:aws:kms:us-east-1:012345678910:alias/ExampleAlias`。
AWS 會以非同步方式驗證 KMS 金鑰。因此，如果指定的 ID、別名或 ARN 無效，則動作雖顯示成功，但最終會失敗。如需詳細資訊，請參閱[對 Amazon EBS 磁碟區連接問題進行疑難排解](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/troubleshoot-ebs-volumes.html)。  
`volumeType`  
類型：字串  
必要：否  
有效值：`gp2`\$1`gp3`\$1`io1`\$1`io2`\$1`sc1`\$1`st1`\$1`standard`  
Amazon EBS 磁碟區類型。如需有關磁碟區類型的詳細資訊，請參閱 *Amazon EBS User Guide* 中的 [Amazon EBS volume types](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-volume-types.html)。預設磁碟區類型為 `gp3`。  
Fargate 任務不支援 `standard` 磁碟區類型。  
`sizeInGiB`  
類型：整數  
必要：否  
有效範圍：介於 1 到 16,384 之間的整數   
EBS 磁碟區的大小 (GiB)。如果未提供快照 ID 來設定要連接的磁碟區，則必須提供大小值。如果使用快照來設定要連接的磁碟區，則預設值為快照大小。然後，您可以指定大於或等於快照大小的大小。  
對於 `gp2` 與 `gp3` 磁碟區類型，有效值範圍為 1-16,384。  
對於 `io1` 與 `io2` 磁碟區類型，有效值範圍為 4-16,384。  
對於 `st1` 與 `sc1` 磁碟區類型，有效值範圍為 125-16,384。  
對於 `standard` 磁碟區類型，有效值範圍為 1-1,024。  
`snapshotId`  
類型：字串  
必要：否  
現有 Amazon EBS 磁碟區的快照 ID，Amazon ECS 可將其用於建立要連接的新磁碟區。您必須擇一指定 `snapshotId` 或 `sizeInGiB`。  
`volumeInitializationRate`  
類型：整數  
必要：否  
從現有 Amazon EBS 磁碟區的快照擷取資料以建立要連接之新磁碟區的速率 (以 MiB/s 為單位)。只有在您指定了 `snapshotId` 時，才能指定此屬性。如需有關此磁碟區初始化速率的詳細資訊，包括支援的初始化速率範圍，請參閱 *Amazon EBS User Guide* 中的 [Initialize Amazon EBS volumes](https://docs.aws.amazon.com/ebs/latest/userguide/initalize-volume.html)。  
`iops`  
類型：整數  
必要：否  
每秒 I/O 操作的次數 (IOPS)。對 `gp3`、`io1` 和 `io2` 磁碟區而言，這代表針對磁碟區佈建的 IOPS 數量。對於 `gp2` 磁碟區，此值代表磁碟區的基準效能，以及磁碟區為爆量而累積的 I/O 額度比率。這是 `io1` 和 `io2` 磁碟區的必要參數。`gp2`、`st1`、`sc1` 或 `standard` 磁碟區不支援此參數。  
對於 `gp3` 磁碟區，有效值範圍為 3,000 到 16,000。  
對於 `io1` 磁碟區，有效值範圍為 100 到 64,000。  
對於 `io2` 磁碟區，有效值範圍為 100 到 64,000。  
`throughput`  
類型：整數  
必要：否  
為連接至由服務維護之任務的磁碟區佈建的輸送量。  
僅 `gp3` 磁碟區支援此參數。  
`roleArn`  
類型：字串  
必要：是  
基礎設施 (IAM) 角色的 Amazon Resource ARN AWS Identity and Access Management (ARN)，提供 Amazon ECS 許可來管理任務的 Amazon EBS 資源。如需詳細資訊，請參閱[Amazon ECS 基礎結構 IAM 角色](infrastructure_IAM_role.md)。  
`tagSpecifications`  
類型：物件  
必要：否  
要套用至每個 Amazon EBS 磁碟區的標籤規格。    
`resourceType`  
類型：字串  
必要：是  
有效值：`volume`  
建立時要標記的資源類型。  
`tags`  
類型： 物件陣列  
必要：否  
套用至磁碟區以協助您對其進行分類與整理的中繼資料。每個標籤皆由您定義的鍵與選用值組成。`AmazonECSCreated` 與 `AmazonECSManaged` 都是 Amazon ECS 代表您新增的預留標籤，因此您最多可以指定 48 個自己的標籤。刪除磁碟區時，也會一併刪除標籤。如需詳細資訊，請參閱[標記 Amazon ECS 資源](ecs-using-tags.md)。    
`key`  
類型：字串  
長度限制：長度下限為 1。長度上限為 128。  
必要：否  
組成標籤的鍵值對的一部分。索引鍵是一般標籤，作用就像更特定標籤值的類別。  
`value`  
類型：字串  
長度限制：長度下限為 0。長度上限為 256。  
必要：否  
組成標籤的鍵值對的選用部分。值就像標籤類別 (索引鍵) 內的描述項。  
`propagateTags`  
類型：字串  
有效值：`TASK_DEFINITION` \$1 `SERVICE` \$1 `NONE`  
必要：否  
指定是否將標籤從任務定義或服務複製到磁碟區。如果指定了 `NONE` 或未指定任何值，則不會複製標籤。  
`fileSystemType`  
類型：字串  
必要：否  
有效值：`xfs`\$1`ext3`\$1`ext4`\$1`NTFS`  
磁碟區上的檔案系統類型。磁碟區的檔案系統類型決定了資料在磁碟區中的儲存與擷取方式。對於從快照建立的磁碟區，您必須指定與建立快照時磁碟區所使用的相同檔案系統類型。如果有檔案系統類型不相符，則任務將無法啟動。  
Linux 的有效值為 `xfs`、ext3 與 `, and ext4`。連接至 Linux 任務之磁碟區的預設值為 `XFS`。  
Windows 的有效值為 `NTFS`。連接至 Windows 任務之磁碟區的預設值為 `NTFS`。

# 服務定義範本
<a name="sd-template"></a>

以下顯示 Amazon ECS 服務定義的 JSON 表示法。

EC2

```
{
    "cluster": "", 
    "serviceName": "", 
    "taskDefinition": "", 
    "loadBalancers": [
        {
            "targetGroupArn": "", 
            "loadBalancerName": "", 
            "containerName": "", 
            "containerPort": 0
        }
    ], 
    "serviceRegistries": [
        {
            "registryArn": "", 
            "port": 0, 
            "containerName": "", 
            "containerPort": 0
        }
    ], 
    "desiredCount": 0, 
    "clientToken": "", 
    "launchType": "EC2", 
    "capacityProviderStrategy": [
        {
            "capacityProvider": "", 
            "weight": 0, 
            "base": 0
        }
    ], 
    "platformVersion": "", 
    "role": "", 
    "deploymentConfiguration": {
        "deploymentCircuitBreaker": {
            "enable": true, 
            "rollback": true
        }, 
        "maximumPercent": 0, 
        "minimumHealthyPercent": 0, 
        "alarms": {
            "alarmNames": [
                ""
            ], 
            "enable": true, 
            "rollback": true
        }
    }, 
    "placementConstraints": [
        {
            "type": "distinctInstance", 
            "expression": ""
        }
    ], 
    "placementStrategy": [
        {
            "type": "binpack", 
            "field": ""
        }
    ], 
    "networkConfiguration": {
        "awsvpcConfiguration": {
            "subnets": [
                ""
            ], 
            "securityGroups": [
                ""
            ], 
            "assignPublicIp": "DISABLED"
        }
    }, 
    "healthCheckGracePeriodSeconds": 0, 
    "schedulingStrategy": "REPLICA", 
    "deploymentController": {
        "type": "EXTERNAL"
    }, 
    "tags": [
        {
            "key": "", 
            "value": ""
        }
    ], 
    "enableECSManagedTags": true, 
    "propagateTags": "TASK_DEFINITION", 
    "enableExecuteCommand": true, 
    "availabilityZoneRebalancing": "ENABLED",
    "serviceConnectConfiguration": {
        "enabled": true, 
        "namespace": "", 
        "services": [
            {
                "portName": "", 
                "discoveryName": "", 
                "clientAliases": [
                    {
                        "port": 0, 
                        "dnsName": ""
                    }
                ], 
                "ingressPortOverride": 0
            }
        ], 
        "logConfiguration": {
            "logDriver": "journald", 
            "options": {
                "KeyName": ""
            }, 
            "secretOptions": [
                {
                    "name": "", 
                    "valueFrom": ""
                }
            ]
        }
    }, 
    "volumeConfigurations": [
        {
            "name": "", 
            "managedEBSVolume": {
                "encrypted": true, 
                "kmsKeyId": "", 
                "volumeType": "", 
                "sizeInGiB": 0, 
                "snapshotId": "", 
                "volumeInitializationRate": 0,
                "iops": 0, 
                "throughput": 0, 
                "tagSpecifications": [
                    {
                        "resourceType": "volume", 
                        "tags": [
                            {
                                "key": "", 
                                "value": ""
                            }
                        ], 
                        "propagateTags": "NONE"
                    }
                ], 
                "roleArn": "", 
                "filesystemType": ""
            }
        }
    ]
}
```

Fargate

```
{
    "cluster": "", 
    "serviceName": "", 
    "taskDefinition": "", 
    "loadBalancers": [
        {
            "targetGroupArn": "", 
            "loadBalancerName": "", 
            "containerName": "", 
            "containerPort": 0
        }
    ], 
    "serviceRegistries": [
        {
            "registryArn": "", 
            "port": 0, 
            "containerName": "", 
            "containerPort": 0
        }
    ], 
    "desiredCount": 0, 
    "clientToken": "", 
    "launchType": "FARGATE", 
    "capacityProviderStrategy": [
        {
            "capacityProvider": "", 
            "weight": 0, 
            "base": 0
        }
    ], 
    "platformVersion": "", 
    "platformFamily": "",
    "role": "", 
    "deploymentConfiguration": {
        "deploymentCircuitBreaker": {
            "enable": true, 
            "rollback": true
        }, 
        "maximumPercent": 0, 
        "minimumHealthyPercent": 0, 
        "alarms": {
            "alarmNames": [
                ""
            ], 
            "enable": true, 
            "rollback": true
        }
    }, 
    "placementStrategy": [
        {
            "type": "binpack", 
            "field": ""
        }
    ], 
    "networkConfiguration": {
        "awsvpcConfiguration": {
            "subnets": [
                ""
            ], 
            "securityGroups": [
                ""
            ], 
            "assignPublicIp": "DISABLED"
        }
    }, 
    "healthCheckGracePeriodSeconds": 0, 
    "schedulingStrategy": "REPLICA", 
    "deploymentController": {
        "type": "EXTERNAL"
    }, 
    "tags": [
        {
            "key": "", 
            "value": ""
        }
    ], 
    "enableECSManagedTags": true, 
    "propagateTags": "TASK_DEFINITION", 
    "enableExecuteCommand": true, 
    "availabilityZoneRebalancing": "ENABLED",
    "serviceConnectConfiguration": {
        "enabled": true, 
        "namespace": "", 
        "services": [
            {
                "portName": "", 
                "discoveryName": "", 
                "clientAliases": [
                    {
                        "port": 0, 
                        "dnsName": ""
                    }
                ], 
                "ingressPortOverride": 0   
            }
        ], 
        "logConfiguration": {
            "logDriver": "journald", 
            "options": {
                "KeyName": ""
            }, 
            "secretOptions": [
                {
                    "name": "", 
                    "valueFrom": ""
                }
            ]
        }
    }, 
    "volumeConfigurations": [
        {
            "name": "", 
            "managedEBSVolume": {
                "encrypted": true, 
                "kmsKeyId": "", 
                "volumeType": "", 
                "sizeInGiB": 0, 
                "snapshotId": "", 
                "volumeInitializationRate": 0, 
                "iops": 0, 
                "throughput": 0, 
                "tagSpecifications": [
                    {
                        "resourceType": "volume", 
                        "tags": [
                            {
                                "key": "", 
                                "value": ""
                            }
                        ], 
                        "propagateTags": "NONE"
                    }
                ], 
                "roleArn": "", 
                "filesystemType": ""
            }
        }
    ]
}
```

您可以使用下列 AWS CLI 命令建立此服務定義範本。

```
aws ecs create-service --generate-cli-skeleton
```