AWS 雲端 DevOps 核心服務 CodeBuild 與 CodePipeline

AWS 提供的 CodeCommit、CodeBuild 和 CodePipeline 是建構雲端 DevOps 流程的重要服務。CodeCommit 作為版本控制系統，安全地儲存程式碼，並與 Git 工具整合。雖然 AWS 已宣佈 CodeCommit 不再接受新客戶，但現有使用者仍可繼續使用。CodeBuild 則專注於程式碼建置和測試，自動擴充套件以適應不同規模的專案，支援多種程式語言和建構環境。CodePipeline 則串聯整個 CI/CD 流程，自動化軟體釋出流程，並與其他 AWS 和第三方服務整合。CloudWatch 則提供監控和警示功能，確保無伺服器應用程式的穩定性和效能。這些服務共同組成了 AWS 雲端 DevOps 的核心，協助開發團隊提升效率並交付高品質軟體。

AWS CodeCommit 與 AWS CodeBuild：雲端 DevOps 的核心服務

AWS CodeCommit：安全託管的 Git 儲存函式庫服務

AWS CodeCommit 是由 AWS 提供的全託管原始碼控制服務，主要用於安全地託管私有 Git 儲存函式庫。此服務消除了開發者自行管理原始碼控制系統或擔憂基礎設施擴充套件的需求。CodeCommit 與現有的 Git 工具無縫整合，使其成為 AWS 生態系統中 DevOps 實踐的強大助力。

作為 AWS 開發者工具套件的一部分，CodeCommit 提供高用性、耐用性和可擴充套件性。它支援標準 Git 功能，允許團隊儲存從程式碼到二進位制檔案的各種內容。憑藉靜態和傳輸中加密、提取請求以及與其他 AWS 服務的整合等功能，CodeCommit 為協作開發提供了強大的平台。其按需付費模式和自動擴充套件使其成為各規模組織最佳化開發工作流程的理想選擇。

AWS 於 2024 年 7 月 25 日宣佈，CodeCommit 將不再接受新客戶。現有的 CodeCommit 使用者可以繼續使用該服務，但 AWS 不計劃引入新的功能，僅提供安全性和可用性更新。對於希望從 CodeCommit 遷移的使用者，AWS 建議使用其他 Git 提供商，如 GitHub 或 GitLab。

CodeCommit 的關鍵特性

• 高用性和可擴充套件性
• 支援標準 Git 功能
• 與其他 AWS 服務整合
• 靜態和傳輸中加密
• 按需付費模式

AWS CodeBuild：全託管的持續整合服務

AWS CodeBuild 是由 AWS 提供的一項全託管的持續整合服務，旨在簡化原始碼編譯、測試執行和生成可佈署軟體套件的過程。作為現代 DevOps 實踐的重要組成部分，CodeBuild 消除了開發者管理自有建置伺服器的需求，使他們能夠專注於編寫程式碼和交付功能。

此強大的服務可自動擴充套件以滿足任何專案規模的需求，同時處理多個建置任務以避免開發流程中的瓶頸。它支援廣泛的程式語言和建置環境，使其成為各規模團隊的多功能工具。透過自動化建置和測試流程（如圖 5-1 所示），CodeBuild 有助於確保軟體釋出的一致性和可靠性，同時降低傳統建置系統的操作負擔。

CodeBuild 的優勢

1. 全託管服務：作為無伺服器服務，它消除了建置伺服器的組態和管理需求，從而降低了營運成本。
2. 可擴充套件性：該服務可自動擴充套件以處理多個平行建置任務，確保開發流程在專案成長過程中保持高效。
3. 成本效益：採用按使用量付費的模式，您只需為建置過程中使用的計算資源付費，從而為各規模團隊最佳化成本。
4. 靈活性：它支援廣泛的程式語言、建置工具和環境，以滿足不同的專案需求和技術堆疊。

CodeBuild 的關鍵組成部分

1. 建置專案：定義每個專案的建置環境、原始碼位置和建置命令。
2. 建置環境：預先組態或自定義的 Docker 映像，提供建置和測試程式碼所需的工具和執行環境。
3. Buildspec：一個 YAML 檔案，指定建置過程中要執行的命令序列。
4. 構件：建置過程生成的輸出，可以儲存在指定的位置或用於 CI/CD 管道的後續階段。

對比分析：CodeBuild、Jenkins 和 GitHub Actions

在選擇合適的 CI/CD 工具時，團隊需要考慮多個因素，包括整合能力、可擴充套件性和維護成本。以下是對 CodeBuild、Jenkins 和 GitHub Actions 的比較：

• AWS CodeBuild：理想於以 AWS 為中心的環境，因其無縫整合和可擴充套件性。然而，它可能缺乏 Jenkins 和 GitHub Actions 的靈活性。
• Jenkins：高度靈活，支援廣泛的外掛程式，使其適合複雜的 CI/CD 管道。然而，它需要大量的維護工作。
• GitHub Actions：使用者友好，與 GitHub 無縫整合，使其成為使用 GitHub 進行版本控制的團隊的理想選擇。它比 CodeBuild 和 Jenkins 更容易設定，但可能無法提供與 Jenkins 相同的自定義級別。

使用案例

AWS CodeBuild 在軟體開發生命週期中的各種場景中表現出色。它特別適合自動化持續整合和交付（CI/CD）管道，使團隊能夠建立完全自動化的釋出流程，將程式碼變更推廣到多個佈署環境。它可以取代管理傳統建置伺服器的複雜性，使組織能夠執行現有的作業，而無需組態和維護建置節點。此外，它可以與原始碼儲存函式庫整合，自動啟動從原始碼構建並回傳結果，使其成為開源專案和協作開發工作的理想選擇。

程式碼範例與解析

以下是一個簡單的 Buildspec YAML 檔案範例，用於定義 CodeBuild 的建置流程：

version: 0.2.0

phases:
  install:
    commands:
      - echo "Installing dependencies..."
      - npm install
  build:
    commands:
      - echo "Building the project..."
      - npm run build
  post_build:
    commands:
      - echo "Post-build actions..."
artifacts:
  files:
    - '**/*'

內容解密：

• version：指定 Buildspec 的版本。
• phases：定義建置流程的不同階段，包括 install、build 和 post_build。
• commands：在每個階段中執行的命令列表。
• artifacts：指定要作為構件輸出的檔案。

AWS 雲端 DevOps 實戰：CodeBuild 與 CodePipeline 深度解析

在現代軟體開發流程中，持續整合（CI）與持續交付（CD）已成為提升開發效率與軟體品質的關鍵實踐。AWS 提供了多項強大的服務來支援 DevOps 文化與實踐，其中 AWS CodeBuild 與 AWS CodePipeline 是兩項核心工具，分別負責自動化建構與佈署流程。本文將探討這兩項服務的特點、優勢、限制，並提供實際操作。

AWS CodeBuild：全託管建構服務

AWS CodeBuild 是一款全託管的建構服務，能夠編譯原始碼、執行測試並產生可佈署的軟體套件。其主要優勢在於：

1. 無伺服器架構：無需管理或維護建構伺服器，自動擴充套件以處理多個建構任務。
2. 與 AWS 服務緊密整合：原生支援 AWS CodeCommit、AWS CodePipeline 等服務，簡化 CI/CD 流程。
3. 支援多種程式語言與建構工具：提供多種預設環境，同時支援自訂 Docker 映像檔。

使用 CodeBuild 的實務挑戰

儘管 CodeBuild 帶來了諸多便利，但在實際應用中仍需注意以下挑戰：

1. 本地與雲端環境的差異：雖然 CodeBuild 提供本地建構模擬功能，但仍可能與實際雲端環境存在差異，導致建構結果不一致。
2. 廠商鎖定風險：過度依賴 AWS 生態系可能使得未來轉移至其他 CI/CD 解決方案變得困難。

CodeBuild 實作步驟

1. 登入 AWS 管理主控台，搜尋並進入 CodeBuild 控制檯。
2. 建立新的建構專案，設定來源儲存函式庫（如 CodeCommit 或 GitHub）。
3. 組態建構環境，包括運算型別、作業系統與執行階段環境。
4. 指定建構規格（buildspec.yml），定義建構流程。
5. 設定輸出成品與日誌儲存於 S3。

AWS CodePipeline：持續交付服務

AWS CodePipeline 是一款全託管的持續交付服務，能夠自動化軟體釋出流程，將程式碼變更從原始碼到生產環境的整個過程自動化。其主要特點包括：

1. 視覺化流程設計：提供圖形介面與 CLI 工具來定義和管理釋出流程。
2. 多階段支援：支援建構、測試、佈署等多個階段，並可平行執行以提升效率。
3. 廣泛的整合能力：除了與 AWS 服務緊密整合外，也支援 GitHub、Jenkins 等第三方工具。

CodePipeline 的關鍵組成要素

1. Pipeline（Pipeline）：定義整個釋出流程的工作流程。
2. Stage（階段）：將Pipeline劃分為多個邏輯階段，如建構、測試、佈署等。
3. Action（動作）：在每個階段中執行的具體任務，如編譯程式碼或佈署至生產環境。
4. Artifact（成品）：在不同階段間傳遞的檔案或檔案集。

CodePipeline 的優勢與挑戰

優勢：

• 加速軟體交付，實作快速迭代。
• 確保程式碼變更經過一致的品品檢查。
• 提供詳細的執行歷史與監控能力。

挑戰：

• 高度整合於 AWS 生態系，對非 AWS 環境的支援較為複雜。
• 需要一定的學習曲線來掌握其設定與組態。

CodePipeline 實作步驟

1. 在 AWS 管理主控台 中進入 CodePipeline 控制檯。
2. 建立新的Pipeline，選擇自訂或使用現有範本。
3. 設定來源階段（如 CodeCommit 或 GitHub）。
4. 組態建構階段（如使用 CodeBuild）。
5. 定義佈署階段，將應用佈署至目標環境。

Amazon CloudWatch：監控與觀測性服務

在 DevOps 環境中，監控與觀測性是確保系統穩定性的關鍵。Amazon CloudWatch 提供即時的效能指標、日誌收集與事件監控，能夠幫助團隊快速識別與解決問題。其主要功能包括：

1. 指標收集與監控：收集 AWS 資源與應用程式的效能指標。
2. 日誌管理：集中儲存、監控與分析應用程式日誌。
3. 事件回應：根據 CloudWatch 警示，自動觸發修復動作。

AWS CloudWatch 監控在無伺服器架構中的重要性

在無伺服器架構中，AWS CloudWatch 監控扮演著至關重要的角色。它提供了一個集中式的平台來觀察多個 AWS 服務，消除了對單獨監控工具的需求。透過 CloudWatch，您可以設定警示、建立自定義儀錶板，並自動回應特定的事件或閾值突變。這種級別的監控對於維護無伺服器應用程式的可靠性、可擴充套件性和成本效益至關重要，使您能夠在問題影響使用者之前主動識別和解決。

AWS CloudWatch 監控的應用案例

CloudWatch 在無伺服器生態系統中的多個場景中表現出色。它特別適用於監控 Lambda 函式效能、跟蹤 API Gateway 請求和分析 DynamoDB 表吞吐量。CloudWatch 可以幫助您識別 Lambda 中的冷啟動、檢測異常 API 延遲，並最佳化資料函式庫讀/寫容量。它對於成本最佳化也非常有價值，允許您跟蹤資源使用情況並為意外的峰值設定警示。此外，CloudWatch 的日誌和指標相關功能使其成為故障排除複雜無伺服器架構的優秀工具，幫助您快速定位多個服務中的問題根源。

AWS CloudWatch 監控的關鍵組成部分

CloudWatch 由幾個基本元件組成：

1. 指標：代表您的資源和應用程式效能的數值資料點。
2. 日誌：來自您的 AWS 資源和應用程式的根據文字的事件和活動記錄。
3. 警示：當特定指標超過預定義閾值時觸發的通知。
4. 儀錶板：您的指標和日誌的可自定義視覺表示，用於一目瞭然的監控。
5. 事件：描述 AWS 資源變化的近實時系統事件流。

AWS CloudWatch 監控的功能特點

CloudWatch 提供了一系列強大的功能：

1. 自定義指標：允許您發布自己的指標，為您的無伺服器架構提供監控應用程式特定資料點的靈活性。
2. 日誌洞察：使您能夠對日誌資料執行互動式查詢，幫助您快速分析和排除無伺服器堆積疊中的問題。
3. 異常檢測：利用機器學習演算法自動識別指標中的異常模式，在問題升級之前提醒您。
4. 複合警示：讓您根據多個指標或條件建立警示，為監控複雜無伺服器系統提供更全面的方法。

程式碼範例：使用 CloudWatch 指標和警示

import boto3

# 初始化 CloudWatch 客戶端
cloudwatch = boto3.client('cloudwatch')

# 發布自定義指標
response = cloudwatch.put_metric_data(
    Namespace='ServerlessApp',
    MetricData=[
        {
            'MetricName': 'LambdaFunctionErrors',
            'Dimensions': [
                {
                    'Name': 'FunctionName',
                    'Value': 'MyLambdaFunction'
                },
            ],
            'Value': 1,
            'Unit': 'Count'
        },
    ]
)

內容解密：

1. 使用 boto3 函式庫初始化 CloudWatch 客戶端。
2. put_metric_data 方法用於發布自定義指標到 CloudWatch。
3. Namespace 指定了指標的名稱空間，這裡使用的是 ServerlessApp。
4. MetricName 定義了指標的名稱，這裡是 LambdaFunctionErrors，用於跟蹤 Lambda 函式錯誤。
5. Dimensions 用於為指標新增額外的維度資訊，這裡根據 FunctionName 跟蹤特定 Lambda 函式的錯誤。
6. Value 是指標的實際值，這裡設定為 1，表示發生了一個錯誤。
7. Unit 指定了指標值的單位，這裡是 Count，表示計數。

使用 Plantuml 圖表呈現 CloudWatch 工作流程

@startuml
skinparam backgroundColor #FEFEFE

title AWS 雲端 DevOps 核心服務 CodeBuild 與 CodePipeline

|開發者|
start
:提交程式碼;
:推送到 Git;

|CI 系統|
:觸發建置;
:執行單元測試;
:程式碼品質檢查;

if (測試通過?) then (是)
    :建置容器映像;
    :推送到 Registry;
else (否)
    :通知開發者;
    stop
endif

|CD 系統|
:部署到測試環境;
:執行整合測試;

if (驗證通過?) then (是)
    :部署到生產環境;
    :健康檢查;
    :完成部署;
else (否)
    :回滾變更;
endif

stop

@enduml

圖表翻譯： 此圖表展示了 CloudWatch 的工作流程。首先，系統檢查 CloudWatch 指標。如果發現異常，則觸發警示並通知管理員；如果一切正常，則繼續監控，不斷迴圈檢查指標狀態。

AWS CloudWatch 的優勢

CloudWatch 為無伺服器應用程式監控提供了許多好處。它提供了一個集中式的平台來觀察多個 AWS 服務，消除了對單獨監控工具的需求。該服務能夠自動回應特定的事件或指標閾值，可以顯著減少手動干預並提高整體系統可靠性。CloudWatch 與其他 AWS 服務（如用於自定義指標發布的 Lambda 或用於警示通知的 SNS）的整合，建立了一個強大的生態系統來管理無伺服器應用程式。此外，其按需付費的定價模型與無伺服器架構的成本效益特性相吻合。

AWS CloudWatch 的侷限性

雖然 CloudWatch 是一個強大的工具，但它也有一些侷限性。對於高容量日誌記錄或在長時間內以精細粒度儲存指標時，該服務可能會變得昂貴。有效地使用 CloudWatch 也存在學習曲線，特別是在設定複雜警示或自定義指標時。此外，雖然 CloudWatch 在 AWS 生態系統內提供了廣泛的監控功能，但對於混合架構中的外部或本地元件的監控可能不那麼有效，需要額外的組態。

AWS CloudWatch 的實際操作

1. 登入到 AWS 控制檯。
2. 在搜尋欄中輸入 “CloudWatch”，然後點選 “CloudWatch” 結果以存取 CloudWatch 控制檯。
3. 點選 “檢視日誌” 以存取日誌組螢幕，您可以在此檢視有關您的服務和活動的詳細資訊。
4. 您可以建立日誌組來組織日誌。
5. 您還可以將日誌匯出到 S3 儲存桶中。

CloudWatch 警示的應用案例

CloudWatch 警示是一種多功能工具，可廣泛應用於無伺服器架構中的各種場景。它們擅長於監控 Lambda 函式效能、追蹤 API Gateway 請求率，以及觀察 DynamoDB 表格吞吐量。警示可以設定為檢測無伺服器應用程式行為中的異常情況，例如意外的錯誤率激增或異常的流量模式。它們對於成本最佳化特別有用，可以在資源使用量接近預定義限制時提醒團隊。此外，CloudWatch 警示可以觸發自動回應，例如擴充套件資源或呼叫修復 Lambda 函式，使其成為維護無伺服器環境中高用性和回應能力的不可或缺的工具。

CloudWatch 警示的關鍵元件

CloudWatch 警示由幾個基本元件組成：

1. 指標：警示的基礎，代表從 AWS 資源收集的特定資料點隨時間的變化。
2. 閾值：預先定義的值，當超過此值時，會觸發警示狀態。
3. 評估週期：指標必須連續超過閾值的時間段數，以啟動警示。
4. 動作：當警示狀態變更時觸發的回應，例如傳送通知或執行 AWS 資源。

CloudWatch 警示的功能特點

CloudWatch 警示提供了多種強大的功能：

1. 指標數學警示：允許您根據涉及多個指標的數學表示式建立警示，從而實作更複雜的監控場景，並提供對無伺服器應用程式行為的更深入洞察。

   #### 內容解密：
   指標數學警示允許結合多個指標進行複雜運算，能夠更靈活地監控系統。例如，可以透過結合 CPU 使用率和記憶體使用量來評估系統負載。
   

2. 複合警示：透過使用邏輯運算子組合多個警示，您可以建立複雜的警示條件，同時考慮無伺服器基礎架構的多個方面，從而減少噪音並提供更有意義的警示。

   #### 內容解密：
   複合警示透過邏輯運算（如 AND、OR）組合多個簡單警示，能夠更精確地定義警示條件，避免不必要的幹擾。
   

3. 異常檢測：此功能使用機器學習演算法分析歷史資料，並自動檢測指標中的異常模式，幫助您在問題變成嚴重問題之前識別潛在問題。

   #### 內容解密：
   異常檢測利用機器學習技術，可以自動學習正常行為模式並識別偏差，有助於提前發現潛在問題。
   

4. 高解析度警示：能夠以 10 秒或 30 秒的間隔評估指標，提供近乎實時的監控能力，允許對無伺服器環境中的關鍵變化進行快速檢測和回應。

   #### 內容解密：
   高解析度警示使監控更加及時，對於需要快速反應的系統至關重要，能夠在第一時間發現並處理問題。
   

CloudWatch 警示的優勢

CloudWatch 警示為管理無伺服器應用程式提供了許多好處。它們提供實時監控和警示功能，能夠快速回應潛在問題。設定自定義閾值和動作的靈活性允許根據特定的應用程式需求量身定製監控解決方案。與其他 AWS 服務的整合促進了自動修復和擴充套件，提高了整體系統可靠性。CloudWatch 警示還透過識別趨勢和潛在問題來支援主動管理。它們能夠匯總跨多個資源的資料，提供無伺服器應用程式健康狀況的全面檢視，簡化了複雜的監控任務並提高了營運效率。

CloudWatch 警示的缺點

雖然 CloudWatch 警示是強大的工具，但它們也有一些限制。組態過程可能很複雜，尤其是在複雜的監控場景中，如果設定不正確，可能會導致錯過警示或誤報。使用像指標數學和異常檢測這樣的進階功能存在學習曲線。CloudWatch 警示也可能產生額外的成本，特別是對於高解析度監控或處理大規模應用程式生成的大量指標。預設的指標資料保留期限有限，這可能會限制長期趨勢分析。此外，雖然 CloudWatch 警示擅長於監控 AWS 資源，但如果沒有額外的工具或自定義指標，它們可能無法為複雜、分散式無伺服器應用程式的所有方面提供全面的洞察。

CloudWatch 警示實用

1. 從 AWS CloudWatch 控制檯點選「建立警示」，如圖 5-8 所示；它將重定向到如圖 5-11 所示的警示控制檯。

2. 點選「建立警示」以建立新的警示。

3. 要設定警示，您需要定義指標、條件、動作、名稱和描述。一旦您組態了這些設定，您就可以預覽並建立警示。新建立的警示將在 CloudWatch 警示控制檯頁面上可見。

4. 您可以透過點選設定圖示然後選擇選項來自定義警示檢視，如圖 5-12 所示。

AWS CloudWatch 儀錶板

Amazon CloudWatch 儀錶板是 AWS 生態系統中的強大工具，它為您的雲資源和應用程式提供了集中檢視。它允許您為 AWS 資源建立可定製的、視覺化的指標和警示顯示，從而實作實時監控和故障排除。透過 CloudWatch 儀錶板，您可以獲得對無伺服器應用程式和基礎架構的效能、健康狀況和營運狀態的寶貴洞察。

該儀錶板提供了一個使用者友好且可適應的介面，使您能夠將各種指標、日誌和警示整合到一個統一的檢視中。這種統一的視角協助 DevOps 團隊快速發現問題、監控趨勢，並做出資料驅動的決策，以增強其無伺服器應用程式並在 AWS 雲環境中保持無縫營運。