GitHub Actions 自動化持續佈署微服務至 Kubernetes

– 18 分鐘閱讀

在現代軟體開發流程中，持續整合與持續佈署（CI/CD）至關重要。本文將深入探討如何運用 GitHub Actions 建立 CI/CD 管道，實作微服務的自動化建置、測試和佈署至 Kubernetes。此流程包含撰寫工作流程 YAML 檔案、設計 Shell 指令碼、設定環境變數、操作 kubectl 等環節。

GitHub Actions 提供了便捷的平臺，直接在程式碼儲存函式庫中建立自動化工作流程。透過 YAML 檔案定義工作流程，並結合 Shell 指令碼執行建置、測試及佈署等任務。環境變數的運用，讓佈署設定更具彈性，而 kubectl 則負責與 Kubernetes 互動，管理應用程式佈署。以下將逐步說明如何整合這些技術，打造自動化佈署流程。

建立 GitHub Actions 工作流程

要建立 GitHub Actions 工作流程，您需要在您的程式碼倉函式庫中建立一個新的 YAML 檔案。該檔案定義了工作流程的組態，包括要執行的任務和事件觸發器。您可以使用 GitHub Actions 提供的範本來建立工作流程，也可以從頭開始建立自己的工作流程。

GitHub Actions 的優點

GitHub Actions 有許多優點，包括：

  • 自動化軟體建置、測試和佈署的流程
  • 支援多種程式設計語言和框架
  • 可以根據不同的事件觸發工作流程
  • 提供了一個簡單的方式來定義工作流程
  • 可以與其他 GitHub 工具整合，例如 GitHub Pages 和 GitHub Packages

圖表翻譯：

此圖表展示了 GitHub Actions 的工作流程。從開始到完成，工作流程包括定義工作流程、觸發工作流程、執行任務和完成工作流程等步驟。每個步驟都可以根據不同的事件觸發，例如程式碼推播、提取請求和問題建立。透過使用 GitHub Actions，您可以自動化軟體建置、測試和佈署的流程，並提高軟體交付的效率和品質。

  flowchart TD
    A[定義工作流程] --> B[選擇觸發器]
    B --> C[組態任務]
    C --> D[儲存工作流程]

圖表翻譯：

此圖表展示了建立 GitHub Actions 工作流程的步驟。從定義工作流程到儲存工作流程，建立工作流程包括選擇觸發器、組態任務和儲存工作流程等步驟。您可以使用 GitHub Actions 提供的範本來建立工作流程，也可以從頭開始建立自己的工作流程。透過使用 GitHub Actions，您可以自動化軟體建置、測試和佈署的流程，並提高軟體交付的效率和品質。

自動化工作流程入門：使用 GitHub Actions

GitHub Actions 是一個強大的工具，允許您自動化軟體開發工作流程。它提供了一種簡單的方式來定義和執行工作流程，從而節省時間和提高效率。在本文中，我們將探討如何使用 GitHub Actions 建立一個簡單的工作流程，並瞭解其基本概念。

工作流程組態檔案

GitHub Actions 工作流程是透過 YAML 組態檔案定義的。這些檔案儲存在您的儲存函式庫中，並由 GitHub Actions 執行。以下是 hello world 工作流程的 YAML 組態檔案：

name: Hello World
on:
  push:
    branches:
      - main
  workflow_dispatch:
jobs:
  hello-world:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Run the shell script
        run:./index.sh

這個組態檔案定義了一個名為 “Hello World” 的工作流程，它在推播到 main 分支時觸發。工作流程由一個名為 “hello-world” 的 job 組成，該 job 執行在 Ubuntu Linux 上。

工作流程步驟

工作流程步驟是工作流程中的一系列任務。每個步驟可以執行一條命令或一組命令。以下是 hello world 工作流程的步驟：

steps:
  - uses: actions/checkout@v3
  - name: Run the shell script
    run:./index.sh

第一個步驟簽出儲存函式庫的程式碼，然後第二個步驟執行 shell 指令碼 index.sh。

Inline 命令

您也可以在工作流程中 inline 執行命令。以下是 hello world 工作流程的 inline 命令版本：

steps:
  - uses: actions/checkout@v3
  - name: Prints hello world
    run: echo "Hello world!"

這個版本的工作流程直接在工作流程中執行 echo 命令，而不是執行 shell 指令碼。

持續佈署的工作流程

在持續佈署的過程中，我們可以使用不同的語法來呼叫多個命令。以下是使用 steps 來定義多個命令的範例：

steps:
  - uses: actions/checkout@v3
  - name: Prints hello world
    run: |
      <command1>
      <command2>
      <etc>

我們也可以定義多個步驟，每個步驟都有自己的命令：

steps:
  - uses: actions/checkout@v3
  - name: First step
    run: |
      <command1>
      <command2>
      <etc>
  - name: Second step
    run: |
      <command1>
      <command2>
      <etc>

在實際應用中，我們可以直接在工作流程中呼叫命令，而不需要使用 shell 指令碼。然而，在某些情況下，使用 shell 指令碼可以將命令與工作流程檔案分開，提高可讀性和維護性。

觸發工作流程

現在，我們已經建立了一個簡單的工作流程，並定義了一個 job 讓它執行。讓我們看看這個工作流程在行動中。 如第 8.3 節所述，要試驗本章的範例，您需要 fork 每個程式碼倉函式庫。如果您尚未這樣做，現在就 fork example-1： 然後，克隆您自己的倉函式庫副本。前往您的 fork 的 Actions 標籤，如果您尚未啟用工作流程，請啟用它。因為我們尚未觸發任何工作流程，所以歷史記錄中不應該有任何工作流程列出。 現在，嘗試進行更改；例如，在 index.sh 檔案中，將 “hello world” 改為 “hello computer”。然後，提交您的更改到程式碼倉函式庫，並使用 git push 將您的程式碼更改推播到 GitHub。這將觸發我們早先在清單 8.2 中定義的工作流程。

使用垂直條 | 來啟動多行命令塊

多個命令

多行命令塊

在工作流程中，我們可以使用垂直條 | 來啟動多行命令塊。這允許我們將多個命令寫在同一塊中，使得工作流程檔案更容易閱讀和維護。

自動化工作流程與持續整合

在上一節中，我們建立了一個簡單的 GitHub Actions 工作流程，該工作流程在程式碼變更時觸發並執行一個 shell 指令碼。現在，我們將進一步探索如何實作持續整合（Continuous Integration, CI）和持續佈署（Continuous Deployment, CD）。

工作流程歷史

當我們提交程式碼變更時，GitHub Actions 會觸發工作流程並記錄其狀態和輸出。我們可以在 GitHub 中檢視工作流程歷史，以便追蹤工作流程的執行情況。

手動觸發工作流程

除了程式碼變更觸發工作流程外，我們還可以手動觸發工作流程。這對於測試和除錯工作流程非常有用。我們可以在 GitHub Actions 中點選「Run Workflow」按鈕來手動觸發工作流程。

實作持續整合

在這一節中，我們將建立一個 CI 管道，該管道會在程式碼變更時觸發自動化測試。雖然我們尚未涵蓋自動化測試，但我們將看到如何在 CI 管道中觸發自動化測試。

示例 2：持續整合

讓我們移動到示例 2 中的程式碼：http://mng.bz/1Jxq。在這個示例中，我們將建立一個 CI 管道，該管道會在程式碼變更時觸發自動化測試。

  flowchart TD
    A[程式碼變更] --> B[觸發工作流程]
    B --> C[執行自動化測試]
    C --> D[記錄測試結果]

內容解密：

  • 在這個示例中，我們建立了一個 CI 管道，該管道會在程式碼變更時觸發自動化測試。
  • 我們使用 GitHub Actions 來定義工作流程，並在程式碼變更時觸發工作流程。
  • 工作流程執行自動化測試，並記錄測試結果。

圖表翻譯：

  • 圖表顯示了 CI 管道的工作流程。
  • 當程式碼變更時，工作流程被觸發，並執行自動化測試。
  • 測試結果被記錄下來，以便追蹤測試的結果。

持續佈署

在這個例子中，我們將使用 Node.js 的視訊串流微服務，並加入自動化測試。專案的結構如圖 8.11 所示。

自動化測試的工作流程

清單 8.3 顯示了自動化測試的工作流程。有兩個命令需要注意。第一個是 npm ci，它類別似於 npm install，但設計用於在 CI 管線中執行，以確保依賴項的安裝是可預測和穩定的。第二個命令是 npm test，它是 Node.js 中執行自動化測試的慣用命令。

這個例子是根據 Node.js，但您可以輕鬆地將其適應於其他語言或框架。事實上，您不需要花太多時間思考這個問題，只需搜尋一個工作流程範本作為起點，如 8.7.3 節所述。GitHub Actions 已經為每種語言和框架準備好了範本。

持續佈署的微服務

以下是持續佈署的微服務組態檔案：

name: CI
on:
  push:
    branches:
      - main
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-node@v3
        with:
          node-version: 18.x
          cache: 'npm'
      - run: npm ci
      - run: npm test

要試用這個例子，您需要 fork 和 clone 程式碼倉函式庫。確保您進入 GitHub Actions 標籤並啟用工作流程執行。然後，嘗試修改程式碼並推播您的程式碼。這將觸發工作流程並執行自動化測試。

成果

我們現在已經建立了一個有用的 GitHub Actions 工作流程，可以在每次推播程式碼到 GitHub 時自動測試微服務。我們可以輕鬆地看到自動化測試管線如何在每次程式碼變更時執行測試，而不會跳過任何一步。如果我們推播壞的程式碼，CI 管線將快速地檢測到問題並通知我們，以便我們糾正情況。

內容解密：

在這個例子中，我們使用 npm ci 和 npm test 命令來執行自動化測試。npm ci 命令用於在 CI 管線中安裝依賴項，以確保依賴項的安裝是可預測和穩定的。npm test 命令則用於執行自動化測試。

圖表翻譯：

以下是工作流程組態檔案的 Mermaid 圖表：

  graph LR
    A[Push 程式碼] --> B[觸發工作流程]
    B --> C[執行 npm ci]
    C --> D[執行 npm test]
    D --> E[顯示測試結果]

這個圖表顯示了工作流程的執行過程，從推播程式碼到顯示測試結果。

8.9 持續佈署微服務

現在，我們來到了主要事件和使用 GitHub Actions 的最重要原因之一。在本文中，我們將建立一個工作流程，自動將我們的影片串流媒體微服務佈署到 Kubernetes，每當我們將程式碼更改推播到 GitHub 時。

8.9.1 示例 3 概覽

讓我們來看看示例 3 的工作流程，該工作流程會自動執行 Node.js 微服務的測試。

  • 定義工作流程的名稱
  • 工作流程在推播到主分支時觸發
  • 取得程式碼倉函式庫的副本，包括 Node.js 微服務專案
  • 安裝 Node.js 版本 18
  • 安裝依賴項，這與 npm install 類別似，但設計為非互動式和在自動化管道中執行
  • 對 Node.js 專案執行自動測試

如圖 8.12 所示，專案佈局與我們之前看到的示例 2 類別似。請注意新增的檔案，包括有用的 shell 指令碼、用於構建、釋出和佈署微服務的 YAML 檔案，以及用於建立生產映像的 Dockerfile。

8.9.2 組態佈署組態

在設定微服務專案的自動佈署之前，我們需要組態佈署管道。為了避免將佈署細節硬編碼到專案中，我們需要對佈署組態檔案進行引數化，以便在 CD 管道執行期間填入空白值。

在前面的章節中，我們使用環境變數來組態微服務，環境變數也是一種簡單且有效的方式來組態 CD 管道。將容器註冊表和版本號等細節硬編碼到程式碼中是不合理的，因為這些值可能會發生變化。

微服務的版本號不能硬編碼，因為它會頻繁發生變化。如果硬編碼版本號，則意味著需要定期更新程式碼倉函式庫中的版本號，這對於未來的多個微服務專案來說將非常困難。

以下是專案結構和工作流程組態檔案的詳細訊息：

  • chapter-8-example-3：專案根目錄
  • Dockerfile-prod：生產環境 Dockerfile
  • package.json：Node.js 專案組態檔案
  • .github：GitHub Actions 工作流程組態目錄
  • workflows：工作流程組態檔案目錄
  • deploy.yaml：佈署組態檔案
  • scripts：shell 指令碼目錄
  • build-image.sh：構建映像指令碼
  • delete.sh：刪除資源指令碼
  • deploy.sh：佈署指令碼
  • push-image.sh：推播映像指令碼
  • kubernetes：Kubernetes 組態檔案目錄
  • deploy.yaml：Kubernetes 佈署組態檔案
  • src：源程式碼目錄
  • index.js：Node.js 專案入口檔案
  • videos：影片檔案目錄
  • SampleVideo_1280x720_1mb.mp4：示例影片檔案

內容解密：

以上內容介紹瞭如何使用 GitHub Actions 實作微服務的持續佈署。透過組態工作流程和佈署管道，可以自動將程式碼更改推播到 Kubernetes，實作無人值守的佈署過程。

圖表翻譯：

圖 8.12 顯示了專案佈局和工作流程組態檔案的關係。透過這個圖表，可以清晰地看到不同元件之間的關係和工作流程的執行順序。

  graph LR
    A[專案根目錄] --> B[GitHub Actions 工作流程]
    B --> C[佈署管道]
    C --> D[Kubernetes]
    D --> E[微服務]
    E --> F[影片串流媒體]

圖表翻譯：

以上 Mermaid 圖表顯示了專案根目錄、GitHub Actions 工作流程、佈署管道、Kubernetes、微服務和影片串流媒體之間的關係。透過這個圖表，可以清晰地看到不同元件之間的關係和工作流程的執行順序。

持續佈署管線的微服務封裝

為了實作微服務的持續佈署，我們需要建立一個 Dockerfile 來封裝微服務。這個 Dockerfile 將包含所有必要的設定和依賴項，以便在生產環境中佈署微服務。

Dockerfile 的作用

Dockerfile 是一個文字檔案，包含了用於構建 Docker 映像的指令。透過執行這些指令，Docker 可以建立一個包含微服務所有必要元件的映像。

Shell 指令碼的使用

除了 Dockerfile 之外，我們還需要建立 Shell 指令碼來自動化微服務的構建、發布和佈署過程。這些指令碼將使用 Docker CLI 來執行相關任務。

Kubernetes 佈署組態

為了在 Kubernetes 中佈署微服務，我們需要建立一個佈署組態檔案（deployment.yaml）。這個檔案將定義微服務的佈署設定，包括容器映像、版本號和其他相關組態。

玄貓的微服務程式碼

以下是玄貓的微服務程式碼：

from flask import Flask, jsonify

app = Flask(__name__)

@app.route('/healthcheck', methods=['GET'])
def healthcheck():
    return jsonify({'status': 'ok'})

if __name__ == '__main__':
    app.run(host='0.0.0.0', port=5000)

這個程式碼定義了一個簡單的 Flask 應用程式，提供了一個健康檢查端點。

持續佈署的實作

為了實作持續佈署，我們需要使用一個工具來自動化微服務的構建、發布和佈署過程。這個工具可以是 Jenkins、GitLab CI/CD 或其他類別似的工具。

envsubst 的使用

envsubst 是一個命令列工具，允許我們將環境變數注入到組態檔案中。在我們的例子中，我們可以使用 envsubst 來注入容器登錄檔和版本號到 Kubernetes 佈署組態檔案中。

佈署組態檔案的建立

以下是佈署組態檔案（deployment.yaml）的內容：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: microservice
spec:
  replicas: 3
  selector:
    matchLabels:
      app: microservice
  template:
    metadata:
      labels:
        app: microservice
    spec:
      containers:
      - name: microservice
        image: ${CONTAINER_REGISTRY}/microservice:${VERSION}
        ports:
        - containerPort: 5000

在這個檔案中，我們使用了環境變數 CONTAINER_REGISTRY 和 VERSION 來定義容器映像的位置和版本號。

持續佈署管線的建立

以下是持續佈署管線的建立過程：

  1. 建立一個新的 Git 分支。
  2. 更新微服務程式碼。
  3. 執行 Shell 指令碼來構建和發布微服務。
  4. 使用 envsubst 注入環境變數到佈署組態檔案中。
  5. 佈署微服務到 Kubernetes 叢集中。

透過這個過程，我們可以實作微服務的持續佈署，確保每次程式碼更新都可以快速地佈署到生產環境中。

使用環境變數和 envsubst 命令自動化佈署組態

在自動化佈署流程中，使用環境變數和 envsubst 命令可以幫助我們動態地組態佈署檔案。這使得我們可以更輕鬆地管理和維護應用程式的版本和容器登錄檔。

環境變數的設定

首先，我們需要設定 VERSION 和 CONTAINER_REGISTRY 這兩個環境變數。這些變數將被用來填充佈署組態檔案中的引數。

export VERSION=1.0.0
export CONTAINER_REGISTRY=gcr.io/my-project

使用 envsubst 命令

envsubst 命令可以用來替換組態檔案中的引數，使用環境變數的值。以下是如何使用 envsubst 命令來填充佈署組態檔案 deploy.yaml 中的引數：

envsubst < deploy.yaml

這個命令會讀取 deploy.yaml 檔案，並將其中的 $VERSION 和 $CONTAINER_REGISTRY 引數替換為環境變數的值。

佈署組態檔案範例

以下是 deploy.yaml 檔案的範例內容：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: video-streaming
spec:
  replicas: 1
  selector:
    matchLabels:
      app: video-streaming
  template:
    metadata:
      labels:
        app: video-streaming
    spec:
      containers:
      - name: video-streaming
        image: $CONTAINER_REGISTRY/video-streaming:$VERSION
        imagePullPolicy: IfNotPresent
        env:
        - name: PORT
          value: "4000"

在這個範例中， $CONTAINER_REGISTRY 和 $VERSION 引數將被替換為環境變數的值。

結果

使用 envsubst 命令後，佈署組態檔案 deploy.yaml 將被填充為：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: video-streaming
spec:
  replicas: 1
  selector:
    matchLabels:
      app: video-streaming
  template:
    metadata:
      labels:
        app: video-streaming
    spec:
      containers:
      - name: video-streaming
        image: gcr.io/my-project/video-streaming:1.0.0
        imagePullPolicy: IfNotPresent
        env:
        - name: PORT
          value: "4000"

這樣，我們就可以輕鬆地管理和維護應用程式的版本和容器登錄檔了。

8.9 持續佈署

在開始自動化之前，我們必須先了解如何手動完成任務。因此，如果您尚未使用過 envsubst，現在是嘗試直接使用它的時機。在終端機中設定以下環境變數：

export CONTAINER_REGISTRY=<您的容器登入網址>
export VERSION=1

您需要使用自己的容器登入網址。您可以使用之前建立的容器登入，或按照第 3 章第 3.9.1 節或第 7 章第 7.9.2 節的方法建立一個新的登入。

現在，在 chapter-8-example-3 專案中使用 envsubst 命令，輸入 deploy.yaml 檔案：

cd chapter-8-example-3
envsubst <./scripts/kubernetes/deploy.yaml

在輸出中，您應該看到 deploy.yaml 中的引數已被替換為環境變數的值。

8.9.3 手動佈署先於自動佈署

在自動化佈署過程之前，我們需要有一個可以自動化的流程。如果我們無法手動完成一個流程，那麼我們就不應該嘗試自動化它。就像任何編碼任務一樣，我們必須先能夠在本地機器上執行它，然後才能嘗試在生產環境中執行它。

這與我們在第 6 章中進行的手動佈署流程相同，不同的是，這次我們將建立 shell 指令碼來包含構建、發布和佈署微服務的命令。使用 shell 指令碼可以為我們的佈署建立一個框架或腳手架，使得在本地測試和確保它的工作之前將其移至雲端變得更加容易。shell 指令碼還給了我們一種方式來測試我們的佈署程式碼，以便在未來對其進行修改時進行除錯。

如果您直接嘗試在 GitHub Actions 中執行這些命令，您可能會遇到問題，而這些問題如果您先在本地執行就會更容易除錯和解決。因此，在生產環境中執行程式碼之前先在本地執行它可以使我們更加有效。

8.9 持續佈署

要將程式碼佈署到生產環境，我們需要有一個目標環境。由於我們最終希望在 GitHub Actions 中執行佈署程式碼，因此我們不能使用本地 Kubernetes 例項（在 Docker Desktop 中）。此時，我們需要一個雲端中的 Kubernetes 叢集。我們還需要一個容器登入。如果您正在為一家科技公司工作，您可能已經有多個生產或生產類別似環境可供使用。但是在任何情況下，如第 6 章所示，建立自己的 Kubernetes 叢集以進行學習、測試和實驗是相當容易的。

現在，請確保您有一個 Kubernetes 叢集（第 6 章或第 7 章）和一個容器登入（第 3 章或第 7 章）可供使用。您需要知道每個叢集和登入的詳細訊息，包括容器登入的 URL 和使用者名和密碼。您還需要知道如何使用 kubectl 認證您的 Kubernetes 叢集，但我們稍後會再次涵蓋這一點。

建立和發布映像的 shell 指令碼

讓我們現在建立 shell 指令碼來編碼構建和發布映像的命令，如第 3 章所示。清單 8.4（從 chapter-8-example-3 專案中的 scripts/build-image.sh 提取）是我們需要建立的三個 shell 指令碼中的第一個，用於為微服務建立持續佈署管道。

將佈署過程分成三個獨立部分是有意義的：第一部分用於構建映像，第二部分用於發布映像，第三部分用於將微服務佈署到 Kubernetes。當然，我們可以將所有這些結合成一個大型 shell 指令碼，但將其分成三個使得每個指令碼都變得更小、更容易獨立測試。這也是分工的一種好方法。稍後，當我們的持續佈署管道出現問題時，除錯會更容易，因為很明顯問題出現在哪個階段（哪個 shell 指令碼）。

清單 8.4 中的 shell 指令碼封裝了構建微服務映像的命令。作為輸入，它接受我們已經看到的環境變數：CONTAINER_REGISTRY 和 VERSION。這些用於標記映像以發布到登入中，並設定映像版本號。

docker build -t $CONTAINER_REGISTRY/video-streaming:$VERSION --file./Dockerfile-prod.

現在，讓我們在本地測試第一個 shell 指令碼。如果您尚未這樣做，請在終端機中設定以下環境變數（在 Windows 中，請在 WSL2 下開啟 Linux 終端機）：

export CONTAINER_REGISTRY=<您的容器登入網址>
export VERSION=1

清單 8.4：構建映像的 shell 指令碼

構建映像並標記…

內容解密：

上述 shell 指令碼使用 docker build 命令構建映像，並使用 CONTAINER_REGISTRY 和 VERSION 環境變數標記映像。這使得我們可以輕鬆地控制映像的版本號和發布位置。

圖表翻譯：

  graph LR
    A[設定環境變數] --> B[構建映像]
    B --> C[標記映像]
    C --> D[發布映像]

圖表描述了構建和發布映像的流程，從設定環境變數開始，然後構建映像，標記映像，最後發布映像。

持續佈署的實踐

在實踐持續佈署的過程中，我們需要關注環境變數的設定。為了完成這個過程，我們首先需要進入目錄 chapter-8-example-3，然後執行 shell 指令碼 build-image.sh。這個指令碼負責構建映象，以便它可以被發布。

cd chapter-8-example-3
./scripts/build-image.sh

構建完成後，我們可以使用 docker image list 來檢查映象是否已經在本地可用。接下來，我們需要將映象發布到容器登入函式庫中。為了做到這一點，我們需要設定環境變數 REGISTRY_UN 和 REGISTRY_PW，它們分別代表用於驗證的使用者名稱和密碼。

export REGISTRY_UN=<registry-username>
export REGISTRY_PW=<registry-password>

然後，我們可以執行 shell 指令碼 push-image.sh 來發布映象到容器登入函式庫中。

./scripts/push-image.sh

發布完成後，我們可以使用 Kubernetes 組態檔案來佈署微服務。為了實作這一點，我們需要使用 envsubst 來填充組態檔案中的引數，然後使用 kubectl 來佈署微服務。

envsubst <./scripts/kubernetes/deploy.yaml | kubectl apply -f -

這個過程可以透過執行 shell 指令碼 deploy.sh 來自動完成。

./scripts/deploy.sh

完成佈署後，我們可以透過 GitHub Actions 來實作自動化的持續佈署。但是在此之前，我們應該清理叢集並刪除測試佈署。為了做到這一點，我們可以使用 shell 指令碼 delete.sh。

./scripts/delete.sh

這個指令碼會刪除微服務的佈署，從而幫助我們保持叢集的清潔和簡潔。

圖表翻譯：

  graph LR
    A[構建映象] --> B[發布映象]
    B --> C[佈署微服務]
    C --> D[清理叢集]

這個流程圖描述了從構建映象到佈署微服務，再到清理叢集的整個過程。每一步驟都對應著特定的 shell 指令碼和操作，幫助我們實作自動化的持續佈署。

自動化佈署微服務的工作流程

現在，我們已經建立和測試了佈署用的 Shell 指令碼，可以從 GitHub Actions 工作流程中呼叫它們。檢視清單 8.7（章節 8 示例 3/.github/workflows/deploy.yaml），您可以看到如何順序執行每個 Shell 指令碼。

此過程（執行三個 Shell 指令碼）與我們在本地所做的相同，除了透過玄貓的魔力，我們的佈署現在將在每次向 GitHub 推播程式碼變更時自動發生。每當我們修改程式碼時，GitHub 將分配一個執行器為我們進行佈署。不再需要手動佈署了，謝謝你！今天真是美好的一天！

以下是工作流程定義：

name: 佈署微服務
on:
  push:
    branches:
      - main
  workflow_dispatch:
jobs:
  佈署:
    runs-on: ubuntu-latest
    env:
      版本: ${{ github.sha }}
      容器登錄檔: 
      登錄檔使用者名稱: ${{ secrets.登錄檔使用者名稱 }}
      登錄檔密碼: ${{ secrets.登錄檔密碼 }}
    步驟:
      - 使用: actions/checkout@v3
      - 名稱: 建立
        執行:./scripts/建立映像檔.sh
      - 名稱: 釋出
        執行:./scripts/推播映像檔.sh
      - 使用: tale/kubectl-action@v1
        with:
          base64-kube-config: 
          ${ secrets.KUBE_CONFIG }
          kubectl-version: v1.24.2
      - 名稱: 佈署
        執行:./scripts/佈署.sh

清單 8.7 中有兩個關鍵元素需要理解：

  • 如何在工作流程中安裝和驗證 kubectl
  • 如何設定環境變數（傳遞給 Shell 指令碼的輸入）

讓我們逐一介紹這些專案。

安裝和驗證 kubectl

在工作流程中，我們使用 tale/kubectl-action 來安裝和驗證 kubectl。這個動作會下載和安裝指定版本的 kubectl，並使用提供的 Kubernetes 組態檔案進行驗證。

設定環境變數

在工作流程中，我們設定了幾個環境變數，包括 VERSION、CONTAINER_REGISTRY、REGISTRY_UN 和 REGISTRY_PW。這些變數用於傳遞給 Shell 指令碼，提供必要的輸入引數。

透過這個工作流程，我們可以自動化微服務的佈署過程，無需手動干預。每次推播程式碼變更時，GitHub Actions 都會自動執行工作流程，完成佈署任務。

自動化佈署流程

在 GitHub Actions 中，可以手動觸釋出署過程。這個過程包括了多個步驟，以下是詳細的解釋：

玄貓風格技術文章結論：GitHub Actions 自動化佈署

從 DevOps 工程師的日常工作來看，持續整合和持續佈署（CI/CD）已成為不可或缺的環節。GitHub Actions 作為原生整合的 CI/CD 解決方案，展現出其便捷性和強大功能。本文深入探討了從建立簡單工作流程到實作自動化佈署 Kubernetes 微服務的完整流程，涵蓋了 YAML 組態檔案撰寫、多行命令執行、環境變數設定、envsubst 的妙用以及 Shell 指令碼的整合等關鍵技術。

透過多個例項分析，我們可以看到 GitHub Actions 如何簡化 CI/CD 管線的構建。其原生整合的特性大幅降低了組態和管理成本，同時提供了豐富的預設動作和社群資源，加速了開發團隊的自動化行程。然而，GitHub Actions 也存在一些限制，例如對於複雜場景的客製化組態可能需要更深入的 YAML 語法理解，以及對於私有程式碼倉函式庫的計費模式需要仔細評估。

展望未來，隨著雲原生技術的蓬勃發展，GitHub Actions 與 Kubernetes 的整合將更加緊密。預計未來會出現更多針對特定應用場景的預設動作和工具，進一步降低 CI/CD 的門檻。同時，安全性考量也將日益受到重視，例如 secrets 管理和漏洞掃描等功能的強化。

玄貓認為，GitHub Actions 對於追求快速迭代和高效佈署的團隊而言，是一個值得投資的 CI/CD 工具。尤其對於已經使用 GitHub 進行程式碼管理的團隊，其無縫整合的優勢更為明顯。建議團隊成員積極探索 GitHub Actions 的豐富功能，並結合自身業務需求，打造最佳的自動化佈署流程。

玄貓

玄貓

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