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

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

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

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

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

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

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

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

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

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

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

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