Ansible Tutorial: Ubuntu 24.04 पर पहला Playbook कैसे चलाएं

आप क्या बना रहे हैं

Ansible इंस्टॉल किया हुआ एक कंट्रोल मशीन, और एक या अधिक नए Ubuntu 24.04 VPS, जिनमें स्टॉक इमेज के अलावा कुछ भी नहीं है। अंत तक आपके पास एक इन्वेंट्री फाइल होगी जो आपके सर्वर्स के नाम बताएगी, एक ad-hoc पिंग कमांड जो यह साबित करेगी कि ऑथेंटिकेशन पूरी तरह काम कर रहा है, और एक प्लेबुक जो नए VPS की पूरी चेकलिस्ट को कोड के रूप में चलाएगी: आपके SSH की (key) के साथ एक डिप्लॉय यूजर, हार्डन्ड sshd, fail2ban, unattended upgrades, और एक फायरवॉल जो बाकी सब कुछ ब्लॉक करने से पहले OpenSSH को अनुमति देता है। इसे एक सर्वर पर चलाएं या बीस पर। इसे दो बार चलाएं और दूसरी बार में कुछ भी नहीं बदलेगा, यही इसका मुख्य उद्देश्य है।

पंद्रह वर्षों तक VPS प्रोविजनिंग करने के बाद मैं आपको ईमानदारी से यह पैटर्न बता सकता हूँ: हर कोई पहले पाँच सर्वर्स को हाथ से सेटअप करता है, फिर छठे सर्वर पर एक पूरा वीकेंड बर्बाद कर देता है क्योंकि किसी को याद नहीं रहता कि उन्होंने पहले पाँच के साथ क्या किया था। यह गाइड कई Linux सर्वर्स को मैनेज करने के विषय पर गहराई से चर्चा करती है, इसे उस दिन पढ़ें जब आप खुद को तीन अलग-अलग टर्मिनल्स में एक ही apt install टाइप करते हुए पाएं।

Ansible वास्तव में क्या है, एक पैराग्राफ में

Ansible agentless है। जिन सर्वर्स को यह manage करता है, उन पर कोई daemon install करने की आवश्यकता नहीं होती: control machine सामान्य SSH के माध्यम से connect होती है, target पर एक छोटा Python module copy करती है, उसे execute करती है, उसके द्वारा print किए गए JSON को पढ़ती है और फिर उसे delete कर देती है। target को केवल python3 की आवश्यकता होती है, जो हर stock Ubuntu image में पहले से मौजूद होता है। यहाँ सबसे महत्वपूर्ण शब्द idempotent है, और इसका सीधा सा अर्थ है: एक task किसी state (स्थिति) का वर्णन करता है, न कि किसी action (क्रिया) का। किसी package के लिए state: present का अर्थ है "सुनिश्चित करें कि यह installed है", न कि "installer चलाएं"। यदि वह state पहले से ही मौजूद है, तो Ansible किसी भी चीज़ को नहीं बदलता और उसे changed के बजाय ok के रूप में report करता है। यह गुण ही पूरा product है, यही वह चीज़ है जो playbook को दोबारा चलाना सुरक्षित बनाती है, और सुरक्षित reruns ही वह चीज़ हैं जो एक shell script को infrastructure में बदल देती हैं।

पूर्व-आवश्यकताएँ और शुरुआती सावधानियाँ

• एक control machine: आपका लैपटॉप या एक छोटा VPS। मैं Ubuntu 24.04 का उपयोग मानकर चल रहा हूँ; pipx के Homebrew से install होने के बाद macOS पर भी यह समान रूप से काम करता है।
• एक या अधिक target VPS जो KVM पर Ubuntu 24.04 चला रहे हों और root के रूप में पहुँच योग्य हों। इन पर कुछ भी install नहीं किया जाता है।
• प्रत्येक target के लिए SSH key authentication। Ansible का authentication स्तर बिल्कुल आपके ssh command जैसा ही होता है, यदि ssh root@host पासवर्ड के लिए prompt करता है, तो Ansible विफल हो जाएगा।
• Ubuntu 24.04 पर, pip install ansible, error: externally-managed-environment के साथ विफल हो जाता है। यह distro की सोची-समझी नीति है, कोई खराबी नहीं। pipx का उपयोग करें।
• YAML में whitespace ही syntax है। गलत indent से mapping values are not allowed in this context उत्पन्न होता है, और कहीं भी tab character का उपयोग घातक है।
• जब playbook sshd को harden कर रहा हो, तो प्रत्येक target पर एक सक्रिय SSH session खुला रखें। जिन भी ग्राहकों को lockout से उबरने में मैंने मदद की है, उन सभी ने "साफ तौर पर टेस्ट करने के लिए" अपना आखिरी session बंद कर दिया था।

चरण 1: control machine पर Ansible को pip के बजाय pipx के साथ install करें

स्वाभाविक प्रवृत्ति pip3 install ansible का उपयोग करने की होती है। एक बिल्कुल नए 24.04 image पर यह एक चरण पहले ही विफल हो जाता है, Command 'pip3' not found, but can be installed with: sudo apt install python3-pip, और केवल pip install करने से आप वास्तविक समस्या में फंस जाते हैं:

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 system Python को externally managed (PEP 668) के रूप में चिह्नित करता है, इसलिए pip समान फाइलों के लिए apt से संघर्ष नहीं कर सकता। --break-system-packages का उपयोग न करें; यह flag स्पष्ट रूप से चेतावनी देता है। इसका सही समाधान pipx है, जो Ansible को अपना isolated virtualenv देता है और binaries को आपके PATH में डाल देता है:

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

pipx ensurepath के बाद एक नया shell खोलें ताकि PATH में हुआ बदलाव प्रभावी हो सके। --include-deps केवल दिखावा नहीं है: ansible package में स्वयं की कोई console scripts नहीं होती हैं, ansible, ansible-playbook, और बाकी सभी इसकी ansible-core dependency के entry points हैं, इसलिए इस flag के बिना pipx No apps associated with package ansible or its dependencies के साथ install करने से मना कर देता है। और केवल ansible-core के बजाय ansible package install करें, क्योंकि पूर्ण package में community collections शामिल होती हैं, और यह playbook उनमें से दो (ansible.posix और community.general) के modules का उपयोग करती है।

ansible --version

सही परिणाम ansible [core 2.19.x] जैसी पंक्ति के साथ शुरू होता है और उस Python का नाम बताता है जिसके तहत यह चलता है; यहाँ दी गई किसी भी चीज़ के लिए कोई भी वर्तमान core release उपयुक्त है। इसके विपरीत ansible: command not found का अर्थ है कि ~/.local/bin अभी तक आपके PATH में नहीं है, नया shell खोलें, या source ~/.bashrc का उपयोग करें।

install प्रक्रिया बस इतनी ही है। targets पर कुछ भी install करने की आवश्यकता नहीं है।

चरण 2: प्रत्येक target के लिए SSH key access

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

इसके बाद, प्रत्येक host के लिए एक बार इसे प्रमाणित करें:

ssh root@10.0.0.10 true && echo ok

यह एक कमांड दो काम करती है: यह पुष्टि करती है कि key authentication बिना पासवर्ड के काम कर रहा है, और यह host key को known_hosts में रिकॉर्ड करती है। इसे अभी करें, क्योंकि यदि host key रिकॉर्ड नहीं की गई है, तो Ansible रन के बीच में एक interactive prompt दिखाएगा, जो ऐसा लगेगा जैसे प्रक्रिया अटक गई है।

चरण 3: इन्वेंट्री, पहले INI, बड़े होने पर YAML

इन्वेंट्री एक टेक्स्ट फ़ाइल है जिसमें उन मशीनों की सूची होती है जिन्हें Ansible एक्सेस कर सकता है। एक नए प्रोजेक्ट डायरेक्टरी में inventory.ini बनाएँ:

[vps]
web1 ansible_host=10.0.0.10
web2 ansible_host=10.0.0.20

[vps:vars]
ansible_user=root

web1 आपके द्वारा चुना गया एक उपनाम (alias) है, जो आउटपुट में दिखाई देता है और जिसे आप --limit web1 के साथ टारगेट करते हैं। ansible_host वास्तविक पता है। [vps] एक समूह है, और [vps:vars] इसमें मौजूद प्रत्येक होस्ट के लिए वेरिएबल सेट करता है; ansible_user वह यूजर है जिसके रूप में Ansible लॉगिन करता है। इसके बगल में, एक ansible.cfg रखें ताकि आपको दोबारा कभी -i टाइप न करना पड़े:

[defaults]
inventory = inventory.ini

Ansible वर्तमान डायरेक्टरी से ansible.cfg को पढ़ता है। वही इन्वेंट्री YAML फॉर्मेट में, जिसे inventory.yml के रूप में सेव करें और ansible.cfg को उस नाम पर पॉइंट करें, वह विकल्प है जिसे आप तब पसंद करेंगे जब होस्ट्स में कई वेरिएबल जुड़ जाएँ:

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

ये दोनों समान हैं। दो सर्वरों के लिए INI को देखना आसान है; बीस सर्वरों पर YAML बेहतर तरीके से स्केल होता है। एक चुनें और उसके बारे में सोचना बंद करें।

चरण 4: ad-hoc commands, वह green pong जो सब कुछ सिद्ध करता है

ansible all -m ping

यह ICMP नहीं है। ping module एक पूर्ण पूर्वाभ्यास (full dress rehearsal) है: SSH login, module copy, target पर Python execution, और cleanup। सही परिणाम हरा (green) होता है, प्रत्येक host के लिए एक block:

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

हरा SUCCESS रंग का अर्थ है कि authentication, Python interpreter, और transport सभी सही ढंग से काम कर रहे हैं, इसलिए playbook भी काम करेगी। लाल UNREACHABLE! रंग का अर्थ है कि किसी भी module के चलने से पहले transport विफल हो गया; सटीक error string और उसका समाधान नीचे failure modes अनुभाग में दिया गया है। दो और ad-hoc commands जो जानने योग्य हैं:

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

Ad-hoc का उपयोग केवल एक बार किए जाने वाले कार्यों और जाँच के लिए होता है। कोई भी कार्य जिसे आप दो बार चलाएंगे, उसे playbook में होना चाहिए।

चरण 5: पहला playbook, नए-VPS के लिए checklist as code

यह वह सब कुछ है जो आप एक नए सर्वर पर पहले दस मिनट में मैन्युअल रूप से करते हैं। इसे site.yml के रूप में सेव करें:

---
- 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

वे पंक्तियाँ जिन्हें कॉपी करने के बजाय समझना आवश्यक है:

Variables vars: के अंतर्गत रहते हैं और उन्हें "{{ deploy_user }}" के साथ संदर्भित किया जाता है। जब कोई मान (value) ब्रेस से शुरू हो, तो पूरे एक्सप्रेशन को कोट्स में रखें, अन्यथा YAML पार्सर इसे गलत पढ़ सकता है। lookup('file', ...) रनटाइम पर control मशीन से आपकी public key को पढ़ता है, इसलिए playbook में कोई भी key सामग्री शामिल नहीं होती।

लूप (The loop): loop: "{{ baseline_services }}" प्रत्येक आइटम के लिए service टास्क को एक बार चलाता है, और आउटपुट में प्रत्येक आइटम अपनी अलग पंक्ति में दिखाई देता है। ध्यान दें कि apt टास्क इसके बजाय पूरी पैकेज सूची को एक बार में लेता है; एक apt ट्रांजेक्शन तेज होता है और पैकेजों के लिए यही पसंदीदा पैटर्न है। लूप उन मॉड्यूल्स के लिए हैं जो वास्तव में एक समय में एक ही चीज़ पर काम करते हैं।

हैंडलर (The handler) वह अवधारणा है जिसे आत्मसात करना जरूरी है। notify: Restart ssh का अर्थ "ssh को अभी रीस्टार्ट करें" नहीं है। यह हैंडलर को कतार (queue) में डालता है, जो play के अंत में केवल एक बार चलता है, और वह भी तब जब नोटिफाई करने वाला टास्क वास्तव में changed रिपोर्ट करे। कल playbook को फिर से चलाएं: drop-in फ़ाइल पहले से ही सही है, copy टास्क ok रिपोर्ट करता है, और sshd को कभी भी रीस्टार्ट नहीं किया जाता। validate: लाइन ट्रिगर पर सुरक्षा है; sshd पुरानी फ़ाइल को बदलने से पहले नई फ़ाइल की जाँच करता है, इसलिए कोई भी टाइपो (typo) डेमन को तोड़ने के बजाय टास्क को फेल कर देता है।

जानबूझकर PermitRootLogin prohibit-password, न कि no। यह playbook एक key के साथ root के रूप में लॉग इन करता है। prohibit-password पासवर्ड के माध्यम से root लॉगिन को बंद कर देता है जबकि आपका लॉगिन सक्रिय रहता है। एक बार deploy यूजर सिद्ध हो जाने के बाद (ssh deploy@10.0.0.10 sudo true, सादा पता, क्योंकि web1 केवल Ansible द्वारा जाना जाने वाला एक उपनाम है), इन्वेंट्री में ansible_user=deploy को स्विच करें और बाद के रन में इसे no तक सीमित करें। सुरक्षा को उस क्रम में सख्त करें जिससे आप सर्वर से बाहर न हो जाएं।

00- उपसर्ग मायने रखता है। अधिकांश कीवर्ड्स के लिए sshd उस पहले ऑकरेंस (occurrence) का सम्मान करता है जिसे वह पार्स करता है, और Ubuntu का sshd_config अपने स्वयं के मुख्य भाग से पहले लेक्सिकल क्रम में sshd_config.d/*.conf को शामिल करता है। Ubuntu 24.04 क्लाउड इमेजेस में पहले से ही उस डायरेक्टरी में 60-cloudimg-settings.conf होता है, और जो प्रोवाइडर्स cloud-init के माध्यम से पासवर्ड लॉगिन सक्षम करते हैं, वे PasswordAuthentication yes के साथ एक 50-cloud-init.conf जोड़ते हैं; हमारे फ़ाइल का नाम 00-hardening.conf रखने से यह सबसे पहले सॉर्ट होता है और दोनों पर प्रभावी हो जाता है।

टास्क का क्रम फायरवॉल सुरक्षा के लिए महत्वपूर्ण है। Allow OpenSSH, deny पॉलिसी के साथ Enable ufw से पहले चलता है। Ansible टास्क को सूचीबद्ध क्रम में ही निष्पादित करता है, इसलिए दीवार खड़ी होने से पहले छेद (hole) मौजूद रहता है। fail2ban को यहाँ उपयोगी होने के लिए किसी कॉन्फ़िगरेशन की आवश्यकता नहीं है; इसके Ubuntu डिफ़ॉल्ट्स बॉक्स से बाहर निकलते ही sshd की निगरानी करते हैं, और jails वास्तव में क्या करती हैं और उन्हें कैसे ट्यून करना है, यह fail2ban on Ubuntu 24.04 guide में कवर किया गया है।

चरण 6: --check के साथ ड्राई रन करें, फिर इसे वास्तविक रूप में चलाएं

ansible-playbook site.yml --check

Check mode कनेक्ट होता है, गणना करता है कि यह क्या करेगा, और कुछ भी बदलता नहीं है। नीचे दिए गए PLAY RECAP में changed= की संख्या देखें, यह उन कार्यों की संख्या है जो प्रत्येक host को संशोधित करेंगे। एक महत्वपूर्ण चेतावनी: check mode की एक संरचनात्मक सीमा है जहाँ बाद का कार्य पहले के कार्य के परिवर्तनों पर निर्भर करता है। Ubuntu की standard server image में ufw पहले से होता है, इसलिए यह playbook ड्राई रन में ठीक चलता है, लेकिन इसके बिना एक minimal image पर, ufw कार्य check mode में fail हो जाते हैं, क्योंकि check mode ने वास्तव में package install नहीं किया होता है और module के पास कॉल करने के लिए कुछ नहीं होता है। यह ड्राई रन की एक सीमा है, न कि आपके playbook में कोई bug। जब plan सही दिखे:

ansible-playbook site.yml

प्रत्येक कार्य प्रति host एक लाइन प्रिंट करता है, पीला changed, हरा ok, और recap में यह दिखना चाहिए:

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

दस ok का मतलब है fact-gathering और आठ कार्य और handler। आपका changed मेरे से एक या दो अंक भिन्न हो सकता है: Ubuntu की standard image में ufw और unattended-upgrades पहले से होते हैं, और fail2ban apt द्वारा install होते ही खुद को start कर लेता है, इसलिए एक कार्य अपनी पहली ही run पर वैध रूप से ok रिपोर्ट कर सकता है, क्योंकि वह state पहले से मौजूद होती है। जिन संख्याओं का शून्य होना अनिवार्य है, वे unreachable और failed हैं। become: true पर एक नोट: यह एक औपचारिकता है जब आप root के रूप में connect होते हैं, लेकिन जिस क्षण आप ansible_user को deploy पर बदलते हैं, sudo वास्तविक हो जाता है, और यह playbook जो NOPASSWD sudoers file install करता है, वही आपके command line से -K को दूर रखता है। इसके बिना आपको Missing sudo password मिलेगा, जिसे नीचे समझाया गया है।

चरण 7: इसे दो बार चलाएं, idempotence कैसा दिखता है

उसी कमांड को तुरंत दोबारा चलाएं:

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

changed=0, और ok एक से कम हो गए क्योंकि un-notified handler कभी नहीं चला। कुछ भी reinstall नहीं हुआ, sshd restart नहीं हुआ, और ufw को नहीं छुआ गया। यही वह चीज है जो playbook को एक provisioner के साथ-साथ एक audit भी बनाती है: अगले महीने inventory में web3 जोड़ें और दोबारा चलाएं, नया box बन जाएगा, पुराने boxes verify हो जाएंगे। जिस box को आपने नहीं छुआ है, उस पर गैर-शून्य (nonzero) changed का मतलब drift है, और यह बताता है कि किसी ने मैन्युअल रूप से उसे edit किया है जिसे playbook में edit किया जाना चाहिए था।

यहाँ से यह पैटर्न और बढ़ता है। अगली playbook जो लिखने लायक है, वह उसी VPS पर WireGuard VPN स्थापित करती है और ufw rule को सख्त करती है ताकि SSH केवल tunnel पर ही जवाब दे; उसके बाद, एक ऐसी playbook जो हर app server पर Docker और Compose install करती है। जब site.yml तीन स्क्रीन से अधिक लंबा हो जाए, तो इसे roles में विभाजित करें, लेकिन उससे पहले नहीं।

विफलता के प्रकार और वे संदेश जो आपको दिखाई देंगे

Permission denied के साथ UNREACHABLE।

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

SSH ट्रांसपोर्ट किसी भी मॉड्यूल के चलने से पहले विफल हो गया: ansible_user गलत है, key को उस host पर कभी कॉपी नहीं किया गया था, या गलत key दी जा रही है। इसे सामान्य ssh root@10.0.0.10 के साथ reproduce करें, फिर यह देखने के लिए कि कौन सी keys दी गई थीं, ssh -v का उपयोग करें। यदि password SSH काम करता है लेकिन Ansible नहीं, तो आपने ssh-copy-id को छोड़ दिया है।

sudo password गायब है।

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

आपने become: true सेट किया, एक non-root user के रूप में कनेक्ट किया, और उस user को sudo के लिए password की आवश्यकता है। या तो कमांड लाइन में -K (--ask-become-pass) जोड़ें, या user को NOPASSWD sudoers प्रविष्टि दें, जो कि ठीक यही कारण है कि playbook आपके द्वारा उस पर स्विच करने से पहले deploy के लिए एक इंस्टॉल करती है।

error: externally-managed-environment। आपने Ubuntu 24.04 पर system Python के विरुद्ध pip चलाया। यह चरण 1 में कवर किया गया है: pip का नहीं, बल्कि pipx का उपयोग करें, और --break-system-packages का नहीं।

mapping values are not allowed in this context।

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

यह लगभग हमेशा indentation की समस्या होती है: गलत गहराई पर कोई key, या colon के बाद space का न होना। रिपोर्ट की गई line संख्या गलती के पास इंगित करती है, ठीक उस पर नहीं, इसलिए ऊपर वाली line की भी जाँच करें। इसके समान found character '\t' that cannot start any token का अर्थ है कि एक tab आ गया है; YAML में tab वर्जित हैं। हर रन से पहले ansible-playbook site.yml --syntax-check को एक आदत बना लें, और अपने editor को YAML के लिए दो-space indentation पर सेट करें।

/usr/bin/python3: not found। मानक Ubuntu 24.04 images पर यह दुर्लभ है, लेकिन minimal या netboot images पर सामान्य है: मॉड्यूल निष्पादन विफल हो जाता है क्योंकि target पर Python नहीं है। इसे raw मॉड्यूल के साथ bootstrap करें, यह एकमात्र ऐसा मॉड्यूल है जिसे दूसरी तरफ किसी चीज़ की आवश्यकता नहीं होती: ansible all -m raw -a "apt-get update && apt-get install -y python3" --become, फिर playbook को दोबारा चलाएं।

FAQ

क्या मुझे उन सर्वर्स पर Ansible इंस्टॉल करने की आवश्यकता है जिन्हें यह मैनेज करता है?

नहीं। Ansible agentless है: कंट्रोल मशीन SSH के माध्यम से छोटे Python मॉड्यूल्स भेजती है, उन्हें चलाती है और फिर हटा देती है। टारगेट मशीन पर केवल python3 और SSH एक्सेस की आवश्यकता होती है, जो कि स्टॉक Ubuntu इमेजेस में पहले से मौजूद होते हैं। इस पूरी गाइड में इंस्टॉलेशन केवल आपकी कंट्रोल मशीन पर ही होता है।

Ansible "Permission denied (publickey)" क्यों कहता है?

Permission denied (publickey) के साथ UNREACHABLE! ब्लॉक का मतलब है कि Ansible के कुछ भी चलाने से पहले SSH ऑथेंटिकेशन विफल हो गया। जांचें कि इन्वेंट्री में ansible_user उस अकाउंट से मेल खाता है जिसे आपने वास्तव में सेटअप किया है, कि आपने उस होस्ट पर ssh-copy-id चलाया है, और यह कि साधारण ssh user@host बिना पासवर्ड के लॉगिन हो जाता है। जो कुछ भी साधारण ssh कमांड को ठीक करता है, वही Ansible को भी ठीक करता है, क्योंकि दोनों एक ही ट्रांसपोर्ट का उपयोग करते हैं।

Ansible में idempotent का क्या अर्थ है?

एक टास्क किसी क्रिया को करने के बजाय एक वांछित स्थिति (desired state) घोषित करता है, जैसे "यह पैकेज मौजूद है", "यह लाइन इस फाइल में है"। यदि वह स्थिति पहले से मौजूद है, तो Ansible कुछ नहीं करता और changed के बजाय ok रिपोर्ट करता है। यही कारण है कि प्लेबुक को दो बार चलाने पर दूसरी बार changed=0 दिखाई देता है, और यही कारण है कि दोबारा चलाना एक जोखिम भरा री-इंस्टॉल होने के बजाय एक सुरक्षित ऑडिट होता है।

क्या मुझे Ubuntu 24.04 पर Ansible इंस्टॉल करने के लिए pip या pipx का उपयोग करना चाहिए?

pipx का। Ubuntu 24.04 सिस्टम Python को externally managed के रूप में चिह्नित करता है, इसलिए pip install ansible डिजाइन के अनुसार error: externally-managed-environment के साथ विफल हो जाता है। pipx install --include-deps ansible, Ansible को एक अलग virtualenv में रखता है और ansible, ansible-playbook और बाकी को आपके PATH पर सफाई से एक्सपोज करता है।

ansible और ansible-core पैकेज में क्या अंतर है?

ansible-core केवल इंजन और ansible.builtin मॉड्यूल्स का समूह है। ansible पैकेज में कोर के साथ-साथ क्यूरेटेड कम्युनिटी कलेक्शंस भी शामिल होते हैं, जिनमें ansible.posix (authorized_key मॉड्यूल) और community.general (ufw मॉड्यूल) शामिल हैं, जिनका उपयोग इस गाइड में किया गया है। पूर्ण पैकेज के साथ शुरुआत करें; केवल तभी कोर और चुनिंदा कलेक्शंस पर जाएं जब आपके पास ऐसा करने का कोई ठोस कारण हो।