本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。 # 容器 現代化是一種轉型的旅程，提供許多選項，包括將單體分解為微服務、使用無伺服器函數 (AWS Lambda) 將應用程式重新架構為事件驅動，以及將資料庫從 SQL Server 重新轉換為 Amazon Aurora 或專用受管資料庫。將 .NET Framework 應用程式轉換為 Linux 和 Windows 容器的現代化途徑比其他現代化選項需要更少的精力。容器提供下列優點： + **加速創新** – 移至容器可讓您更輕鬆地自動化開發生命週期的階段，包括建置、測試和部署應用程式。透過自動化這些程序，開發和營運團隊有更多時間專注於創新。 + **降低總體擁有成本 (TCO)** – 轉移到容器也可以降低您對授權管理和端點保護工具的依賴。由於容器是暫時性的運算單位，因此您可以自動化並簡化修補、擴展和備份和還原等管理任務。這可降低管理和操作容器型工作負載的 TCO。最後，與虛擬機器相比，容器更有效率，因為您可以透過提供更好的隔離，使用容器來最大化應用程式的位置。這會增加應用程式基礎設施資源的使用率。 + **改善資源使用率** – 與虛擬機器相比，容器更有效率，因為您可以使用容器來最大化應用程式的位置。這可透過提供更好的隔離來提高應用程式的基礎設施資源使用率。 + **縮小技能差距** - AWS 提供沉浸式日，讓您的開發團隊提升容器技術和 DevOps 實務的技能。 **Topics** + [將 Windows 應用程式移至容器](windows-containers-main.md) + [最佳化 Amazon ECS 上 AWS Fargate 任務的成本](optimizer-ecs-fargate.md) + [了解 Amazon EKS 成本](kubecost-main.md) + [使用 App2Container 複寫 Windows 應用程式](app2container-main.md) 如需授權資訊，請參閱 Amazon Web Services 的授權**一節和 Microsoft：常見問答集或將您的問題透過電子郵件傳送至 [microsoft@amazon.com](mailto:microsoft@amazon.com)。 [https://aws.amazon.com/windows/faq/#licensing-q](https://aws.amazon.com/windows/faq/#licensing-q) # 將 Windows 應用程式移至容器 ## 概觀 根據 [CNCF 2021 年度調查](https://www.cncf.io/reports/cncf-annual-survey-2021/)，96% 的組織正在使用或評估容器來現代化其基礎設施。這是因為容器可協助您的組織降低風險、提高營運效率和速度，並啟用敏捷性。您也可以使用容器來降低執行應用程式的成本。本節提供跨容器服務以經濟實惠的方式執行 AWS 容器的建議，包括 [Amazon Elastic Container Service (Amazon ECS)](https://aws.amazon.com/ecs/)、[Amazon Elastic Kubernetes Service (Amazon EKS)](https://aws.amazon.com/eks/) 和 [AWS Fargate](https://aws.amazon.com/fargate/)。 ## 成本利益 下列資訊圖表顯示企業可以透過根據[AWS 最佳化和授權評估 (AWS OLA) ](https://aws.amazon.com/optimization-and-licensing-assessment/)建議，將 ASP.NET Framework 應用程式合併到 Amazon Elastic Compute Cloud (Amazon EC2) 執行個體來節省成本。下列資訊圖表顯示將應用程式移至 Windows 容器可以節省哪些額外成本。 ![\[ASP.NET 整合\]](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/optimize-costs-microsoft-workloads/images/asp_net_consolidation.png) OLA AWS 建議企業進行提升，並轉移到個別的 t3.small 執行個體。如下列效能使用率分析所示，企業可以在內部部署伺服器上執行七個 ASP.NET 應用程式，藉此節省這些成本。 ![\[效能使用率分析\]](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/optimize-costs-microsoft-workloads/images/perform_util_analysis-partA.png) 進一步分析顯示，透過在容器上執行工作負載，企業可以節省更多成本。容器可減少 CPU、RAM 和磁碟使用量等系統資源的作業系統額外負荷 （下一節說明）。在此案例中，企業可以將所有七個應用程式合併到一個 t3.large 執行個體，並且仍有 3 GB 的 RAM 可供備用。遷移至容器有助於企業使用容器而非 Amazon EC2，在運算和儲存之間平均節省 64% 的成本。 ## 成本最佳化建議 下一節提供透過整合應用程式和使用容器來最佳化成本的建議。 ### 減少 Amazon EC2 上的 Windows 使用量 Windows 容器可讓您將更多應用程式合併到較少Amazon EC2 EC2 上的 Windows 使用量。例如，假設您有 500 個 ASP.NET 應用程式。如果您為 Amazon EC2 上的 Windows 執行一個核心，則等於 500 個 Windows 執行個體 (t3.small)。如果您假設使用 Windows 容器 （使用 t3.large) 的比率為 1：7 （可能會根據 EC2 執行個體類型/大小而大幅增加），則只需要大約 71 個 Windows 執行個體。這表示您的 Windows on Amazon EC2 使用量減少了 85.8%。 ### 降低 Windows 授權成本 如果您授權 Windows 執行個體，則不需要授權在該執行個體上執行的容器。因此，使用 Windows 容器合併 ASP.NET 應用程式可以大幅降低您的 Windows 授權成本。 ### 減少您的儲存體使用量 每次啟動新的 EC2 執行個體時，您都會建立並支付新的 Amazon Elastic Block Store (Amazon EBS) 磁碟區，以容納作業系統。隨著規模擴展，成本也會隨之擴展。如果您使用容器，可以降低儲存成本，因為所有容器共用相同的基本作業系統。此外，容器會使用 layer 的概念，根據該映像為所有執行中的容器重複使用容器映像的不可變部分。在上述範例案例中，所有容器都會執行 .NET Framework，因此都會共用中繼和不可變的 ASP.NET Framework layer。 ### 將end-of-support伺服器遷移至容器 Windows Server 2012 和 Windows Server 2012 R2 的支援已於 2023 年 10 月 10 日結束。您可以遷移在 Windows Server 2012 或舊版上執行的應用程式，方法是將它們容器化以在新的作業系統上執行。如此一來，您就可以避免在不合規的作業系統上執行應用程式，同時利用容器提供的成本效率、降低風險、營運效率、速度和敏捷性。 如果您的應用程式需要與目前使用中的作業系統版本 （例如 COM Interop) 相關的特定 APIs，請謹慎考慮此方法。在此情況下，您必須測試將應用程式移至較新的 Windows 版本。Windows 容器會將基本容器映像 （例如 Windows Server 2019) 與容器主機的作業系統 （例如 Windows Server 2019) 對齊。測試和移至容器可讓您在未來更輕鬆地進行作業系統升級，方法是變更 Dockerfile 內的基本映像，並部署到執行最新版本 Windows 的新主機集。 ### 移除第三方管理工具和授權 管理您的伺服器機群需要使用數種第三方系統操作工具來進行修補和組態管理。這些可讓基礎設施管理變得複雜，而且您通常會產生第三方授權成本。如果您在 上使用容器 AWS，則不需要在作業系統端管理任何內容。容器執行時間會管理容器。這表示基礎主機是暫時性的，可以輕鬆取代。您可以執行容器，而不需要直接管理容器主機。此外，您可以使用 等免費工具 AWS Systems Manager Session Manager ，輕鬆存取主機並對問題進行故障診斷。 ### 改善控制和可攜性 相較於 EC2 執行個體，容器可讓您更精細地控制 CPU 和 RAM 等伺服器資源。對於 EC2 執行個體，您可以選取執行個體系列、執行個體類型和 CPU [選項來控制 CPU](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-optimize-cpu.html) 和 RAM。不過，使用容器時，您可以確切定義要配置給 ECS 任務定義中容器或 [Amazon EKS 中 Pod ](https://docs.aws.amazon.com/eks/latest/userguide/fargate-pod-configuration.html)的 CPU 或 RAM 數量。事實上，我們建議為 Windows [容器指定容器層級的 CPU 和記憶體](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/windows_task_definitions.html)。此精細程度可帶來成本效益。請考慮下列範例程式碼： ``` json { "taskDefinitionArn": "arn:aws:ecs:us-east-1:123456789012:task-definition/demo-service:1", "containerDefinitions": [ { "name": "demo-service", "image": "mcr.microsoft.com/dotnet/framework/samples:aspnetapp-windowsservercore-ltsc2019", "cpu": 512, "memory": 512, "links": [], "portMappings": [ { "containerPort": 80, "hostPort": 0, "protocol": "tcp" } ], ``` ### 加速創新 移至容器可讓您更輕鬆地自動化開發生命週期的階段，包括建置、測試和部署應用程式。如果您將這些程序自動化，則可以讓開發和營運團隊有更多時間專注於創新。 ### 降低 TCO 移至容器通常會減少對授權管理和端點保護工具的依賴。由於容器是暫時性的運算單位，因此您可以自動化並簡化修補、擴展和備份和還原等管理任務。這可以降低管理和操作容器型工作負載的 TCO。與虛擬機器相比，容器更有效率，因為它們可讓您最大化應用程式的置放，以便您可以提高應用程式的基礎設施資源使用率。 ### 關閉技能差距 AWS 提供計畫和沉浸式日，提升容器和 DevOps 技術的客戶開發團隊技能。這包括實作諮詢和啟用。 ### 重構 .NET 5\$1 並使用 Linux 容器 雖然您可以將 .NET Framework 應用程式移至容器來降低成本，但當您將舊版 .NET 應用程式重構為雲端原生替代方案時，可以進一步節省成本 AWS。 ### 移除授權成本 將您的應用程式從 Windows 上的 .NET Framework 重構為 Linux 上的 .NET Core，可節省約 45% 的成本。 ### 存取最新的增強功能 將您的應用程式從 Windows 上的 .NET Framework 重構為 Linux 上的 .NET Core，可讓您存取最新的增強功能，例如 Graviton2。相較於可比較的執行個體，Graviton2 提供 40% 更好的效能價格。 ### 改善安全性和效能 將您的應用程式從 Windows 上的 .NET Framework 重構為 Linux 上的 .NET Core，可改善安全性和效能。這是因為您取得最新的安全修補程式、受益於容器隔離，以及可存取新功能。 ### 使用 Windows 容器，而不是在一個 IIS 執行個體上執行許多應用程式 考慮以下優點：使用 Windows 容器，而不是在具有網際網路資訊服務 (IIS) 的 EC2 Windows 執行個體上執行多個應用程式： + **安全** – 容器提供開箱即用的安全層級，但無法透過 IIS 層級的隔離達成。如果一個 IIS 網站或應用程式遭到入侵，所有其他託管網站都會公開且容易受到攻擊。容器逸出很少見，而且比透過 Web 漏洞取得伺服器的控制更難利用。 + **彈性** – 能夠在程序隔離中執行容器，並讓自己的執行個體允許更精細的聯網選項。容器也在許多 EC2 執行個體中提供複雜的分佈方法。當您在單一 IIS 執行個體上合併應用程式時，不會獲得這些好處。 + **管理開銷** – 伺服器名稱指示 (SNI) 會建立需要管理和自動化的開銷。此外，您必須掌握典型的作業系統管理操作，例如修補、故障診斷 BSOD （如果沒有自動擴展）、端點保護等。根據[安全最佳實務](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/jj635855(v=ws.11))設定 IIS 網站是一項耗時且持續的活動。您甚至可能需要設定[信任層級](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/hh831532(v=ws.11))，這也會增加管理開銷。容器設計為無狀態且不變。最後，如果您改用 Windows 容器，您的部署會更快、更安全且可重複。 ## 後續步驟 投資現代基礎設施來執行舊版工作負載，為您的組織帶來巨大的優勢。 AWS 容器服務可讓您更輕鬆地管理基礎基礎設施，無論是在內部部署還是在雲端，因此您可以專注於創新和業務需求。雲端中幾乎有 80% 的容器在 AWS 今天執行。 為幾乎所有使用案例 AWS 提供一組豐富的容器服務。若要開始使用，請參閱 [Containers at AWS](https://aws.amazon.com/containers/)。 ## 其他資源 + [使用 ECS 容量提供者和 EC2 Spot 執行個體最佳化容器工作負載的成本 ](https://aws.amazon.com/blogs/containers/optimize-cost-for-container-workloads-with-ecs-capacity-providers-and-ec2-spot-instances/)(AWS 部落格） + [Amazon ECS 和 的成本最佳化檢查清單 AWS Fargate](https://aws.amazon.com/blogs/containers/cost-optimization-checklist-for-ecs-fargate/) (AWS 部落格） + [Amazon EKS on AWS Graviton2 已全面推出：多架構應用程式的考量事項](https://aws.amazon.com/blogs/containers/eks-on-graviton-generally-available/) (AWS 部落格） + [上的 Kubernetes 成本最佳化 AWS](https://aws.amazon.com/blogs/containers/cost-optimization-for-kubernetes-on-aws/) (AWS 部落格） + [使用 Karpenter 整合最佳化 Kubernetes 運算成本](https://aws.amazon.com/blogs/containers/optimizing-your-kubernetes-compute-costs-with-karpenter-consolidation/) (AWS 部落格） # 最佳化 Amazon ECS 上 AWS Fargate 任務的成本 ## 概觀 適當調整 AWS Fargate 任務的大小是成本最佳化的重要步驟。通常，應用程式是使用 Fargate 任務的任意大小來建置，而且永遠不會重新檢視。這可能會導致 Fargate 任務過度佈建和不必要的花費。本節說明如何使用 [AWS Compute Optimizer](https://aws.amazon.com/compute-optimizer/) 提供可行的建議，以便針對在 Fargate 上執行的 Amazon Elastic Container Service (Amazon ECS) 服務最佳化任務 CPU 和記憶體。Compute Optimizer 也會量化採用這些建議的成本影響。這可讓您根據節省機會的大小，排定最佳化工作的優先順序。Compute Optimizer 建議提供容器層級的 CPU 和記憶體組態，以縮減任務大小。 ## 成本利益 在 Fargate 上正確調整 Amazon ECS 任務的大小，可以為長時間執行的任務降低成本 30-70%。如果不檢閱應用程式效能指標以正確調整任務大小，您可以將 EC2 運算執行個體上使用的相同思維套用至容器大小。這會導致大型 Fargate 任務增加閒置資源的成本。您可以使用 Compute Optimizer 以反應方式呈現正確的大小調整機會。理想情況下，應用程式擁有者會檢閱特定應用程式效能指標，並移除作業系統額外負荷，以確保指定適當的任務大小。如需詳細資訊，請參閱本指南的將 [Windows 應用程式移至容器](windows-containers-main.md)一節。 ## 成本最佳化建議 本節提供使用 Compute Optimizer 在 Fargate 任務上正確調整 Amazon ECS 大小的建議。 作為成本最佳化程序的一部分，我們建議您執行下列動作： + 啟用運算最佳化工具 + 使用 Compute Optimizer 結果 + 標記要調整大小的任務 + 啟用成本分配標籤以使用 AWS 帳單工具 + 實作正確的大小調整建議 + 在 Cost Explorer 中檢閱成本前後 ### 啟用運算最佳化工具 您可以在[AWS Compute Optimizer](https://docs.aws.amazon.com/compute-optimizer/latest/ug/getting-started.html#account-opt-in)組織或單一帳戶層級啟用 AWS Organizations。整個組織的組態為所有成員帳戶在整個機群中新的和現有的執行個體提供持續報告。這可讓適當調整大小成為週期性活動，而不是point-in-time活動。 #### 組織層級 對於大多數組織而言，使用 Compute Optimizer 最有效率的方式是在組織層級。這可為您的組織提供多帳戶和多區域可見性，並將資料集中到一個來源以供檢閱。若要在組織層級啟用此功能，請執行下列動作： 1. 使用具有[必要許可](https://docs.aws.amazon.com/compute-optimizer/latest/ug/security-iam.html)的角色登入您的[AWS Organizations 管理帳戶](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html)，並選擇加入此組織中的所有帳戶。您的組織必須[啟用所有功能](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_org_support-all-features.html)。 1. 啟用管理帳戶後，您可以登入帳戶、查看所有其他成員帳戶，以及瀏覽他們的建議。 **注意** 最佳實務是設定 Compute Optimizer 的[委派管理員帳戶](https://docs.aws.amazon.com/compute-optimizer/latest/ug/delegate-administrator-account.html)。這可讓您執行最低權限原則，將 AWS Organizations 管理帳戶的存取權降到最低，同時仍提供整個組織的服務存取權。 #### 單一帳戶層級 如果您以成本高的帳戶為目標，但無法存取 AWS Organizations，您仍然可以為該帳戶和區域啟用 Compute Optimizer。若要了解選擇加入程序，請參閱 [入門 AWS Compute Optimizer](https://docs.aws.amazon.com/compute-optimizer/latest/ug/getting-started.html)。 **注意** 建議會每天重新整理，最多可能需要 12 小時才能產生。請記住，Compute Optimizer 在過去 14 天內需要 24 小時的指標，才能在 Fargate 上為 Amazon ECS 產生建議。如需詳細資訊，請參閱 Compute Optimizer 文件中的 [Fargate 上的 Amazon ECS 服務需求](https://docs.aws.amazon.com/compute-optimizer/latest/ug/requirements.html#requirements-ecs-fargate)。 Compute Optimizer 會自動分析 Fargate 上 Amazon ECS 服務的下列 Amazon CloudWatch 和 Amazon ECS 使用率指標： + `CPUUtilization` – 服務中使用的 CPU 容量百分比。 + `MemoryUtilization` – 服務中使用的記憶體百分比。 ### 使用 Compute Optimizer 結果 考慮一個範例，專注於在單一帳戶和單一區域中進行正確的調整大小變更。在此範例中，運算最佳化工具會在所有帳戶的組織層級啟用。請記住，適當調整大小是一種破壞性程序，在大多數情況下，應用程式擁有者會在數週的排程維護時段以精確度執行。 如果您在組織的管理帳戶中導覽至 Compute Optimizer （如下列步驟所示），您可以選擇要調查的帳戶。在此範例中，一個任務正在 中過度佈建的單一帳戶中執行`us-east-1`。重點是調整 Amazon ECS 服務的建議大小。 1. 開啟 [Compute Optimizer 主控台](https://console.aws.amazon.com/compute-optimizer/)。 1. 在**儀表板**頁面上，依**問題清單篩選=過度佈建**，以查看 Fargate 上的所有 Amazon ECS 服務。 1. 若要檢閱 **Fargate 上過度佈建 ECS 服務**的詳細建議，請向下** **捲動，然後選擇**檢視建議**。 1. 選擇**匯出**並儲存檔案以供日後使用。 **注意** 若要儲存建議以供未來檢閱，您必須有一個 S3 儲存貯體可供 Compute Optimizer 在每個區域中寫入 。如需詳細資訊，請參閱 Compute Optimizer 文件中的[適用於 的 Amazon S3 儲存貯體政策 AWS Compute Optimizer](https://docs.aws.amazon.com/compute-optimizer/latest/ug/create-s3-bucket-policy-for-compute-optimizer.html)。 若要查看 Compute Optimizer 的建議，請執行下列動作： 1. 在 [Compute Optimizer 主控台](https://console.aws.amazon.com/compute-optimizer/)中，前往**匯出建議**頁面。 1. 針對 **S3 儲存貯體目的地**，選擇您的 S3 儲存貯體。 1. 在**匯出篩選條件**區段中，針對**資源類型**，選擇 **Fargate 上的 ECS 服務**。 1. 在 **Fargate 的 ECS 服務建議**頁面上，深入了解 Fargate 上的其中一個 ECS 服務，並查看 Compute Optimizer 的 CPU 和記憶體建議。例如，檢閱**比較目前設定與建議任務大小**的建議，以及**比較目前設定與建議容器大小**區段的建議。 若要取得您需要正確調整大小的 Fargate ECS 服務清單，請執行下列動作： 1. 開啟 [Amazon S3 主控台](https://console.aws.amazon.com/s3/)。 1. 在導覽窗格中，選擇**儲存貯體**，然後選擇您匯出結果的儲存貯體。 1. 在**物件**索引標籤上，選取您的物件，然後選擇**下載**。 1. 在您下載的結果中，篩選調查結果欄，以僅顯示 Fargate 上的 **OVER\$1PROVISIONED** Amazon ECS 服務。這會顯示您計劃針對適當大小設定目標的 Amazon ECS 服務。 1. 將任務定義存放在文字編輯器中以供日後使用。 ### 適當調整標籤任務的大小 標記工作負載是在 中組織資源的強大工具 AWS。您可以使用標籤來深入了解成本並啟用退款。有許多方法和策略可將標籤新增至 資源， AWS 以處理退款和自動化。如需詳細資訊，請參閱 AWS 白皮書[標記 AWS 資源的最佳實務](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html)。下列範例使用 [AWS CloudShell](https://console.aws.amazon.com/cloudshell/home)來標記目標帳戶和 內屬於任何 Amazon ECS 服務一部分的所有任務 AWS 區域。 ``` #!/bin/bash # Set variables TAG_KEY="rightsizing" TAG_VALUE="enabled" # Get a list of ECS Clusters ClustersArns=$( aws ecs list-clusters –query 'clusterArns' –output text) for ClustersArn in $ClustersArns; do ServiceArns=$( aws ecs list-services –cluster $ClustersArn –query 'serviceArns' –output text) for ServiceArn in $ServiceArns; do TasksArns=$( aws ecs list-tasks –cluster $ClustersArn –service-name $ServiceArn –query 'taskArns' –output text) for TasksArn in $TasksArns; do aws ecs tag-resource –resource-arn $TasksArn –tags key=$TAG_KEY,value=$TAG_VALUE done done done ``` 下列程式碼範例示範如何啟用[標籤傳播](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html#ECS-UpdateService-request-propagateTags)至所有 Amazon ECS 服務。 ``` #!/bin/bash # Set variables TAG_KEY="rightsizing" TAG_VALUE="enabled" # Get a list of ECS Clusters ClustersArns=$(aws ecs list-clusters --query 'clusterArns' --output text) for ClustersArn in $ClustersArns; do ServiceArns=$(aws ecs list-services --cluster $ClustersArn --query 'serviceArns' --output text) for ServiceArn in $ServiceArns; do aws ecs update-service --cluster $ClustersArn --service $ServiceArn --propagate-tags SERVICE &>/dev/null aws ecs tag-resource --resource-arn $ServiceArn --tags key=$TAG_KEY,value=$TAG_VALUE done done ``` ### 啟用成本分配標籤以使用 AWS 帳單工具 我們建議您啟用使用者定義的成本分配標籤。這可讓計費 AWS 工具 （例如 AWS Cost Explorer 和） 識別和篩選**權利調整**標籤 AWS Cost and Usage Report。如果您未啟用此功能，則標籤篩選選項和資料將無法使用。如需使用成本分配標籤的資訊，請參閱 文件中的 AWS 帳單與成本管理 [啟用使用者定義的成本分配標籤](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/activating-tags.html)。 等待 24 小時後，您可以在 Cost Explorer 中看到 標籤，然後在下一節實作正確的大小調整建議。若要這樣做，請在 Cost Explorer 中搜尋 **Rightsizing** 標籤。 ### 實作正確的大小調整建議 Compute Optimizer 將提供任務或容器大小建議。若要實作正確的大小調整建議，請執行下列動作。 1. 開啟 [Amazon ECS 主控台](https://console.aws.amazon.com/ecs/v2)。 1. 從導覽列中選擇包含您任務定義的區域。 1. 在導覽窗格中，選擇 **Task Definitions** (任務定義)。 1. 在 **Task definitions** (任務定義) 頁面上，選擇任務，然後選擇 **Create new revision** (建立新修訂版)。 1. 在 **Create new task definition revision** (建立新任務定義修訂版) 頁面上進行變更。若要更新容器大小建議，請在 [ECS 任務定義](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html#task_size)中的 **containerDefinitions** 區塊`memory`下更新 `cpu`和 。例如： ``` "containerDefinitions": [ { "name": "your-container-name", "image": "your-image", "cpu": 1024, "memory": 2048, } ], ``` 1. 驗證資訊，然後選擇 **Create** (建立)。 若要更新 Amazon ECS 服務，請執行下列動作： 1. 開啟 [Amazon ECS 主控台](https://console.aws.amazon.com/ecs/v2)。 1. 在 **Clusters** (叢集) 頁面上，選取您的叢集。 1. 在 **Cluster overview** (叢集概觀) 頁面中，選取服務，然後選擇 **Update** (更新)。 1. 針對 **Task definition** (任務定義)，選擇要使用的任務定義系列和修訂。 對於進階運算子，您可以使用 CloudShell 更新 Amazon ECS 服務。例如： ``` bash #!/bin/bash # Set variables ClustersName="workshop-cluster" ServiceName="lab7-fargate-service" TaskDefinition="lab7-fargate-demo:3" # update the service aws ecs update-service --cluster $ClustersName --service $ServiceName --task-definition $TaskDefinition ``` ### 檢閱成本前後 在您正確調整資源大小後，您可以使用 Cost Explorer，透過使用 **Rightsizing** 標籤來顯示成本前後。請記住，您可以使用[資源標籤](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html)來追蹤成本。透過使用多層標籤，您可以實現對成本的精細可見性。在本指南中涵蓋的範例中，**Rightizing** 標籤用於將一般標籤套用至所有目標執行個體。然後，**團隊**標籤用於進一步組織資源。下一個步驟是介紹應用程式標籤，以進一步顯示操作特定應用程式的成本影響。 考慮一個範例，說明在單一帳戶層級使用 **Rightsizing** 標籤可以實現的成本降低。在此範例中，營運成本從每天 30.26 美元降至每天 7.56 美元。假設每月 744 小時，適當調整規模之前的年度成本為 11，044.9 美元。在適當調整規模後，年成本降至 2，759.4 美元。這表示此帳戶的運算成本降低了 75%。試想這在大型組織中的影響。 開始適當調整大小的旅程之前，請考慮下列事項： + AWS 提供許多降低成本的選項。這包括 [AWS OLA](https://aws.amazon.com/optimization-and-licensing-assessment/)，其中 會在移至 之前 AWS 檢閱您的現場部署執行個體 AWS。OLA AWS 也為您提供適當大小的建議和授權指導。 + 購買 [Savings Plans](https://aws.amazon.com/savingsplans/) 之前，請先完成所有正確的調整大小。這可協助您避免在 Savings Plans 承諾上過度購買。 ## 後續步驟 我們建議執行下列步驟： 1. 檢閱您現有的環境，並考慮將 Amazon EBS gp2 磁碟區轉換為 gp3 磁碟區。 1. 檢閱 [Savings Plans](https://aws.amazon.com/savingsplans/)。 ## 其他資源 + [Compute Optimizer 入門 ](https://aws.amazon.com/compute-optimizer/getting-started/)(AWS 文件） + [標記 AWS 資源的最佳實務](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html) (AWS 白皮書） + [上的 Windows 容器 AWS](https://catalog.us-east-1.prod.workshops.aws/workshops/1de8014a-d598-4cb5-a119-801576492564/en-US) (AWS Workshop Studio) # 了解 Amazon EKS 成本 ## 概觀 全面檢視是有效監控 Kubernetes 部署成本的必要條件。唯一的固定和已知成本是 Amazon Elastic Kubernetes Service (Amazon EKS) 控制平面。這包括組成部署的所有其他元件，從運算和儲存到聯網，都是根據您的應用程式需求的可變數量。 您可以使用 [Kubecost](https://www.kubecost.com/) 來分析從[命名空間](https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/)[和服務](https://kubernetes.io/docs/concepts/services-networking/service/)到個別 [Pod](https://kubernetes.io/docs/concepts/workloads/pods/) 的 Kubernetes 基礎設施成本，然後在儀表板中顯示資料。Kubecost 表面叢集內成本，例如運算和儲存，以及 out-of-cluster成本。 [Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html) [Amazon Relational Database Service ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Welcome.html) Kubecost 會根據此資料提出適當大小的建議，並顯示可能影響系統的關鍵警示。Kubecost 可與 [整合](https://www.ibm.com/docs/en/kubecost/self-hosted/1.x?topic=integrations-aws-cloud-billing-integration)[AWS Cost and Usage Report](https://docs.aws.amazon.com/cur/latest/userguide/what-is-cur.html)，以顯示 [Compute Savings Plans](https://docs.aws.amazon.com/savingsplans/latest/userguide/what-is-savings-plans.html)、[預留執行個體](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-reserved-instances.html)和其他折扣計劃的節省。 ## 成本利益 Kubecost 提供可視覺化 Amazon EKS 部署成本的報告和儀表板。它可讓您從叢集向下切入各個元件，例如控制器、服務、節點、Pod 和磁碟區。這可讓您全面檢視在 Amazon EKS 環境中執行的應用程式。透過啟用此可見性，您可以根據 Kubecost 建議採取行動，或精細檢視每個應用程式的成本。正確調整 Amazon EKS 節點群組的大小可提供與標準 EC2 執行個體相同的潛在節省成本。如果您可以正確調整容器和節點的大小，則可以從執行容器所需的執行個體大小，以及自動擴展群組中所需的 EC2 執行個體數量中移除運算膨脹。 ## 成本最佳化建議 若要利用 Kubecost，建議您執行下列動作： 1. 將 Kubecost 部署到您的環境 1. 取得 Windows 應用程式的精細成本明細 1. 正確大小的叢集節點 1. 適當大小的容器請求 1. 管理未充分利用的節點 1. 修正捨棄的工作負載 1. 根據建議採取行動 1. 更新自我管理節點 ### 將 Kubecost 部署到您的環境 [Amazon EKS Finhack 研討會](https://catalog.us-east-1.prod.workshops.aws/workshops/c4ab40ed-0299-4a4e-8987-35d90ba5085e/en-US)會教導您如何在 AWS 擁有的帳戶中部署設定為使用 Kubecost 的 Amazon EKS 環境。這可讓您取得 技術的實作體驗。如果您有興趣在您的組織中執行此研討會，請聯絡您的客戶團隊。 若要使用 [Helm](https://helm.sh/) 將 Kubecost 部署到您的 Amazon EKS 叢集，請參閱 AWS 部落格上的 [AWS 和 Kubecost 協作，為 EKS 客戶提供成本監控](https://aws.amazon.com/blogs/containers/aws-and-kubecost-collaborate-to-deliver-cost-monitoring-for-eks-customers/)。或者，您可以參考[官方 Kubecost 文件](https://www.ibm.com/docs/en/kubecost/self-hosted/3.x?topic=installation)，以取得有關安裝和設定 Kubecost 的說明。如需 Windows 節點的 Kubecost 支援相關資訊，請參閱 [Kubecost 文件中的 Windows 節點支援](https://www.ibm.com/docs/en/kubecost/self-hosted/3.x?topic=configuration-windows-node-support)。 ### 取得 Windows 應用程式的精細成本明細 雖然您可以使用 [Amazon EC2 Spot 執行個體](https://aws.amazon.com/ec2/spot/)來大幅節省成本，但您也可以受益於 Windows 工作負載往往具有狀態。Spot 執行個體的使用取決於應用程式，建議您驗證它們是否適用於您的使用案例。 若要取得 Windows 應用程式的精細成本明細，[請登入 Kubecost](https://auth.app.kubecost.com/login)。在導覽頁面中，選擇**節省**。 ### 正確大小的叢集節點 在 [Kubecost](https://auth.app.kubecost.com/login) 中，從導覽列選擇**節省**，然後選擇**大小正確的叢集節點**。 試想一個範例，其中 Kubecost 報告叢集在 vCPU 和 RAM 方面都過度佈建。下表顯示 Kubecost 的詳細資訊和建議。 **** |   | Current | 建議：簡單 | 建議：複雜 | | --- | --- | --- | --- | | 總計數 | 每月 3462.57 美元 | 每月 137.24 美元 | 每月 303.68 美元 | | 節點計數 | 4 | 5 | 4 | | CPU | 74 VCPUs | 10 VCPUs | 8 VCPUs | | RAM | 152 GB | 20 GB | 18 GB | | 執行個體明細 | 2 c5.xlarge \$1 其他 2 個 | 5 t3a.medium | 2 c5n.large \$1 其他 1 個 | 如 Kubecost 部落格文章所述 [尋找 Kubernetes 叢集的最佳節點集](https://blog.kubecost.com/blog/cluster-right-sizing/)，簡單選項會使用單一節點群組，而複雜節點則使用多節點群組方法。**了解如何採用**按鈕可以執行一鍵式叢集調整大小。它需要安裝 [Kubecost 叢集控制器](https://www.ibm.com/docs/en/kubecost/self-hosted/3.x?topic=configuration-cluster-controller)。 如果您使用的是非由 [eksctl](https://eksctl.io/) 建立的[自我管理 Windows 節點](https://docs.aws.amazon.com/eks/latest/userguide/launch-windows-workers.html)，請參閱[更新現有的自我管理節點群組](https://docs.aws.amazon.com/eks/latest/userguide/update-stack.html)。這些指示說明如何在 [Auto Scaling 群組](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-groups.html)使用的 Amazon EC2 啟動範本中變更執行個體類型。 ### 適當大小的容器請求 在 [Kubecost](https://auth.app.kubecost.com/login) 中，從導覽列選擇 **Savings**，然後前往**請求適當大小建議**頁面。此頁面顯示 Pod 的[效率](https://www.ibm.com/docs/en/kubecost/self-hosted/2.x?topic=dashboard-efficiency-idle)、適當大小的建議，以及預估的成本節省。您可以使用**自訂**按鈕，依**叢集**、**節點**、**命名空間\$1控制器**等進行篩選。 例如，假設 Kubecost 已計算出您的一些 Pod 在 CPU 和 RAM （記憶體） 方面過度佈建。然後，Kubecost 建議您調整為新的 CPU 和 RAM 值，以實現其估計每月節省。若要變更 CPU 和 RAM 值，您必須更新[部署資訊](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/)清單檔案。 ### 管理未充分利用的節點 在 [Kubecost](https://auth.app.kubecost.com/login) 中，從導覽列選擇**節省**，然後選擇**管理未充分利用的節點**。 試想一個範例，其中頁面顯示叢集中的一個節點在 CPU 和 RAM （記憶體） 方面未充分利用，因此可以耗盡並終止或調整大小。選擇未通過節點和 Pod 檢查的節點，將為您提供為什麼無法耗盡它們的詳細資訊。 ### 修正捨棄的工作負載 在 [Kubecost](https://auth.app.kubecost.com/login) 中，從導覽列中選擇**節省**，然後選擇**捨棄的工作負載**頁面。在此範例中，您會依稱為 **windows** 的命名空間進行篩選。此頁面顯示不符合流量閾值且被視為已捨棄的 Pod。Pod 需要在定義的期間內傳送或接收特定數量的網路流量。 仔細考慮捨棄一或多個 Pod 之後，您可以縮減複本數量、刪除部署、調整其大小以使用較少的資源，或通知應用程式擁有者您認為捨棄部署，以節省成本。 ### 根據建議採取行動 在**適當大小的叢集節點**區段中，Kubecost 會分析叢集中工作者節點的使用情況，並針對正確調整節點大小以降低成本提出建議。有兩種類型的節點群組可與 Amazon EKS 搭配使用：[自我管理和](https://docs.aws.amazon.com/eks/latest/userguide/worker.html)[受管](https://docs.aws.amazon.com/eks/latest/userguide/managed-node-groups.html)。 ### 更新自我管理節點 如需有關更新自我管理節點的資訊，請參閱 Amazon EKS 文件中的[自我管理節點更新](https://docs.aws.amazon.com/eks/latest/userguide/update-workers.html)。它指出`eksctl`無法使用 建立的節點群組無法更新，而且必須遷移至具有新組態的新節點群組。 例如，假設您有一個名為`ng-windows-m5-2xlarge`** **（使用 m5.2xlarge EC2 執行個體） 的 Windows 節點群組，而且您想要將 Pod 遷移到名為`ng-windows-t3-large`** **（由 t3.large EC2 執行個體支援以節省成本） [的新節點群組](https://docs.aws.amazon.com/eks/latest/userguide/launch-windows-workers.html)。 若要在使用 所部署的節點群組時遷移至新的節點群組`eksctl`，請執行下列動作： 1. 若要尋找 Pod 目前的節點，請執行 `kubectl describe pod -n `命令。 1. 執行 `kubectl describe node ` 命令。輸出顯示節點正在 m5.2xlarge 執行個體上執行。它也符合節點群組名稱 (`ng-windows-m5-2xlarge`)。 1. 若要將部署變更為使用節點群組 `ng-windows-t3-large`，請刪除節點群組`ng-windows-m5-2xlarge`並執行 `kubectl describe svc,deploy,pod -n windows`。部署現在在其節點群組已刪除時立即開始重新部署。 **注意** 當您刪除節點群組時，服務將會停機。 1. 幾分鐘後再次執行`kubectl describe svc,deploy,pod -n windows`命令。輸出顯示 Pod 再次處於**執行**中狀態。 1. 若要顯示 Pod 現在正在節點群組 上執行`ng-windows-t3-large`，請再次執行 `kubectl describe pod -n `和 `kubectl describe node `命令。 ### 替代調整大小方法 此方法適用於自我管理或受管節點群組的任意組合。[無縫遷移工作負載從 EKS 自我管理節點群組到 EKS 受管節點群組](https://aws.amazon.com/blogs/containers/seamlessly-migrate-workloads-from-eks-self-managed-node-group-to-eks-managed-node-groups/)部落格文章提供指引，說明如何將工作負載從具有大型執行個體類型的一個節點群組遷移到大小正確的節點群組，而不會停機。 ## 後續步驟 Kubecost 可讓您輕鬆地將 Amazon EKS 環境的成本視覺化。Kubecost 與 Kubernetes 和 AWS APIs深度整合可協助您找到潛在的成本節省。您可以在 Kubecost 的 **Savings** 儀表板中將這些視為建議。Kubecost 也可以透過其[叢集控制器功能](https://github.com/kubecost/cluster-turndown)為您實作其中一些建議。 我們建議您檢閱 和 Kubecost 協作中的step-by-step部署，以從 AWS 容器部落格為 EKS 客戶提供成本監控部落格文章。 [AWS](https://aws.amazon.com/blogs/containers/aws-and-kubecost-collaborate-to-deliver-cost-monitoring-for-eks-customers/) ## 其他資源 + [Amazon EKS 研討會](https://www.eksworkshop.com/) (Amazon EKS 研討會） + [AWS 和 Kubecost 協同合作，為 EKS 客戶提供成本監控](https://aws.amazon.com/blogs/containers/aws-and-kubecost-collaborate-to-deliver-cost-monitoring-for-eks-customers/) (AWS 部落格） + [Amazon EKS Finhack 研討會](https://catalog.us-east-1.prod.workshops.aws/workshops/c4ab40ed-0299-4a4e-8987-35d90ba5085e/en-US) (AWS Workshop Studio) + [上的 Windows 容器 AWS](https://catalog.us-east-1.prod.workshops.aws/workshops/1de8014a-d598-4cb5-a119-801576492564/en-US) (AWS Workshop Studio) # 使用 App2Container 複寫 Windows 應用程式 ## 概觀 [AWS App2Container](https://docs.aws.amazon.com/app2container/latest/UserGuide/what-is-a2c.html) 是一種命令列工具，可將 Java 和 .NET Web 應用程式遷移和現代化為容器。App2Container 會分析並建置在裸機、虛擬機器、Amazon Elastic Compute Cloud (Amazon EC2) 執行個體或其他雲端提供者中執行之所有應用程式的清查。您選取要容器化的應用程式。App2Container 會將應用程式成品和相依性封裝至容器映像、設定網路連接埠，並產生必要的 Amazon Elastic Container Service (Amazon ECS) 和 Amazon Elastic Kubernetes Service (Amazon EKS) 部署成品，這些成品是基礎設施即程式碼 (IaC) 範本。App2Container 佈建將容器化應用程式部署至生產環境所需的雲端基礎設施和 CI\$1CD 管道。如需詳細資訊，請參閱 [ App2Container 文件中的 App2Container 運作方式](https://docs.aws.amazon.com/app2container/latest/UserGuide/what-is-a2c.html)。 App2Container 使用 App2Container，您可以將應用程式遷移至容器 AWS 並將其現代化，同時將應用程式的部署和操作標準化。您可以使用 App2Container 協助快速建置概念驗證 (PoC)，或加速在容器中部署生產工作負載。 使用 Windows 應用程式時，有幾件事需要記住。App2Container 支援在 Microsoft Internet Information Services (IIS) 上部署的 ASP.NET 應用程式容器化，包括在 Windows Server 2016、Windows Server 2019 或 Windows Server Core 2004 上執行的 IIS 託管 Windows Communication Foundation (WCF) 應用程式。如需詳細資訊，請參閱 App2Container 文件中的 [Windows 支援的應用程式](https://docs.aws.amazon.com/app2container/latest/UserGuide/supported-applications.html)。App2Container 使用 Windows Server Core 做為其容器成品的基礎映像，將 Windows Server Core 容器版本與您執行容器化命令的伺服器作業系統 (OS) 版本相符。此方法會將應用程式與基礎作業系統分離，讓您可以在不執行傳統遷移的情況下升級作業系統。 如果您使用工作者機器將應用程式容器化，容器基礎映像，例如 Windows Server 2019 長期服務管道 (LTSC)，會與您的工作者機器作業系統相符，例如 Windows Server 2019。如果您直接在應用程式伺服器上執行容器化，版本會與您的應用程式伺服器作業系統相符。如果您的應用程式在 Windows Server 2008 或 2012 R2 上執行，您仍然可以透過設定工作者機器進行容器化和部署步驟來使用 App2Container。App2Container 不支援在 Windows 用戶端作業系統上執行的應用程式，例如 Windows 7 或 Windows 10。App2Container 支援適用於 Java 程序的 Tomcat、TomEE 和 JBoss （獨立模式） 架構。如需詳細資訊，請參閱 [App2Container 相容性](https://docs.aws.amazon.com/app2container/latest/UserGuide/compatibility-a2c.html)。 ## 成本利益 與one-application-to-one-server部署設計模式相比，容器化和合併應用程式可以[節省高達 60% 的運算](https://catalog.workshops.aws/msft-costopt/en-US/containers/moving-to-containers)成本。App2Container 可協助加速應用程式容器化程序。以下是使用 App2Container 滿足您的現代化需求的一些優點： + App2Container 免費提供。 + App2Container 支援容器映像中的多個應用程式。 + 使用 App2Container 將舊版 .NET 應用程式移至容器，以解決即將終止支援的作業系統。您可以移至較新的作業系統，避免支付延伸支援的費用，並降低安全風險。 + 容器是封裝 .NET 應用程式的有效且符合成本效益的方法。在 [MACO 建議 - 移至](https://catalog.workshops.aws/msft-costopt/en-US/containers/moving-to-containers)容器中檢閱容器的優點。 + 應用程式整合和容器化可透過更有效率地使用您的運算資源，協助減少您的運算、儲存和授權使用量。 + 移至容器可以降低營運開銷和基礎設施成本，並提高開發可攜性和部署敏捷性。 ## 成本最佳化建議 如需如何使用 App2Container 的說明，請參閱 [入門 AWS App2Container](https://docs.aws.amazon.com/app2container/latest/UserGuide/start-intro.html)。如需 App2Container 命令的相關資訊，請參閱 [App2Container 命令參考](https://docs.aws.amazon.com/app2container/latest/UserGuide/a2c-commands.html)。 ## 後續步驟 App2Container 可以加速容器化應用程式和部署至 Amazon EKS 或 Amazon ECS 的程序。將應用程式部署到容器可減少運算、聯網和儲存成本，並降低應用程式運算子的操作開銷。 如需 App2Container 的實際操作體驗，請參閱 [Modernize with AWS App2Container Workshop](https://catalog.us-east-1.prod.workshops.aws/workshops/2c1e5f50-0ebe-4c02-a957-8a71ba1e8c89/en-US)。如果您想要有深入學習體驗，請要求您的 AWS 客戶團隊設定 App2Container 沉浸日。 ## 其他資源 + [使用 容器化複雜的多層 Windows 應用程式 AWS App2Container](https://aws.amazon.com/blogs/modernizing-with-aws/containerizing-complex-multi-tier-windows-applications-aws-app2container/) (AWS 部落格文章） + [使用 容器化舊版 ASP.NET 應用程式 AWS App2Container](https://aws.amazon.com/blogs/modernizing-with-aws/containerizing-legacy-asp-net-applications-using-aws-app2container-a2c/) (AWS 部落格文章） + [App2Container 支援的應用程式](https://docs.aws.amazon.com/app2container/latest/UserGuide/supported-applications.html) (AWS 文件） + [使用 AWS App2Container 研討會現代化](https://catalog.us-east-1.prod.workshops.aws/workshops/2c1e5f50-0ebe-4c02-a957-8a71ba1e8c89/en-US) (AWS 研討會工作室） + [AWS App2Container FAQs](https://aws.amazon.com/app2container/faqs/) (AWS 網站）