GitOps K8s 自動化佈署：使用Tekton和Buildah進行應用程式容器化

雲端原生方法的核心是自動化，尤其是在Kubernetes環境中。然而，Kubernetes本身並沒有內建容器建置機制，它依賴諸如Tekton之類別的附加元件或外部服務來完成這一工作。這也是為什麼我們需要學習如何使用Tekton來封裝和佈署應用程式。

設定容器登入檔認證

與私有Git儲存函式庫別似，將容器映像推播到容器登入檔也需要認證。我們需要建立一個Secret並將其附加到ServiceAccount：

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

確認Secret已建立並檢查類別是否為kubernetes.io/dockerconfigjson：

kubectl get secrets

為這個Task建立一個ServiceAccount並增加Secret：

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

建立應用容器化的Tekton Task

接下來，我們將建立一個新的Task，除了編譯應用程式外，還會建立容器映像並推播到容器登入檔：

apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
  name: build-push-app
spec:
  workspaces:
    - name: source
      description: The git repo will be cloned onto the volume backing this workspace
  params:
    - name: contextDir
      description: the context dir within source
      default: quarkus
    - name: tlsVerify
      description: tls verify
      type: string
      default: "false"
    - name: url
      default: https://github.com/gitops-cookbook/tekton-tutorial-greeter.git
    - name: revision
      default: master
    - name: subdirectory
      default: ""
    - name: sslVerify
      description: defines if http.sslVerify should be set to true or false in the global git config
      type: string
      default: "false"
    - name: storageDriver
      type: string
      description: Storage driver
      default: vfs
    - name: destinationImage
      description: the fully qualified image name
      default: ""
  steps:
    - image: 'gcr.io/tekton-releases/github.com/tektoncd/pipeline/cmd/git-init:v0.21.0'
      name: clone
      resources: {}
      script: |
        CHECKOUT_DIR="$(workspaces.source.path)/$(params.subdirectory)"
        cleandir() {
          # Delete any existing contents of the repo directory if it exists.
          # We don't just "rm -rf $CHECKOUT_DIR" because $CHECKOUT_DIR might be "/"
          # or the root of a mounted volume.
          if [[ -d "$CHECKOUT_DIR" ]] ; then
            # Delete non-hidden files and directories
            rm -rf "$CHECKOUT_DIR"/*
            # Delete files and directories starting with . but excluding ..
            rm -rf "$CHECKOUT_DIR"/.[!.]*
            # Delete files and directories starting with .. plus any other character
            rm -rf "$CHECKOUT_DIR"/..?*
          fi
        }
        /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)"
    - 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包含三個主要步驟：

clone：從Git儲存函式庫程式碼
build-sources：使用Maven編譯Java應用程式
build-and-push-image：使用Buildah建立容器映像並推播到容器登入檔

在實際工作中，我經常需要調整這些步驟以適應不同的專案需求。例如，對於Node.js專案，我會將Maven編譯替換為npm build；對於Go專案，則使用go build命令。

建立Task後，使用以下命令執行：

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

理解Tekton中的工作區與引數

在上述設定中，我們使用了一些Tekton的關鍵概念，值得深入理解：

工作區(Workspace)

工作區是Tekton中的一個重要概念，它允許Task在執行期間分享檔案或目錄。在我們的例子中，我們使用了一個名為source的工作區來儲存Git儲存函式庫容，並在不同步驟間分享。

工作區可以與多種Kubernetes儲存選項整合，包括：

EmptyDir（如範例中使用的）
PersistentVolumeClaim
ConfigMap
Secret

在生產環境中，我通常會使用PersistentVolumeClaim以確保資料在Pod重啟後仍然保留。

引數(Params)

引數允許我們在執行Task時動態設定其行為。在我們的例子中，我們使用了多個引數：

url：Git儲存函式庫RL
contextDir：應用程式在倉函式庫目錄
destinationImage：容器映像的目標位置

這種設計使得Task更加靈活，可以適應不同的專案和環境。

安全考量與最佳實踐

在設定Tekton的認證機制時，有幾點安全最佳實踐值得注意：

使用最小許可權原則：為ServiceAccount分配最小必要許可權，避免過度授權。
定期輪換認證：定期更新Secret中的認證資訊，特別是個人存取令牌。
使用RBAC限制存取：限制對包含認證資訊的Secret的存取。
考慮使用外部金鑰管理系統：在大型組織中，考慮使用Vault等工具管理金鑰。

在我的實踐中，我發現將這些安全考量整合到CI/CD流程的早期階段非常重要，因為後期修改可能會變得複雜與成本高昂。

擴充套件Tekton流程

隨著CI/CD需求的增長，你可能需要擴充套件上述基本流程。以下是一些常見的擴充套件點：

增加測試步驟：在構建容器之前增加單元測試和整合測試步驟。
加入漏洞掃描：使用工具如Trivy或Clair掃描容器映像中的漏洞。
實作多環境佈署：設計Pipeline支援不同環境（開發、測試、生產）的佈署。
整合通知機制：在Pipeline執行完成後傳送Slack或Email通知。

這些擴充套件可以逐步增加，以滿足團隊不斷發展的需求。

透過這些技術和實踐，你可以在Kubernetes上構建一個強大的CI/CD系統，支援私有Git儲存函式庫和自動化容器建置流程。這不僅提高了開發效率，還確保了佈署過程的一致性和可靠性。

在雲端原生的世界中，掌握這些技能將使你能夠更有效地管

Tekton在Kubernetes中的持續整合與佈署實踐

佈署應用到Kubernetes使用Tekton Task

在前面的章節中，我們探討了Tekton用於持續整合(CI)的任務設定，現在讓我們深入持續佈署(CD)的環節，學習如何將容器映像佈署到Kubernetes叢集。

我們可以利用之前建立並推播的容器映像quay.io/gitops-cookbook/tekton-greeter:latest，透過建立一個簡單而強大的佈署任務來完成這項工作。

建立kubectl佈署任務

首先，建立一個能夠執行kubectl命令的Task：

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

這個Task定義了一個能執行kubectl命令的任務，它使用OpenShift CLI映像，相比Google提供的kubectl映像體積更小。這裡的引數SCRIPT允許我們在執行時指定要執行的kubectl命令，提供了極大的靈活性。

建立這個Task：

kubectl create -f kubectl-task.yaml

建立專用服務帳戶與許可權

Tekton預設使用預設的ServiceAccount執行任務，但最佳實踐是為特定操作建立專用的服務帳戶。因此，我們建立一個名為tekton-deployer-sa的服務帳戶：

kubectl create serviceaccount tekton-deployer-sa

服務帳戶需要許可權才能佈署應用到Kubernetes。我們需要建立Role和RoleBinding來賦予這些許可權：

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

接著建立RoleBinding將Role與ServiceAccount連結：

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: task-role-binding
roleRef:
  kind: Role
  name: task-role
  apiGroup: rbac.authorization.k8s.io
subjects:
- kind: ServiceAccount
  name: tekton-deployer-sa

建立這些資源：

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

執行佈署任務

現在可以定義一個TaskRun來執行我們的佈署任務：

apiVersion: tekton.dev/v1beta1
kind: TaskRun
metadata:
  name: kubectl-taskrun
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：

kubectl create -f kubectl-taskrun.yaml

檢查日誌以確認結果：

tkn taskrun logs kubectl-run -f

幾秒鐘後，佈署應該處於Ready狀態：

kubectl get deploy

最後，暴露佈署並轉發流量以測試應用：

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

在另一個終端中，測試應用：

curl localhost:8080

如果一切順利，你應該看到：Meeow!! from Tekton ----

建立Tekton Pipeline進行建構與佈署

在前面的章節中，我們看到了如何建立Tasks來執行一系列步驟。現在讓我們進一步探討Tekton Pipelines，它允許我們將多個Tasks組合在一起，按照特定順序執行，可以是序列或平行的方式。

Tekton Pipeline概述

Tekton Pipeline是Tasks的集合，它支援引數傳遞和在不同Tasks之間交換結果的機制。Pipeline可以定義執行流程，並且提供了靈活的設定選項。

首先，讓我們為我們的佈署服務帳戶增加容器倉函式庫：

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

接著建立一個完整的Pipeline來建構和佈署我們的應用：

apiVersion: tekton.dev/v1beta1
kind: Pipeline
metadata:
  name: tekton-greeter-pipeline
spec:
  params:
  - name: GIT_REPO
    type: string
  - name: GIT_REF
    type: string
  - name : DESTINATION_IMAGE
    type: string
  - name : SCRIPT
    type: string
  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
  - name: deploy-app
    taskRef:
      name: kubectl
    params:
    - name: SCRIPT
      value: "$(params.SCRIPT)"
    workspaces:
    - name: source
    runAfter:
    - build-push-app
  workspaces:
  - name: source

這個Pipeline定義了四個引數：Git儲存函式庫L、Git分支或標籤、目標映像位置以及佈署指令碼。它包含兩個任務：build-push-app（建構和推播應用）和deploy-app（佈署應用）。runAfter欄位指定了任務執行的順序，確保佈署任務在建構任務成功完成後執行。workspaces提供了在不同任務間分享資料的機制。

建立Pipeline：

kubectl create -f tekton-greeter-pipeline.yaml

執行Pipeline

要執行Pipeline，我們需要建立一個PipelineRun資源：

apiVersion: tekton.dev/v1beta1
kind: PipelineRun
metadata:
  generateName: tekton-greeter-pipeline-run-
spec:
  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: source
    emptyDir: {}

執行Pipeline：

kubectl create -f tekton-greeter-pipelinerun.yaml

檢查執行狀態：

tkn pipelinerun ls

Tekton Hub介紹

到目前為止，我們已經學習瞭如何在Pipeline中重用現有的Tasks，這正是理解Tekton Hub的好時機。Tekton Hub是一個根據Web的平台，供開發者發現、分享和貢獻Tekton資源。

Tekton Hub提供了大量預先定義的Tasks和Pipelines，這些可以直接用於各種CI/CD場景，避免從零開始構建管道。這些分享資源經過社群審核和測試，能夠提高開發效率並促進最佳實踐的採用。

在實際開發中，我發現將自定義Tasks與Tekton Hub上的公共資源相結合，可以顯著加速CI/CD流程的設計和實作。特別是對於常見的操作，如git克隆、映像建構和Kubernetes佈署，使用社群維護的資源可以減少設定錯誤並提高管道的可靠性。

深入理解Tekton的工作流程

Tekton的工作流程設計反映了雲原生應用開發的現代方法。每個Task都是獨立的，具有明確定義的輸入和輸出，這使得它們可以輕鬆組合和重用。這種模組化方法不僅提高了可維護性，還使得自動化流程更容易理解和除錯。

在設計Tekton Pipelines時，我建議從識別工作流程中的獨立步驟開始，然後將這些步驟對映到各個Tasks。這樣可以確保每個Task專注於單一職責，並且可以獨立測試。接著，將這些Tasks連線成一個完整的Pipeline，定義清晰的執行順序和資料流。

最後，透過使用PipelineRun和TaskRun資源，可以靈活地傳遞引數和設定，使同一個Pipeline能夠用於不同的應用和環境。這種引數化方法是Tekton強大功能的核心，它使CI/CD流程既標準化又靈活。

透過這種方式，Tekton不僅簡化了持續整合和佈署過程，還提供了一個一致的框架，使團隊能夠跨專案和環境標準化他們的開發流程。

在實際應用中，我發現將Tekton與GitOps實踐結合使用效果最佳，這樣可以實作完全自動化的應用生命週期管理，從程式碼提交到生產佈署，所有步驟都可追蹤、可重複與可靠。

Tekton Hub：預建元件加速 CI/CD 實作

在實作 CI/CD 管線時，我們經常需要重複開發相同功能的任務元件，例如從 Git 倉函式庫程式碼、建置應用程式、封裝容器映像等。這些重複性工作不僅耗費時間，還可能因為不同團隊實作方式不同而導致維護困難。Tekton Hub 正是為解決這個問題而生的元件函式庫提供了豐富的、經過社群驗證的預建 Task，讓我們能夠快速組裝高品質的管線。

利用 Tekton Hub 的預建 Task

在我們的例項中，可以利用 Tekton Hub 中已有的 Task 來取代自行撰寫的 Task。所需的關鍵 Task 包括：

git-clone：從指定 URL 複製程式碼函式庫出工作區
maven：執行 Maven 建置指令
buildah：將原始碼建置為容器映像並推播至容器登入檔
kubernetes-actions：通用的 kubectl CLI 任務，可執行各種 Kubernetes 指令

讓我們先將這些 Task 安裝到名稱空間中：

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

執行後，系統會確認這些 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

可以透過以下命令交叉確認：

kubectl get tasks

輸出應類別似於：

NAME                AGE
...
buildah             50s
git-clone           52s
kubernetes-actions  49s
maven               51s
...

在這裡，我們透過 tkn hub install 命令安裝了四個核心 Task。Tekton Hub 作為 Tekton 生態系統的中央元件函式庫許開發者重用已經驗證過的 Task，而不必從頭開始編寫。這些 Task 都經過社群測試和最佳化，能夠處理從程式碼取得到佈署的整個流程中的關鍵步驟。

持久化工作空間：管線任務間的資料分享

在 Tekton 管線中，不同任務間需要分享資料，例如從 git-clone 任務取得的程式碼需要傳遞給後續的建置和容器化任務。為此，我們需要設定永續性儲存區宣告 (PersistentVolumeClaim) 作為工作空間：

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

使用 kubectl 建立資源：

kubectl create -f app-source-pvc.yaml

確認建立成功：

kubectl get pvc

您應該會看到類別似以下的輸出：

NAME            STATUS  VOLUME                                    CAPACITY   ACCESS MODES  STORAGECLASS  AGE
app-source-pvc  Bound   pvc-e85ade46-aaca-4f3f-b644-d8ff99fd9d5e  1Gi        RWO           standard      61s

永續性儲存區宣告 (PVC) 是 Kubernetes 中用於請求儲存空間的機制。在這個例子中，我們建立了一個 1GB 大小、具有 ReadWriteOnce 存取模式的 PVC。這意味著該卷只能被一個節點以讀寫模式掛載，這對於我們的管線是足夠的，因為 Tekton 任務通常是按順序執行的。在 Minikube 環境中，預設的 StorageClass 會自動提供動態儲存。

使用 Hub 任務的完整管線定義

以下是使用 Tekton Hub 任務的完整管線定義：

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

建立此資源：

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

這個管線定義包含四個關鍵任務：

fetch-repo - 使用 git-clone 任務從 GitHub 上提取程式碼
build-app - 使用 maven 任務執行 Maven 建置流程
build-push-image - 使用 buildah 任務構建並推播容器映像
deploy - 使用 kubernetes-actions 任務佈署應用程式

每個任務都有特定的引數設定，並使用工作空間來分享資料。runAfter 欄位確保任務按正確順序執行。注意，我們使用了兩個工作空間：app-source 用於分享程式碼和建置產物，而 maven-settings 用於 Maven 建置設定。

啟動並監控管線執行

現在可以使用以下命令啟動管線：

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

這個命令使用 tkn pipeline start 啟動管線，並指定了多個引數：

使用 tekton-deployer-sa 服務帳號，這個帳號需要具有推播映像和佈署應用的許可權
設定各種管線引數，包括 Git 倉函式庫支、構建上下文和目標映像
為工作空間指定永續性儲存區宣告和臨時目錄
--showlog 標誌會即時顯示管線執行日誌

管線執行過程分析

管線執行時會顯示詳細的日誌，我們可以看到整個流程：

程式碼提取階段：

[fetch-repo : clone] + CHECKOUT_DIR=/workspace/output/
[fetch-repo : clone] + /ko-app/git-init '-url=https://github.com/gitops-cookbook/tekton-tutorial-greeter.git' '-revision=master'...
[fetch-repo : clone] {"level":"info"..."Successfully cloned https://github.com/gitops-cookbook/tekton-tutorial-greeter.git..."}

Maven 建置階段：

[build-app : mvn-goals] [INFO] [org.jboss.threads] JBoss Threads version 3.1.1.Final
[build-app : mvn-goals] [INFO] [io.quarkus.deployment.QuarkusAugmentor] Quarkus augmentation completed in 1296ms
[build-app : mvn-goals] [INFO] BUILD SUCCESS

容器映像建置與推播階段：

[build-push-image : build] STEP 1/2: FROM registry.access.redhat.com/ubi8/openjdk-11
[build-push-image : build] Trying to pull registry.access.redhat.com/ubi8/openjdk-11:latest...
...
[build-push-image : build] STEP 2/2: COPY target/quarkus-app /deployments/
[build-push-image : build] COMMIT quay.io/gitops-cookbook/tekton-greeter:latest
[build-push-image : build] --> c07e36a8e61
[build-push-image : build] Successfully tagged quay.io/gitops-cookbook/tekton-greeter:latest

Kubernetes 佈署階段：

[deploy : kubectl] deployment.apps/tekton-greeter created

管線架構最佳化與實踐技巧

使用 Tekton Hub 的預建 Task 後，我們的管線變得更加標準化與易於維護。這種方式有幾個關鍵優勢：

標準化與一致性

使用 Hub 中的 Task 確保了不同團隊和專案間的一致性。舉例來說，git-clone 任務會以一致的方式處理 Git 操作，避免因不同實作方式導致的問題。

減少維護負擔

當 Tekton Hub 中的 Task 更新時，我們可以輕鬆升級到新版本，而不必自行維護這些基礎元件。這使得我們能夠專注於業務邏輯而非基礎設施程式碼。

工作空間策略

在這個管線中，我們使用了兩種工作空間：

永續性儲存區宣告 (app-source-pvc) 用於分享程式碼和建置產物
臨時目錄 (emptyDir) 用於 Maven 設定

這種混合策略能夠最佳化資源使用，只在必要時使用持久儲存。

引數化與可重用性

管線定義中的大量引數使其具有高度靈活性。我們可以針對不同的專案、分支或佈署目標重用同一管線，只需調整引數值即可。

進階技巧：ClusterTask 的使用

許多 Tekton 安裝（特別是 OpenShift Pipelines 的 Operator 安裝）會提供一系列 ClusterTask，這些是在整個叢集中所有名稱空間都可用的 Task。可以用以下命令檢查您的安裝是否已提供這些 ClusterTask：

kubectl get clustertasks

使用 ClusterTask 可以進一步減少重複安裝相同 Task 的需求，特別是在大型組織中多團隊分享同一叢集的情況下。

玄貓

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