Belajar GitLab CI/CD - Menyiapkan & Mengelola GitLab Runners

#Pendahuluan

Di episode 2 kalian berhasil membuat .gitlab-ci.yml pertama dan pipeline berjalan. Tapi pernahkah kalian bertanya: siapa yang sebenarnya menjalankan job itu? Jawabannya adalah GitLab Runner — pahlawan di balik layar yang mengambil job dari antrean dan mengeksekusinya. Episode ini membedah klasifikasi tipe runner, jenis executor, cara registrasi, dan bagaimana tags mengarahkan job ke runner yang tepat.

Pemahaman ini krusial: di perusahaan besar, arsitektur runner menentukan kecepatan, biaya, dan keamanan seluruh pipeline. Keputusan seperti "jalankan di shared runner atau dedicated runner?" dan "pakai Docker executor atau Kubernetes executor?" adalah keputusan arsitektur, bukan sekadar konfigurasi.

#Pembahasan Utama

#Klasifikasi Tipe GitLab Runner

Runner bisa dibedakan berdasarkan cakupan (scope) pelayanannya:

• Shared Runners — disediakan GitLab.com secara gratis untuk semua pengguna; pada instance self-hosted, shared runner dikonfigurasi admin untuk seluruh instance. Cocok untuk mulai belajar tanpa infrastruktur sendiri.
• Group Runners — dimiliki satu Group/Organisasi dan melayani semua project di dalam group tersebut. Ideal untuk standarisasi kapasitas antar project dalam satu tim.
• Specific / Project Runners — dedicated untuk satu project saja. Dipakai untuk kebutuhan khusus: hardware GPU, requirement keamanan, atau isolasi lingkungan.

Analogi sederhananya: shared runner seperti layanan antar-jemput umum, group runner seperti bus antar-jemput kantor untuk semua divisi, dan specific runner seperti mobil pribadi yang hanya melayani satu kantor — dengan spesifikasi yang bisa disesuaikan.

#Tipe Executor pada GitLab Runner

Executor menentukan cara runner mengeksekusi job. Tiga yang paling populer:

• Shell executor — mengeksekusi script langsung di OS host runner. Paling sederhana dan cepat, tapi job tidak terisolasi: script bisa menyentuh file dan service host. Cocok untuk mesin sederhana atau kebutuhan akses host.
• Docker executor — menjalankan job di dalam container Docker yang terisolasi. Paling populer karena bersih, konsisten, dan memakai image yang berbeda per job (lewat keyword image). Ini standar untuk pipeline produksi.
• Kubernetes executor — membuat pod baru per job secara dinamis di cluster Kubernetes. Ideal untuk skala besar: pod di-spawn saat ada job dan dihapus setelah selesai, sehingga pemanfaatan resource efisien.

Analoginya: shell executor seperti memasak langsung di dapur umum, docker executor seperti memasak di panci sendiri yang bersih dan bisa dibawa, sedangkan kubernetes executor seperti memesan koki baru untuk setiap pesanan.

#Instalasi GitLab Runner

Runner dijalankan di mesin yang kalian kontrol — laptop, VM, atau server CI. Instalasi di Ubuntu/Debian menggunakan repository resmi GitLab:

curl -sS https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh | sudo bash
sudo apt-get update
sudo apt-get install -y gitlab-runner
gitlab-runner --version

Runner terdaftar sebagai service sistem (gitlab-runner), dan seluruh konfigurasi disimpan di /etc/gitlab-runner/config.toml.

#Registrasi Runner

Setiap runner harus didaftarkan ke GitLab dengan token unik. Token diambil dari Settings → CI/CD → Runners di project, group, atau instance — tergantung tipe runner yang ingin dibuat. Contoh registrasi non-interaktif:

gitlab-runner register \
  --url https://gitlab.com/ \
  --token glrt-XXXXXXXXXXXX \
  --executor docker \
  --description "docker-runner-01" \
  --docker-image alpine:3.20

Parameter yang paling penting:

• --url — alamat instance GitLab (https://gitlab.com/ untuk SaaS).
• --token — token registrasi dari halaman Runners.
• --executor — tipe executor yang dipakai (docker, shell, kubernetes, dll).
• --docker-image — image default untuk job yang tidak menulis keyword image sendiri.

Hasil registrasi tersimpan di /etc/gitlab-runner/config.toml — versi ringkasnya:

concurrent = 4
 
[[runners]]
  name = "docker-runner-01"
  url = "https://gitlab.com/"
  executor = "docker"
  [runners.docker]
    image = "alpine:3.20"
    privileged = false

#Tags: Mengarahkan Job ke Runner Spesifik

Setelah runner terdaftar, kalian bisa memberinya tags — label yang dipakai job untuk memilih runner mana yang mengerjakan pekerjaannya. Daftarkan dengan --tag-list:

gitlab-runner register \
  --url https://gitlab.com/ \
  --executor docker \
  --tag-list "docker,high-cpu"

Di dalam .gitlab-ci.yml, job memakai keyword tags untuk meminta runner dengan label tersebut:

deploy_prod:
  stage: deploy
  script:
    - ./deploy.sh
  tags:
    - docker
    - high-cpu

Job deploy_prod hanya akan diambil oleh runner yang memiliki semua tag tersebut. Jika tidak ada runner yang cocok, job akan menganggur (stuck) selamanya. Aturan praktis: gunakan tags untuk routing yang benar-benar spesifik — misal arsitektur (amd64), hardware (gpu), atau tipe job (build, deploy) — bukan untuk menggantikan konfigurasi executor.

#Verifikasi dan Pemantauan Runner

Untuk memastikan runner sehat dan terdaftar, gunakan perintah berikut:

gitlab-runner status
gitlab-runner list
glab runner list

#Kesalahan Umum

1. Job stuck (status pipeline menggantung). Pipeline tidak pernah selesai karena tidak ada runner yang cocok dengan tag yang diminta, atau shared runner sedang mati. Cek halaman Runners dan daftar tag.
2. Runner tidak mengambil job tak bertag. Secara default, runner yang punya tag hanya menerima job yang juga punya tag. Jika kalian ingin runner menerima semua job, daftarkan dengan --run-untagged=true.
3. Menjalankan runner di laptop pribadi. Untuk produksi, jangan menjalankan runner di mesin kerja kalian — kode dari orang lain akan dieksekusi di mesin tersebut. Gunakan VM, container, atau server khusus.

#Penutup

Pada episode 3 ini kalian telah menguasai sisi infrastruktur GitLab CI/CD:

• Klasifikasi runner: shared (seluruh instance), group (satu organisasi), dan specific (satu project).
• Tipe executor: shell (langsung di host), docker (container terisolasi, paling populer), dan kubernetes (pod dinamis).
• Registrasi runner dengan gitlab-runner register beserta --url, --token, --executor, dan --docker-image.
• Routing job memakai tags dengan keyword tags, plus verifikasi dengan gitlab-runner status, gitlab-runner list, dan glab runner list.

Sekarang pipeline kalian punya tenaga kerja yang jelas. Di episode 4 kita akan mengendalikan kapan pekerjaan itu dijalankan — dynamic control flow dengan rules dan workflow: perbedaan only/except yang legacy vs rules modern, kondisi if, changes, exists, parameter when, dan mencegah duplicate pipeline dengan workflow: rules. Sampai jumpa di episode 4!