Technical Tutorials

Modern uygulama dağıtımı yalnızca hız değil, güvenilirlik de gerektirir. Kubernetes dünyasında sıfır kesintiye uğramayan dağıtımlar artık bir lüks değil; üretim düzeyindeki sistemler için temel bir beklentidir. GitLab CI'ın derleme ve test süreçlerindeki sağlamlığını, ArgoCD'nin dağıtım orkestrasyonu için bildirimci gücüyle birleştirerek, güncellemeler sırasında hizmetlerinizin erişilebilir kalmasını sağlayan GitOps tabanlı bir hat oluşturabilirsiniz.

Neden GitLab CI ve ArgoCD Bir Arada Kullanılmalı?

Geleneksel CI/CD araçları genellikle hem derlemeyi hem de dağıtımı tek bir monolitik adımda ele alır. Bu yaklaşım etkili olsa da karmaşık durum yönetimi sorunlarına yol açabilir. Sorumlulukları ayırmak belirgin avantajlar sunar:

GitLab CI: Derleme, birim testleri, görüntü oluşturma ve artefaktları bir konteyner kayıt defterine (registry) itme konularında üstün performans gösterir.
ArgoCD: Git deponuzda tanımlanan istenen durumu, Kubernetes kümenizin canlı durumuyla senkronize etmede uzmanlaşmıştır.

Bu ayrım, "nasıl derleneceğini" "nasıl dağıtılacağından" ayırmanızı sağlar; bu da daha net denetim izleri ve daha basit geri alma (rollback) mekanizmaları sunar.

GitLab CI Hattının Kurulması

Öncelikle GitLab CI iş akışını tanımlayalım. Buradaki temel amaç, bir konteyner görüntüsü üretmek ve Git depodaki Kubernetes manifestlerini güncellemektir. Bu, GitOps'un temel ilkesidir: Git deposu tek doğruluk kaynağıdır.

stages:
  - build
  - push
  - deploy

variables:
  REGISTRY_IMAGE: $CI_REGISTRY_IMAGE

build:
  stage: build
  image: docker:latest
  services:
    - docker:dind
  script:
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
    - docker build -t $REGISTRY_IMAGE:$CI_COMMIT_SHA .
  only:
    - main

push:
  stage: push
  image: alpine:latest
  script:
    - apk add --no-cache git
    - git config --global user.email "gitlab-ci-token@gl-sa-pipeline"
    - git config --global user.name "GitLab CI"
    - echo "$CI_REGISTRY_PASSWORD" > ~/.netrc
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
    - docker push $REGISTRY_IMAGE:$CI_COMMIT_SHA

update-manifests:
  stage: deploy
  image: alpine:latest
  script:
    - apk add --no-cache git
    - git config --global user.email "gitlab-ci-token@gl-sa-pipeline"
    - git config --global user.name "GitLab CI"
    - cd k8s-manifests
    - sed -i 's|image: .*$|image: '$REGISTRY_IMAGE':$CI_COMMIT_SHA|' deployment.yaml
    - git add .
    - git commit -m "Update image to $CI_COMMIT_SHA" || true
    - git push origin main
  only:
    - main
  after_script:
    - echo "Manifests updated. ArgoCD will now detect the change."

update-manifests işini (job) fark edin. Bu iş doğrudan Kubernetes'e dağıtım yapmaz. Bunun yerine, depodaki deployment.yaml dosyasını yeni görüntü etiketiyle günceller. Bu, ArgoCD'nin Git deposundaki değişikliği farklamasını tetikler.

GitOps için ArgoCD Yapılandırması

ArgoCD, Kubernetes kümenizde bir denetleyici (controller) olarak çalışır. Git deponuzu sürekli olarak izler. Manifestlerde bir değişiklik (örneğin GitLab CI'dan gelen görüntü etiketi güncellemesi) algıladığında, kümeyi yeni durumla otomatik olarak senkronize eder.

Sıfır kesinti sağlamak için, Kubernetes dağıtım stratejinizin RollingUpdate olarak ayarlanmış olması gerekir. Bu varsayılan stratejidir, ancak açıkça belirtmek iyidir.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app
        image: registry.gitlab.com/group/my-app:latest
        ports:
        - containerPort: 8080
        readinessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 10

Sıfır Kesinti İçin Temel Yapılandırma:

maxUnavailable: 0: Güncelleme sırasında kullanılamaz pod sayısının sıfırdan fazla olmamasını sağlar. Bu, en az replicas (bu durumda 3) pod'un her zaman çalışıyor ve trafiği karşılamaya hazır olduğunu garanti eder.
readinessProbe: ArgoCD ve Kubernetes, bir pod'un "Hazır" olup olmadığını belirlemek için bu sonda (probe)ya güvenir. Yeni bir pod, bu sonda başarılı olduktan sonra ancak sağlıklı kabul edilir ve IP'si Service'in Endpoints'ine eklenir. Bu, trafiğin tam olarak başlatılmamış pod'lara yönlendirilmesini engeller.

Sıfır Kesintiye Uğramayan Akış

Bir geliştirici kodu main dalına birleştirdiğinde adım adım süreç şöyledir:

Tetikleyici: GitLab CI hattı başlar.
Derleme ve İtme: Yeni bir Docker görüntüsü derlenir ve benzersiz bir commit SHA etiketiyle kayıt defterine itilir.
Manifest Güncellemesi: CI işi, Git deposundaki deployment.yaml dosyasını yeni görüntü etiketini referans alacak şekilde günceller ve bunu commit'ler.
ArgoCD Senkronizasyonu: ArgoCD, Git commit değişikliğini algılar. İstenen durumu (yeni görüntü) canlı durumla (eski görüntü) karşılaştırır.
Kademeli Güncelleme (Rolling Update): ArgoCD, yeni manifesti Kubernetes'e uygular.
- Kubernetes, yeni görüntüyle yeni bir ReplicaSet oluşturur.
- Yeni pod'lar başlar ve readiness sonda testlerini geçer.
- Kubernetes, eski pod'ları sonlandırmaya yalnızca yeni pod'lar hazır olduktan sonra başlar.
- LoadBalancer/Service, bu geçiş boyunca trafiği sağlıklı pod'lara yönlendirmeye devam eder.
Tamamlanma: Tüm yeni pod'lar çalışır durumda, eski pod'lar sonlandırılmış ve uygulama sıfır kesintiye uğramadan tamamen güncellenmiştir.

Dirençlilik İçin En İyi Uygulamalar

Görüntüler için Anlamlı Sürümleme (Semantic Versioning) Kullanın: Commit SHA'ları hassas olsa da, anlamlı etiketler (örneğin, v1.2.0) ArgoCD arayüzünde geri almayı kolaylaştırır. Git commit'ini geri alarak görüntü etiketini önceki kararlı sürüme döndürebilirsiniz.
Sağlık Kontrolleri Hayati Önem Taşır: livenessProbe ve readinessProbe yapılandırmalarının doğru olduğundan emin olun. Yeni bir pod readiness kontrolünü geçemezse, ArgoCD senkronizasyonu sağlıksız olarak işaretler; bu da eski pod'lar kaldırılmadan önce müdahale etmenizi sağlar.
ArgoCD Senkronizasyon Pencereleri: Daha sıkı kontrol için, kritik iş saatlerinde otomatik dağıtımları önlemek üzere ArgoCD senkronizasyon pencerelerini yapılandırın.
İzleme: Senkronizasyon durumunu, sağlığı ve dağıtım süresini izlemek için ArgoCD metriklerini Prometheus/Grafana ile entegre edin.

Sonuç

GitLab CI'ı derleme otomasyonu ve ArgoCD'yi bildirimci dağıtım için kullanarak sağlam, denetlenebilir ve dirençli bir CI/CD hattı oluşturursunuz. Sıfır kesintinin anahtarı, araçların kendisinde değil, Kubernetes Kademeli Güncelleme stratejilerinin doğru yapılandırılmasında ve titiz sağlık sonda testlerinde yatar. Bu GitOps yaklaşımı, dağıtımlarınızın öngörülebilir, geri alınabilir ve doğruluk kaynağınız olan Git depoyla her zaman senkronize olmasını sağlar.