返回文章列表

FlixTube 微服務佈署:Docker 與 Kubernetes 最佳實踐

本文深入探討 FlixTube 微服務架構的佈署流程,涵蓋 Docker 容器化封裝、Kubernetes 叢集佈署及 GitHub Actions 持續佈署。文章詳細說明如何使用 Docker 建立和釋出容器映像,利用 kubectl 佈署和管理微服務,並透過 GitHub Actions

Web 開發 容器化

FlixTube 微服務架構採用 Docker 容器化技術封裝個別服務,簡化佈署流程並確保環境一致性。透過 Dockerfile 定義映像建置步驟,開發者能輕鬆建立包含所有必要依賴項的容器映像。接著,利用 Docker CLI 工具將映像釋出至容器登入中心,方便 Kubernetes 叢集存取。Kubernetes 作為容器協調系統,負責自動化佈署、擴充套件和管理容器化應用,確保 FlixTube 微服務在生產環境中的高用性和高擴充套件性。kubectl 命令列工具提供操作 Kubernetes 叢集的介面,方便開發者佈署、更新和監控微服務。此外,文章也介紹如何使用 GitHub Actions 建立 CI/CD 管線,自動化建置、測試和佈署流程,進一步提升開發效率。

容器登記冊

容器登記冊是儲存和管理 Docker 容器映像的重要元件。透過使用容器登記冊,我們可以輕鬆地管理和佈署我們的微服務。

Kubernetes 叢集

Kubernetes 叢集是用於自動化佈署、擴充套件和管理容器化應用的容器協調系統。透過使用 Kubernetes,我們可以建立一個高用性和高擴充套件性的雲端環境。

FlixTube 開發

在 FlixTube 的開發過程中,我們使用 Docker 來封裝和釋出我們的微服務。Docker 提供了一種輕量級和便捷的方式來封裝和佈署應用程式。

使用 Docker 封裝微服務

透過使用 Docker,我們可以將我們的微服務封裝成容器,並將其釋出到容器登記冊中。這樣,我們就可以輕鬆地管理和佈署我們的微服務。

使用 kubectl 佈署微服務

kubectl 是 Kubernetes 的命令列工具,透過使用 kubectl,我們可以佈署和管理我們的微服務到 Kubernetes 叢集中。

生產環境佈署

在生產環境中,我們應該使用 azure-storage 服務來取代 mock-storage 服務。azure-storage 服務提供了一種安全和高可用性的方式來儲存和管理資料。

內容解密:

# 使用 Docker 封裝微服務
docker build -t my-service.

# 將微服務釋出到容器登記冊
docker tag my-service:latest <registry-url>/my-service:latest
docker push <registry-url>/my-service:latest

# 使用 kubectl 佈署微服務到 Kubernetes 叢集
kubectl apply -f deployment.yaml

圖表翻譯:

在這個圖表中,我們可以看到 Docker 封裝微服務,然後釋出到容器登記冊中。接著,Kubernetes 叢集佈署微服務,並執行它。這個過程展示瞭如何使用 Docker 和 Kubernetes 來建立一個高用性和高擴充套件性的雲端環境。

Kubernetes 生產環境佈署

10.9.2 生產環境佈署

在將微服務映象發布到容器登入函式庫之前,我們需要登入登入函式庫並設定一些環境變數,這些變數將被用於佈署過程。

首先,開啟終端機並設定以下環境變數:

export CONTAINER_REGISTRY=<url-to-your-container-registry>

注意,Windows 使用者需要使用 WSL2 Linux 終端機來執行這些命令和指令碼。

接下來,使用以下命令登入容器登入函式庫:

docker login $CONTAINER_REGISTRY

輸入您的登入函式庫使用者名和密碼後,您就可以在同一終端機中執行生產環境佈署指令碼:

cd chapter-10/scripts/production-kub
./deploy.sh

這個指令碼會建立和佈署所有 FlixTube 微服務。雖然這個指令碼仍然有一些重複的程式碼,但這是為了簡化您的閱讀體驗。

比較生產環境佈署指令碼和本地佈署指令碼(在 10.8.2 節中),您會發現生產環境佈署指令碼會將映象推播到容器登入函式庫,並使用 envsubst 命令(在第 8 章 8.9.2 節中介紹)填充每個微服務的範本組態。這些組態會使用 CONTAINER_REGISTRY 環境變數,並將擴充套件的範本組態傳遞給 kubectl 來佈署每個微服務到 Kubernetes。

內容解密:

在這個過程中,我們使用了 docker login 命令來登入容器登入函式庫,並設定了 CONTAINER_REGISTRY 環境變數。然後,我們執行了生產環境佈署指令碼,該指令碼會建立和佈署所有 FlixTube 微服務。

圖表翻譯:

這個流程圖展示了生產環境佈署的步驟,從設定環境變數到使用 kubectl 佈署微服務到 Kubernetes。

10.9.3 測試生產環境佈署

當 FlixTube 佈署到生產環境的 Kubernetes 叢集後,我們應該驗證它是否正常運作。同樣地,我們可以使用 kubectl get podskubectl get deploykubectl get services 來檢視為 FlixTube 建立的 Kubernetes 資源。關於測試已佈署的微服務的更多資訊,請參考第 6 章,6.11.5 和 6.11.6 節。

kubectl get services 的輸出中,我們可以找到入口微服務的 IP 地址。開啟瀏覽器並導航到該 IP 地址的網頁:關於測試本地佈署的更多細節,請參考第 6 章,6.8.5 和 6.8.6 節。

10.9.4 刪除生產環境佈署

當您完成測試和實驗後,使用提供的 shell 指令碼刪除佈署:

./delete.sh

該 shell 指令碼會為每個微服務呼叫 kubectl delete,從 Kubernetes 中刪除它們。

10.10 持續佈署到生產環境

在手動佈署 FlixTube 到生產環境並進行測試和實驗後,我們現在準備啟用 CD 管道。您可以跟隨,但這可能比之前的章節更具挑戰性。如果出現問題,您可能需要傳回到本地或手動佈署(我們剛剛在 10.8 和 10.9 節中完成的內容)來排除問題。 如同第 8 章中所做的,我們將使用 GitHub Actions 建立 CD 管道。它應該相對容易轉移到其他 CD 平臺。如我在第 8 章中所說,CD 管道基本上只是一種執行 shell 指令碼的方式,即使一些提供者也提供了漂亮的 UI。圖 10.16 展示了 FlixTube 的 CD 管道結構。

開發人員提交程式碼到本地倉函式庫。 開發人員將程式碼變更推播到託管程式碼倉函式庫。 各種 GitHub Actions 的組態檔案定義了我們微服務的持續佈署管道。 CD 管道由玄貓自動呼叫; 因此,佈署由玄貓控制。

內容解密:

上述過程描述瞭如何測試和刪除生產環境佈署,以及如何啟用 CD 管道。首先,我們使用 kubectl 命令來驗證 FlixTube 的佈署狀態。然後,我們使用 shell 指令碼刪除佈署。最後,我們啟用 CD 管道,使用 GitHub Actions 來自動化佈署過程。

圖表翻譯:

上述圖表展示了 CD 管道的流程,從開發人員提交程式碼到佈署由玄貓控制。每個步驟都清楚地展示了過程中的邏輯關係。

微服務佈署流程:Docker 和 kubectl 的應用

在現代軟體開發中,微服務架構已成為了一種主流的設計模式。它允許我們將一個大型應用程式拆分成多個小型、獨立的服務,每個服務負責一部分的功能。然而,管理和佈署這些微服務可能會變得複雜。為了簡化這個過程,我們可以使用 Docker 和 kubectl 這兩個強大的工具。

Docker:容器化的解決方案

Docker 是一個容器化平臺,允許我們將應用程式和其依賴包裝成一個容器,然後在任何支援 Docker 的環境中執行。這意味著我們可以在本地開發環境中建立一個微服務,然後直接佈署到生產環境中,而不需要擔心環境差異的問題。

建立 Docker 映像

要建立一個 Docker 映像,我們需要建立一個 Dockerfile,它包含了建立映像的指令。例如:

FROM python:3.9-slim

WORKDIR /app

COPY requirements.txt.

RUN pip install -r requirements.txt

COPY..

CMD ["python", "app.py"]

這個 Dockerfile 告訴 Docker 使用 Python 3.9 的基礎映像,複製 requirements.txt 到工作目錄,安裝依賴包,然後複製應用程式程式碼到工作目錄。最後,設定命令來執行應用程式。

執行 Docker 容器

一旦我們建立了 Docker 映像,就可以使用 docker run 命令來執行容器:

docker run -p 8000:8000 my-microservice

這個命令啟動一個新的容器從 my-microservice 映像,並將容器的 8000 連線埠對映到主機的 8000 連線埠。

kubectl:Kubernetes 的命令列工具

kubectl 是 Kubernetes 的命令列工具,允許我們管理和佈署微服務到 Kubernetes 叢集。要使用 kubectl,我們需要先建立一個 Kubernetes 叢集,然後組態 kubectl 來連線到叢集。

佈署微服務到 Kubernetes

要佈署微服務到 Kubernetes,我們需要建立一個佈署組態檔(deployment YAML 檔案),它定義了微服務的佈署細節。例如:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-microservice
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-microservice
  template:
    metadata:
      labels:
        app: my-microservice
    spec:
      containers:
      - name: my-microservice
        image: my-microservice:latest
        ports:
        - containerPort: 8000

這個 YAML 檔案定義了一個名為 my-microservice 的佈署,具有 3 個複製品,使用 my-microservice:latest 映像,並將容器的 8000 連線埠暴露給外界。

應用佈署組態

要應用這個佈署組態,我們可以使用 kubectl apply 命令:

kubectl apply -f deployment.yaml

這個命令告訴 kubectl 應用 deployment.yaml 檔案中的組態,建立或更新 my-microservice 佈署。

GitHub Actions:自動化佈署流程

GitHub Actions 是一個連續整合和連續佈署(CI/CD)工具,允許我們自動化軟體開發和佈署流程。要使用 GitHub Actions,我們需要在 GitHub 儲存函式庫中建立一個工作流程組態檔(workflow YAML 檔案),它定義了自動化流程的細節。

建立工作流程組態

例如:

name: Deploy to Kubernetes

on:
  push:
    branches:
      - main

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v2
      - name: Login to Kubernetes
        uses: kubernetes/login-action@v1
        with:
          token: ${{ secrets.KUBE_TOKEN }}
      - name: Deploy to Kubernetes
        run: |
          kubectl apply -f deployment.yaml

這個 YAML 檔案定義了一個名為 Deploy to Kubernetes 的工作流程,當 main 分支收到推播時觸發。工作流程包括三個步驟:簽出程式碼、登入 Kubernetes,以及佈署到 Kubernetes。

自動化佈署

當我們推播程式碼到 main 分支時,GitHub Actions 會自動觸發工作流程,執行佈署步驟,將微服務佈署到 Kubernetes 叢集。

Kubernetes 環境下的 FlixTube 持續佈署

在本文中,我們將探討如何實作 FlixTube 的持續佈署(Continuous Deployment, CD)到 Kubernetes 環境中。為了跟隨本文的內容,您需要有一個 GitHub 帳戶,並且已經完成了第 8 章中的相關設定。

10.10.1 持續佈署的前置條件

要實作持續佈署,您需要滿足以下條件:

  • 您需要有一個 GitHub 帳戶。如果您已經完成了第 8 章中的內容,您應該已經有一個 GitHub 帳戶。
  • 您需要一個容器註冊中心(Container Registry)和一個 Kubernetes 叢集。這些資源的設定請參考第 10.9.1 節。
  • 您需要將您的 Kubernetes 叢集的認證資料編碼為 Base64 格式。這部分的操作請參考第 8 章中的 8.9.5 節。

10.10.2 設定您的程式碼倉函式庫

要執行 FlixTube 的持續佈署Pipeline,您需要 fork 第 10 章的程式碼倉函式庫,並按照第 8 章中的 8.9.9 節的指導增加必要的秘密(Secrets)。您需要在您的程式碼倉函式庫中增加以下秘密:

  • CONTAINER_REGISTRY:您的容器註冊中心 URL
  • REGISTRY_UN:您的容器註冊中心使用者名
  • REGISTRY_PW:您的容器註冊中心密碼
  • KUBE_CONFIG:Base64 編碼的 Kubernetes 叢集組態,用於認證您的 kubectl 客戶端

10.10.3 佈署基礎設施

在使用持續佈署佈署 FlixTube 之前,我們需要先手動佈署 FlixTube 所依賴的基礎設施,包括 MongoDB 和 RabbitMQ。由於這些基礎設施不會頻繁變化,因此我們只需要佈署一次。

在第 10 章的程式碼倉函式庫中,有一個 shell 指令碼可以幫助您完成這一步:

cd chapter-10
./scripts/cd/infrastructure.sh

您可以檢視這個 shell 指令碼,它相當簡單,主要是使用 kubectl apply 命令來佈署 MongoDB 和 RabbitMQ 的組態到您的 Kubernetes 叢集中。

回顧第 4 章,我們曾經討論過如何使 Kubernetes 叢集變得「無狀態」(Stateless),也就是說,從叢集中移除持久化的 MongoDB 資料函式庫,並使用外部管理的資料函式庫來儲存資料。在這裡,我們直接將 MongoDB 佈署到叢集中,這主要是為了方便您自己佈署和測試。如果您正在開發一個生產級別的應用程式,建議您將資料函式庫抽取出來,使用外部管理的 MongoDB 服務。這樣可以更好地管理資料和應用程式的可擴充套件性。

個別微服務的 CD Pipeline

在 chapter-10 程式碼倉函式庫中,檢視 .github/workflows 目錄,您將看到每個微服務都有單獨的 GitHub Actions 工作流程檔案(YAML 檔案)。例如,開啟 gateway 微服務的 CD Pipeline組態檔案(chapter-10/.github/workflows/gateway.yaml),您將看到整個工作流程,如清單 10.16 所示。注意,大部分工作都委託給由玄貓組態的 shell 指令碼。

name: 佈署 gateway
on:
  push:
    branches:
      - main
    paths:
      - gateway/**
  workflow_dispatch:
jobs:
  deploy:
    runs-on: ubuntu-latest
    env:
      VERSION: ${{ github.sha }}
      REGISTRY_UN: ${{ secrets.REGISTRY_UN }}
      REGISTRY_PW: ${{ secrets.REGISTRY_PW }}
      NAME: gateway
      DIRECTORY: gateway
    steps:
      - uses: actions/checkout@v3
      - name: 建立
        run:./scripts/cd/build-image.sh
      - name: 釋出
        run:./scripts/cd/push-image.sh
      - uses: tale/kubectl-action@v1
        with:
          base64-kube-config: ${{ secrets.KUBE_CONFIG }}
          kubectl-version: v1.24.2
      - name: 佈署
        run:./scripts/cd/deploy.sh

清單 10.16 啟用 gateway 的個別 CD Pipeline

  • 命名 CD Pipeline
  • 在推播到 main 分支時執行工作流程
  • 將 CD Pipeline範圍限定為 gateway 子目錄。這個工作流程只會在 gateway 微服務發生變化時執行。這就是允許在 monorepo 中為微服務啟用獨立 CD Pipeline的原因。
  • 允許從 GitHub Actions UI 觸發 CD Pipeline
  • 設定在 shell 指令碼中使用的環境變數

內容解密:

這個 YAML 檔案定義了一個 GitHub Actions 工作流程,該工作流程負責佈署 gateway 微服務。工作流程在推播到 main 分支且變更發生在 gateway 子目錄時觸發。它使用環境變數儲存版本、登入倉函式庫憑據和 Kubernetes 組態等訊息。工作流程包括四個步驟:簽出程式碼、建立映像、釋出映像和佈署應用程式。每個步驟都委託給 shell 指令碼,這些指令碼組態和維護由玄貓負責。

圖表翻譯:

此圖表展示了 CD Pipeline的工作流程。當程式碼推播到 main 分支時,工作流程被觸發,然後依次執行簽出程式碼、建立映像、釋出映像和佈署應用程式的步驟。

10.10 持續佈署管線

持續佈署(Continuous Deployment,CD)是一種自動化佈署流程,當程式碼變更時,會自動構建、測試和佈署應用程式。以下是 FlixTube 的 CD 管線組態:

10.10.1 建立 Docker 映像

  • 使用 Dockerfile 建立 Docker 映像
  • 將映像釋出到容器登入中心

10.10.2 安裝和組態 kubectl

  • 安裝 kubectl 工具
  • 組態 kubectl 連線到 Kubernetes 叢集

10.10.3 擴充套件組態範本

  • 使用 envsubst 擴充套件組態範本
  • 將組態檔案應用到 Kubernetes 叢集

10.10.4 佈署微服務

  • 佈署微服務到 Kubernetes 叢集
  • 確保微服務正常執行

10.11 FlixTube 的未來

恭喜!如果您已經完成了本章的內容,您現在已經有了一個執行在生產環境中的 FlixTube 應用程式,並且您已經準備好繼續開發和演進它。您可以進行程式碼變更,測試它們,並且佈署您的更新到生產環境。

FlixTube 的未來是什麼?這取決於您的想象力!在第 12 章中,我們將討論 FlixTube 未來的技術方面:

  • 如何擴充套件以滿足不斷增長的使用者基數?
  • 如何擴充套件開發和佈署流程,以滿足應用程式的增長和開發團隊的增長?

現在,只需想象一下,您想在未來為 FlixTube 增加哪些微服務。圖 10.17 給您了一些靈感,展示了 FlixTube 未來可能的樣子。

10.12 繼續學習

在本章中,我們研究了 FlixTube 示例應用程式的結構和佈局。我們構建、執行和測試了它,並且透過其 CD 管線將其佈署到生產環境。

您現在已經有了一個執行的 FlixTube 應用程式,那麼接下來呢?閱讀任何書籍只能帶您走到一定的程度。掌握這些技能的關鍵是練習、練習和再次練習。嘗試使用程式碼,嘗試增加功能,嘗試增加新的微服務,甚至嘗試破壞 FlixTube 以檢視會發生什麼。練習開發藝術是帶您到下一個級別的關鍵。

內容解密:

上述 Plantuml 圖表展示了 FlixTube 的 CD 管線流程。流程從構建 Docker 映像開始,然後釋出映像到容器登入中心。接下來,安裝和組態 kubectl 工具,以便連線到 Kubernetes 叢集。然後,使用 envsubst 擴充套件組態範本,並將組態檔案應用到 Kubernetes 叢集。最後,佈署微服務到 Kubernetes 叢集,並確保微服務正常執行。

圖表翻譯:

這個圖表展示了 FlixTube 的 CD 管線流程。流程包括構建 Docker 映像、釋出映像、安裝和組態 kubectl、擴充套件組態範本和佈署微服務。每一步驟都很重要,以確保 FlixTube 應用程式可以順暢地佈署到生產環境。透過這個圖表,我們可以清晰地看到 CD 管線的流程和每一步驟的重要性。

Kubernetes叢集架構設計

在設計Kubernetes叢集時,需要考慮多個因素,以確保叢集的可擴充套件性、安全性和高用性。以下是Kubernetes叢集架構設計的一些關鍵要素:

元資料管理

元資料是指描述Kubernetes資源的資料,例如Pod、ReplicaSet、Deployment等。元資料管理是指如何儲存、管理和查詢這些元資料。Kubernetes提供了etcd作為元資料儲存的解決方案。

影片上傳和串流

在FlixTube應用中,影片上傳和串流是兩個重要的功能。Kubernetes提供了多種方式來實作這些功能,例如使用Azure Storage作為影片儲存的解決方案,使用LoadBalancer或Ingress作為影片串流的入口。

Azure Storage

Azure Storage是一種雲端儲存解決方案,提供了高用性和可擴充套件性的儲存服務。Kubernetes可以與Azure Storage整合,實作影片儲存和串流的功能。

歷史記錄

歷史記錄是指Kubernetes叢集的操作記錄,例如建立、更新和刪除資源的記錄。Kubernetes提供了audit log作為歷史記錄的解決方案。

外部儲存

外部儲存是指Kubernetes叢集以外的儲存解決方案,例如雲端儲存或分散式檔案系統。Kubernetes可以與外部儲存整合,實作資源的分享和儲存。

雲端儲存

雲端儲存是一種雲端計算的儲存解決方案,提供了高用性和可擴充套件性的儲存服務。Kubernetes可以與雲端儲存整合,實作資源的分享和儲存。

多個入口

多個入口是指Kubernetes叢集提供多個入口點,以便不同的應用可以存取不同的資源。Kubernetes提供了Ingress作為多個入口的解決方案。

使用者/帳戶管理

使用者/帳戶管理是指Kubernetes叢集的使用者和帳戶管理,例如建立、更新和刪除使用者和帳戶。Kubernetes提供了RBAC(Role-Based Access Control)作為使用者/帳戶管理的解決方案。

客戶門戶

客戶門戶是指Kubernetes叢集的客戶門戶,例如FlixTube應用的客戶門戶。Kubernetes提供了Ingress作為客戶門戶的解決方案。

FlixTube使用者

FlixTube使用者是指FlixTube應用的使用者,例如建立、更新和刪除FlixTube使用者。Kubernetes提供了RBAC(Role-Based Access Control)作為FlixTube使用者管理的解決方案。

內容解密:

以上內容介紹了Kubernetes叢集架構設計的一些關鍵要素,包括元資料管理、影片上傳和串流、Azure Storage、歷史記錄、外部儲存、雲端儲存、多個入口、使用者/帳戶管理、客戶門戶和FlixTube使用者。這些要素都是Kubernetes叢集設計中非常重要的部分,可以幫助您設計一個可擴充套件性、安全性和高可用性的Kubernetes叢集。

@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle

title FlixTube 微服務佈署:Docker 與 Kubernetes 最佳實踐

package "Kubernetes Cluster" {
    package "Control Plane" {
        component [API Server] as api
        component [Controller Manager] as cm
        component [Scheduler] as sched
        database [etcd] as etcd
    }

    package "Worker Nodes" {
        component [Kubelet] as kubelet
        component [Kube-proxy] as proxy
        package "Pods" {
            component [Container 1] as c1
            component [Container 2] as c2
        }
    }
}

api --> etcd : 儲存狀態
api --> cm : 控制迴圈
api --> sched : 調度決策
api --> kubelet : 指令下達
kubelet --> c1
kubelet --> c2
proxy --> c1 : 網路代理
proxy --> c2

note right of api
  核心 API 入口
  所有操作經由此處
end note

@enduml

圖表翻譯:

以上圖表展示了Kubernetes叢集架構設計的一些關鍵要素之間的關係,包括元資料管理、影片上傳和串流、Azure Storage、歷史記錄、外部儲存、雲端儲存、多個入口、使用者/帳戶管理、客戶門戶和FlixTube使用者。這些要素都是Kubernetes叢集設計中非常重要的部分,可以幫助您設計一個可擴充套件性、安全性和高可用性的Kubernetes叢集。

FlixTube 的微服務架構在 Docker 與 Kubernetes 的協同下,展現了現代雲原生應用程式的高度彈性與可擴充套件性。透過容器化技術封裝微服務,搭配 Kubernetes 叢集的自動化佈署和管理,有效簡化了複雜的佈署流程並提升了系統的可靠性。然而,生產環境的佈署仍需考量安全性及效能最佳化,例如 Azure Storage 的整合以及持續佈署管線的完善,才能確保服務的穩定執行。技術團隊應著重於最佳化容器映像大小、資源組態以及網路效能等關鍵挑戰,才能充分釋放此架構的潛力。隨著雲原生技術的持續發展,預見未來 FlixTube 將能更靈活地應對不斷變化的市場需求,並持續提升使用者經驗。玄貓認為,此架構符合現代軟體開發的趨勢,值得更多企業借鏡與實踐。