Yükleniyor
Bulut Altyapı DevOps , , , , , , ,
GitHub Actions’da Özel Runner İmajları: Kontrol Artık Sizde!
GitHub Actions’da Özel Runner İmajları: Kontrol Artık Sizde!
⏱️ 7 dk okuma📅 29 Mart 2026🔄 Güncelleme: 3 Nisan 2026👁️ 13 görüntülenme

İ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ı. Yani, abartmıyorum: Gerçek anlamda oyunu değiştiren bir adım oldu.

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ı…

💡 Bilgi: Custom image ile kendi araçlarını, environment ayarlarını, sertifikalarını daha build başlamadan runner’a gömüyorsun. Böylece her run sıfırdan kurulum derdi yok; “Ay bunu da mı yükleyeceğiz?” stresinden kurtulmak güzel oluyor.
  • 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! Veritabanı Federasyonu: Data API Builder Zincirleme ile Farklı Sistemleri Birleştirmek yazımızda bu konuya da değinmiştik. Açık Kaynak Güvenlik Açıkları: 2025’te Neler Değişti, Ne Anlama Geliyor? yazımızda bu konuya da değinmiştik. Bu konuyla ilgili GitHub Issues ve Projelerde Ajan Aktivitesi: Gerçekten Ne Değişti? yazımıza da göz atmanızı tavsiye ederim.

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 yani saat harcamak azalıyor. Tabii imaj bakımına gelince iş değişiyor… Oraya da geleceğim. Daha fazla bilgi için Microsoft Entra’da Sonradan Görülen Tutarlılıkla Yaşamak: Hayal Kırıklığı mı, Gerçekçi Bir Mimarı mi? yazımıza bakabilirsiniz.

Her şey güllük gülistanlık değil tabii; 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ği

FROM 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

Imaj Yükleme ve Kullanma Senaryosu:

  • Imajı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

Imaj 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 oldu 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 Imajda direkt sabitlendi
Anlık Güncelleme Yayma Tüm workflow’u elle update gerekir Imaj registry’den tek hamlede yayılır
Büyük Güvenlik Açığı Krizi (örn log4j) Tüm akışlarda manuel patch lazım Imaj 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 oldu — gayet işe yaradı diyebilirim.

💡 Bilgi: GitHub Actions’ın yeni güvenlik yol haritasıyla (burada detayı var!) özel imajların zero trust yaklaşımında anahtar rol oynayacağı netleşti.
Yani gelecekte bu konuya el atmazsak bizden sonra ağlayan çok olacak…

Birkaç Pratik İpucu – Kendi Deneyimlerimden “Acı Reçeteler”  😅

  • Imaj 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.

  • Imaj 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 oldu!

  • 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…

İçeriği paylaş:

İlgili Yazılar

📬 Bu yazıyı faydalı buldunuz mu?

Azure, DevOps ve bulut teknolojileri hakkında güncel içerikler için beni takip edin!

Etiket

Yorum gönder

A.KILIÇ

Microsoft Azure Çözüm Uzmanı | Bulut Bilişim, Yapay Zekâ, DevOps ve Kurumsal Güvenlik alanlarında 15+ yıl deneyim. Azure, Kubernetes, AI/ML ve modern altyapı mimarileri üzerine yazılar yazıyorum.

tüm yazıları gör

İlginizi Çekebilir

SİZİN İÇİN DERLEDİK

© 2026 Aşkın KILIÇ | Tüm hakları saklıdır. | Tasarım SpiceThemes