Belajar Kubernetes Shared Filesystem RWX - CI/CD Build & Deploy Pipeline

#Pendahuluan

Upload manual image dan kubectl apply yang setengah jadi sudah waktunya pensiun. Di episode 22 kita membangun pipeline rilis yang konsisten: perubahan kode → build image → push registry → deploy ke cluster → traffic mengalir — tanpa satu pun langkah manusia di tengah jalan.

Khusus untuk arsitektur kita (stateful via PVC RWX), ada aturan emas: kode berubah, data jangan diganggu. Pipeline harus tahu perbedaan antara "update image" dan "migrasi schema".

#Pipeline Build Image

Workflow GitHub Actions untuk build dan push image ke GHCR:

name: build-image
on:
  push:
    branches: [main]
    paths: ["app/**", "Dockerfile"]
jobs:
  build:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: write
    steps:
      - uses: actions/checkout@v4
 
      - uses: docker/setup-buildx-action@v3
 
      - uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}
 
      - uses: docker/build-push-action@v6
        with:
          context: ./app
          push: true
          tags: ghcr.io/${{ github.repository }}:${{ github.sha }}

Setiap commit ke main menghasilkan image baru ber-tag commit hash.

#Update Deployment

#Rolling Update dengan kubectl

Setelah image terpush, lakukan deploy:

Update image dan tunggu rapi

kubectl set image deployment/laravel laravel-web=ghcr.io/<user>/laravel-media:$(git rev-parse HEAD)
kubectl rollout status deployment/laravel --timeout=180s

Rolling update mengganti Pod satu per satu; data volume RWX tetap ter-mount — dari sudut pandang data, ini hanya pertukaran proses.

#GitOps: Argo CD / Flux

Pola GitOps menyimpan seluruh manifest di git, dan operator (Argo CD/Flux) menjaga cluster selalu sesuai repo. Saat image berubah, cukup update repo — operator menerapkan:

argocd app sync laravel
argocd app health laravel

Keuntungan GitOps: history deploy = history git, rollback = revert commit, drift cluster terdeteksi otomatis.

#Kapan Image Baru Membutuhkan Storage?

Aturan emas pipeline + storage:

• Code change saja → cukup kubectl set image; volume tidak tersentuh; data tetap.
• Schema/data migration → jalankan job migrate dulu, baru rollout aplikasi:

Migrasi sebelum rollout

kubectl apply -f job-migrate.yaml
kubectl wait --for=condition=complete job/laravel-migrate --timeout=180s
kubectl set image deployment/laravel laravel-web=ghcr.io/<user>/laravel-media:v2

• Media seed → sinkron via init container (episode 12) atau job terpisah; jangan di dalam image deployment.

#Zero-Downtime

Dua mekanisme menjaga lalu lintas tetap mengalir selama rollout:

• readinessProbe — Pod baru tidak dimasukkan ke Service sebelum benar-benar siap (termasuk volume & symlink siap dari episode 12). Pod lama tidak dilepas sebelum penggantinya siap.
• Rolling update strategy — kendalikan kecepatan:

spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0

maxUnavailable: 0 menjamin selalu ada Pod lama yang melayani — traffic tidak pernah kosong. maxSurge: 1 membatasi Pod baru yang muncul serentak.

Gunakan maxUnavailable: 0 untuk aplikasi single-Pod sekalipun; biaya yang dibayar hanya satu Pod sementara di atas kapasitas.

#Penutup

Pada episode 22 ini, rilis aplikasi kalian kini otomatis dan aman:

Inti yang harus dibawa pulang:

• Pipeline GitHub Actions: build + push image ke registry dengan tag unik.
• Deploy via kubectl set image (rolling) atau GitOps (Argo CD/Flux).
• Code change tidak menyentuh volume; migrasi schema dijalankan sebelum rollout.
• Zero-downtime: readinessProbe + maxUnavailable: 0, maxSurge: 1.
• Rollback image semudah kubectl rollout undo.

Di episode 23 selanjutnya kita akan mengeraskan produksi: manajemen Config & Secret, security checklist dari ekspor NFS sampai Pod security admission, operational checklist, dan penyusunan runbook untuk skenario NFS down. Sampai jumpa di episode 23!