Agentless Otomasyon: Ansible’ın Çalışma Mantığı

Ansible çoğu zaman "konfigürasyon yönetim aracı" olarak tanımlanır ve genellikle bu seviyede bırakılır. Playbook yazılır, komut çalışır ve işler otomatik hale gelir. Ancak bu yaklaşım Ansible'ın gerçekten neler yapabildiğini anlamak için yeterli değildir.

Bir komut verdiğimizde Ansible arka planda ne yapar? Hedef makineye nasıl bağlanır, neyi nereye kopyalar ve nasıl çalıştırır? Neden agent gerekmez ve bu gerçekten ne anlama gelir?

Bu yazıda Ansible'ı kullanmayı değil, nasıl çalıştığını anlamayı hedefliyoruz. SSH bağlantısından modül execution sürecine kadar olan akışı adım adım inceleyerek sistemin arkasındaki mekanizmayı net bir şekilde ortaya koyacağız.

Nedir bu Ansible?

Kısa haliyle Ansible'ı Red Hat tarafından desteklenen, agent gerektirmeyen (agentless), açık kaynak kodlu bir otomasyon aracı olarak tanımlayabiliriz. SSH ve Python kullanarak sunuculara bağlanır ve sistem yönetimini otomatize eder.

Kullanım alanları

• Konfigürasyon yönetimi
• Paket yükleme ve güncelleme
• Servis yönetimi
• Kullanıcı ve yetki yönetimi
• Çok sunuculu senkronizasyon ve patch uygulamaları

Avantajları

• Agent gerekmez, sadece SSH ve Python yeterlidir.
• Basit YAML yapısı (Ansible Playbook)
• Platform bağımsız (Linux, macOS, bazı Windows işlemleri)
• Modüller sayesinde görev bazlı çalışma

Ansible'ın Mimarisi

Ansible'ın mimarisini iki katmanda ele almak gerekir: açık kaynak Ansible'ın kendi bileşenleri ve Red Hat'in kurumsal ürünü olan Ansible Automation Platform'un (AAP) getirdiği ek bileşenler. Standalone Ansible küçük ve orta ölçekli ortamlar için yeterliyken, AAP büyük ölçekli ve kurumsal ihtiyaçlar için bu yapının üzerine ek katmanlar ekler.

Standalone Ansible Bileşenleri

• Control Node:

  • Ansible'ın yüklü olduğu merkez makinedir.
  • Playbook'lar burada yazılır ve yürütülür.
  • CLI (ansible, ansible-playbook, ansible-inventory) buradan çalıştırılır.
  • Bir ortamda birden fazla Control Node olabilir ancak bunlar birbirinden bağımsız çalışır, aralarında otomatik bir koordinasyon yoktur.

• Managed Node:

  • Ansible'ın kontrol ettiği hedef sistemlerdir.
  • SSH (veya başka bağlantı yöntemi) ile erişim sağlanır.
  • Agent gerekmez, sadece Python (veya raw modüller için bash) yeterlidir.

• Hop Nodes (Proxy Jump / Bastion Hosts):

  • Hedef sistemlere doğrudan erişilemeyen durumlarda devreye girer.
  • Control Node -> Hop Node -> Managed Node şeklinde bir geçiş sağlar.
  • Güvenlik politikaları gereği izole edilmiş ağ segmentlerine erişmek için kullanılır.
  • ansible_ssh_common_args ile yapılandırılır: ansible_ssh_common_args='-o ProxyCommand="ssh -W %h:%p bastion_user@bastion_host"'

• Inventory Source:

  • Ansible'ın sunucu hedeflerini belirlediği listedir.
  • Statik (INI/YAML dosyaları) veya dinamik (API, CMDB, script) olabilir.
  • Dinamik inventory ile bulut ortamlarında (AWS, Azure, GCP) anlık sunucu listesi çekilebilir.

• Galaxy CLI / Ansible Galaxy:

  • Collection ve role'lerin paylaşıldığı, indirildiği paket deposudur.
  • Topluluk tarafından geliştirilen içeriklere erişim sağlar.
  • CLI ile kullanımı: ansible-galaxy collection install community.mysql

• Content Collections:

  • Ansible 2.9'dan itibaren modüller, roller ve plugin'ler koleksiyonlara ayrılmıştır.
  • Her collection belirli bir alan veya platforma odaklanır. Örn: community.docker, ansible.posix, redhat.rhel_system_roles.
  • Galaxy veya özel bir hub üzerinden dağıtılır.
  • Versiyonlama desteği sayesinde farklı ortamlarda farklı collection sürümleri kullanılabilir.

Ansible Automation Platform (AAP) Bileşenleri

AAP, standalone Ansible'ın üzerine inşa edilmiş kurumsal bir üründür. Sadece otomasyon yapmakla kalmaz, bu otomasyonu yönetilebilir, denetlenebilir ve ölçeklenebilir hale getirir. Aşağıdaki bileşenler AAP lisansı kapsamında gelir ve standalone Ansible kurulumlarında yer almaz.

AAP'nin kurumsal lisansı olmayan ortamlar için AWX iyi bir alternatiftir. AWX, AAP'nin upstream açık kaynak projesidir ve Automation Controller doğrudan AWX üzerine inşa edilmiştir. Web arayüzü, RBAC, job scheduling ve credential yönetimi gibi temel özellikler AWX'te de bulunur. Farkı şudur: AWX topluluk tarafından geliştirilir, Red Hat desteği ve SLA'i yoktur. Ayrıca sertifikalı içerik dağıtımı, Execution Node yönetimi ve EDA gibi ileri düzey özellikler yalnızca AAP'de yer alır. Küçük ve orta ölçekli ortamlarda ya da lisans maliyetinin kısıtlayıcı olduğu durumlarda AWX, AAP'nin işlevselliğinin büyük bölümünü ücretsiz olarak sunar.

• Automation Controller:

  • AAP'nin merkezi yönetim bileşenidir. Eski adıyla Ansible Tower olarak bilinir.
  • Playbook'ların çalıştırılması, zamanlanması ve izlenmesi web arayüzü üzerinden yapılır.
  • RBAC (Role-Based Access Control) ile hangi kullanıcının hangi playbook'u çalıştırabileceği belirlenir.
  • Her çalıştırmanın detaylı logları tutulur. Kim ne zaman hangi playbook'u çalıştırdı, çıktılar neydi gibi bilgiler audit amacıyla saklanır.
  • REST API desteği sayesinde CI/CD pipeline'larına entegre edilebilir.
  • Credential yönetimi merkezi olarak yapılır. SSH key, vault şifresi, bulut API anahtarları gibi hassas bilgiler şifreli biçimde saklanır ve kullanıcılarla doğrudan paylaşılmaz.

• Execution Node:

  • Playbook'ların fiilen çalıştırıldığı node'lardır. Automation Controller bu node'lara iş dağıtır.
  • Control plane (Automation Controller) ile data plane (Execution Node) birbirinden ayrılır. Bu sayede Controller üzerindeki yük azalır.
  • Farklı ağ segmentlerine veya coğrafi bölgelere yerleştirilerek managed node'lara daha yakın çalışabilirler.
  • 1000+ sunuculuk ortamlarda performans ve ölçeklenebilirlik için kritik öneme sahiptir.

• Automation Hub:

  • Kurumun kendi içinde Content Collection dağıtımını merkezi olarak yönettiği depodur.
  • Ansible Galaxy'nin kurumsal ve özel alternatifi olarak düşünülebilir.
  • Onaylı ve test edilmiş collection'ların dağıtılmasını sağlar. Böylece güvenilmeyen topluluk içeriklerinin doğrudan production ortamına girmesinin önüne geçilir.
  • Red Hat tarafından sertifikalandırılmış collection'lar burada barındırılır.

• EDA Controller (Event-Driven Automation):

  • Belirli olaylara göre otomasyon tetiklemeye yarar.
  • Bir Zabbix alarmı geldiğinde, bir log satırında belirli bir pattern eşleştiğinde veya bir webhook tetiklendiğinde otomatik olarak playbook çalıştırabilir.
  • Rulebook adı verilen YAML tabanlı kurallarla hangi olayın hangi aksiyonu tetikleyeceği tanımlanır.
  • Reaktif otomasyon senaryolarında (self-healing infrastructure gibi) özellikle değerlidir.

↗ github.com

GitHub - ansible/awx: AWX provides a web-based user interface, REST API, and task engine built on top of Ansible. It is one of the upstream projects for Red Hat Ansible Automation Platform.

AWX provides a web-based user interface, REST API, and task engine built on top of Ansible. It is one of the upstream projects for Red Hat Ansible Automation Platform. - ansible/awx

Nasıl Kurulur?

Ubuntu/Debian

sudo apt update && sudo apt install ansible -y

RHEL/CentOS

sudo dnf install epel-release -y && sudo dnf install ansible -y

macOS

brew install ansible

Doğrulama

ansible --version

SSH Anahtar Çiftleri ve Bağlantı

SSH Key Generation

ssh-keygen -t rsa -b 4096 -C "svcansible"

• -t rsa: Anahtar türünü belirtir. RSA yaygın kullanılan ve geniş platform desteğine sahip bir asimetrik şifreleme algoritmasıdır. Alternatif olarak daha modern ve performanslı olan ed25519 de tercih edilebilir: ssh-keygen -t ed25519 -C "svcansible"
• -b 4096: Anahtar uzunluğunu bit cinsinden belirtir. RSA için 2048 minimum kabul edilebilir seviye olsa da 4096 bit brute-force saldırılarına karşı daha güçlü bir koruma sağlar. ed25519 kullanılıyorsa bu parametre gerekli değildir. Algoritma sabit ve yeterli uzunlukta anahtar üretir.
• -C "svcansible": Anahtara yorum (comment) ekler. Genellikle anahtarın hangi kullanıcıya veya servise ait olduğunu belirtmek için kullanılır. svcansible, Ansible otomasyonu için ayrılmış servis kullanıcısını ifade eder. Bu yorum authorized_keys dosyasında anahtarın sonunda görünür ve yönetim kolaylığı sağlar.

Varsayılan yol: RSA için ~/.ssh/id_rsa, ed25519 için ~/.ssh/id_ed25519

Neden SSH Key?

• Parolalı oturumlarda otomasyon zorlaşır. İnsan etkileşimi gerekir.
• SSH anahtarları ile parolasız, güvenli ve otomatik bağlantı sağlanır.
• Güvenlik açısından parola yerine public key authentication tercih edilir.
• SSH Key'ler her ortamda çalışır ve script ile kolayca dağıtılabilir.

SSH Key vs Kerberos

• Kerberos centralized (merkezi) kimlik doğrulama sağlar.
• Kerberos ticket'lar süreye bağlıdır (genelde 10-24 saat).
• Keytab dosyası saklamak gerekir ve bu dosya kritik yetkiler taşır.
• Ticket sürekli yenilenmelidir. Aksi takdirde authentication hataları oluşur.
• Ansible gibi agentless yapılar için bu durum otomasyonu kırabilir.

Bu nedenle: SSH key ile authentication, Ansible için daha sade, stabil ve risksizdir.

SSH Key Kopyalama

ssh-copy-id user@managed-node

Public key'i hedef sunucunun ~/.ssh/authorized_keys dosyasına otomatik olarak ekler. ssh-copy-id kurulu değilse aynı işlem manuel olarak da yapılabilir:

cat ~/.ssh/id_rsa.pub | ssh user@host "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

Ansible'ı Nasıl Konfigüre Ederiz?

Örnek Konfigürasyon

[defaults]
inventory = ./hosts
remote_user = svcansible
host_key_checking = False
retry_files_enabled = False
private_key_file = ~/.ssh/id_rsa

• inventory: Hedef makinelerin tanımlandığı dosya yolu
• remote_user: SSH bağlantılarında kullanılacak kullanıcı adı
• host_key_checking: SSH'ın bilinen sunucu anahtarlarını doğrulama mekanizmasıdır. Bir sunucuya ilk kez bağlanıldığında SSH, sunucunun kimliğini doğrulamak için parmak izini (fingerprint) ~/.ssh/known_hosts dosyasına kaydeder. Sonraki bağlantılarda bu parmak izi karşılaştırılır, eşleşmezse bağlantı reddedilir. False yapıldığında bu doğrulama devre dışı kalır ve Ansible yeni sunuculara otomatik olarak bağlanabilir. Production ortamlarında True bırakılması önerilir. Aksi halde man-in-the-middle saldırılarına karşı savunmasız kalınabilir.
• retry_files_enabled = False: Ansible'ın başarısız playbook çalıştırmaları sonrası .retry uzantılı dosyalar oluşturmasını engelleme
• private_key_file: Default olarak Ansible'ın private keyler için baktığı path (private key farklı bir dizindeyse değiştirilebilir)

Inventory (Envanter) Dosyası

INI Formatı

[webservers] 
web1 ansible_host=192.168.1.101 
web2 ansible_host=192.168.1.102  
[dbservers] 
db1 ansible_host=192.168.1.201

Eğer sunucuların DNS kaydı varsa:

[webservers] 
web1
web2
[dbservers] 
db1

YAML Formatı

all:
  children:
    webservers:
      hosts:
        web1:
          ansible_host: 192.168.1.101
        web2:
          ansible_host: 192.168.1.102
    dbservers:
      hosts:
        db1:
          ansible_host: 192.168.1.201

Eğer sunucuların DNS kaydı varsa:

all:
  children:
    webservers:
      hosts:
        web1:
        web2:
    dbservers:
      hosts:
        db1:

Demo: İlk Bağlantı Testi

ansible -i hosts all -m ping

• -i hosts: Kullanılacak inventory dosyasını belirtir. Bu örnekte hosts adlı dosya inventory olarak kullanılıyor.
• all: Inventory'deki tüm sunuculara bu komutu uygula anlamına gelir. Belirli bir gruba uygulamak için all yerine grup adı yazılabilir: ansible -i hosts webservers -m ping
• -m ping: Çalıştırılacak modülü belirtir. Buradaki ping, Linux'un ICMP ping komutuyla karıştırılmamalıdır. Ansible'ın ping modülü ağ erişilebilirliğini değil, SSH bağlantısının kurulabildiğini ve managed node'da Python'ın çalıştığını doğrular.

Bu komutun çalışması için hosts dosyasının komutun çalıştırıldığı dizinde olması gerekir. Alternatif olarak:

• Absolute path: -i /full/path/to/hosts
• Relative path: -i ../env/hosts

Eğer ansible.cfg içinde şu şekilde tanımlıysa:

[defaults]
inventory = ./hosts

o zaman sadece şu komut yeterlidir:

ansible all -m ping

Ancak yine de ./hosts dosyasının ansible.cfg ile aynı dizinde olması ya da doğru path verilmiş olması gerekir.

./hosts dosyamızda web1 ve web2 sunucularımızın bulunduğunu varsayalım. Beklenen çıktı:

web1 | SUCCESS => { "changed": false, "ping": "pong" }
web2 | SUCCESS => { "changed": false, "ping": "pong" }

SUCCESS bağlantının başarılı olduğunu, changed: false ise ping modülünün sistemde herhangi bir değişiklik yapmadığını gösterir. Bağlantı başarısız olsaydı UNREACHABLE veya FAILED çıktısı alınırdı.

Ansible Arka Planda Nasıl Çalışır?

Ansible, agent gerektirmeyen yapısı sayesinde hedef sistemlere SSH üzerinden bağlanır. Bu bağlantı süreci geçici işlemlerle gerçekleştirilir ve hedef sistemde kalıcı bir yazılım kurulumu gerekmez. Hedef makinelerde yalnızca SSH erişimi ve Python bulunması yeterlidir.

Bağlantının Kurulması

Ansible, kontrol makinesinden hedef makinaya OpenSSH kullanarak bağlanır. Bu bağlantıda kullanıcı adı, IP, port ve anahtar gibi detaylar şu inventory değişkenleriyle özelleştirilebilir:

• ansible_user: Bağlantı yapılacak kullanıcı
• ansible_host: Hedef sunucunun IP adresi ya da DNS adı
• ansible_port: SSH portu (varsayılan 22)
• ansible_ssh_private_key_file: Kullanılacak özel anahtar yolu

[webservers]
web1 ansible_host=192.168.1.101 ansible_user=svcansible ansible_port=22 ansible_ssh_private_key_file=~/.ssh/id_rsa ansible_connection=ssh

Bağlantı türü ansible_connection ile belirlenir. Varsayılanı ssh'dir. Alternatif türler:

• paramiko: Python tabanlı SSH istemcisi. OpenSSH kurulu olmayan ortamlarda ya da bağlantı davranışı üzerinde daha fazla kontrol gerektiğinde tercih edilir.
• local: Hedef ve kontrol makinesi aynıysa kullanılır. SSH bağlantısı kurulmaz, komutlar doğrudan yerel makinede çalıştırılır.
• docker, kubectl, chroot: Konteyner ve özel ortamlar için kullanılır.

Yukarıdaki inventory tanımına göre Ansible arka planda şu komutu çalıştırır:

ssh -i ~/.ssh/id_rsa [email protected] -p 22

Modül ve Parametrelerin Transferi

Ansible, kullanılacak modülün Python kodunu ve bu modüle ait parametreleri hedef sisteme gönderir. Bu işlem şu şekilde gerçekleşir:

• Modülün Python script'i /tmp/ansible-XXXXXX/ dizinine kopyalanır.
• Eğer kullanılan user'ın /tmp dizininde yetkisi yoksa modülün Python script'i /home/%u/.ansible/tmp dizinine kopyalanır.
• Parametreler ise JSON formatında hazırlanıp stdin üzerinden iletilir.

Örnek modül dosyası yolu:

/tmp/ansible-tmp-1234567890.123456/module_name.py

Modülün Çalıştırılması

Gönderilen modül, hedef sistemdeki Python yorumlayıcısıyla çalıştırılır:

/usr/bin/python3 /tmp/ansible-tmp-XXXXXX/module_name.py

Parametreler komut satırından değil, stdin üzerinden şu formatla iletilir:

{"src": "/etc/hosts", "dest": "/tmp/hosts"}

Bu, Ansible'ın modül ve parametreleri otomatik olarak JSON'a dönüştürüp script'e verdiği formdur. Teknik olarak Ansible modül çalıştırma mantığını şu adımla yürütür:

ssh user@host "python3 /tmp/module.py" < parameters.json

JSON Formatında Sonuç

Modül çalışmasını tamamladıktan sonra sonucu JSON çıktısı olarak stdout üzerinden Ansible'a iletir:

{
  "changed": true,
  "msg": "Servis başlatıldı"
}

Ansible bu çıktıyı işleyerek sonuçları kullanıcıya bildirir (ok, changed, failed).

Geçici Dosyaların Temizlenmesi

Görev tamamlandıktan sonra oluşturulan geçici dosyalar Ansible tarafından silinir. Sistem temiz kalır ve kalıcı bir iz bırakılmaz.

Python Neden Gerekli?

Ansible modülleri büyük ölçüde Python ile yazılmıştır. Bu nedenle standart modüllerin çalışabilmesi için hedef sistemde Python kurulu olmalıdır. ansible_python_interpreter değişkeni ile Python yorumlayıcısının yolu manuel olarak belirtilebilir. Desteklenen Python versiyonu kullanılan ansible-core sürümüne göre değişir. Güncel gereksinimler için resmi ansible-core support matrix tablosuna başvurulmalıdır.

Tek istisna raw modülüdür. raw, doğrudan SSH üzerinden ham komut çalıştırır ve Python gerektirmez. Bu nedenle genellikle Python kurulu olmayan sistemlere Python'ı kurmak için bootstrap aracı olarak kullanılır:

- name: Install Python on target
  ansible.builtin.raw: dnf install -y python3

Ansible Modül Mimarisi

Her modül, belirli bir namespace altında yer alır ve namespace.collection.module formatını takip eder:

• ansible.builtin.package: ansible namespace'i, builtin collection'ı, package modülü. Ansible Core ile birlikte gelen yerleşik modülleri ifade eder. Ek kurulum gerektirmez.
• ansible.posix.mount: ansible namespace'i, posix collection'ı, mount modülü. POSIX sistemlere özgü işlemler için kullanılan collection'dan gelir. ansible-galaxy collection install ansible.posix ile kurulur.
• community.general.expect: community namespace'i, general collection'ı, expect modülü. Topluluk tarafından geliştirilen ve geniş kapsamlı araçları barındıran collection'dan gelir. ansible-galaxy collection install community.general ile kurulur.

Bu yapı sayesinde aynı işlevi gören ama farklı kaynaklardan gelen modüller birbiriyle çakışmaz. Hangi modülün nereden geldiği ve nasıl kurulacağı namespace üzerinden anlaşılır.

Özet: Adım Adım İşleyiş

1. Bağlantı Kurulur – SSH ile hedefe ulaşılır.
2. Modül Transferi – Python script ve parametreler gönderilir.
3. Çalıştırma – Modül hedefte çalıştırılır.
4. Sonuç Alınır – JSON çıktısı kontrol makinesine döner.
5. Temizlik – Geçici dosyalar silinir.

Bu süreç her task için yeniden işler. Bu nedenle Ansible "stateless" olarak tanımlanır.

Idempotency

Ansible'ın temel tasarım prensiplerinden biri idempotency'dir. Bir işlem idempotent ise, aynı işlemi bir kez çalıştırmakla on kez çalıştırmak aynı sonucu verir.

Bunu somutlaştıralım. ansible.builtin.package modülü ile bir paket yüklemek istediğimizde:

- name: Ensure nginx is installed
  ansible.builtin.package:
    name: nginx
    state: present

Bu task'ı ilk çalıştırdığımızda ilgili sunucuda nginx kurulu değilse Ansible paketi kurar ve changed döner. İkinci kez çalıştırdığımızda nginx zaten kurulu olduğu için Ansible hiçbir şey yapmaz ve ok döner.

Şu ayrım kritiktir:

• ok -> Sistem zaten istenen durumda, hiçbir şey değişmedi.
• changed -> Ansible bir değişiklik yaptı.
• failed -> Bir şeyler ters gitti.

Peki bu neden önemli? Çünkü production ortamlarında aynı playbook'u patch döngülerinde, CI/CD pipeline'larında, ya da bir şeyin doğru konfigürasyonda olduğundan emin olmak için zamanla defalarca çalıştırabiliriz. Idempotency sayesinde bu çalıştırmalar sistemi bozmaz, yalnızca sapmaları düzeltir.

Ancak her modül idempotent değildir. ansible.builtin.command ve ansible.builtin.shell modülleri doğası gereği idempotent değildir çünkü Ansible bu komutların ne yaptığını bilemez. Bu yüzden mümkün olduğunca amaca özel modüller (package, service, file, copy vb.) tercih edilmeli, command ve shell yalnızca başka seçenek yoksa kullanılmalıdır.

İyi yazılmış bir playbook'ta changed sayısı mümkün olduğunca az olmalıdır. Eğer her çalıştırmada her şey changed dönüyorsa, bu playbook'un idempotent olmadığının işaretidir.

Sık Sorulan Sorular

Agent nedir? Ansible neden agentsız?

Agent, hedef sistemde kurulu olan, kontrol merkezinden talimat bekleyen servistir. Ansible ise hiçbir agent kurmadan, doğrudan SSH ile çalışır. Bu da onu sade, kurulum gerektirmeyen ve düşük maliyetli kılar.

SSH Key mi daha güvenli, parola mı?

SSH Key:

• Brute-force saldırılarına dayanıklıdır.
• Otomasyon dostudur.
• Güvenli ve yönetilebilir.

Parola:

• Otomasyonda problem çıkarır.
• Elle girilmesi gerekir.
• Zayıf olabilir ve sık değişmesi gerekebilir.

ansible.cfg ayarlarının hangi değeri kullanacağını Ansible nasıl belirler?

Ansible, birden fazla yerde bulunabilen ansible.cfg dosyalarından öncelik sırasına göre ilk bulduğunu kullanır:

Bu yazıda Ansible'ın yüzeysel bir araç tanımının ötesine geçerek nasıl çalıştığını adım adım inceledik. SSH bağlantısından modül transferine, idempotency'den mimari bileşenlere kadar ele aldığımız bu temel, ilerleyen yazılarda playbook yazımı, rol mimarisi ve değişken yönetimi gibi konulara geçişi çok daha sağlam bir zemine oturtacak.