GitHub Runner, GitHub Actions içindeki job’ları çalıştıran ajandır. GitHub varsayılan olarak GitHub-hosted runner sunar; bu makineleri GitHub yönetir. Self-hosted runner ise sizin dağıttığınız ve yönettiğiniz makinedir. Fiziksel sunucu, sanal makine, container, on-premises ortam veya cloud instance olabilir.
Self-hosted runner’a yönelen ekipler genellikle iki şeyi aynı anda çözmeye çalışır: derleme işlerinin kurum içi ağa erişmesi ve CI/CD kapasitesinin kontrol altına alınması. Bu karar doğru olabilir; fakat güvenlik ve işletme sorumluluğu açıkça tanımlanmazsa runner altyapısı iç ağa açılan zayıf halkaya dönüşür.
Ne zaman mantıklı?
Self-hosted runner şu durumlarda değerlendirilebilir:
- Pipeline’ın kurum içi veritabanı, artifact deposu, test ortamı veya private API’ye erişmesi gerekiyorsa.
- GPU, ARM, yüksek bellek, özel işletim sistemi veya lisanslı derleme aracı gerekiyorsa.
- Build ortamındaki araç sürümlerini ve imajları standartlaştırmak istiyorsanız.
- GitHub-hosted runner kotaları, coğrafi ihtiyaçlar veya ağ kısıtları yetersiz kalıyorsa.
- Enterprise Server veya kapalı ağ senaryosunda Actions işlerini içeride çalıştırmanız gerekiyorsa.
Asıl sorumluluklar
GitHub dokümanı self-hosted runner için net bir ayrım yapar: runner uygulaması güncellenebilir, ancak işletim sistemi ve kurulu yazılımların güncellenmesi sizin sorumluluğunuzdadır. Pratikte sorumluluk listesi şöyledir:
- Runner makinesinin patch yönetimi
- Base image ve toolchain güncellemeleri
- Ağ segmentasyonu ve firewall kuralları
- Gizli bilgilerin hangi job’lara verileceği
- Log ve artifact içinde hassas veri sızıntısı kontrolü
- Kapasite planlama ve kuyruk süreleri
- Runner token’larının yaşam döngüsü
Güvenlik modeli: güvenilmeyen kodu ayırın
Self-hosted runner’ın en kritik riski, dışarıdan gelen veya tam güvenilmeyen kodun sizin makinenizde çalışmasıdır. Özellikle public repository, fork pull request, dış katkı ve pull_request_target gibi akışlar dikkat ister.
Somut güvenlik kararları:
- Public repository için self-hosted runner kullanmadan önce ayrı risk değerlendirmesi yapın.
- Fork PR işlerini, üretim ağına erişen runner havuzunda çalıştırmayın.
- Build ve test job’ları için minimum gizli bilgi sağlayın; deploy anahtarlarını her job’a vermeyin.
- Runner’ı staging/test ağıyla sınırlandırın; üretim veritabanına doğrudan erişim vermeyin.
- Kısa ömürlü runner kullanın; iş bitince çalışma dizini ve makine/pod temizlensin.
- Aynı host üzerinde farklı güven seviyesindeki projeleri koşturmayın.
Kubernetes ve ARC
Actions Runner Controller, runner’ları Kubernetes üzerinde çalıştırmak ve talebe göre ölçeklemek için yaygın bir yoldur. Her job için pod oluşturulması, iş bitince pod’un silinmesi ve node ölçeklemesiyle kapasite yönetimi kolaylaşır.
Ancak ARC kullanmak tek başına güvenlik garantisi değildir. Aşağıdaki tasarım kararları ayrıca verilmelidir:
- Hangi repository veya organizasyon hangi runner group’a erişebilir?
- Runner pod’larının namespace, service account ve network policy sınırı nedir?
- Image build için privileged Docker-in-Docker mı kullanılacak, yoksa daha sınırlı bir yöntem mi seçilecek?
- Cache ve artifact depolarında proje ayrımı nasıl yapılacak?
- Runner imajı kim tarafından ve nasıl güncellenecek?
Maliyet gerçekte nerede oluşur
Self-hosted runner GitHub’ın dakika ücretini ortadan kaldırır, maliyeti sıfırlamaz. Faturayı şu kalemler oluşturur:
- Makine kapasitesi: Runner’lar sabit sunucuda duruyorsa iş olmadığı saatlerde de ödeme yaparsınız. Kubernetes üzerinde talebe göre ölçeklendiğinde bu kalem işin süresine iner.
- Depolama ve önbellek: Bağımlılık önbelleği, imaj katmanları ve iş çıktıları hızlı büyür. Önbelleği kapatmak süreyi, sınırsız bırakmak diski büyütür.
- Ağ trafiği: Her işte imaj ve paket indiriliyorsa hem süre hem trafik artar. Kurum içi registry aynası bu kalemi belirgin biçimde düşürür.
- Bakım zamanı: İşletim sistemi yamaları, runner ve imaj güncellemeleri, sürüm uyumsuzluklarının ayıklanması. Bu kalem genelde hesaba katılmaz, sonra en pahalısı çıkar.
Pratikte kararı şöyle veriyoruz: derleme süreleri kısa ve işler kurum içi ağa erişmiyorsa GitHub-hosted runner daha ekonomiktir; işler uzun sürüyorsa, büyük önbellek kullanıyorsa, özel donanım (GPU, ARM) veya kurum içi veritabanı/registry erişimi gerekiyorsa self-hosted runner kazanır.
Maliyeti düşüren dört karar:
- Runner’ları talebe göre ölçekleyin; boşta bekleyen kalıcı havuz tutmayın.
- Bağımlılık ve imaj önbelleğini kurum içinde tutun, saklama süresine sınır koyun.
- İş türüne göre ayrı havuz kullanın; her işi en büyük makinede çalıştırmayın.
- Kuyruk süresini ölçün. Kapasite kararı tahminle değil, bekleme süresiyle verilir.
Resmi kaynaklar
- GitHub’ın genel açıklaması: About self-hosted runners
- Gereksinimler, routing ve autoscaling: Self-hosted runners reference
- Plan ve kullanım koşulları: GitHub Pricing
Mono ne zaman yardımcı olur?
- Runner group ve label stratejisi
- ARC ile Kubernetes tabanlı runner havuzu
- Public/private repository ayrımı
- Gizli bilgi kapsamı ve deploy yetki modeli
- Image build güvenliği
- Kuyruk, kapasite ve gözlemleme tasarımı
