GitHub Actions Self-Hosted Runner: Detaylı Kurulum ve Üretim Stratejileri

 · 

GitHub Actions Self-Hosted Runner: Detaylı Kurulum ve Üretim Stratejileri

GitHub Actions Self-Hosted Runner: Detaylı Kurulum ve Üretim Stratejileri

GitHub Actions iş akışları için sağlanan bulut tabanlı runner'lar birçok proje için yeterli olsa da, bazı durumlarda özel gereksinimler devreye girer. Bu gereksinimler, spesifik donanım bağımlılıkları, ağ kısıtlamaları, özel lisanslı yazılımlar veya maliyet optimizasyonları olabilir. Self-hosted runner'lar, bu tür senaryolarda GitHub Actions'ın esnekliğini kendi altyapınıza taşıyarak tam kontrol sağlar.

Neden Self-Hosted Runner Tercih Edilmeli?

Self-hosted runner'lar, GitHub'ın sunduğu sanal makinelerin ötesine geçme ihtiyacı duyduğunuzda stratejik bir avantaj sunar. Örneğin, bir CI/CD pipeline'ında özel GPU donanımına sahip bir makinede ağır makine öğrenimi modellerini eğitmeniz gerekiyorsa, veya belirli bir ağ segmentindeki on-premise bir Kubernetes kümesine doğrudan erişim sağlamanız şartsa, self-hosted runner'lar kaçınılmaz hale gelir. Kendi donanımınızı ve işletim sisteminizi yönetme yeteneği, bağımlılıkları ve çalışma ortamını tamamen kontrol etmenizi sağlar.

Self-Hosted Runner Yapılandırmasının Temelleri

Gereksinimler

Self-hosted runner kurmadan önce aşağıdaki temel gereksinimleri karşıladığınızdan emin olun:

  • Desteklenen bir işletim sistemi (Linux, macOS veya Windows).
  • Minimum 2 vCPU ve 7 GB RAM.
  • İnternet erişimi (özellikle GitHub API'larına ve runner agent'ının çalıştığı GitHub Actions hizmetlerine).
  • sudo yetkilerine sahip bir kullanıcı (Linux/macOS için).
  • GitHub Personal Access Token (PAT) veya GitHub App kimlik doğrulaması.

Kurulum ve İlk Çalıştırma (Linux Örneği)

Runner kurulumu, GitHub repository'nizin veya organizasyonunuzun 'Settings' bölümünden 'Actions' -> 'Runners' sekmesine giderek başlar. Buradan işletim sisteminize uygun talimatları alabilirsiniz. Aşağıdaki adımlar bir Linux makine üzerinde kurulumu gösterir:

# 1. Runner yazılımını indirmek için bir dizin oluşturun ve buraya geçin. Bu dizin runner'ın çalışma dizini olacaktır.cd ~mkdir actions-runner && cd actions-runner# 2. En son runner sürümünü GitHub'dan indirin.wget https://github.com/actions/runner/releases/download/v2.311.0/actions-runner-linux-x64-2.311.0.tar.gz# 3. İndirilen paketi açın.tar xzf ./actions-runner-linux-x64-2.311.0.tar.gz# 4. Runner'ı yapılandırın. Bu adımda sizden GitHub URL'i (örn. https://github.com/your-org/your-repo) ve bir PAT istenir.PAT'ı GitHub Ayarları'ndan (Developer Settings -> Personal Access Tokens) 'repo' ve 'workflow' yetkileriyle oluşturmanız gerekmektedir. Runner'ın adı ve etiketleri bu adımda belirlenir.$ ./config.sh --url https://github.com/your-org/your-repo --token YOUR_PAT_TOKEN# 5. Runner'ı başlatın. Bu komut, runner'ın GitHub Actions işlerini dinlemeye başlamasını sağlar.Sadece test amaçlı veya kısa süreli çalıştırmalar için uygundur. Üretim ortamında servis olarak çalıştırılmalıdır.$ ./run.sh

Servis Olarak Yapılandırma (systemd ile Linux)

Üretim ortamlarında runner'ın sürekli çalışır durumda olması ve sistem yeniden başlatıldığında otomatik olarak başlaması kritiktir. systemd kullanarak runner'ı bir servis olarak yapılandırmak en yaygın yöntemdir:

# 1. Runner dizinine geri dönün.cd ~/actions-runner# 2. Runner'ı systemd servisi olarak kurun. Bu işlem, runner dizininde bir .service dosyası oluşturur ve systemd'ye kaydeder.$ sudo ./svc.sh install# 3. Servisi başlatın. Runner artık arka planda çalışacaktır.$ sudo ./svc.sh start# 4. Servisin durumunu kontrol edin.runner@your-host:~/actions-runner$ sudo systemctl status actions.runner.your-org.your-repo.service● actions.runner.your-org.your-repo.service - GitHub Actions Runner for your-org/your-repo   Loaded: loaded (/etc/systemd/system/actions.runner.your-org.your-repo.service; enabled; vendor preset: enabled)   Active: active (running) since Thu 2023-10-26 10:00:00 UTC; 1min ago Main PID: 1234 (Runner.Listener)    Tasks: 8 (limit: 1000)   Memory: 50.1M   CGroup: /system.slice/actions.runner.your-org.your-repo.service           └─1234 /home/runner/actions-runner/bin/Runner.Listener run --startuptype service# 5. Sistemi yeniden başlattığınızda otomatik olarak başlaması için servisi etkinleştirin.$ sudo systemctl enable actions.runner.your-org.your-repo.service

Güvenlik ve Erişim Kontrolü

Self-hosted runner'lar, üzerinde çalışacak kodun ve erişebileceği kaynakların potansiyel güvenlik risklerini beraberinde getirir. Dikkat edilmesi gerekenler:

  • Ağ İzole Etme: Runner'ı mümkün olduğunca izole bir ağ segmentinde çalıştırın. Sadece ihtiyaç duyduğu dış kaynaklara (GitHub API, Docker Hub vb.) ve iç kaynaklara (on-premise veritabanları, Kubernetes API) erişimi olmalıdır.
  • Kimlik Doğrulama: Runner'ı kurarken kullanılan PAT, runner'ın erişim yetkilerini belirler. Minimum ayrıcalık prensibiyle, sadece gerekli repository veya organizasyonlara erişim sağlayan ve sadece workflow çalıştırma yetkisi olan bir PAT kullanın. Alternatif olarak, daha güvenli olan GitHub Apps ile kimlik doğrulama yapılabilir.
  • Bağımlılık Yönetimi: Runner ortamına yüklenen tüm yazılımları ve bağımlılıkları güncel tutun. Güvenlik açıklarını minimize etmek için ortamı düzenli olarak yamalayın.
  • İş Yükü İzolasyonu: Eğer aynı runner üzerinde farklı projelerin iş yüklerini çalıştırıyorsanız, her işin temiz bir ortamda başladığından emin olmak için her işten önce ortamı sıfırlama veya ephemeral runner'lar kullanma stratejileri geliştirin.

Üretim Senaryolarında Self-Hosted Runner Kullanımı

Gerçek dünya üretim ortamlarında self-hosted runner'lar, genellikle özel ve zorlu gereksinimleri karşılamak için kullanılır.

Özel Donanım İhtiyaçları ve Lisanslama

Bir telekomünikasyon şirketinin ağ ekipmanları için firmware derlemesi yaptığını düşünün. Bu derleme süreci, özel bir FPGA veya ASIC programlama donanımı gerektirebilir ve bu donanım sadece şirket içi veri merkezindeki belirli bir sunucuya fiziksel olarak bağlıdır. Ayrıca, derleme için kullanılan EDA (Electronic Design Automation) yazılımları pahalı lisanslara sahip olabilir ve bu lisanslar sadece belirli IP adreslerinden veya fiziksel sunuculardan erişilebilir. Self-hosted runner, bu donanım ve yazılımların bulunduğu sunucu üzerinde çalışarak, GitHub Actions iş akışının bu kısıtlı kaynakları verimli bir şekilde kullanmasını sağlar.

# Örnek bir GitHub Actions workflow adımı- name: Firmware Derlemesi  uses: actions/checkout@v3  with:    submodules: true- name: FPGA Toolchain Kurulumu  # Özel FPGA toolchain kurulumu (önceden runner üzerine kurulmuş olabilir)- name: Firmware Derlemesini Başlat  run: |    source /opt/fpga-toolchain/setup_env.sh    make firmware-build PLATFORM=custom-fpga-board    echo "Firmware derlemesi tamamlandı."

Ağ Kısıtlamaları ve On-Premise Entegrasyon

Finans sektöründe faaliyet gösteren bir kurum, hassas müşteri verilerini işleyen bir mikroservis mimarisine sahip olabilir. Güvenlik protokolleri gereği, bu mikroservislerin dağıtıldığı Kubernetes kümesi veya veritabanları sadece özel bir VPC (Virtual Private Cloud) içinden veya on-premise veri merkezinden erişilebilir. GitHub Actions'ın bulut tabanlı runner'ları bu kaynaklara doğrudan erişemezken, on-premise ağ içinde konumlandırılmış self-hosted runner'lar bu kaynaklarla güvenli bir şekilde etkileşime girebilir.

# Örnek Kubernetes dağıtım adımı- name: Kubernetes'e Dağıtım  uses: actions/checkout@v3- name: Kubeconfig Ayarları  run: |    mkdir -p ~/.kube    echo "$KUBE_CONFIG_BASE64" | base64 --decode > ~/.kube/config  env:    KUBE_CONFIG_BASE64: ${{ secrets.KUBECONFIG_BASE64 }} # Base64 encoded kubeconfig- name: Uygulamayı Dağıt  run: |    kubectl apply -f k8s/deployment.yaml    kubectl rollout status deployment/my-financial-app --timeout=5m

Burada KUBECONFIG_BASE64 bir GitHub Secret olarak saklanır ve self-hosted runner, on-premise Kubernetes kümesine bu yapılandırma ile güvenli bir şekilde bağlanır.

Ölçeklenebilirlik ve Otomasyon

Yoğun CI/CD iş yüklerine sahip büyük ekipler için tek bir self-hosted runner yeterli olmayabilir. Bu durumda, runner grupları ve otomatik ölçeklendirme çözümleri devreye girer. AWS EC2 Auto Scaling Grupları, Azure Scale Sets veya Kubernetes tabanlı orchestrator'lar kullanılarak, belirli koşullar altında (örn. bekleyen iş sayısı) otomatik olarak yeni runner instance'ları başlatılabilir ve iş yükü bittiğinde sonlandırılabilir. Bu, hem maliyet optimizasyonu sağlar hem de iş kuyruklarının kısa kalmasını garantiler.

Sonuç

GitHub Actions self-hosted runner'lar, standart bulut runner'larının yetersiz kaldığı durumlar için güçlü ve esnek bir çözüm sunar. Özel donanım, ağ kısıtlamaları veya belirli yazılım lisanslama gereksinimleri gibi karmaşık üretim senaryolarında, self-hosted runner'lar CI/CD süreçlerinizi kendi altyapınızla kusursuz bir şekilde entegre etmenizi sağlar. Güvenlik ve ölçeklenebilirlik stratejileriyle birleştirildiğinde, bu yaklaşım geliştirme ve dağıtım süreçlerinizi optimize etmek için kritik bir araç haline gelir.

← Blog Listesine Dön