Argo CD ve Flux ile GitOps tabanlı sürekli dağıtım kurulumu

GitOps dağıtımı geleneksel CD'den nasıl ayrılır?

Geleneksel CI/CD hattında pipeline, işin sonunda kümeye bağlanıp kubectl ya da Helm komutu çalıştırır; yani değişikliği dışarıdan iter. GitOps'ta ise kümenin içinde çalışan bir ajan, Git deposunda tanımlı istenen durumu düzenli olarak okur ve kümenin gerçek durumunu buna eşitler. Bağlantıyı küme başlattığı için CI sistemine kümenin yönetici anahtarını vermeniz gerekmez.

İş bölümü şöyle kurulur: CI tarafı kodu derler, testleri çalıştırır, imajı üretir ve kayıt defterine gönderir; ardından dağıtım deposundaki sürüm bilgisini günceller. CD tarafını Argo CD ya da Flux üstlenir ve depodaki değişikliği kümeye yansıtır. Kümede elle yapılan bir değişiklik depodaki tanımdan sapma (drift) yaratır; ajan bunu ya rapor eder ya da geri alır. Böylece Git hem değişiklik geçmişi hem denetim kaydı hem de geri dönüş noktası olur.

Dağıtım deposunun düzeni

GitOps'un kalitesi, depo düzeninin netliğine bağlıdır. Yaygın yaklaşım, uygulama kodunu ve dağıtım tanımlarını ayrı depolarda tutmaktır. Böylece sürüm bilgisi değişikliği, uygulama geliştirme akışında gürültü yaratmaz ve dağıtım tanımlarına erişim ayrıca yetkilendirilebilir. Küçük ekiplerde tek depo da işe yarar, ama klasörlerin ortama göre ayrılması şarttır.

Örnek bir düzen:

apps/ odeme-servisi/ base/ deployment.yaml service.yaml kustomization.yaml overlays/ staging/ kustomization.yaml production/ kustomization.yaml

Base klasörü ortak tanımı, overlays klasörleri ise ortama özgü farkları (imaj etiketi, kopya sayısı, kaynak sınırı) taşır. Helm kullanıyorsanız aynı mantıkla ortam başına bir values dosyası tutulur. Ortamlar arası terfi (promotion) bu durumda bir dosyadaki imaj etiketini staging'den production'a taşıyan, gözden geçirilen bir birleştirme isteğidir.

Argo CD kurulumu ve ilk giriş

Argo CD, kümede kendi ad alanında çalışır. Resmî başlangıç belgesindeki akış şöyledir:

kubectl create namespace argocd kubectl apply -n argocd --server-side --force-conflicts -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

Server-side apply gereklidir; çünkü bazı Argo CD kaynak tanımları (örneğin ApplicationSet) istemci taraflı apply'ın ek açıklama boyutu sınırını aşar. Kurulumdan sonra argocd komut satırı aracını edinip kümeye erişim sağlarsınız. Arayüze erişim için argocd-server servisini LoadBalancer tipine çevirebilir ya da kubectl port-forward ile geçici erişim açabilirsiniz.

Yönetici (admin) hesabının ilk parolası otomatik üretilir ve argocd-initial-admin-secret adlı Secret içinde tutulur. Parolayı şu komutla okursunuz:

argocd admin initial-password -n argocd

Giriş için argocd login komutu kullanılır. Belge, başlangıç parolası kullanıldıktan sonra bu Secret'ın silinmesini önerir. Kendi kümenizin dışındaki bir kümeye dağıtım yapacaksanız argocd cluster add ile hedef kümeyi kaydedersiniz.

Application kaydı: depoyu kümeye bağlamak

Argo CD'de bir uygulama, Application adlı kaynakla tanımlanır. Kaynak depo, yol ve hedef küme-ad alanı burada belirtilir:

apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: odeme-servisi-staging namespace: argocd spec: project: default source: repoURL: https://git.example.com/platform/dagitim-deposu.git targetRevision: main path: apps/odeme-servisi/overlays/staging destination: server: https://kubernetes.default.svc namespace: odeme syncPolicy: automated: {} syncOptions: - CreateNamespace=true

Bu tanımı kubectl apply ile kümeye uygulamak yeterlidir; Argo CD depoyu okur, yolu çözer (düz manifest, Kustomize ya da Helm olabilir) ve kümedeki durumu karşılaştırır. Arayüzde uygulama Synced ya da OutOfSync olarak, sağlık durumu da Healthy, Progressing veya Degraded gibi etiketlerle görünür. Çok sayıda benzer uygulama için ApplicationSet kaynağı, bir şablondan klasör ya da küme başına otomatik Application üretir.

Senkronizasyon politikası: elle mi otomatik mi, prune ve selfHeal

Varsayılan davranışta Argo CD farkı gösterir ama uygulamaz; sync işlemini siz tetiklersiniz. Üretim öncesi ortamlarda otomatik senkronizasyon (automated sync) açılır. Bu durumda depodaki her değişiklik kümeye kendiliğinden yansır. Şu ayarlar kritik önemdedir:

• prune: Depodan silinen kaynak kümeden de silinsin mi? Güvenlik amacıyla otomatik senkronizasyon, Git'te artık tanımlı olmayan kaynakları varsayılan olarak silmez. Silmesini istiyorsanız automated altında prune: true yazarsınız.
• selfHeal: Biri kümede elle bir değişiklik yaparsa Argo CD bunu depodaki duruma geri çevirsin mi? selfHeal: true ile geri çevirir. Kapalıyken elle yapılan değişiklik, depoda yeni commit olana kadar kalır.

SyncPolicy bölümünün otomatik hali şöyle görünür:

syncPolicy: automated: prune: true selfHeal: true

Kritik production uygulamalarında birçok ekip otomatik prune'u kapalı bırakıp senkronizasyonu elle onaylatır; ya da senkronizasyon penceresi tanımlayarak dağıtımı belirli saatlere sınırlar. Kaynakların bağımlılık sırasıyla uygulanması gerekiyorsa (veritabanı göçü, ardından uygulama) sync aşamaları ve dalgaları kullanılır.

Flux ile yaklaşım farkı ve seçim ölçütleri

Flux aynı fikri farklı bir yapıyla uygular. Kaynaklar (Sources) isimli kaynak türleriyle tanımlanır: GitRepository, OCIRepository, HelmRepository ve Bucket. Bu kaynaklardan gelen çıktıyı Kustomization ve HelmRelease kaynakları kümeye uygular. Flux belgeleri uzlaştırma (reconciliation) döngüsünü anlatır; Kustomization için varsayılan uzlaştırma aralığı dakikalar mertebesindedir ve .spec.interval ile değiştirilebilir. Kümede kubectl ile yapılan değişiklikler hızla geri alınır; bunu engellemek istiyorsanız uzlaştırmayı askıya almak ya da değişikliği depoya göndermek gerekir.

Seçim ölçütleri:

• Görsel arayüz ihtiyacı: Argo CD'nin uygulama ağacı ve fark görünümü yerleşik gelir; Flux ağırlıklı olarak komut satırı ve kaynak durumları üzerinden çalışır.
• Çok kümeli yönetim: İkisi de destekler; Argo CD merkezi bir kontrol düzlemi gibi çalışırken Flux her kümede bağımsız ajan olarak oturur.
• Helm ve Kustomize birlikte kullanımı: İkisinde de yerleşik destek vardır.
• Ekibin alışkanlığı: Kubernetes kaynak yönetimine alışkın ekipler Flux'u, görsel takip isteyenler Argo CD'yi daha kolay benimser.

Seçim, teknik üstünlükten çok işletme tarzı sorusudur; aynı kurumda farklı ekiplerin farklı aracı seçmesi de görülür.

Sır yönetimi ve sık yapılan hatalar

GitOps'ta en büyük tuzak, Secret nesnelerini depoya düz metin olarak koymaktır. Kubernetes Secret değerleri yalnızca base64 kodludur, şifreli değildir. Depoya şifreli biçimde koyabilen araçlar (örneğin Sealed Secrets ya da SOPS ile şifreleme) veya sırları kümeye dışarıdaki bir kasadan çeken operatörler kullanılmalıdır. Hangi yöntemi seçerseniz seçin, parolanın kendisi hiçbir zaman commit geçmişinde yer almamalıdır.

• Elle kubectl düzenlemesi yapmak: selfHeal açıksa değişiklik silinir, kapalıysa depoyla küme arasında sessiz uyumsuzluk oluşur. Acil müdahale gerekiyorsa değişikliği hemen depoya da yansıtın.
• Ortam ayrımı olmadan tek klasör kullanmak: Staging için yapılan değişiklik yanlışlıkla production'a gider.
• Her şeyi tek Application'a yüklemek: Hata ayıklama ve geri alma zorlaşır; uygulamaları mantıklı birimlere bölün.
• Prune'u bilinçsiz açmak: Yanlış taşınan bir klasör, kümedeki canlı kaynakları siler. Önce pilot ortamda deneyin.
• İmaj etiketi olarak latest kullanmak: Hangi sürümün çalıştığı izlenemez; sabit etiket ya da özet değeri (digest) kullanın.

Bu beceriyi Mindset programlarında nerede çalışırsınız?

GitOps tabanlı dağıtım, DevOps ve platform mühendislerinin, Kubernetes yöneticilerinin ve yazılım ekibinde sürüm sürecinden sorumlu kıdemli geliştiricilerin çalıştığı bir alandır. Mindset kataloğunda birkaç program bu konuya farklı noktalardan değiniyor. CI/CD Pipeline Tasarımı (GitLab) programı GitLab ile GitOps ve olgunluk modülünü içeriyor; Helm ve K8s Paket Yönetimi programında GitOps ile Helm entegrasyonu ve üretim Helm yönetimi var; Ansible ile Konfigürasyon Yönetimi programında CI/CD ve GitOps ile Ansible başlığı yer alıyor.

Kurumsal ekipler bu programları birlikte düşünerek hat, paketleme ve altyapı otomasyonunu aynı dağıtım modeline oturtabilir.