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
圖表翻譯：
graph LR
A[Docker] -->|封裝|> B[容器]
B -->|釋出|> C[容器登記冊]
C -->|佈署|> D[Kubernetes 叢集]
D -->|執行|> E[微服務]
在這個圖表中，我們可以看到 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 微服務。
圖表翻譯：
flowchart TD
A[設定環境變數] --> B[登入容器登入函式庫]
B --> C[執行生產環境佈署指令碼]
C --> D[建立和佈署微服務]
D --> E[使用 kubectl 佈署到 Kubernetes]
這個流程圖展示了生產環境佈署的步驟，從設定環境變數到使用 kubectl 佈署微服務到 Kubernetes。
10.9.3 測試生產環境佈署
當 FlixTube 佈署到生產環境的 Kubernetes 叢集後，我們應該驗證它是否正常運作。同樣地，我們可以使用 kubectl get pods、kubectl get deploy 和 kubectl 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 來自動化佈署過程。
圖表翻譯：
graph LR
A[開發人員提交程式碼] --> B[開發人員推播程式碼變更]
B --> C[GitHub Actions 組態檔案]
C --> D[CD 管道自動呼叫]
D --> E[佈署由玄貓控制]
上述圖表展示了 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：您的容器註冊中心 URLREGISTRY_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 指令碼，這些指令碼組態和維護由玄貓負責。
圖表翻譯：
flowchart TD
A[推播到 main 分支] --> B[工作流程觸發]
B --> C[簽出程式碼]
C --> D[建立映像]
D --> E[釋出映像]
E --> F[佈署應用程式]
此圖表展示了 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 以檢視會發生什麼。練習開發藝術是帶您到下一個級別的關鍵。
graph LR
A[開始] --> B[構建Docker映像]
B --> C[釋出Docker映像]
C --> D[安裝和組態kubectl]
D --> E[擴充套件組態範本]
E --> F[佈署微服務]
內容解密：
上述 Mermaid 圖表展示了 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叢集。
graph LR
A[元資料管理] --> B[影片上傳和串流]
B --> C[Azure Storage]
C --> D[歷史記錄]
D --> E[外部儲存]
E --> F[雲端儲存]
F --> G[多個入口]
G --> H[使用者/帳戶管理]
H --> I[客戶門戶]
I --> J[FlixTube使用者]
圖表翻譯：
以上圖表展示了Kubernetes叢集架構設計的一些關鍵要素之間的關係，包括元資料管理、影片上傳和串流、Azure Storage、歷史記錄、外部儲存、雲端儲存、多個入口、使用者/帳戶管理、客戶門戶和FlixTube使用者。這些要素都是Kubernetes叢集設計中非常重要的部分，可以幫助您設計一個可擴充套件性、安全性和高可用性的Kubernetes叢集。
FlixTube 的微服務架構在 Docker 與 Kubernetes 的協同下，展現了現代雲原生應用程式的高度彈性與可擴充套件性。透過容器化技術封裝微服務，搭配 Kubernetes 叢集的自動化佈署和管理，有效簡化了複雜的佈署流程並提升了系統的可靠性。然而，生產環境的佈署仍需考量安全性及效能最佳化，例如 Azure Storage 的整合以及持續佈署管線的完善，才能確保服務的穩定執行。技術團隊應著重於最佳化容器映像大小、資源組態以及網路效能等關鍵挑戰，才能充分釋放此架構的潛力。隨著雲原生技術的持續發展，預見未來 FlixTube 將能更靈活地應對不斷變化的市場需求，並持續提升使用者經驗。玄貓認為，此架構符合現代軟體開發的趨勢，值得更多企業借鏡與實踐。
