Ansible ile Puppet karşılaştırması: ajansız itme mi, ajanlı sürekli uyum mu?

Ortak zemin: kod olarak konfigürasyon ve istenen durum

Ansible ve Puppet, sunucuların yapılandırmasını elle yapmak yerine kodla tanımlamayı sağlayan konfigürasyon yönetimi araçlarıdır. Paket kurmak, dosya ve şablon dağıtmak, servis başlatmak, kullanıcı ve izin yönetmek gibi işler ikisinde de tekrar edilebilir, sürüm kontrolünde tutulabilir ve gözden geçirilebilir hale gelir.

İkisi de istenen durum (desired state) fikrine dayanır: araca "nginx kurulu ve çalışıyor olsun" denir, araç mevcut durumu kontrol eder ve yalnız fark varsa değişiklik yapar. Ansible belgeleri bu özelliği açıkça vurgular: sistem zaten playbook'taki durumla eşleşiyorsa, playbook defalarca çalıştırılsa bile Ansible hiçbir şeyi değiştirmez. Puppet da kendini altyapının istenen durumunu Puppet koduyla tanımlayıp sürdürmenin yolu olarak tarif eder. Farklar, bu durumun nasıl ve ne sıklıkla uygulandığında başlar.

Mimari fark: itme ile çekme

Ansible'da Ansible'ın kurulu olduğu bir kontrol düğümü (control node) ve onun yönettiği uzak sistemler, yani yönetilen düğümler (managed nodes) vardır. Hangi sunucuların yönetileceği envanter (inventory) dosyasında gruplanarak listelenir. Ansible yönetilen sunuculara ek yazılım kurmaz; mevcut işletim sistemi kimlik bilgileriyle SSH üzerinden bağlanır, görevi çalıştırır ve çıkar. Yani değişiklik kontrol düğümünden itilir (push) ve playbook çalıştırıldığında gerçekleşir.

Puppet'ta ise bir birincil sunucu (primary server) ve her yönetilen düğümde çalışan bir Puppet ajanı bulunur. Ajan, Facter ile topladığı sistem bilgilerini (ana bilgisayar adı, IP adresi, işletim sistemi) sunucuya gönderir; sunucu bu bilgilere göre o düğüme özel bir katalog derler. Katalog, düğümün istenen durumunu tanımlayan bir JSON belgesidir. Ajan kataloğu uygular ve sonucu rapor olarak sunucuya geri yollar. İletişim HTTPS ve SSL sertifikalarıyla yapılır, sertifikaları yerleşik bir sertifika otoritesi yönetir. Ajanlar bu döngüyü düzenli aralıklarla tekrarladığı için Puppet, sürekli uyum (continuous enforcement) sağlayan bir çekme (pull) modeline dayanır.

Dil ve kod organizasyonu

• Ölçüt, dil: Ansible playbook'ları YAML ile yazılır, belgeler bu sözdiziminin belge gibi okunduğunu vurgular / Puppet kendi bildirimsel dili olan Puppet dilini kullanır; manifest dosyalarında kaynaklar (package, file, service) ve aralarındaki ilişkiler tanımlanır.
• Ölçüt, yürütme sırası: Ansible görevleri playbook'ta yazıldığı sırayla çalıştırır, bu da prosedürel düşünen ekiplere tanıdık gelir / Puppet'ta kaynaklar arasındaki sıra, bağımlılık ilişkileriyle açıkça belirtilir.
• Ölçüt, yeniden kullanım: Ansible'da roller ve koleksiyonlar / Puppet'ta modüller; Puppet kodunun büyük bölümü modüllerde yaşar ve topluluk modülleri Puppet Forge'da paylaşılır.
• Ölçüt, veri ile kodun ayrılması: Ansible'da envanter değişkenleri, group_vars ve host_vars / Puppet'ta Hiera; veri merkezi bir yerde tutulur, kod ortamdan bağımsız kalır.
• Ölçüt, ortam deseni: Ansible'da envanter grupları ve ortam başına envanterler / Puppet'ta rol ve profil (roles and profiles) deseni yaygın bir düzenleme yoludur.

Örneğin web sunucularına nginx kurup çalışır tutmak için Ansible'da package ve service modüllerini kullanan kısa bir görev listesi yazılır. Puppet'ta aynı istek, nginx paketini ve servisini tanımlayan bir sınıf olarak yazılır ve web sunucusu rolündeki düğümlere atanır.

Sapma kontrolü, raporlama ve uyum

Puppet'ın ajan modeli, yapılandırma sapmasını (drift) yakalamada doğal bir avantaj sağlar. Bir yönetici sunucuda bir ayarı elle değiştirirse, sonraki ajan çalışmasında Puppet bu ayarı tanımlı duruma geri döndürür ve bunu rapora yazar. İsteğe bağlı PuppetDB bileşeni olguları, katalogları ve raporları saklar; geçmiş verilerin sorgulanmasını ve başka uygulamaların bu veriye API ile erişmesini sağlar. Denetim ve uyum raporu üretmesi gereken kurumlar için bu yapı değerlidir.

Ansible'da sapma kontrolü ancak playbook yeniden çalıştırıldığında yapılır. Bunu düzenli hale getirmek için playbook'lar AWX ya da Ansible Automation Platform üzerinden zamanlanır, kontrol kipinde (check mode) çalıştırılarak değişiklik yapmadan fark raporlanır. Ansible bu sayede sürekli uyuma yaklaştırılabilir, ancak bu bir tasarım tercihi ve ek kurulum gerektirir.

Hangi durumda Ansible, hangi durumda Puppet?

Ansible'ı öne çıkaran durumlar: • Sunuculara ajan kurulamıyor ya da istenmiyor; ağ cihazları, depolama sistemleri gibi ajan çalıştıramayan hedefler de yönetilecek. • Konfigürasyonun yanında uygulama dağıtımı, sıralı bakım işleri ve olay anı müdahaleleri gibi orkestrasyon işleri yapılacak. • Ekip YAML ve SSH ile hızlıca başlamak istiyor; öğrenme eğrisinin kısa olması önemli. • Kısa ömürlü bulut sunucuları ve konteyner imajları hazırlanıyor.

Puppet'ı öne çıkaran durumlar: • Uzun ömürlü, çok sayıda sunucudan oluşan bir filo var ve tanımlı durumun sürekli korunması gerekiyor. • Yapılandırma sapmasının otomatik düzeltilmesi ve her değişikliğin raporlanması denetim gereği. • Kurumda yerleşik Puppet kodu, modül kütüphanesi ve rol-profil düzeni bulunuyor.

Sık yapılan hata, iki aracı "hangisi daha güçlü" diye karşılaştırmaktır. Asıl soru, kurumun konfigürasyonu bir kerelik değişiklik olarak mı, sürekli korunması gereken bir sözleşme olarak mı gördüğüdür.

Birlikte kullanım

Bazı kurumlar iki aracı birlikte kullanır: Puppet temel işletim sistemi yapılandırmasını, güvenlik ayarlarını ve uyumu sürekli korurken Ansible uygulama dağıtımı, sıralı yeniden başlatma ve olay anı müdahaleleri gibi bir defalık orkestrasyon işlerini üstlenir. Bu düzende en önemli kural, aynı ayarı iki aracın birden yönetmemesidir; aksi halde araçlar birbirinin değişikliğini geri alır.

Bir araçtan diğerine geçerken önce mevcut yapılandırmanın envanteri çıkarılır, hangi sınıfın ya da rolün hangi sunucu grubunu yönettiği belgelenir. Geçiş sunucu grubu bazında yapılır ve her grupta eski aracın yönetimi kapatılmadan yenisi devreye alınmaz.

Mindset programlarında Ansible ve Puppet

Ansible ile Konfigürasyon Yönetimi eğitimi playbook tasarımı, rol mimarisi, dinamik envanter ve bulut entegrasyonu ile CI/CD ve GitOps bağlantısını ele alır; Linux ve bulut sunucularını otomatikleştiren sistem yöneticileri ve DevOps mühendisleri için uygundur. Ansible'ı kurum genelinde yetkilendirme ve denetim altında işletmek isteyen ekipler Ansible Automation Platform (AWX) ile Kurumsal Otomasyon eğitimine bakabilir.

Puppet ile Konfigürasyon Yönetimi eğitimi istenen durum yönetimi, Hiera ile veri yönetimi ve rol-profil deseni üzerinden ilerler. Büyük sunucu filolarında uyum ve raporlama sorumluluğu taşıyan altyapı ekipleri için doğrudan karşılık bulur.