GitOps Temelleri: CI/CD Pipeline'ınız Size Neden Yalan Söylüyor?

Sıfırdan eksiksiz bir GitOps platformu inşa ettim; iki EKS kümesi, App-of-Apps desenli ArgoCD, Terraform modülleri, Karpenter otomatik ölçeklendirme, Kyverno politikaları ve 352 otomatik test. Her şey bir saatin altında kuruluyor ve değişiklikler beş dakika içinde üretime senkronize ediliyor.

Ancak hikaye teknoloji değil. Hikaye, bunu inşa etmeden önce yaşananlar; sabahın 3'ündeki olaylar, kimsenin açıklayamadığı yapılandırma kaymaları (drift) ve CI/CD pipeline'larımızın temelden bozuk olduğunun yavaş yavaş farkına varılması. Bozuk derken çalışmadıklarını kastetmiyorum. Bize hak etmediğimiz bir güven verdikleri için bozuklardı.

Bu makale, "Şu anda üretim ortamında (production) aslında ne çalışıyor?" diye sorup da net bir cevap alamayan herkes içindir.

Push-Tabanlı CI/CD Sorunu

Çoğu dağıtım (deployment) pipeline'ı şöyle çalışır:

1. Geliştirici kodu Git'e gönderir (push).
2. CI sistemi derler ve test eder.
3. CI sistemi çıktıları (artifacts) üretime gönderir (push).
4. Herkes en iyisini umar.

Ben buna "gönder ve dua et" diyorum. Jenkins, GitHub Actions, GitLab CI; hepsi aynı şeyi yapar. Altyapınıza değişiklikleri iterler ve sonra uzaklaşırlar. Pipeline başarılı olur, bildirim gelir ve herkes dağıtımın çalıştığını varsayar.

Ama gerçekten çalıştı mı?

Bir keresinde, bir geliştiricinin "sadece hızlıca bir şeyi test etmek için" doğrudan üretim ortamına kubectl apply komutu uygulamasından kaynaklanan bir sorunu çözmek için dört saat harcadım. Değişiklik pipeline'ımızdan geçmemişti. Git'te yoktu. Hiçbir yerde belgelenmemişti. Tek kanıt, kimsenin izlemediği Kubernetes denetim günlüklerine gömülmüştü.

İşte bu "configuration drift"tir (yapılandırma kayması); üretimde çalışanın kaynak kodunuzda tanımlananla eşleşmemesi durumu. Ve bu nadir bir durum değildir. Çoğu üretim sisteminin varsayılan halidir.

Push-tabanlı CI/CD, dağıtımı bir durum (state) değil, bir olay (event) olarak ele aldığı için drift yaratır. Pipeline bir kez çalışır, değişiklikleri yapar ve yoluna devam eder. Sonrasında ne olduğu hakkında hiçbir fikri yoktur. Birisi doğrudan bir ConfigMap'i değiştirirse, bir dağıtım manuel olarak ölçeklendirilirse, pipeline bunu bilmez ve umursamaz.

Git deponuz bir şey söyler, kümeniz (cluster) başka bir şey. Ve bir şeyler bozulana kadar kimse fark etmez.

GitOps Aslında Ne Demek?

GitOps terimi 2017'de ortaya atıldı, ancak temel ilkeleri daha eskidir. Özünde GitOps, Git'i tüm sisteminiz için tek gerçeklik kaynağı (single source of truth) olarak ele almaktır; sadece uygulama kodunuz değil, altyapınız, yapılandırmanız ve politikalarınız için de.

GitOps modelinin dört temel ilkesi vardır:

1. Bildirimsel (Declarative)

Tüm sisteminiz bildirimsel olarak tanımlanmalıdır. "Bir dağıtım oluştur, üç kopyaya ölçekle" gibi işleri yapan betikler yerine, "üç kopyalı ve 8080 portunda çalışan bir dağıtım olmalı" gibi durumu tarif eden manifestleriniz olur.

2. Sürümlenmiş ve Değişmez (Versioned and Immutable)

Her şey Git'e gider. Her yapılandırma değişikliği, her altyapı güncellemesi, her politika; hepsi uygulama kodunuzla aynı iş akışları (PR, review) kullanılarak işlenir. Bu size ücretsiz bir denetim izi (audit trail) sağlar.

3. Otomatik Olarak Çekilen (Pulled Automatically)

İşte GitOps'un geleneksel CI/CD'den ayrıldığı nokta. Pipeline'ların altyapınıza değişiklik itmesi yerine, kümelerinizin içinde çalışan ajanlar (agents) değişiklikleri Git'ten çeker.

Bu, güvenlik modeli açısından temelden farklıdır. Push-tabanlı sistemler CI sunucunuzun üretim kümelerine erişim iznine sahip olmasını gerektirirken, pull-tabanlı sistemler sadece kümelerin Git'e okuma erişimine sahip olmasını gerektirir.

4. Sürekli Mutabakat (Continuously Reconciled)

Ajanlar sadece değişiklikleri çekmekle kalmaz, kümenizin mevcut durumunu Git'teki istenen durumla sürekli karşılaştırır. Herhangi bir fark varsa, bunu düzeltir (reconcile).

Bu, drift'i ortadan kaldırmanın anahtarıdır. Birinin doğrudan kubectl apply çalıştırması önemli değildir. Mutabakat döngüsü bunu fark eder ve düzeltir.

Push vs Pull: Bir Zihinsel Model

Push-tabanlı CI/CD'yi, gelip işi yapan ve giden bir müteahhit gibi düşünün. İşi doğru yaptıklarını umarsınız ama kendiniz denetleyene kadar bilemezsiniz. Ve onlar gittikten sonra başkası gelip bir şeyi değiştirirse, müteahhitin haberi olmaz.

GitOps ise mülkte yaşayan bir bekçi gibidir. Planlara sahip oldukları için her şeyin nasıl görünmesi gerektiğini tam olarak bilirler. Sürekli dolaşıp işlerin planlara uyup uymadığını kontrol ederler. Bir şey yanlışsa düzeltirler.

GitOps'un İş Değeri

Yıllarımı finansal hizmetlerde geçirdim, uyumluluğun (compliance) isteğe bağlı olmadığı yerlerde. GitOps uyumluluğu neredeyse otomatik hale getirir. Her değişiklik bir pull request'ten geçer. Her birleştirme (merge) kalıcı bir kayıt oluşturur. Denetçiler "bunu kim onayladı?" diye sorduğunda, Git geçmişini gösterirsiniz.

Ayrıca:

• Daha hızlı kurtarma: Geri alma (rollback) işlemi sadece git revert'tir.
• Azalan bilişsel yük: Geliştiriciler dağıtım prosedürlerini öğrenmek zorunda değildir. Sadece kodu push'larlar.
• Ortam tutarlılığı: Staging ve Production aynı kaynaklardan üretilir.

Sonuç

CI/CD pipeline'ınız size kötü niyetle yalan söylemiyor. Sadece üretimde aslında neyin çalıştığına dair gerçeği söylemek için tasarlanmamıştır.

GitOps modeli değiştirir. Git tek gerçeklik kaynağı olur. Ajanlar sürekli mutabakat sağlar. Drift imkansız hale gelir çünkü herhangi bir sapma otomatik olarak düzeltilir.

AWS ve Kubernetes gibi modern teknolojilerle DevOps pratiklerinizi bir üst seviyeye taşımak için GitOps vazgeçilmezdir. Docker konteynerleriniz ve EKS kümeleriniz artık güvende.