DevOps ile GitOps Arasındaki Fark: Kültür ile Teslimat Yöntemi Nasıl Ayrışır?

Aynı düzlemde değiller: biri çatı, diğeri yöntem

DevOps ile GitOps sık sık iki rakip seçenek gibi karşılaştırılır, ama aynı düzlemde durmazlar. DevOps, yazılım geliştirme ile operasyon ekipleri arasındaki duvarı kaldırmayı amaçlayan bir kültür ve çalışma modelidir. Sürekli entegrasyon, sürekli teslimat, altyapı otomasyonu, izleme, geri bildirim döngüsü ve ortak sorumluluk gibi uygulamaların hepsini kapsar. Belirli bir araç, depo yapısı ya da dağıtım tekniği dayatmaz.

GitOps ise DevOps'un teslimat ve işletim kısmını belirli bir biçimde uygulayan bir yöntemdir. Sistemin olması gereken durumu bildirimsel (declarative) dosyalarla tanımlanır, bu dosyalar sürüm kontrolünde tutulur ve kümedeki bir yazılım ajanı gerçek durumu sürekli bu tanımla eşitler. Değişiklik, sunucuya komut göndererek değil, Git'e bir değişiklik birleştirilerek yapılır.

Bu yüzden doğru soru genellikle DevOps mu GitOps mu değil, DevOps dönüşümü içinde teslimatı GitOps yöntemiyle mi yürütelim sorusudur.

GitOps'un ilkeleri ve DevOps'tan ödünç aldıkları

OpenGitOps topluluğu GitOps'u dört ilkeyle tanımlar: • Bildirimsel: Sistemin istenen yapılandırması adım adım komutlarla değil, bildirimsel olarak tanımlanır. • Sürümlü ve değişmez: İstenen durum, yerinde değiştirilemeyecek biçimde ve tam sürüm geçmişiyle saklanır. • Otomatik çekilen: Yazılım ajanları istenen durum tanımlarını kaynağından kendileri çeker. • Sürekli eşitlenen: Ajanlar gerçek durumu sürekli izler ve istenen durumla uyumlu hale getirmeye çalışır.

Bu ilkelerin dayandığı tekniklerin kökü DevOps uygulamalarındadır. Kod olarak altyapı, kod incelemesiyle değişiklik onayı ve otomatik dağıtım DevOps ekiplerinin uzun süredir kullandığı tekniklerdir. GitOps'un getirdiği asıl yenilik, çekme (pull) modeli ve sürekli eşitlemedir: dağıtım hattı kümeye erişip değişikliği itmez, kümedeki ajan değişikliği kendisi alır ve sapma oluştuğunda düzeltir.

Ölçüt ölçüt farklar

• Ölçüt: Kapsam. DevOps: planlamadan kodlamaya, testten izlemeye kadar tüm yazılım yaşam döngüsü ve ekip yapısı. / GitOps: dağıtım ve çalışma ortamının yapılandırma yönetimi.
• Ölçüt: Doğası. DevOps: kültür, ilkeler ve uygulamalar bütünü. / GitOps: tanımlı ilkeleri olan somut bir işletim yöntemi.
• Ölçüt: Gerçeğin kaynağı. DevOps: belirli bir kaynak şart koşmaz; durum araç, betik ve ortam arasında dağılmış olabilir. / GitOps: istenen durumun tek kaynağı sürüm kontrolündeki bildirimsel dosyalardır.
• Ölçüt: Dağıtım modeli. DevOps: hem itme (pipeline'ın hedefe dağıtım yapması) hem çekme modeli kullanılabilir. / GitOps: çekme modeli ve sürekli eşitleme esastır.
• Ölçüt: Sapma yönetimi. DevOps: elle yapılan değişiklikler izleme ve denetimle yakalanır. / GitOps: ajan, Git'teki tanımla çelişen değişikliği fark eder ve geri alabilir.
• Ölçüt: Geri alma. DevOps: yönteme göre değişir; yeniden dağıtım, önceki paket ya da betik. / GitOps: Git'teki ilgili değişiklik geri alınır, ajan sistemi önceki duruma getirir.
• Ölçüt: Uygun ortam. DevOps: her tür altyapı; sanal makine, konteyner, sunucusuz, kurum içi sistemler. / GitOps: bildirimsel API'si olan ortamlar; pratikteki tipik kullanım alanı Kubernetes'tir.
• Ölçüt: Tipik araçlar. DevOps: CI sunucuları, yapılandırma yönetimi, izleme ve iş takibi araçlarının geniş yelpazesi. / GitOps: Argo CD ve Flux gibi kümede çalışan eşitleme ajanları.

Bir değişikliğin iki yoldan üretime gidişi

Örneğin bir ekip, ödeme servisinin yeni sürümünü üretime almak istiyor.

Klasik bir DevOps hattında geliştirici değişikliği birleştirir, CI testleri koşar, imaj oluşturulur ve hattın son adımı kümeye bağlanarak yeni sürümü dağıtır. Hattın üretim ortamına yazma yetkisi vardır. Biri acil bir sorun için kümede elle ayar değiştirirse, bu değişiklik bir sonraki dağıtıma kadar kimsenin haberi olmadan yaşayabilir.

GitOps ile aynı akışta CI, imajı oluşturduktan sonra kümeye dokunmaz; yalnız ortam deposundaki manifestte imaj etiketini güncelleyen bir değişiklik açar. Bu değişiklik incelenip birleştirildiğinde kümedeki ajan farkı görür ve yeni sürümü uygular. Kümede elle yapılan bir ayar, Git'teki tanımla çeliştiği için sapma olarak raporlanır ya da otomatik olarak geri alınır. Üretime kimin, ne zaman, neyi aldığı sorusunun cevabı Git geçmişidir.

İki akışta da test, inceleme ve otomasyon aynıdır; değişen, üretim ortamına yazma yetkisinin ve gerçeğin kaynağının nerede durduğudur.

Hangi durumda GitOps'a geçmek mantıklı?

GitOps'un güçlü olduğu durumlar: • Uygulamalar Kubernetes üzerinde çalışıyor ve yapılandırma zaten YAML manifestleri, Helm chart'ları ya da Kustomize katmanları olarak tutuluyor. • Birden fazla küme ya da ortam aynı tanımlardan, tutarlı biçimde yönetilmek isteniyor. • Denetim ve uyum ihtiyacı yüksek; her üretim değişikliğinin onaylı ve izlenebilir olması isteniyor. • CI sistemine üretim kümesinin yönetici yetkisini vermek güvenlik açısından istenmiyor.

GitOps'un zorlandığı ya da tek başına yetmediği durumlar: • Altyapının önemli bölümü bildirimsel API sunmayan eski sistemlerden oluşuyor. • Ekip henüz sürüm kontrolü, otomatik test ve kod incelemesi alışkanlığını oturtmamış; GitOps bu temellerin üzerine kurulur. • Gizli bilgiler (parola, anahtar) için ayrı bir çözüm kurulmamış; bunlar Git'e düz metin olarak konamaz. • Veritabanı şeması geçişi gibi sıralı ve geri dönüşü zor işlemler; bunlar ek kurgu ister.

DevOps kültürü ise bu tablonun her satırında geçerliliğini korur. GitOps'u seçmek DevOps'tan vazgeçmek değil, onun teslimat ayağını belirli bir disiplinle uygulamaktır.

Geçişte sık yapılan hatalar

• Kümeye elle müdahaleyi yasaklamadan GitOps'a geçmek: ekip kubectl ile değişiklik yapmaya devam ederse ajan bu değişiklikleri sürekli geri alır ve güven kaybolur. Acil durumlar için de Git üzerinden hızlı bir akış tanımlanmalıdır.
• Uygulama kodu ile ortam yapılandırmasını aynı depoda karıştırmak: her kod değişikliği dağıtım tetikler, ortam geçmişi okunmaz hale gelir. Ortam tanımları için ayrı bir depo ya da en azından ayrı bir klasör yapısı bu karışıklığı önler.
• Gizli bilgileri şifrelemeden depoya koymak: şifreli gizli bilgi ya da harici bir gizli bilgi yöneticisiyle entegrasyon baştan planlanmalıdır.
• GitOps'u DevOps'un tamamı sanmak: izleme, olay yönetimi, geri bildirim ve ekipler arası işbirliği eksikse, Git tabanlı dağıtım tek başına teslimat performansını iyileştirmez.
• Ortamlar arası terfi akışını tanımlamamak: test ortamından üretime hangi değişikliğin, hangi onayla geçeceği belirsizse Git geçmişi düzen yerine karmaşa üretir.

Mindset programlarında DevOps ve GitOps

DevOps Temelleri eğitimi, DevOps felsefesi ve kültürel dönüşümden başlayıp sürekli entegrasyon, sürekli teslimat, altyapı otomasyonu, izleme ve DevOps ekip modellerine uzanır. Yazılım, operasyon ve test ekiplerinin ortak bir dil kurması gereken kurumlarda dönüşümün başlangıç noktası olarak kullanılabilir.

GitOps tarafında iki araç odaklı eğitim bulunur. Argo CD ile GitOps Sürekli Teslimat, repository stratejisi, Application tanımları, ApplicationSet ile ölçekli yönetim ve aşamalı yayın konularını işler; Kubernetes üzerinde çok sayıda uygulamayı yöneten platform ekipleri için uygundur. Flux ile GitOps Operasyonları ise Flux mimarisi, Kustomize ve Helm entegrasyonu ile çok ortamlı kiracı ayrımı üzerinden ilerler.