Ansible Playbook Yazma: İlk Play'den Güvenli Çalıştırmaya

Playbook'un yapısı: play, görev, modül

Playbook, bir YAML dosyasıdır ve sıralı bir play listesi içerir. Her play'in bir hedefi (hosts) ve en az bir görevi vardır. Görevler yukarıdan aşağıya çalışır; her görev bir ad taşır ve tek bir modülü çağırır. Modül, paket kurmak, dosya kopyalamak ya da servisi başlatmak gibi tek bir işi yapan hazır birimdir.

En küçük anlamlı örnek:

--- - name: Web sunucularını güncelle hosts: web_sunucular become: true tasks: - name: Nginx paketi kurulu olsun ansible.builtin.package: name: nginx state: present

- name: Servis çalışsın ve açılışta başlasın ansible.builtin.service: name: nginx state: started enabled: true

Ansible'ın yeni sürümlerinde modüllerin tam nitelikli koleksiyon adlarıyla (ansible.builtin.package gibi) yazılması öneriliyor; böylece aynı ada sahip başka bir modülle karışma olmaz. Buradaki anahtar fikir bildirimselliktir: "kurulu olsun", "çalışsın" diye istenen durumu yazarsınız, Ansible bunu sağlamak için gerekeni yapar.

Envanter ve hedef seçimi

Playbook'taki hosts alanı, envanterdeki bir makine ya da grup adını gösterir. Envanter en basit biçimde bir INI ya da YAML dosyasıdır ve makineleri gruplar altında listeler.

[web_sunucular] webbir.ornek.com webiki.ornek.com

[veritabani] veritabani.ornek.com

Çalıştırma: ansible-playbook -i envanter.ini site.yml

Bağlantı varsayılan olarak SSH ile kurulur; hangi kullanıcıyla bağlanılacağını envanterde ya da remote_user ile verebilirsiniz. Yetki yükseltmek gerektiğinde become: true yazılır. İlk denemede tüm envanter yerine tek bir makineyi hedeflemek için --limit seçeneğini kullanın; hatalı bir playbook'u bütün filoya göndermeden önce küçük bir kapsamda görmek güvenlidir.

Değişkenler ve şablonlar

Aynı playbook'u farklı ortamlarda kullanmak için sabit değerler değişkene çıkarılır. vars bölümü, ayrı bir değişken dosyası ya da envanterdeki grup değişkenleri kullanılabilir. Değişken, çift süslü parantezle çağrılır.

- name: Uygulama ayar dosyası yazılsın hosts: web_sunucular vars: uygulama_adi: portal tasks: - name: Ayar dosyasını şablondan üret ansible.builtin.template: src: uygulama.conf.j2 dest: /etc/uygulama/uygulama.conf

şablon dosyasında (uygulama.conf.j2) {{ uygulama_adi }} gibi ifadeler Jinja2 ile doldurulur. Şablon, makineye özgü değerleri (alan adı, port, ortam adı) tek bir kaynaktan üretmenin standart yoludur. Değişken önceliği konusunda dikkatli olun: aynı değişken birden çok yerde tanımlıysa hangisinin kazandığı, hata ayıklamada en çok zaman alan konulardan biridir. Başlangıçta değişkenleri az yerde tanımlamak sorunu küçültür.

Handler, koşul ve döngü

Handler, yalnızca bir görev bir şeyi değiştirdiğinde çalışan özel görevdir. Klasik kullanım, yapılandırma dosyası değişince servisi yeniden başlatmaktır. Değişiklik yoksa servis dokunulmadan kalır.

tasks: - name: Ayar dosyasını güncelle ansible.builtin.template: src: uygulama.conf.j2 dest: /etc/uygulama/uygulama.conf notify: Servisi yeniden başlat

handlers: - name: Servisi yeniden başlat ansible.builtin.service: name: uygulama state: restarted

Koşul için when, tekrar için loop kullanılır. Örneğin yalnızca belirli bir işletim sistemi ailesinde bir görevi çalıştırmak ya da bir paket listesini tek görevle kurmak mümkündür. Döngü ve koşul, görevleri kopyalayıp yapıştırmak yerine kısa ve okunur bir playbook tutmanın yoludur.

Birden çok değeri tek görevle işlemek için loop kullanılır:

- name: Gerekli paketler kurulu olsun ansible.builtin.package: name: "{{ item }}" state: present loop: - git - curl - unzip when: ansible_facts['os_family'] == "Debian"

Burada ansible_facts, Ansible'ın makineden topladığı bilgileri taşır; koşul yalnızca ilgili işletim sistemi ailesinde görevi çalıştırır. Aynı playbook'u farklı dağıtımlarda kullanacaksanız bu tür koşullar ya da dağıtıma özgü değişken dosyaları gerekir. Çok sayıda koşul biriktiğinde bunları bir role taşıyıp dağıtım başına ayrı görev dosyaları kullanmak okunabilirliği korur.

Çalıştırmadan önce denetle: check, diff, syntax-check

ansible-playbook komutu, değişiklik yapmadan doğrulamak için seçenekler sunar: • --syntax-check: YAML ve yapı hatalarını bulur • --list-hosts ve --list-tasks: hangi makinelerde hangi görevlerin koşacağını gösterir • --check (-C): playbook'u çalıştırır ama sistemi değiştirmez, yapılacak değişiklikleri raporlar • --diff: dosya değişikliklerinin farkını gösterir • --verbose: ayrıntılı çıktı verir

Önerilen akış: önce syntax-check, sonra bir makinede check ile diff, en sonunda gerçek çalıştırma. Check modunda bazı modüller koşullu sonuçlar üretemeyebilir; bu yüzden check çıktısı gerçek çalıştırmanın birebir yansıması değil, güçlü bir ön izlemedir. Playbook'u sürüm kontrolünde tutup değişiklikleri inceleme sürecinden geçirmek, otomasyonun kendisini de denetlenebilir kılar.

Sık yapılan hatalar ve iyi alışkanlıklar

• Görevlere ad vermemek; çıktı okunamaz hale gelir
• Komut çalıştıran modülleri (command, shell) paket, dosya ya da servis modülleri yerine kullanmak; yineleme güvenliği kaybolur
• Girintiyi karıştırmak; YAML'da boşluk anlamlıdır, sekme kullanılmaz
• Parolaları playbook'a düz metin yazmak; Ansible Vault ya da gizli bilgi yöneticisi kullanılmalı
• Tek dev bir playbook yazmak; büyüyen içerik roller halinde bölünmeli

İdempotentlik, yani aynı playbook'un tekrar çalıştırmada hiçbir şeyi değiştirmemesi, kaliteli bir playbook'un temel ölçütüdür. Tekrar çalıştırmada "changed" görüyorsanız genellikle bir görev gerçek durumu denetlemiyordur. Playbook büyüdüğünde rol mimarisine geçmek doğal sonraki adımdır.

Bu beceriyi Mindset programında nerede çalışırsınız

Ansible ile Konfigürasyon Yönetimi eğitimi, sunucu ve altyapı ekiplerinde playbook yazan sistem yöneticileri, DevOps mühendisleri ve operasyon ekipleri için uygundur. Müfredat Ansible Temelleri ve Mimarisi ile Playbook Tasarımı modüllerinden başlayıp Rol Mimarisi ve Yeniden Kullanım, Dinamik Envanter ve Bulut Entegrasyonu, AWX ve CI/CD tarafına uzanır.

Kurumsal bir ekip için bu hat, elle yürütülen sunucu kurulumlarının sürüm kontrollü ve tekrarlanabilir bir playbook'a taşınmasını amaçlar.