CI/CD Süreçlerinde Docker Kullanımı: GitLab Runner Yapılandırması

CI/CD Süreçlerinde Docker Kullanımı: GitLab Runner Yapılandırması​

---

Giriş: Kodu Otomatiğe Bağlamak​

Modern yazılım geliştirmede (DevOps), bir geliştirici kodunu git push ile gönderdiği anda, o kodun otomatik olarak test edilmesi, derlenmesi (build), Docker imajına dönüştürülmesi ve sunucuya yüklenmesi gerekir. Bu sürece CI/CD (Continuous Integration / Continuous Deployment) denir.

GitLab CI, bu alandaki en popüler araçlardan biridir. Ancak GitLab'ın bu işleri yapması için bir "işçiye" ihtiyacı vardır. Bu işçiye GitLab Runner denir. Bu makalede, Docker imajlarını derlemek için GitLab Runner'ı nasıl en verimli şekilde yapılandıracağımızı inceleyeceğiz.

GitLab Runner Nedir?​

GitLab Runner, Go diliyle yazılmış küçük bir ajandır. Sunucunuza kurarsınız, GitLab'a kaydedersiniz (Register) ve GitLab'dan gelen emirleri ("Testi çalıştır", "Docker build yap") bekler.

Executor Seçimi: Shell vs. Docker​

Runner'ı kurarken size "Hangi Executor?" diye sorar.

• Shell Executor: Komutları sunucunun terminalinde doğrudan çalıştırır.
  
  • Avantaj: Basittir.
  • Dezavantaj: İzolasyon yoktur. Bir projenin bağımlılıkları diğerini bozabilir. Sunucu kirlenir.
• Docker Executor (Standart): Her iş (Job) için tertemiz, geçici bir Docker konteyneri açar. İş bitince konteyneri siler.
  
  • Avantaj: Tam izolasyon. Her proje kendi ortamında (Node.js, Python, Java) çalışır.

Docker İçinde Docker Çalıştırma Sorunu (The Docker Build Problem)​

Eğer Docker Executor kullanıyorsanız, şöyle bir paradoks oluşur: "Ben zaten bir Docker konteynerinin içindeyim. Bu konteynerin içinde nasıl docker build komutunu çalıştırıp başka bir imaj oluşturacağım?"Konteynerlerin içinde Docker motoru (Daemon) yoktur. İki çözüm vardır:

Çözüm 1: Docker-in-Docker (DinD)​

Konteynerin içine gerçekten bir Docker Daemon kurmaktır.

• Yöntem: .gitlab-ci.yml dosyasında services: - docker:dind eklenir ve privileged (ayrıcalıklı) mod açılır.
• Dezavantaj: Güvenlik riski yüksektir (Privileged mod). Ayrıca her seferinde sıfırdan cache oluşturduğu için yavaştır.

Çözüm 2: Docker Socket Binding (Önerilen)​

Konteynerin içine Docker kurmak yerine, ana sunucunun (Host) Docker motorunu kullanmaktır.

• Yöntem: Runner ayarlarında (config.toml), sunucunun /var/run/docker.sock dosyasını konteynerin içine bağlarsınız (Mount).
• Mantık: Konteynerin içindeki docker komutu, aslında sunucudaki Docker motoruna emir verir.
• Avantaj: Çok hızlıdır. Sunucudaki imaj önbelleğini (Cache) kullanabilir.
• Dezavantaj: Konteyner, sunucudaki tüm konteynerleri görebilir ve silebilir. Güvenilir projeler için kullanılmalıdır.

Build Sürecini Hızlandırma: Layer Caching​

CI/CD sürecinde her seferinde npm install veya apt update yapmak dakikalar sürer.Docker Socket Binding kullanıldığında, eğer Dockerfile değişmediyse, Docker otomatik olarak önbellekteki (Cache) katmanları kullanır.

• İpucu: docker build --cache-from my-image:latest ... komutuyla, önceki imajı referans alarak build süresini %80 azaltabilirsiniz.

Sonuç​

GitLab Runner ve Docker, modern yazılım fabrikasının montaj hattıdır. Doğru yapılandırma (Socket Binding ve Cache kullanımı), kodun yazılmasıyla canlıya alınması arasındaki süreyi 30 dakikadan 3 dakikaya indirebilir.