Ansible Rolleri: Klasör Yapısı, Yazım ve Yeniden Kullanım

Rol neyi çözer, ne zaman gerekir?

Bir playbook büyüdükçe aynı paket kurulumu, aynı yapılandırma dosyası ve aynı servis ayarı birden fazla yerde kopyalanmaya başlar. Rol, bu tekrarlanan parçayı tek bir adlandırılmış pakete alır: görevler, değişkenler, şablonlar, dosyalar ve handler'lar belirli bir klasör düzeninde toplanır. Ana playbook ise yalnızca "bu gruba şu rolü uygula" diyen ince bir dosyaya iner.

Sorulacak soru şudur: bu iş başka bir ekipte, başka bir projede ya da başka bir ortamda tekrar kullanılacak mı? Evetse rol yazın. Tek seferlik bir iş için rol yazmak gereksiz yapıdır. İyi bir rol tek bir sorumluluk taşır: "web sunucusu kur", "izleme ajanı yapılandır", "veritabanı kullanıcıları oluştur" gibi.

Rolün klasör yapısı

Ansible belgelerine göre bir rolde, kullanmadıklarınızı atlayabileceğiniz ama en az birinin bulunması gereken şu dizinler vardır: • tasks/main.yml: rolün sunduğu görev listesi • handlers/main.yml: ebeveyn play'e aktarılan handler'lar • defaults/main.yml: çok düşük öncelikli varsayılan değişkenler; başka her kaynak bunları ezer • vars/main.yml: rolün sağladığı yüksek öncelikli değişkenler • files/: copy ya da script gibi modüllerle kullanılan dosyalar • templates/: template modülünün şablonları (.j2 uzantılı) • meta/main.yml: rol üst verisi ve bağımlılıklar

İskeleti elle kurmak yerine ansible-galaxy init rol_adi komutu gerekli yapıyı hazır üretir. Dizinlerdeki main.yml dışındaki dosyalar varsayılan olarak yüklenmez; include_role ile tasks_from kullanarak başka bir görev dosyasını açıkça çağırabilirsiniz. Böylece "kurulum" ve "yedekleme" gibi görev dosyalarını aynı rolün içinde ayırabilirsiniz.

Örnek: küçük bir nginx rolü

Rolün adı nginx_kurulum olsun. Görevler tasks/main.yml içinde yaşar:

--- - name: Nginx kurulu olsun ansible.builtin.package: name: nginx state: present

- name: Site ayarı yazılsın ansible.builtin.template: src: site.conf.j2 dest: "{{ nginx_ayar_yolu }}" notify: Nginx yeniden başlasın

- name: Servis çalışsın ansible.builtin.service: name: nginx state: started enabled: true

handlers/main.yml: --- - name: Nginx yeniden başlasın ansible.builtin.service: name: nginx state: restarted

defaults/main.yml: --- nginx_ayar_yolu: /etc/nginx/conf.d/site.conf

Playbook tarafı ise yalnızca:

- hosts: web_sunucular become: true roles: - nginx_kurulum

Değişken adlarının başına rol adını koymak (nginx_ayar_yolu gibi), farklı roller arasında ad çakışmasını önler; tüm roller değişkenleri aynı kapsamda paylaştığı için bu bir alışkanlık olarak önemlidir.

defaults ile vars: hangisine ne konur?

defaults, rolün kullanıcıdan beklediği ayarların güvenli başlangıç değerleridir; çok düşük öncelikli olduğundan envanterden ya da playbook'tan kolayca ezilebilir. Rolü kullanan kişinin değiştirmesini beklediğiniz her şey buraya gider: port, kurulum yolu, açılıp kapanan özellik bayrakları.

vars ise rolün kendi iç sabitleridir ve yüksek önceliklidir; kullanıcının kazara değiştirmemesi gereken değerler, örneğin işletim sistemine göre değişen paket adları burada tutulur. Kural basit: kullanıcı değiştirsin istiyorsanız defaults, değiştirmesin istiyorsanız vars. Karar vermekte zorlanıyorsanız defaults tercih edin; esnek olmak, kilitli olmaktan daha az sürpriz üretir.

Bir rolün giriş değişkenlerini rolün başındaki bir yorumda ya da README'de listelemek, onu başkasının kullanmasını belirgin biçimde kolaylaştırır.

Rolün meta/main.yml dosyasında rolün adı, açıklaması, desteklediği platformlar ve bağımlılıkları tutulur:

galaxy_info: author: platform-ekibi description: Web sunucusu kurulum rolü license: MIT dependencies: - role: ortak_hazirlik

Burada ortak_hazirlik rolü, rol çağrıldığında ondan önce çalışır. Bağımlılık kullanırken şu ilkeler geçerlidir: bağımlılığı olabildiğince az tutun ve bağımlı rolün hangi değişkenleri beklediğini belgeleyin. Aksi hâlde rolü kullanan kişi, çağırmadığı bir rolün neden çalıştığını anlamakta zorlanır.

Rolü çağırma: roles, import_role, include_role

Rolü çağırmanın birkaç yolu vardır ve farkları etiket davranışı ile çalışma zamanında yatar: • roles anahtarı (play düzeyi): klasik yöntemdir; roller, play'in görevlerinden önce, listelendiği sırayla statik olarak içe aktarılır. Her rolün bağımlılıkları önce çalışır. • import_role: statik içe aktarmadır, tasks bölümünde durur. Etiketler rolün tüm görevlerine uygulanır. • include_role: dinamiktir, görevler arasında bulunduğu noktada çalışır. Etiket yalnızca include görevine uygulanır; rol içindeki görevleri etiketle seçmek için onlara da aynı etiket verilmelidir.

Aynı rol bir play içinde farklı parametrelerle birden çok kez çalıştırılabilir; aynı parametrelerle tekrar için rolün meta/main.yml dosyasında allow_duplicates: true gerekir. Koşula bağlı ya da döngüyle rol çağırmak istiyorsanız include_role uygundur; sabit bir sıra yeterliyse roles ya da import_role daha öngörülebilirdir.

Paylaşım, test ve sık hatalar

Rolleri ekip içinde ortak bir depoda tutup requirements dosyasıyla projelere çekebilir, Ansible Galaxy üzerinden paylaşabilir ya da bir koleksiyonun parçası haline getirebilirsiniz. Koleksiyon içindeki roller eklenti gömmeyi desteklemez; eklentiler koleksiyonun plugins yapısında bulunmalıdır. Galaxy'e yüklemek için meta/main.yml dosyası şarttır.

Sık hatalar: • Tek rolde çok fazla sorumluluk toplamak • Değişken adlarına rol öneki koymamak • Her şeyi vars'a yazıp rolü esnemez hale getirmek • Rolü, çalıştığı ortamı (işletim sistemi ailesi) belgelemeden yayınlamak • Rolü hiç sınamadan başka ekibe vermek

Rolü sınamak için sahte bir makine ya da kapsayıcıda üst üste çalıştırın: ilk çalıştırma kurulumu yapar, sonraki hiçbir değişiklik göstermemeli. Sonraki çalıştırmada değişiklik görüyorsanız rol idempotent değildir.

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

Ansible ile Konfigürasyon Yönetimi eğitiminin Rol Mimarisi ve Yeniden Kullanım modülü bu konuyu doğrudan işler. Eğitim, birden fazla ekibin aynı altyapı kodunu paylaştığı kurumlarda sistem yöneticileri, DevOps mühendisleri ve platform ekipleri için uygundur.

Kurumsal bir ekipte rol kitaplığı kurmak, her projede aynı kurulum adımlarını yeniden yazmak yerine denetlenmiş ortak parçaları kullanmayı sağlar. Gelişmiş Ansible Teknikleri ve CI/CD ile GitOps modülleri, bu rolleri bir teslimat hattına bağlamak isteyenler için devam yoludur.