Furkan İkkan English
Yazılara geri dön
Yazı

· Network & System Administrator

GitOps ile Altyapı Yönetimi: Manuel Deploy'lara Son

GitOps altyapınızı version control altına alır; her değişiklik takip edilir, review edilir ve otomatik deploy edilir. İnsan hatasını ve SSH seanslarını bitirin.

DevopsDevOpsGitOpsArgo CDFluxInfrastructure as CodeKubernetesTerraform

GitOps altyapı yönetimi demek, tüm altyapı konfigürasyonunuzu Git'te tutmak ve bu değişiklikleri ortamınıza uygulayan otomatik bir controller'a sahip olmak demek. Sunuculara SSH ile girip komutları elle çalıştırmak yerine, bir commit push'luyorsunuz ve sistem kendini reconcile ediyor. Bu modeli Proxmox cluster'larımda ve Kubernetes workload'larımda bir süredir kullanıyorum ve hata oranlarındaki fark inanılmaz.

Daha önce DevOps vs klasik sysadmin yazımda (https://furkanikkan.com/urun/devops-vs-klasik-sysadmin-2025-te-hangi-model-one-cikiyor-56) da belirttiğim gibi, manuel operasyonlardan declarative altyapıya geçiş sadece bir trend değil — düzinelerce ortamı tükenmeden yönetmenin tek yolu bu.

GitOps Pratikte Ne Demek?

Temel fikir basit: Git sizin tek source of truth'unuz. Production'da hiçbir şey, arkasında bir commit olmadan değişmez. Cluster'ınızın içinde çalışan bir controller, Git'teki istenen durum ile sunuculardaki gerçek durumu sürekli karşılaştırır ve drift'ler otomatik olarak düzeltilir.

Benim bağlı kaldığım dört prensip:

  • Declarative konfigürasyon — her şey kod olarak tanımlanır, imperative script'ler değil
  • Version control — her değişikliğin bir geçmişi, bir yazarı ve bir rollback noktası vardır
  • Otomatik pull — controller değişiklikleri fetch eder ve uygular, CI'dan push değil
  • Sürekli reconciliation — biri manuel olarak bir sunucuyu edit ederse, GitOps onu geri alır

Son nokta insanların düşündüğünden daha önemli. Benim ortamımda incident'ların en büyük kaynağı "biri sabah 2'de bir şeyi fix etti ve dokümante etmeyi unuttu" olurdu. GitOps bunu gizlemeyi imkansız kılar.

Argo CD ve Flux: Gerçekten Kullandığım İki Araç

Kubernetes ortamları için Argo CD ve Flux kullanıyorum. İkisi de aynı temel işi yapıyor — bir Git repo'sunu izler, değişiklikleri algılar, cluster'a uygular — ama pratikte farklı hissettiriyorlar.

Argo CD'nin web UI'sı deploy edilenleri görselleştirmek için gerçekten faydalı. Birden fazla takımın görünürlüğe ihtiyaç duyduğu ortamlarda onu kullanıyorum. Flux daha hafif, daha CLI odaklı ve daha küçük cluster'larda minimal overhead istediğimde daha iyi uyuyor.

Kullandığım temel bir Flux setup'ı:

flux bootstrap git \
  --url=ssh://[email protected]/infra/cluster-config \
  --branch=main \
  --path=clusters/staging

Bu tek komut Flux'u kuruyor, repo'ya bağlıyor ve sync'i başlatıyor. O andan itibaren clusters/staging/'e merge ettiğim her şey otomatik olarak uygulanıyor.

Kubernetes dışı altyapı için — Proxmox VM'leri, DNS kayıtları, load balancer konfigürasyonları — Terraform kullanıyorum ve trigger olarak Git repo'sunu alıyorum. CI pipeline'ı her PR'da terraform plan çalıştırıyor, main'e merge'den sonra sadece terraform apply çalışıyor.

Pull Request'lerle İnsan Hatasını Azaltmak

En büyük kazanç otomasyon değil — review süreci. Biri bir firewall kuralını değiştirmek veya replica sayısını artırmak istediğinde, PR açıyor. Production'a bir şey dokunmadan önce başka bir göz diff'i görüyor. Yanlış yapılandırılmış CIDR range'leri, hatalı memory limitleri ve 0 saniyeye ayarlanmış bir DNS TTL'i yakaladım — hepsi outage'a yol açmadan önce PR review'larında.

Workflow şöyle:

  1. Engineer bir branch oluşturur ve ilgili manifest'i edit eder
  2. CI terraform plan veya kubectl diff --server-side çalıştırır ve sonuçları PR'a post eder
  3. Bir reviewer onaylar veya değişiklik ister
  4. Main'e merge, controller'ı değişikliği uygulamaya tetikler
  5. Bir şey kırılırsa, git revert saniyeler içinde önceki duruma geri alır

Bunu eski yöntemle karşılaştırın: biri SSH ile girer, bir değişiklik yapar, sabah 3'te bir şey kırılır ve kimse neyin değiştiğini bilmez. Bu senaryoyu çok fazla yaşadım.

Downtime Olmadan Configuration Drift Yönetimi

Drift olur. Biri bir node'da bir şey test eder, bir package pipeline dışında güncellenir veya bir cron job bir config dosyasını değiştirir. GitOps olmadan, o drift sessizce birikir ve incident'a yol açana kadar devam eder.

Sürekli reconciliation ile controller drift'i algılar ve düzeltir. Git'te replica sayısını 4 olarak ayarlarsam ve biri manuel olarak 6'ya çıkarırsa, bir dakika içinde tekrar 4'e döner. Kulağa katı geliyor ama production'da tam istediğiniz bu. Değişiklik meşruysa, önce Git'ten geçer.

Nereden Başlamanızı Öneririm

Kubernetes çalıştırıyorsanız, Argo CD ile başlayın. UI insanların ne olduğunu anlamasına yardımcı oluyor ve öğrenme eğrisi daha yumuşak. CLI workflow'larına zaten alışkın olan takımlar için Flux setup'ı daha hızlı ve kaynaklarda daha hafif.

Kubernetes dışındaki her şey için — VM'ler, DNS, CDN konfigürasyonları, firewall kuralları — Terraform'a koyun ve apply'ı Git'ten trigger edin. Bu kısım için fancy bir controller'a ihtiyacınız yok; merge'de çalışan bir GitLab CI veya GitHub Actions pipeline'ı yeterli.

İlk setup bir hafta sonu sürüyor. Getirisi kalıcı. GitOps'a geçtikten sonra incident sayım ciddi şekilde düştü ve rollback süreleri "backup'tan restore et ve umut et"ten tek bir git revert'a indi.

GitOps bir gümüş kurşun değil — monitoring, alerting ve iyi backup'lara hala ihtiyacınız var (3-2-1 backup kuralı yazımda ele aldığım gibi: https://furkanikkan.com/urun/3-2-1-yedekleme-kurali-sadece-yedek-almak-yetmez-49). Ama altyapı yönetimindeki en yaygın failure mode'u ortadan kaldırıyor: takip edilmeyen manuel değişiklikler. Hala config değişikliği için production sunucularına SSH ile giriyorsanız, sıradaki hamleniz bu.

Kapak görseli: HD Wallpapers · CC0 (Openverse / kamu malı) · https://stocksnap.io/photo/light-abstract-V9L6XXK3LB