雲原生容器化自動化：Tekton Pipeline 與 Buildah 整合實踐指南

– 16 分鐘閱讀

雲原生方法的核心在於自動化,特別是在 Kubernetes 環境中實現應用程式的持續整合與持續交付。Kubernetes 本身專注於容器協調與管理,並不內建容器建置機制,而是依賴如 Tekton 這類雲原生 CI/CD 框架與 Buildah 等容器建置工具來完成完整的自動化流程。本文將深入探討如何使用 Tekton 與 Buildah 實現從原始碼到容器映像,再到 Kubernetes 部署的完整自動化鏈路。

容器註冊表認證配置

認證機制的重要性

在容器化工作流程中,將建置完成的容器映像推播到容器註冊表是關鍵環節。無論使用公有雲提供的容器註冊服務如 Quay.io、Docker Hub、Google Container Registry,還是企業內部的私有註冊表如 Harbor、Artifactory,都需要適當的認證機制確保安全性。

容器註冊表認證與 Git 倉庫認證類似,都需要透過 Kubernetes Secret 儲存敏感資訊,並將 Secret 關聯到執行 Task 的 ServiceAccount。這種設計將認證資訊與 Task 定義分離,既提升了安全性,也增強了配置的靈活性。

建立容器註冊表 Secret

Kubernetes 提供了專門的 Secret 類型用於儲存容器註冊表認證資訊。

kubectl create secret docker-registry container-registry-secret \
  --docker-server=YOUR_REGISTRY_SERVER \
  --docker-username=YOUR_REGISTRY_USER \
  --docker-password=YOUR_REGISTRY_PASS

這個命令建立了 docker-registry 類型的 Secret。docker-server 參數指定註冊表的伺服器位址,例如 quay.io、gcr.io 或私有註冊表的 URL。docker-username 與 docker-password 提供認證憑證,建議使用服務帳號或機器人帳號的權杖,而非個人帳號密碼,以符合安全性最佳實踐。

驗證 Secret 建立成功可以查詢資源列表。

kubectl get secrets

輸出中應該能看到 container-registry-secret,其類型欄位顯示為 kubernetes.io/dockerconfigjson。這個類型專門用於儲存容器註冊表的認證資訊,Tekton 與 Kubernetes 會自動識別並使用。

配置 ServiceAccount

建立 Secret 後,需要將其關聯到 ServiceAccount,讓執行的 Task 能夠使用認證資訊。

kubectl create serviceaccount tekton-registry-sa

kubectl patch serviceaccount tekton-registry-sa \
  -p '{"secrets": [{"name": "container-registry-secret"}]}'

第一個命令建立專用的 ServiceAccount。第二個命令使用 patch 操作將 Secret 關聯到 ServiceAccount。當 Task 使用這個 ServiceAccount 執行時,Tekton 會自動配置容器註冊表認證,無需在 Task 定義中明確處理認證邏輯。

在實務應用中,建議為不同的用途建立專用的 ServiceAccount。例如,建置與推播映像的 ServiceAccount、部署應用的 ServiceAccount、管理基礎設施的 ServiceAccount 等。這種職責分離降低了安全風險,限制了潛在的權限濫用。

@startuml
!define DISABLE_LINK
!define PLANTUML_FORMAT svg
!theme _none_

skinparam dpi auto
skinparam shadowing false
skinparam linetype ortho
skinparam roundcorner 5
skinparam defaultFontName "Microsoft JhengHei UI"
skinparam defaultFontSize 16
skinparam minClassWidth 100

actor 管理員
participant "kubectl" as kubectl
participant "Kubernetes API" as api
participant "Secret" as secret
participant "ServiceAccount" as sa

管理員 -> kubectl : 建立 Secret
kubectl -> api : create secret docker-registry
api -> secret : 儲存認證資訊

管理員 -> kubectl : 建立 ServiceAccount
kubectl -> api : create serviceaccount
api -> sa : 建立資源

管理員 -> kubectl : 關聯 Secret
kubectl -> api : patch serviceaccount
api -> sa : 增加 Secret 參照
sa -> secret : 關聯認證

note right of secret
  儲存容器註冊表
  認證憑證
end note

note right of sa
  執行 Task 時
  自動使用認證
end note

@enduml

建立容器化 Task

多階段 Task 設計

容器化流程通常包含多個階段,從原始碼獲取、應用建置到容器映像建立與推播。將這些階段整合到單一 Task 中可以簡化 Pipeline 定義,同時確保執行的一致性。

以下展示一個完整的容器化 Task 定義。

apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
  name: build-push-app
spec:
  workspaces:
  - name: source
    description: Git 倉庫將被複製到此工作空間
  params:
  - name: contextDir
    description: 原始碼的上下文目錄
    default: quarkus
  - name: url
    description: Git 倉庫 URL
    default: https://github.com/gitops-cookbook/tekton-tutorial-greeter.git
  - name: revision
    description: Git 分支或標籤
    default: master
  - name: sslVerify
    description: Git SSL 驗證設定
    type: string
    default: "false"
  - name: tlsVerify
    description: 容器註冊表 TLS 驗證
    type: string
    default: "false"
  - name: storageDriver
    description: Buildah 儲存驅動
    type: string
    default: vfs
  - name: destinationImage
    description: 完整的容器映像名稱
    default: ""
  steps:
  - name: clone
    image: gcr.io/tekton-releases/github.com/tektoncd/pipeline/cmd/git-init:v0.21.0
    script: |
      CHECKOUT_DIR="$(workspaces.source.path)"
      
      cleandir() {
        if [[ -d "$CHECKOUT_DIR" ]]; then
          rm -rf "$CHECKOUT_DIR"/*
          rm -rf "$CHECKOUT_DIR"/.[!.]*
          rm -rf "$CHECKOUT_DIR"/..?*
        fi
      }
      
      cleandir
      
      /ko-app/git-init \
        -url "$(params.url)" \
        -revision "$(params.revision)" \
        -path "$CHECKOUT_DIR" \
        -sslVerify="$(params.sslVerify)"
      
      cd "$CHECKOUT_DIR"
      RESULT_SHA="$(git rev-parse HEAD)"
      echo "複製完成,提交雜湊: $RESULT_SHA"
  
  - name: build-sources
    image: gcr.io/cloud-builders/mvn
    command:
    - mvn
    args:
    - -DskipTests
    - clean
    - install
    env:
    - name: user.home
      value: /home/tekton
    workingDir: /workspace/source/$(params.contextDir)
  
  - name: build-and-push-image
    image: quay.io/buildah/stable
    script: |
      #!/usr/bin/env bash
      buildah --storage-driver=$STORAGE_DRIVER \
        --tls-verify=$(params.tlsVerify) \
        bud --layers -t $DESTINATION_IMAGE $CONTEXT_DIR
      
      buildah --storage-driver=$STORAGE_DRIVER \
        --tls-verify=$(params.tlsVerify) \
        push $DESTINATION_IMAGE docker://$DESTINATION_IMAGE
    env:
    - name: DESTINATION_IMAGE
      value: $(params.destinationImage)
    - name: CONTEXT_DIR
      value: /workspace/source/$(params.contextDir)
    - name: STORAGE_DRIVER
      value: $(params.storageDriver)
    workingDir: /workspace/source/$(params.contextDir)
    volumeMounts:
    - name: varlibc
      mountPath: /var/lib/containers
  
  volumes:
  - name: varlibc
    emptyDir: {}

這個 Task 展示了完整的容器化流程設計。workspaces 定義了儲存空間用於保存原始碼與建置產物。params 提供了豐富的配置選項,讓 Task 能夠適應不同的專案需求。

clone 步驟負責從 Git 倉庫獲取原始碼。使用 Tekton 官方提供的 git-init 工具,確保 Git 操作的標準化。cleandir 函式清理工作目錄,避免殘留檔案影響建置。完成後輸出提交雜湊值,便於追蹤與審計。

build-sources 步驟執行應用建置。這裡使用 Maven 建置 Java 應用,跳過測試以加速流程。對於其他技術棧,可以替換為相應的建置工具,例如 Node.js 使用 npm build、Go 使用 go build、Python 使用 pip install 等。

build-and-push-image 步驟使用 Buildah 建立容器映像。Buildah 是無需 Docker daemon 的容器建置工具,特別適合 Kubernetes 環境。使用 bud 命令建置映像,layers 選項啟用分層快取優化建置速度。push 命令將映像推播到註冊表,docker:// 前綴指定使用 Docker 註冊表協定。

volumeMounts 與 volumes 配置為 Buildah 提供必要的儲存空間。/var/lib/containers 是 Buildah 儲存容器資料的預設位置,掛載 emptyDir 提供臨時儲存。

Task 的靈活性設計

參數化是提升 Task 重用性的關鍵。透過定義豐富的參數,同一個 Task 可以適應多種場景。contextDir 參數支援單一倉庫包含多個應用的情況。storageDriver 參數讓 Task 能夠適應不同的儲存後端。tlsVerify 參數提供了安全性與靈活性的平衡選項。

在設計 Task 時,應該提供合理的預設值,讓簡單場景可以快速使用,同時保留客製化能力滿足複雜需求。參數描述應該清晰說明用途,便於團隊成員理解與使用。

部署 Task 到叢集使用標準的 kubectl 命令。

kubectl create -f build-push-app.yaml

執行容器化 Task

使用配置好的 ServiceAccount 執行 Task,確保認證資訊正確傳遞。

tkn task start build-push-app \
  --serviceaccount=tekton-registry-sa \
  --param url=https://github.com/gitops-cookbook/tekton-tutorial-greeter.git \
  --param destinationImage=quay.io/gitops-cookbook/tekton-greeter:latest \
  --param contextDir=quarkus \
  --workspace name=source,emptyDir="" \
  --use-param-defaults \
  --showlog

serviceaccount 參數指定使用 tekton-registry-sa,包含容器註冊表認證。param 參數覆寫 Task 的預設配置,指定具體的倉庫位置與目標映像。workspace 參數配置工作空間,這裡使用 emptyDir 提供臨時儲存。use-param-defaults 選項使用未明確指定參數的預設值,簡化命令。showlog 選項即時顯示執行日誌,便於追蹤進度與問題診斷。

執行過程中會看到三個階段的日誌輸出。clone 階段顯示 Git 複製進度,build-sources 階段顯示 Maven 建置訊息,build-and-push-image 階段顯示 Buildah 建置與推播過程。成功完成後,容器映像會出現在指定的註冊表中。

@startuml
!define PLANTUML_FORMAT svg
!theme _none_

skinparam dpi auto
skinparam shadowing false
skinparam linetype ortho
skinparam roundcorner 5
skinparam defaultFontName "Microsoft JhengHei UI"
skinparam defaultFontSize 16
skinparam minClassWidth 100

start

:clone 步驟;
note right
  複製 Git 倉庫
  清理工作目錄
  輸出提交雜湊
end note

:build-sources 步驟;
note right
  Maven 建置
  跳過測試
  生成產物
end note

:build-and-push-image 步驟;
note right
  Buildah 建置映像
  推播到註冊表
  使用認證資訊
end note

stop

@enduml

Kubernetes 部署自動化

建立 kubectl Task

在建置與推播容器映像後,下一步是將應用部署到 Kubernetes 叢集。建立一個通用的 kubectl Task 可以執行各種 Kubernetes 操作。

apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
  name: kubectl
spec:
  params:
  - name: SCRIPT
    description: kubectl CLI 命令腳本
    type: string
    default: kubectl help
  steps:
  - name: oc
    image: quay.io/openshift/origin-cli:latest
    script: |
      #!/usr/bin/env bash
      $(params.SCRIPT)

這個 Task 設計簡潔但功能強大。SCRIPT 參數接受任意 kubectl 命令,提供了極大的靈活性。使用 OpenShift CLI 映像而非官方 kubectl 映像,因為前者體積更小且包含額外的工具。

這種通用設計讓同一個 Task 可以執行多種操作,例如建立 Deployment、更新 ConfigMap、檢視 Pod 狀態、刪除資源等。在 Pipeline 中可以多次使用這個 Task,每次執行不同的命令。

部署 Task 使用標準命令。

kubectl create -f kubectl-task.yaml

配置部署權限

執行 Kubernetes 操作需要適當的權限。遵循最小權限原則,只授予必要的操作權限。

apiVersion: v1
kind: ServiceAccount
metadata:
  name: tekton-deployer-sa
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: task-role
rules:
- apiGroups: [""]
  resources: ["pods", "services", "endpoints", "configmaps", "secrets"]
  verbs: ["*"]
- apiGroups: ["apps"]
  resources: ["deployments", "replicasets"]
  verbs: ["*"]
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get"]
- apiGroups: ["apps"]
  resources: ["replicasets"]
  verbs: ["get"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: task-role-binding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: task-role
subjects:
- kind: ServiceAccount
  name: tekton-deployer-sa

這個 RBAC 配置定義了細緻的權限控制。ServiceAccount 是執行操作的身份主體。Role 定義了允許的操作範圍,包括管理 Pod、Service、Deployment 等核心資源。RoleBinding 將 Role 與 ServiceAccount 關聯,授予實際權限。

rules 區段定義了具體的權限規則。第一條規則允許對 Pod、Service、ConfigMap、Secret 執行所有操作,支援完整的應用部署。第二條規則允許管理 Deployment 與 ReplicaSet,實現應用的生命週期管理。後續規則提供了額外的讀取權限,便於狀態查詢與監控。

部署這些資源建立完整的權限配置。

kubectl create -f task-role.yaml
kubectl create -f task-role-binding.yaml

如果需要將容器註冊表認證也加入這個 ServiceAccount,可以使用 patch 命令。

kubectl patch serviceaccount tekton-deployer-sa \
  -p '{"secrets": [{"name": "container-registry-secret"}]}'

執行部署操作

使用 TaskRun 定義具體的部署操作。

apiVersion: tekton.dev/v1beta1
kind: TaskRun
metadata:
  name: kubectl-deploy-run
spec:
  serviceAccountName: tekton-deployer-sa
  taskRef:
    name: kubectl
  params:
  - name: SCRIPT
    value: |
      kubectl create deploy tekton-greeter \
        --image=quay.io/gitops-cookbook/tekton-greeter:latest

這個 TaskRun 使用 tekton-deployer-sa ServiceAccount,具備部署權限。SCRIPT 參數包含實際的 kubectl 命令,這裡建立一個 Deployment 使用剛剛建置的容器映像。

執行 TaskRun 觸發實際部署。

kubectl create -f kubectl-deploy-run.yaml

檢視執行日誌確認結果。

tkn taskrun logs kubectl-deploy-run -f

成功部署後,檢查 Deployment 狀態。

kubectl get deploy

暴露服務並測試應用。

kubectl expose deploy/tekton-greeter --port 8080
kubectl port-forward svc/tekton-greeter 8080:8080

在另一個終端測試應用回應。

curl localhost:8080

如果看到應用的輸出訊息,表示完整的容器化與部署流程已經成功運作。

Pipeline 編排整合

Pipeline 的價值定位

單一 Task 雖然功能完整,但在實際應用中通常需要將多個 Task 組合成 Pipeline,實現更複雜的工作流程。Pipeline 提供了任務編排能力,支援順序執行與平行執行,實現參數傳遞與結果共享,定義明確的執行依賴關係。

Pipeline 讓 CI/CD 流程更加結構化與可維護。將獨立的功能封裝為 Task,透過 Pipeline 組合這些 Task,形成完整的自動化流程。這種模組化設計提升了重用性,便於在不同專案間共享 Task 定義。

完整 Pipeline 定義

以下展示一個整合建置與部署的完整 Pipeline。

apiVersion: tekton.dev/v1beta1
kind: Pipeline
metadata:
  name: tekton-greeter-pipeline
spec:
  params:
  - name: GIT_REPO
    type: string
    default: https://github.com/gitops-cookbook/tekton-tutorial-greeter.git
  - name: GIT_REF
    type: string
    default: master
  - name: DESTINATION_IMAGE
    type: string
    default: quay.io/gitops-cookbook/tekton-greeter:latest
  - name: SCRIPT
    type: string
    default: kubectl create deploy tekton-greeter --image=quay.io/gitops-cookbook/tekton-greeter:latest
  
  tasks:
  - name: build-push-app
    taskRef:
      name: build-push-app
    params:
    - name: url
      value: $(params.GIT_REPO)
    - name: revision
      value: $(params.GIT_REF)
    - name: destinationImage
      value: $(params.DESTINATION_IMAGE)
    workspaces:
    - name: source
      workspace: app-source
  
  - name: deploy-app
    taskRef:
      name: kubectl
    params:
    - name: SCRIPT
      value: $(params.SCRIPT)
    runAfter:
    - build-push-app
  
  workspaces:
  - name: app-source

這個 Pipeline 定義展示了任務編排的核心概念。params 定義了 Pipeline 級別的參數,這些參數會傳遞給各個 Task。tasks 區段定義了要執行的任務清單。

build-push-app 任務執行容器建置與推播。taskRef 參照之前定義的 Task。params 將 Pipeline 參數映射到 Task 參數,建立參數傳遞鏈路。workspaces 指定使用的工作空間,便於資料共享。

deploy-app 任務執行應用部署。runAfter 欄位定義了執行依賴,確保部署在建置成功完成後才執行。這種宣告式的依賴管理讓執行順序清晰明確。

workspaces 區段定義了 Pipeline 級別的工作空間。app-source 工作空間會在執行時綁定到實際的儲存資源,例如 PersistentVolumeClaim 或 emptyDir。

部署 Pipeline 使用標準命令。

kubectl create -f tekton-greeter-pipeline.yaml

執行 Pipeline

使用 PipelineRun 定義 Pipeline 的具體執行實例。

apiVersion: tekton.dev/v1beta1
kind: PipelineRun
metadata:
  generateName: tekton-greeter-pipeline-run-
spec:
  serviceAccountName: tekton-deployer-sa
  params:
  - name: GIT_REPO
    value: https://github.com/gitops-cookbook/tekton-tutorial-greeter.git
  - name: GIT_REF
    value: master
  - name: DESTINATION_IMAGE
    value: quay.io/gitops-cookbook/tekton-greeter:latest
  - name: SCRIPT
    value: kubectl create deploy tekton-greeter --image=quay.io/gitops-cookbook/tekton-greeter:latest
  pipelineRef:
    name: tekton-greeter-pipeline
  workspaces:
  - name: app-source
    emptyDir: {}

這個 PipelineRun 定義了執行的具體配置。generateName 使用名稱前綴,Kubernetes 會自動加上隨機後綴,適合重複執行的場景。serviceAccountName 指定使用具備必要權限的 ServiceAccount。params 提供 Pipeline 參數的具體值。pipelineRef 參照要執行的 Pipeline。workspaces 綁定工作空間到實際儲存,這裡使用 emptyDir 提供臨時儲存。

執行 PipelineRun 觸發完整流程。

kubectl create -f tekton-greeter-pipelinerun.yaml

檢視執行狀態與日誌。

tkn pipelinerun ls
tkn pipelinerun logs -f

日誌會顯示兩個任務的執行過程,從 Git 複製、應用建置、容器建立推播,到最終的 Kubernetes 部署。整個流程自動化執行,無需人工介入。

@startuml
!define DISABLE_LINK
!define PLANTUML_FORMAT svg
!theme _none_

skinparam dpi auto
skinparam shadowing false
skinparam linetype ortho
skinparam roundcorner 5
skinparam defaultFontName "Microsoft JhengHei UI"
skinparam defaultFontSize 16
skinparam minClassWidth 100

package "Pipeline 執行流程" {
  rectangle "build-push-app Task" as build {
    rectangle "clone" as clone
    rectangle "build-sources" as build_sources
    rectangle "build-and-push-image" as build_push
    
    clone -down-> build_sources
    build_sources -down-> build_push
  }
  
  rectangle "deploy-app Task" as deploy {
    rectangle "kubectl deploy" as kubectl_deploy
  }
}

build -down-> deploy : runAfter 依賴

note right of build
  建置容器映像
  推播到註冊表
end note

note right of deploy
  部署到 Kubernetes
  使用新建置映像
end note

@enduml

Tekton Hub 元件重用

Tekton Hub 的生態價值

在實作 CI/CD Pipeline 時,許多操作是通用的,例如從 Git 倉庫複製程式碼、執行建置工具、建立容器映像等。Tekton Hub 作為社群維護的元件庫,提供了大量經過驗證的預建 Task,讓開發者能夠快速組裝高品質的 Pipeline,避免重複造輪子。

Tekton Hub 元件經過社群測試與優化,具有良好的可靠性與效能。使用這些預建 Task 不僅節省開發時間,也確保了最佳實踐的應用。當 Hub 中的 Task 更新時,可以輕鬆升級到新版本,享受社群持續改進的成果。

安裝 Hub Task

使用 tkn CLI 可以方便地從 Hub 安裝 Task。

tkn hub install task git-clone
tkn hub install task maven
tkn hub install task buildah
tkn hub install task kubernetes-actions

這些命令從 Tekton Hub 下載並安裝指定的 Task 到當前命名空間。git-clone 提供標準化的 Git 操作。maven 封裝了 Maven 建置流程。buildah 整合了容器建置功能。kubernetes-actions 提供通用的 kubectl 操作介面。

安裝完成後,系統會顯示確認訊息,包含 Task 名稱與版本。

Task git-clone(0.7) installed in default namespace
Task maven(0.2) installed in default namespace
Task buildah(0.4) installed in default namespace
Task kubernetes-actions(0.2) installed in default namespace

驗證 Task 是否正確安裝。

kubectl get tasks

輸出列表中應該包含剛安裝的四個 Task,確認它們已經可以在 Pipeline 中使用。

持久化工作空間配置

在使用多個 Task 組成的 Pipeline 時,需要在 Task 之間共享資料。PersistentVolumeClaim 提供了持久化的儲存解決方案。

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: app-source-pvc
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

這個 PVC 定義了持久化儲存需求。accessModes 指定為 ReadWriteOnce,表示可以被單一節點以讀寫模式掛載。對於 Tekton Pipeline,這通常已經足夠,因為 Task 按順序執行,不會同時掛載同一個 PVC。resources 請求 1GB 儲存空間,足以容納一般應用的原始碼與建置產物。

建立 PVC 使用標準命令。

kubectl create -f app-source-pvc.yaml

驗證 PVC 狀態。

kubectl get pvc

輸出顯示 PVC 處於 Bound 狀態,表示已經成功綁定到實際的儲存卷。在 Minikube 或其他開發環境中,預設的 StorageClass 會自動提供動態儲存。

使用 Hub Task 的 Pipeline

利用 Tekton Hub 的預建 Task,可以建立更標準化的 Pipeline。

apiVersion: tekton.dev/v1beta1
kind: Pipeline
metadata:
  name: tekton-greeter-pipeline-hub
spec:
  params:
  - name: GIT_REPO
    type: string
    default: https://github.com/gitops-cookbook/tekton-tutorial-greeter.git
  - name: GIT_REF
    type: string
    default: master
  - name: DESTINATION_IMAGE
    type: string
    default: quay.io/gitops-cookbook/tekton-greeter:latest
  - name: CONTEXT_DIR
    type: string
    default: quarkus
  - name: IMAGE_DOCKERFILE
    type: string
    default: ./Dockerfile
  - name: IMAGE_CONTEXT_DIR
    type: string
    default: .
  - name: SCRIPT
    type: string
    default: kubectl create deploy tekton-greeter --image=quay.io/gitops-cookbook/tekton-greeter:latest
  
  tasks:
  - name: fetch-repo
    taskRef:
      name: git-clone
    params:
    - name: url
      value: $(params.GIT_REPO)
    - name: revision
      value: $(params.GIT_REF)
    - name: deleteExisting
      value: "true"
    workspaces:
    - name: output
      workspace: app-source
  
  - name: build-app
    taskRef:
      name: maven
    params:
    - name: GOALS
      value:
      - -DskipTests
      - clean
      - package
    - name: CONTEXT_DIR
      value: $(params.CONTEXT_DIR)
    workspaces:
    - name: maven-settings
      workspace: maven-settings
    - name: source
      workspace: app-source
    runAfter:
    - fetch-repo
  
  - name: build-push-image
    taskRef:
      name: buildah
    params:
    - name: IMAGE
      value: $(params.DESTINATION_IMAGE)
    - name: DOCKERFILE
      value: $(params.IMAGE_DOCKERFILE)
    - name: CONTEXT
      value: $(params.IMAGE_CONTEXT_DIR)
    workspaces:
    - name: source
      workspace: app-source
    runAfter:
    - build-app
  
  - name: deploy
    taskRef:
      name: kubernetes-actions
    params:
    - name: script
      value: $(params.SCRIPT)
    runAfter:
    - build-push-image
  
  workspaces:
  - name: app-source
  - name: maven-settings

這個 Pipeline 展示了如何有效利用 Hub Task。fetch-repo 使用 git-clone Task 標準化 Git 操作,提供了豐富的配置選項如 deleteExisting 確保乾淨的工作目錄。build-app 使用 maven Task 執行建置,GOALS 參數接受陣列形式的 Maven 目標。build-push-image 使用 buildah Task 建立與推播容器映像,完全取代了自訂的建置步驟。deploy 使用 kubernetes-actions Task 執行部署操作。

runAfter 欄位定義了明確的執行順序。fetch-repo 首先執行獲取程式碼。build-app 在程式碼獲取後執行建置。build-push-image 在建置完成後建立容器映像。deploy 在映像推播後執行部署。這種線性流程清晰且易於理解。

workspaces 定義了兩個工作空間。app-source 用於共享原始碼與建置產物,在所有 Task 間傳遞。maven-settings 專門用於 Maven 建置配置,使用 emptyDir 提供臨時儲存即可。

建立這個 Pipeline 使用標準命令。

kubectl create -f tekton-greeter-pipeline-hub.yaml

執行 Hub Pipeline

使用 tkn CLI 啟動 Pipeline,提供完整的參數配置。

tkn pipeline start tekton-greeter-pipeline-hub \
  --serviceaccount=tekton-deployer-sa \
  --param GIT_REPO=https://github.com/gitops-cookbook/tekton-tutorial-greeter.git \
  --param GIT_REF=master \
  --param CONTEXT_DIR=quarkus \
  --param DESTINATION_IMAGE=quay.io/gitops-cookbook/tekton-greeter:latest \
  --param IMAGE_DOCKERFILE=quarkus/Dockerfile \
  --param IMAGE_CONTEXT_DIR=quarkus \
  --param SCRIPT='kubectl create deploy tekton-greeter --image=quay.io/gitops-cookbook/tekton-greeter:latest' \
  --workspace name=app-source,claimName=app-source-pvc \
  --workspace name=maven-settings,emptyDir="" \
  --use-param-defaults \
  --showlog

這個命令展示了完整的 Pipeline 執行配置。serviceaccount 指定具備必要權限的 ServiceAccount。param 參數為 Pipeline 的各個參數提供具體值,覆寫預設配置。workspace 參數綁定工作空間到實際儲存,app-source 使用 PVC 提供持久化儲存,maven-settings 使用 emptyDir 提供臨時儲存。use-param-defaults 選項對未明確指定的參數使用預設值。showlog 選項即時顯示執行日誌。

執行過程會顯示四個階段的詳細日誌。fetch-repo 階段顯示 Git 複製進度與結果。build-app 階段顯示 Maven 建置輸出,包括依賴下載、編譯過程與建置結果。build-push-image 階段顯示 Buildah 建置容器映像的過程,包括基礎映像拉取、層建立與推播進度。deploy 階段顯示 Kubernetes 部署操作的結果。

整個流程自動化執行,從原始碼到運行中的應用,無需人工介入。這正是現代 CI/CD 實踐的核心價值,透過自動化提升效率與可靠性。

@startuml
!define DISABLE_LINK
!define PLANTUML_FORMAT svg
!theme _none_

skinparam dpi auto
skinparam shadowing false
skinparam linetype ortho
skinparam roundcorner 5
skinparam defaultFontName "Microsoft JhengHei UI"
skinparam defaultFontSize 16
skinparam minClassWidth 100

package "Tekton Hub Pipeline 架構" {
  component "Hub Tasks" as hub {
    component [git-clone]
    component [maven]
    component [buildah]
    component [kubernetes-actions]
  }
  
  component "Pipeline" as pipeline {
    component [fetch-repo]
    component [build-app]
    component [build-push-image]
    component [deploy]
  }
  
  component "Workspaces" as ws {
    component [app-source PVC]
    component [maven-settings emptyDir]
  }
}

hub --> pipeline : taskRef 參照
pipeline --> ws : 資料共享

note right of hub
  社群維護
  標準化實作
  持續更新
end note

note right of pipeline
  模組化設計
  清晰依賴
  參數化配置
end note

@enduml

最佳實踐與優化策略

工作空間策略

在 Pipeline 中合理使用工作空間對於效能與資源管理至關重要。對於需要在多個 Task 間共享的大量資料,使用 PersistentVolumeClaim 確保資料持久性。對於只在 Pipeline 執行期間需要的臨時資料,使用 emptyDir 節省儲存資源。對於配置檔案或小型資料,考慮使用 ConfigMap 提供清晰的配置管理。

工作空間的大小應該根據實際需求設定。過大浪費資源,過小可能導致執行失敗。監控工作空間使用情況,根據實際需求調整配置。在生產環境中,考慮使用動態儲存供應,根據需求自動調整儲存容量。

參數化與重用性

Pipeline 的參數化設計是提升重用性的關鍵。定義清晰的參數介面,讓 Pipeline 能夠適應不同的專案與環境。提供合理的預設值,簡化常見場景的使用。使用描述性的參數名稱,便於理解與維護。

在設計參數時,考慮未來的擴展需求。即使當前不需要某些配置選項,預留參數位置也能簡化未來的調整。文檔化參數的用途與可能的取值,降低使用門檻。

安全性考量

在 CI/CD 流程中,安全性應該貫穿整個設計。使用專用的 ServiceAccount 執行不同類型的操作,遵循最小權限原則。定期審計與輪換認證資訊,降低洩露風險。使用 RBAC 精細控制資源存取,限制不必要的權限。

Secret 管理應該特別謹慎。避免在 Pipeline 定義或日誌中暴露敏感資訊。使用 Kubernetes Secret 儲存認證,而非明文配置。在生產環境中,考慮使用外部密鑰管理系統如 HashiCorp Vault。

監控與可觀察性

建立完善的監控體系對於生產環境至關重要。使用 Tekton Dashboard 視覺化 Pipeline 執行狀態。整合 Prometheus 與 Grafana 收集與展示指標。配置告警規則,及時發現異常情況。

日誌管理同樣重要。集中收集 Pipeline 執行日誌,便於問題排查與審計。保留適當的日誌歷史,平衡儲存成本與可追溯性。使用結構化日誌,便於查詢與分析。

總結與展望

Tekton 與 Buildah 的整合價值

Tekton 與 Buildah 的整合提供了完整的雲原生 CI/CD 解決方案。Tekton 作為 Kubernetes 原生的 Pipeline 框架,提供了宣告式的工作流程定義與強大的編排能力。Buildah 作為無需 daemon 的容器建置工具,完美適配 Kubernetes 環境的安全性要求。

這種整合讓容器化應用的完整生命週期管理變得簡單且可靠。從原始碼獲取、應用建置、容器映像建立,到 Kubernetes 部署,整個流程透過宣告式定義實現自動化。模組化的 Task 設計提升了重用性,Tekton Hub 的社群元件加速了開發效率。

持續改進的方向

在實際應用中,CI/CD 流程需要持續優化。根據專案特性調整 Pipeline 結構,平衡執行速度與資源消耗。整合更多的品質檢查步驟,例如程式碼掃描、漏洞檢測、效能測試。實施多環境部署策略,支援開發、測試、生產等不同環境。

擁抱社群生態,持續關注 Tekton Hub 的新元件與最佳實踐。參與社群討論,分享經驗與學習他人的實作。隨著 Tekton 生態系統的發展,新功能與改進持續湧現,保持學習與實踐,讓 CI/CD 系統與時俱進。

在雲原生時代,自動化是提升競爭力的關鍵。Tekton 與 Buildah 提供了強大的工具與靈活的架構,讓團隊能夠建構真正現代化的 CI/CD 系統,支撐業務的快速發展與創新。

玄貓 BlackCat

玄貓 BlackCat

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