Amazon DOP-C02: CI/CD 管線與部署策略 — 學習指南

By Laurynas Brazys · 4 August 2026 · #amazon #dop-c02 #certification #exam-prep #study-guide

屬於 AWS DevOps Engineer Professional DOP-C02 — 學習指南. 使用經過驗證的解答練習： Amazon 考試中心, 或參加限時模擬考試： ExamRoll.io.

總覽

一個健全的 AWS CI/CD 系統，會將跨多個帳戶和區域的原始碼控制、建置、測試、成品治理、部署協調以及安全的發布策略整合在一起。其核心託管服務——CodeCommit、CodeArtifact、CodeBuild、CodePipeline 和 CodeDeploy——免除了伺服器維護的負擔，與 IAM 和 KMS 緊密整合，並為部署到 EC2/Auto Scaling、ECS 和 Lambda 的藍/綠、金絲雀、滾動式及就地部署提供一流的支援。高效的 pipeline 也仰賴精確的觸發器（webhook、EventBridge、排程）、嚴謹的成品管理、用於加速的建置快取，以及搭配健康狀態警報以實現自動回滾的特定模式流量轉移。對企業而言，跨帳戶和跨區域的模式是必要的，這需要角色擔任、區域性成品存放區和一致的加密政策。

使用 AWS 開發人員工具進行協調

使用 CodeCommit 作為一個私有、高可用性的 Git 服務。它與 EventBridge 整合以處理儲存庫和 pull request 事件，支援核准規則範本，並使用 IAM 進行精細的授權。對於第三方 Git（GitHub/Bitbucket），可設定 CodePipeline 的來源動作搭配 webhook，以實現近乎即時的觸發。

CodeArtifact 為多個生態系統（npm、Maven、PyPI、NuGet）集中管理套件。它支援與公開註冊庫的上游連線並具備快取功能、每個儲存庫的 KMS 加密，以及會自動過期的範圍限定驗證權杖。在 CodeBuild 中，透過在 pre_build 階段呼叫

undefined

來整合，以設定套件管理器，而無需嵌入長期有效的密鑰。

CodeBuild 提供短暫、容器化的建置環境，無需管理工作節點。關鍵功能包括：

• 環境隔離和 VPC 支援，以存取私有依賴項目。為 Docker 建置啟用特權模式，並啟用本地 Docker 圖層快取以加速映像檔建置。
• 環境變數來自三個來源：純文字、SSM Parameter Store 和 Secrets Manager（預設安全，無硬編碼密鑰）。您也可以從 CodePipeline 傳遞變數。
• 用於縮短建置時間的快取：
  • 本地快取：原始碼快取、Docker 圖層快取，以及建置主機上的自訂目錄。
  • S3 快取：可在不同建置之間共享的可重用依賴項目集。
• 成品管理：指定 primary 和 secondaryArtifacts 來發布多個輸出（例如，應用程式套件和 CloudFormation 範本）。使用 KMS 金鑰加密成品，並避免使用公開的 ACL。
• 報告：將日誌傳送到 CloudWatch Logs/S3。使用報告來呈現測試結果，並使用 CodeBuild 徽章作為 PR 的回饋。

CodePipeline 是協調器。定義多個階段（來源、建置、測試、部署、核准），其中的動作可以並行或循序執行。最佳實踐：

• 觸發器：
  • 對於 GitHub/Bitbucket 來源，使用 Webhook。
  • 對於 CodeCommit 分支變更，使用 EventBridge 規則；當 pipeline 無法啟動時，請檢查此規則是否存在。
  • 透過呼叫

undefined

的 EventBridge 排程規則來實現排程的 pipeline。

• 成品存放區：pipeline 使用的每個區域一個 S3 儲存貯體；使用客戶管理的 KMS 金鑰。對於跨區域的動作，需新增區域性的成品存放區。
• 手動核准：搭配 SNS 或 EventBridge 來整合聊天/webhook，以實現近乎即時的通知。
• 精細的 IAM：一個具備最小權限的 pipeline 服務角色；對於跨帳戶操作，則由每個動作擔任各自的角色。

CodeDeploy 是部署引擎，支援 EC2/on-prem、ECS 和 Lambda 等目標。它管理生命週期掛鉤、流量轉移、健康狀態檢查，並透過 CloudWatch 警報實現自動回滾。請確保 EC2 執行個體上運行 CodeDeploy 代理程式、擁有一個執行個體設定檔，並具備對 CodeDeploy 端點的對外連線能力（或透過 NAT 的出口流量）。被跳過的事件和無操作的部署通常表示代理程式、權限或連線方面有問題。

部署策略與 CodeDeploy 生命週期

根據風險、容量和平台選擇策略：

• 就地部署 (In-place) (EC2/on-prem)：在現有的執行個體上更新應用程式。可與 OneAtATime、HalfAtATime 或 AllAtOnce 部署組態結合使用。附加一個 ELB 來排除流量並重新註冊執行個體。
• 滾動式部署 (Rolling) (ECS)：在同一個服務上分批替換任務。可以是原生的 ECS 滾動式更新，或透過 CodeDeploy 以藍/綠部署方式進行受控的流量轉移。
• 藍/綠部署 (Blue/green)：
  • EC2/Auto Scaling：佈建一個綠色的 ASG，進行驗證，然後將流量從藍色環境切換到綠色環境。可選擇性地終止或保留藍色環境。
  • ECS：在第二個目標群組後方建立一個替代的任務集；進行驗證，然後切換接聽器。
  • Lambda：將別名流量轉移到新的函數版本並進行監控。
• 金絲雀部署 (Canary)：先轉移一小部分百分比的流量（例如 10%），觀察一段時間，然後完成部署。
• 線性部署 (Linear)：以相等的步驟增加流量（例如，每 5 分鐘增加 10%）。

CodeDeploy 的 appspec.yml 定義了要安裝的內容以及執行腳本的時機：

• 對於 EC2/On-Prem (YAML)：
  • files：放置檔案的位置。
  • permissions：無需自訂腳本即可更新檔案所有權/模式。
  • hooks (通用)：ApplicationStop、BeforeInstall、Install、AfterInstall、ApplicationStart、ValidateService。
  • 流量控制 hooks (當使用負載平衡器時)：BeforeBlockTraffic、AfterBlockTraffic、BeforeAllowTraffic、AfterAllowTraffic。
  • 使用預先定義的環境變數（例如 DEPLOYMENT_GROUP_NAME、DEPLOYMENT_ID、LIFECYCLE_EVENT）來動態修改行為而無需個別的修訂版本，例如根據不同的部署群組切換 Apache 的日誌級別。
• 對於 ECS：
  • resources：包含 TaskDefinition 和 LoadBalancerInfo 的 TargetService。
  • hooks：BeforeInstall、AfterInstall、AfterAllowTestTraffic、BeforeAllowTraffic、AfterAllowTraffic。
  • AfterAllowTestTraffic 非常適合在帶有測試接聽器的綠色任務集上執行煙霧測試/整合測試。
• 對於 Lambda：
  • resources 定義了要轉移的函數、版本和別名。
  • hooks：BeforeAllowTraffic 和 AfterAllowTraffic。

流量轉移與回滾：

• 設定部署組態：
  • Lambda/ECS：Canary10Percent15Minutes、Canary10Percent5Minutes、Linear10PercentEvery1Minute、AllAtOnce 或自訂組態。
  • EC2 藍/綠部署：透過負載平衡器接聽器/目標群組進行一次性 (All-at-once)、金絲雀 (canary) 或線性 (linear) 的流量重新路由。
• 將 CloudWatch 警報新增至部署群組，以便在發生錯誤、5xx 或自訂指標異常時自動回滾。對於 ECS，警報可以監控目標群組的 5xx 錯誤或服務指標；對於 Lambda，則監控帶有別名/版本維度的函數 Errors/Throttles。
• 使用生命週期 hooks（例如 AfterAllowTestTraffic）透過 Lambda 或 SSM 執行驗證；非零的退出碼會觸發回滾。

EC2、ECS 和 Lambda 的藍/綠部署與流量轉移

EC2/Auto Scaling：

• 使用 CodeDeploy 進行藍/綠部署時，會為綠色環境佈建一個新的 Auto Scaling group，將其與一個獨立的目標群組關聯，然後切換 ALB 接聽器。您可以選擇自動終止藍色環境，或保留它以便快速回滾。
• 對於 EC2 上的就地部署，可與 ELB 結合使用，以優雅地取消註冊/註冊執行個體並保護可用性。部署組態決定了批次大小和步調。

ECS：

• CodeDeploy 透過一個 ALB 後方的兩個目標群組與 ECS 服務整合。系統會使用新的任務定義建立一個替代的任務集（綠色）。
• 測試流量透過一個專用的測試接聽器流向綠色目標群組；在正式升級前，生產流量會一直留在藍色環境。
• 在監控 CloudWatch 警報的同時，透過金絲雀或線性轉移將流量逐步移至綠色環境。在切換到生產環境前，使用 AfterAllowTestTraffic 來執行驗證（例如，一個呼叫綜合檢查的 Lambda 函數）。

Lambda：

• CodeDeploy 透過加權路由將函數別名更新至一個新版本。金絲雀和線性模式會逐步轉移流量百分比。別名上的 CloudWatch 警報會驅動自動回滾。
• 使用 AWS SAM 或 CDK 時，可在範本中設定 AutoPublishAlias 和 DeploymentPreference，為每個函數編碼金絲雀/線性策略和警報。

CodeDeploy 之外的加權路由：

• 對於多區域或多堆疊的平衡，帶有健康檢查的 Route 53 加權記錄可提供區域性的流量分割（例如，將 1% 流量分到次要區域）和容錯移轉。這補充而非取代 CodeDeploy 的每個服務的流量轉移功能。

跨帳號與跨區域交付

企業級管線通常位於一個集中的「工具」帳號中，並部署到跨多個區域的開發/測試/生產帳號：

• 跨帳號：
  • 在 CodePipeline 動作中，指定目標帳號裡的一個 RoleArn，該角色需信任管線角色的委託人。為每個動作（CloudFormation、CodeDeploy、ECS、Lambda）使用最小權限。
  • 對於需要存取目標帳號資源的 CodeBuild，讓建置任務擔任一個角色 (STS) 或使用每個帳號專屬的動作角色，而非寬鬆的 AdministratorAccess。
  • 對於部署到 EC2 的 CodeDeploy，目標帳號負責管理應用程式/部署群組與服務角色；管線則擔任一個角色來呼叫 CreateDeployment。
• 跨區域：
  • 在管線設定中為每個區域新增一個成品儲存庫（一個 S3 儲存貯體搭配區域性的 KMS 金鑰）。更新儲存貯體政策，以允許管線角色和每個動作的角色進行讀寫。
  • 必要時建置區域特定的成品（例如，使用 aws cloudformation package 指令將 Lambda 程式碼封裝並指定到一個區域本地的 S3 儲存貯體）。
  • 在遠端區域中的 CloudFormation 部署動作必須參考該區域的成品儲存庫，並可在目標帳號中指定一個堆疊執行角色以實現最小權限。

安全性、成品與治理：

• 保持成品儲存貯體為私有；避免使用如 authenticated-read 等公開 ACL。應依賴限定於管線和動作角色的儲存貯體政策，並搭配 KMS 加密。
• 標準化 buildspecs 以可預測的方式推送成品（例如，用於 EC2/CodeDeploy 的應用程式套件、用於 ECS 的 taskdef.json 和 appspec、用於 Lambda 的已封裝範本）。
• 透過為 EC2 預先烘焙 AMI 來推動不可變性，以確保 CodeDeploy 代理程式和基礎執行環境的一致性；這能減少漂移並縮短部署時間。
• 使用 EventBridge 規則將管線事件鏡像到通知、ChatOps 或票務系統，並用於編排手動審批關卡。

實務問題情境

Spotify 需要為數百個微服務實現更安全的發布，這些服務運行在一個混合的運算基底上（ECS on Fargate、基於 EC2 的服務和 Lambda）。他們要求在導入生產流量前，能進行金絲雀部署和藍/綠部署並搭配自動化測試，同時需要成品治理和跨區域晉升，並將生產環境保留在一個獨立的帳號中。

1. 建立儲存庫與套件

• 使用 CodeCommit 存放私有儲存庫，並透過 EventBridge 驅動 PR/測試自動化。CodeArtifact 則託管 npm、Maven 和 PyPI 的相依套件，並設定上游來源和 KMS 加密，以標準化供應鏈控管。 理由：集中式的 IAM/KMS 整合，關鍵儲存庫無需外部 webhook；CodeArtifact 提供快取且受管理的套件。

2. 建置與測試

• 為每個服務建立 CodeBuild 專案，並整合 VPC、本地快取（Docker 層與原始碼），以及從 Secrets Manager/Parameter Store 取得的環境變數。建置映像檔並推送到 ECR；產生次要成品（taskdef.json/appspec.yaml 或已封裝的 CloudFormation 範本）。 理由：短暫、隔離的建置，強大的機密處理能力，透過快取加速週期，且多重輸出可同時支援容器和無伺服器封裝。

3. 編排管線

• 在一個工具帳號中建立一個集中的 CodePipeline，包含以下階段：Source、Build、Unit Tests、Deploy-to-Staging、Automated Tests、Manual Approval、Deploy-to-Prod。觸發器來自 EventBridge 對 CodeCommit 更新的監聽；一個夜間排程的 EventBridge 規則則會啟動整合測試。 理由：制式化、可稽核的流程，設有審批關卡，並支援事件驅動與排程驅動兩種執行方式。

4. 藍/綠部署與金絲雀部署

• ECS 服務使用 CodeDeploy 的藍/綠部署，搭配兩個目標群組和金絲雀流量轉移；驗證步驟在 AfterAllowTestTraffic 階段透過一個執行合約測試和綜合性檢查的 Lambda 來運行。EC2 服務在容量允許時，使用 CodeDeploy 的就地部署（OneAtATime）或藍/綠 ASG 交換。Lambda 函數則使用 CodeDeploy 搭配 Canary10Percent15Minutes 策略進行部署，並在 API Gateway 的 Errors 和 5xx 指標上設定 CloudWatch 警報。 理由：為每種執行環境提供頂級的流量控制，並在警報觸發時自動回復，將對客戶的影響降到最低。

5. 跨帳號與跨區域晉升

• 管線在開發/測試/生產帳號中擔任各環境專屬的角色。對於 us-east-1 和 eu-west-1，設定區域性的成品儲存庫和區域性的 KMS 金鑰；CodeBuild 產生區域特定的已封裝範本，並將成品上傳到區域本地的儲存貯體。每個帳號/區域中的 CloudFormation 動作使用堆疊執行角色；CodeDeploy 動作則指定環境特定的應用程式/部署群組。 理由：對生產環境的強隔離，透過擔任角色實現最小權限，以及合規的加密，同時營運開銷低。

6. 成品治理與安全性

• 強制 S3 成品儲存貯體為私有，並採用限制性政策，移除任何公開 ACL。簽署容器映像檔和範本；將 SBOMs 作為建置成品儲存。使用 IAM 條件金鑰，將生產環境的動作限制在僅能由工具帳號中的管線執行。 理由：防止資料外洩，改善來源追溯性，並符合供應鏈最佳實務。

7. 可觀測性與通知

• 為所有部署群組附加 CloudWatch 警報；EventBridge 規則將 CodePipeline 的執行與核准事件轉發到一個 SNS 主題，以及一個會發布訊息到 Slack 的 Lambda。 理由：更快的反饋、自動化回復，以及在需要時進行人為介入的核准。

此設計將異質的執行環境統一在單一受控的工具鏈下，提供具備自動化驗證的安全推出策略，透過移除自行託管的 CI/CD 基礎設施來減少維護工作，並以清晰的職責分離實現全球擴展。

所有領域 · 基礎設施即程式碼與組態管理 →

練習這些題目 → · 在 ExamRoll.io 上限時練習 →

瀏覽 Amazon →