Ansible ile Sunucuların Günlük Yönetimi: Komut, Yama ve Kullanıcı İşleri

Bu sayfa neyi anlatır: yapılandırma yazmak değil, filoyu işletmek

Ansible iki farklı işte kullanılır. Birincisi sunucunun olması gereken durumunu playbook ve rollerle kod olarak yazmaktır; bu konu yapılandırma yönetimi sayfasında anlatılır. İkincisi, kurulmuş bir sunucu filosunu her gün işletmektir: bir servisi on sunucuda aynı anda yeniden başlatmak, güvenlik yamasını kesinti yaratmadan geçirmek, ayrılan bir çalışanın hesabını tüm makinelerden kaldırmak, hangi sunucuda hangi işletim sistemi sürümünün çalıştığını tek komutla görmek.

Bu sayfa ikinci işe odaklanır. Sistem yöneticisinin sorduğu sorular burada farklıdır: hedefi nasıl daraltırım, aynı anda kaç sunucuya dokunurum, bir şey ters giderse işlemi nasıl durdururum, değişikliği uygulamadan önce nasıl görürüm. Aşağıdaki komutların tamamı Ansible'ın resmî belgelerindeki sözdizimine dayanır; örneklerdeki grup ve kullanıcı adları temsilidir.

Envanteri sorgulamak ve hedefi daraltmak

Filoda iş yapmadan önce Ansible'ın sunucuları nasıl gördüğünü kontrol edin. ansible-inventory --graph komutu grupları ve içindeki sunucuları ağaç olarak gösterir; --vars eklenirse grup değişkenleri de listelenir. Dinamik envanter kullanıyorsanız bulut sağlayıcısından gelen listenin beklediğiniz gibi olup olmadığını bu komutla görürsünüz.

Hedef seçiminde desenler kullanılır: • webservers:dbservers iki grubun birleşimidir. • webservers:!atlanta web sunucularından atlanta grubundakileri hariç tutar. • webservers:&staging yalnız hem web hem staging grubunda olanları seçer.

Playbook'u bütün gruba değil daha dar bir kümeye uygulamak için --limit kullanılır: ansible-playbook yama.yml --limit 'webservers:!atlanta'. Ünlem işaretli desenlerde tek tırnak kullanın, aksi halde kabuk ifadeyi kendisi yorumlamaya çalışır. Başarısız sunucular bir yeniden deneme dosyasına yazdırılmışsa --limit @dosya.retry biçimiyle yalnız onlar tekrar çalıştırılabilir.

Anlık komutlarla hızlı işler

Tek seferlik işler için playbook yazmak gerekmez; ansible komutu bir modülü doğrudan çalıştırır. Günlük işletimde en sık kullanılanlar: • ansible webservers -m ansible.builtin.ping: bağlantı ve Python ortamı çalışıyor mu. • ansible all -m ansible.builtin.setup: sunuculardan işletim sistemi, bellek, ağ gibi sistem bilgilerini toplar; filter parametresiyle yalnız ilgilendiğiniz alan istenebilir. • ansible webservers -m ansible.builtin.service -a "name=httpd state=restarted" --become: servisi yönetici yetkisiyle yeniden başlatır. • ansible webservers -m ansible.builtin.copy -a "src=/etc/hosts dest=/tmp/hosts": dosyayı tüm gruba kopyalar.

Aynı anda kaç sunucuya bağlanılacağını -f (forks) seçeneği belirler. Büyük bir grupta servisi yeniden başlatırken bu değeri düşük tutmak, bütün sunucuların aynı anda hizmet dışı kalmasını önler. Anlık komutun geçmişi tutulmaz; aynı komutu ikinci kez yazıyorsanız onu küçük bir playbook'a dönüştürme zamanı gelmiştir.

Yama ve yeniden başlatmayı kademeli yürütmek

Güvenlik yamaları filonun tamamına aynı anda uygulanırsa hata bütün hizmeti durdurur. Ansible'da bunun karşılığı serial anahtar sözcüğüdür: play'deki tüm görevler önce birinci küçük grupta tamamlanır, ancak sonra sıradaki gruba geçilir. serial değerine sabit bir sayı, yüzde ya da giderek büyüyen bir liste verilebilir; böylece ilk turda tek sunucuda deneyip sonra grubu büyütebilirsiniz.

Tipik bir yama playbook'unun iskeleti şöyledir: sunucuyu yük dengeleyiciden çıkar, paketleri güncelle, ansible.builtin.reboot modülüyle yeniden başlat, servisin yanıt verdiğini kontrol et, sunucuyu yük dengeleyiciye geri al. reboot modülü makinenin kapanmasını, yeniden açılmasını ve komutlara yanıt vermesini bekler; bu yüzden ayrı bir bekleme görevine gerek kalmaz. Çok güncelleme alan makinelerde zaman aşımı süresini artırmak gerekebilir.

Destekleyici anahtar sözcükler: • max_fail_percentage: bir gruptaki hata oranı eşiği aşarsa çalıştırmayı durdurur; serial ile kullanıldığında oran grup boyutuna göre hesaplanır. • run_once: veritabanı şeması güncellemesi gibi işi her grupta yalnız bir sunucuda çalıştırır. • throttle: tek bir görevin eş zamanlı çalışma sayısını forks ve serial değerinin altına indirir. • order: sunucuların işlenme sırasını belirler; sorted, reverse_sorted ve shuffle gibi değerler alır.

Değişiklikten önce görmek: check, diff ve limit

Üretim sunucusunda bir değişikliği uygulamadan önce ne olacağını görmek mümkündür. ansible-playbook site.yml --check playbook'u simülasyon olarak çalıştırır ve uzak sistemde değişiklik yapmaz. --diff eklenirse desteklenen modüller dosyanın önceki ve sonraki halini gösterir. Diff çıktısı uzun olabileceği için resmî belge bunu tek sunucuyla sınırlamayı önerir: ansible-playbook site.yml --check --diff --limit web-a.example.com.

Check modunun sınırlarını bilin. Bu modu desteklemeyen modüller hiçbir şey raporlamaz ve hiçbir şey yapmaz; önceki bir görevin kayıtlı sonucuna bağlı koşullu görevler de doğru tahmin edilemez. Görev düzeyinde check_mode: true yazılan görev her zaman simülasyonda kalır; when: not ansible_check_mode koşulu ise bir görevi yalnız gerçek çalıştırmada devreye sokar.

Parola ya da anahtar içeren şablonlarda diff çıktısı gizli bilgiyi ekrana dökebilir. Bu görevlere diff: false yazmak o görevin karşılaştırma çıktısını kapatır.

Kullanıcı, SSH anahtarı ve erişim yönetimi

Erişim işleri filo yönetiminin en hassas kısmıdır ve elle yapıldığında unutulan bir sunucu güvenlik açığına dönüşür. Ayrılan bir çalışanın hesabını tüm sunuculardan kaldırmak tek komuttur: ansible all -m ansible.builtin.user -a "name=ornekkullanici state=absent" --become. Ancak kalıcı düzen için kullanıcı listesini bir değişken dosyasında tutup playbook ile uygulamak daha güvenlidir; hesabın kimin onayıyla açıldığı sürüm geçmişinde kalır.

SSH genel anahtarlarını dağıtmak için ansible.posix.authorized_key modülü kullanılır. Bu modül ansible-core içinde gelmez; ansible.posix koleksiyonunun kurulu olması gerekir. exclusive seçeneği listede olmayan diğer anahtarları siler; döngü içinde kullanıldığında her turda ayrı uygulandığı için beklenmedik silmelere yol açabilir, bu yüzden anahtar listesini tek seferde verin.

Parola özeti ya da API anahtarı taşıyan görevlerde no_log: true kullanın; böylece değer çalışma çıktısına ve günlüklere yazılmaz. Gizli değişkenler depoda Ansible Vault ile şifreli tutulur.

Ölçek büyüdüğünde ve Mindset programları

Filo yönetimini birden fazla kişi yapmaya başladığında komut satırından çalıştırmanın sınırları görünür: kimin hangi komutu ne zaman çalıştırdığı kaydedilmez, kimlik bilgileri kişisel bilgisayarlarda dağınık kalır. Bu noktada AWX ya da Ansible Automation Platform, yama playbook'unu iş şablonu olarak tanımlayıp zamanlamaya, onay adımı eklemeye ve çalıştırma geçmişini saklamaya imkân verir.

Mindset kataloğunda bu iki ihtiyaca karşılık gelen iki program var. Ansible ile Konfigürasyon Yönetimi, playbook ve rol yazımından dinamik envantere kadar Ansible'ın kendisini öğretir. Ansible Automation Platform (AWX) ile Kurumsal Otomasyon ise bu sayfadaki işletim konularının kurumsal karşılığına, yani kimlik bilgisi yönetimine, iş şablonlarına, zamanlamaya ve denetim kayıtlarına odaklanır.