運用藍綠部署與Terraform實現零停機部署策略

– 10 分鐘閱讀

在現代軟體交付生命週期中，頻繁且可靠的部署是維持競爭力的核心。傳統的部署模式常伴隨著服務中斷，對用戶體驗與業務連續性構成挑戰。為此，DevOps 領域發展出多種先進部署策略，旨在實現零停機或近乎零停機的目標。本文將從基礎設施即代碼（IaC）工具 Terraform 的資源生命週期管理談起，解析其 create_before_destroy 機制如何作為降低停機風險的第一步。進而，系統性地介紹藍綠部署此一核心部署模式，探討其如何透過維護兩套平行生產環境，達成無縫流量切換與快速回滾。同時，我們也將分析其衍生策略，如金絲雀發布，如何透過逐步導入流量來控制風險，以及如何在 Azure 這樣的公有雲平台上，利用其原生服務實現這些高可用性部署架構。

部署過程中的停機時間縮減策略

本章將深入探討如何在 DevOps 實踐中，進一步提升應用程式交付的頻率與可靠性，特別關注於減少生產環境部署時的應用程式停機時間。我們將從 Terraform 部署中的常見問題出發，介紹藍綠部署 (Blue-Green Deployment) 的概念與模式，並探討如何在 Azure 環境中實踐，同時也將介紹功能標籤 (Feature Flags) 的應用，以實現無需重新部署即可修改應用程式行為的能力。

Terraform 部署中的停機時間問題

在應用程式交付的生命週期中，部署新版本到生產環境是一個關鍵環節。儘管 DevOps 實踐，如基礎設施即代碼 (IaC) 和持續整合/持續部署 (CI/CD)，能顯著提升應用程式品質和交付頻率，但部署過程本身仍可能導致應用程式暫時不可用。

Terraform 的資源替換行為: 當使用 Terraform 管理基礎設施時，某些資源的變更可能會觸發 Terraform 的「銷毀與重建」(destroy and recreate) 行為。例如，如果修改了一個資源的名稱或某些關鍵屬性，Terraform 可能會認為該資源已無法原地修改，而需要先銷毀現有資源，然後再創建一個具有新屬性的新資源。

實際案例: 假設我們使用 Terraform 在 Azure 上部署了一個 Web App。如果我們需要更改該 Web App 的名稱，Terraform 的執行計劃可能會顯示：

  1. 銷毀現有的 Web App 資源。
  2. 創建一個具有新名稱的新 Web App 資源。

在 Terraform 自動執行銷毀和重建的過程中，Web App 將處於不可訪問狀態，這對用戶體驗和業務連續性會產生負面影響。儘管這種自動化過程效率很高，但它直接導致了應用程式的停機時間。

解決 Terraform 部署停機問題：create_before_destroy 選項

為了緩解 Terraform 在資源替換過程中造成的應用程式停機時間，Terraform 提供了一個名為 create_before_destroy 的選項。此選項允許我們控制 Terraform 在銷毀和重建資源時的順序。

應用 create_before_destroy:

將 create_before_destroy 選項添加到資源塊中，可以指示 Terraform 在銷毀舊資源之前，先創建新資源。

resource "azurerm_app_service" "webapp" {
  name = "MyWebAppBook1" # 新名稱

  # ... 其他 azurerm_app_service 的配置 ...

  lifecycle {
    create_before_destroy = true
  }
}
  • lifecycle 塊: 這是 Terraform 中用於控制資源行為的塊。
  • create_before_destroy = true: 當設置為 true 時，Terraform 會在執行此資源的銷毀操作之前，先執行其創建操作。

create_before_destroy 的工作流程: 當 Terraform 檢測到需要替換資源時（例如，由於名稱更改），啟用 create_before_destroy = true 後，其執行順序將變為：

  1. 創建新資源: Terraform 首先會創建一個具有新屬性（例如新名稱）的新資源。
  2. 更新依賴關係: 如果有其他資源依賴於舊資源，Terraform 會嘗試更新這些依賴關係，使其指向新創建的資源。
  3. 銷毀舊資源: 一旦新資源成功創建並準備就緒，Terraform 便會銷毀舊資源。

優勢: 通過這種方式，應用程式可以在舊資源仍然運行時，在新資源上進行部署和測試。一旦新資源準備就緒，流量就可以無縫地切換到新資源，從而最大限度地減少或完全消除應用程式的停機時間。

部署停機時間縮減策略：create_before_destroy 與藍綠部署

本節將深入探討兩種關鍵的部署策略，旨在大幅減少應用程式在生產環境中的停機時間。首先，我們將延續 Terraform 的 create_before_destroy 選項，探討其在實際應用中的工作流程和注意事項。接著，我們將介紹藍綠部署 (Blue-Green Deployment) 的核心概念、架構模式，以及兩種常見的藍綠部署變體：金絲雀發布 (Canary Release) 和暗啟動 (Dark Launch)。

create_before_destroy 選項的進階應用與限制

在 Terraform 中，create_before_destroy 選項為管理資源替換時的停機時間提供了有效的解決方案。當 Terraform 需要銷毀一個資源並創建一個具有變更的新資源時，此選項確保新資源在舊資源被銷毀前創建完成。

azurerm_app_service 範例中的工作流程: 在 Azure 中，當我們使用 azurerm_app_service 資源並啟用 create_before_destroy = true 時，Terraform 的操作流程如下：

  1. 創建新 Web App: Terraform 首先創建一個新的 Azure Web App 實例，其名稱由 name = "MyWebAppBook1" 指定。
  2. 配置新 Web App: 在創建過程中，新 Web App 的配置會被應用。這裡特別使用了 app_settings 中的 WEBSITE_RUN_FROM_PACKAGE 屬性，該屬性指向一個 ZIP 格式的應用程式包的 URL。這意味著新 Web App 可以立即從指定的 URL 加載並運行應用程式，而無需額外的部署步驟。
  3. 銷毀舊 Web App: 一旦新 Web App 成功創建並運行，Terraform 便會銷毀舊的 Web App 實例。

create_before_destroy 的關鍵考量: 雖然 create_before_destroy 極大地減少了停機時間，但其有效性取決於新資源的準備速度。如果新資源的創建和配置過程較長，或者應用程式的啟動時間較慢，那麼在舊資源被銷毀後，新資源可能還未完全準備好，這仍然可能導致短暫的服務中斷。

  • 適用場景: 此選項特別適用於能夠快速啟動的資源，例如：
    • Azure Web App，當使用 WEBSITE_RUN_FROM_PACKAGE 時，可以快速載入應用程式。
    • 使用預先構建的 VM 映像（如通過 Packer 創建的映像），這些映像已包含所有必要的應用程式和配置，可以快速啟動。
  • 不適用場景: 對於需要長時間初始化或部署過程複雜的資源，此選項可能無法完全消除停機時間。

藍綠部署 (Blue-Green Deployment) 概念與模式

藍綠部署是一種先進的部署策略，旨在實現應用程式的零停機時間發布，並提供快速回滾的能力。

核心概念: 藍綠部署的核心思想是維護兩個完全相同的生產環境：

  • 藍色環境 (Blue Environment): 運行當前穩定版本的應用程式。
  • 綠色環境 (Green Environment): 部署新版本應用程式的環境。

一個路由器（通常是負載均衡器或 DNS 服務）負責將用戶流量導向其中一個環境。

架構示意圖: 此架構通常包含：

  • 兩個獨立且相同的應用程式運行環境（藍色和綠色）。
  • 一個路由器，負責將用戶請求導向當前活躍的環境。

基本使用模式:

  1. 初始部署: 應用程式的第一個穩定版本（N）部署到藍色環境，路由器將所有流量導向藍色環境。
  2. 新版本部署: 當準備部署新版本（N+1）時，將其部署到綠色環境。
  3. 流量切換: 一旦綠色環境中的新版本經過測試並確認穩定，路由器會將所有流量從藍色環境切換到綠色環境。
  4. 閒置與回滾: 此時，藍色環境變為閒置狀態，可以保留用於測試下一個版本（N+2）或作為快速回滾的目標。如果新版本出現問題，可以迅速將流量切換回藍色環境。

這種模式確保了在部署過程中，生產環境始終有一個可用的版本，從而消除了用戶可見的停機時間。

藍綠部署的變體模式

藍綠部署的概念可以衍生出幾種更細緻的部署模式，以適應不同的風險承受能力和測試需求。

金絲雀發布 (Canary Release) 模式

金絲雀發布是一種風險較低的部署策略，它將新版本逐步引入生產環境。

  • 概念: 新版本應用程式部署到綠色環境，但最初只對一小部分用戶開放。這就像礦工在進入危險礦井前，先放出金絲雀來測試空氣是否有毒。
  • 實現方式: 路由器被配置為將一小部分用戶流量（例如 10%）導向綠色環境，而其餘大部分流量（90%）仍導向藍色環境。
  • 監控與驗證: 在小範圍用戶測試期間，密切監控新版本的性能、錯誤率和用戶反饋。
  • 逐步擴大: 如果測試順利，逐步增加導向綠色環境的流量比例，直到所有用戶都轉移到新版本。
  • 優勢: 能夠在影響範圍最小的情況下發現和解決潛在問題，降低了全面部署失敗的風險。

架構示意圖: 此模式下，路由器會將大部分流量導向藍色環境（版本 N），而一小部分流量導向綠色環境（版本 N+1）。一旦測試成功，路由器會將所有流量切換到綠色環境。

暗啟動 (Dark Launch) 模式

暗啟動模式允許在不影響用戶體驗的情況下，將新功能部署到生產環境。

  • 概念: 新功能被部署到生產環境，但其代碼被隱藏或禁用，對用戶不可見。
  • 實現方式: 應用程式的後端代碼部署了新功能，但前端或相關邏輯被暫時禁用。
  • 按需啟用: 當需要測試或啟用這些新功能時，可以通過配置更改（例如功能標籤）來激活它們，而無需重新部署整個應用程式。
  • 優勢: 可以在生產環境中進行真實數據的測試，而不會影響現有用戶。這對於驗證複雜功能或評估新功能對系統性能的影響非常有用。

這兩種模式都建立在藍綠部署的基礎上，提供了更精細的控制和更低的風險，使得團隊能夠更自信地向生產環境交付變更。

Azure 上的藍綠部署實踐：App Service Slots 與 Traffic Manager

本節將聚焦於如何在 Azure 雲端環境中實踐藍綠部署策略，以達到最小化部署停機時間的目標。我們將探討兩種主要的 Azure 服務：App Service Slots 和 Azure Traffic Manager，並說明它們如何協同工作以實現藍綠部署和金絲雀發布模式。

利用 Azure App Service Slots 實現藍綠部署

Azure App Service 提供了一項強大的功能——部署槽 (Deployment Slots)，這使得實現藍綠部署變得相對簡單且成本效益高。

核心概念: App Service Slots 允許您為一個主 Web App 或 Function App 創建多個獨立的運行環境（最多可達 20 個，取決於 App Service Plan 的等級）。這些槽與主應用程式共享相同的基礎設施配置，但可以獨立部署和運行不同版本的應用程式。

  • 主 Web App (藍色環境): 代表生產環境，運行當前穩定版本的應用程式。
  • 部署槽 (綠色環境): 作為一個獨立的運行實例，用於部署新版本的應用程式。

實踐步驟:

  1. 創建部署槽: 在 Azure 入口網站中，為您的 Web App 創建一個新的部署槽。
  2. 部署新版本: 將新版本的應用程式部署到這個新創建的槽中。
  3. 流量分配 (金絲雀發布):
    • Azure App Service 允許您配置流量百分比，將一部分用戶流量導向部署槽。例如，您可以將 10% 的流量分配給槽，讓一小部分用戶測試新版本。
    • 這相當於金絲雀發布模式，可以在真實生產環境中收集用戶反饋和監控新版本的表現。
  4. 流量切換 (Swap):
    • 一旦新版本在槽中經過充分測試並確認穩定，就可以執行「交換」(Swap) 操作。
    • 此操作會將槽的內容（新版本）與主 Web App 的內容（舊版本）進行交換。
    • 交換完成後，主 Web App 將運行新版本，而原來的槽則運行舊版本，準備好作為回滾目標或用於下一次部署。

優勢:

  • 零停機時間: 交換操作在後台進行，對用戶幾乎沒有感知。
  • 快速回滾: 如果新版本出現問題，可以立即將槽與主 Web App 再次交換，快速恢復到舊版本。
  • 成本效益: 相較於維護兩個完全獨立的生產環境，使用部署槽更具成本效益。

利用 Azure Traffic Manager 實現藍綠部署

Azure Traffic Manager 是一個基於 DNS 的流量負載均衡器，可以將用戶流量導向不同的服務端點（如 Web Apps）。它為實現藍綠部署提供了另一種強大的方法，尤其適用於需要更靈活的流量控制場景。

核心概念: Azure Traffic Manager 允許您定義流量路由規則，將請求分發到一個或多個後端服務。

  • 兩個獨立的 Web App: 您需要部署兩個獨立的 Web App 實例，分別代表藍色環境（生產環境）和綠色環境（新版本測試環境）。
  • Traffic Manager 設定檔 (Profile): 在 Traffic Manager 中創建一個設定檔，定義流量路由策略。

實踐步驟:

  1. 創建兩個 Web App: 分別部署應用程式的當前版本（藍色）和新版本（綠色）到兩個獨立的 Azure Web App 實例。
  2. 配置 Traffic Manager 設定檔:
    • 路由方法: 選擇一種路由方法，例如「加權」(Weighted) 路由。
    • 加權設定: 為每個 Web App 端點分配一個權重。
      • 例如，將藍色環境（主 Web App）的權重設置為 100%，綠色環境（新版本 Web App）的權重設置為 0%，則所有流量都會導向藍色環境。
      • 要進行金絲雀發布，可以將藍色環境的權重設置為 90%，綠色環境設置為 10%。
  3. 定義端點: 將兩個 Web App 的 URL 添加為 Traffic Manager 的端點。
  4. 流量調整與切換:
    • 通過動態調整每個 Web App 端點的權重，可以控制流量分配。
    • 例如，要將流量切換到新版本，只需將綠色環境的權重增加到 100%，並將藍色環境的權重降至 0%。
    • 如果需要回滾，則反之亦然。

優勢:

  • 靈活的流量控制: 提供細粒度的流量控制，支持加權、優先級、地理位置等多種路由策略。
  • 獨立環境: 兩個 Web App 是完全獨立的，提供了更好的隔離性。
  • DNS 層級負載均衡: 在 DNS 層級進行流量管理，適用於跨區域或跨部署的場景。

權衡部署效率與系統穩定性後，我們可以清晰地看到，從 create_before_destroy 到藍綠部署的演進，不僅是技術手法的升級，更是組織在風險管理與服務韌性上成熟度的體現。這些策略的選擇，深刻反映了一家企業對使用者體驗承諾的深度，以及其駕馭變革的內在能力。

create_before_destroy 提供了一種優雅的技術性解方，處理了基礎設施層面的替換難題，但其效益仍受限於單一資源的啟動週期。相較之下，藍綠部署及其金絲雀、暗啟動等變體，則代表了一種更宏觀的架構性思維轉變。真正的挑戰已非技術實現本身——雲端平台已大幅降低其門檻——而是組織是否具備支撐這些策略的監控能力、數據分析文化，以及在不確定性中快速決策的敏捷性。

未來3至5年，部署策略的焦點將從被動的「零停機」追求，轉向主動的「價值驗證」。頂尖團隊將不再僅僅視金絲雀發布為風險緩衝，而是將其作為即時市場反饋迴路與商業實驗的核心引擎。

玄貓認為，高階管理者應將部署策略的成熟度，視為衡量團隊技術韌性與市場適應力的關鍵指標，並將其作為驅動組織持續學習與進化的核心槓桿。

玄貓 BlackCat

玄貓 BlackCat

技術愛好者，專注於分享程式開發、雲端技術與 AI 應用的心得體會。