GitLab Runner, .gitlab-ci.yml içinde tanımlanan job’ları çalıştıran ajandır. GitLab sunucusu pipeline’ı planlar; runner ise işi fiilen çalıştırır ve sonucu GitLab’a raporlar. Bu yüzden GitLab Runner, CI/CD’nin yalnızca yardımcı bileşeni değil, güvenlik ve kapasite kararının merkezidir.
Runner konusunda en sık sorulanlar şunlardır: pipeline neden kuyrukta bekliyor, hangi executor seçilmeli, Kubernetes’e geçmeli miyiz ve gizli bilgileri nasıl koruruz? Bu sorular ayrı ayrı değil, tek bir runner mimarisi kararı olarak ele alınmalıdır.
Executor seçimi
Runner’ın işi nerede çalıştıracağını executor belirler:
| Executor | Ne zaman uygun? | Dikkat noktası |
|---|---|---|
| Docker | Standart build/test işleri, container tabanlı toolchain | Docker socket, cache ve image güvenliği tasarlanmalı |
| Kubernetes | Dinamik ölçek, pod izolasyonu, büyük CI trafiği | Namespace, service account ve network policy sınırları gerekir |
| Shell | Özel donanım veya çok basit güvenilen işler | İzolasyon zayıftır; güvenilmeyen kod için uygun değildir |
| SSH / özel modeller | Mevcut uzak makinelerde iş çalıştırma | Bakımı ve erişim kontrolü daha dikkat ister |
Kubernetes executor modern ekipler için güçlüdür; her job ayrı pod olarak çalıştırılabilir ve iş bitince ortam temizlenebilir. Ancak Kubernetes kullanmak otomatik olarak güvenli yapmaz. Pod yetkileri, node seçimi, image pull izinleri ve ağ politikaları ayrıca yapılandırılmalıdır.
Shared, group ve project runner
Runner paylaşımı bir maliyet/izolasyon kararıdır:
- Shared runner: Çok sayıda proje ortak kullanır. Yönetimi kolaydır, ancak güvenlik ve kuyruk kontrolü sınırlı olabilir.
- Group runner: Aynı ekip veya ürün ailesi için dengeli modeldir. Ortak standart korunurken erişim sınırı çizilebilir.
- Project runner: Hassas iş, özel donanım, production deploy veya lisanslı araç gerektiren projelerde tercih edilir.
Her job aynı güven seviyesinde değildir. Test job’ı, image build job’ı ve production deploy job’ı aynı runner havuzunda çalışmamalıdır.
Güvenlik: gizli bilgiyi job’a göre verin
Runner güvenliğinde temel prensip, job’ın yalnızca ihtiyacı olan erişimi almasıdır.
Somut kontroller:
- Merge request job’ları için production deploy anahtarı sağlamayın.
- Fork veya dış katkı pipeline’larını iç ağa erişen runner’da çalıştırmayın.
- Protected branch/tag şartı olmadan hassas değişkenleri açmayın.
- Shell executor’ı güvenilmeyen kodda kullanmayın.
- Runner cache’ini proje ve güven seviyesi bazında ayırın.
- Privileged container kullanımını istisna haline getirin.
- Deploy job’larını ayrı runner tag’i ve onay mekanizmasıyla sınırlandırın.
Burada “secret” yerine pratik soru şudur: Bu job hangi gizli bilgiye, hangi ortamda, ne kadar süreyle erişiyor?
Image build: DinD her zaman doğru cevap değil
Docker-in-Docker bazı pipeline’larda kolaylık sağlar; fakat privileged çalışma ve Docker daemon erişimi nedeniyle risk doğurabilir. Image build için şu seçenekler karşılaştırılmalıdır:
- BuildKit veya rootless build yaklaşımları
- Kaniko benzeri daemon gerektirmeyen build araçları
- Ayrı ve izole DinD runner havuzu
- Merkezi build cache ve base image yönetimi
Eğer DinD gerekiyorsa, bunu tüm runner havuzuna açmak yerine sadece image build job’larına ayrılmış runner’larda çalıştırmak daha güvenli olur.
Kapasite ve maliyet
Runner kapasitesi yanlış planlandığında geliştirici deneyimi bozulur: pipeline kuyrukları uzar, cache verimsizleşir, büyük image pull işlemleri ağı tüketir. Satın alma ve işletim kararında şu metrikler izlenmelidir:
- Ortalama ve p95 pipeline bekleme süresi
- Runner doluluk oranı
- Job başına CPU/bellek ihtiyacı
- Cache hit oranı
- Artifact ve container image storage büyümesi
- Başarısız job tekrarlarının oranı
GitLab.com kullanıyorsanız compute minutes ve plan sınırları; self-managed kullanıyorsanız VM/Kubernetes kapasitesi, bakım ve izleme maliyeti birlikte değerlendirilmelidir.
Resmi kaynaklar
- Runner kurulumu ve executor ayrıntıları için GitLab Runner documentation
- GitLab CI/CD temelleri için GitLab CI/CD documentation
- Plan ve compute ayrımı için GitLab Pricing
Mono ne zaman yardımcı olur?
- Docker/Kubernetes/Shell executor seçimi
- Runner group ve tag stratejisi
- Güvenilmeyen job ayrımı
- Gizli bilgi kapsamı ve protected branch modeli
- Kubernetes executor kurulumu ve ağ politikaları
- Image build güvenliği ve cache tasarımı
- Pipeline kuyruk ve kapasite analizi
