iToverDose/Yazılım· 24 NISAN 2026 · 12:08

GitOps Sürecini Basitleştiren Kargo: CI ve ArgoCD Entegrasyonu Nasıl Olmalı?

GitOps’un sunduğu altyapı yönetimindeki kolaylıklar, sürekli entegrasyon ve dağıtım arasındaki boşluk nedeniyle gölgede kalabiliyor. Kargo, bu boşluğu doldurarak CI çıktılarını ArgoCD’ye sorunsuzca aktaran yeni bir platform sunuyor.

DEV Community4 dk okuma0 Yorumlar

GitOps yaklaşımı, altyapıyı kod olarak yönetmeyi vaat ederken, sürekli entegrasyon (CI) ve dağıtım (CD) arasındaki geçiş süreci genellikle zorluklarla doludur. ArgoCD, Kubernetes kümelerindeki durumun Git depolarıyla senkronize edilmesinde oldukça başarılı olsa da, yeni container görüntüleri veya Helm chart’ları mevcut olduğunda bu manifest’lerin manuel olarak güncellenmesini gerektirir. Bu geçiş noktası, CI çıktıları ile GitOps arasındaki bağı koparan geleneksel yöntemlerin aksine, Kargo gibi yeni nesil çözümlerle daha akıcı hale getirilebilir.

Kargo, Akuity tarafından geliştirilen ve ArgoCD’nin de arkasındaki ekip tarafından desteklenen bir sürekli promosyon platformudur. Bu araç, CI ve ArgoCD arasındaki boşluğu doldurarak, altyapı yönetiminde modülerlik ve bağımsızlık ilkesini korurken, dağıtım süreçlerini standartlaştırır.

GitOps’ta Gizli Tıkanıklık: CI ve CD Arasındaki Boşluk

Çoğu GitOps kurulumu, en az iki depoya dayanır: biri uygulama kaynak kodunu, diğeri ise Kubernetes manifest’lerini içerir. Sürekli entegrasyon boruları, container görüntülerini oluşturur, bunları kayıt hizmetlerine (örneğin AWS ECR) gönderir ve ardından yeni görüntü etiketlerini manifest deposuna eklemek için doğrudan Git’e commit yapar. Bu yöntem işlevsel olsa da, aşağıdaki gibi sorunlara yol açabilir:

  • Bağımlılık yoğunluğu: CI boruları, GitOps deposunun yapısını (örneğin Kustomize katmanları veya ortam yolları) anlamak zorundadır. Manifest deposundaki bir yeniden düzenleme, birçok CI yapılandırmasının güncellenmesini gerektirebilir.
  • Ortam karmaşası: Geliştirme ortamından üretim ortamına geçiş süreçlerinde yapılan değişiklikler, her hizmet deposunda .gitlab-ci.yml gibi dosyaların düzenlenmesini zorunlu kılar.
  • Kayma riski: Manuel veya komut dosyasıyla yapılan commit’ler, özellikle birden fazla takımın aynı GitOps deposunu paylaştığı durumlarda tutarsızlıklara yol açabilir.

Kargo, bu sorunları çözmek için sürekli promosyon adı verilen yeni bir katman ekler. Bu katman, CI çıktılarını ArgoCD’ye aktarırken, bağımsızlığı ve denetlenebilirliği korur.

Kargo ile GitOps Promosyonlarının Yeniden Tasarlanması

Kargo, mevcut araçları değiştirmek yerine onları destekleyen bir platformdur. Sürekli promosyon kavramını merkeze alarak, cluster durumunu yönetmek yerine Git manifest’lerinin güncellenmesine odaklanır. Platformun çekirdek bileşenleri, ortamlar arasında tutarlı ve otomatik promosyonlar sağlamak için birlikte çalışır.

Temel Kavramlar ve İş Akışı

Kargo’nun mimarisi dört ana soyutlama üzerine kuruludur:

  • Depolar (Warehouses): Bu bileşenler, container kayıt hizmetleri, Helm depoları ve hatta Git commit’lerini izler. Yeni bir görüntü, chart veya manifest versiyonu ortaya çıktığında, Depo bu referansları Freight adı verilen bir nesneye toplar. Freight, bir promosyon için gerekli olan tüm bileşenlerin versiyonlarını içeren, kendi kendine yeten bir pakettir.
  • Freight: Freight, manifest’lerin manifest’i olarak düşünülebilir. Bir promosyon sırasında kullanılan tüm görüntü, chart ve bağımlılıkların belirli versiyonlarını içerir. Freight, ortamlar arasında tutarlılığı sağlamak için bir boru hattı boyunca ilerler.
  • Aşamalar (Stages): Bu bileşenler, geliştirme, test ve üretim gibi ortamları temsil eder. Freight, her Aşamaya yalnızca onay veya otomatik kriterler karşılandığında ilerleyebilir.
  • PromosyonGörevleri (PromotionTasks) ve KümePromosyonGörevleri (ClusterPromotionTasks): Bu görevler, Freight’ı bir Aşamaya aktarmak için gerekli adımları tanımlar. PromosyonGörevleri proje bazlıyken, KümePromosyonGörevleri küme genelinde geçerlidir ve birden fazla uygulama için yeniden kullanılabilir iş akışları sunar.

Tipik Bir Promosyon Akışı

İş akışı, bir geliştiricinin commit’iyle başlar. GitLab CI (veya başka bir CI sistemi), kodu derler, testleri çalıştırır ve oluşan container görüntüsünü (örneğin AWS ECR’ye) gönderir. Aynı anda, Helm chart’ları da bir OCI kayıt hizmetine veya Helm deposuna yayınlanır. Bu noktada, CI borusunun görevi tamamlanır.

Kargo’nun Deposu, yeni bir bileşeni algılar ve Freight adı verilen bir nesne oluşturur. Bu Freight, geliştirme Aşamasına girer ve KümePromosyonGörevleri tarafından tanımlanan standart adımlar yürütülür:

  1. GitOps deposunu geçici bir çalışma alanına klonlar.
  2. İlgili YAML dosyasını (örneğin, Helm değerleri dosyası veya Kustomize katmanı) yeni görüntü etiketi veya chart versiyonuyla günceller.
  3. Değişikliği açıklayıcı bir mesajla commit eder.
  4. Güncellemeyi GitOps deposuna gönderir.

ArgoCD, GitOps deposunu sürekli izlediğinden, yapılan değişikliği algılar ve cluster’ı yeni duruma senkronize eder. Bu süreç, test ve üretim gibi sonraki Aşamalarda da tekrarlanır. Promosyonlar, Kargo’nun arayüzü üzerinden manuel olarak ya da otomatik olarak tetiklenebilir.

KümePromosyonGörevleri ile Standartlaştırılmış Promosyonlar

Kargo’nun en güçlü özelliklerinden biri, KümePromosyonGörevleri ve PromosyonGörevleri arasındaki ayrımdır. KümePromosyonGörevleri, küme genelinde kullanılabilen yeniden kullanılabilir promosyon mantığını tanımlarken, PromosyonGörevleri ise proje bazlı özel adımlar içerebilir.

Örneğin, iki farklı KümePromosyonGörevleri, yaygın senaryoları ele alabilir:

apiVersion: kargo.akuity.io/v1alpha1
kind: ClusterPromotionTask
metadata:
  name: image-to-git-promote
spec:
  vars:
    - name: branch
      value: main
    - name: repoURL
      value: git@gitlab.com:org/gitops-repo.git
    - name: yamlPath
      value: overlays/dev/image.yaml
    - name: imageField
      value: spec.image.tag

  steps:
    - uses: git-clone
      config:
        repoURL: ${{ vars.repoURL }}
        checkout:
          branch: ${{ vars.branch }}
        create: true
        path: ./workspace

    - uses: yaml-update
      as: update-image
      config:
        path: ./workspace/${{ vars.yamlPath }}
        updates:
          - key: ${{ vars.imageField }}
            value: ${{ quote(imageFrom(vars.image).Tag) }}

    - uses: git-commit
      as: commit
      config:
        path: ./workspace
        message: "Görüntü etiketini ${{ imageFrom(vars.image).Tag }} olarak güncelle"

    - uses: git-push
      config:
        path: ./workspace

Bu tanımlar, görüntü etiketlerini GitOps deposuna otomatik olarak aktarmak için yeniden kullanılabilir bir şablon sunar. Benzer şekilde, farklı ortamlar için özel görevler de tanımlanabilir.

Geleceğe Bakış: GitOps’un Evrimi

Kargo gibi araçlar, GitOps’un sunduğu avantajları korurken, CI ve CD arasındaki boşluğu doldurarak süreçleri daha güvenilir ve ölçeklenebilir hale getiriyor. Gelecekte, bu tür platformların daha da yaygınlaşması ve Kubernetes tabanlı uygulamaların dağıtımında standart bir bileşen haline gelmesi bekleniyor. Geliştiricilerin ve DevOps ekiplerinin, altyapı yönetimini basitleştirirken aynı zamanda güvenlik ve tutarlılığı da artırabilecekleri yeni çözümler, teknoloji dünyasında önemli bir yer tutmaya devam edecek.

Kargo’nun sunduğu bu yenilikçi yaklaşım, GitOps’un potansiyelini tam anlamıyla ortaya çıkarmak için kritik bir adım olarak değerlendirilebilir.

Yapay zeka özeti

GitOps’taki CI ve CD boşluğunu kapatan Kargo’nun nasıl çalıştığını, avantajlarını ve Kubernetes ortamlarında nasıl kullanılabileceğini öğrenin.

Yorumlar

00
YORUM BIRAK
ID #M1ZDKM

0 / 1200 KARAKTER

İnsan doğrulaması

9 + 4 = ?

Editör onayı sonrası yayına girer

Moderasyon · Spam koruması aktif

Henüz onaylı yorum yok. İlk yorumu sen bırak.