GitOps İş Akışı Diyagramı: Argo CD ya da Flux ile Pull Tabanlı Dağıtım

Klasik bir pipeline'da CI kodu derler, sonra sonucu kubectl apply ya da helm upgrade ile cluster'a iter. Çalışır, ama pipeline'ın her cluster için yönetici kimlik bilgilerine ihtiyacı olur, cluster'a sormadan neyin çalıştığını kimse kesin olarak söyleyemez ve elle düzenlenmiş bir deployment, deponun söylediğinden sessizce farklılaşır.

GitOps yönü tersine çevirir. İstenen durumu Git tutar; cluster'ın içindeki bir ajan onu sürekli çeker ve cluster'ı ona uydurur. Bu yazı ilkeleri, çoğu ekibin kullandığı iki depolu iş akışını, terfinin ve geri almanın nasıl işlediğini anlatıyor ve tüm akışı çiziyor.

Dört ilke

CNCF'in OpenGitOps projesi GitOps'u dört ilkeyle tanımlar:

1. Bildirimsel: sistemin istenen durumu bildirimsel olarak ifade edilir.
2. Versiyonlanmış ve değişmez: bu durum, eksiksiz ve değişmez bir sürüm geçmişi tutacak şekilde saklanır; pratikte bu Git demektir.
3. Otomatik olarak çekilir: yazılım ajanları istenen durumu kaynaktan çeker.
4. Sürekli uzlaştırılır: ajanlar gerçek durumu istenen durumla sürekli karşılaştırır ve farkı düzeltir.

Üçüncü madde, GitOps'u "Git'i okuyan bir pipeline'dan dağıtım"dan ayıran şeydir. Cluster çeker; dışarıdaki hiçbir şey onun içine itmez.

İki depo: kod ve yapılandırma

Çoğu ekip iki tür değişikliği birbirinden ayırır:

• Uygulama deposu kaynak kodu tutar. CI onu derler, testleri çalıştırır, tarar ve değişmez bir imaj etiketini registry'ye iter.
• Yapılandırma deposu her ortam için Kubernetes manifest'lerini, Helm değerlerini ya da Kustomize overlay'lerini tutar. Neyin nerede çalışması gerektiğini, imaj etiketleri dahil, tanımlar.

Aralarındaki bağ küçük ve açık bir değişikliktir: CI ya da bir imaj otomasyon aracı, yapılandırma deposunda staging için imaj etiketini yükselten bir pull request açar. O pull request, incelemesi ve denetim izi olan dağıtım talebinin ta kendisidir.

Cluster'daki controller

Argo CD ve Flux yaygın kullanılan iki GitOps controller'ıdır. İkisi de cluster'ın içinde çalışır, yapılandırma deposunu yoklar ya da ondan webhook alır, manifest'leri işler, canlı nesnelerle karşılaştırır ve farkı uygular.

Uzlaştırma ayarları sistemin ne kadar katı olduğunu belirler:

• Otomatik senkronizasyon: yeni commit'leri kimsenin bir düğmeye basmasına gerek kalmadan uygular.
• Budama (pruning): Git'ten kaldırılan nesneleri siler.
• Kendi kendini iyileştirme (self-heal): doğrudan cluster'da yapılan değişiklikleri geri alır. Argo CD'nin otomatik senkronizasyon seçeneklerinde self-heal, otomatik senkronizasyondan ayrı bir anahtardır.

Git'i gerçek doğruluk kaynağı yapan ayar self-heal'dir. O olmadan, gece 3'te yapılan bir kubectl edit kalıcı ve görünmez hale gelir.

Terfi ve geri alma

Ortamlar, yapılandırma deposunda klasörler, overlay'ler ya da dosyalardır. Terfi, bir sürümü birinden diğerine kopyalamak demektir:

1. Pull request staging etiketini yükseltir; staging, merge'den sonraki dakikalar içinde güncellenir.
2. Testler ve kontroller staging'e karşı çalışır.
3. İkinci bir pull request production'ı aynı etikete yükseltir. Onu merge etmek, production dağıtımının ta kendisidir.

Geri alma, o merge'ün git revert ile geri alınmasıdır. Controller eski etiketi görür ve uygular. Tüm geçmiş Git'te olduğu için "geçen salı saat 14:00'te production'da ne çalışıyordu?" sorusunun kesin bir cevabı vardır.

Pull request'i kim açar

Yeni bir imajı yapılandırma deposuna bağlamanın iki yaygın yolu vardır:

• CI açar. Pipeline'ın son adımı yapılandırma deposunu klonlar, tek bir satırı değiştirir, bir branch'e commit eder ve bir pull request açar. Açıktır, hata ayıklaması kolaydır ve pipeline'ın yalnızca o tek depo için bir token'a ihtiyacı olur.
• Bir imaj otomasyon aracı commit eder. Flux'un imaj otomasyon controller'ları ve Argo CD Image Updater projesi bir registry'yi izleyebilir, bir politikaya uyan yeni etiketleri seçebilir ve bunları Git'e geri yazabilir. Her zaman en son build'i çalıştırması gereken staging ortamları için kullanışlıdır.

Pek çok ekip ikisini birleştirir: otomasyon staging'i güncel tutarken production değişiklikleri her zaman bir kişiden ya da bir sürüm işinden gelen, incelenmiş bir pull request olarak gelir. Hangisini seçerseniz seçin diyagrama yazın, çünkü "yeni bir sürüm buraya nasıl geliyor?" bir GitOps kurulumu hakkında herkesin sorduğu ilk sorudur.

Uçtan uca bir sürüm

Bir shop servisinin 1.8.0 sürümünü commit'ten production'a kadar takip edin:

1. Bir geliştirici uygulama deposuna bir değişikliği merge eder. CI testleri çalıştırır, imajı derler, tarar ve shop:1.8.0 imajını registry'ye iter.
2. CI, yapılandırma deposunda staging etiketini 1.7.3'ten 1.8.0'a değiştiren bir pull request açar. Bir inceleyici onaylar ve merge eder.
3. Bir iki dakika içinde controller yeni commit'i fark eder, staging manifest'lerini işler ve deployment'ı günceller. Kubernetes, imajı registry'den çeken yeni pod'ları devreye alır.
4. Duman testleri staging'de geçer. Sürüm sorumlusu, production'ı 1.8.0'a ayarlayan ikinci bir pull request açar.
5. O merge'den sonra production aynı şekilde güncellenir. Hata oranları artarsa merge commit'ini geri almak 1.7.3'ü geri getirir.

Hiçbir noktada cluster'ın dışındaki hiçbir şeyin cluster kimlik bilgilerine ihtiyacı olmadı ve her adım geride bir commit bıraktı.

Gizli bilgiler (secrets)

Düz metin secret'lar Git'e konamaz. Yaygın yaklaşımlar:

• Git'te şifrelenmiş, Sealed Secrets ya da SOPS gibi araçlarla; yalnızca cluster'ın içinde çözülür.
• Git'te referanslar, değerler başka yerde, bir secrets manager'dan okuyan External Secrets gibi bir operatörle.

Her iki durumda da yapılandırma deposu incelenebilir kalır ve secret değerleri asla bir diff'te görünmez.

Mimari diyagram

Nasıl okunur:

• Üst sıra, derleme: bir geliştirici uygulama deposuna push eder; CI 1.8.0 imajını derler, test eder ve registry'ye iter.
• Orta: CI, yapılandırma deposunda staging etiketini yükselten bir pull request açar. CI'ın dağıtıma dokunduğu tek yer burasıdır.
• Alt, cluster: GitOps controller'ı yapılandırma deposunu çeker (kesikli) ve onu artık 1.8.0 çalıştıran staging namespace'ine ve kendi pull request'i merge edilene kadar hâlâ 1.7.3 çalıştıran production'a uygular. Node'lar imajları registry'den çeker (noktalı).
• Markdown bloğu iş akışı kurallarını belirtir: pull request ile terfi, revert ile geri alma, self-heal ile geri alınan sapmalar.

Ekip için neler değişir

• CI cluster kimlik bilgilerini kaybeder. Dışarıya cluster uzanır; pipeline'ın yalnızca bir depoya yazma erişimine ihtiyacı vardır.
• İncelemeler dağıtımları da kapsar. Kimin neyi, ne zaman ve neden dağıttığı pull request geçmişindedir.
• Sapmalar görünür hale gelir. Controller, senkron olmayan kaynakları gizlemek yerine gösterir.
• Hata ayıklama yer değiştirir. "Bu neden dağıtılmadı?" sorusunun cevabı controller'ın senkronizasyon durumu ve olaylarındadır; bu yüzden onları merge eden kişilere görünür kılın.

GitOps diyagramına neler konmalı

• İki depo da, ve onları bağlayan pull request.
• Çekme yönü: pipeline'dan cluster'a değil, controller'dan yapılandırma deposuna.
• Her ortam, çalıştırdığı sürümle birlikte; böylece terfi görünür olur.
• Senkronizasyon ayarları: otomatik senkronizasyon, budama, self-heal.

Dağıtım stratejileri diyagramı devreye almanın kendisinin nasıl canary ya da blue-green olabileceğini gösteriyor, CI/CD pipeline diyagramı derleme aşamalarını ayrıntılı ele alıyor, Kubernetes mimari diyagramı cluster'ın kendisini gösteriyor, Kubernetes YAML'dan diyagrama yazısı ise yapılandırma deposundaki manifest'lerin nasıl bir resme dönüştürüleceğini anlatıyor.

Archboard'da oluşturun

1. Google ya da GitHub ile giriş yapın ve bir diyagram oluşturun.
2. C4 Modeli paketinden bir Kişi, DevOps paketinden iki Depo düğümü ve bir İş hattı, Docker paketinden de bir Kayıt deposu ekleyin.
3. Cluster için Temel paketinden bir Çerçeve ekleyin ve içine GitOps controller'ı için bir Konteyner koyun.
4. Kubernetes paketinden iki Namespace düğümü ekleyin ve her birinin içine, çalıştırdığı sürümle etiketlenmiş bir Deployment koyun.
5. Çekme işlemini controller'dan yapılandırma deposuna giden kesikli bir kenarla çizin ve iş akışı kurallarını içeren, Temel paketinden bir Markdown bloğu ekleyin.

Örnek 12 diyagram düğümü kullanıyor ve Free planın sınırları içinde kalıyor.

SSS

GitOps ile CI/CD arasındaki fark nedir? CI/CD yazılımı derler, test eder ve teslim eder. GitOps ise teslim kısmını yapmanın bir yoludur: istenen durum Git'te yaşar ve hedef ortamdaki bir ajan, bir pipeline'ın değişiklikleri içeri itmesi yerine onu çeker ve uzlaştırır.

Argo CD mi kullanmalıyım, Flux mı? İkisi de aynı modeli uygular. Argo CD'nin zengin bir web arayüzü ve uygulama odaklı görünümleri vardır; Flux ise pek çok ekibin tamamen Git ve CLI üzerinden yönettiği, birleştirilebilir controller'lardan oluşan bir settir.

Ayrı uygulama ve yapılandırma depolarına ihtiyacım var mı? Bu yaygın bir gelenektir, kural değil. Ayrı depolar dağıtım geçmişini temiz tutar ve yapılandırmanın kod yeniden derlenmeden değişebilmesini sağlar.

GitOps ile nasıl geri alırım? Yapılandırma deposunda sürümü değiştiren commit'i revert edin. Controller önceki durumu uygular.

GitOps'ta secret'lar nasıl yönetilir? Onları Git'te şifrelenmiş olarak saklayın ya da Git'te referansları tutup değerleri cluster'ın içindeki bir secrets manager'dan bir operatörün getirmesine izin verin.

Ücretsiz başlayın — tek kullanıcı, kredi kartı gerekmez.