Arsitektur Ephemeral Self-Hosted Runner: Strategi Automasi CI/CD Aman, Hemat Biaya, dan Bebas Antrean Skala Enterprise

Dalam lanskap pengembangan perangkat lunak modern, Continuous Integration dan Continuous Deployment (CI/CD) telah berevolusi dari sekadar opsi otomatisasi menjadi tulang punggung produktivitas tim. Namun, seiring bertambahnya jumlah developer dan kompleksitas aplikasi, infrastruktur CI/CD konvensional sering kali membentur dinding pembatas: antrean build yang panjang, biaya komputasi awan yang membengkak, dan risiko keamanan akibat berbagi lingkungan eksekusi.

Banyak organisasi memulai dengan managed runner yang disediakan oleh platform seperti GitHub Actions, GitLab CI, atau Bitbucket Pipelines. Solusi ini praktis, tetapi membatasi kendali Anda atas spesifikasi perangkat keras, penyimpanan cache, dan isolasi jaringan. Artikel ini akan membahas sudut pandang alternatif yang kian krusial bagi skala enterprise: Arsitektur Ephemeral Self-Hosted Runner berbasis Event-Driven Auto-scaling.

---

Anatomi Masalah: Mengapa Managed Runner & Static Runner Mulai Gagal?

Sebelum membedah solusinya, kita harus memahami mengapa pendekatan tradisional (baik managed maupun static self-hosted) gagal memenuhi kebutuhan tim skala besar.

1. Efek 'Noisy Neighbor' & Antrean Vendor: Pada shared managed runner, kecepatan eksekusi Anda bergantung pada beban global platform. Di jam-jam sibuk, pipeline Anda harus mengantre.
2. State Leakage & Risiko Keamanan: Static self-hosted runner (mesin virtual yang terus menyala dan mengeksekusi job bergantian) rentan terhadap kebocoran data. Sisa-sisa kredensial, env variables, atau artefak dari build sebelumnya bisa diakses oleh build berikutnya jika tidak dibersihkan secara sempurna.
3. Penyimpangan Konfigurasi (Configuration Drift): Semakin lama sebuah server runner menyala, semakin besar peluang dependensi di dalamnya menjadi rusak atau tidak konsisten karena interaksi dari berbagai pipeline.

---

Solusi Masa Depan: Ephemeral Self-Hosted Runner

Pendekatan terbaik untuk mengatasi masalah di atas adalah menerapkan konsep Ephemeral Runner (Runner Sekali Pakai).

Prinsip Utama: Satu lingkungan eksekusi (pod atau VM) hanya dibuat ketika ada job CI/CD yang masuk, mengeksekusi tepat satu job tersebut, lalu langsung dihancurkan (terminated) segera setelah job selesai.

Berikut adalah diagram alur logis dari arsitektur ini:

[ Webhook Event ] ──> [ Autoscaling Controller ] ──> [ K8s / Cloud Provider ]
                             │                                │
                             ▼                                ▼
                     (Validasi Token)                (Spawn Ephemeral Pod)
                                                              │
                                                              ▼
                                                     [ Eksekusi CI/CD Job ]
                                                              │
                                                              ▼
                                                    [ Destroy Pod & Cleanup ]

Keuntungan Utama Arsitektur Ini:

• Isolasi Mutlak (Zero State Leakage): Setiap pipeline berjalan di atas lingkungan yang benar-benar bersih (immutability).
• Efisiensi Biaya (Scale-to-Zero): Ketika tidak ada aktivitas koding (misal: malam hari atau akhir pekan), infrastruktur komputasi runner akan menyusut hingga nol.
• Keamanan Jaringan: Runner berada di dalam VPC (Virtual Private Cloud) Anda sendiri, memungkinkan pipeline mengakses database internal atau cluster Kubernetes privat tanpa membuka firewall ke internet publik.

---

Mengimplementasikan Autoscaling Runner di Kubernetes (ARC)

Salah satu perkakas paling tangguh untuk menerapkan pola ini di ekosistem GitHub Actions adalah Actions Runner Controller (ARC) yang berjalan di atas Kubernetes. ARC mendengarkan webhook dari platform CI/CD dan secara dinamis membuat Pod Kubernetes baru sebagai runner.

Berikut adalah contoh manifest deklaratif HorizontalRunnerAutoscaler menggunakan ARC untuk mengatur skala runner secara otomatis berdasarkan beban kerja aktual:

apiVersion: actions.summerwind.dev/v1alpha1
kind: HorizontalRunnerAutoscaler
metadata:
  name: enterprise-runner-scaler
  namespace: actions-runner
spec:
  scaleTargetRef:
    name: enterprise-runner-deploy
  minReplicas: 0
  maxReplicas: 50
  metrics:
    - type: TotalNumberOfQueuedAndInProgressWorkflowRuns
      repositoryNames:
        - "organisasi-kita/core-api-service"
        - "organisasi-kita/frontend-monorepo"

Membedah Konfigurasi di Atas:

• minReplicas: 0: Memastikan efisiensi biaya maksimal. Jika tidak ada commit atau pull request, tidak ada biaya komputasi yang keluar.
• maxReplicas: 50: Batas atas untuk mencegah lonjakan biaya tak terkendali (denial-of-wallet) jika terjadi looping tak terbatas pada pipeline.
• TotalNumberOfQueuedAndInProgressWorkflowRuns: Metrik berbasis event ini memastikan scaling terjadi secara proaktif saat job masuk ke antrean, bukan menunggu utilisasi CPU runner penuh terlebih dahulu.

---

Optimalisasi Cache Jaringan untuk Memangkas Waktu Build

Tantangan terbesar dari arsitektur ephemeral adalah hilangnya local cache karena wadah eksekusi selalu baru. Jika setiap build harus mengunduh ulang ribuan dependensi (node_modules, Go modules, atau Maven dependencies), waktu build justru akan membengkak.

Untuk mengatasinya, integrasikan arsitektur ini dengan Distributed Remote Caching menggunakan protokol internal berkecepatan tinggi, seperti S3-compatible storage (MinIO atau AWS S3) yang terhubung melalui VPC Endpoint.

Contoh konfigurasi optimasi caching pada GitHub Actions dengan memanfaatkan penyimpanan internal:

name: Production Build & Security Scan
on: [push]

jobs:
  build:
    runs-on: self-hosted-ephemeral
    steps:
      - name: Checkout Source Code
        uses: actions/checkout@v4

      - name: Setup Node.js Environment
        uses: actions/setup-node@v4
        with:
          node-version: '20'

      - name: Cache Monorepo Dependencies
        uses: actions/cache@v4
        with:
          path: ~/.npm
          key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
          restore-keys: |
            ${{ runner.os }}-node-

      - name: Fast Install & Build
        run: |
          npm ci --prefer-offline
          npm run build

Dengan mengombinasikan opsi --prefer-offline dan cache yang tersimpan di jaringan lokal (VPC), waktu resolusi dependensi dapat dipangkas hingga 70-80% dibandingkan mengunduhnya langsung dari internet publik di setiap ephemeral run.

---

Matriks Perbandingan Strategi Infrastruktur CI/CD

Untuk memberikan gambaran yang komprehensif bagi tim arsitektur Anda, berikut adalah komparasi objektif antar model runner:

Dimensi Evaluasi	Managed Cloud Runner	Static Self-Hosted VM	Ephemeral Autoscaling Runner
Keamanan Data	Rendah (Pihak ketiga)	Sedang (Rawan kebocoran state)	Sangat Tinggi (Isolasi total)
Kontrol Jaringan	Terbatas (Butuh VPN/Proxy)	Penuh (Berada di VPC)	Penuh (Berada di VPC/K8s)
Kecepatan Antrean	Tergantung beban vendor	Lambat jika antrean menumpuk	Instan (Dibuat sesuai kebutuhan)
Efisiensi Biaya	Berdasarkan menit pemakaian	Boros (Server menyala 24/7)	Optimal (Pay-per-use sejati)
Overhead Maintenance	Nol	Sedang	Tinggi di awal (Setup IaC & K8s)

---

Kesimpulan: Kapan Anda Harus Bermigrasi?

Membangun arsitektur ephemeral self-hosted runner memang membutuhkan investasi waktu dan keahlian teknik di awal (operational overhead). Namun, jika organisasi Anda memenuhi kriteria berikut, migrasi ini bukan lagi sekadar opsi, melainkan kebutuhan mendesak:

• Anda beroperasi di industri dengan regulasi ketat (Fintech, HealthTech, GovTech) yang melarang kode atau data internal diproses di luar jaringan perusahaan.
• Tim pengembang Anda sering mengeluhkan waktu tunggu pipeline (build queue bottleneck).
• Tagihan bulanan untuk managed CI/CD minutes Anda sudah mulai melampaui biaya operasional klaster Kubernetes internal Anda sendiri.

Dengan mengadopsi otomatisasi CI/CD berbasis ephemeral runner, Anda tidak hanya mengamankan gerbang suplai perangkat lunak Anda (software supply chain), tetapi juga memberikan pengalaman kerja yang tangkas dan memuaskan bagi tim developer.