Docker Swarm 叢集藍綠佈署與自我修復系統實踐

– 11 分鐘閱讀

在現代軟體開發中，持續交付和高用性至關重要。本文將探討如何結合 Jenkins、Docker Swarm 和 Consul，實作應用程式的藍綠佈署和自我修復，確保服務不間斷執行並提升系統可靠性。首先，我們會修改 Jenkinsfile，利用 deploySwarm 函式將服務佈署至 Swarm 叢集。接著，我們將會驗證佈署結果，確認容器狀態和 Consul 中的服務資訊。最後，我們將探討如何構建自我修復系統，包含應用層級、系統層級和硬體層級的自我修復機制，並結合 Consul Watches 和 Jenkins 實作反應式自我修復，提升系統的容錯能力和穩定性。

叢集與擴充套件服務

在前面的章節中，我們探討瞭如何利用 Jenkins Workflow 和 Docker Swarm 來實作藍綠佈署。在本章節中，我們將探討如何將此流程擴充套件到整個 Swarm 叢集。

Jenkinsfile 的變更

為了實作藍綠佈署在 Swarm 叢集上的擴充套件，我們需要對 Jenkinsfile 進行一些修改。主要的變更包括使用 deploySwarm 函式來佈署服務到 Swarm 叢集。

deploySwarm 函式

def deploySwarm(serviceName, swarmIp, color, instances) {
    stage "Deploy"
    withEnv(["DOCKER_HOST=tcp://${swarmIp}:2375"]) {
        sh "docker-compose pull app-${color}"
        try {
            sh "docker network create ${serviceName}"
        } catch (e) {}
        sh "docker-compose -f docker-compose-swarm.yml -p ${serviceName} up -d db"
        sh "docker-compose -f docker-compose-swarm.yml -p ${serviceName} rm -f app-${color}"
        sh "docker-compose -f docker-compose-swarm.yml -p ${serviceName} scale app-${color}=${instances}"
    }
    putInstances(serviceName, swarmIp, instances)
}

內容解密：

  1. stage "Deploy"：定義了一個名為 “Deploy” 的階段，用於佈署服務。
  2. withEnv(["DOCKER_HOST=tcp://${swarmIp}:2375"])：設定環境變數 DOCKER_HOST，指向 Swarm 管理節點的 Docker 守護程式。
  3. sh "docker-compose pull app-${color}"：從登入檔中提取最新的容器映像。
  4. try { sh "docker network create ${serviceName}" } catch (e) {}：建立一個 Docker 網路，如果網路已存在，則捕捉異常並忽略。
  5. sh "docker-compose -f docker-compose-swarm.yml -p ${serviceName} up -d db"：使用 Docker Compose 佈署資料函式庫服務。
  6. sh "docker-compose -f docker-compose-swarm.yml -p ${serviceName} rm -f app-${color}"：移除任何現有的應用服務容器。
  7. sh "docker-compose -f docker-compose-swarm.yml -p ${serviceName} scale app-${color}=${instances}"：擴充套件應用服務到指定的例項數量。
  8. putInstances(serviceName, swarmIp, instances)：將例項數量儲存到 Consul 中。

驗證佈署結果

在 Jenkins 構建完成後，我們可以透過以下步驟驗證佈署結果：

  1. 檢查容器狀態：
export DOCKER_HOST=tcp://10.100.192.200:2375
docker ps --filter name=books --format "table {{.Names}}"

內容解密：

  1. export DOCKER_HOST=tcp://10.100.192.200:2375：設定環境變數 DOCKER_HOST，指向 Swarm 管理節點的 Docker 守護程式。

  2. docker ps --filter name=books --format "table {{.Names}}"：列出名稱包含 “books” 的容器。

  3. 檢查 Consul 中的服務資訊：

curl swarm-master:8500/v1/catalog/service/books-ms-blue | jq '.'
curl swarm-master:8500/v1/kv/books-ms/color?raw
curl swarm-master:8500/v1/kv/books-ms/instances?raw

內容解密：

  1. curl swarm-master:8500/v1/catalog/service/books-ms-blue | jq '.'：查詢 Consul 中名為 “books-ms-blue” 的服務資訊。
  2. curl swarm-master:8500/v1/kv/books-ms/color?raw：查詢 Consul 中儲存的目前佈署的顏色。
  3. curl swarm-master:8500/v1/kv/books-ms/instances?raw：查詢 Consul 中儲存的目前佈署的例項數量。

第二次執行 Swarm 佈署

在第一次佈署成功後，我們可以再次執行 Jenkins 構建來佈署新的版本（例如，從藍色切換到綠色）。

  1. 手動觸發 Jenkins 構建。
  2. 檢查容器狀態和 Consul 中的服務資訊，以驗證新的佈署是否成功。

透過以上步驟，我們成功地將藍綠佈署擴充套件到了整個 Swarm 叢集，並且驗證了佈署的正確性。

自我修復系統（Self-Healing Systems）

自我修復系統是一種能夠在沒有人為干預的情況下，自動檢測自身錯誤並進行修復的系統。這種系統能夠持續檢查和最佳化自身狀態，並根據變化中的條件進行自動調整，以達到容錯和回應式系統的能力。

自我修復的層級和型別

自我修復系統可以分為三個層級，分別是應用層級、系統層級和硬體層級。

應用層級的自我修復

應用層級的自我修復是指應用程式或服務能夠內部自我修復。傳統上，我們透過異常捕捉和日誌記錄來處理問題。當發生異常時，我們通常會忽略它並繼續執行，或者在某些情況下停止應用程式。

應用層級自我修復的實作

要實作應用層級的自我修復，可以使用Akka等框架。Akka的使用監督器和設計模式，可以建立內部自我修復的應用程式和服務。Akka不是唯一能夠實作此功能的框架，其他許多函式庫和框架也能夠建立容錯應用程式。

// 使用Akka實作自我修復的範例
import akka.actor.*;

public class MyActor extends AbstractActor {
    @Override
    public Receive createReceive() {
        return receiveBuilder()
            .match(String.class, s -> {
                // 處理訊息
            })
            .matchAny(o -> {
                // 處理其他訊息
            })
            .build();
    }
}

內容解密：

上述程式碼展示瞭如何使用Akka建立一個演員（Actor）。這個演員可以接收訊息並進行處理。如果在處理過程中發生異常，Akka的監督機制可以自動重啟演員，從而實作自我修復。

系統層級的自我修復

系統層級的自我修復是指整個系統能夠自我修復。這需要監控系統資源和狀態，並根據需要進行調整。

硬體層級的自我修復

硬體層級的自我修復是指硬體裝置能夠自我修復或被自動替換。這通常需要特殊的硬體設計和組態。

自我修復系統（Self-Healing Systems）深度解析

自我修復系統是現代雲端與分散式系統中的關鍵技術，能夠在發生故障時自動還原至正常運作狀態。本篇文章將探討自我修復系統的三個主要層面：應用層級、系統層級與硬體層級的自我修復機制，並分析其實作方式與挑戰。

應用層級的自我修復

應用層級的自我修復高度依賴於程式語言與設計模式，不同的程式語言與框架需要採用不同的自我修復策略。開發者需要設計內部機制，使應用程式能夠在內部錯誤或異常情況下自我修復。然而，這種方式可能導致服務之間的耦合度增加，尤其是在微服務架構中，服務可能以不同語言開發並採用不同框架。

程式碼範例：簡單的自我修復機制

import time
import random

def self_healing_service():
    try:
        # 模擬服務運作
        if random.random() < 0.1:  # 10% 機率模擬錯誤
            raise Exception("Service Error")
        print("Service is running")
    except Exception as e:
        print(f"Error occurred: {e}, restarting service...")
        # 重新啟動服務的邏輯
        self_healing_service()

while True:
    self_healing_service()
    time.sleep(1)

內容解密：

  1. 錯誤模擬：程式碼中使用 random.random() 來模擬服務執行過程中的錯誤，錯誤發生機率為10%。
  2. 例外處理：當錯誤發生時，捕捉例外並輸出錯誤訊息，接著呼叫自身函式以模擬重新啟動服務。
  3. 持續執行：使用 while True 迴圈確保服務持續執行，並每隔一秒檢查一次服務狀態。

系統層級的自我修復

系統層級的自我修復可以獨立於應用程式內部實作，提供更通用的解決方案。主要監控兩個導向：

  1. 處理程式失敗：當某個處理程式失敗時，需要重新佈署或重新啟動該服務。
  2. 回應時間監控：根據回應時間的變化進行動態擴充套件或縮減資源。

常見的監控方法：

  • Time-To-Live (TTL)：服務需定期向監控系統傳送訊號確認其運作狀態，若未在預定時間內更新狀態，則視為失敗。
  • Pinging：監控系統主動向服務傳送請求檢查其狀態，若無回應或回應異常，則執行修復措施。

系統層級自我修復流程

此圖示說明瞭系統層級自我修復的基本流程，透過持續監控服務狀態並在發現異常時執行修復措施，確保系統的高用性。

硬體層級的自我修復

硬體層級的自我修復並非真正意義上的自我修復，而是指當硬體發生故障時，將服務重新佈署至健康的節點上。常見的做法是定期檢查硬體元件的狀態，並根據檢查結果採取相應的措施。

主動式與被動式修復

  • 被動式修復（Reactive Healing）：在故障發生後進行修復，是目前大多陣列織採用的方式。
  • 主動式修復（Preventive Healing）：透過預防性檢查與維護，減少故障發生的機率。

自我修復系統的架構與預防性修復

自我修復系統（Self-Healing Systems）是一種能夠自動檢測、診斷和修復自身問題的系統。這種系統的設計理念是預測可能出現的問題，並採取相應的措施來避免這些問題的發生。

預防性修復

預防性修復的核心思想是預測未來可能出現的問題，並採取措施避免這些問題。為了實作這一點，我們需要使用相關資料來進行預測。相對簡單但可靠性較低的方法是根據近乎實時的資料。例如，如果某個 HTTP 請求的回應時間超過 500 毫秒，我們可能會想要擴充套件該服務。相反，如果回應時間小於 100 毫秒，我們可能會想要縮減該服務，以將資源分配給其他更需要的服務。

然而，僅僅依靠當前狀態來預測未來存在變數。如果某個請求的回應時間很長，可能是因為需要擴充套件服務，但也可能是暫時性的流量增加，下一次檢查可能會發現需要縮減服務。在微服務架構中，這可能是一個小問題，因為微服務易於擴充套件和縮減。但對於單體式應用程式來說，這種策略可能會帶來更多問題。

程式碼示例：根據回應時間動態調整服務規模

import time
import random

def get_response_time(service):
    # 模擬取得服務的回應時間
    return random.uniform(0.1, 1.0)

def adjust_service_scale(service, response_time):
    if response_time > 0.5:
        # 擴充套件服務
        print(f"擴充套件 {service} 服務")
    elif response_time < 0.1:
        # 縮減服務
        print(f"縮減 {service} 服務")

# 模擬檢查服務回應時間並調整服務規模
service_name = "example_service"
response_time = get_response_time(service_name)
adjust_service_scale(service_name, response_time)

內容解密：

  1. get_response_time 函式：模擬取得某個服務的回應時間，傳回一個隨機值，代表該服務的回應時間。
  2. adjust_service_scale 函式：根據回應時間來決定是否擴充套件或縮減服務。如果回應時間大於 0.5 秒，則擴充套件服務；如果小於 0.1 秒，則縮減服務。
  3. 邏輯說明：透過不斷檢查服務的回應時間，並根據預設的閾值來動態調整服務規模，可以有效提升系統的自我修復能力。

如果我們考慮歷史資料，預防性修復就會變得更加可靠，但同時也更加複雜。我們需要儲存相關資訊（如回應時間、CPU 使用率、記憶體使用率等），並使用複雜的演算法來評估趨勢和做出結論。例如，如果觀察到記憶體使用率在過去一小時內穩步上升，並達到了一個臨界點（如 90%），這將是一個明確的訊號，表明需要擴充套件相關服務。

自我修復系統架構

無論內部流程和工具如何，每個自我修復系統都會有一些共同的元素。首先，我們需要一個叢集，因為單個伺服器無法實作容錯。如果硬體發生故障，我們無法修復它。因此，系統必須從叢集開始。

自我修復系統架構

@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle

title Docker Swarm 叢集藍綠佈署與自我修復系統實踐

package "Docker 架構" {
    actor "開發者" as dev

    package "Docker Engine" {
        component [Docker Daemon] as daemon
        component [Docker CLI] as cli
        component [REST API] as api
    }

    package "容器運行時" {
        component [containerd] as containerd
        component [runc] as runc
    }

    package "儲存" {
        database [Images] as images
        database [Volumes] as volumes
        database [Networks] as networks
    }

    cloud "Registry" as registry
}

dev --> cli : 命令操作
cli --> api : API 呼叫
api --> daemon : 處理請求
daemon --> containerd : 容器管理
containerd --> runc : 執行容器
daemon --> images : 映像檔管理
daemon --> registry : 拉取/推送
daemon --> volumes : 資料持久化
daemon --> networks : 網路配置

@enduml

此圖示展示了自我修復系統的基本架構，從叢集的建立到服務的佈署，再到叢集協調器和服務登入檔的應用，最終實作對系統狀態的監控。

詳細說明：

  1. 叢集：自我修復系統的第一步是建立叢集，以實作容錯和容錯移轉。
  2. 佈署服務：在叢集中佈署服務，但需要叢集協調器來管理這些服務，以避免資源使用不均衡。
  3. 叢集協調器：使用 Docker Swarm、Kubernetes 或 Apache Mesos 等工具來協調叢集內的服務佈署和容錯移轉。
  4. 服務登入檔：使用 Consul、etcd 或 Zookeeper 等工具來儲存和管理系統中的服務資訊，這是監控系統狀態的前提。

自我修復系統（Self-Healing Systems）實作

自我修復系統是現代雲端基礎設施和微服務架構中的關鍵組成部分。這種系統能夠自動檢測、診斷和修復故障，從而提高系統的可用性和可靠性。本篇文章將探討如何使用 Docker、Consul Watches 和 Jenkins 來建立一個反應式自我修復系統。

服務登入檔的重要性

要建立自我修復系統，第一步是建立一個服務登入檔，用於儲存系統中所有服務的資訊。服務登入檔的作用是讓系統中的其他元件能夠發現和與彼此通訊。常見的服務登入檔工具包括 Consul、etcd 和 ZooKeeper 等。

圖 15-08：自我修復系統架構：服務登入檔若無監控機制更新資訊則形同虛設

如同圖 15-08 所示，服務登入檔需要一個監控機制來更新服務資訊。Registrator 是一個可以用於監控 Docker 容器並更新 Consul 服務登入檔的工具。

健康監控

有了服務登入檔之後，下一步是進行健康監控。健康監控工具需要知道系統的期望狀態和實際狀態。Consul Watches 可以用於監控 Consul 中的服務狀態變化，而 Kubernetes 和 Mesos 也提供了自己的健康監控工具。

圖 15-09：自我修復系統架構：健康監控工具利用服務登入檔驗證系統狀態

修復措施

當健康監控工具檢測到異常時，需要執行修復措施。最簡單的修復措施是向叢集協調器傳送訊號，以重新佈署失敗的服務。Jenkins 可以用於執行修復措施，包括重新佈署服務、傳送通知等。

圖 15-10：自我修復系統架構：修復措施至少應包括向叢集協調器傳送訊號以重新佈署失敗的服務

程式碼範例：使用 Jenkins 執行修復措施

pipeline {
    agent any
    stages {
        stage('Redeploy Service') {
            steps {
                sh 'docker service update --force myservice'
            }
        }
    }
}

內容解密：

上述 Jenkinsfile 程式碼定義了一個簡單的Pipeline，用於重新佈署名為 myservice 的 Docker 服務。當健康監控工具檢測到異常時，可以觸發此Pipeline以執行修復措施。

  1. pipeline { agent any } 定義了一個Pipeline，可以在任何可用的代理節點上執行。
  2. stage('Redeploy Service') 定義了一個名為「重新佈署服務」的階段。
  3. sh 'docker service update --force myservice' 在該階段中執行了一個 shell 命令，用於強制更新 myservice 服務。

預防性修復

除了反應式自我修復之外，我們還可以採取預防性措施來避免故障的發生。這需要收集和分析歷史資料，以預測潛在的問題。

圖 15-11：自我修復系統架構：預防性修復需要分析歷史資料

為了實作預防性修復，我們需要一個資料收集器來收集 CPU 使用率、硬碟使用率、網路流量等指標資料。這些資料可以儲存在一個時序資料函式庫中，以便進行分析和預測。

圖 15-12：自我修復系統架構：預防性修復需要持續收集大量資料

使用 Docker、Consul Watches 和 Jenkins 建立自我修復系統

我們已經介紹了建立自我修復系統所需的各個元件。現在，讓我們來看看如何使用 Docker、Consul Watches 和 Jenkins 建立一個反應式自我修復系統。

首先，我們需要建立虛擬機器並安裝所需的工具。然後，我們可以使用 Consul 作為服務登入檔，Registrator 作為服務監控工具，Jenkins 作為修復措施執行器。

圖 15-13：自我修復系統架構：工具組合範例

結論： 建立自我修復系統需要結合多個工具和技術，包括服務登入檔、健康監控、修復措施執行器等。透過使用 Docker、Consul Watches 和 Jenkins，我們可以建立一個反應式自我修復系統，以提高系統的可用性和可靠性。同時，我們也可以採取預防性措施來避免故障的發生，從而進一步提高系統的穩定性。

玄貓 BlackCat

玄貓 BlackCat

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