Membangun CI/CD Pipeline dengan Tekton: Native Pipeline untuk Kubernetes Cluster

Understanding Tekton Pipeline Architecture on Kubernetes

Tekton beroperasi sebagai kumpulan custom resource definition (CRD) yang terintegrasi langsung ke dalam ekosistem Kubernetes. Pendekatan ini menghilangkan kebutuhan akan external CI/CD runner karena Tekton memanfaatkan pod Kubernetes sebagai unit eksekusi tugas. Setiap komponen dalam arsitektur Tekton memiliki peran spesifik dalam alur kerja pipeline.

Tiga objek utama dalam Tekton adalah Pipeline, Task, dan PipelineRun. Pipeline mendefinisikan keseluruhan rangkaian proses CI/CD. Task mengenkapsulasi satu langkah kerja spesifik seperti build atau test. PipelineRun adalah instansi eksekusi dari Pipeline yang berjalan di cluster. Hubungan hierarkis ini memungkinkan kita mendeklarasikan seluruh alur CI/CD sebagai konfigurasi Kubernetes murni.

Untuk memulai, kita perlu menginstal Tekton Pipelines pada cluster Kubernetes terlebih dahulu. Perintah berikut menerapkan manifest resmi Tekton:

kubectl apply --filename https://storage.googleapis.com/tekton-releases/pipeline/latest/release.yaml

> ⚠️ Note: Perintah ini memerlukan akses ke Kubernetes cluster yang aktif, sehingga tidak dapat dieksekusi di lingkungan sandbox lokal. Jalankan perintah ini pada cluster target setelah kubectl terkonfigurasi.

Setelah instalasi selesai, verifikasi bahwa Pipeline resource telah tersedia dengan menjalankan kubectl get pipeline. Hasilnya menampilkan daftar Pipeline yang telah terdaftar di cluster. Arsitektur ini memberikan keuntungan besar karena setiap Task dieksekusi sebagai pod Kubernetes independen, sehingga scaling dan resource management sepenuhnya dikelola oleh cluster.

Gambar: Diagram arsitektur tingkat tinggi Kubernetes master dan application node — Sumber: Wikimedia Commons (CC BY-SA 4.0 oleh Khtan66)

Constructing Reusable Tekton Tasks with Parameterized Workflows

Task merupakan blok bangunan fundamental dalam Tekton. Setiap Task mendefinisikan serangkaian langkah yang dieksekusi secara sequential dalam satu pod Kubernetes. Keunggulan utama Task adalah kemampuannya untuk menerima parameter dan workspace, menjadikannya reusable di berbagai konteks pipeline.

Menggunakan params memungkinkan kita meneruskan nilai dinamis seperti URL repository atau nama branch ke dalam Task. Sementara workspaces menyediakan mekanisme berbagi data antar langkah dalam Task dan antar Task dalam Pipeline. Kombinasi kedua fitur ini menciptakan komponen yang sangat fleksibel dan dapat digunakan kembali.

Berikut adalah contoh Task parameterisasi yang menerima git repository URL dan branch name, kemudian menjalankan langkah build:

apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
  name: build-app-task
spec:
  params:
    - name: git-url
      type: string
      description: URL repository git
    - name: git-revision
      type: string
      description: Nama branch atau commit
  workspaces:
    - name: source
      description: Workspace untuk menyimpan source code
  steps:
    - name: clone
      image: alpine/git
      script: |
        git clone $(params.git-url) $(workspaces.source.path)
        cd $(workspaces.source.path)
        git checkout $(params.git-revision)
    - name: build
      image: maven:3.8-openjdk-17
      script: |
        cd $(workspaces.source.path)
        mvn package -DskipTests

> ✅ Validasi: YAML di atas tervalidasi dengan parser yaml.safe_load (PyYAML) — sintaks valid, kind=Task, apiVersion=tekton.dev/v1beta1, name=build-app-task. Definisi ini tidak dieksekusi karena memerlukan cluster Kubernetes dengan Tekton Pipelines terinstal.

Logika di balik konfigurasi ini sederhana namun powerful. Langkah pertama mengkloning repository ke dalam workspace yang dibagikan. Langkah kedua menggunakan Maven untuk membangun aplikasi Java. Workspace memastikan artifact build dari langkah clone tersedia untuk langkah build tanpa perlu komunikasi antar pod. Ketika Task ini dipanggil dalam Pipeline yang berbeda, kita cukup mengganti parameter git-url dan git-revision tanpa mengubah definisi Task itu sendiri.

Orchestrating a Full CI/CD PipelineRun from Source to Deployment

PipelineRun menggabungkan beberapa Task menjadi grafik eksekusi yang terkoordinasi. Objek ini bertindak sebagai trigger yang menjalankan seluruh rangkaian proses CI/CD, mulai dari cloning source code hingga deployment ke cluster Kubernetes.

Integrasi git trigger events dilakukan melalui Kubernetes service accounts dan service bindings. Tekton mendukung pipeline triggers yang secara otomatis memulai eksekusi ketika ada push event atau pull request ke repository. Artifact antar Task dilewatkan menggunakan Tekton Workspaces yang backed oleh PersistentVolumeClaims, memastikan data persisten di seluruh tahapan pipeline.

Berikut adalah contoh PipelineRun yang mengchain tiga Task: source cloning, build, dan deploy:

apiVersion: tekton.dev/v1beta1
kind: PipelineRun
metadata:
  name: full-ci-cd-pipeline
spec:
  pipelineRef:
    name: ci-cd-pipeline
  params:
    - name: git-url
      value: "https://github.com/example/repo.git"
    - name: git-revision
      value: "main"
    - name: image-tag
      value: "latest"
  workspaces:
    - name: shared-workspace
      volumeClaimTemplate:
        spec:
          accessModes:
            - ReadWriteOnce
          resources:
            requests:
              storage: 1Gi

> ✅ Validasi: YAML di atas tervalidasi dengan parser yaml.safe_load (PyYAML) — sintaks valid, kind=PipelineRun, apiVersion=tekton.dev/v1beta1, name=full-ci-cd-pipeline. Objek ini tidak dieksekusi karena memerlukan cluster Kubernetes dengan Tekton Pipelines terinstal.

Pipeline yang dirujuk oleh PipelineRun ini mendefinisikan tiga Task berurutan. Task pertama mengkloning source code ke dalam shared workspace. Task kedua mengambil source dari workspace yang sama, membangun container image, dan mendorongnya ke registry. Task ketiga mengambil image yang telah dibangun dan melakukan deployment ke Kubernetes cluster. Seluruh eksekusi berjalan sebagai satu kesatuan proses, dengan setiap Task hanya dimulai setelah Task sebelumnya selesai dengan sukses.

Expected output dari eksekusi PipelineRun mencakup status penyelesaian setiap Task, URL image yang telah dipush ke registry, dan konfirmasi deployment ke cluster. Kita dapat memantau status menggunakan kubectl get pipelinerun dan kubectl logs untuk melihat detail eksekusi setiap Task.

Gambar: Diagram konsep containerized continuous delivery pipeline — Sumber: Wikimedia Commons (CC BY-SA 2.5 oleh DDuvall (WMF) dan TCipriani (WMF))

Monitoring Pipeline Execution and Implementing Security Best Practices

Monitoring eksekusi PipelineRun dapat dilakukan melalui dua pendekatan utama. Pertama, menggunakan kubectl logs untuk mengakses log langsung dari setiap TaskRun. Kedua, dengan menginstal Tekton Dashboard yang menyediakan antarmuka visual untuk melihat status PipelineRun, TaskRun, dan log secara real-time.

Keamanan dalam Tekton harus diprioritaskan dengan menerapkan prinsip least privilege. Service account yang digunakan oleh PipelineRun harus memiliki minimal RBAC permissions yang hanya mencakup resource yang dibutuhkan. Hindari memberikan cluster-wide access karena hal ini meningkatkan permukaan serangan jika terjadi kompromi pada pipeline.

Selain itu, implementasi image scanning dan admission controllers sebagai pipeline gate sebelum deployment sangat penting. Langkah ini memastikan bahwa container image yang diproduksi telah lolos pemindaian kerentanan sebelum diterapkan ke production. Konfigurasi timeout dan retry policies pada PipelineRun juga meningkatkan ketahanan eksekusi terhadap kegagalan transient.

apiVersion: tekton.dev/v1beta1
kind: PipelineRun
metadata:
  name: secure-pipeline-run
spec:
  serviceAccountName: restricted-sa
  timeout: "1h"
  params:
    - name: enable-image-scan
      value: "true"
  pipelineRef:
    name: secure-ci-cd-pipeline

> ✅ Validasi: YAML di atas tervalidasi dengan parser yaml.safe_load (PyYAML) — sintaks valid, kind=PipelineRun, apiVersion=tekton.dev/v1beta1, name=secure-pipeline-run. Objek ini tidak dieksekusi karena memerlukan cluster Kubernetes dengan Tekton Pipelines terinstal.

Pada contoh di atas, serviceAccountName dibatasi hanya untuk resource tertentu, timeout mencegah eksekusi berjalan tanpa batas, dan parameter enable-image-scan mengaktifkan gate pemindaian keamanan.

Scaling Pipeline Design Across Multiple Teams and Projects

Untuk organisasi dengan banyak tim, berbagi common Task definitions antar namespace menjadi penting. Tekton mendukung cluster-scoped custom resources yang memungkinkan Task diakses dari berbagai namespace tanpa perlu duplikasi. Pendekatan ini mengurangi overhead pemeliharaan dan memastikan konsistensi standar build di seluruh organisasi.

Versioning pipeline definitions bersama application code dalam git repository adalah praktik terbaik yang direkomendasikan. Dengan menyimpan definisi Pipeline dan Task sebagai kode, kita dapat melakukan review, rollback, dan audit perubahan secara transparan. Pendekatan GitOps-driven ini selaras dengan filosofi declarative dari Tekton itu sendiri.

Pipeline templates yang mengenforce standar organisasi sambil memungkinkan tim-level customization memberikan keseimbangan antara kontrol dan fleksibilitas. Setiap tim dapat membuat PipelineRun berdasarkan template yang telah disetujui, mengganti parameter sesuai kebutuhan tanpa mengubah inti dari definisi pipeline.

Siap membangun CI/CD pipeline Kubernetes-native yang lebih advanced? Bergabunglah dengan kursus Docker & DevOps di Rumah Coding untuk mendalami praktik Kubernetes dan Tekton secara langsung.