Ansible ile Sunucu Otomasyonuna Giriş

Tek bir sunucuya SSH ile bağlanıp elle kurmak keyiflidir; nginx'i yüklersiniz, birkaç ayarı düzenlersiniz ve iş biter. Ama sunucu sayısı üçe, beşe, ona çıktığında bu keyif hızla kâbusa döner. Her makineye tek tek bağlanıp aynı komutları tekrarlamak yorucu olmasının yanında hataya da çok açıktır: bir sunucuda bir paketi kurmayı unutursunuz, diğerinde bir ayarı yanlış girersiniz ve "aynı" olması gereken sistemleriniz sessizce birbirinden ayrışır. İşte bu "kar tanesi sunucu" (snowflake server) sorunu, otomasyonun neden gerekli olduğunu en iyi anlatan durumdur.

Ansible tam da bu noktada devreye girer. Sunucularınızın nasıl yapılandırılması gerektiğini okunabilir metin dosyalarına yazarsınız; Ansible da bu tarifi SSH üzerinden onlarca makineye aynı anda, tekrarlanabilir biçimde uygular. Bu rehberde Ansible'ın ajansız mimarisini, envanter dosyasını, ad-hoc komutları, ilk playbook'unuzu (paket kurma, servis başlatma, dosya kopyalama), otomasyonun kalbi olan idempotency kavramını ve büyüdükçe işinizi kurtaracak rolleri kıdemli bir sistem yöneticisinin gözünden ele alacağız. SSH tarafında eksiğiniz varsa önce SSH bağlantısı ve güvenliği yazımıza göz atmanızı öneririm; Ansible'ın tüm işi o kanalın üzerinden yürür.

Ansible Nedir ve Ajansız Mimari Neden Önemli#

Ansible, açık kaynaklı bir yapılandırma yönetimi (configuration management) ve otomasyon aracıdır. Temel fikri basittir: "istenen durumu" (desired state) YAML formatında tanımlarsınız, Ansible da uzak sunucuları o duruma getirir. Yani "şu komutu çalıştır" demek yerine "nginx paketi kurulu olsun ve servis çalışıyor olsun" dersiniz; nasıl yapılacağını Ansible çözer.

En büyük ayırt edici özelliği ajansız (agentless) çalışmasıdır. Puppet veya Chef gibi bazı araçlar, yönettiğiniz her sunucuya kalıcı bir ajan (agent) yazılımı kurmanızı ve bunun sürekli çalışmasını gerektirir. Ansible ise hedef sunucularda hiçbir özel yazılım istemez; yönetim makinenizde Ansible kurulu olması ve hedeflere SSH ile erişebilmeniz yeterlidir. Ansible, komutları geçici olarak SSH üzerinden gönderir, uzak tarafta Python ile çalıştırır ve sonucu geri alır. İş bitince arkasında bir servis bırakmaz.

Bu yaklaşımın pratikteki avantajlarını şöyle özetleyebiliriz:

Ajansız olmak, farklı sağlayıcılarda dağınık duran sunucuları yönetirken paha biçilmezdir. Yeni bir sunucu aldığınızda tek yapmanız gereken SSH anahtarınızı eklemektir; başka hiçbir kurulum gerekmez.

Kurulum ve İlk Bağlantı#

Ansible'ı sadece kontrol makinesine kurarsınız; bu, kendi dizüstü bilgisayarınız ya da yönetim için ayırdığınız küçük bir sunucu olabilir. Hedef sunuculara Ansible kurmanıza gerek yok; onlarda yalnızca Python'un bulunması yeterlidir ki modern dağıtımların neredeyse tamamında zaten kurulu gelir.

Kontrol makinesinde kurulum dağıtıma göre şöyledir:

# Ubuntu/Debian
sudo apt update && sudo apt install -y ansible

# AlmaLinux/Rocky Linux
sudo dnf install -y epel-release && sudo dnf install -y ansible

# Kurulumu ve sürümü doğrula
ansible --version

Ansible SSH üzerinden çalıştığı için, kontrol makinenizden hedef sunuculara parolasız SSH anahtarı ile bağlanabiliyor olmanız kritik öneme sahiptir. Henüz anahtarınız yoksa oluşturup hedef sunuculara kopyalayın:

# Anahtar çifti oluştur (zaten varsa atlayın)
ssh-keygen -t ed25519 -C "ansible-kontrol"

# Ortak anahtarı hedef sunucuya gönder
ssh-copy-id [email protected]

# Elle bağlanarak parolasız erişimi doğrula
ssh [email protected]

Parola sormadan bağlanabildiğinizde temel hazırlığınız tamamdır. Üretim ortamında root yerine sudo yetkisine sahip ayrı bir kullanıcıyla çalışmak çok daha güvenlidir; bu ayrımı ve anahtar güvenliğini SSH güvenliği rehberimizde bulabilirsiniz.

Envanter (Inventory) Dosyası#

Ansible'ın hangi sunucularla konuşacağını bir envanter (inventory) dosyasından öğrenir. Bu dosya, yönettiğiniz makinelerin listesidir; onları mantıksal gruplara ayırarak "web sunucuları" ya da "veritabanları" gibi kümelere komut göndermenizi sağlar. En basit haliyle INI formatında yazılır; proje klasörünüzde bir inventory.ini oluşturalım:

[web]
web1 ansible_host=203.0.113.10
web2 ansible_host=203.0.113.11

[db]
db1 ansible_host=203.0.113.20

[tum_sunucular:children]
web
db

[all:vars]
ansible_user=deploy
ansible_ssh_private_key_file=~/.ssh/id_ed25519
ansible_python_interpreter=/usr/bin/python3

Burada web ve db iki grup; web1, db1 gibi isimler ise takma adlardır (alias). ansible_host her makinenin gerçek IP'sini belirtir. [tum_sunucular:children] bloğu iki grubu tek üst grupta birleştirir; böylece "hem web hem db" demek istediğinizde tek isim kullanabilirsiniz. [all:vars] altında ise tüm hedeflere uygulanacak ortak değişkenleri (bağlanılacak kullanıcı, kullanılacak SSH anahtarı, uzak Python yolu) tanımlarız.

Envanterin doğru okunduğunu ve tüm sunuculara ulaşılabildiğini şu iki komutla test edin:

# Envanterdeki grup ve makine yapısını göster
ansible-inventory -i inventory.ini --graph

# Tüm sunuculara "ping" at (gerçek ICMP değil, SSH+Python testidir)
ansible all -i inventory.ini -m ping

Buradaki ping modülü sizi yanıltmasın; ICMP ping değildir. Ansible'ın hedefe SSH ile bağlanıp Python'u çalıştırabildiğini doğrulayan bir sağlık kontrolüdür. Her sunucudan "ping": "pong" yanıtı alıyorsanız otomasyona hazırsınız demektir.

Ad-hoc Komutlar#

Bir playbook yazmadan, tek seferlik işler için Ansible'ın ad-hoc komutlarını kullanabilirsiniz. Bunlar "şu grubu al, şu modülü çalıştır" mantığında hızlı tek satırlık komutlardır; günlük operasyonlarda inanılmaz pratiktir. Söz dizimi ansible <grup> -m <modül> -a "<argümanlar>" şeklindedir.

Örneğin tüm web sunucularının çalışma süresini (uptime) tek komutla görelim:

# Tüm web sunucularında 'uptime' komutunu çalıştır
ansible web -i inventory.ini -m command -a "uptime"

# Tüm sunucularda disk kullanımını gör
ansible all -i inventory.ini -m command -a "df -h"

# Sadece db grubunda bellek durumunu kontrol et
ansible db -i inventory.ini -m command -a "free -m"

Paket kurmak, servis yönetmek gibi işleri de ad-hoc yapabilirsiniz. Bunlarda genellikle yükseltilmiş yetki (--become, yani sudo) gerekir:

# Tüm sunucularda paket listesini güncelle (Ubuntu/Debian)
ansible all -i inventory.ini -m apt -a "update_cache=yes" --become

# Web sunucularına nginx kur
ansible web -i inventory.ini -m apt -a "name=nginx state=present" --become

# nginx servisini başlat ve açılışa ekle
ansible web -i inventory.ini -m service -a "name=nginx state=started enabled=yes" --become

Ad-hoc komutlar; hızlı bir kontrol veya acil bir düzeltme için mükemmeldir. Ancak birden fazla adımı tekrar tekrar çalıştırmak istediğinizde, bunları kalıcı ve okunabilir bir tarife dönüştürmeniz gerekir. İşte o tarif "playbook"tur.

İlk Playbook'unuzu Yazmak#

Playbook, Ansible'ın kalbidir. Sunucularınızda olmasını istediğiniz durumu YAML formatında adım adım tanımlayan bir dosyadır. Ad-hoc komutların aksine playbook'lar Git'e alınabilir, gözden geçirilebilir ve defalarca güvenle çalıştırılabilir. Bir web sunucusunu baştan hazırlayan web-kurulum.yml dosyası yazalım:

---
- name: Web sunucularini yapilandir
  hosts: web
  become: yes

  tasks:
    - name: Paket onbellegini guncelle
      apt:
        update_cache: yes
        cache_valid_time: 3600

    - name: Nginx paketini kur
      apt:
        name: nginx
        state: present

    - name: Ozel ana sayfayi kopyala
      copy:
        src: files/index.html
        dest: /var/www/html/index.html
        owner: www-data
        group: www-data
        mode: "0644"

    - name: Nginx servisini baslat ve acilisa ekle
      service:
        name: nginx
        state: started
        enabled: yes

Bu dosyayı çözelim. En üstteki blok bir play'dir: hosts: web tarifin yalnızca web grubundaki sunuculara uygulanacağını, become: yes ise komutların sudo ile çalıştırılacağını söyler. tasks altındaki her madde bir görevdir (task) ve bir modül çağırır. name alanları zorunlu değildir ama çıktıyı okunabilir kılar.

Görevlerin sırası mantığı takip eder: önce paket önbelleği güncellenir, sonra nginx kurulur, ardından copy modülüyle yerel files/index.html dosyası sunucuya taşınır ve en sonunda servis başlatılıp açılışa eklenir. copy görevindeki src kontrol makinenizdeki dosyayı, dest ise hedefteki konumu ifade eder. Playbook'u çalıştırmak için:

# Playbook'u calistir
ansible-playbook -i inventory.ini web-kurulum.yml

# Once ne degisecegini gormek icin "prova" modu (hicbir sey degistirmez)
ansible-playbook -i inventory.ini web-kurulum.yml --check

--check bayrağı çok değerlidir: Ansible hiçbir şeyi değiştirmeden, çalıştırılsaydı nelerin değişeceğini raporlar. Üretimde bir playbook'u ilk kez uygulamadan önce daima bu "prova" modunu kullanın.

Idempotency: Otomasyonun Kalbi#

Ansible'ı basit bir kabuk (shell) betiğinden ayıran en önemli özellik idempotency (değişmezlik / tekrarlanabilirlik) ilkesidir. Bunun anlamı şudur: bir playbook'u bir kez de çalıştırsanız yüz kez de çalıştırsanız sonuç aynı olur; sistem yalnızca gereken değişiklik varsa müdahale eder, hâlihazırda doğru olan hiçbir şeye dokunmaz.

Bir örnekle netleştirelim. apt: name=nginx state=present görevini ilk çalıştırdığınızda nginx kurulu değilse Ansible onu kurar ve durumu changed olarak işaretler. İkinci kez çalıştırdığınızda ise nginx zaten kurulu olduğu için Ansible hiçbir şey yapmaz ve durumu ok olarak raporlar. Elle yazdığınız bir apt install nginx betiği ise her seferinde çalışmaya çalışır; idempotent değildir.

Bir playbook çalışması sonunda gördüğünüz özet tam olarak bunu gösterir:

PLAY RECAP *********************************************************
web1  : ok=4    changed=0    unreachable=0    failed=0
web2  : ok=4    changed=1    unreachable=0    failed=0

Burada web1 üzerinde changed=0 görüyoruz: makine zaten istenen durumdaydı. web2 üzerinde ise changed=1; demek ki orada bir eksik vardı ve Ansible onu düzeltti. Bu davranış otomasyonu güvenle tekrar tekrar çalıştırmanızı sağlar. Bir sunucunun ayarı bozulduğunda ya da yeni bir makine eklediğinizde aynı playbook'u yeniden çalıştırırsınız; Ansible sadece "kayan" (drift eden) kısımları gerçek duruma geri getirir.

İdempotency'nin tek istisnası command ve shell modülleridir; bunlar ne çalıştırdığınızı bilmediği için her seferinde çalışır. Bu yüzden mümkün olduğunca ham komut yerine amaca özel modülleri (apt, service, copy, template, user) tercih edin; onlar durumu anlayacak kadar akıllıdır.

Handler'lar ve Değişkenlerle Esneklik#

Bir yapılandırma dosyasını değiştirdiğinizde çoğu zaman ilgili servisi yeniden başlatmanız gerekir; ama bunu yalnızca dosya gerçekten değiştiyse yapmak istersiniz. Ansible bunu handler mekanizmasıyla çözer: bir görevin sonuna notify eklersiniz ve o görev değişiklik yaptığında haber verdiği handler, playbook'un sonunda bir kez çalışır.

---
- name: Nginx yapilandirmasini yonet
  hosts: web
  become: yes

  vars:
    site_adi: cloutr-ornek

  tasks:
    - name: Site yapilandirmasini sablondan olustur
      template:
        src: templates/site.conf.j2
        dest: "/etc/nginx/sites-available/{{ site_adi }}.conf"
      notify: Nginx'i yeniden baslat

    - name: Siteyi etkinlestir
      file:
        src: "/etc/nginx/sites-available/{{ site_adi }}.conf"
        dest: "/etc/nginx/sites-enabled/{{ site_adi }}.conf"
        state: link
      notify: Nginx'i yeniden baslat

  handlers:
    - name: Nginx'i yeniden baslat
      service:
        name: nginx
        state: restarted

Bu playbook'ta iki yeni kavram var. Birincisi vars bloğundaki site_adi değişkeni; {{ site_adi }} söz dizimiyle görevler içinde kullanılıyor ve aynı playbook'u farklı site adları için tekrar kullanmanızı sağlar. İkincisi template modülü: copy'ye benzer ama Jinja2 şablonlarını işler, yani dosyadaki {{ değişken }} ifadelerini gerçek değerleriyle doldurarak yazar; böylece her sunucu için özelleştirilmiş yapılandırma üretebilirsiniz.

Kritik nokta handler mantığıdır: notify ile çağrılan handler, ilgili görevlerden en az biri değişiklik yaptıysa ve yalnızca bir kez çalışır. Yapılandırma zaten günceldi ve hiçbir şey değişmediyse handler hiç tetiklenmez; yani gereksiz yere servisi yeniden başlatıp kesintiye yol açmazsınız. Bu, idempotency ilkesinin servis yönetimine yansımasıdır.

Rollerle Yapıyı Ölçeklemek#

Küçük bir proje tek bir playbook ile idare edilebilir. Ama sunucu tipleri (web, veritabanı, önbellek) ve görev sayısı arttıkça tek dosya yönetilemez hale gelir. Ansible bu karmaşayı roller (roles) ile çözer. Rol, belirli bir işi (örneğin "nginx kurup yapılandır") yapan görevleri, şablonları, dosyaları ve değişkenleri standart bir klasör yapısında paketleyen yeniden kullanılabilir birimdir.

Bir rol iskeletini ansible-galaxy ile otomatik oluşturabilirsiniz:

ansible-galaxy init roles/nginx

Bu komut şu standart yapıyı üretir:

roles/nginx/
├── tasks/       # main.yml — rolün ana görevleri
├── handlers/    # main.yml — yeniden başlatma vb. handler'lar
├── templates/   # Jinja2 şablonları (.j2)
├── files/       # olduğu gibi kopyalanacak statik dosyalar
├── vars/        # rol değişkenleri
├── defaults/    # varsayılan (kolayca ezilebilen) değişkenler
└── meta/        # rol bağımlılıkları ve bilgileri

Rolü kullanan ana playbook'unuz artık sadece "hangi gruba hangi rolü uygulayacağını" söyler; ayrıntılar rolün içindedir:

---
- name: Tum altyapiyi kur
  hosts: web
  become: yes
  roles:
    - nginx
    - php-fpm
    - guvenlik-duvari

- name: Veritabani sunucularini kur
  hosts: db
  become: yes
  roles:
    - mysql
    - guvenlik-duvari

Bu yaklaşımın gücü tekrar kullanılabilirlikte yatar. "guvenlik-duvari" rolünü bir kez yazar, hem web hem db sunucularında kullanırsınız; yeni bir sunucu tipi eklediğinizde mevcut rolleri lego parçaları gibi birleştirirsiniz. Bu felsefe konteynerlerin taşınabilirliğiyle de örtüşür; servisleri konteyner temelli düşünmeye başladıysanız Docker'a giriş yazımız iyi bir sonraki adımdır. Ansible ile Docker sıklıkla birlikte kullanılır: Ansible sunucuyu hazırlar, Docker uygulamayı çalıştırır.

Çok Sunucuda Tekrarlanabilir Kurulumun Değeri#

Şimdi tüm bu parçaların pratikte neden önemli olduğunu somut bir senaryoyla görelim. Diyelim ki bir e-ticaret projesi için üç özdeş web sunucusu ve bir yük dengeleyici (load balancer) arkasında çalışan bir altyapı kuruyorsunuz. Elle yaklaşımda her sunucuya tek tek bağlanır, aynı on beş komutu tekrarlar ve kaçınılmaz olarak birinde bir şeyi atlarsınız.

Ansible ile aynı işi tek komutla, birebir aynı sonuçla yaparsınız:

# Uc web sunucusunu da ayni anda, ayni tarifle kur
ansible-playbook -i inventory.ini web-kurulum.yml

Dördüncü sunucu mu geldi? Envanterin [web] grubuna bir satır ekler ve aynı playbook'u yeniden çalıştırırsınız. Ansible mevcut üç sunucuya (idempotency sayesinde) dokunmaz, yalnızca yeni makineyi diğerleriyle birebir aynı hale getirir. Bu tekrarlanabilirliğin somut kazanımları şunlardır:

• Tutarlılık: Tüm sunucular kelimesi kelimesine aynı yapılandırmaya sahip olur; "bu sunucuda niye farklı çalışıyor" sorunu ortadan kalkar.
• Belgelenmiş altyapı: Playbook'unuz aynı zamanda sunucunuzun canlı, çalışan belgesidir; kim ne kurdu diye tahmin etmezsiniz.
• Hızlı felaket kurtarma: Bir sunucu tamamen çökse bile, boş bir makineye aynı playbook'u uygulayarak dakikalar içinde birebir kopyasını üretirsiniz.
• Sürüm kontrolü: Playbook'ları Git'te tutarsınız; her altyapı değişikliği gözden geçirilebilir ve geri alınabilir bir commit olur.
• Ölçeklenebilirlik: Üç sunucu da otuz sunucu da aynı komutla yönetilir; iş yükünüz makine sayısıyla değil, tarifin karmaşıklığıyla artar.

Bu yaklaşım "altyapıyı kod olarak" (Infrastructure as Code) yönetmenin özüdür. Yönettiğiniz sunucularda tam kök erişimine ihtiyacınız olduğunu unutmayın; paylaşımlı hosting'de bu düzeyde otomasyon mümkün değildir. Kendi playbook'larınızı çalıştırabileceğiniz ortamlar için VDS ve sanal sunucu çözümleri idealdir.

Sıkça Sorulan Sorular#

Ansible kullanmak için hedef sunuculara bir şey kurmam gerekiyor mu?#

Hayır, Ansible'ın en büyük avantajı ajansız (agentless) çalışmasıdır. Yalnızca kontrol makinenize (kendi bilgisayarınız veya bir yönetim sunucusu) Ansible kurarsınız. Hedef sunucularda ise sadece SSH erişimi ve Python bulunması yeterlidir ki ikincisi neredeyse tüm modern Linux dağıtımlarında zaten varsayılan olarak kuruludur. Yeni bir sunucu eklerken tek yapmanız gereken SSH anahtarınızı tanımlamak ve envantere bir satır eklemektir.

Ansible ile bir kabuk (shell) betiği arasındaki fark nedir?#

Kabuk betiği komutları sırayla ve koşulsuz çalıştırır; aynı betiği iki kez çalıştırırsanız işlemleri tekrar yapmaya kalkar ve bazen hata verir. Ansible ise idempotency ilkesiyle çalışır: sistemin olması gereken durumunu tanımlarsınız ve Ansible yalnızca eksik olanı düzeltir, zaten doğru olana dokunmaz. Ayrıca Ansible tek bir komutla onlarca sunucuyu paralel yönetebilir, okunabilir YAML kullanır ve sonuçları düzgün biçimde raporlar; bir betikte bunların hepsini elle yazmanız gerekirdi.

Envanter dosyası ne işe yarar?#

Envanter, Ansible'ın yöneteceği sunucuların listesidir ve onları mantıksal gruplara (web, db, önbellek gibi) ayırmanızı sağlar. Bu gruplama sayesinde "tüm web sunucularına nginx kur" gibi komutları tek seferde, doğru makinelere gönderebilirsiniz. Envanterde her sunucunun IP adresini, bağlanılacak kullanıcıyı ve SSH anahtarını da tanımlayabilirsiniz; böylece Ansible her makineye nasıl erişeceğini bilir.

Idempotency tam olarak ne anlama geliyor?#

Idempotency, bir playbook'u kaç kez çalıştırırsanız çalıştırın sonucun hep aynı olması demektir. Ansible sistemin mevcut durumunu kontrol eder ve yalnızca istenen duruma ulaşmak için gereken değişiklikleri yapar; zaten doğru olan hiçbir şeye müdahale etmez. Bu sayede aynı playbook'u güvenle tekrar tekrar çalıştırabilir, bozulan ayarları eski haline getirebilir veya yeni sunucuları mevcutlarla birebir aynı hale getirebilirsiniz. Ham komutlar (command/shell modülleri) bu kuralın dışındadır; onlar her seferinde çalışır.

Rolleri ne zaman kullanmaya başlamalıyım?#

Küçük ve tek amaçlı işler için basit bir playbook yeterlidir; birkaç görevlik bir kurulum için rol yazmak fazla olur. Ancak sunucu tipleriniz çeşitlendiğinde, aynı görevleri farklı gruplarda tekrar kullandığınızda veya bir playbook yüzlerce satıra ulaştığında roller şart olur. Roller görevleri, şablonları ve değişkenleri standart bir klasör yapısında paketleyerek yeniden kullanılabilir hale getirir; böylece "güvenlik duvarı" veya "nginx" gibi parçaları bir kez yazıp farklı sunucularda lego gibi birleştirebilirsiniz.

Ansible ile Docker birlikte kullanılabilir mi?#

Evet, ikisi birbirini çok iyi tamamlar. Yaygın bir yaklaşımda Ansible sunucunun kendisini hazırlar (paketleri kurar, kullanıcıları oluşturur, güvenlik duvarını ve Docker motorunu yapılandırır) ve uygulamaların çalıştırılmasını Docker'a bırakır. Ansible'ın docker_container gibi modülleriyle konteynerleri de doğrudan yönetebilirsiniz. Yani Ansible altyapı katmanını, Docker ise uygulama katmanını tekrarlanabilir kılar; ikisini birleştirdiğinizde baştan sona otomatik bir dağıtım hattı elde edersiniz.

Kapanış#

Ansible, sunucu yönetimini elle tekrar eden bir zanaat olmaktan çıkarıp okunabilir, versiyonlanabilir ve tekrarlanabilir bir mühendislik disiplinine dönüştürür. Ajansız mimarisi sayesinde tek yapmanız gereken SSH erişimidir; envanterle sunucularınızı gruplar, ad-hoc komutlarla hızlı işleri halleder, playbook'larla kalıcı yapılandırmayı tanımlar ve idempotency sayesinde her şeyi güvenle tekrar çalıştırabilirsiniz. Bir sunucu için değil, on sunucu için düşünmeye başladığınızda bu yaklaşımın değeri katlanarak artar.

Ansible ile otomasyona başlamak için tam kök erişimine sahip, esnek bir sunucuya ihtiyacınız var. Clou.TR'nin VDS sunucuları ve sanal sunucu paketleri kendi playbook'larınızı çalıştırmanız için ideal ortamı sunar; kurulum ve bakım yükünü tamamen bize bırakmak isterseniz sunucu yönetimi hizmetimiz ile altyapınızı biz sizin adınıza kurup izleyebiliriz. Tüm seçenekleri görmek için sunucu paketlerimizi, veri güvenliği için yedekleme çözümlerimizi inceleyebilirsiniz.