GitLab Runner: Shell vs Docker Executor

GitLab Runner mengeksekusi job dari .gitlab-ci.yml. Pemilihan executor menentukan isolasi, kebersihan environment, dan cara job berinteraksi dengan host.

ArsitekturCopy Anchor Link

GitLab ──job──▶ GitLab Runner ──▶ Executor ──▶ Job
                                  ├── shell
                                  ├── docker
                                  ├── kubernetes
                                  └── ssh

Instalasi runnerCopy Anchor Link

Debian/UbuntuCopy Anchor Link

curl -L "https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh" | bash
apt install -y gitlab-runner
gitlab-runner --version
systemctl status gitlab-runner --no-pager

RegistrasiCopy Anchor Link

Dapatkan URL dan token dari GitLab → Settings → CI/CD → Runners.

gitlab-runner register \
  --non-interactive \
  --url https://gitlab.com/ \
  --token "$RUNNER_TOKEN" \
  --executor docker \
  --docker-image alpine:latest \
  --description "docker-runner-01" \
  --tag-list "docker,linux"

Cek:

gitlab-runner list
gitlab-runner verify

Shell executorCopy Anchor Link

Job berjalan langsung di mesin runner memakai shell.

[[runners]]
  name = "shell-runner"
  url = "https://gitlab.com/"
  token = "TOKEN"
  executor = "shell"

Shell executor sering dipakai untuk deployment ke server yang sama dengan runner.

Docker executorCopy Anchor Link

Setiap job berjalan di container baru.

[[runners]]
  name = "docker-runner"
  url = "https://gitlab.com/"
  token = "TOKEN"
  executor = "docker"
  [runners.docker]
    image = "alpine:latest"
    privileged = false
    volumes = ["/cache", "/var/run/docker.sock:/var/run/docker.sock"]
    cache_dir = "/cache"

Docker-in-Docker vs socket bindingCopy Anchor Link

Socket binding praktis, tetapi sangat berbahaya untuk job tidak tepercaya.

CacheCopy Anchor Link

[runners]
  cache_dir = "/cache"

[runners.docker]
  volumes = ["/cache"]

Di .gitlab-ci.yml:

cache:
  key: "$CI_COMMIT_REF_SLUG"
  paths:
    - node_modules/

Untuk cache terpusat, gunakan S3/MinIO/GCS.

TagsCopy Anchor Link

Runner hanya mengambil job dengan tag yang cocok.

deploy:
  tags: [shell, production]
  script: ./deploy.sh

Pisahkan runner berdasarkan kebutuhan:

• docker untuk build image.
• shell untuk deploy host.
• gpu untuk job khusus.
• production dengan akses terbatas.

Konfigurasi config.tomlCopy Anchor Link

Lokasi umum: /etc/gitlab-runner/config.toml.

concurrent = 4
check_interval = 0

[[runners]]
  name = "docker-runner"
  url = "https://gitlab.com/"
  token = "TOKEN"
  executor = "docker"
  [runners.docker]
    image = "node:22-alpine"
    privileged = false
    disable_entrypoint_overwrite = false
    shm_size = 0

concurrent membatasi job paralel. Terlalu tinggi dapat menghabiskan CPU/RAM.

KeamananCopy Anchor Link

• Jangan gunakan runner bersama untuk repo publik dengan secret produksi.
• Batasi tag dan protected runner.
• Jalankan runner sebagai user non-root.
• Perbarui runner secara rutin.
• Pisahkan runner produksi dari runner build umum.
• Audit volume dan akses Docker socket.

Praktik: memilih executorCopy Anchor Link

1. Build dan test → Docker executor.
2. Deploy ke host → Shell executor di host tersebut.
3. Butuh isolasi penuh tanpa akses host → Docker executor tanpa socket.
4. Butuh build image → DinD atau kaniko/buildah.
5. Butuh skala besar → Kubernetes executor.

RingkasanCopy Anchor Link

• Runner mengeksekusi job; executor menentukan lingkungan.
• Shell cepat tetapi tidak terisolasi.
• Docker memberi isolasi dan reproducibility, dengan biaya overhead.
• Tag, concurrency, cache, dan keamanan runner harus direncanakan.