Ubuntu 24.04 VPS साठी पहिले Ansible playbook

तुम्ही काय तयार करणार आहात

Ansible इन्स्टॉल केलेले एक control machine आणि stock image शिवाय इतर काहीही नसलेले एक किंवा अधिक नवीन Ubuntu 24.04 VPSes. शेवटी तुमच्याकडे सर्व्हरची नावे असलेली inventory file, authentication end-to-end कार्यरत असल्याचे सिद्ध करणारा ad-hoc ping आणि नवीन VPS साठीची संपूर्ण checklist code म्हणून चालवणारे playbook असेल: तुमच्या SSH key सह deploy user, hardened sshd, fail2ban, unattended upgrades आणि इतर सर्व गोष्टी नाकारण्यापूर्वी OpenSSH ला परवानगी देणारा firewall. हे एकाच सर्व्हरवर किंवा वीस सर्व्हरवर लागू करा. ते दोनदा चालवा. दुसऱ्या run मध्ये कोणताही बदल होणार नाही. हाच यामागचा मुख्य उद्देश आहे.

पंधरा वर्षे VPSes provision केल्यानंतर मला दिसणारा प्रत्यक्ष नमुना असा आहे: प्रत्येकजण पहिले पाच सर्व्हर manually सेट करतो. त्यानंतर सहाव्या सर्व्हरवर पूर्ण weekend खर्च होतो, कारण पहिल्या पाच सर्व्हरवर नेमके काय केले होते हे कोणालाही आठवत नसते. हे मार्गदर्शक अनेक Linux सर्व्हरचे व्यवस्थापन या विषयाचा अधिक सविस्तर आढावा घेते. तुम्ही तेव्हा हे मार्गदर्शक सुरू करा, जेव्हा तुम्ही एकच apt install तीन terminals मध्ये पुन्हा पुन्हा टाइप करत असल्याचे स्वतःच्या लक्षात येईल.

Ansible म्हणजे नेमके काय, एका परिच्छेदात

Ansible agentless आहे. ते व्यवस्थापित करत असलेल्या सर्व्हरवर कोणताही daemon स्थापित करण्याची गरज नसते. नियंत्रण मशीन सामान्य SSH द्वारे कनेक्ट होते, target वर एक छोटा Python module कॉपी करते, तो execute करते, त्याने छापलेला JSON वाचते आणि तो module हटवते. Target साठी आवश्यक असलेली एकमेव गोष्ट म्हणजे python3; प्रत्येक standard Ubuntu image मध्ये ती आधीपासून असते. येथे महत्त्वाचा शब्द idempotent आहे. त्याचा सरळ अर्थ असा: task कृतीचे नाही, तर state चे वर्णन करते. एखाद्या package साठी state: present याचा अर्थ “हे installed आहे याची खात्री करा” असा होतो; “installer चालवा” असा नाही. State आधीपासूनच योग्य असल्यास Ansible काहीही बदलत नाही आणि त्याची नोंद ok म्हणून करते, changed म्हणून नाही. हाच गुणधर्म या product चा केंद्रबिंदू आहे. यामुळे playbook पुन्हा चालवणे सुरक्षित होते आणि सुरक्षितपणे पुन्हा चालवता येणारे playbook shell script चे infrastructure मध्ये रूपांतर करते.

पूर्वअट, तसेच सुरुवातीपासून लक्षात ठेवण्याच्या महत्त्वाच्या बाबी

• एक control machine: तुमचा laptop किंवा छोटा VPS. येथे Ubuntu 24.04 गृहीत धरले आहे; Homebrew मधून pipx install केल्यानंतर macOS वरही हीच पद्धत कार्य करते.
• KVM वर Ubuntu 24.04 चालवणारे एक किंवा अधिक target VPS. ते root म्हणून प्रवेशयोग्य असावेत. त्यावर काहीही install केले जाणार नाही.
• प्रत्येक target साठी SSH key authentication आवश्यक आहे. Ansible ला तुमच्या ssh command प्रमाणेच authentication मिळते. ssh root@host password साठी prompt करत असल्यास Ansible अयशस्वी होतो.
• Ubuntu 24.04 वर pip install ansible हे error: externally-managed-environment मुळे बंद होते. हे जाणीवपूर्वक लागू केलेले distro policy आहे; हा बिघाड नाही. pipx वापरा.
• YAML मध्ये whitespace हा syntax चा भाग आहे. चुकीच्या indent मुळे mapping values are not allowed in this context निर्माण होते आणि कुठेही tab character असल्यास प्रक्रिया अयशस्वी होते.
• playbook sshd चे hardening करत असताना प्रत्येक target वर कार्यरत SSH session उघडे ठेवा. ग्राहकाला झालेल्या प्रत्येक lockout मधून पुनर्प्राप्ती करताना शेवटचे session बंद करून "clean वरून चाचणी" करण्यात आली होती.

पायथनऐवजी pipx वापरून नियंत्रण मशीनवर Ansible स्थापित करा

सहसा pip3 install ansible असा प्रयत्न केला जातो. पूर्णपणे नवीन 24.04 image वर ही पद्धत एक पायरी आधीच अपयशी ठरते: Command 'pip3' not found, but can be installed with: sudo apt install python3-pip. त्यानंतर pip स्थापित केल्यावर खरा अडथळा येतो:

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 बाहेरून व्यवस्थापित असल्याचे (PEP 668) नमूद केले आहे. त्यामुळे pip समान files साठी 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 आणि इतर scripts त्याच्या ansible-core dependency चे entry points आहेत. त्यामुळे हा flag नसल्यास pipx No apps associated with package ansible or its dependencies सह installation नाकारते. तसेच bare ansible-core ऐवजी ansible package स्थापित करा. पूर्ण package मध्ये community collections समाविष्ट असतात आणि या playbook मध्ये त्यांपैकी दोन collections मधील modules वापरले आहेत (ansible.posix आणि community.general).

ansible --version

योग्य परिणामाची सुरुवात ansible [core 2.19.x] सारख्या line ने होते आणि त्यात Ansible कोणत्या Python अंतर्गत चालते हे नमूद केलेले असते. येथे कोणतेही सध्याचे core release पुरेसे आहे. ansible: command not found याचा अर्थ ~/.local/bin अजून तुमच्या PATH मध्ये उपलब्ध नाही. नवीन shell उघडा किंवा source ~/.bashrc चालवा.

एवढीच संपूर्ण installation प्रक्रिया आहे. Target machines वर काहीही स्थापित केले जात नाही.

पायरी 2: प्रत्येक लक्ष्यावर SSH key द्वारे प्रवेश

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

ही एक ओळ दोन कामे करते: password शिवाय key auth कार्यरत असल्याची खात्री करते आणि host key ची नोंद known_hosts मध्ये करते. हे आत्ताच करा, कारण Ansible नोंद नसलेली host key run च्या मध्यभागी लपवलेल्या interactive prompt म्हणून दाखवते. त्यामुळे प्रक्रिया अडकली आहे असेच दिसते.

पायरी 3: inventory — सुरुवात INI पासून, वाढ झाल्यावर YAML

inventory ही Ansible ज्या मशीनवर काम करू शकते त्यांची यादी असलेली मजकूर फाइल आहे. नवीन project directory मध्ये inventory.ini तयार करा:

[vps]
web1 ansible_host=10.0.0.10
web2 ansible_host=10.0.0.20

[vps:vars]
ansible_user=root

web1 हे तुम्ही निवडलेले alias आहे. Output मध्ये तेच दिसते आणि --limit web1 सोबत target म्हणून तेच वापरता. ansible_host हा प्रत्यक्ष address आहे. [vps] हा group आहे. [vps:vars] त्यातील प्रत्येक host साठी variables सेट करते; ansible_user या account ने Ansible login करते. त्याच्या शेजारी ansible.cfg जोडा, म्हणजे तुम्हाला पुन्हा -i टाइप करावे लागणार नाही:

[defaults]
inventory = inventory.ini

Ansible सध्याच्या directory मधून ansible.cfg वाचते. हीच inventory YAML मध्ये तयार करून inventory.yml या नावाने save करा आणि त्याऐवजी ansible.cfg ला त्या नावाकडे निर्देशित करा. प्रत्येक host सोबत अनेक variables असतील तेव्हा ही पद्धत अधिक उपयुक्त ठरेल:

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

दोन्ही पद्धती समतुल्य आहेत. दोन servers असताना INI पटकन समजते. वीस servers असताना YAML अधिक चांगल्या प्रकारे विस्तारते. एक पद्धत निवडा आणि त्याबद्दल पुन्हा विचार करू नका.

पायरी 4: ad-hoc commands, सर्वकाही कार्यरत असल्याचे दर्शवणारा हिरवा pong

ansible all -m ping

हा ICMP नाही. ping module ही संपूर्ण चाचणी आहे: SSH login, module copy, target वरील Python execution आणि cleanup. योग्य परिणाम हिरव्या रंगात दिसतो आणि प्रत्येक 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 अयशस्वी झाले. अचूक string आणि त्यावरील उपाय खालील failure modes section मध्ये दिले आहेत. आणखी दोन उपयुक्त ad-hoc commands:

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

ad-hoc commands एकदाच करायच्या कृती आणि तपासण्यांसाठी वापरा. एखादी कृती दोनदा करावी लागणार असेल, तर ती playbook मध्ये असली पाहिजे.

पायरी 5: पहिले playbook, code म्हणून नवीन VPS तपासणी सूची

नवीन सर्व्हरवर पहिल्या दहा मिनिटांत तुम्ही हाताने कराल त्या सर्व कृती येथे आहेत. हे 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 brace ने सुरू होत असल्यास संपूर्ण expression ला quote करा; अन्यथा YAML parser त्याचा चुकीचा अर्थ लावू शकतो. lookup('file', ...) runtime वेळी control मशीनवरील public key वाचते. त्यामुळे playbook मध्ये key material समाविष्ट होत नाही.

The loop. loop: "{{ baseline_services }}" प्रत्येक item साठी service task एकदा चालवते आणि output मध्ये प्रत्येक item स्वतंत्र ओळीवर दाखवते. apt task मात्र संपूर्ण package list एकाच वेळी घेते. एकच apt transaction अधिक जलद असतो आणि packages साठी हीच preferred पद्धत आहे. Loops चा वापर प्रत्यक्षात एका वेळी एकाच गोष्टीवर काम करणाऱ्या modules साठी करावा.

The handler ही अंतर्भूत करून घेण्यासारखी संकल्पना आहे. notify: Restart ssh चा अर्थ "ssh आत्ताच restart करा" असा नाही. तो handler ला queue मध्ये ठेवतो. हा handler play च्या शेवटी एकदाच चालतो आणि notifying task ने प्रत्यक्षात changed नोंदवले असल्यासच चालतो. उद्या playbook पुन्हा चालवा: drop-in file आधीच योग्य असल्याने copy task ok नोंदवते आणि sshd पुन्हा सुरू केला जात नाही. validate: ओळ trigger वरील safety आहे. sshd जुनी file बदलण्यापूर्वी तिची तपासणी करते. त्यामुळे typo असल्यास task अयशस्वी होतो; daemon बंद पडत नाही.

PermitRootLogin prohibit-password, no नाही, जाणीवपूर्वक. हे playbook key वापरून root म्हणून login करते. prohibit-password password द्वारे होणारे root logins बंद करते आणि तुमचे सध्याचे login सुरू ठेवते. deploy user सिद्ध झाल्यानंतर (ssh deploy@10.0.0.10 sudo true, म्हणजे plain address, कारण web1 हा फक्त Ansible ला माहीत असलेला alias आहे), inventory मध्ये ansible_user=deploy वर बदला आणि नंतरच्या run मध्ये ते no पर्यंत अधिक सुरक्षित करा. तुम्हाला server पासून lock out होणार नाही अशा क्रमाने hardening करा.

00- prefix महत्त्वाचा आहे. बहुतेक keywords साठी sshd त्याला parse करताना आढळणारी पहिली occurrence स्वीकारते. Ubuntu चे sshd_config स्वतःच्या body आधी lexical order मध्ये sshd_config.d/*.conf समाविष्ट करते. Ubuntu 24.04 cloud images मध्ये त्या directory मध्ये आधीच 60-cloudimg-settings.conf असते. cloud-init द्वारे password logins सक्षम करणारे providers 50-cloud-init.conf मध्ये PasswordAuthentication yes समाविष्ट करतात. आमच्या file ला 00-hardening.conf असे नाव दिल्याने ती सर्वप्रथम sort होते आणि दोन्हींवर लागू होते.

Task order ही firewall safety आहे. Allow OpenSSH, deny policy असलेल्या Enable ufw आधी चालते. Ansible tasks सूचीमध्ये दिलेल्या क्रमानेच चालवते. त्यामुळे wall लागू होण्यापूर्वी hole उपलब्ध असतो. येथे उपयुक्त होण्यासाठी fail2ban साठी configuration आवश्यक नाही. त्याची Ubuntu defaults sshd वर सुरुवातीपासून लक्ष ठेवतात. Jails प्रत्यक्षात काय करतात आणि कोणत्या settings tune कराव्यात, हे Ubuntu 24.04 वरील fail2ban मार्गदर्शक मध्ये दिले आहे.

पायरी 6: --check सह dry run करा, त्यानंतर प्रत्यक्ष चालवा

ansible-playbook site.yml --check

Check mode कनेक्ट होते, playbook काय करेल याची गणना करते आणि कोणताही बदल करत नाही. तळाशी असलेल्या PLAY RECAP मधील changed= संख्या वाचा. प्रत्येक host मध्ये बदल करणाऱ्या tasks ची ही संख्या असते. एक महत्त्वाची मर्यादा लक्षात ठेवा: एखादे पुढील task आधीच्या task ने केलेल्या बदलांवर अवलंबून असल्यास check mode ची संरचनात्मक मर्यादा असते. Ubuntu च्या standard server image मध्ये ufw आधीपासून उपलब्ध असते. त्यामुळे हा playbook dry run मध्ये सुरळीत चालतो. मात्र ufw नसलेल्या minimal image मध्ये check mode मध्ये ufw tasks अयशस्वी होतात. कारण check mode package प्रत्यक्ष install करत नाही आणि त्यानंतर module कडे call करण्यासाठी काहीही उपलब्ध राहत नाही. ही dry run ची मर्यादा आहे; तुमच्या playbook मधील त्रुटी नाही. योजना योग्य दिसत असल्यास:

ansible-playbook site.yml

प्रत्येक task प्रत्येक host साठी एक ओळ दाखवते: yellow changed, green 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

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

पायरी 7: ते दोनदा चालवा; idempotence कशी दिसते

तीच command लगेच पुन्हा चालवा:

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

changed=0 आणि ok प्रत्येकी एकाने कमी झाले, कारण notification न झालेला handler कधीच चालला नाही. काहीही पुन्हा install झाले नाही, sshd पुन्हा सुरू झाले नाही आणि ufw मध्ये कोणताही बदल झाला नाही. त्यामुळे playbook हे provisioner इतकेच audit म्हणूनही काम करते: पुढील महिन्यात inventory मध्ये web3 जोडा आणि ते पुन्हा चालवा. नवीन box तयार होईल आणि जुन्या boxes ची पडताळणी केली जाईल. तुम्ही हाताळलेला नसलेल्या box वरचा शून्येतर changed म्हणजे drift आहे. playbook मध्ये संपादित केले पाहिजे असलेले काहीतरी कोणीतरी manually संपादित केले आहे, हे त्यावरून कळते.

यापुढे ही पद्धत विस्तारत जाते. पुढील उपयुक्त playbook म्हणजे त्याच VPS वर WireGuard VPN स्थापित करणे आणि ufw नियम अधिक कडक करून SSH ने फक्त tunnel वरूनच प्रतिसाद द्यावा अशी व्यवस्था करणे. त्यानंतर प्रत्येक app server वर Docker आणि Compose स्थापित करणारे playbook लिहा. site.yml तीन screens पेक्षा मोठे झाल्यावर ते roles मध्ये विभागा; त्यापूर्वी नाही.

तुम्हाला दिसणाऱ्या त्रुटींसह अपयशाच्या स्थिती

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
}

कोणतेही module चालण्यापूर्वी SSH transport अयशस्वी झाला: ansible_user चुकीचे आहे, key त्या host वर कधीही कॉपी केली गेली नाही किंवा चुकीची key वापरली जात आहे. साध्या ssh root@10.0.0.10 ने पुन्हा प्रयत्न करा. त्यानंतर कोणत्या 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 आवश्यक आहे. Command line मध्ये -K (--ask-become-pass) जोडा किंवा त्या user साठी NOPASSWD sudoers entry द्या. म्हणूनच playbook, तुम्ही deploy वर switch करण्यापूर्वीच, त्यासाठी एक entry install करते.

error: externally-managed-environment. तुम्ही Ubuntu 24.04 वरील system Python विरुद्ध pip चालवले. याचे निराकरण step 1 मध्ये दिले आहे: pipx वापरा, pip नाही आणि --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 number नेमकी चूक दर्शवत नाही; तो चुकाच्या जवळचा भाग दर्शवतो. त्यामुळे त्याच्या आधीची line देखील तपासा. यासारखीच त्रुटी found character '\t' that cannot start any token म्हणजे tab वापरला गेला आहे; YAML मध्ये tab वापरण्यास परवानगी नाही. प्रत्येक run पूर्वी ansible-playbook site.yml --syntax-check चालवण्याची सवय लावा आणि YAML साठी editor मध्ये two-space indentation सेट करा.

/usr/bin/python3: not found. Standard Ubuntu 24.04 images मध्ये ही त्रुटी क्वचितच आढळते. Minimal किंवा netboot images मध्ये ती सामान्य आहे. Target वर Python नसल्यामुळे module execution अयशस्वी होते. raw module वापरून ते bootstrap करा. हा far side वर कोणत्याही गोष्टीवर अवलंबून नसलेला एकमेव module आहे: ansible all -m raw -a "apt-get update && apt-get install -y python3" --become. त्यानंतर playbook पुन्हा चालवा.

FAQ

Ansible व्यवस्थापित करत असलेल्या सर्व्हरवर ते स्थापित करणे आवश्यक आहे का?

नाही. Ansible agentless आहे: control machine लहान Python modules SSH द्वारे पाठवते, ते चालवते आणि नंतर काढून टाकते. Target वर फक्त python3 आणि SSH access आवश्यक आहे. Stock Ubuntu images मध्ये हे दोन्ही आधीपासून उपलब्ध असतात. या संपूर्ण मार्गदर्शिकेत एकमेव installation तुमच्या control machine वर होते.

Ansible मध्ये "Permission denied (publickey)" असे का दिसते?

UNREACHABLE! block मधील Permission denied (publickey) याचा अर्थ Ansible ने काहीही चालवण्यापूर्वी SSH authentication अयशस्वी झाले आहे. Inventory मधील ansible_user तुम्ही प्रत्यक्षात तयार केलेल्या account शी जुळते का ते तपासा. त्या host वर ssh-copy-id चालवले आहे का ते तपासा. तसेच plain ssh user@host password न विचारता login करते का ते तपासा. Plain ssh command दुरुस्त केल्यावर Ansible देखील दुरुस्त होते, कारण दोन्ही समान transport वापरतात.

Ansible मध्ये idempotent याचा अर्थ काय?

Task मध्ये करावयाची action नव्हे, तर अपेक्षित state घोषित केली जाते: "हे package उपस्थित आहे" किंवा "ही line या file मध्ये आहे". State आधीपासूनच योग्य असल्यास Ansible काहीही करत नाही आणि changed ऐवजी ok नोंदवते. त्यामुळे playbook दुसऱ्यांदा चालवल्यावर changed=0 दिसते. पुन्हा चालवणे धोकादायक reinstall न राहता सुरक्षित audit ठरते.

Ubuntu 24.04 वर Ansible स्थापित करण्यासाठी pip किंवा pipx वापरावे का?

pipx वापरा. Ubuntu 24.04 मध्ये system Python externally managed म्हणून चिन्हांकित केलेले आहे. त्यामुळे pip install ansible हे डिझाइननुसार error: externally-managed-environment सह अयशस्वी होते. pipx install --include-deps ansible Ansible एका isolated virtualenv मध्ये ठेवते आणि ansible, ansible-playbook तसेच इतर commands तुमच्या PATH मध्ये व्यवस्थित उपलब्ध करून देते.

ansible आणि ansible-core packages मध्ये काय फरक आहे?

ansible-core हे engine असून त्यात फक्त ansible.builtin modules असतात. ansible package मध्ये core सोबत निवडक community collections समाविष्ट असतात. त्यात ansible.posix (authorized_key module) आणि community.general (ufw module) यांचा समावेश आहे; या दोन्हींचा वापर या मार्गदर्शिकेत केला आहे. सुरुवातीला पूर्ण package वापरा. विशिष्ट कारण असेल तेव्हाच core सोबत स्वतः निवडलेल्या collections वापरून installation लहान करा.