GitHub Actions ile Self-Hosted Runner Yapılandırması: Özelleştirilmiş CI/CD Ortamları Oluşturma

GitHub Actions, modern yazılım geliştirme süreçlerinin ayrılmaz bir parçası haline gelmiştir. Standart GitHub tarafından yönetilen runner'lar çoğu senaryo için yeterli olsa da, bazı durumlarda bu varsayılan ortamlar kısıtlayıcı olabilir. İşte bu noktada self-hosted runner'lar devreye girer. Kendi altyapınız üzerinde çalıştırdığınız bu runner'lar, CI/CD iş akışlarınıza benzersiz bir esneklik ve kontrol sağlar.

Neden Self-Hosted Runner Kullanmalısınız?

GitHub tarafından sağlanan sanal makineler (GitHub-hosted runner'lar) çeşitli işletim sistemleri ve önceden yüklenmiş araçlarla gelir. Ancak, belirli senaryolarda bu genel amaçlı ortamlar yetersiz kalabilir:

• Güvenlik ve Ağ İzolasyonu: Hassas verilerin işlenmesi veya şirket içi ağ kaynaklarına (örneğin, bir veritabanı sunucusu, bir Kubernetes kümesi, şirket içi bir dağıtım hedefi) erişim gerektiğinde, genel bulut ortamında çalışan runner'lar risk taşıyabilir. Self-hosted runner'lar, bu iş akışlarını kendi güvenli ağ ortamınızda çalıştırmanıza olanak tanır.
• Özelleştirilmiş Donanım ve Yazılım: Özel GPU'lar, yüksek bellek kapasitesi, belirli bir işletim sistemi sürümü veya önceden lisanslanmış özel yazılımlar gibi donanım veya yazılım gereksinimleriniz olabilir. Self-hosted runner ile bu ortamı tam olarak istediğiniz gibi yapılandırabilirsiniz.
• Kaynak Kısıtlamaları ve Maliyet Optimizasyonu: Yoğun ve uzun süreli derleme, test veya dağıtım işlemleri, GitHub-hosted runner dakikaları açısından maliyetli olabilir. Kendi sunucularınızdaki atıl kapasiteyi kullanarak veya ayrılmış makinelerle self-hosted runner çalıştırarak, özellikle büyük ekipler ve sık entegrasyonlar için maliyetleri optimize edebilirsiniz.
• Önbellekleme ve Performans: Derleme bağımlılıkları veya büyük dosyalar için daha agresif önbellekleme stratejileri uygulayabilir, hatta sürekli çalışan bir runner üzerinde gerekli paketleri önceden yükleyerek iş akışı başlangıç sürelerini kısaltabilirsiniz.

Self-Hosted Runner Kurulumu ve Yapılandırması

Self-hosted runner'ı yapılandırmak için izlenmesi gereken adımlar oldukça basittir, ancak sisteminize ve güvenlik gereksinimlerinize göre dikkatli olunmalıdır. Aşağıdaki örnek, bir Linux sunucusu üzerinde kurulumu göstermektedir.

1. Runner Uygulamasını İndirme

GitHub deponuzun veya organizasyonunuzun "Settings" kısmına gidin, ardından "Actions" ve "Runners" sekmesini seçin. Burada "New self-hosted runner" butonuna tıklayarak işletim sisteminize uygun indirme ve yapılandırma komutlarını alabilirsiniz. Genellikle bu adımlar şuna benzer:

# Runner dizini oluşturmamkdir actions-runner && cd actions-runner# En son runner paketini indirme (örnek olarak x64 Linux)# GitHub Actions runner sürümleri için resmi dokümantasyonu kontrol edincurl -o actions-runner-linux-x64-2.316.0.tar.gz -L https://github.com/actions/runner/releases/download/v2.316.0/actions-runner-linux-x64-2.316.0.tar.gz# Paketi açmatar xzf ./actions-runner-linux-x64-2.316.0.tar.gz

Açıklama: İlk olarak, runner dosyalarını barındıracak bir dizin oluşturulur. Ardından, curl komutu ile GitHub'ın resmi depolarından işletim sisteminize uygun runner paketi indirilir. Son olarak, indirilen tar.gz dosyası tar xzf komutu ile mevcut dizine açılır.

2. Runner'ı Yapılandırma

Paketi açtıktan sonra, runner'ı GitHub hesabınıza veya organizasyonunuza kaydetmeniz gerekir. Bu işlem, bir yapılandırma scripti aracılığıyla yapılır ve size özel bir token kullanır.

# Runner'ı yapılandırma# GitHub'dan aldığınız yapılandırma komutunu kullanın# Örnek: ./config.sh --url https://github.com/YOUR_ORG/YOUR_REPO --token A_TOKEN_FROM_GITHUB --name my-custom-runner --labels self-hosted,linux,my-specific-label./config.sh --url https://github.com/YOUR_ORG_OR_REPO_URL --token YOUR_REGISTRATION_TOKEN --runnergroup Default --labels self-hosted,linux,my-custom-label

Açıklama: config.sh scripti çalıştırıldığında, runner'ın hangi GitHub URL'sine bağlanacağı (organizasyon veya depo seviyesi), kayıt token'ı, runner'ın adı ve en önemlisi etiketleri (labels) belirlenir. Etiketler, GitHub Actions iş akışlarınızda belirli runner'ları hedeflemek için kullanılır. Örneğin, self-hosted,linux,my-custom-label etiketlerini kullanarak bu runner'ı özel işler için ayırabilirsiniz.

3. Runner'ı Çalıştırma

Runner'ı yapılandırdıktan sonra, ya ön planda manuel olarak ya da bir sistem servisi olarak arka planda çalıştırabilirsiniz.

Ön Planda Çalıştırma (Test Amaçlı)

# Runner'ı ön planda çalıştırma./run.sh

Açıklama: Bu komut, runner uygulamasını doğrudan çalıştırır. Test ve hata ayıklama için kullanışlıdır, ancak sunucu yeniden başlatıldığında veya oturum kapandığında durur.

Sistem Servisi Olarak Çalıştırma (Production İçin)

Production ortamlarında runner'ı bir sistem servisi olarak çalıştırmak en iyi yaklaşımdır. Bu, runner'ın sistem başlangıcında otomatik olarak başlamasını ve arka planda sürekli çalışmasını sağlar.

# systemd servis dosyası oluşturma# /etc/systemd/system/actions-runner.service[Unit]Description=GitHub Actions RunnerAfter=network.target[Service]ExecStart=/home/youruser/actions-runner/run.shWorkingDirectory=/home/youruser/actions-runnerUser=youruserRestart=alwaysRestartSec=5[Install]WantedBy=multi-user.target

Açıklama: Yukarıdaki systemd servis dosyası, runner'ı youruser kullanıcısı altında çalıştırır. ExecStart ve WorkingDirectory yollarını kendi kurulumunuza göre güncellediğinizden emin olun. Restart=always ayarı, runner uygulamasının herhangi bir nedenle durması durumunda otomatik olarak yeniden başlatılmasını sağlar.

# systemd servisini etkinleştirme ve başlatmasudo systemctl daemon-reloadsudo systemctl enable actions-runner.servicesudo systemctl start actions-runner.service# Servis durumunu kontrol etmesudo systemctl status actions-runner.service

Açıklama: daemon-reload ile systemd konfigürasyonunu yeniden yükler, enable ile servisi sistem başlangıcında çalışacak şekilde ayarlar ve start ile servisi hemen başlatırız. status komutu ile servisin çalıştığını doğrulayabiliriz.

GitHub Actions İş Akışınızda Self-Hosted Runner Kullanımı

Runner'ınız hazır ve çalışır durumda olduğunda, GitHub Actions iş akışı dosyalarınızda (.github/workflows/*.yml) onu hedefleyebilirsiniz. Bunu, iş tanımındaki runs-on anahtarını kullanarak yaparsınız.

# .github/workflows/deploy.ymlname: Custom Deployment Workflowon:  push:    branches:      - mainjobs:  build-and-deploy:    runs-on: [self-hosted, linux, my-custom-label] # Daha önce tanımladığımız etiketleri kullanıyoruz    steps:    - name: Checkout code      uses: actions/checkout@v4    - name: Setup Node.js      uses: actions/setup-node@v4      with:        node-version: '20'    - name: Install dependencies      run: npm install    - name: Build project      run: npm run build    - name: Deploy to Internal Server      run: |        echo "Deploying to internal staging server..."        # Şirket içi sunucuya SSH ile bağlanma veya özel dağıtım aracı kullanma        # ssh user@internal-server "deploy-script.sh"        # Bu adım, self-hosted runner'ın şirket içi ağa erişim yeteneğini gösterir.      env:        INTERNAL_SERVER_IP: 192.168.1.100 # Örnek iç IP

Açıklama: runs-on: [self-hosted, linux, my-custom-label] ifadesi, bu işin yalnızca belirtilen etiketlere sahip self-hosted runner'lar üzerinde çalıştırılmasını sağlar. Bu sayede, hassas dağıtım adımları, şirket içi ağ kaynaklarına erişim gerektiren işlemler güvenli ve kontrollü bir ortamda gerçekleştirilebilir.

Gerçek Üretim Senaryoları ve En İyi Uygulamalar

Senaryo 1: On-Premise Veritabanı ile Entegrasyon ve Güvenlik

Büyük bir finans kuruluşu, geliştirme ve test ortamlarını tamamen şirket içi bir ağda tutmaktadır. Bu ağ, internetten izole edilmiştir ve yüksek güvenlik standartlarına sahiptir. Yeni bir mikroservis geliştirme döngüsünde, CI/CD adımlarının bir parçası olarak, veritabanı şema değişikliklerinin test edilmesi ve test verilerinin yüklenmesi gerekmektedir. GitHub-hosted runner'lar bu kapalı ağa erişemez.

Çözüm: Kuruluş, güvenli şirket içi veri merkezlerinde Linux tabanlı sanal makineler üzerinde self-hosted runner'lar kurar. Bu runner'lar, yalnızca belirli iç IP adreslerinden GitHub'a çıkış yapabilecek şekilde yapılandırılır ve iç ağdaki veritabanı sunucularına doğrudan erişebilir. İş akışları, bu self-hosted runner'ları hedefleyerek, hassas veritabanı işlemlerini güvenli ve izole bir ortamda gerçekleştirir. Ayrıca, runner makineleri periyodik olarak güvenlik yamaları ve güncellemelerle korunur.

Senaryo 2: Özel Donanım Gerektiren ML Modeli Eğitimi

Bir yapay zeka şirketi, büyük dil modelleri (LLM) üzerinde çalışmaktadır. Model eğitimi, yüksek performanslı GPU'lara ve çok sayıda CPU çekirdeğine sahip sunucular gerektirir. Model eğitim süreci saatler sürebilir ve GitHub-hosted runner'ların sunduğu kaynaklar bu tür görevler için yetersiz veya çok maliyetli olabilir.

Çözüm: Şirket, NVIDIA GPU'larla donatılmış güçlü sunucuları AWS EC2 P3/P4 örnekleri üzerinde veya kendi veri merkezlerinde self-hosted runner olarak yapılandırır. Bu runner'lara özel etiketler (örneğin, gpu-enabled, high-memory) atanır. Model eğitimi ve hiperparametre ayarlama iş akışları, bu özel etiketleri kullanarak ilgili runner'lara yönlendirilir. Böylece, GitHub Actions'ın otomasyon yetenekleri, özel donanımın tüm gücüyle birleşir ve maliyet etkin bir şekilde yüksek performanslı hesaplama görevleri yürütülür.

Senaryo 3: Büyük Ölçekli Kurumsal Dağıtımlar ve Sürekli Çalışan Runner'lar

Büyük bir e-ticaret platformu, günlük yüzlerce dağıtım gerçekleştirmekte ve her dağıtım birden fazla mikroservisi etkilemektedir. Her dağıtım adımı, özel dağıtım araçları ve şirket içi Kubernetes kümelerine erişim gerektirir. GitHub-hosted runner'ların her iş için yeniden başlatılması ve bağımlılıkların her seferinde indirilmesi, toplam dağıtım süresini uzatmaktadır.

Çözüm: Platform, Kubernetes kümesi içerisinde veya AWS Auto Scaling Grupları aracılığıyla dinamik olarak ölçeklenebilen self-hosted runner havuzları kurar. Bu runner'lar, gerekli dağıtım araçlarını ve bağımlılıkları önceden yüklenmiş custom AMI'ler (Amazon Machine Images) veya Docker imajları kullanılarak başlatılır. Runner'lar sürekli çalışır ve her iş başlangıcında bağımlılık indirme veya ortam kurulum maliyetini ortadan kaldırır. Otomatik ölçeklendirme, yoğun zamanlarda ek runner'ların devreye girmesini, atıl zamanlarda ise kaynakların serbest bırakılmasını sağlar, böylece hem performans hem de maliyet verimliliği optimize edilir. Ayrıca, runner'lar belirli dağıtım hedefleri için özel IAM rolleri veya güvenlik grupları ile yapılandırılarak "least privilege" prensibi uygulanır.

Sonuç

GitHub Actions self-hosted runner'lar, CI/CD süreçlerinizi standart bulut ortamlarının ötesine taşıyan güçlü ve esnek bir çözümdür. Güvenlik, özel donanım veya yazılım gereksinimleri, maliyet optimizasyonu veya ağ izolasyonu gibi spesifik ihtiyaçlarınız olduğunda, kendi altyapınız üzerinde runner'lar yapılandırmak, geliştirme ve dağıtım iş akışlarınızı tam kontrole almanızı sağlar. Doğru yapılandırma ve yönetim ile self-hosted runner'lar, organizasyonunuzun DevOps stratejisinin kritik bir bileşeni haline gelebilir.