Kubernetes 自動化佈署實戰：GitHub Actions 與 CI/CD

– 16 分鐘閱讀

在現代軟體開發流程中，持續整合與持續佈署（CI/CD）至關重要。本文將探討如何結合 GitHub Actions 和 Kubernetes，打造自動化的微服務佈署Pipeline。從基礎設施即程式碼（IaC）出發，利用 Terraform 建立和管理 Kubernetes 叢集，再整合 GitHub Actions，實作程式碼更新後自動觸發建置、測試及佈署流程，最終將微服務容器化佈署至 Kubernetes。此流程不僅提升佈署效率，也確保軟體交付的穩定性和可靠性，讓開發團隊更專注於產品功能開發。

7.15 繼續學習

在本章中，我們使用 Terraform 和基礎設施即程式碼（Infrastructure as Code, IaC）技術來建立根據 Kubernetes 的生產環境。但是，還有很多東西需要學習關於 IaC 和 Terraform，因此以下是一些書籍，如果您想更深入地探索：

  • 《Terraform 實戰》作者：玄貓（Manning, 2021）
  • 《Terraform 深度剖析》作者：玄貓（Manning, 預計 2024 年春季）
  • 《基礎設施即程式碼：模式和實踐》作者：玄貓（Manning, 2022） 此外，最佳的資源是 Terraform 檔案。我建議您從他們的網站開始，並點選教程和檔案。作為一個練習，嘗試找到並學習更多關於本章中使用的 Terraform 資源。

摘要

  • 基礎設施即程式碼是一種技術，其中我們將基礎設施組態儲存為程式碼。編輯和執行該程式碼是我們更新基礎設施的方式。
  • Terraform 是一個工具和語言，用於透過程式碼建立雲端資源和應用程式基礎設施。
  • 寫作建立基礎設施的程式碼與寫作最終要在生產環境中執行的程式碼並不不同，除了，即使我們可以在本地開發電腦上執行 Terraform 程式碼，但結果始終出現在雲端中。
  • Terraform 允許我們逐步建立基礎設施，這被稱為演化式架構。
  • Terraform 由玄貓提供動力，這意味著它可以用於在所有主要雲端平臺上建立基礎設施：AWS、GCP、Azure 等。
  • Terraform 必須在使用前初始化，我們應該修復提供者版本號以避免令人厭惡的驚喜。
  • Terraform 專案是使用 terraform init 初始化的。

表 7.2 Terraform 命令複習

命令描述
terraform init初始化 Terraform 專案並下載提供者外掛
terraform apply -auto-approve執行工作目錄中的 Terraform 程式碼檔案以遞增方式更新基礎設施

持續佈署

在本章中，我們將收穫前兩章工作的成果。在第6章和第7章中，您學習瞭如何使用程式碼建立基礎設施以及如何手動佈署微服務到該基礎設施。在本章中，您將學習如何自動化佈署。重要的是，您將學習如何使用GitHub Actions建立微服務的自動化、持續佈署管道。這種自動化將成為您在微服務上取得成功的關鍵部分。為了簡化事物，我們將專注於佈署單個微服務，但這將給我們一個可以應用於所有微服務的配方。

使用GitHub Actions建立自動化工作流程

GitHub Actions是一個根據GitHub的服務，根據程式碼倉函式庫中的動作執行自動化工作流程。在本章中，我們將使用GitHub Actions在程式碼倉函式庫的主分支中更新程式碼時自動測試和佈署程式碼。

取得程式碼

本章的示例程式碼與本章其他章節的程式碼結構不同。前幾章的示例程式碼位於同一位置，而本章中的每個示例都包含在其自己的單獨程式碼倉函式庫中。這樣做是為了使您容易fork程式碼倉函式庫並自己嘗試使用GitHub Actions進行每個示例。如果您不熟悉fork程式碼倉函式庫，請不要擔心，指示將會出現。

本章介紹了三個示例專案，從example-1開始，然後是example-2，最後是example-3。如需安裝和使用Git克隆程式碼倉函式庫的幫助，請參閱第2章。如果您遇到程式碼問題，請在GitHub中對相應的程式碼倉函式庫提出問題。

執行本章的示例

執行本章示例專案的程式碼與之前的每個章節都不同。到目前為止，每個章節都在我們的個人開發電腦上執行程式碼。然而，當我們執行自動化佈署管道（如本章中的示例）時，我們的程式碼將在雲端執行。

工具版本和目的

工具版本目的
GitHub Actions-執行自動化工作流程

建立CI管道以執行微服務的自動化測試

我們將使用GitHub Actions建立一個CI管道，以執行微服務的自動化測試。這個管道將在我們更新程式碼時自動執行測試，以確保我們的微服務是穩定和功能正常的。

建立自動化佈署管道以佈署微服務到Kubernetes

接下來，我們將使用GitHub Actions建立一個自動化佈署管道，以佈署微服務到Kubernetes。這個管道將在我們更新程式碼時自動佈署微服務，讓我們可以快速和輕鬆地交付變更給使用者。

圖表翻譯：

  graph LR
    A[更新程式碼] --> B[執行自動化測試]
    B --> C[佈署微服務到Kubernetes]
    C --> D[交付變更給使用者]

這個圖表展示了我們使用GitHub Actions建立的自動化工作流程。當我們更新程式碼時，GitHub Actions將執行自動化測試，以確保我們的微服務是穩定和功能正常的。如果測試透過，GitHub Actions將自動佈署微服務到Kubernetes，讓我們可以快速和輕鬆地交付變更給使用者。

持續整合與持續佈署

什麼是持續整合？

在深入探討持續佈署（CD）之前，我們先來瞭解什麼是持續整合（CI）。CI是一種自動化的流程，當程式碼有變更時，會自動執行各種檢查和測試，以確保程式碼仍然能正常運作。通常，CI流程包括編譯程式碼、執行lint工具以及自動化測試。自動化測試是CI流程中最重要的部分，因為它能夠快速地發現程式碼中的問題。

CI流程的工作原理

當多個開發人員共同合作於一個程式碼函式庫時，CI流程就變得非常重要。它可以自動地檢查整合後的程式碼是否仍然能正常運作。當開發人員提交程式碼變更到GitHub時，CI流程就會被觸發，自動執行各種檢查和測試。如果所有測試都透過，則該次CI流程被標記為成功；如果有任何測試失敗，則被標記為失敗，並通常會傳送電子郵件通知團隊成員。

什麼是持續佈署？

持續佈署（CD）是一種技術，透過頻繁的自動化佈署將程式碼更新到生產環境。簡單來說，就是當程式碼有更新時，自動觸發新的佈署。CD流程建立在CI流程之上，增加了額外的步驟將程式碼佈署到生產環境。

自動化佈署的重要性

要實作自動化佈署，我們需要撰寫能夠自動執行的佈署程式碼，並確保它能夠在雲端環境中無人干預地執行。這些佈署程式碼必須盡可能可靠，並進行徹底的測試，以確保它們不會在生產環境中失敗。當佈署程式碼在生產環境中失敗時，除錯將更加困難，因為它是在雲端執行，而不是在本地機器上。

內容解密：

上述段落介紹了持續整合（CI）和持續佈署（CD）的基本概念。CI是一種自動化流程，用於檢查程式碼變更並確保它們不會破壞現有的功能。CD則是在CI的基礎上，增加了自動化佈署到生產環境的步驟。這兩種技術都非常重要，因為它們能夠幫助開發團隊快速、可靠地交付軟體更新。

  flowchart TD
    A[程式碼變更] --> B[CI流程]
    B --> C[自動化測試]
    C --> D[檢查結果]
    D --> E[成功或失敗]
    E --> F[通知團隊]
    F --> G[修正錯誤]

圖表翻譯：

此圖表展示了CI流程的工作原理。當程式碼有變更時，CI流程被觸發，執行自動化測試和檢查。如果所有測試透過，則該次CI流程被標記為成功；如果有任何測試失敗，則被標記為失敗，並通知團隊成員進行修正。

實踐CI/CD

要實踐CI/CD，首先需要建立一個GitHub帳戶，如果尚未擁有。接下來，fork一個示例程式碼函式庫，以便您可以嘗試使用GitHub Actions。然後，啟用該forked函式庫中的工作流程，以便您可以觸發自動化工作流程。

  flowchart TD
    A[建立GitHub帳戶] --> B[Fork示例程式碼函式庫]
    B --> C[啟用工作流程]
    C --> D[觸發自動化工作流程]
    D --> E[檢視結果]

內容解密：

上述段落介紹瞭如何開始使用GitHub Actions實踐CI/CD。首先，需要建立一個GitHub帳戶，然後fork一個示例程式碼函式庫，以便您可以嘗試使用GitHub Actions。接下來，啟用該forked函式庫中的工作流程，以便您可以觸發自動化工作流程。

持續整合流程的運作

當開發人員將程式碼推播到儲存函式庫（repository）或提交提取請求（pull request）時，會觸發一系列的事件。這些事件會啟動持續整合（Continuous Integration，CI）的流程。CI 流程是一種自動化的工作流程，負責將多個開發人員的程式碼整合到一起，並執行自動化測試和其他檢查，以確保程式碼的正確性和穩定性。

持續整合流程的步驟

在 CI 流程中，程式碼會經過多個階段的檢查和測試。首先，程式碼會被整合到一起，然後會執行自動化測試，包括單元測試、整合測試和功能測試等。這些測試可以幫助開發人員快速地發現程式碼中的錯誤和問題。

持續整合流程的優點

持續整合流程有很多優點。首先，它可以幫助開發人員快速地發現和修復錯誤，從而提高程式碼的品質和穩定性。其次，它可以自動化很多重複性的工作，例如程式碼的編譯和測試，從而節省開發人員的時間和精力。最後，它可以幫助開發團隊更好地合作和溝通，從而提高團隊的生產力和效率。

圖表翻譯：

  graph LR
    A[程式碼推播] --> B[CI 流程啟動]
    B --> C[自動化測試]
    C --> D[程式碼整合]
    D --> E[錯誤檢查和修復]

上述圖表展示了持續整合流程的基本步驟。當程式碼被推播到儲存函式庫時，CI 流程會被啟動，然後會執行自動化測試和程式碼整合。最後，會進行錯誤檢查和修復，以確保程式碼的正確性和穩定性。

內容解密：

持續整合流程是一種自動化的工作流程，負責將多個開發人員的程式碼整合到一起，並執行自動化測試和其他檢查，以確保程式碼的正確性和穩定性。在這個流程中，程式碼會經過多個階段的檢查和測試，包括單元測試、整合測試和功能測試等。這些測試可以幫助開發人員快速地發現程式碼中的錯誤和問題，並且可以自動化很多重複性的工作，例如程式碼的編譯和測試。

持續佈署的概念與實踐

持續佈署（Continuous Deployment，CD）是一種軟體開發方法，旨在自動化佈署流程，以便在程式碼變更後立即將其佈署到生產環境。這個過程通常涉及自動化測試、構建和佈署，以確保軟體的品質和穩定性。

持續佈署的工作原理

當開發人員提交程式碼變更到版本控制系統（如 Git）後，持續佈署流程就會被觸發。這個流程包括以下步驟：

  1. 自動化測試：執行自動化測試以確保程式碼變更沒有引入錯誤或 bug。
  2. 構建：構建軟體以準備佈署。
  3. 佈署：將軟體佈署到生產環境。

如果任何一步驟失敗，持續佈署流程就會被中止，開發人員會收到通知以便進行修復。

持續佈署與持續交付的區別

持續交付（Continuous Delivery，CD）和持續佈署（Continuous Deployment，CD）這兩個術語經常被混淆。然而，它們之間存在著微妙的差異：

  • 持續交付：自動化構建、測試和佈署流程，以便在程式碼變更後快速將其交付給客戶。
  • 持續佈署：自動化佈署流程，以便在程式碼變更後立即將其佈署到生產環境。

實踐持續佈署

要實踐持續佈署，需要使用工具如 Docker、Kubernetes 和 GitHub Actions 等。以下是實踐持續佈署的一個簡單示例：

  1. 建立 Docker 映像：使用 Dockerfile 建立一個 Docker 映像，以便包含軟體的所有依賴項。
  2. 建立 Kubernetes 佈署：使用 Kubernetes 的 YAML 檔案建立一個佈署，以便定義軟體的佈署組態。
  3. 設定 GitHub Actions：設定 GitHub Actions 以便在程式碼變更後自動觸發持續佈署流程。
內容解密：

上述內容介紹了持續佈署的概念和實踐方法。以下是關於上述內容的詳細解說：

  • 持續佈署的工作原理：持續佈署流程包括自動化測試、構建和佈署等步驟。
  • 持續交付與持續佈署的區別：持續交付著重於自動化構建、測試和佈署流程，而持續佈署著重於自動化佈署流程。
  • 實踐持續佈署：需要使用工具如 Docker、Kubernetes 和 GitHub Actions 等，以便建立一個自動化的佈署流程。

圖表翻譯：

以下是上述內容的視覺化圖表：

  graph LR
    A[程式碼變更] --> B[自動化測試]
    B --> C[構建]
    C --> D[佈署]
    D --> E[生產環境]

上述圖表展示了持續佈署流程的各個步驟，從程式碼變更到自動化測試、構建和佈署，最終將軟體佈署到生產環境。

自動化佈署流程

在軟體開發的過程中，自動化佈署流程是一個非常重要的環節。它可以幫助我們快速、可靠地將新版本的微服務佈署到生產環境中。下面，我們來探討一下自動化佈署流程的工作原理和實作方式。

自動化佈署的優點

自動化佈署可以帶來許多優點，包括：

  • 加快佈署速度：自動化佈署可以快速地將新版本的微服務佈署到生產環境中，減少了手動佈署的時間和風險。
  • 提高可靠性：自動化佈署可以確保每次佈署都按照相同的流程進行，減少了人為錯誤的可能性。
  • 增強安全性：自動化佈署可以透過自動化的方式來確保佈署過程的安全性，例如，可以自動地更新依賴函式庫和組態檔案。

自動化佈署的實作方式

自動化佈署可以透過多種方式來實作，包括：

  • 使用CI/CD工具：CI/CD工具（例如Jenkins、GitLab CI/CD、CircleCI等）可以幫助我們自動化佈署流程。這些工具可以監控程式碼函式庫的變化，並在程式碼發生變化時自動觸釋出署流程。
  • 使用容器化技術：容器化技術（例如Docker）可以幫助我們將微服務封裝成容器，並自動地佈署到生產環境中。
  • 使用Kubernetes：Kubernetes是一種容器協調系統，可以幫助我們自動地管理和佈署容器化的微服務。

實際案例

下面，我們來看一個實際案例。假設我們有一個微服務，使用Docker容器化，並使用Kubernetes進行協調。當我們提交程式碼變化到程式碼函式庫時，CI/CD工具會自動觸釋出署流程。佈署流程會將新版本的微服務封裝成Docker容器，並使用Kubernetes將其佈署到生產環境中。

  flowchart TD
    A[程式碼提交] --> B[CI/CD工具]
    B --> C[封裝Docker容器]
    C --> D[Kubernetes佈署]
    D --> E[生產環境]

內容解密：

上述流程圖展示了自動化佈署流程的工作原理。當程式碼提交到程式碼函式庫時，CI/CD工具會自動觸釋出署流程。佈署流程會將新版本的微服務封裝成Docker容器，並使用Kubernetes將其佈署到生產環境中。

圖表翻譯：

此圖表展示了自動化佈署流程的工作原理。圖表從左到右展示了程式碼提交、CI/CD工具、封裝Docker容器、Kubernetes佈署和生產環境等步驟。每個步驟都代表了自動化佈署流程中的一個環節。

8.6 自動化佈署的重要性

自動化佈署是一種能夠為我們帶來許多好處的技術。首先，手動佈署是非常枯燥和耗時的，並且每次手動佈署都存在錯誤的風險。自動化佈署可以幫助我們減少時間和風險。其次，自動化佈署可以建立一個交付產品功能給客戶的管道，讓我們可以快速地做出改變並獲得快速的反饋。最後，當佈署是自動化、可靠和回應迅速的時候，它就像是一種魔術一般地融入背景中，使我們可以專注於交付有用的功能給客戶，而不會被煩瑣的佈署過程分散注意力。

此外，自動化佈署還可以提供一個佈署記錄，記錄了什麼改變、為什麼改變以及誰觸發了佈署。這些記錄對於追蹤和管理佈署非常重要。

8.7 GitHub Actions 簡介

GitHub Actions 是一種自動化工作流程的工具，可以幫助我們建立自動化的佈署管道。使用 GitHub Actions，我們可以定義一系列任務，這些任務可以在程式碼倉函式庫中觸發特定事件時執行，例如推播程式碼或提交提取請求。

GitHub Actions 的工作流程是使用 YAML 檔案定義的，工作流程由多個任務組成，每個任務可以執行一系列命令或指令碼。工作流程可以由多種事件觸發，例如程式碼推播或提取請求提交。

8.7.1 為什麼選擇 GitHub Actions

GitHub Actions 是一種很好的自動化工作流程工具，因為它與 GitHub 程式碼倉函式庫緊密整合，允許我們的程式碼和自動化管道並存。這使得觸發自動化工作流程從程式碼倉函式庫事件變得很容易。另外，GitHub Actions 還提供了很多擴充套件功能，讓我們可以根據需要定製工作流程。

8.7.2 什麼是工作流程

工作流程是一系列任務的流程，任務之間按照特定的順序執行。這也基本上是我們所說的管道的意思，不過管道有一點不同的含義：管道是一種將工作程式碼交付到生產環境的管道。在 GitHub Actions 中，工作流程是實際上自動化管道的名稱。

8.7.3 建立新的工作流程

建立新的工作流程最簡單的方法是從 GitHub 程式碼倉函式庫開始。如果你之前已經 fork 了 chapter-8-example-1 程式碼倉函式庫，你可以導航到那裡並跟隨指示進行。

內容解密：

以上內容介紹了自動化佈署的重要性和 GitHub Actions 的簡介。自動化佈署可以幫助我們減少時間和風險，並提供一個交付產品功能給客戶的管道。GitHub Actions 是一種很好的自動化工作流程工具，可以幫助我們建立自動化的佈署管道。

圖表翻譯：

  graph LR
    A[程式碼倉函式庫] -->|觸發事件|> B[GitHub Actions]
    B -->|執行工作流程|> C[自動化佈署]
    C -->|交付程式碼|> D[生產環境]

這個圖表展示了程式碼倉函式庫、GitHub Actions 和自動化佈署之間的關係。當程式碼倉函式庫發生特定事件時，GitHub Actions 會被觸發，然後執行工作流程，最終實作自動化佈署。

自動化工作流程概述

自動化工作流程是指一系列的任務，按照預定的順序自動執行，以提高工作效率和減少人工干預。這些工作流程通常在雲端平臺或虛擬機器上執行，利用容器化技術來保證環境的一致性。

工作流程的組成

一個工作流程（Workflow）由多個任務（Job）組成，每個任務又包含多個步驟（Step）。每個步驟可以執行一個或多個命令、指令碼或程式。這種模組化的設計使得工作流程高度可定製和擴充套件。

工作流程的執行環境

工作流程通常在一個「執行器」（Runner）中執行，後者可能是一個容器（Container），執行在虛擬機器（Virtual Machine）上。這種架構提供了良好的隔離性和資源管理，確保不同工作流程之間不會相互幹擾。

工作流程的觸發

工作流程可以透過多種方式觸發，包括手動觸發、定時觸發、事件觸發等。例如，透過 GitHub Actions UI 手動觸發一個工作流程，或者設定工作流程在特定時間或事件發生時自動執行。

工作流程的結構

  • 工作流程（Workflow）：最高層級的工作單元，代表了一系列相關任務的集合。
  • 任務（Job）：工作流程中的一個獨立單元，包含一系列步驟。
  • 步驟（Step）：任務中的最小執行單元，可以是一個命令、指令碼或程式。
  graph LR
    A[工作流程] --> B[任務1]
    A --> C[任務2]
    B --> D[步驟1]
    B --> E[步驟2]
    C --> F[步驟3]
    C --> G[步驟4]

圖表翻譯：

上述Mermaid圖表展示了工作流程的結構。一個工作流程可以包含多個任務，每個任務又包含多個步驟。這種層次結構使得工作流程易於管理和維護。

什麼是 GitHub Actions？

GitHub Actions 是一個連續整合和連續佈署（CI/CD）的工具，允許開發人員自動化軟體建置、測試和佈署的流程。它提供了一個簡單的方式來定義工作流程，從而實作自動化的軟體交付。

GitHub Actions 的工作原理

當您將程式碼推播到 GitHub 時，GitHub Actions 會自動觸發工作流程。工作流程由一系列任務組成，每個任務都可以執行特定的動作，例如建置、測試和佈署程式碼。工作流程可以根據不同的事件觸發，例如程式碼推播、提取請求和問題建立。

GitHub Actions 作為 CI/CD 工具的興起，反映了開發流程自動化和雲原生技術的深度融合。透過多維比較分析，GitHub Actions 與 Jenkins、GitLab CI/CD 等傳統 CI/CD 工具相比，其與 GitHub 平臺的緊密整合、簡化的 YAML 組態以及豐富的開源 Actions 生態系統，都使其更具易用性和擴充套件性。然而，GitHub Actions 在處理複雜的Pipeline協調和私有化佈署方面仍存在一定的限制，這也是未來需要持續最佳化的方向。從技術演進預測來看，Serverless 計算和容器化技術的發展將進一步推動 CI/CD 工具的輕量化和彈性化，GitHub Actions 也將持續整合這些新技術，降低開發者使用門檻。玄貓認為，對於中小型團隊和開源專案而言，GitHub Actions 已展現出其強大的競爭力，值得優先考慮並深入學習。

玄貓

玄貓

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