在 IT 領域,自動化無疑已成為提高工作效率和減少人為錯誤的關鍵。Sealos 作為一個強大的雲作業系統,已經為許多企業和開發者提供了穩定可靠的服務。與此同時,隨著技術不斷髮展,整合更多的功能和服務變得尤為重要。考慮到這一點,本文將介紹如何利用 GitHub Action 來進一步豐富 Sealos 在應用更新方面的自動化體驗。
在現代軟體開發中,持續整合 (CI) 和持續部署/交付 (CD) 是至關重要的環節。它們可以幫助開發團隊高效地驗證程式碼的質量並確保其準確無誤地交付到生產環境中。GitHub Action 正是在這個背景下誕生的 CI/CD 工具,致力於為開發者提供一種簡潔且高效的自動化工具。
簡單來說,GitHub Action 是一個 CI/CD 工具,它允許開發者在 GitHub 倉庫中自動執行多種任務,從而極大地提高了工作效率。它可以自動進行程式碼的構建、測試和部署等關鍵步驟,確保在每次程式碼更新或合併請求中都能夠進行快速而準確的驗證和交付。
但 GitHub Action 不僅僅是一個傳統的 CI/CD 工具。其獨特之處在於,它與 GitHub 倉庫實現了無縫整合。這意味著開發者無需離開 GitHub 環境,就能夠設定和管理整個自動化流程,極大地簡化了操作過程。此外,由於 GitHub 是目前世界上最大的程式碼託管平臺,這種深度整合使得大量開發者能夠輕鬆上手並利用 GitHub Action 進行自動化操作。
Sealos 的視覺化桌面環境極大簡化了使用者對分散式應用的管理和維護,使用者不再需要進行復雜的操作或擁有深厚的技術背景就能輕鬆管理分散式應用。通過減少複雜性和提供直觀的介面,Sealos 顯著地降低了使用者的心智負擔,使其可以更加集中地完成工作。
Sealos 海外叢集:https://cloud.sealos.io
Sealos 國內叢集:https://cloud.sealos.top
但 Sealos 不僅僅適用於普通使用者,對於雲原生領域的專業人員,提供了終端,您可以在終端中執行各種命令列操作。
同時還提供了 kubeconfig 檔案的下載功能。擁有這個檔案,專業人員可以將其下載到本地電腦,並使用 kubectl 命令列工具來直接管理和操作 Sealos 中的應用資源。這為那些希望深入管理和設定的雲原生專家們提供了極大的靈活性。
有了 kubeconfig 之後,我們可以用來實現各種神奇的功能,比如本文將要介紹的自動更新應用映象。
對於自己開發的應用,要想自動更新應用的映象,前提是得先自動構建映象。
GitHub Action 完美整合在 GitHub 平臺上,無需額外設定或切換到其他平臺即可基於原始碼來構建映象。對於公開的倉庫,GitHub 提供了一定的免費計算額度,適合小型專案或個人開發者。
使用 GitHub Action 自動構建並推播映象的流程如下:
建立工作流檔案:在你的 GitHub 倉庫中建立一個 .github/workflows
目錄,並在該目錄下建立一個工作流組態檔,例如 docker_build.yml
。
設定 Secret:為了安全地推播映象到 Docker Hub 和 ghcr.io,你需要在 GitHub 倉庫的 "Secrets" 部分設定相應的認證資訊。通常,這包括你的 Docker Hub 使用者名稱、密碼,以及 ghcr.io 的 token。例如:
編寫工作流指令碼:在組態檔中,定義所需的觸發條件(如 push
到 master
分支)、執行環境以及執行的命令。
範例:
# 定義工作流的名稱
name: Build and Push Docker Image
# 定義觸發工作流的條件
on:
workflow_dispatch: # 允許手動觸發工作流
push: # 當有程式碼推播事件發生時
branches:
- master # 只有推播到 master 分支時才觸發
# 定義工作流的任務
jobs:
build-image:
# 定義執行此任務的環境:最新版本的 ubuntu
runs-on: ubuntu-latest
# 定義任務中的步驟
steps:
# 檢出程式碼。只檢出最新的1次提交
- uses: actions/checkout@v3
with:
fetch-depth: 1
# 設定 QEMU 模擬器,這通常用於多平臺的 Docker 構建
- name: Set up QEMU
uses: docker/setup-qemu-action@v2
# 設定 Docker Buildx,用於構建多平臺的 Docker 映象
- name: Set up Docker Buildx
uses: docker/setup-buildx-action@v2
# 登入到 Docker Hub
- name: Login to DockerHub
uses: docker/login-action@v2
with:
username: ${{ secrets.DOCKER_USERNAME }} # 使用儲存在 GitHub Secrets 中的 DockerHub 使用者名稱
password: ${{ secrets.DOCKER_PASSWORD }} # 使用儲存在 GitHub Secrets 中的 DockerHub 密碼
# 登入到 ghcr.io (GitHub Container Registry)
- name: Login to ghcr.io
uses: docker/login-action@v2
with:
registry: ghcr.io
username: ${{ github.repository_owner }} # 使用倉庫的擁有者名作為使用者名稱
password: ${{ secrets.GHCR_TOKEN }} # 使用儲存在 GitHub Secrets 中的 ghcr.io 的存取令牌
# 構建並推播 Docker 映象到 docker.io 和 ghcr.io
- name: Build and push Docker images to docker.io and ghcr.io
uses: docker/build-push-action@v2
with:
platforms: linux/amd64 # 設定構建平臺為 linux/amd64
context: . # Docker 構建上下文設定為當前目錄
push: true # 設定為真以確保構建後的映象被推播
tags: | # 定義推播的標籤
${{ secrets.DOCKER_USERNAME }}/xxxx:latest
ghcr.io/${{ github.repository_owner }}/xxxx:latest
觸發工作流:每當符合觸發條件的事件發生時,GitHub Action 就會自動執行定義的工作流,從而構建和推播 Docker 映象。
監控與偵錯:你可以在 GitHub 倉庫的 "Actions" 分頁中,檢視工作流的執行情況,包括紀錄檔、狀態和結果。
使用 GitHub Action 自動構建映象不僅可以簡化開發流程,還可以確保每次程式碼的更改都得到了有效且一致的處理,大大提高了開發效率和程式碼質量。同時通過使用 GitHub 的 secrets 功能,還確保了認證資訊的安全。
現在我們來到了最後一步。要想自動更新映象,首先我們來回顧一下整個流程:
首先,當你的應用程式碼更新併合併到主分支時,GitHub Action 會自動觸發構建映象的任務。構建完成後,新的應用映象會被推播到映象倉庫。
接下來,你需要在 GitHub Action 中呼叫 kubectl,更新 Sealos 叢集中對應的 Deployment 或 StatefulSet。這樣,Sealos 叢集的應用就會使用新的映象版本進行卷動更新。
我們可以利用一個特定的 GitHub Action:actions-hub/kubectl
。這個 Action 提供了在 GitHub Actions 工作流中執行 kubectl
命令的能力。
以下是如何在你的 GitHub Actions 工作流中使用 actions-hub/kubectl
來更新 Sealos 應用映象:
為了讓 kubectl
能夠與你的 Sealos 或其他 Kubernetes 叢集進行通訊,你需要提供一個有效的 Kubeconfig,Sealos 的 kubeconfig 可以在桌面中下載。
下載完成後,你需要將其中的內容轉換為 base64 格式:
$ cat kubeconfig.yaml | base64
然後將轉換後的內容儲存到 GitHub 倉庫的 Secret 中,假設 Secret 名為 KUBE_CONFIG
。Secret 設定方式參考上文。
現在您只需要在前面自動構建映象的工作流指令碼中新增一個新的 job 來呼叫 kubectl 即可。例如:
# 定義工作流的名稱
name: Build and Push Docker Image
# 定義觸發工作流的條件
on:
workflow_dispatch: # 允許手動觸發工作流
push: # 當有程式碼推播事件發生時
branches:
- master # 只有推播到 master 分支時才觸發
# 定義工作流的任務
jobs:
build-image:
...
...
deploy:
needs: build-image
runs-on: ubuntu-latest
if: github.repository == '<your_repository>'
steps:
- name: Checkout code
uses: actions/checkout@v3
- uses: actions-hub/kubectl@master
env:
KUBE_CONFIG: ${{ secrets.KUBE_CONFIG }}
with:
args: rollout restart deployment my-deployment
在這個例子中,我們更新一個名為 my-deployment
的 Deployment,更新的方法非常簡單:直接捲動重啟。因為 Deployment 的 imagePullPolicy
預設都是 Always,且映象 tag 保持 latest 不變,所以直接重啟就會拉取最新的映象。
如果您的映象每次構建的 tag 都不同,那可以使用這個命令來更新映象:
...
with:
args: set image deployment/my-deployment my-container=my-repo/my-image:<tag>
在這個例子中,我們更新一個名為 my-deployment
的 Deployment,將 my-container
的映象設定為 my-repo/my-image:<tag>
。其中 tag 可以通過環境變數的形式從構建映象的 job 中獲取。
如果您的應用不是自己開發的,且這個應用已提供了映象,那麼您可以設計一個定時觸發的工作流,工作流的任務是檢測映象倉庫(例如 Docker Hub)的映象有沒有更新,如果更新了,就呼叫 kubectl 來更新映象。