Ansible मध्ये unreachable hosts कसे इग्नोर करावे?

Unreachable host म्हणजे अयशस्वी टास्क नव्हे

Ansible मध्ये unreachable hosts कडे दुर्लक्ष करण्यासाठी तुम्ही ignore_unreachable: true सेट करता आणि हा स्विच कार्य करतो. हे कधी वापरावे हे समजून घेणे महत्त्वाचे आहे, कारण Ansible दोन वेगवेगळ्या समस्या दोन वेगवेगळ्या प्रकारे हाताळते. होस्टवर रन झालेला आणि एरर दिलेला टास्क म्हणजे failure होय. ज्या होस्टशी Ansible अजिबात कनेक्ट होऊ शकले नाही, तो unreachable असतो. ignore_errors फक्त पहिल्या प्रकारच्या समस्येसाठी आहे. ignore_unreachable फक्त दुसऱ्या प्रकारच्या समस्येसाठी आहे.

प्ले रिकॅपमधील फरक खालीलप्रमाणे आहे.

PLAY RECAP *********************************************************************
web1  : ok=7  changed=2  unreachable=0  failed=0  skipped=0  rescued=0  ignored=0
web2  : ok=0  changed=0  unreachable=1  failed=0  skipped=0  rescued=0  ignored=0

Ansible ने web1 शी कनेक्ट करून सात टास्क रन केले. web2 मध्ये unreachable=1 आणि failed=0 दिसतात, याचा अर्थ त्यावर काहीही रन झाले नाही. Ansible ला कनेक्शन मिळालेच नाही, म्हणून त्याने त्या होस्टला प्ले मधून काढून टाकले आणि उर्वरित काम सुरू ठेवले. जर तो प्ले सिक्युरिटी अपडेट इन्स्टॉल करत असेल, तर तुमच्या सर्व्हरपैकी एकावर ते अपडेट नाही.

होस्ट पोहोचण्यायोग्य का नसतो

'Unreachable' म्हणजे कोणत्याही मॉड्यूलने होस्टशी संपर्क साधण्यापूर्वीच कनेक्शन अयशस्वी झाले आहे. वाचण्यासाठी कोणताही मॉड्यूल आउटपुट उपलब्ध नसतो, फक्त एक कनेक्शन एरर दिसते आणि ती मशीनला स्पर्श करणाऱ्या पहिल्याच टास्कवर येते.

fatal: [web2]: UNREACHABLE! => {"changed": false, "msg": "Failed to connect to the host via ssh: ssh: connect to host 203.0.113.20 port 22: Connection refused", "unreachable": true}

msg फील्डमध्ये मूळ कारण दिलेले असते. तुम्हाला खालीलपैकी काही एरर्स दिसू शकतात:

• Connection refused: TCP कनेक्शन नाकारले गेले आहे, याचा अर्थ त्या पोर्टवर काहीही सुरू नाही. sshd बंद आहे किंवा SSH दुसऱ्या पोर्टवर हलवले आहे आणि तुमच्या इन्व्हेंटरीमध्ये अजूनही 22 पोर्ट नमूद आहे.
• Connection timed out: कशाकडूनही प्रतिसाद मिळालेला नाही. फायरवॉल पॅकेट्स ड्रॉप करत आहे किंवा सर्व्हर बंद आहे. प्रत्येक प्रयत्नासाठी पूर्ण कनेक्शन टाइमआउट लागतो, जो डीफॉल्टनुसार 10 सेकंद असतो.
• Host key verification failed.: ~/.ssh/known_hosts मधील की सर्व्हरने सादर केलेल्या कीशी जुळत नाही. रीबिल्ट केलेल्या VPS चा IP ॲड्रेस तोच राहतो पण होस्ट की बदलते, त्यामुळे री-इन्स्टॉलेशननंतर हे अपेक्षित आहे, परंतु इतर वेळी हे गंभीर मानले जाते.
• Permission denied (publickey): SSH ने प्रतिसाद दिला पण तुमची की नाकारली. पोर्ट व्यवस्थित आहे, त्यामुळे ही ऑथेंटिकेशनची समस्या आहे, सहसा चुकीचा ansible_user किंवा लोड न केलेली की हे याचे कारण असते.
• Timeout (12s) waiting for privilege escalation prompt: कनेक्शन यशस्वी झाले पण become अयशस्वी झाले. sudo पासवर्डची वाट पाहत आहे जो कधीच मिळत नाही.

Python इंटरप्रिटर गहाळ असणे हे या यादीतील अपेक्षित कारण मानले जाते, परंतु ते यात येत नाही. SSH कनेक्ट होते, याचा अर्थ होस्ट पोहोचण्यायोग्य आहे. त्यानंतर मॉड्यूल चालवण्यासाठी तिथे काहीही उपलब्ध नसते:

fatal: [db1]: FAILED! => {"changed": false, "module_stdout": "/bin/sh: 1: /usr/bin/python3: not found\r\n", "msg": "The module failed to execute correctly, you probably need to set the interpreter", "rc": 127}

ती ओळ FAILED! असे दर्शवते आणि रिकॅपमध्ये ती failed अंतर्गत मोजली जाते, त्यामुळे ignore_unreachable त्याला कधीही स्पर्श करणार नाही. त्या होस्टसाठी ansible_python_interpreter सेट करा किंवा त्यावर python3 इन्स्टॉल करा.

प्लेमध्ये पोहोचता न येणारे (unreachable) होस्ट कसे दुर्लक्षित करावे

टास्क स्तरावर, हे कीवर्ड मॉड्यूलच्या बाजूला वापरले जाते:

- name: Read the package list, and do not stop if the host is down
  ansible.builtin.command: dpkg -l
  register: packages
  changed_when: false
  ignore_unreachable: true

प्ले स्तरावर हे प्लेमधील प्रत्येक टास्कसाठी डीफॉल्ट सेट करते आणि एखादा विशिष्ट टास्क ते पुन्हा बदलू शकतो:

- name: Opportunistic fleet maintenance
  hosts: all
  ignore_unreachable: true
  tasks:
    - name: This runs, cannot connect, and the play carries on
      ansible.builtin.ping:

    - name: This one still ends the play for a host that is down
      ansible.builtin.ping:
      ignore_unreachable: false

यामागे काय बदल घडतात हे जाणून घेणे महत्त्वाचे आहे. जेव्हा ignore_unreachable सेट केलेले असते, तेव्हा होस्टला प्लेमधून काढून टाकले जात नाही. त्यामुळे, त्यानंतरचा प्रत्येक टास्क पुन्हा कनेक्ट करण्याचा प्रयत्न करतो आणि त्याच प्रकारे अपयशी ठरतो. यातील प्रत्येक प्रयत्न कनेक्शन टाइमआउटपर्यंत वाट पाहतो, जोपर्यंत तुम्ही ansible.cfg मधील timeout बदलत नाही तोपर्यंत तो 10 सेकंद असतो. एका मृत सर्व्हरवर वीस टास्कचा प्ले चालवल्यास रनच्या वेळेत सुमारे 200 सेकंद वाढतात आणि लॉगमध्ये वीस लाल ओळी दिसतात.

त्यामुळे, एकदा तपासा आणि त्यानंतर त्या होस्टला व्यवस्थित थांबवा:

- name: Opportunistic fleet maintenance
  hosts: all
  gather_facts: false
  tasks:
    - name: Check that the host answers before doing any work
      ansible.builtin.ping:
      register: reachable
      ignore_unreachable: true

    - name: End the play for this host if it never answered
      ansible.builtin.meta: end_host
      when: reachable.unreachable | default(false)

    - name: Gather facts now that the connection is known good
      ansible.builtin.setup:

    - name: Refresh the package index
      ansible.builtin.apt:
        update_cache: true
      become: true

यामुळे प्रत्येक टास्कसाठी एक याऐवजी, प्रत्येक मृत होस्टसाठी फक्त एक कनेक्शन प्रयत्न होतो. Ansible 2.8 मध्ये जोडलेले end_host, सध्याच्या होस्टसाठी प्ले समाप्त करते, परंतु त्याला 'failed' म्हणून चिन्हांकित करत नाही. unreachable की केवळ कनेक्शन अयशस्वी झाल्यावरच नोंदणीकृत रिझल्टवर (registered result) अस्तित्वात असते, म्हणून default(false) अट अशा प्रत्येक होस्टवर वैध राहते ज्याने प्रतिसाद दिला आहे. प्ले स्तरावर फॅक्ट गॅदरिंग (fact gathering) बंद ठेवले जाते, कारण अन्यथा अंतर्निहित Gathering Facts टास्क हाच तो टास्क ठरला असता जिथे कनेक्शन तुटते, आणि तुम्हाला तिथे तुमचा स्वतःचा ping टास्क हवा असतो.

ignore_unreachable हे प्ले कीवर्ड आणि टास्क कीवर्ड दोन्ही आहे. हे प्लेबुकमध्ये अशा ठिकाणी ठेवा जिथे वाचकाला ते सहज दिसेल, रोलच्या आत ठेवू नका, कारण हे कीवर्ड ठरवते की कोणत्या होस्टला रन दरम्यान वगळण्याची परवानगी आहे. प्लेबुक्स आणि रोल्समधील विभागणी या विषयावर कोणती लेयर अशा सेटिंग्जसाठी जबाबदार असावी, याचे विवेचन केले आहे.

ignore_errors हे चुकीचे साधन का आहे

Ansible दस्तऐवजीकरण या मर्यादेबद्दल स्पष्ट आहे. ignore_errors "हे फक्त तेव्हाच काम करते जेव्हा टास्क रन होऊ शकते आणि 'failed' असे मूल्य परत करते. हे undefined variable errors, connection failures, execution issues (उदाहरणार्थ, गहाळ पॅकेजेस) किंवा syntax errors कडे दुर्लक्ष करण्यास Ansible ला सांगत नाही."

कनेक्शन अयशस्वी झाल्यास ते कधीही failed: true सह टास्क रिझल्ट बनत नाही. ते एक स्वतंत्र फ्लॅग म्हणून येते आणि Ansible आधी त्या फ्लॅगवर कृती करते: होस्ट unreachable यादीत जातो आणि प्ले मधून बाहेर पडतो. प्ले मधील सर्व बारा टास्कवर ignore_errors: true लावले तरी, बंद SSH पोर्ट असलेला होस्ट पहिल्याच टास्कवर थांबतो. या विषयातील हा सर्वात सामान्य गोंधळ आहे आणि तुमच्या जुन्या प्लेबुक्समध्ये हे शोधणे (grep करणे) फायदेशीर ठरेल, विशेषतः जे VPS वर पहिले प्लेबुक लिहिताना तयार केले होते.

समस्या दाबण्यापूर्वी तिचे निराकरण करा

समस्या कायमस्वरूपी दाबून ठेवल्यामुळे सर्व्हरच्या ताफ्यात विसंगती निर्माण होते, कारण ज्या होस्टपर्यंत कोणीही पोहोचू शकत नाही, तिथे कोणीही पॅचिंगही करत नाही. प्रथम खालील क्रमाने तपासणी करा. येथे दिलेली प्रत्येक कमांड फक्त माहिती वाचण्याचे काम करते.

1. ansible web2 -i inventory.ini -m ansible.builtin.ping -o एका होस्टवर एक मॉड्यूल चालवते आणि एक ओळ आउटपुट देते.
2. त्याच कमांडमध्ये -vvvv जोडा. Ansible तयार करत असलेली पूर्ण ssh कमांड प्रिंट करेल, ज्यामध्ये टार्गेट युजर, पोर्ट, प्रायव्हेट की आणि पास केलेले ऑप्शन्स दिसतील.
3. ती ssh कमांड स्वतः -v वापरून चालवा. जर साध्या ssh द्वारे प्रवेश मिळत नसेल, तर समस्या Ansible च्या खाली आहे आणि कोणत्याही playbook कीवर्डने ती सुटणार नाही.
4. msg स्ट्रिंग वाचा आणि ती वरील यादीशी जुळवून पहा. Connection refused आणि Connection timed out दोन वेगवेगळ्या ठिकाणांकडे निर्देश करतात; एक SSH सर्व्हिसकडे आणि दुसरी नेटवर्क पाथकडे.
5. Host key verification failed. साठी, तुम्ही ssh-keygen -F web2.example.com मध्ये काय साठवले आहे ते तपासा. जर सर्व्हर पुन्हा बिल्ड केला असेल, तर जुनी एन्ट्री ssh-keygen -R web2.example.com वापरून काढून टाका आणि प्रोव्हायडर कन्सोलवरून खात्री केल्यानंतर नवीन की स्वीकार करा. ansible.cfg मध्ये host_key_checking = False सेट केल्याने एरर निघून जाते, परंतु त्याच वेळी ती सुरक्षा तपासणीही काढून टाकली जाते जी तुम्हाला सांगू शकली असती की आता त्या पत्त्यावर वेगळी मशीन प्रतिसाद देत आहे.
6. Permission denied (publickey) साठी, Ansible कोणत्या गोष्टींचा वापर करत आहे याची खात्री करा. ansible-inventory -i inventory.ini --host web2 सध्या लागू असलेले व्हेरिएबल्स प्रिंट करते, ज्यामध्ये ansible_user आणि ansible_port यांचा समावेश असतो.
7. जर SSH काम करत असेल पण मॉड्यूल्स चालत नसतील, तर ansible web2 -m ansible.builtin.raw -a 'command -v python3 || echo none' वापरून इंटरप्रिटर तपासा. raw मॉड्यूल शेलद्वारे कमांड चालवते आणि त्यासाठी टार्गेटवर python ची आवश्यकता नसते.

केवळ या सर्व पायऱ्यांनंतरच होस्टकडे दुर्लक्ष करण्याचा निर्णय घेणे, ही सवय न राहता एक जाणीवपूर्वक घेतलेला निर्णय ठरेल.

रिकॅपमध्ये पोहोचता न येणाऱ्या (unreachable) होस्टची गणना स्वतंत्रपणे केली जाते आणि CI सहसा याकडे दुर्लक्ष करते

ansible-playbook यशस्वी झाल्यावर 0, किमान एक होस्ट अयशस्वी झाल्यास 2 आणि किमान एक होस्ट पोहोचण्यायोग्य नसल्यास 4 असा एक्झिट कोड देते. हे दोन मूल्ये सोर्स कोडमध्ये बिट फ्लॅग्स आहेत, त्यामुळे ज्या रनमध्ये एक होस्ट अयशस्वी झाला आहे आणि एक पोहोचण्यायोग्य नाही, त्याचा एक्झिट कोड 6 असतो. ansible कमांड देखील समान कोड्स परत करते. ऑगस्ट 2026 मध्ये ansible-core सोर्स कोडच्या आधारे याची पडताळणी करण्यात आली होती.

आता ignore_unreachable: true सेट करा आणि त्याच मृत होस्टवर सात टास्कचा प्ले रन करा:

PLAY RECAP *********************************************************************
web1  : ok=7  changed=2  unreachable=0  failed=0  skipped=0  rescued=0  ignored=0
web2  : ok=7  changed=0  unreachable=0  failed=0  skipped=0  rescued=0  ignored=7

web2 मध्ये unreachable=0 आणि सात टास्क ok असे रिपोर्ट केले जाते आणि रन 0 एक्झिट कोडसह पूर्ण होतो. जेव्हा हा कीवर्ड सेट केला जातो, तेव्हा Ansible त्या होस्टसाठी ok आणि ignored काउंटर वाढवते, त्याऐवजी ज्याला ते dark म्हणतात, जो unreachable कॉलम भरतो. लाल रंगाच्या UNREACHABLE! ओळी अजूनही प्रिंट होतात, त्यामुळे लॉग प्रामाणिक राहतो, परंतु रिकॅप आणि एक्झिट कोड तसे नसतात.

जो CI जॉब फक्त $? तपासून प्लेबुक रन करतो, तो या रनला यशस्वी (green) मानतो आणि समरीमध्ये मशीन कधीही कनेक्ट झाले नव्हते, असा कोणताही उल्लेख नसतो. प्ले सुरू होण्यापूर्वी पोहोचण्यायोग्यता तपासण्यासाठी (reachability check) एक स्वतंत्र स्टेप तयार करा:

ansible all -i inventory.ini -m ansible.builtin.ping -o

हे प्रत्येक होस्टसाठी एक ओळ प्रिंट करते आणि कोणताही होस्ट पोहोचण्यायोग्य नसल्यास 4 एक्झिट कोड देते. यामुळे पाइपलाइनला अयशस्वी होण्यासाठी एक कारण मिळते आणि लॉगमध्ये तुम्हाला संबंधित होस्टची नावे मिळतात. ping साठी टार्गेटवर कार्यरत Python इंटरप्रिटरची आवश्यकता असते, त्यामुळे हे केवळ कनेक्शनपेक्षा थोडे अधिक सिद्ध करते, जे सहसा तुम्हाला हवे असते. त्यानंतर ignore_unreachable वापरून प्लेबुक रन करा, जेणेकरून जे होस्ट सुरू आहेत, त्यांच्यावर बदल लागू होतील.

any_errors_fatal आणि max_fail_percentage चा बॅचवर होणारा परिणाम

जेव्हा फ्लीटच्या काही भागावर काही चूक घडते, तेव्हा काय करावे हे हे दोन कीवर्ड ठरवतात. हे दोन्ही कीवर्ड अनरिचेबल (unreachable) होस्ट्सना वेगवेगळ्या प्रकारे हाताळतात.

any_errors_fatal: true अनरिचेबल होस्टवर प्रतिक्रिया देते. Ansible बॅचमधील उर्वरित होस्ट्सवर चालू असलेले कार्य पूर्ण करते आणि त्यानंतर त्या बॅचमधील प्रत्येक होस्टसाठी प्ले (play) थांबवते. जेव्हा एखादी प्रक्रिया 'सर्व किंवा काहीही नाही' (all or nothing) या तत्त्वावर आधारित असते, जसे की समन्वित स्कीमा बदल (coordinated schema change), तेव्हा याचा वापर करा.

max_fail_percentage: 30 अनरिचेबल होस्टवर प्रतिक्रिया देत नाही. ही तपासणी अपयशी (failed) होस्ट्सच्या संख्येला बॅचच्या आकाराने भागते. अनरिचेबल होस्ट्सची गणना वेगळ्या यादीत केली जाते, त्यामुळे ते या संख्येवर कोणताही परिणाम करत नाहीत. उदाहरणार्थ, दहापैकी चार होस्ट्स अनरिचेबल असले तरी max_fail_percentage: 10 अंतर्गत प्रक्रिया सुरू राहते, तर दोन होस्ट्सचे कार्य अपयशी ठरल्यास प्ले थांबते. दस्तऐवजीकरणामध्ये आणखी एक महत्त्वाची बाब नमूद केली आहे: "दिलेली टक्केवारी ओलांडली (exceeded) पाहिजे, ती गाठली (equaled) नाही पाहिजे." serial: 4 सह, चारपैकी दोन अपयश आल्यावर प्रक्रिया थांबवायची असेल, तर 50 ऐवजी 49 ही संख्या लिहावी लागते.

अशी एक स्थिती आहे जिथे अनरिचेबल होस्ट्स स्वतःहून रन (run) थांबवतात. जर बॅचमधील प्रत्येक होस्ट अपयशी ठरला असेल किंवा अनरिचेबल असेल, तर Ansible कडे काम करण्यासाठी काहीही उरत नाही आणि ते NO MORE HOSTS LEFT सह प्ले समाप्त करते.

serial: संपूर्ण फ्लीटमध्ये बदल लागू करणे

- name: Rolling nginx config update
  hosts: webservers
  serial: 2
  max_fail_percentage: 25
  tasks:
    - name: Deploy the site config
      ansible.builtin.template:
        src: site.conf.j2
        dest: /etc/nginx/conf.d/site.conf
        owner: root
        mode: "0644"
      become: true
      notify: Reload nginx
  handlers:
    - name: Reload nginx
      ansible.builtin.service:
        name: nginx
        state: reloaded
      become: true

serial: 2 संपूर्ण प्ले दोन होस्टवर चालवते, ते पूर्ण करते आणि त्यानंतर पुढील दोन होस्टवर प्रक्रिया सुरू करते. serial: "25%" हे ग्रुपच्या आकारानुसार स्केल होते. serial: [1, 5, 10] ही यादी 'कॅनरी' (canary) स्वरूपाची आहे: प्रथम एक होस्ट, त्यानंतर पाच, मग दहा आणि उरलेले सर्व होस्ट शेवटच्या बॅचच्या आकारानुसार चालवले जातात. max_fail_percentage हे प्रति बॅच मोजले जाते, त्यामुळे हे दोन्ही घटक एकत्रितपणे काम करतात. जर पहिले मशीन निकामी झाले, तर चाळीस मशीन खराब होण्याआधीच ही प्रक्रिया थांबते. यामुळेच एका कंट्रोल मशीनवरून लिनक्स सर्व्हर्सच्या फ्लीटचे व्यवस्थापन करणे एकाच कमांडद्वारे सुरक्षितपणे करणे शक्य होते.

अनरिचेबल (unreachable) होस्ट्सना कधी दुर्लक्षित करावे आणि कधी करू नये

संधीसाधू (opportunistic) कामांसाठी त्यांना दुर्लक्षित करा. फॅक्ट कलेक्शन रन किंवा तासाभराची ड्रिफ्ट चेक (drift check) करताना एखादा होस्ट बंद असल्यास काहीही नुकसान होत नाही, कारण पुढच्या वेळी तो आपोआप कव्हर केला जातो. अशा वेळी प्ले लेव्हल ignore_unreachable: true हा योग्य पर्याय आहे, जो पिंग स्टेपसोबत वापरल्यास वगळलेल्या होस्टची नावे अशा ठिकाणी दिसतात जिथे ती कोणाच्या तरी निदर्शनास येतील.

सुरक्षा पॅच रन (security patch run) करताना त्यांना कधीही दुर्लक्षित करू नका. अशा रनचे मूल्य हेच असते की प्रत्येक होस्टवर फिक्स (fix) लागू झाल्याची खात्री मिळते. अनरिचेबल स्थिती दाबून ठेवल्यास "एक सर्व्हर अजूनही असुरक्षित आहे" ही महत्त्वाची माहिती लपून जाते आणि रिपोर्टमध्ये सर्व काही ठीक असल्याचे चुकीचे चित्र दिसते. जो होस्ट दोन आठवड्यांपासून अनरिचेबल आहे, तोच होस्ट सर्वात जास्त मागे पडलेला असण्याची शक्यता असते. अशा वेळी रनला exit 4 सह थांबू द्या आणि एखाद्या व्यक्तीला ते तपासू द्या.

दोन्ही परिस्थितींमध्ये एक नियम लागू होतो: प्रक्रिया थांबवू नका, पण नोंद (record) मात्र कधीही टाळू नका. जर एखादा होस्ट वगळला गेला असेल, तर त्याची माहिती रिकॅपमध्ये, CI लॉगमध्ये किंवा मॉनिटरिंग अलर्टमध्ये दिसलीच पाहिजे. Ansible ला फक्त प्ले रन होत असलेल्या काही सेकंदांपुरतीच होस्टच्या अस्तित्वाची माहिती असते, त्यामुळे मंगळवारपासून सर्व्हर बंद आहे हे शोधण्यासाठी ते योग्य ठिकाण नाही. हे काम मॉनिटरिंगचे आहे आणि Zabbix इन्स्टॉल करणारे Ansible playbook वापरून तुम्ही एका दुपारमध्ये संपूर्ण फ्लीटवर लक्ष ठेवू शकता.

FAQ

Ansible मधील ignore_errors आणि ignore_unreachable मधील फरक काय आहे?

ignore_errors: true हे अशा टास्कला लागू होते जे होस्टवर रन झाले आणि ज्याने एरर (उदा. नॉन-झिरो एक्झिट कोड) दिली. ignore_unreachable: true हे अशा होस्टला लागू होते ज्याच्याशी Ansible कनेक्ट होऊ शकले नाही, जिथे कोणतेही मॉड्युल रन झाले नाही. हे दोन्ही टास्क रिझल्टमधील वेगवेगळ्या फील्ड्स तपासतात आणि एक दुसऱ्याची जागा घेऊ शकत नाही. Ansible डॉक्युमेंटेशननुसार, ignore_errors "Ansible ला अनडिफाइन्ड व्हेरिएबल एरर्स, कनेक्शन फेल्युअर, एक्झिक्युशन इश्यूज (उदा. पॅकेज गहाळ असणे) किंवा सिंटॅक्स एरर्सकडे दुर्लक्ष करण्यास सांगत नाही", आणि बंद असलेला SSH पोर्ट हा एक कनेक्शन फेल्युअरचा प्रकार आहे.

ignore_unreachable मुळे प्ले रिकॅप (play recap) मधून होस्ट लपवला जातो का?

थोडक्यात सांगायचे तर, हो. हे कीवर्ड सेट केल्यावर, Ansible त्या होस्टला unreachable मध्ये मोजणे थांबवते आणि त्याऐवजी प्रत्येक टास्कसाठी एकदा ok आणि ignored म्हणून मोजते, ज्यामुळे रनचा एक्झिट कोड 0 येतो. fatal: [host]: UNREACHABLE! ओळी तरीही प्रिंट होतात, त्यामुळे रिकॅप आणि एक्झिट कोड चुकीचे असले तरी लॉग अचूक राहतो. ignored कॉलमवर लक्ष ठेवा, किंवा ansible all -m ansible.builtin.ping -o ही पायरी स्वतंत्रपणे रन करा जेणेकरून न पोहोचता येणाऱ्या होस्टमुळे नॉन-झिरो एक्झिट कोड मिळेल.

होस्ट अनरिचेबल (unreachable) असताना ansible-playbook कोणता एक्झिट कोड देते?

ते 4 हा कोड देते. किमान एक फेल झालेला होस्ट असल्यास रन 2 हा कोड देते, आणि हे दोन्ही व्हॅल्यूज बिट फ्लॅग्स असल्याने, फेल्युअर आणि अनरिचेबल होस्ट दोन्ही असल्यास रन 6 हा कोड देते. यशस्वी रन 0 कोड देते. हे कोड्स ऑगस्ट 2026 मध्ये ansible-core च्या सोर्स कोडनुसार तपासले गेले आहेत. ignore_unreachable: true सेट केल्यामुळे 4 हा कोड निघून जातो, म्हणूनच फक्त एक्झिट कोड तपासणारी पाइपलाइन स्किप झालेली मशीन ओळखू शकत नाही.

ज्या होस्टने प्रतिसाद दिला नाही, त्याच्यासाठी उर्वरित प्ले (play) कशी स्किप करावी?

पहिली टास्क ansible.builtin.ping करा, ज्यामध्ये ignore_unreachable: true आणि register: reachable वापरा, त्यानंतर when: reachable.unreachable | default(false) या अटीवर ansible.builtin.meta: end_host वापरा. end_host मुळे त्या होस्टसाठी प्ले संपते आणि तो होस्ट 'फेल' म्हणून मार्क होत नाही. प्लेवर gather_facts: false सेट करा जेणेकरून तुमची पिंग टास्क कनेक्शन तुटल्याचे ओळखू शकेल. या पॅटर्नशिवाय, मृत होस्ट प्लेमध्येच राहतो आणि प्रत्येक पुढील टास्कसाठी पुन्हा कनेक्शन टाइमआउटची वाट पाहावी लागते.

सिक्युरिटी पॅच रन करताना अनरिचेबल होस्टकडे दुर्लक्ष करावे का?

नाही. पॅच रन करणे महत्त्वाचे असते कारण त्यामुळे प्रत्येक होस्ट अपडेट झाल्याची खात्री मिळते. अनरिचेबल होस्टकडे दुर्लक्ष केल्यास ही खात्री मिळत नाही आणि रिकॅप फक्त हिरवा दिसतो. रनला 4 हा एक्झिट कोड येऊ द्या, ज्या होस्टने प्रतिसाद दिला नाही त्यांची नावे वाचा आणि त्यांना दुरुस्त करा. एरर सप्रेस करणे हे फक्त अशा वारंवार होणाऱ्या रनसाठी योग्य आहे जिथे पुढच्या वेळी राहिलेले काम पूर्ण केले जाईल.