本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。 # 在 中更新運算環境 AWS Batch AWS Batch 提供多種策略來更新運算環境，每個都專為特定更新案例和需求而設計。這些方法使用相同的基礎更新 API，但代表有效管理更新的不同規範方法。您可以使用 AWS Batch 主控台或 來管理這些更新 AWS CLI。了解這些策略可協助您選擇最符合您需求的方法，同時將對工作負載的干擾降至最低。 本主題提供可用更新策略的概觀，以及何時使用每種方法的指引。如需詳細程序，請參閱每個更新策略的個別區段。 **重要** AWS Batch 會代表您和在您的帳戶中建立和管理多個 AWS 資源，包括 Amazon EC2 啟動範本、Amazon EC2 Auto Scaling 群組、Amazon EC2 Spot 機群和 Amazon ECS 叢集。這些受管資源經過專門設定，以確保最佳 AWS Batch 操作。除非 AWS Batch 文件中明確說明，否則手動修改這些 AWS Batch受管資源可能會導致意外行為，包括`INVALID`運算環境、次佳執行個體擴展行為、延遲工作負載處理或意外成本。 AWS Batch 服務無法確定是否支援這些手動修改。一律使用支援的 AWS Batch APIs或 AWS Batch 主控台來管理您的運算環境。 不支援的手動修改包括執行您自己的 Amazon ECS AWS Batch任務或服務受管 Amazon ECS 叢集，或直接啟動其他程序、協助程式或服務 AWS Batch受管執行個體。 AWS Batch 會完全控制受管運算環境中的運算資源，並且可以隨時終止執行個體、停止任務或擴展叢集。在這些受管資源上，您在 AWS Batch 任務提交之外執行的任何工作負載都可以中斷，而不會出現警告。執行非AWS Batch 工作負載的 AWS Batch受管叢集和執行個體也會干擾 AWS Batch 任務排程和執行個體擴展。 **Topics** + [運算環境更新策略](#update-strategies) + [選擇正確的更新策略](#choosing-update-strategies) + [AMI 更新考量事項](#ami-update-considerations) + [執行擴展更新](scaling-updates.md) + [執行基礎設施更新](infrastructure-updates.md) + [執行運算環境的藍/綠更新](blue-green-updates.md) ## 運算環境更新策略 當您使用擴展或基礎設施更新時，會更新運算環境。對於藍/綠更新策略，您要建立新的運算環境 （綠色），然後將工作負載從舊的運算環境 （藍色） 遷移到新的運算環境 （綠色）。 AWS Batch 提供三種不同的運算環境更新策略： 擴展更新 擴展更新會透過新增或移除執行個體來調整運算環境的容量，而無需取代現有的執行個體。這是最快的更新案例，不需要停機時間。當您需要變更容量設定 (vCPUs時，請使用擴展更新。這些更新通常會在幾分鐘內完成。 Fargate 更新是使用與擴展更新相同的程序執行。如需詳細資訊，請參閱[執行擴展更新](scaling-updates.md)。 基礎設施更新 基礎設施更新會將運算環境中的執行個體取代為具有更新設定的新執行個體。這些更新需要特定的服務角色和配置策略組態，但可提供最短的停機時間，而執行中的任務可能會中斷。當您需要修改執行個體類型、AMI 組態、聯網設定、服務角色、環境狀態或其他基礎設施元件時，請使用基礎設施更新。這些更新通常會在 10-30 分鐘內完成，視任務完成而定。 如需詳細資訊，請參閱[執行基礎設施更新](infrastructure-updates.md)。 藍/綠更新 藍/綠更新會與您現有的環境一起建立新的運算環境，讓工作負載逐漸轉換，無須停機。此方法提供最安全的更新路徑，但需要暫時執行兩個環境。當您需要零停機時間、想要在完全部署之前測試變更、需要快速復原功能，或使用不支援的組態進行基礎設施更新時，請使用藍/綠更新。完成的時間是可變的，由您控制。 如需詳細資訊，請參閱[執行運算環境的藍/綠更新](blue-green-updates.md)。 ## 選擇正確的更新策略 使用此決策指南來選取最符合您需求的更新策略： ### 在 時選擇擴展更新 當您只需要調整運算容量 (vCPUs) 時，請選擇擴展更新策略。當您不需要快速更新而不需要停機時間，也不需要基礎設施組態變更時，擴展更新是理想的選擇。 如需詳細程序，請參閱[執行擴展更新](scaling-updates.md)。 ### 在 時選擇基礎設施更新 當您需要修改執行個體類型、AMI 設定、服務角色、環境狀態或聯網組態時，請選擇基礎設施更新策略。您的環境必須使用 *AWSServiceRoleForBatch* 服務連結角色和 `BEST_FIT_PROGRESSIVE`、 `SPOT_CAPACITY_OPTIMIZED`或 的配置策略`SPOT_PRICE_CAPACITY_OPTIMIZED`。當在更新期間接受某些任務中斷，且您希望自動更新至最新的 Amazon ECS 最佳化 AMI 時，基礎設施更新運作良好。 如需詳細程序，請參閱[執行基礎設施更新](infrastructure-updates.md)。 ### 在 時選擇藍/綠更新 當您的工作負載需要零停機時間，或您需要在轉換生產工作負載之前測試變更時，請選擇藍/綠更新策略。當快速復原功能很重要、您的環境使用`BEST_FIT`配置策略，或您的環境不使用 *AWSServiceRoleForBatch* 服務連結角色時，這種方法至關重要。當您使用需要手動更新或需要進行主要組態變更AMIs 時，藍/綠更新也是最佳選擇。 如需詳細程序，請參閱[執行運算環境的藍/綠更新](blue-green-updates.md)。 ## AMI 更新考量事項 更新 AMIs的方法取決於您的運算環境組態。 ### 將 AWS Batch 提供的預設 AMI 更新為最新 AWS Batch 當符合下列所有條件時， 可以在[基礎設施](infrastructure-updates.md#infrastructure-updates.title)更新期間更新至最新的 Amazon ECS 最佳化 AMI： **注意** 基礎設施更新完成後`updateToLatestImageVersion`，會將 設定為 `false`。若要啟動另一個更新`updateToLatestImageVersion`，必須將 設定為 `true`。 + 運算環境使用 *AWSServiceRoleForBatch* 服務連結角色 + 配置策略設定為 `BEST_FIT_PROGRESSIVE`、 `SPOT_CAPACITY_OPTIMIZED`或 `SPOT_PRICE_CAPACITY_OPTIMIZED` + `imageId`、 `imageIdOverride`或 啟動範本中未明確指定 AMI ID + `updateToLatestImageVersion` 設定為 `true` ### 使用藍/綠部署的 AMI 更新 在這些情況下，您必須使用藍/綠部署來更新 AMIs： + 使用`BEST_FIT`配置策略時 （不支援基礎設施更新） + 不使用 *AWSServiceRoleForBatch* [服務連結角色](using-service-linked-roles-batch-general.md)時 ### 自訂 AMI 的 AMI 更新 如果您在運算環境的啟動範本中指定自訂 AMI，則 EC2 組態中的 `imageId` 參數或 `imageIdOverride` 參數 AWS Batch 不會在基礎設施更新期間自動更新您的自訂 AMI。您可以在最初在運算環境建立期間使用的 參數中指定新的 ID，以更新自訂 AMI ID。如果您想要使用 AWS Batch提供的 AMI 切換到 ，您可以在運算環境更新中移除自訂 AMI ID。 # 執行擴展更新 擴展更新會透過新增或移除執行個體來調整運算環境的容量。這是最快的更新策略，不需要取代現有的執行個體。擴展更新適用於任何服務角色類型和配置策略，使其成為最靈活的更新選項。 ## 觸發擴展更新的變更 當您僅修改下列設定時， 會 AWS Batch 執行擴展更新。如果您將這些設定與其他運算環境設定一起修改， 會改為 AWS Batch 執行[基礎設施更新](infrastructure-updates.md#infrastructure-updates.title)。 下列設定會在完全修改時觸發擴展更新： + `desiredvCpus` – 設定環境的 vCPUs目標數量。 + `maxvCpus` – 定義可啟動vCPUs 數目上限。 + `minvCpus` – 指定要維護的 vCPUs數目下限。 + `minScaleDownDelayMinutes` – 指定最短時間 （以分鐘為單位），讓執行個體在任務完成後 AWS Batch 於運算環境中執行。 **注意** `minScaleDownDelayMinutes` 不適用於在基礎設施更新期間要取代的執行個體。 對於 Fargate 運算環境，您也可以修改這些設定以進行擴展更新： + `securityGroupIds` – 運算環境的安全群組 IDs。 + `subnets` – 運算環境的子網路。 **注意** 我們建議您不要使用 `desiredvCpus` 啟動擴展更新，因為 AWS Batch 會動態調整 `desiredvCpus`。反之，您應該更新 `minvCpus`。 更新 時`desiredvCpus`，值必須介於 `minvCpus`和 之間`maxvCpus`。新值必須大於或等於目前的 `desiredvCpus`。如需詳細資訊，請參閱[更新`desiredvCpus`設定時的錯誤訊息](error-desired-vcpus-update.md)。 **重要** 如果您將這些擴展設定與其他運算環境設定 （例如執行個體類型、AMI IDs 或啟動範本） 一起修改， 會 AWS Batch 執行基礎設施更新，而非擴展更新。基礎設施更新需要更長的時間，而且可能會取代現有的執行個體。 ------ #### [ Performing scaling updates using the AWS 管理主控台 ] 1. 在 https：//[https://console.aws.amazon.com/batch/](https://console.aws.amazon.com/batch/) 開啟 AWS Batch 主控台。 1. 在導覽窗格中，選擇**環境**，然後選擇**運算環境**索引標籤。 1. 選取要更新的運算環境。 1. 選擇**動作**，然後選擇**編輯**。 1. 修改支援[擴展更新的一或多個設定](#scaling-updates-triggers)。例如： + 針對**最低 vCPUs**輸入最低 vCPUs數量。 + 針對**所需的 vCPUs**，輸入所需的 vCPUs 數量。 + 針對**最大 vCPUs**輸入最大 vCPUs 數量。 1. 選擇**儲存變更**。 1. 監控運算環境狀態。更新應該快速完成，因為它只涉及擴展操作。 ------ #### [ Performing scaling updates using the AWS CLI ] 使用 **update-compute-environment**命令來執行擴展更新。下列兩個範例示範常見的擴展操作。您可以修改下列一或多個[支援擴展更新的設定](#scaling-updates-triggers) + 此範例會更新所需的 vCPUs、最小值和最大值： ``` aws batch update-compute-environment \ --compute-environment your-compute-environment-name \ --compute-resources minvCpus=2,maxvCpus=8 ``` ------ ## 監控擴展更新 使用 AWS Batch 主控台監控您的擴展更新，以檢視運算環境狀態，並檢查執行個體計數和 vCPU 指標。您也可以 AWS CLI 搭配 **describe-compute-environments**命令使用 來檢查狀態，並監控執行個體計數和 vCPU 值。 # 執行基礎設施更新 基礎設施更新會將運算環境中的執行個體取代為具有更新設定的新執行個體。此更新策略需要比擴展更新更長的時間，並且需要特定的服務角色和配置策略設定。基礎設施更新提供一種方法來修改基本運算環境組態，同時保持服務可用性。 **重要** 基礎設施更新需要 *AWSServiceRoleForBatch* 服務連結角色，以及 `BEST_FIT_PROGRESSIVE`、 `SPOT_CAPACITY_OPTIMIZED`或 的配置策略`SPOT_PRICE_CAPACITY_OPTIMIZED`。如果您的環境不符合這些要求，請改用藍/綠更新。 ## 觸發基礎設施更新的變更 當您修改下列任何設定時， 會 AWS Batch 執行基礎設施更新。當您搭配擴展更新設定修改這些設定時，也會發生基礎設施更新。 下列設定會觸發基礎設施更新： **運算組態** + `allocationStrategy` – 決定 如何 AWS Batch 選取執行個體類型。 + `instanceTypes` – 指定要使用的 EC2 執行個體類型。 + `bidPercentage` – Spot 執行個體的隨需價格百分比上限。 + `type` – 運算環境類型 (`EC2` 或 `SPOT`)。 **AMI 和啟動組態** + `imageId` – 用於執行個體的特定 AMI。 + `ec2Configuration` – EC2 組態，包括 `imageIdOverride`。 + `launchTemplate` – EC2 啟動範本設定。 + `ec2KeyPair` – 執行個體存取的 SSH 金鑰對。 + `updateToLatestImageVersion` – 自動 AMI 更新設定。 **網路和安全性** + `subnets` – 啟動執行個體的 VPC 子網路 （適用於 EC2 運算環境）。 + `securityGroupIds` – 執行個體的安全群組 （適用於 EC2 運算環境）。 + `placementGroup` – EC2 置放群組組態。 **其他設定** + `instanceRole` – EC2 執行個體的 IAM 角色。 + `tags` – 套用至 EC2 執行個體的標籤。 **重要** 如果您同時修改任何基礎設施更新設定與擴展更新設定 （例如 `desiredvCpus`、 或 `minvCpus`)`maxvCpus`， 會 AWS Batch 執行基礎設施更新。基礎設施更新需要比擴展更新更長的時間。 ## 基礎設施更新期間的 AMI 選擇 在基礎設施更新期間，運算環境的 AMI ID 可能會變更，取決於是否在這三個設定中的任何一個中指定 AMIs。AMIs是在 `imageId`（在 中`computeResources`)、 `imageIdOverride`（在 中`ec2Configuration`) 或 中指定的啟動範本中指定`launchTemplate`。假設沒有在這些設定中指定 AMI IDs，且`updateToLatestImageVersion`設定為 `true`。然後， 支援的最新 Amazon ECS 最佳化 AMI AWS Batch 會用於任何基礎設施更新。 如果在其中至少一個設定中指定 AMI ID，則更新取決於提供更新之前使用的 AMI ID 的設定。當您建立運算環境時，選取 AMI ID 的優先順序是啟動範本、`imageId`設定，最後是`imageIdOverride`設定。不過，如果使用的 AMI ID 來自啟動範本，則更新 `imageId`或 `imageIdOverride`設定不會更新 AMI ID。更新從啟動範本選取的 AMI ID 的唯一方法是更新啟動範本。如果啟動範本的版本參數為 `$Default`或 `$Latest`，則會評估指定啟動範本的預設或最新版本。如果預設選取不同的 AMI ID，或選取最新版本的啟動範本，則會在更新中使用該 AMI ID。 如果啟動範本未用於選取 AMI ID，則會使用 `imageId`或 `imageIdOverride` 參數中指定的 AMI ID。如果同時指定兩者，則會使用 `imageIdOverride` 參數中指定的 AMI ID。 假設運算環境使用 `imageId`、 `imageIdOverride`或 `launchTemplate` 參數指定的 AMI ID，而且您想要使用 支援的最新 Amazon ECS 最佳化 AMI AWS Batch。然後，更新必須移除提供 AMI IDs的設定。對於 `imageId`，這需要為該參數指定空字串。對於 `imageIdOverride`，這需要為 `ec2Configuration` 參數指定空字串。 如果 AMI ID 來自啟動範本，您可以變更為下列 AWS Batch 其中一種方式支援的最新 Amazon ECS 最佳化 AMI： + 為 `launchTemplateId`或 `launchTemplateName` 參數指定空字串，以移除啟動範本。這會移除整個啟動範本，而不是單獨移除 AMI ID。 + 如果更新版本的啟動範本未指定 AMI ID，則 `updateToLatestImageVersion` 參數必須設定為 `true`。 ## 更新期間的任務處理 使用更新政策，設定在基礎設施更新期間處理執行中任務的方式。當您設定 時`terminateJobsOnUpdate=true`，執行中的任務會立即終止，系統會忽略`jobExecutionTimeoutMinutes`設定，並在執行個體可以取代時立即繼續更新。當您設定 時`terminateJobsOnUpdate=false`，執行中的任務會在指定的逾時期間內繼續，預設逾時為 30 分鐘，如果超過逾時，任務就會終止。 **注意** 若要重試在更新期間終止的任務，請設定任務重試策略。如需詳細資訊，請參閱[自動化任務重試](job_retries.md)。 ------ #### [ Performing infrastructure updates using the AWS 管理主控台 ] 1. 在 https：//[https://console.aws.amazon.com/batch/](https://console.aws.amazon.com/batch/) 開啟 AWS Batch 主控台。 1. 在導覽窗格中，選擇**環境**，然後選擇**運算環境**索引標籤。 1. 選取要更新的運算環境。 1. 選擇**動作**，然後選擇**編輯**。 1. 在**更新行為**區段中，設定執行中任務的處理方式： + 選擇將 **AMI 更新至最新版本**，將 AMI 更新至最新版本。 + 選擇**更新時立即終止任務**，以在執行更新程序時終止任務。 + 針對**任務執行逾時**，輸入開始更新程序之前要等待的分鐘數。 1. 修改需要[基礎設施更新的一或多個設定](#infrastructure-updates-triggers)。例如： + **執行個體角色** + **使用 EC2 Spot 執行個體** + **允許的執行個體類型** + **置放群組** + **EC2 金鑰對** + **EC2 組態** + **啟動範本** + **子網路** + **安全群組** 1. 選擇**儲存變更**。 1. 監控運算環境狀態。環境會在更新程序`UPDATING`期間顯示。 ------ #### [ Performing infrastructure updates using the AWS CLI ] 使用 **update-compute-environment**命令來變更一或多個[需要基礎設施更新的設定](#infrastructure-updates-triggers)。以下三個範例是常見的基礎設施操作。 + 此範例會更新執行個體類型並設定更新政策： ``` aws batch update-compute-environment \ --compute-environment your-compute-environment-name \ --compute-resources instanceTypes=default_x86_64 \ --update-policy terminateJobsOnUpdate=false,jobExecutionTimeoutMinutes=30 ``` + 此範例會更新 VPC 子網路和安全群組： ``` aws batch update-compute-environment \ --compute-environment your-compute-environment-name \ --compute-resources subnets=subnet-abcd1234,subnet-efgh5678 securityGroupIds=sg-abcd1234 \ --update-policy terminateJobsOnUpdate=true ``` + 此範例可自動更新至最新的 Amazon ECS 最佳化 AMI： ``` aws batch update-compute-environment \ --compute-environment your-compute-environment-name \ --compute-resources updateToLatestImageVersion=true \ --update-policy terminateJobsOnUpdate=false,jobExecutionTimeoutMinutes=60 ``` ------ ## 監控基礎設施更新 使用 AWS Batch 主控台監控您的基礎設施更新，以監看運算環境狀態變更為 `UPDATING`、監控執行個體替換進度，以及檢查是否有任何失敗的更新。一旦運算環境狀態為 ，更新就會成功`VAILD`。您也可以使用 CloudWatch 追蹤執行個體終止事件，並在更新期間監控任務狀態。使用 AWS CLI，使用 **describe-compute-environments**命令來檢查狀態並監控執行個體生命週期事件。 # 執行運算環境的藍/綠更新 藍/綠更新是一種更新策略，可透過與現有的運算環境 （藍色） 一起建立新的運算環境 （綠色） 來減少停機時間和風險。此方法可讓您逐步將工作負載轉換至新環境，同時保持現有環境的運作。藍/綠更新提供最安全的更新路徑，並使用任何服務角色類型或配置策略。 ## 概觀 藍/綠更新提供多種優點，使其非常適合生產環境。它們透過在更新過程中持續執行工作負載，提供*零停機時間*。此方法可*讓您輕鬆復原*功能，讓您可以在發生問題時快速還原至原始環境。您可以實作*逐步轉換*策略，在完全切換生產工作負載之前驗證新環境的效能。此方法也提供絕佳的*風險緩解*，因為原始環境會保持不變並運作，直到您選擇將其移除為止。 ### 需要藍/綠更新時 在下列情況下，您必須使用藍/綠更新： + 當您的運算環境使用`BEST_FIT`配置策略時 （不支援基礎設施更新） + 當您的運算環境不使用 *AWSServiceRoleForBatch* 服務連結角色時 + 當您需要在不同的服務角色類型之間轉換時 ### 建議藍/綠更新時 藍/綠更新特別建議用於生產環境，其中零停機時間對您的工作負載至關重要。當您在轉換生產工作負載之前需要測試新組態時，此方法可正常運作，確保變更符合您的效能和可靠性需求。當快速復原功能對您的操作很重要時，請選擇藍/綠更新，尤其是當您更新具有重大變更AMIs 時。當您想要在完全承諾變更之前驗證效能特性和行為，以提供更新程序的信心時，此方法也很理想。 ### 先決條件 在執行藍/綠更新之前，請確定您有： + 建立和管理運算環境的適當 [IAM 許可](IAM_policies.md#IAM_policies.title) + 檢視和修改任務佇列設定的存取權 + 為您的任務定義設定的任務重試策略，以處理轉換期間的潛在失敗。如需詳細資訊，請參閱[自動化任務重試](job_retries.md)。 + 新運算環境的 AMI ID。這可以是： + Amazon ECS 最佳化 AMI 的最新核准版本 （預設為使用） + 符合 Amazon ECS 容器執行個體 AMI 規格的自訂 AMI。使用自訂 AMI 時，您可以透過下列其中一種方式指定它： + 在 EC2 組態中使用**映像 ID 覆寫**欄位 + 在啟動範本中指定它 如需建立自訂 AMIs的詳細資訊，請參閱 [教學課程：建立運算資源 AMI](create-batch-ami.md)。 建立新環境之前，您需要記錄現有運算環境的組態。您可以使用 AWS 管理主控台 或 來執行此操作 AWS CLI。 **注意** 下列程序詳細說明如何執行只變更 AMI 的藍/綠更新。您可以更新新環境的其他設定。 **重要** 當您移除舊 （藍色） 運算環境時，這些執行個體上目前執行的任何任務都會失敗，因為執行個體將會終止。在任務定義中設定任務重試策略，以自動處理這些失敗。如需詳細資訊，請參閱[自動化任務重試](job_retries.md)。 對新環境有信心之後： 編輯任務佇列以移除舊的運算環境。 等待舊環境中任何執行中的任務完成。 刪除舊的運算環境。 ------ #### [ Performing blue/green updates using the AWS 管理主控台 ] 1. 複製您目前的運算環境 1. 在 https：//[https://console.aws.amazon.com/batch/](https://console.aws.amazon.com/batch/) 開啟 AWS Batch 主控台。 1. 選取您現有的運算環境。 1. 選擇**動作**，然後選擇**複製**。 1. 在**名稱**中，輸入新運算環境的唯一名稱。 1. 選擇**下一步**。 1. 在**執行個體組態**區段中，更新 AMI 設定： 1. 展開 **Additional configuration (其他組態)**。 1. 對於 **EC2 組態**，請在**映像類型中指定新的 AMI 類型**，並在**映像 ID 覆寫欄位中指定 AMI ID**。 1. 選擇**下一步**。 1. 針對**網路組態**，選擇**下一步**。 1. 檢閱從現有環境自動複製的其他設定。 1. 選擇**建立運算環境**。 1. 等待新的運算環境狀態變成 `VALID`。 1. 變更任務佇列順序 1. 在導覽窗格中，選擇**任務佇列**。 1. 選取與您現有運算環境相關聯的任務佇列。 1. 選擇**編輯**。 1. 在**連線運算環境中**，新增新的運算環境： + 新增訂單編號高於現有環境的新運算環境，以轉換工作負載。 + 驗證新環境是否正常運作後，您可以提供較低的訂單號碼，使其成為主要環境。 1. 選擇**更新任務佇列**。 1. 清除 1. 監控新環境中的任務執行，以確保一切如預期般運作。 1. 對新環境有信心之後： 1. 編輯任務佇列以移除舊的運算環境。 1. 等待舊環境中任何執行中的任務完成。 1. 刪除舊的運算環境。 ------ #### [ Performing blue/green updates using the AWS CLI ] 1. 若要使用 取得組態 AWS CLI，請使用下列命令： ``` aws batch describe-compute-environments \ --compute-environments your-compute-environment-name ``` 建立新環境時，請儲存輸出以供參考。 1. 使用現有環境的組態建立新的運算環境，但使用新的 AMI。以下是範例命令結構： 將範例值取代為上一個步驟的實際組態： ``` cat < ./blue-green-compute-environment.json { "computeEnvironmentName": "your-new-compute-environment-name", "type": "MANAGED", "state": "ENABLED", "computeResources": { "instanceRole": "arn:aws:iam::012345678901:instance-profile/ecsInstanceRole", "type": "EC2", "minvCpus": 2, "desiredvCpus": 2, "maxvCpus": 256, "instanceTypes": [ "optimal" ], "allocationStrategy": "BEST_FIT_PROGRESSIVE", "ec2Configuration": [ { "imageType": "ECS_AL2023", "imageIdOverride": "ami-0abcdef1234567890" } ], "subnets": [, "subnet-0abcdef1234567890" ], "securityGroupIds": [ "sg-0abcdef1234567890" ] } } EOF ``` ``` $ aws batch create-compute-environment --cli-input-json file://./blue-green-compute-environment.json ``` 1. 等待新的環境變成可用： ``` aws batch describe-compute-environments \ --compute-environments your-new-compute-environment-name \ --query 'computeEnvironments[].status' ``` 1. 將新的運算環境新增至您的任務佇列： ``` aws batch update-job-queue \ --job-queue your-job-queue \ --compute-environment-order order=1,computeEnvironment=your-existing-environment \ order=2,computeEnvironment=your-new-compute-environment-name ``` 1. 驗證後，請再次更新，讓新的環境成為主要環境： ``` aws batch update-job-queue \ --job-queue your-job-queue \ --compute-environment-order order=1,computeEnvironment=your-new-compute-environment-name ``` 在舊環境中完成所有任務之後，請停用 ，然後刪除它： ``` aws batch update-compute-environment \ --compute-environment your-existing-environment \ --state DISABLED ``` ``` aws batch delete-compute-environment \ --compute-environment your-existing-environment ``` ------