Ansible, bir envanterde seçtiğiniz makinelerin durumunu YAML playbook’larıyla yönetir. Aynı işi her sunucuda elle tekrarlamak yerine hedefleri, istenen durumu ve doğrulama adımlarını kod olarak tanımlarsınız. Agentless, yönetilen Linux makinede hiç ön koşul olmadığı anlamına gelmez: çoğu Ansible modülü için SSH erişimi ve uyumlu Python gerekir.
Bu rehberde Ubuntu 24.04 LTS kontrol makinesi, Python 3.12 ve ansible-core 2.20 kullanılır. Yönetilen Ubuntu 24.04 makinede önce mevcut kullanıcıya ait küçük bir örnek yapılandırma dosyası oluşturulur. Amaç envanteri, geçerli YAML’ı, check mode’u ve ikinci çalıştırmada gereksiz değişiklik yapılmadığını öğrenmektir. Çalışan web sunucusu, paketler veya ağ kuralları değiştirilmez.
Kontrol makinesi ile yönetilen makineyi ayırın
- Kontrol makinesi: Ansible ve projenin bulunduğu bilgisayardır. Bu örnek Ubuntu içindir; yerel Windows kontrol makinesi yerine desteklenen bir Linux/WSL ortamı planlayın.
- Yönetilen makine: SSH ile eriştiğiniz hedeftir. Uyumlu Python, yetkili kullanıcı ve gereken dosya izinleri bulunmalıdır. Ansible’ın kendisini her hedefe kurmanız gerekmez.
- Envanter: Hangi makinenin hangi gruba ait olduğunu belirtir. Uygulama ve veritabanı makinelerini tek bir belirsiz
allhedefiyle yönetmeyin. - Playbook: Hedef grup ve görevleri tanımlar. Modüller çoğunlukla mevcut durumla hedef durumu karşılaştırır; rastgele
shellkomutları otomatik olarak idempotent olmaz.
SSH sunucusunun parmak izini önce güvenilir kanaldan doğrulayın. Ayrı görev kullanıcınızla elle giriş yapabildiğinizi kontrol edin. İlk örnek için root, become veya genel sudo izni gerekmez.
Görselin adım adım açıklaması
- Hedefle: Envanter ile makineleri seç.
- Tanımla: Playbook içinde istenen durumu belirt.
- Uygula: Durumu bilen modülleri kullan.
- Tekrarla: Gereksiz değişiklik olmadığını doğrula.
Ansible’ı ayrı Python ortamına kurun
Kontrol makinesinde Python 3.12 ve venv paketini kurun. Var olan sistem Python paketlerini değiştirmek yerine ayrı ortam kullanın:
sudo apt update
sudo apt install python3.12 python3.12-venv
python3.12 -m venv "$HOME/.venvs/fc-ansible"
. "$HOME/.venvs/fc-ansible/bin/activate"
python -m pip install 'ansible-core>=2.20,<2.21'
ansible --versionansible --version çıktısından kullanılan Python’u, ansible-core sürümünü ve yapılandırma dosyasını kontrol edin. Sürüm aralığı aynı ana sürümdeki düzeltmeleri alır; kabul ettiğiniz tam bağımlılık listesini proje kaydında tutun:
install -d -m 700 "$HOME/fc-ansible-project"
cd "$HOME/fc-ansible-project"
python -m pip freeze > requirements.lockYeni bir ansible-core sürümüne geçmeden önce resmî Python destek matrisini ve porting guide’ı okuyup aynı kabul adımlarını tekrar çalıştırın.
Envanteri oluşturun ve hedefleri görün
hosts.ini dosyasını hazırlayın. Sunucu adı, kullanıcı ve özel anahtar yolunu kendi doğrulanmış erişiminizle değiştirin; özel anahtarın içeriğini envantere koymayın.
[web_sunuculari]
web01 ansible_host=server.example.com ansible_user=deploy ansible_ssh_private_key_file=~/.ssh/fibacloud_ed25519
[web_sunuculari:vars]
ansible_python_interpreter=/usr/bin/python3Hedef listesini ve Python modülü çalıştırılabildiğini kontrol edin:
ansible-inventory -i hosts.ini --graph
ansible -i hosts.ini web_sunuculari -m ansible.builtin.pingAnsible ping modülü ICMP ping değildir; giriş yapıp Python modülü çalıştırabildiğinizi sınar. pong yanıtı sunucunun uygulama sağlık kontrolünün yerine geçmez. Yanlış sunucu anahtarı, kullanıcı veya özel anahtar varsa doğrulamayı kapatmak yerine erişimi düzeltin.
Geçerli YAML ile ilk playbook
demo.yml dosyasına aşağıdaki içeriği yazın. YAML’da sekme yerine boşluk kullanın; hosts, become, vars ve tasks, name ile aynı play seviyesinde bulunur.
---
- name: Kullanıcıya ait örnek yapılandırmayı yönet
hosts: web_sunuculari
gather_facts: true
become: false
vars:
demo_directory: "{{ ansible_facts['env']['HOME'] }}/fc-ansible-demo"
tasks:
- name: Özel örnek dizinini oluştur
ansible.builtin.file:
path: "{{ demo_directory }}"
state: directory
mode: "0700"
- name: Örnek yapılandırmayı yerleştir
ansible.builtin.copy:
dest: "{{ demo_directory }}/application.ini"
mode: "0600"
content: |
[application]
environment=demo
log_level=infoHedef kullanıcının ev dizinindeki fc-ansible-demo bu denemeye ayrılmış yeni bir dizin olmalıdır. İçinde gerçek uygulama dosyaları varsa devam etmeyin; yeni bir deneme adı seçin. Örnek; dizin ve dosya izinlerini açıkça tanımlar, sistem hizmetini yeniden başlatmaz ve parola içermez.
Sözdizimi, ön izleme ve iki çalıştırma
Önce YAML ve playbook yapısını denetleyin:
ansible-playbook -i hosts.ini demo.yml --syntax-check
ansible-playbook -i hosts.ini demo.yml --list-hosts --limit web01Listede yalnız değiştirmek istediğiniz makine bulunmalıdır. Sonra destekleyen modüllerle değişiklik ön izlemesi yapın:
ansible-playbook -i hosts.ini demo.yml --check --diff --limit web01Check mode tam bir sanal sunucu çalıştırması değildir. Bazı modüller desteklemez; önceki görevlerin henüz oluşmamış çıktısına bağımlı işlemler tam olarak canlandırılamayabilir. --diff içerik gösterebilir; gizli dosyalar için kullanmayın. Örnekteki metin gizli bilgi içermez.
Ön izlemeyi değerlendirdikten sonra aynı kapsamı uygulayın ve tekrar çalıştırın:
ansible-playbook -i hosts.ini demo.yml --limit web01
ansible-playbook -i hosts.ini demo.yml --limit web01İlk çalıştırmada gereken dosyalar oluşturulur. İçerik ve izinler arada değişmediyse ikinci çalıştırmada changed=0, her iki çalıştırmada failed=0 ve unreachable=0 beklenir. changed=0 çıktısı bütün altyapının güvenli olduğunu kanıtlamaz; yalnız bu görevlerin o anda değişiklik gerekmediğini gösterir. Hedefte dosya içeriğini ve 0700/0600 izinlerini de doğrulayın.
Hata ayırma ve güvenli genişletme
| Belirti | Kontrol |
|---|---|
| YAML/syntax hatası | Girinti, iki nokta, tırnaklar ve play seviyeleri. Önce --syntax-check. |
UNREACHABLE |
SSH adresi, kullanıcı, sunucu anahtarı, erişim ağı ve seçili anahtar. |
| Python bulunamıyor | Hedefte Python yolu ve seçilen ansible-core sürümünün destek matrisi. |
| İzin reddi | Hedef kullanıcının dizin izinleri. Gereksiz genel become: true eklemeyin. |
| İkinci çalıştırma da değişiyor | Değişken zaman damgaları, dışarıdan değişen dosyalar veya durumu denetlemeyen görevler. |
Gerçek web sunucusu otomasyonuna geçerken hedef dağıtımın paket ve hizmet modüllerini kullanın. Yalnız ilgili görevlerde gereken yetki yükseltmesini tanımlayın. Yeniden başlatma gerekiyorsa yapılandırma doğrulamasından sonra çalışan handler tasarlayın; her çalıştırmada koşulsuz yeniden başlatma yapmayın.
Parolaları ve erişim belirteçlerini düz envanter veya playbook içine yazmayın. Ansible Vault ya da kurumunuzun sır yönetimiyle çalışın. Vault veriyi saklanırken korur; çözülmüş bir sırrın günlükte veya diff çıktısında görünmesini tek başına engellemez.
Geri dönüş ve bakım
Bu örnek yalnız yeni deneme dizini oluşturur. Geri dönüşte o dizinin bu çalışmaya ait olduğunu ve sonradan önemli dosya eklenmediğini doğrulayın; ardından deneme dosyasını ve boş dizini kaldırın. Gerçek uygulama otomasyonunda ise önceki sürüm, yapılandırma yedeği ve geri dönüş playbook’u önceden hazırlanmalıdır.
Playbook ve sır içermeyen envanter şablonunu sürüm kontrolünde tutun. Her değişiklikte sözdizimi, hedef listesi, check mode ve ikinci çalıştırma kontrolünü tekrarlayın. Ansible/Python veya hedef işletim sistemi sürümü değiştiğinde ayrı test makinesinde yeniden kabul yapın.
Kaynaklar
- Ansible — Kurulum, kontrol ve yönetilen makine gereksinimleri
- Ansible — Check mode ve diff mode sınırları
- Ansible — Playbook yapısı ve YAML
- Ansible — file modülü: durum ve izinler
- Ansible — copy modülü: içerik, izin ve check mode
- Ansible — Sürümler ve destek yaşam döngüsü
Teknik içerik ve kaynaklar 4 Ekim 2026 tarihinde gözden geçirildi. Sürüm veya sağlayıcı değişikliğinde ilgili resmî belgeyi yeniden kontrol edin.
Bir yanıt yazın