Ansible ile Sunucu Konfigürasyonu Nasıl Yönetilir?

Konfigürasyon yönetimi ve Ansible'ın yeri

Konfigürasyon yönetimi, sunucuların ve altyapının istenen durumunu kodla tanımlayıp tekrarlanabilir biçimde uygulamaktır. Elle yapılan kurulumlarda her sunucu zamanla farklılaşır; aynı ayarın hangi makinede yapıldığını kimse bilmez. Kodla tanımlanan konfigürasyon ise sürüm kontrolüne girer, gözden geçirilir ve istenen sayıda sunucuya aynı şekilde uygulanır.

Ansible bu iş için yaygın kullanılan bir otomasyon aracıdır. Hedef sunucularda ayrıca bir ajan kurulumu gerektirmez; genellikle SSH üzerinden bağlanır, YAML biçiminde yazılan playbook dosyalarındaki görevleri sırayla çalıştırır. Okunabilir söz dizimi ve düşük kurulum yükü, ekiplerin hızlı başlamasını sağlar.

Temel kavramlar: envanter, modül, playbook, rol

• Envanter (inventory): yönetilecek sunucuların listesi ve gruplarıdır. Web sunucuları, veritabanı sunucuları gibi gruplara ayrılabilir. Bulut ortamlarında sunucular sürekli değiştiği için envanter dinamik olarak bulut sağlayıcısından da üretilebilir.
• Modül: tek bir işi yapan küçük birim; paket kurmak, dosya kopyalamak, servisi yeniden başlatmak gibi.
• Playbook: hangi sunucu grubunda hangi görevlerin hangi sırayla çalışacağını anlatan YAML dosyası.
• Rol (role): ilişkili görevleri, değişkenleri, şablonları ve dosyaları klasör yapısı içinde paketleyen yeniden kullanılabilir birim.
• Değişken ve şablon: ortama göre değişen değerleri koddan ayırır.
• Handler: yalnızca bir değişiklik olduğunda tetiklenen görev; örneğin yapılandırma dosyası değiştiyse servisi yeniden başlatmak.

Ansible'ın temel ilkesi idempotenttir: aynı playbook tekrar çalıştırıldığında sistem zaten istenen durumdaysa değişiklik yapmaz. Bu özellik, otomasyonun güvenle tekrarlanabilmesini sağlar.

Adım adım: ilk konfigürasyon otomasyonu

• Hedefi netleştirin: sunucunun son hali neye benzemeli? Kurulu paketler, açık portlar, kullanıcılar, servisler ve yapılandırma dosyalarını listeleyin.
• Envanteri yazın ve sunuculara erişimi deneyin. Bağlantı sorunlarını daha playbook yazmadan ayıklayın.
• Önce tek görevli küçük bir playbook çalıştırın, çıktıyı okuyun.
• Görevleri mantıksal sırayla ekleyin ve her ekleme sonrası tekrar çalıştırarak idempotent davrandığını doğrulayın.
• Ortama göre değişenleri değişkene ve şablona taşıyın.
• Tekrar eden yapıları role dönüştürün.
• Parola ve anahtar gibi gizli bilgileri, Ansible'ın şifreli saklama özelliğiyle ya da bir gizli bilgi yöneticisiyle yönetin; düz metin olarak depoya koymayın.
• Playbook'u önce deneme moduyla çalıştırın, ardından gerçek sunuculara uygulayın.

Pratik bir doğrulama alışkanlığı: playbook'u iki kez art arda çalıştırın. İkinci çalıştırmada hiçbir görev değişiklik bildirmiyorsa playbook idempotent davranıyor demektir; bildiriyorsa hangi görevin her seferinde değişiklik yaptığını bulup düzeltin.

Örnek senaryo: web sunucusu hazırlama

Örneğin bir ekip, yeni bir uygulama için birden fazla web sunucusunu aynı şekilde hazırlamak istiyor. Envanterde bu sunucular web grubu altında toplanır. Playbook'un görevleri şöyle sıralanır: gerekli paketleri kur, uygulama kullanıcısını oluştur, yapılandırma dosyasını şablondan üret, güvenlik duvarı kurallarını aç, servisi başlat ve etkinleştir.

Yapılandırma şablonundaki sunucu adı ve ortam değerleri değişkenlerden gelir. Dosya değiştiğinde handler servisi yeniden başlatır; değişmediyse servise dokunulmaz. Sonradan aynı işi test ortamı için çalıştırmak, yalnızca değişken dosyasını değiştirmek demektir.

Bu yapı bir rol olarak paketlendiğinde başka projeler de aynı web sunucusu rolünü yeniden kullanabilir. Böylece bir güvenlik düzeltmesi tek yerde yapılır, tüm sunuculara playbook ile dağıtılır.

Büyüdükçe: AWX, CI/CD ve GitOps

Birkaç sunucudan ekip ölçeğine geçildiğinde komut satırından elle çalıştırma yetersiz kalır. Ansible'ın web arayüzlü ve yetkilendirmeli yönetim platformları (AWX ve Ansible Automation Platform), çalıştırmaları merkezi olarak zamanlar, kimin neyi ne zaman çalıştırdığını kaydeder ve erişimi rollere göre sınırlar.

Playbook ve rol kodu bir sürüm kontrol deposunda tutulduğunda, değişiklikler gözden geçirme sürecinden geçer ve CI/CD hattında otomatik sözdizimi denetimi ile test ortamında deneme yapılabilir. Konfigürasyonun deponun tek doğruluk kaynağı olduğu bu yaklaşım GitOps çizgisine yaklaşır: altyapıda yapılacak her değişiklik önce depoya girer.

Sık yapılan hatalar

• Her şeyi komut çalıştıran genel modüllerle yapmak. Özel modüller idempotenttir, genel komutlar her zaman aynı güvenceyi vermez.
• Tek devasa playbook yazmak. Roller ve parçalı dosyalar yerine kopyalanan görev blokları bakımı zorlaştırır.
• Gizli bilgileri düz metin olarak depoya koymak.
• Üretim sunucularına doğrudan, denemeden uygulamak. Önce deneme modu ve test ortamı kullanılmalıdır.
• Sunucuya elle müdahale etmeye devam etmek. Elle yapılan değişiklik, bir sonraki çalıştırmada ezilir ya da kodla gerçek durum arasında fark yaratır.
• Envanteri ve değişken önceliklerini düzensiz tutmak; hangi değerin hangi kaynaktan geldiğini kimse bilemez.

Başlangıçtan ileri düzeye yol ve Mindset programı

Başlangıçta Linux komut satırı, SSH ve YAML söz dizimini rahat kullanmak yeterlidir. Ardından envanter, modüller ve basit playbook yazımı gelir. Orta düzeyde roller, değişkenler, şablonlar, koşullar ve döngüler, dinamik envanter ve bulut entegrasyonu öğrenilir. İleri düzeyde özel modül yazımı, gelişmiş teknikler, AWX ya da Automation Platform işletimi ve CI/CD ile birlikte kullanım yer alır.

Mindset kataloğundaki Ansible ile Konfigürasyon Yönetimi eğitiminin modül başlıkları bu sırayı izler: Ansible Temelleri ve Mimarisi, Playbook Tasarımı, Rol Mimarisi ve Yeniden Kullanım, Dinamik Envanter ve Bulut Entegrasyonu, Gelişmiş Ansible Teknikleri, AWX ve Ansible Automation Platform, CI/CD ve GitOps ile Ansible.