本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。
Amazon ECS 服務部署控制器和策略
部署服務之前,請先判斷部署服務的選項,以及服務使用的功能。
排程策略
現已推出兩個服務排程器策略概念:
複本排程策略
複本排程策略會在叢集中放置並維持所需的任務數量。
對於在 Fargate 上執行任務的服務,當服務排程器啟動新任務或停止執行任務時,服務排程器會盡力嘗試在可用區域之間維持平衡。您無須指定任務置放策略或限制條件。
當您在 EC2 執行個體上建立執行任務的服務時,您可以選擇性地指定任務置放策略和限制條件,以自訂任務置放決策。如果未指定任務置放策略或限制,預設情況下,服務排程器會將任務分散到可用區域。服務排程器使用以下邏輯:
-
決定您叢集中的哪些容器執行個體可支援服務的任務定義 (例如,必要的 CPU、記憶體、連接埠和容器執行個體屬性)。
-
決定哪些容器執行個體可滿足針對服務所定義的任何置放限制。
-
當您有取決於常駐程式服務的複本服務時 (例如,必須先執行常駐程式日誌路由器任務,才能使用記錄),請建立任務置放限制,以確保常駐程式服務任務在複本服務任務之前置放在 EC2 執行個體上。如需詳細資訊,請參閱Amazon ECS 任務置放限制範例。
-
如已定義置放策略,請使用該策略從剩餘的待選項目中選取執行個體。
-
如未定義任何置放策略,請使用下列邏輯平衡您叢集中可用區域的任務:
-
排序有效的容器執行個體。優先考慮在此服務的個別可用區域中,執行中任務數量最少的執行個體。例如,如果區域 A 有一項執行中的服務任務,而區域 B 和 C 都沒有,則最適合置放的即為區域 B 或 C 中的有效容器執行個體。
-
根據先前的步驟,將新的服務任務置放在最佳可用區域的有效容器執行個體。偏好此服務執行中任務數量最少的容器執行個體。
-
建議您在使用 REPLICA
策略時使用服務重新平衡功能,因為它有助於確保服務的高可用性。
協助程式排程策略
常駐程式排程策略會在每個活動容器執行個體上準確部署一個任務,其可滿足叢集中所有指定的任務置放限制條件。服務排程器會評估執行中任務的任務置放限制,並停止不符合置放限制的任務。當您使用此策略時,您不需要指定所需的任務數量、任務置放策略,或使用 Service Auto Scaling 政策。
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 中的容器執行個體。
-
根據先前的步驟,停止最佳可用區域中容器執行個體上的任務。偏好此服務執行中任務數量最多的容器執行個體。
-
部署控制器
部署控制器是決定如何為您的服務部署任務的機制。有效選項為:
-
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 時
-
-
外部
使用第三方部署控制器。
-
藍/綠部署 (採用 技術 AWS CodeDeploy)
CodeDeploy 會將應用程式的更新版本安裝為新的替換任務集,並將原始應用程式任務集的生產流量重新路由至替換任務集。成功部署後,原始任務集會終止。在傳送生產流量到服務之前,使用此部署控制器來驗證服務的新部署。