Terraform mu ArgoCD mi? Hangisi Ne Zaman Kullanılmalı?

Modern yazılım dünyasında altyapı ve uygulama yönetimini kod ile yapıyoruz. Çünkü “Infrastructure as Code” (IaC) ve “GitOps” yaklaşımları, ekiplerin daha güvenilir, tekrarlanabilir ve otomatize süreçler oluşturmasını sağlar. Bu noktada Terraform ve ArgoCD, DevOps ve platform mühendisliği dünyasında sıkça karşılaşılan iki güçlü araç olarak öne çıkıyor ve biraz da tercih sırasında kafa karışıklığı yaratıyor..

Bu kafa karışıklığını gidermek ve iyi bir yöntem belirleyebilmek için şu sorulara yanıt arayacağız; bu iki araç ne işe yarar? Birbirlerinin yerini alabilir mi? Hangi senaryoda hangisi tercih edilmeli?

Öyleyse, Terraform ve ArgoCD arasındaki farkları, kapsamlarını, en iyi kullanım senaryolarını ve birlikte nasıl çalışabileceklerini ele alarak başlayalım.

Öncelikle her ikisinin de temelinde yatan GitOps ile başlayalım.

1. GitOps Nedir?

GitOps, Kubernetes gibi cloud-native sistemlerde tüm infrastructure ve application konfigürasyonlarının, versioned ve immutable bir kaynakta (örneğin Git) saklanması ve bu reponun tüm sistem için single source of truth kabul edilmesi yaklaşımıdır. Desired state, declarative olarak tanımlanır; agent’lar bu durumu repodan otomatik olarak pull eder ve sistemin mevcut state’ini sürekli gözlemleyerek continuous reconciliation sağlar.

Yani kısacası: “Cluster’da ne varsa, Git’te de o olacak. Git’te olmayan hiçbir şey cluster’da olmayacak ve bu durum sürekli denetlenip state güncel tutulacak.” diyebiliriz

Peki bu sadece Kubernetes cluster için mi geçerli? Cluster dışındaki EC2, RDS gibi kaynaklarımızı da GitOps prensibiyle kullanabilir miyiz?

Bunun cevabı da evettir, ve hatta öyle olması gereklidir. Terraform ile Infrastructure'ımızı git reposunda tutabilir ve single source of truth olarak kullanabiliriz. Sadece tamamen bir GitOps yaklaşımı elde edebilmek için drift detection ya da auto reconciliation konularına dikkat etmek gerekir. Aksi halde GitOps prensiplerine uyuyoruz diyemeyiz!

2. Terraform Nedir?

Terraform, HashiCorp tarafından geliştirilen açık kaynaklı bir Infrastructure as Code (IaC) aracıdır. AWS, Azure, Google Cloud, Kubernetes ve daha birçok provider ile entegre çalışır. Infrastructure'ınızı kodda tanımlar, versiyonlar ve uygularsınız.

Neden tercih ediyoruz sorusuna gelince, sadece Kubernetes resourceları değil, harici EC2, S3, GKE gibi Kubernetes dışında kalan resourceları da yönetebiliyorsunuz.

Terraform'un çok geniş bir provider desteği mevcut. AWS, Google, Azure, DigitalOcean, VMWare, Kubernetes gibi providerlar üzerindeki tüm resourcelarınızı, servislerinizi Terraform ile yönetebilir ve statelerini tutabilirsiniz.

Aşağıdaki listeden providerları listeleyebilirsiniz.

Bu geniş provider desteği sayesinde;

• GitOps prensiplerine uymak kolaylaşır ve IaC becerisini kazanırsınız.
• Infrastructure'ı modüllere bölebilir ve yönetebilirsiniz
• State tutmuş olursunuz
• Locking mekanizmalarıyla ekip çalışmasını mümkün hale getirirsiniz

2.1 Helm varken Terraform'a gerek var mıdır?

İkisinin birbiriyle ne alakası var diye düşünebilirsiniz. Fakat bu konuda kavram karmaşası yaşandığı için ara başlık olarak ekleme ihtiyacı duydum. Örnek senaryo üzerinden bunu tartışalım.

Senaryomuzda, ArgoCD'i k8s clustera kurmak istiyoruz. Bu durumda iki alternatifimiz var.

1. Helm ile localden install etmek
2. Terraform Helm provider kullanarak install etmek

İlk seçeneğe baktığımızda, helm ile localden kurmak, bugün çalışsın yeter düşüncesinin dışa vurumudur. Bu yaklaşımın ciddi operasyonel ve mimari eksiklikleri vardır. Şimdi teknik olarak neden bu yöntemin hatalı olduğunu açıkça ortaya koyalım:

❌ Helm history != Terraform state

Helm ile localden kurulum yaptığınızda, elinizde hiçbir state olmaz. Çünkü helm history sadece release geçmişini gösterir:

• Bir helm uninstall sonrası veya helm resource'u yanlışlıkla sildiğinizde tüm history silinir. Elinizde rollback atacağınız hiçbir şey kalmaz.
  • Böyle bir durumda tekrar localden güncel values.yaml ile kurarım diyorsanız iki sonraki maddeyi okuyunuz 👇🏻
• kubectl delete ns xyz gibi bir komutta her şey uçup gider, geri dönebilmek hiçbir iz kalmaz.
  • Böyle bir durumda tekrar localden güncel values.yaml ile kurarım diyorsanız bir sonraki maddeyi okuyunuz 👇🏻
• Drift'i tespit edemezsiniz! Manual yapılan değişiklikler helm history'e yansımaz! Mevcutta çalışanla uygulama ile historydeki son revision arasında hangi manual değişikliklerin olduğunu asla bilemezsiniz.
  • Siz repoya pushladığınız values.yaml'a güveniyor olabilirsiniz ama o kurulumun üzerinden nelerin manual değiştirildiğini bilemeyeceksiniz. Üstelik bu değişiklik values.yaml içinde olmayan bir default value üzerinde de yapılmış olabilir. Herkesin clusterda admin olduğu ekiplerde bunu yaşamamak imkansız bir olay! Bu sebeple, yeniden kurduğunuzda, son çalışan kurulumdan alakasız ve uzak bir noktadan başlamış olabilirsiniz.
• Audit trail oluşturulamaz. Kim tarafından, ne zaman, hangi parametreyle (values parametrelerinden bahsetmiyorum, cli parametrelerini söylüyorum) kurulduğu asla bilinemez.
• Drift detection ve continuously reconciled prensiplerine uyulmadığı için GitOps'u uygulayamazsınız. GitOps'u uygulamak için ArgoCD kurarken, daha en başta bu prensiplere aykırı hareket etmiş olursunuz.
• Diğer resourcelara dependency oluşturamazsınız. Eğer helm kurulumunuz başka bir resource'a veya onun bir bileşenine ihtiyaç duyuyorsa depend on kuramazsınız.

Ve bu gibi sebeplerle, eğer kendi kişisel projenizi veya bir PoC yapmıyorsanız, lütfen localinizden helm install ve upgrade komutlarını kullanmayı bırakınız.

İkinci seçeneğe artık değinmeye bile gerek yok fakat yinede, Terraform Helm provider ile kurulumu yaptığınızda;

• Gerçek bir state'e sahip olursunuz,
• Mevcut state ile bir drift mevcut mu kolaylıkla anlarsınız
• Continuously reconcile'i aktif etmek kolaylaşır, çünkü artık diff'e sahipsiniz
• Locking mekanizmasıyla ekip çalışmasını kolaylaştırırsınız,

3. ArgoCD Nedir?

ArgoCD, Kubernetes-native bir GitOps aracıdır. Kubernetes manifest dosyalarınızı (YAML, Kustomize, Helm chart, vs.) Git reposunda saklayarak, K8s cluster’ınıza otomatik ve sürekli olarak senkronize eder.

Neden tercih ediyoruz sorusuna gelince, Kubernetes clusterı içindeki resourceları yönetebilmek için biçilmiş kaftandır.

Terraform'a göre tek farkı;

• hem resourceları görselleştirerek hem de diyagramla ilişkilerini göstererek environmenti anlamamızı kolaylaştırır.
• düşünülüyor...

Bu kadar 😃

Şu an şaşırmış olabilirsiniz ama bir sonraki başlıkta sebebini anlayacaksınız.

NOT: Easy boy! Avantajları demedim, farkından bahsettim.

4. Terraform mu ArgoCD mi?

Bu yazının en kritik başlığı bu olacak. Madde madde karşılaştırarak gidelim.

• Eğer yöneteceğiniz infrastructure sadece Kubernetes cluster'ınızın içindeki resourcelardan oluşmuyorsa; AWS, Google, Azure gibi providerlardaki service ve resourceları da kapsıyorsa;
  • Kazanan Terraform, hem de mutlak galibiyetle. 🎉
  • Zaten ArgoCD ile bunu yapmak mümkün değil.
• Kubernetes resourceları için, drift tespit etmek, yani manual yapılan değişiklikleri gün yüzünde çıkarmak istiyorsanız;
  • Terraform Cloud kullanarak Drift Detection özelliğinden yararlanabilirsiniz (fakat ücretli)
  • Terraform veya OpenTofu ile cronjob, bot vs kullanarak veya pipeline CI/CD süreçlerinize dahil ederek yararlanabilirsiniz (uğraştırıcı)
  • ArgoCD sync özelliği ile drift tespit edilen resourceları Out of Sync olarak işaretler. (otomatik ve herhangi bir ekstra çabaya gerek yok)

• Bu nedenle bu başlık için seçimim ArgoCD olacak 🎉
• Kubernetes resourceları için, Continuously Reconciled'ı sağlamak adına, infranızı daima desired state'de tutmak istiyorsanız;
  • Terraform Cloud kullanarak auto-approve seçeneğini seçebilirsiniz (ücretli)
  • Terraform veya OpenTofu ile --auto-approve parametresini kullanabilirsiniz (öncesinde plan komutunu çalıştırmak gerekli). Cronjob, bot vs kullanarak veya pipeline CI/CD süreçlerinize dahil ederek yapabilirsiniz (uğraştırıcı)
  • ArgoCD auto-sync özelliğini kullanabilirsiniz. (otomatik ve herhangi bir ekstra çabaya gerek yok)

• Bu nedenle bu başlık için seçimim ArgoCD olacak 🎉

• Kubernetes resourceları için, audit trail, loglama ve RBAC gerektiğinde;
  • Terraform Cloud kullanabilirsiniz (ücretli)
  • Terraform veya OpenTofu bu özellikleri sunmaz. Kubernetes tarafında bunları çözmenizi ister
  • ArgoCD'nin kendi RBAC yönetimi ve gelişmiş loglama, audit trail yetenekleri mevcut
  • Bu nedenle bu başlık için seçimim ArgoCD olacak 🎉
• Bildirim ve mesajlaşma, uygulama entegrasyonları (Slack, teams vs);
  • Terraform Cloud kullanabilirsiniz (ücretli)
  • Terraform veya OpenTofu bu özellikleri sunmaz. Kendiniz CI/CD süreçlerinize entegre etmelisiniz
  • ArgoCD desteği mevcut ve entegre olduğu uygulama sayısı çok fazla
  • Bu nedenle bu başlık için seçimim ArgoCD olacak 🎉

Bu liste böyle uzayıp gider ama özetle;

• eğer söz konusu infrastructure Kubernetes resourcelarında oluşuyorsa,
• Terraform Cloud için ücret ödemek istemiyorsanız,
• CI/CD sürecinizde kendinizi parçalamak istemiyorsanız

ArgoCD açık ara kazanan oluyor.

5. Terraform ve ArgoCD Bir Arada Nasıl Kullanılır?

Kişisel tecrübelerim ve büyük teknoloji firmalarının davranışlarını gözlemlediğimde doğru olan yöntemin aşağıdaki liste gibi olduğunu düşünüyorum ve uyguluyorum.

Terraform'u şu durumlarda tercih ediyorum;

• Cloud providerlardaki EC2, S3, VPC gibi resourcelarımı yönetirken,
• Github, bitbucket repolarımı kurarken, yönetirken,
• GSuit gibi email servislerinde mail adreslerini yönetirken,
• Kubernetes clusterlarını (EKS, GKE) kurarken,
• Kubernetes ve Helm provider ile ArgoCD i kurarken (GitOps by GitOps)

ArgoCD'i ise şu durumda kullanıyorum;

• Kubernetes clusterımdaki tüm resourceları yönetirken

Aslında buradan da anlayacağınız üzere Kubernetes içi ve dışı şeklinde bir ayrım mevcut. Cluster resourceları söz konusu olduğunda sorumluluk ArgoCD'de, öncesinde ise Terraform'da.

Bu kullanım stratejisi için şu repoyu inceleyebilirsiniz:

6. Özet

Terraform ve ArgoCD, farklı alanlara odaklanmış, güçlü ve tamamlayıcı araçlardır. "Hangisi daha iyi?" sorusundansa, "Hangi iş için hangisi daha uygun?" sorusu sorulmalıdır.

🚀 En başarılı DevOps ekipleri, bu iki aracı birlikte kullanarak hem altyapılarını hem de uygulamalarını kodla, otomatik, izlenebilir ve tekrarlanabilir şekilde yönetiyor.