GitOps Nedir? Argo CD ile Adım Adım Kurulum

"Canlıya kim, ne zaman, neyi çıkardı?" sorusunun cevabı bir kişinin hafızasındaysa, sürecinizde bir sorun vardır. GitOps, bu sorunu ortadan kaldıran bir çalışma modelidir: canlı ortamın nasıl görünmesi gerektiğini Git'te tanımlarsınız ve bir araç, canlı ortamı bu tanıma göre sürekli eşitler.

Bu yazıda GitOps'un ne olduğunu, geleneksel dağıtımdan farkını ve Argo CD ile Kubernetes üzerinde adım adım nasıl kurulacağını anlatıyoruz. Yaklaşımı hem kendi altyapımızda hem müşteri ortamlarında kullanıyoruz; aşağıdaki örnekler çalışan yapılandırmaların sadeleştirilmiş halidir.

GitOps nedir?

GitOps, dört fikre dayanır:

1. Deklaratif tanım. Sistemin "nasıl yapılacağını" değil, "nasıl olması gerektiğini" yazarsınız: şu uygulamadan üç kopya, şu imaj sürümüyle, şu yapılandırmayla.
2. Git tek doğruluk kaynağıdır. İstenen durumun tamamı bir Git deposunda tutulur. Bir şeyin canlıda nasıl olduğunu öğrenmek için sunucuya değil, depoya bakarsınız.
3. Değişiklikler Git üzerinden yapılır. Canlıya bir şey çıkarmak, bir commit ve pull request demektir. Kimse kümeye elle komut çalıştırmaz.
4. Bir denetleyici sürekli eşitler. Küme içinde çalışan bir araç, canlı durumu depodaki tanımla karşılaştırır ve fark varsa düzeltir.

Bu modelin en önemli özelliği, dağıtımın çekme (pull) ile yapılmasıdır: dışarıdan kümeye bağlanıp bir şeyleri itmek yerine, küme içindeki denetleyici depoyu okur. Böylece CI sisteminizin kümeye yönetici yetkisiyle erişmesi gerekmez, bu da güvenlik açısından önemli bir kazançtır.

Geleneksel dağıtımdan farkı

Geleneksel yaklaşımda bir CI hattı derleme ve testten sonra kubectl apply gibi bir komutla kümeye değişiklik gönderir. Bu çalışır, ama bazı sorunları vardır:

Fark, en çok bir şey ters gittiğinde hissedilir. Geleneksel modelde "şu an canlıda tam olarak ne çalışıyor?" sorusu bir araştırmadır; GitOps'ta bir bakışta cevaplanır.

Argo CD nedir?

Argo CD, Kubernetes için en yaygın GitOps denetleyicilerinden biridir. Bir Git deposunu izler, içindeki manifestleri kümeyle karşılaştırır ve farkları gösterir ya da otomatik uygular. Web arayüzü, komut satırı aracı ve zengin bir uygulama durumu görünümü sunar.

Argo CD'nin merkezinde Application adlı bir kaynak vardır. Bir Application, "şu Git deposundaki şu yol, şu kümedeki şu namespace'e uygulansın" der.

Adım adım kurulum

Aşağıdaki adımlar, çalışan bir Kubernetes kümeniz ve kubectl erişiminiz olduğunu varsayar.

1. Argo CD'yi kurun

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

Bileşenlerin hazır olmasını bekleyin:

kubectl -n argocd get pods

Gerçek ortamlarda stable yerine belirli bir sürüm etiketi kullanmak ve kurulumu Helm ile yapmak daha sağlıklıdır; böylece hangi sürümün çalıştığı bilinir ve yükseltmeler kontrol altında olur.

2. Arayüze ve komut satırına erişin

Başlangıç yönetici parolası bir Secret içinde saklanır:

kubectl -n argocd get secret argocd-initial-admin-secret \
  -o jsonpath="{.data.password}" | base64 -d

Arayüze yerelde erişmek için port yönlendirme yeterlidir:

kubectl -n argocd port-forward svc/argocd-server 8080:443

Ardından tarayıcıdan https://localhost:8080 adresine admin kullanıcısıyla girebilirsiniz. İlk girişten sonra bu parolayı değiştirin ve başlangıç Secret'ını silin. Kalıcı erişim için Argo CD'yi bir Ingress arkasına, mutlaka TLS ile açın.

3. Manifestlerin bulunacağı bir depo hazırlayın

Uygulamanın Kubernetes tanımlarını, kod deposundan ayrı bir depoda tutmak yaygın ve önerilen bir düzendir. Böylece bir yapılandırma değişikliği, uygulama kodunun yeniden derlenmesini gerektirmez ve dağıtım geçmişi temiz kalır. Basit bir yapı şöyle olabilir:

gitops-repo/
  apps/
    my-app/
      deployment.yaml
      service.yaml

deployment.yaml içinde, çalışacak imaj sürümü açıkça yazılıdır:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 2
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
        - name: my-app
          image: registry.example.com/my-app:1.0.3
          ports:
            - containerPort: 3000

4. Bir Application tanımlayın

Argo CD'ye bu yolu izlemesini söyleyen kaynak:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-app
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/your-org/gitops-repo.git
    targetRevision: main
    path: apps/my-app
  destination:
    server: https://kubernetes.default.svc
    namespace: prod
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true

Uygulayın:

kubectl apply -f application.yaml

Birkaç saniye içinde Argo CD depoyu okur, prod namespace'ini oluşturur ve uygulamayı kümeye dağıtır. Arayüzde uygulamanın Synced ve Healthy durumuna geçtiğini görürsünüz.

5. Senkronizasyon ayarlarını anlayın

syncPolicy bölümündeki iki ayar, GitOps'un davranışını belirler:

• prune: true: Depodan silinen bir kaynak, kümeden de silinir. Bunu kapalı tutarsanız silinen tanımlar kümede artık olarak kalır.
• selfHeal: true: Kümede elle yapılan bir değişiklik (örneğin biri kubectl edit ile kopya sayısını değiştirdi) otomatik geri alınır. Bu, "Git tek doğruluk kaynağı" ilkesinin uygulanmasıdır.

Otomatik eşitlemeyi (automated) hiç açmazsanız Argo CD yalnızca farkı gösterir; siz onay verince uygular. Kritik üretim ortamlarında başlangıçta manuel onayla ilerleyip güven oluştuktan sonra otomatiğe geçmek makul bir yaklaşımdır.

Yeni sürümü canlıya almak

GitOps'ta dağıtım bir commit'tir. Yeni imaj sürümünü canlıya almak için deployment.yaml içindeki etiketi değiştirin:

image: registry.example.com/my-app:1.0.4

Değişikliği commit edip gönderdiğinizde Argo CD farkı algılar ve kümeyi günceller. Kubernetes yeni sürümü kademeli olarak devreye alır; sorun çıkarsa eski kopyalar çalışmaya devam eder.

Pratikte bu commit'i elle atmak yerine, CI hattınız imajı derleyip depoya gönderdikten sonra bu etiketi otomatik günceller. Böylece CI, kümeye hiç dokunmaz; yalnızca Git'e yazar.

Geri dönüş

Bir sürüm sorun çıkardığında geri dönmek, bir commit'i geri almak kadar basittir:

git revert HEAD
git push

Argo CD önceki tanımı algılar ve kümeyi buna göre eşitler. Ne zaman, kim tarafından, neden geri dönüldüğü Git geçmişinde kalır. Bu, "eski komutu bulmaya çalışmak" ile kıyaslandığında büyük bir fark yaratır.

Sık yapılan hatalar

• Gizli anahtarları depoya düz metin yazmak. Git geçmişi silinmez; bir kez giren parola sonsuza dek geçmişte kalır. Gizli anahtarlar için Sealed Secrets ya da External Secrets gibi çözümler kullanın.
• Uygulama kodu ve yapılandırmayı tek depoda karıştırmak. Her kod commit'inin bir dağıtımı tetiklemesi ya da yapılandırma değişikliğinin yeniden derleme gerektirmesi, süreci yavaşlatır.
• latest etiketi kullanmak. Hangi sürümün çalıştığı belirsizleşir ve geri dönüş anlamsızlaşır. Her zaman belirli, değişmeyen bir sürüm etiketi kullanın.
• selfHeal açıkken elle müdahale etmeye çalışmak. Acil bir düzeltme gerekiyorsa değişikliği Git'e yazın; aksi halde Argo CD elle yaptığınız değişikliği geri alır.
• Tek bir depoya herkese yazma izni vermek. Bu depo artık canlı ortamınızın kontrol paneli; erişimi, gözden geçirme zorunluluğu ve dal koruması ile sınırlayın.

GitOps ne zaman değerlidir?

Tek bir servisi tek bir ortamda çalıştıran çok küçük bir ekip için GitOps gereğinden ağır olabilir. Ancak birden çok servis, birden çok ortam ya da bir ekip söz konusuysa; denetlenebilirlik, geri dönüş kolaylığı ve kümenin tanımlı durumda kalması gerçek bir işletme yükünü hafifletir. Bu karar, Kubernetes'in kendisine geçiş kararıyla ilişkilidir; onu da küçük ekipler için Kubernetes rehberimizde ele aldık.

Sonuç

GitOps, dağıtımı bir dizi elle yapılan işlem olmaktan çıkarıp, denetlenebilir ve geri alınabilir bir Git iş akışına dönüştürür. Argo CD ile bunu kurmak birkaç saatlik bir iştir; asıl değer, sonraki her dağıtımın öngörülebilir olmasında ortaya çıkar.

Mevcut dağıtım sürecinizi GitOps'a taşımak ya da sıfırdan kurmak için desteğe ihtiyacınız varsa, DevOps danışmanlığı hizmetimizde önce mevcut durumu inceler, en riskli adımdan başlayan kademeli bir geçiş planı çıkarırız.