Rehberler

Yazan Matt Connor 2026-10-11

Ansible ile Ilk Playbook: Ubuntu 24.04 VPS Kurulumu

Q: Ansible neden "Permission denied (publickey)" hatası veriyor?

UNREACHABLE! bloğunun Permission denied (publickey) ile birlikte kullanılması, Ansible herhangi bir işlem çalıştırmadan önce SSH kimlik doğrulamasının başarısız olduğunu gösterir. Envanterdeki ansible_user değerinin gerçekten yapılandırdığınız hesapla eşleştiğini, bu makineye ssh-copy-id çalıştırdığınızı ve düz ssh user@host komutunun parola istemeden oturum açtığını denetleyin. Düz ssh komutunu düzelten işlem Ansible'ı da düzeltir; çünkü ikisi aynı aktarım mekanizmasını kullanır.

Q: ansible ve ansible-core paketleri arasındaki fark nedir?

ansible-core, yalnızca ansible.builtin modüllerini içeren altyapıdır. ansible paketi, çekirdek bileşenleri topluluk tarafından seçilerek düzenlenmiş koleksiyonlarla birlikte sunar. Bunlar arasında bu kılavuzda kullanılan ansible.posix (authorized_key modülü) ve community.general (ufw modülü) bulunur. Tam paketle başlanmalıdır; yalnızca bir gerekçe bulunduğunda core ve elle seçilmiş koleksiyonlarla daha küçük bir kuruluma geçilmelidir.

Ubuntu 24.04 uzerinde pipx ile Ansible kurulumunu, envanter dosyasini ve VPS guvenlik sikilastirma playbookunu ogrenin. Permission denied ve sudo hatalarina cozumler.

Yapılacaklar

Ansible'ın kurulu olduğu bir denetim makinesi ile üzerinde stok imaj dışında hiçbir şey bulunmayan bir veya daha fazla yeni Ubuntu 24.04 VPS kurulacaktır. İşlemin sonunda sunucularınızı adlandıran bir envanter dosyasına, kimlik doğrulamanın uçtan uca çalıştığını kanıtlayan geçici bir ping komutuna ve yeni VPS denetim listesinin tamamını kod olarak çalıştıran bir playbook'a sahip olunacaktır: SSH anahtarınızla bir dağıtım kullanıcısı, güvenliği güçlendirilmiş sshd, fail2ban, unattended upgrades ve diğer tüm bağlantıları reddetmeden önce OpenSSH'e izin veren bir güvenlik duvarı. Yapılandırma tek bir sunucuya veya yirmi sunucuya uygulanabilir. İkinci kez çalıştırıldığında hiçbir değişiklik yapılmaz. Amaç budur.

On beş yıllık VPS hazırlama deneyiminden sonra görülen durum açıktır: Herkes ilk beş sunucuyu elle kurar, ardından altıncı sunucuda bir hafta sonunu kaybeder; çünkü ilk beş sunucuda ne yaptığını kimse hatırlamaz. Bu kılavuz, birden fazla Linux sunucusunu yönetme konusunu daha ayrıntılı ele alır. Aynı apt install komutunu üç terminalde yazdığınızı fark ettiğiniz gün bu kılavuza başvurun.

Ansible'in gerçekte ne olduğu, tek paragrafta

Ansible aracısızdır. Yönettiği sunuculara kurulacak bir daemon yoktur: kontrol makinesi normal SSH üzerinden bağlanır, küçük bir Python modülünü hedefe kopyalar, modülü çalıştırır, yazdırdığı JSON verisini okur ve modülü siler. Bir hedefin ihtiyaç duyduğu tek şey python3 değeridir; bu değer her standart Ubuntu imajında zaten bulunur. Önemli olan sözcük idempotent ifadesidir ve anlamı açıktır: bir görev, eylemi değil bir durumu tanımlar. Bir paket için state: present, "bunun kurulu olduğundan emin ol" anlamına gelir; "yükleyiciyi çalıştır" anlamına gelmez. Durum zaten sağlanmışsa Ansible hiçbir değişiklik yapmaz ve sonucu ok olarak bildirir; changed olarak bildirmez. Ürünün tamamı bu özelliktir; bir playbook'un yeniden çalıştırılmasını güvenli kılan da budur ve güvenli yeniden çalıştırmalar, kabuk betiğini altyapıya dönüştürür.

Ön koşullar ve baştan bilinmesi gereken sorunlar

Bir kontrol makinesi: dizüstü bilgisayarınız veya küçük bir VPS. Ubuntu 24.04 varsayılmaktadır; Homebrew üzerinden pipx kurulduktan sonra macOS da aynı şekilde çalışır.
KVM üzerinde Ubuntu 24.04 çalıştıran ve root olarak erişilebilen bir veya daha fazla hedef VPS. Bu makinelere hiçbir şey kurulmaz.
Her hedef için SSH anahtarı kimlik doğrulaması. Ansible, kimlik doğrulaması açısından ssh komutunuzla tamamen aynıdır; ssh root@host parola isterse Ansible başarısız olur.
Ubuntu 24.04 üzerinde pip install ansible, error: externally-managed-environment ile sonlanır. Bu bir bozulma değil, dağıtımın kasıtlı politikasıdır. pipx kullanılmalıdır.
YAML boşluk kullanımına duyarlıdır. Girintinin yanlış olması mapping values are not allowed in this context üretir ve herhangi bir yerdeki sekme karakteri işlemi başarısız kılar.
Playbook sshd'yi güvenli hale getirirken her hedefte çalışan bir SSH oturumunu açık tutun. Kurtarılmasına yardımcı olduğum her erişim kilitlenmesinde, son oturum "temiz ortamdan test etmek" amacıyla kapatılmıştı.

Adım 1: Ansible'ı kontrol makinesine pip yerine pipx ile kurun

Klasik içgüdü pip3 install ansible kullanmaktır. Henüz yeni kurulmuş bir 24.04 imajında bu işlem bir adım erken başarısız olur, Command 'pip3' not found, but can be installed with: sudo apt install python3-pip komutu çalıştırılır ve pip kurulumu yapmak sizi asıl engelle karşılaştırır:

pip3 install ansible

error: externally-managed-environment

× This environment is externally managed
╰─> To install Python packages system-wide, try apt install
    python3-xyz, where xyz is the package you are trying to
    install.

Ubuntu 24.04, sistem Python'ını harici olarak yönetilen (PEP 668) şeklinde işaretler; bu nedenle pip, aynı dosyalar üzerinde apt ile çakışamaz. --break-system-packages kullanmaya çalışmayın; bayrağın ismi dürüsttür. Temiz çözüm, Ansible'a kendi yalıtılmış virtualenv ortamını sağlayan ve çalıştırılabilir dosyaları PATH değişkeninize ekleyen pipx aracıdır:

sudo apt update && sudo apt install -y pipx
pipx ensurepath
pipx install --include-deps ansible

PATH değişikliğinin geçerli olması için pipx ensurepath komutundan sonra yeni bir kabuk (shell) açın. --include-deps bir süs değildir: ansible paketi kendi başına konsol betikleri içermez; ansible, ansible-playbook ve diğerleri, ansible-core bağımlılığının giriş noktalarıdır. Bu bayrak olmadan pipx, No apps associated with package ansible. hatasıyla kurulumu reddeder ve --include-deps ile tekrar denemenizi söyler. Ayrıca sadece ansible-core değil, ansible paketini kurun; tam paket topluluk koleksiyonlarını içerir ve bu playbook, bunlardan ikisine ait (ansible.posix ve community.general) modülleri kullanır.

ansible --version

2026-10-11 itibarıyla yeni bir kurulum, ansible-core 2.21.5 sürümünü sabitleyen ansible 14.5.0 paketini çeker. Bu nedenle doğru sonuç ansible [core 2.21.5] ile başlar ve çalıştığı Python sürümünü belirtir; buradaki her işlem için güncel bir core sürümü yeterlidir. Core 2.21, kontrol makinesinde Python 3.12 veya daha yenisini gerektirir ki bu da Ubuntu 24.04 ile gelen sürümdür. Eğer eski bir kurulum hala core 2.19 rapor ediyorsa, 2.19 serisinin ömrünün Kasım 2026'da dolacağını unutmayın. ansible: command not found hatası ise ~/.local/bin dosyasının henüz PATH değişkeninizde olmadığını, yeni bir kabuk açmanız gerektiğini veya source ~/.bashrc durumunu ifade eder.

Kurulumun tamamı budur. Hedef makinelere hiçbir şey kurulmaz.

Adım 2: Her hedefe SSH anahtarıyla erişim

ssh-keygen -t ed25519 -C "ansible control"
ssh-copy-id root@10.0.0.10
ssh-copy-id root@10.0.0.20

Ardından her ana bilgisayar için bir kez doğrulayın:

ssh root@10.0.0.10 true && echo ok

Bu tek satır iki işi yapar: anahtar kimlik doğrulamasının parola olmadan çalıştığını doğrular ve ana bilgisayar anahtarını known_hosts içine kaydeder. Bunu şimdi yapın. Aksi takdirde Ansible, kaydedilmemiş bir ana bilgisayar anahtarını çalışmanın ortasında gizlenen etkileşimli bir istem olarak gösterir; bu da tam olarak işlemin takıldığı izlenimini verir.

3. Adım: envanter; önce INI, büyüdüğünde YAML

Envanter, Ansible'ın erişebileceği makineleri listeleyen bir metin dosyasıdır. Yeni bir proje dizininde inventory.ini dosyasını oluşturun:

[vps]
web1 ansible_host=10.0.0.10
web2 ansible_host=10.0.0.20

[vps:vars]
ansible_user=root

web1 seçtiğiniz bir takma addır. Çıktıda görünen ad budur ve --limit web1 ile hedeflediğiniz addır. ansible_host gerçek adrestir. [vps] bir gruptur ve [vps:vars] bu gruptaki her ana bilgisayar için değişkenleri ayarlar; ansible_user ise Ansible'ın oturum açacağı kullanıcıdır. Bunun yanına bir ansible.cfg ekleyin; böylece -i değerini tekrar yazmanız gerekmez:

[defaults]
inventory = inventory.ini

Ansible, ansible.cfg dosyasını geçerli dizinden okur. Aynı envanteri YAML biçiminde inventory.yml adıyla kaydedip ansible.cfg seçeneğini bu ada yönlendirin. Ana bilgisayarların her biri birden fazla değişken taşıdığında bu yöntemi tercih edeceksiniz:

vps:
  hosts:
    web1:
      ansible_host: 10.0.0.10
    web2:
      ansible_host: 10.0.0.20
  vars:
    ansible_user: root

İkisi de eşdeğerdir. İki sunucuda INI biçimini hızlıca incelemek daha kolaydır; yirmi sunucuda YAML daha iyi ölçeklenir. Birini seçin ve bu konuyu artık düşünmeyin.

4. Ad-hoc komutları: her şeyi doğrulayan yeşil pong

ansible all -m ping

Bu işlem ICMP kullanmaz. ping modülü tam bir prova gerçekleştirir: SSH ile oturum açar, modülü kopyalar, hedefte Python çalıştırır ve temizleme işlemi yapar. Doğru sonuç yeşildir ve her ana bilgisayar için bir blok görüntülenir:

web1 | SUCCESS => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/bin/python3"
    },
    "changed": false,
    "ping": "pong"
}

Yeşil SUCCESS; kimlik doğrulamanın, Python yorumlayıcısının ve aktarımın çalıştığını gösterir. Bu durumda playbook da çalışır. Kırmızı UNREACHABLE!, herhangi bir modül çalıştırılmadan önce aktarımın başarısız olduğu anlamına gelir. Hata durumları aşağıdaki bölümde ilgili tam dize ve düzeltme açıklanır. Bilinmesi gereken iki ad-hoc komutu daha:

ansible all -a "uptime"
ansible all -m apt -a "update_cache=true upgrade=dist" --become

Ad-hoc komutları tek seferlik işlemler ve kontroller için kullanılır. İki kez çalıştırılacak her işlem playbook içine alınmalıdır.

5. Adım: ilk playbook, yeni VPS kontrol listesinin kod olarak uygulanması

Bu, yeni bir sunucuda ilk 10 dakika içinde elle yapılacak işlemlerin tamamıdır. Bunu site.yml olarak kaydedin:

---
- name: Baseline a fresh Ubuntu VPS
  hosts: vps
  become: true

  vars:
    deploy_user: deploy
    deploy_pubkey: "{{ lookup('file', '~/.ssh/id_ed25519.pub') }}"
    baseline_packages:
      - fail2ban
      - unattended-upgrades
      - ufw
    baseline_services:
      - fail2ban
      - unattended-upgrades

  tasks:
    - name: Create the deploy user
      ansible.builtin.user:
        name: "{{ deploy_user }}"
        groups: sudo
        append: true
        shell: /bin/bash

    - name: Install the deploy user's SSH key
      ansible.posix.authorized_key:
        user: "{{ deploy_user }}"
        key: "{{ deploy_pubkey }}"

    - name: Passwordless sudo for the deploy user
      ansible.builtin.copy:
        dest: /etc/sudoers.d/deploy
        content: "{{ deploy_user }} ALL=(ALL) NOPASSWD:ALL\n"
        mode: "0440"
        validate: /usr/sbin/visudo -cf %s

    - name: Install baseline packages
      ansible.builtin.apt:
        name: "{{ baseline_packages }}"
        state: present
        update_cache: true

    - name: Enable and start baseline services
      ansible.builtin.service:
        name: "{{ item }}"
        state: started
        enabled: true
      loop: "{{ baseline_services }}"

    - name: Harden sshd with a drop-in
      ansible.builtin.copy:
        dest: /etc/ssh/sshd_config.d/00-hardening.conf
        content: |
          PasswordAuthentication no
          KbdInteractiveAuthentication no
          PermitRootLogin prohibit-password
          X11Forwarding no
        mode: "0644"
        validate: /usr/sbin/sshd -t -f %s
      notify: Restart ssh

    - name: Allow OpenSSH through ufw
      community.general.ufw:
        rule: allow
        name: OpenSSH

    - name: Enable ufw with default deny
      community.general.ufw:
        state: enabled
        policy: deny

  handlers:
    - name: Restart ssh
      ansible.builtin.service:
        name: ssh
        state: restarted

Kopyalamak yerine anlaşılması gereken satırlar:

Değişkenler vars: altında tanımlanır ve "{{ deploy_user }}" ile kullanılır. Bir değer süslü ayraçla başlıyorsa ifadenin tamamını tırnak içine alın; aksi halde YAML ayrıştırıcısı ifadeyi yanlış yorumlar. lookup('file', ...), çalışma zamanında public key değerini control makinesinden okur. Böylece playbook içinde anahtar materyali bulunmaz.

Döngü. loop: "{{ baseline_services }}", hizmet görevini her öğe için bir kez çalıştırır ve çıktıda her öğeyi ayrı satırda gösterir. apt görevinin bunun yerine tüm paket listesini tek seferde aldığını unutmayın. Paketler için tek bir apt işlemi daha hızlıdır ve tercih edilen yöntemdir. Döngüler, gerçekten tek seferde yalnızca bir öğe üzerinde işlem yapan modüller içindir.

Handler, özümsenmesi gereken kavramdır. notify: Restart ssh, "ssh'yi şimdi yeniden başlat" anlamına gelmez. Handler'ı kuyruğa alır. Handler, play'in sonunda bir kez çalışır ve yalnızca bildirim gönderen görev gerçekten changed bildirdiyse çalıştırılır. Playbook'u yarın yeniden çalıştırın: drop-in dosyası zaten doğrudur, copy görevi ok bildirir ve sshd yeniden başlatılmaz. validate: satırı, tetikleyici için güvenlik kontrolüdür. sshd eski yapılandırmayı değiştirmeden önce dosyayı denetler. Böylece yazım hatası daemon'u bozmak yerine görevin başarısız olmasına neden olur.

PermitRootLogin prohibit-password, no değil, kasıtlı olarak kullanılır. Bu playbook root hesabıyla ve bir key kullanarak oturum açar. prohibit-password, sizin oturumunuzu açık tutarken root hesabıyla password login işlemlerini devre dışı bırakır. Deploy user doğrulandıktan sonra (ssh deploy@10.0.0.10 sudo true, düz adres; çünkü web1 yalnızca Ansible'ın bildiği bir alias'tır), inventory içindeki ansible_user=deploy değerini değiştirin ve sonraki çalıştırmada bunu no olarak sıkılaştırın. Erişiminizi kaybetmenize neden olmayacak bir sırayla güvenliği güçlendirin.

00- ön eki önemlidir. sshd, çoğu anahtar sözcük için ayrıştırdığı ilk oluşumu kullanır. Ubuntu'nun sshd_config dosyası, kendi gövdesinden önce sözlüksel sırayla sshd_config.d/*.conf dosyasını içerir. Ubuntu 24.04 cloud image'ları bu dizinde zaten bir 60-cloudimg-settings.conf dosyası sağlar. cloud-init üzerinden password login işlemlerini etkinleştiren sağlayıcılar ise 50-cloud-init.conf dosyasını PasswordAuthentication yes ile ekler. Dosyamıza 00-hardening.conf adını vermek, dosyanın ilk sırada gelmesini ve her ikisine de üstün gelmesini sağlar.

Görevlerin sırası firewall güvenliğini sağlar. Allow OpenSSH, deny policy ile Enable ufw işleminden önce çalışır. Ansible görevleri listelenen sıraya kesin olarak uyar. Bu nedenle duvar etkinleşmeden önce açıklık oluşur. fail2ban'ın burada yararlı olması için ek yapılandırma gerekmez. Ubuntu varsayılanları sshd'yi doğrudan izler. Jail'lerin gerçekte ne yaptığı ve hangi ayarların değiştirileceği, Ubuntu 24.04 üzerinde fail2ban kılavuzu içinde ele alınır.

Adım 6: --check ile deneme çalıştırması yapın, ardından gerçek çalıştırmayı başlatın

ansible-playbook site.yml --check

Denetim modu bağlantı kurar ve ne yapacağını hesaplar, ancak hiçbir değişiklik yapmaz. Alttaki PLAY RECAP bölümünde yer alan changed= sayısını okuyun. Bu sayı, her ana bilgisayarı değiştirecek görevlerin sayısıdır. Önemli bir sınırlama vardır: Daha sonraki bir görev önceki bir görevin yaptığı değişikliklere bağlı olduğunda denetim modu yapısal olarak sınırlıdır. Ubuntu'nun standart server image sürümü ufw ile önceden geldiğinden bu playbook deneme çalıştırmasında sorunsuz çalışır. Ancak ufw'nin bulunmadığı minimal bir image kullanılırsa ufw görevleri denetim modunda başarısız olur. Bunun nedeni, denetim modunun paketi gerçekten kurmaması ve modülün çağırabileceği bir bileşen bulunmamasıdır. Bu durum, playbook'taki bir hata değil, deneme çalıştırmalarının bir sınırlamasıdır. Plan doğru görünüyorsa:

ansible-playbook site.yml

Her görev, her ana bilgisayar için bir satır yazdırır. changed sarı, ok yeşil renktedir. Özet şu şekilde olmalıdır:

PLAY RECAP *********************************************************************
web1 : ok=10  changed=9  unreachable=0  failed=0  skipped=0  rescued=0  ignored=0
web2 : ok=10  changed=9  unreachable=0  failed=0  skipped=0  rescued=0  ignored=0

On ok, gerçeklerin toplanması, sekiz görev ve handler görevinden oluşur. changed değerinizin benimkinden bir veya iki farklı olması normaldir. Ubuntu'nun standart image sürümü ufw ve unattended-upgrades ile önceden gelir. Ayrıca fail2ban, apt tarafından kurulur kurulmaz kendisini başlatır. Bu nedenle bir görev ilk çalıştırmada meşru olarak ok bildirebilir. Bu, görevin bildirdiği durumun zaten mevcut olduğu anlamına gelir. Sıfır olması gereken sayılar unreachable ve failed değerleridir. become: true hakkında bir not: root olarak bağlandığınız sürece bu yalnızca bir formalitedir. Ancak ansible_user değerini deploy olarak değiştirdiğiniz anda sudo gerçekten devreye girer. Bu playbook'un kurduğu NOPASSWD sudoers dosyası, -K ifadesinin komut satırınızda görünmesini önleyen bileşendir. Bu dosya olmadan aşağıda açıklanan Missing sudo password ile karşılaşırsınız.

Adım 7: iki kez çalıştırma ve idempotence davranışı

Aynı komutu hemen tekrar çalıştırın:

web1 : ok=9  changed=0  unreachable=0  failed=0  skipped=0  rescued=0  ignored=0

changed=0 ve ok birer azaldı; çünkü bildirim gönderilmemiş işleyici hiç çalışmadı. Hiçbir şey yeniden kurulmadı, sshd yeniden başlatılmadı ve ufw üzerinde işlem yapılmadı. Playbook'u bir provisioner kadar denetim aracı yapan özellik budur: gelecek ay envantere web3 ekleyip yeniden çalıştırın; yeni sunucu oluşturulur, mevcut sunucular doğrulanır. Dokunmadığınız bir sunucudaki sıfır olmayan changed değeri drift olduğunu gösterir. Ayrıca, playbook'ta bulunması gereken bir ayarın birisi tarafından elle değiştirildiğini belirtir.

Bu noktadan sonra aynı yaklaşım genişletilebilir. Yazılması gereken bir sonraki playbook, aynı VPS üzerinde bir WireGuard VPN kurmalı ve ufw kuralını SSH'nin yalnızca tünel üzerinden yanıt vereceği şekilde sıkılaştırmalıdır. Bundan sonra her uygulama sunucusuna Docker ve Compose kuran bir playbook yazılabilir. site.yml üç ekranı aşmaya başladığında bunu rollere ayırın, ancak bundan önce ayırmayın.

Hata modları ve karşılaşacağınız dizeler

UNREACHABLE with Permission denied.

web1 | UNREACHABLE! => {
    "changed": false,
    "msg": "Failed to connect to the host via ssh: root@10.0.0.10: Permission denied (publickey).",
    "unreachable": true
}

SSH aktarımı, herhangi bir modül çalışmadan önce başarısız oldu: ansible_user hatalı, anahtar o sunucuya hiç kopyalanmadı veya yanlış anahtar sunuluyor. Sorunu yeniden oluşturmak için düz ssh root@10.0.0.10 komutunu, ardından hangi anahtarların sunulduğunu görmek için ssh -v komutunu kullanın. Parola ile SSH bağlantısı çalışıyor ancak Ansible çalışmıyorsa, ssh-copy-id adımını atlamışsınız demektir.

Missing sudo password.

web1 | FAILED! => {
    "msg": "Missing sudo password"
}

become: true ayarını yaptınız, root olmayan bir kullanıcıyla bağlandınız ve bu kullanıcının sudo için parolaya ihtiyacı var. Komut satırına -K (--ask-become-pass) ekleyin ya da kullanıcıya NOPASSWD yetkisi içeren bir sudoers girdisi tanımlayın; playbook'un siz geçiş yapmadan önce deploy için bir tane kurmasının tam nedeni budur.

error: externally-managed-environment. Ubuntu 24.04 üzerinde sistem Python'ına karşı pip çalıştırdınız. 1. adımda ele alındığı gibi: pip değil pipx kullanın ve --break-system-packages kullanmayın.

mapping values are not allowed in this context.

ERROR! Syntax Error while loading YAML.
  mapping values are not allowed in this context

Neredeyse her zaman girintileme hatasıdır: yanlış derinlikte bir anahtar veya iki nokta üst üste işaretinden sonra eksik boşluk. Bildirilen satır numarası hatanın tam yerini değil, yakınını işaret eder; bir üst satırı da kontrol edin. Bunun benzeri olan found character '\t' that cannot start any token hatası, araya bir tab karakterinin sızdığı anlamına gelir; YAML tab kullanımını yasaklar. Her çalıştırmadan önce ansible-playbook site.yml --syntax-check komutunu bir refleks haline getirin ve düzenleyicinizi YAML için iki boşluklu girintilemeye ayarlayın.

/usr/bin/python3: not found. Standart Ubuntu 24.04 imajlarında nadirdir, minimal veya netboot imajlarında ise yaygındır: hedef sistemde Python bulunmadığı için modül yürütme başarısız olur. Bunu raw modülü ile önyükleyin; bu modül, karşı tarafta Python gerektirmeyen az sayıdaki modülden biridir (script diğeridir) ve doğrudan komut iletmek için tasarlanmıştır: ansible all -m raw -a "apt-get update && apt-get install -y python3" --become, ardından playbook'u tekrar çalıştırın.

FAQ

Ansible'ı yönettiği sunuculara yüklemek gerekir mi?

Hayır. Ansible aracısız çalışır: denetim makinesi küçük Python modüllerini SSH üzerinden gönderir, çalıştırır ve kaldırır. Hedefte yalnızca python3 ve SSH erişimi bulunmalıdır; stok Ubuntu imajlarında her ikisi de zaten bulunur. Bu kılavuzdaki tek yükleme işlemi denetim makinenizde gerçekleştirilir.

Ansible neden "Permission denied (publickey)" hatası veriyor?

UNREACHABLE! bloğunun Permission denied (publickey) ile birlikte kullanılması, Ansible herhangi bir işlem çalıştırmadan önce SSH kimlik doğrulamasının başarısız olduğunu gösterir. Envanterdeki ansible_user değerinin gerçekten yapılandırdığınız hesapla eşleştiğini, bu makineye ssh-copy-id çalıştırdığınızı ve düz ssh user@host komutunun parola istemeden oturum açtığını denetleyin. Düz ssh komutunu düzelten işlem Ansible'ı da düzeltir; çünkü ikisi aynı aktarım mekanizmasını kullanır.

Ansible'da idempotent ne anlama gelir?

Bir görev, gerçekleştirilecek bir eylem yerine istenen durumu bildirir: "bu paket mevcut", "bu satır bu dosyada bulunuyor". Durum zaten sağlanıyorsa Ansible hiçbir işlem yapmaz ve ok yerine changed bildirir. Bu nedenle bir playbook ikinci kez çalıştırıldığında changed=0 gösterilir; yeniden çalıştırma, riskli bir yeniden yükleme değil, güvenli bir denetimdir.

Ansible'ı Ubuntu 24.04 üzerine yüklemek için pip mi, pipx mi kullanılmalı?

pipx kullanılmalıdır. Ubuntu 24.04, sistem Python ortamını harici olarak yönetilen bir ortam olarak işaretler; bu nedenle pip install ansible tasarım gereği error: externally-managed-environment ile başarısız olur. pipx install --include-deps ansible, Ansible'ı yalıtılmış bir virtualenv içine yerleştirir ve ansible, ansible-playbook ile diğer bileşenleri PATH üzerinde düzgün şekilde kullanılabilir hale getirir.

ansible ve ansible-core paketleri arasındaki fark nedir?

ansible-core, yalnızca ansible.builtin modüllerini içeren altyapıdır. ansible paketi, çekirdek bileşenleri topluluk tarafından seçilerek düzenlenmiş koleksiyonlarla birlikte sunar. Bunlar arasında bu kılavuzda kullanılan ansible.posix (authorized_key modülü) ve community.general (ufw modülü) bulunur. Tam paketle başlanmalıdır; yalnızca bir gerekçe bulunduğunda core ve elle seçilmiş koleksiyonlarla daha küçük bir kuruluma geçilmelidir.

#ansible #automation #ubuntu #devops