GitHub Actions’da Özel Runner İmajları: Kontrol Artık Sizde!
İlk Bakışta Özel Runner İmajları: “Nihayet!” Dedirten Yenilik
GitHub Actions tarafında biraz kafa patlatan herkes hosted runner’ların pratikliğini ve bir o kadar da can sıkıcı sınırlamalarını mutlaka fark etmiştir. Her build’da aynı eski setup, sürekli paket çekme, dependency güncelleme… Sanki döngüde dönüp duruyorsun! Arada insanın sabrını baya zorluyor (bizzat test ettim). İşte burada custom image desteği devreye giriyor — lafı dolandırmadan söyleyeyim: Valla bu özellik tam anlamıyla hayat kurtarıyor.
Bende ilk defa 2025’in sonbaharında bir finans müşterisiyle Azure DevOps ile GitHub Actions altyapısını karşılaştırırken preview olarak gelen custom image özelliğini test etme şansı doğdu. Açıkçası başlarda kuşkuluydum; ya stabilite sorun çıkarsa diye epey düşündüm. İmaj bozulursa ne olacak? Ama her sürümde biraz daha oturdu ve şimdi genel erişime açıldı. Yanı, abartmıyorum: Gerçek anlamda oyunu değiştiren bir adım öldü.
Custom Image Nedir? Hosting Runner’dan Farkı Ne?
Şöyle söyleyeyim, Klasik GitHub-hosted runner dediğimiz şey size birkaç hazır işletim sistemi (ubuntu-latest, windows-latest vs.) sunuyor. Özelleştirme yapmak isterseniz de pipeline’ın başında upuzun setup script’leriyle cebelleşmek zorunda kalırsınız (ben de ilk duyduğumda şaşırmıştım). Bir de eksik modül draması, dependency nerde kaldı kargaşası…
- Kurumun güvenlik sertifikasını ekle
- Kendi script toolset’ını ortamda hazır tut
- Sıkıntılı dependency versiyonlarını pin’le
- Sık kullanılan CLI araçları önceden yükle
Açıkçası, Küçük bir startup için belki 30 saniye kaybetmek dert değil. Büyük entegrasyonlarda yüzlerce pipeline koşturunca işler çığırından çıkıyor. Geçen yıl Logosoft’taki e-ticaret projemizde klasik runnerlarla job süresi 8-9 dakika iken, custom imajla 3 dakikaya indi! Ekip şaşkınlıktan gözlerini açamadı.
Neden Kendi Imajınızı Kurmalısınız?
Standartlaştırma: Herkes Aynı Zeminde Başlıyor
Hani, “Staging neden prod gibi davranmıyor ya?” sorusu kadar moral bozucu az şey vardır yazılımda… En çok da de de enterprise tarafta branch bazında farklı araç versiyonu kaos çıkarıyor. Custom image ile tüm ekipler aynı tabanda başlıyor; ortalık karışmıyor.
Hız Kazanmak Mümkün mü?
Peki hız artışı var mı? Kesinlikle! En net örneği şöyle anlatayım: Bir data science ekibi Jupyter + Python + spesifik C++ lib’lerine ihtiyaç duyuyordu; setup öyle uzuyordu ki CI/CD’ye burun kıvırmaya başladılar resmen (inanın bana). İşte, custom image ile işleri çözdük; ilk run %70 hızlandı — abarttığımı düşünebilirsin ama bizzat yaşadım!
Maliyetler ve Operasyonel Basitlik
Burası genelde arada kaynıyor ama custom image sayesinde init script masrafından ciddi oranda yırtıyorsunuz — daha az hata demek daha az debug işi yanı saat harcamak azalıyor. Tabiî imaj bakımına gelince iş değişiyor… Oraya da geleceğim.
Her şey güllük gülistanlık değil tabiî; imaj yönetimi ekstra yük getiriyor — eski imajların güncelliğini takip etmeyi unutursan zincirin en zayıf halkası olabilirsin!
Peki Nasıl Çalışıyor? Adım Adım Kendi Imajınızı Oluşturmak
Başlangıç İçin Bir Temel Şart mı Var?
Sürekli şu soru geliyor bana:”Sıfırdan VM mi yaratacağız?” Hayır dostum! GitHub curated base images veriyor sana – mesela Ubuntu’nun stabilize snapshot’ları var ellerinde. Sen bunun üstüne istediğin gibi inşa ediyorsun.
Kodla Anlatmak Daha Kolay:
# Basit bir Dockerfile örneğiFROM ghcr.io/github/runner-base/ubuntu-latest
# Sık kullandığın araçlar gelsin
RUN apt-get update
&& apt-get install - y jq curl git
# Python ve pip modüllerini gömelim
RUN apt-get install - y python3-pip
&& pip install --no-cache-dir numpy pandas scikit-learn
# Sertifika ekleme işi
COPY mycorp-rootCA.crt /usr/local/share/ca-certificates/
RUN update-ca-certificates
İmaj Yükleme ve Kullanma Senaryosu:
- İmajını build edip registry’e push’luyorsun (GitHub Container Registry veya Azure Container Registry olur).
- .github/workflows altındaki ilgili job’da runner-image olarak kendi container tag’ını gösteriyorsun.
- Tetikleyip çalıştırıyorsun; başka işlem yok!
Bazı projelerde docker layer cache kullanımı kritik derecede hız kazandırıyor — özellikle veri bilimi işlerinde çok net gördüm bunu. Daha fazla bilgi için github ile ilgili önceki yazımız bakabilirsiniz.
Zorluklar & Tuzaklar – Gerçek Hayattan Kısa Notlar
İmaj Yönetimi Sandığınız Kadar Kolay Değil!
Açık konuşalım; herkes ilk başta gazla girişiyor ama zamanla eski imajların güncellenmesi unutulabiliyor resmen… Mesela bir müşterimizde (2026’nın hemen başlarında), log4j faciasında haftalarca eski imajlardan sızma olup olmadığını aramak zorunda kaldık! Otomatik security scanning olmadan risk büyük — entegre etmek şart öldü artık.
Sürüm Takibi – Kaos mu Düzen mi?
| Sorun | Klasik Runner’da | Custom Image’da |
|---|---|---|
| Araç Versiyonu Sabitleme | Zorlayıcı; init script ile uğraşırsın | İmajda direkt sabitlendi |
| Anlık Güncelleme Yayma | Tüm workflow’u elle update gerekir | İmaj registry’den tek hamlede yayılır |
| Büyük Güvenlik Açığı Krizi (örn log4j) | Tüm akışlarda manuel patch lazım | İmaj rebuild+push = otomatik yayılır* |
| Dökümantasyon Yükü | Düşük ama kaotik ortam riski yüksek | Daha fazla disiplin ister |
*Not: Dağıtımdan önce test pipeline koymazsan yeni imaj bütün işleri mahvedebilir!
Bir defasında canlıya aniden rollout yaptık ve gece boyu debelendik…
Küçük Startup vs Kurumsal Devler – Hangisine Ne Kadar Lazım?
- Küçük Startup: Kod hızlı değişiyorsa ve sürekli deneme yapılıyorsa klasik runner iş görür aslında… Dependency cehennemine düştüğünde ancak custom image’a geçmek mantıklı oluyor.
- Büyük Kurum: ISO/SOC uyumu şart işe veya environment drift yüzünden hatalar fırlıyorsa custom image kaçınılmaz hâle geliyor.
Bak başka yol pek yok.
Siber Güvenlik Odaklı Proje: Root CA sertifika eklemek ya da özel network bağlantısı gerekiyorsa zaten alternatifsizsin!
Ama hybrid çözümü deneyebilirsin:
Kritik işler custom image üzerinde koşsun,
gerisi klasik hosted runner’da devam etsin.
Böylece hem operasyonel maliyet dengelenir hem de risk dağıtılmış olur…
Deneyen ekiplerden feedback aldığım öldü — gayet işe yaradı diyebilirim.
Yanı gelecekte bu konuya el atmazsak bizden sonra ağlayan çok olacak…
Birkaç Pratik İpucu – Kendi Deneyimlerimden “Acı Reçeteler” 😅
- İmaj Layer Sayısını Abartmayın – Fazla layer push/pull sürelerini acayip artırabiliyor (Bunu canlı gördüm, kimse inanmadı!)
Ekim ’25’de prod deploy’da saçımız diken diken olmuştu…
Kısacası minimalizm iyidir.
İmaj Güncellemelerini Otomasyona Bağlayın –
Dependabot tarzı tool devreye alıp version drift’i engelleyin;
Aksi durumda her yerde farklı dependency kalabiliyor.
Sertifika Zinciri Ekliyorsanız Test Pipeline’da Kontrol Edin —
Yanlış certificate chain nedeniyle production deploy gece üçte patladı,
Logosoft SaaS projesinin release’i rezil öldü!
Maliyet Hesabını Unutmayın —
Büyük boyutlu imaj storage maliyetini fırlatabiliyor,
FinOps tarafında öğrendiklerimin çoğu tam burada işe yaradı.
Dökümantasyonu Eksiksiz Tutun —
Yoksa iki ay sonra “Kim hangi library’i niye ekledi?” sorusunun cevabı ortada bulunamıyor…
Caching’i Mantıklı Kullanmak Şart —
Layer bazlı reusable bloklar oluşturup gereksiz rebuild’den kaçının!
Her run’da sıfırdan toplama yapmak pilinizi bitirir.
Kritik job’larda yeni imaja önce canary deployment şeklinde minik ölçekle test edin;
Toplu rollout felaket getirebilir…
Maalesef bunları bizzat yaşayarak öğrenmiş biri olarak söylüyorum!
Neleri Beklememek Lazım? Eksikler ve Hayal Kırıklıkları… 🙃
Aklımdaki en büyük hayal kırıklıkları listesi şöyle…
- Docker layer cache tüm pipeline çeşitlerinde stabil çalışmıyor;
Mesela de self-hosted sistemden gelenlerin dikkat etmesi gereken detay bu.
İmaj bakımı ekstra operasyonel yük bindiriyor —
Ekibinizde hiç DevOps tecrübesi olmayan varsa başlangıçta zorlanabilirler,
bu konuda dürüst olmak gerek!
Bazı edge case’lerde kernel/gpu driver ihtiyacı varsa hâlâ klasik self-hosted VM’e geri dönmeniz gerekecek.
AI projelerinde birkaç kez böyle tuzağa düştük…
Beklediğim en büyük eksiklik hâlâ GUI destekleyen özel runner’ın olmayışıydı —
Desktop uygulama testlerinde workaround peşindeyiz hâlâ!
Ama geliştiriciler çalışmaya devam ediyor gibi görünüyor…
Belki yakındır?
Maalesef henüz tatmin edici sonuç alamadık.
Sıkça Sorulan Sorular
Custom image ile hosted runner arasındaki temel fark ne?
Hosted runner, ubuntu-latest ya da windows-latest gibi hazır ortamlar sunuyor; özelleştirme için pipeline başında uzun kurulum script’leri yazman gerekiyor. Custom image ise kendi araçlarını, environment ayarlarını ve sertifikalarını runner’a daha build başlamadan gömüyor. Böylece her job’ta sıfırdan dependency kurma derdi azalıyor.
Custom image kullanınca build süreleri gerçekten kısalıyor mu?
Evet, özellikle her job’da tekrar tekrar kurulan bağımlılıklar varsa hız ciddi artıyor. Yazıda geçen örnekte klasik runnerlarla job süresi 8-9 dakikayken custom imajla 3 dakikaya indi. Bir başka senaryoda da ilk run yaklaşık %70 hızlanmış.
Custom image bozulursa ya da güncelleme sonrası sorun çıkarsa ne yapılıyor?
Başta en çok kuşku duyulan konu bu; imaj bozulursa job’lar etkilenebilir. Ancak sürümler oturdukça stabilite iyileşiyor ve özellik genel erişime açılıyor. Yine de pratikte imajı versiyonlayıp kontrollü güncellemek, sürpriz arızaları azaltıyor.
Custom image maliyet ve operasyonel yükü nasıl etkiliyor?
Custom image sayesinde her job için init script masrafı azalıyor ve daha az hata çıktığı için debug süresi düşüyor. Bu da ekiplerin saat harcamasını azaltıyor. Tabii imaj bakımına geçince iş biraz başka tarafa kayıyor; imajı güncel tutmak ayrı bir sorumluluk oluyor.
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
