Ansible tutorial: VPS साठी पहिला playbook

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

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

पंधरा वर्षे VPS provision करण्याची प्रयोगाची माहिती असल्याने मी तुम्हाला एक वास्तव सांगू शकतो: प्रत्येकजण पहिले पाच सर्व्हर मॅन्युअली सेट करतो, आणि सहाव्या सर्व्हरसाठी पूर्ण वीकेंड वाया घालवतो कारण कोणालाही पहिल्या पाच सर्व्हरवर काय केले होते ते आठवत नाही. हा मार्गदर्शक managing multiple Linux servers मधील माहिती अधिक सखोल करतो — ज्या दिवशी तुम्हाला तीन वेगवेगळ्या terminals मध्ये एकच apt install टाईप करताना आढळेल, त्याच दिवशी हे वाचा.

Ansible नक्की काय आहे, एका परिच्छेदात

Ansible हे agentless आहे. ज्या सर्व्हर्सचे व्यवस्थापन ते करते, त्यावर कोणतेही daemon इन्स्टॉल करण्याची गरज नसते: control machine सामान्य SSH द्वारे कनेक्ट होते, target वर एक लहान Python module कॉपी करते, ते execute करते, त्यातून मिळणारा JSON डेटा वाचते आणि नंतर ते module डिलीट करते. target साठी फक्त python3 असणे आवश्यक आहे, जे प्रत्येक stock Ubuntu image मध्ये आधीपासूनच असते. idempotent हा सर्वात महत्त्वाचा शब्द आहे, याचा साधा अर्थ असा आहे: एखादे task ही एक state (स्थिती) दर्शवते, कोणतीही action (कृती) नाही. एखाद्या package साठी state: present याचा अर्थ "हे इन्स्टॉल असल्याची खात्री करा" असा होतो, "installer रन करा" असा नाही. जर ती state आधीच अस्तित्वात असेल, तर Ansible काहीही बदल करत नाही आणि changed ऐवजी ok असा रिपोर्ट देते. हे गुणधर्मच या उत्पादनाचे मुख्य वैशिष्ट्य आहे — यामुळेच playbook पुन्हा पुन्हा रन करणे सुरक्षित ठरते, आणि सुरक्षित पुनरावृत्तीमुळेच (reruns) shell script चे रूपांतर infrastructure मध्ये होते.

Prerequisites, and the gotchas up front

• एक control machine: तुमचा laptop किंवा एखादा लहान VPS. मी Ubuntu 24.04 गृहीत धरत आहे; Homebrew मधून pipx install केल्यानंतर macOS वर देखील हे सारख्याच पद्धतीने काम करते.
• एक किंवा अधिक target VPSes जे KVM वर Ubuntu 24.04 चालवत आहेत आणि root म्हणून एक्सेस करता येतात. त्यावर काहीही install केले जाणार नाही.
• प्रत्येक target साठी SSH key authentication. Ansible ची authentication प्रक्रिया तुमच्या ssh कमांड सारखीच असते — जर ssh root@host ने password विचारला, तर Ansible fail होईल.
• Ubuntu 24.04 वर, pip install ansible error: externally-managed-environment मुळे बंद होतो. हे डिस्ट्रोचे (distro) मुद्दाम केलेले धोरण आहे, त्रुटी नाही. pipx वापरा.
• YAML मधील whitespace हा syntax आहे. चुकीच्या indentation मुळे mapping values are not allowed in this context येतो, आणि कुठेही tab character वापरल्यास प्रक्रिया थांबते.
• Playbook द्वारे sshd harden करत असताना प्रत्येक target वर एक SSH session उघडी ठेवा. मी ग्राहकांना रिकव्हर करण्यास मदत केलेल्या प्रत्येक lockout मध्ये, "to test from clean" साठी शेवटचे session बंद करणे आवश्यक होते.

Step 1: pip ऐवजी pipx वापरून control machine वर Ansible install करा

pip3 install ansible वापरणे ही एक जुनी पद्धत आहे. जर तुम्ही एकदम नवीन 24.04 image वापरत असाल आणि Command 'pip3' not found, but can be installed with: sudo apt install python3-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 ला 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

PATH मध्ये बदल लागू होण्यासाठी pipx ensurepath नंतर नवीन shell उघडा. --include-deps ही केवळ सजावट नाही: ansible पॅकेजमध्ये स्वतःचे कोणतेही console scripts नसतात — ansible, ansible-playbook आणि इतर सर्व हे त्याच्या ansible-core dependency चे entry points आहेत — त्यामुळे flag शिवाय pipx No apps associated with package ansible or its dependencies एररसह installation नाकारते. आणि फक्त ansible-core ऐवजी ansible पॅकेज install करा — पूर्ण पॅकेजमध्ये community collections समाविष्ट असतात, आणि या playbook मध्ये त्यातील दोन (ansible.posix आणि community.general) मॉड्यूल्सचा वापर केला आहे.

ansible --version

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

ही पूर्ण installation प्रक्रिया आहे. target machines वर काहीही install करण्याची गरज नाही.

Step 2: SSH key access to every target

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

या एका ओळीमुळे दोन कामे पूर्ण होतात: first, key authentication पासवर्डशिवाय काम करते की नाही याची खात्री होते, आणि second, host key known_hosts मध्ये record होते. हे आताच पूर्ण करा, कारण जर host key record नसेल, तर Ansible रनच्या मध्ये interactive prompt दाखवते. यामुळे प्रक्रिया थांबल्यासारखी (hang) वाटते.

Step 3: inventory — सुरुवातीला INI वापरा, विस्तार झाल्यावर YAML वापरा

Inventory ही एक text file आहे ज्यामध्ये Ansible द्वारे हाताळल्या जाणाऱ्या machines ची यादी असते. नवीन 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 वापरताना हेच नाव दिसेल. ansible_host हा प्रत्यक्ष address आहे. [vps] हा एक group आहे, आणि [vps:vars] त्या group मधील प्रत्येक host साठी variables सेट करते; ansible_user हे Ansible कडून वापरले जाणारे login user आहे. याच्या शेजारी, -i पुन्हा टाईप करण्याची गरज पडू नये म्हणून ansible.cfg वापरा:

[defaults]
inventory = inventory.ini

Ansible current directory मधून ansible.cfg वाचते. YAML मधील समान inventory — ते inventory.yml नावाने सेव्ह करा आणि ansible.cfg मध्ये त्या नावाचा संदर्भ द्या — जेव्हा प्रत्येक host कडे अनेक variables असतील तेव्हा तुम्हाला ते अधिक सोयीचे वाटेल:

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

हे दोन्ही equivalent आहेत. दोन servers साठी INI पाहण्यास सोपे आहे; 20 servers साठी YAML अधिक चांगले काम करते. यापैकी एक निवडा आणि पुढील विचार करणे थांबवा.

Step 4: ad-hoc commands — the green pong that proves everything

ansible all -m ping

हे ICMP नाही. ping module हे पूर्ण चाचणी (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 fail झाला आहे; अचूक error string आणि उपाय खालील failure modes विभागात दिले आहेत. इतर दोन महत्त्वाचे ad-hoc commands:

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

Ad-hoc चा वापर एकदाच करायच्या (one-offs) किंवा तपासणीसाठी (checks) करा. जी कोणतीही command तुम्हाला दोनदा रन करावी लागते, ती playbook मध्ये असावी.

Step 5: पहिले playbook — new-VPS checklist as code

नवीन सर्व्हरवर पहिल्या 10 मिनिटांत तुम्ही मॅन्युअली (by hand) जी कामे कराल, ती सर्व यात समाविष्ट आहेत. हे 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 }}" ने संदर्भित केले जाते — जर व्हॅल्यू { ने सुरू होत असेल, तर संपूर्ण एक्सप्रेशन कोटेशन मार्क्समध्ये लिहा, अन्यथा YAML पार्सर चुकीचा अर्थ लावू शकतो. lookup('file', ...) रनटाइममध्ये control मशीनवरून तुमची public key वाचते, त्यामुळे playbook मध्ये कोणतीही key सामग्री नसते.

The loop. loop: "{{ baseline_services }}" प्रत्येक आयटमसाठी सर्व्हिस टास्क एकदा चालवते आणि आउटपुटमध्ये प्रत्येक आयटम स्वतंत्र ओळीवर दिसतो. लक्षात घ्या की apt टास्क संपूर्ण पॅकेज लिस्ट एकाच वेळी घेतो — एक apt ट्रान्झॅक्शन वेगाने पूर्ण होते आणि पॅकेजेससाठी हाच योग्य पॅटर्न आहे; loops हे अशा मॉड्यूल्ससाठी आहेत जे खरोखर एका वेळी एकाच गोष्टीवर काम करतात.

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

PermitRootLogin prohibit-password, no नाही — जाणीवपूर्वक. हे playbook की (key) वापरून root म्हणून लॉग इन करते. prohibit-password तुमची की चालू ठेवून root password लॉगिन बंद करते. एकदा deploy युजरची खात्री झाली (ssh deploy@10.0.0.10 sudo true — साधा पत्ता, कारण web1 हा फक्त Ansible ला माहित असलेला alias आहे), की inventory मध्ये ansible_user=deploy बदला आणि नंतरच्या रनमध्ये ते no पर्यंत कडक करा. अशा क्रमाने hardening करा ज्यामुळे तुम्ही सर्व्हरपासून वेगळे (strand) पडणार नाही.

00- प्रीफिक्स महत्त्वाचा आहे. बहुतेक कीवर्ड्ससाठी sshd पहिल्या आढळलेल्या कीवर्डचा मान घेते, आणि Ubuntu च्या sshd_config मध्ये त्याच्या स्वतःच्या बॉडीच्या आधी लेक्सिकल ऑर्डरमध्ये sshd_config.d/*.conf समाविष्ट असते. Ubuntu 24.04 cloud images मध्ये त्या डिरेक्टरीमध्ये आधीच 60-cloudimg-settings.conf असते, आणि cloud-init द्वारे password लॉगिन सक्षम करणारे प्रोव्हायडर्स PasswordAuthentication yes सह 50-cloud-init.conf जोडतात; आपले नाव 00-hardening.conf ठेवल्यामुळे ते आधी सॉर्ट होते आणि दोन्हीवर मात करते.

Task order ही firewall सुरक्षा आहे. Allow OpenSSH हे Enable ufw च्या आधी 'deny' पॉलिसीसह चालते — Ansible टास्क दिलेल्या क्रमानेच कार्यान्वित करते, त्यामुळे भिंत उभारण्यापूर्वीच तो पोर्ट (hole) उघडा असतो. fail2ban ला येथे उपयुक्त ठरण्यासाठी कोणत्याही कॉन्फिगरेशनची गरज नाही; त्याचे Ubuntu डिफॉल्ट्स थेट sshd वर लक्ष ठेवतात, आणि jails प्रत्यक्षात काय करतात — आणि काय ट्यून करायचे — हे fail2ban on Ubuntu 24.04 guide मध्ये दिले आहे.

Step 6: --check वापरून dry run करा, त्यानंतर प्रत्यक्ष रन करा

ansible-playbook site.yml --check

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

ansible-playbook site.yml

प्रत्येक task प्रत्येक 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 आणि आठ tasks आणि handler मिळून एकूण संख्या आहे. तुमची changed माझ्यापेक्षा एक किंवा दोन ने वेगळी असू शकते: Ubuntu च्या standard image मध्ये ufw आणि unattended-upgrades आधीपासून असतात, आणि apt ने इंस्टॉल केल्याबरोबर fail2ban स्वतः सुरू होते, त्यामुळे एखादा task त्याच्या पहिल्याच run मध्ये ok रिपोर्ट करू शकतो — कारण तो state आधीच अस्तित्वात असतो. unreachable आणि failed या संख्या शून्य असणे आवश्यक आहे. become: true बद्दल एक टीप: तुम्ही root म्हणून कनेक्ट होत असताना ही केवळ एक औपचारिकता आहे, परंतु जसे तुम्ही ansible_user बदलून deploy कराल, तसे sudo प्रभावी होते — आणि हा playbook इंस्टॉल करणारी NOPASSWD sudoers file, -K तुमच्या command line वर येऊ देत नाही. त्याशिवाय तुम्हाला Missing sudo password येईल, ज्याबद्दल खाली माहिती दिली आहे.

Step 7: run it twice — what idempotence looks like

तोच command लगेच पुन्हा रन करा:

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 जोडा आणि पुन्हा rerun करा — नवीन box तयार होईल आणि जुने boxes verify होतील. ज्या box ला तुम्ही स्पर्श केला नाही, तिथे nonzero changed दिसणे म्हणजे drift आहे; याचा अर्थ असा की ज्या गोष्टी playbook मध्ये बदलल्या पाहिजे होत्या, त्या कोणीतरी manual पद्धतीने बदलल्या आहेत.

येथून पुढे ही पद्धत अधिक प्रभावी होते. पुढचा playbook लिहिताना WireGuard VPN on the same VPS सेट करा आणि ufw rule अधिक कडक करा जेणेकरून SSH फक्त tunnel वरून प्रतिसाद देईल; त्यानंतर, प्रत्येक app server वर Docker and Compose install करणारा playbook लिहा. जेव्हा site.yml तीन screens पेक्षा जास्त लांब जाईल, तेव्हा त्याला roles मध्ये विभाजित करा — पण त्याआधी नाही.

Failure modes, with the strings you will see

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 वापरली जात आहे. हे तपासण्यासाठी आधी plain ssh root@10.0.0.10 वापरा, त्यानंतर ssh -v वापरा जेणेकरून कोणत्या keys offered झाल्या आहेत ते समजेल. जर password SSH काम करत असेल पण Ansible काम करत नसेल, तर तुम्ही ssh-copy-id वगळले आहे.

Missing 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 साठी आधीच एक entry इंस्टॉल केली जाते.

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 चुकीच्या depth वर आहे, किंवा colon नंतर space दिलेला नाही. रिपोर्ट केलेली line number चुकीच्या ठिकाणी असू शकते — त्यावरील line देखील तपासा. found character '\t' that cannot start any token चा अर्थ असा आहे की तिथे tab वापरला गेला आहे; YAML मध्ये tabs वापरण्यास मनाई आहे. प्रत्येक run करण्यापूर्वी ansible-playbook site.yml --syntax-check करण्याची सवय करा, आणि तुमच्या editor मध्ये YAML साठी two-space indentation सेट करा.

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

FAQ

मला ज्या सर्व्हर्सना मॅनेज करायचे आहे, त्यावर Ansible इन्स्टॉल करण्याची गरज आहे का?

नाही. Ansible हे agentless आहे: कंट्रोल मशीन SSH द्वारे लहान Python modules पाठवते, ते रन करते आणि नंतर काढून टाकते. टार्गेट मशीनला फक्त python3 आणि SSH ॲक्सेसची आवश्यकता असते, जे दोन्ही गोष्टी stock Ubuntu images मध्ये आधीपासूनच असतात. या संपूर्ण गाईडमध्ये फक्त तुमच्या कंट्रोल मशीनवर इन्स्टॉलेशन करणे आवश्यक आहे.

Ansible मध्ये "Permission denied (publickey)" असा एरर का येतो?

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

Ansible मध्ये idempotent म्हणजे काय?

Task एखादी कृती करण्याऐवजी अपेक्षित state घोषित करते — उदा. "हा package उपस्थित आहे" किंवा "ही line या file मध्ये आहे". जर ती state आधीच अस्तित्वात असेल, तर Ansible काहीही करत नाही आणि changed ऐवजी ok रिपोर्ट करते. म्हणूनच playbook दोनदा रन केल्यास दुसऱ्यांदा changed=0 दिसते, आणि पुन्हा रन करणे हे जोखमीचे re-install करण्याऐवजी एक सुरक्षित audit असते.

Ubuntu 24.04 वर Ansible इन्स्टॉल करण्यासाठी मी pip किंवा pipx वापरावे?

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

ansible आणि ansible-core पॅकेजेस मधील फरक काय आहे?

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