Ansible లో unreachable హోస్ట్‌లను ఎలా విస్మరించాలి?

అందుబాటులో లేని హోస్ట్ విఫలమైన టాస్క్ కాదు

Ansible లో అందుబాటులో లేని హోస్ట్‌లను విస్మరించడానికి మీరు 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)

ఏదైనా మాడ్యూల్ హోస్ట్‌ను చేరుకోకముందే కనెక్షన్ విఫలమైతే, దానిని 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 కనెక్షన్ తిరస్కరించబడింది, అంటే ఆ పోర్ట్‌లో ఏ సేవ వినడం లేదు (listening). sshd ఆగిపోయి ఉండవచ్చు, లేదా SSH వేరే పోర్ట్‌కు మారినా మీ ఇన్వెంటరీలో ఇంకా 22 అని ఉండవచ్చు.
• Connection timed out: ఏ సమాధానం రాలేదు. ఫైర్‌వాల్ ప్యాకెట్లను డ్రాప్ చేస్తోంది లేదా సర్వర్ ఆఫ్ అయి ఉండవచ్చు. ప్రతి ప్రయత్నానికి పూర్తి కనెక్షన్ టైమ్‌అవుట్ పడుతుంది, ఇది డిఫాల్ట్‌గా 10 సెకన్లు ఉంటుంది.
• Permission denied (publickey): SSH స్పందించింది కానీ మీ కీని తిరస్కరించింది. పోర్ట్ సరిగానే ఉంది, కాబట్టి ఇది అథెంటికేషన్ సమస్య. సాధారణంగా తప్పుడు ansible_user లేదా లోడ్ చేయని కీ వల్ల ఇది జరుగుతుంది.
• Host key verification failed.: ~/.ssh/known_hosts లోని కీ, సర్వర్ అందించిన కీతో సరిపోలడం లేదు. రీబిల్డ్ చేసిన VPS తన IP అడ్రస్‌ను ఉంచుకుని కొత్త హోస్ట్ కీని పొందుతుంది, కాబట్టి రీఇన్‌స్టాల్ తర్వాత ఇది సహజం, కానీ ఇతర సమయాల్లో ఇది తీవ్రమైన విషయం.
• 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 ని ఇన్‌స్టాల్ చేయండి.

Playలో అందుబాటులో లేని hostలను ఎలా విస్మరించాలి

Task స్థాయిలో, ఈ keyword మాడ్యూల్ పక్కనే ఉంటుంది:

- 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

Play స్థాయిలో ఇది ఆ playలోని ప్రతి taskకు డిఫాల్ట్‌ను సెట్ చేస్తుంది, ఒకే ఒక task దీనిని తిరిగి మార్చవచ్చు:

- 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 సెట్ చేసినప్పుడు, ఆ host play నుండి తొలగించబడదు, కాబట్టి ప్రతి తదుపరి task మళ్ళీ కనెక్ట్ అవ్వడానికి ప్రయత్నించి అదే విధంగా విఫలమవుతుంది. అటువంటి ప్రతి ప్రయత్నం connection timeout కోసం వేచి ఉంటుంది, మీరు ansible.cfg లో timeout ని మార్చకపోతే ఇది 10 సెకన్లు ఉంటుంది. ఒక dead server పై ఇరవై taskల play రన్ అయితే, అది రన్ టైమ్‌కు సుమారు 200 సెకన్లను జోడిస్తుంది మరియు logలో ఇరవై ఎరుపు రంగు లైన్లను చూపిస్తుంది.

కాబట్టి ఒకసారి తనిఖీ చేసి, ఆ hostను పద్ధతిగా ఆపివేయండి:

- 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

ఇది ప్రతి taskకు ఒక ప్రయత్నం కాకుండా, ప్రతి dead hostకు ఒక కనెక్షన్ ప్రయత్నం మాత్రమే చేస్తుంది. Ansible 2.8లో చేర్చబడిన end_host, ప్రస్తుత host కోసం playని విఫలం (failed) అని గుర్తించకుండా ముగిస్తుంది. కనెక్షన్ విఫలమైనప్పుడు మాత్రమే registered resultలో unreachable కీ ఉంటుంది, కాబట్టి default(false) ప్రతి స్పందించిన hostపై కండిషన్‌ను చెల్లుబాటు అయ్యేలా ఉంచుతుంది. Play స్థాయిలో fact gathering నిలిపివేయబడుతుంది, ఎందుకంటే లేకపోతే implicit Gathering Facts task కనెక్షన్ విఫలమైన చోట మొదటి taskగా మారుతుంది, కానీ మీరు మీ స్వంత ping taskనే అక్కడ ఉండాలని కోరుకుంటారు.

ignore_unreachable అనేది ఒక play keyword మరియు task keyword. దీనిని role లోపల కాకుండా, playbookలో పాఠకులకు కనిపించేలా ఉంచండి, ఎందుకంటే ఏ hostలను రన్ నుండి మినహాయించవచ్చో ఇది నిర్ణయిస్తుంది. Playbooks మరియు roles మధ్య విభజన ఇటువంటి సెట్టింగ్‌ను ఏ పొర (layer) నిర్వహించాలో వివరిస్తుంది.

ignore_errors ఎందుకు సరైన పద్ధతి కాదు

Ansible డాక్యుమెంటేషన్ దీని పరిమితి గురించి స్పష్టంగా చెబుతోంది. ignore_errors "టాస్క్ రన్ అయ్యి 'failed' అనే విలువను తిరిగి ఇచ్చినప్పుడు మాత్రమే ఇది పనిచేస్తుంది. ఇది undefined variable errors, connection failures, execution issues (ఉదాహరణకు, missing packages), లేదా syntax errors వంటి వాటిని Ansible విస్మరించేలా చేయదు."

ఒక connection failure ఎప్పటికీ failed: true తో కూడిన టాస్క్ రిజల్ట్‌గా మారదు. ఇది ఒక ప్రత్యేకమైన ఫ్లాగ్‌గా వస్తుంది, మరియు Ansible ముందుగా ఆ ఫ్లాగ్ ఆధారంగానే స్పందిస్తుంది: హోస్ట్ unreachable జాబితాలోకి వెళ్తుంది మరియు ప్లే (play) నుండి బయటకు వస్తుంది. ఒక ప్లేలోని పన్నెండు టాస్క్‌లకు ignore_errors: true ని జోడించినా, SSH పోర్ట్ క్లోజ్ అయి ఉన్న హోస్ట్ మొదటి టాస్క్ వద్దే ఆగిపోతుంది. ఈ విషయంలో ఇది అత్యంత సాధారణ గందరగోళం, కాబట్టి మీ పాత ప్లేబుక్‌లలో దీని కోసం grep చేయడం మంచిది, ముఖ్యంగా VPS పై మొదటి ప్లేబుక్ రాయడం నేర్చుకునేటప్పుడు రాసిన వాటిలో ఇది చాలా ముఖ్యం.

అణచివేసే ముందు డీబగ్ చేయండి

అణచివేత శాశ్వతంగా మారితే, సర్వర్ల సమూహం (fleet) నిర్వహణ దెబ్బతింటుంది. ఎందుకంటే ఎవరూ చేరుకోలేని హోస్ట్, ఎవరూ ప్యాచ్ చేయని హోస్ట్‌గా మారుతుంది. ముందుగా ఈ క్రమంలో సమస్యను పరిష్కరించండి. ఇక్కడ ఉన్న ప్రతి కమాండ్ కేవలం సమాచారాన్ని మాత్రమే చదువుతుంది.

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 అవసరం లేదు.

దీని తర్వాత మాత్రమే, హోస్ట్‌ను విస్మరించడం అనేది ఒక అలవాటుగా కాకుండా, ఒక నిర్ణయంగా ఉండాలి.

రీక్యాప్ (recap) అన్‌రీచబుల్ (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 ఆ హోస్ట్ కోసం dark అని పిలిచే కౌంటర్‌కు బదులుగా ok మరియు ignored కౌంటర్లను పెంచుతుంది; ఇదే unreachable కాలమ్‌ను నింపుతుంది. ఎరుపు రంగులో ఉండే UNREACHABLE! లైన్లు ఇప్పటికీ ప్రింట్ అవుతాయి, కాబట్టి రీక్యాప్ మరియు ఎగ్జిట్ కోడ్ తప్పుగా ఉన్నప్పటికీ, లాగ్ మాత్రం వాస్తవాన్ని చూపుతుంది.

ప్లేబుక్‌ను రన్ చేసి కేవలం $? ను మాత్రమే చెక్ చేసే CI జాబ్, ఆ రన్‌ను సక్సెస్ (green) గా పరిగణిస్తుంది. ఒక మెషీన్ అసలు కనెక్ట్ కాలేదనే విషయం దాని సమ్మరీలో ఎక్కడా కనిపించదు. కాబట్టి, ప్లే రన్ అవ్వకముందే రీచబిలిటీ చెక్‌ను ఒక ప్రత్యేక స్టెప్‌గా చేర్చండి:

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 మిగిలిన బ్యాచ్‌లోని హోస్ట్‌లపై ప్రస్తుత టాస్క్‌ను పూర్తి చేసి, ఆ తర్వాత ఆ బ్యాచ్‌లోని ప్రతి హోస్ట్‌కు ప్లేను ఆపివేస్తుంది. కోఆర్డినేటెడ్ స్కీమా మార్పుల వంటి, అన్నీ లేదా ఏమీ లేని (all or nothing) రన్ మాత్రమే అర్థవంతంగా ఉన్నప్పుడు దీనిని ఉపయోగించండి.

max_fail_percentage: 30 చేరుకోలేని హోస్ట్‌కు స్పందించదు. ఈ చెక్ విఫలమైన (failed) హోస్ట్‌ల సంఖ్యను బ్యాచ్ పరిమాణంతో భాగిస్తుంది, మరియు చేరుకోలేని హోస్ట్‌లు ప్రత్యేక జాబితాలో ఉంటాయి కాబట్టి అవి ఆ సంఖ్యను మార్చవు. పది హోస్ట్‌లలో నాలుగు చేరుకోలేకపోయినా max_fail_percentage: 10 కింద రన్ కొనసాగుతుంది, కానీ రెండు హోస్ట్‌లు ఒక టాస్క్‌లో విఫలమైతే ప్లే ఆగిపోతుంది. డాక్యుమెంటేషన్ మరొక ముఖ్యమైన విషయాన్ని జోడిస్తుంది: "సెట్ చేసిన శాతాన్ని మించాలే కానీ, దానికి సమానంగా ఉండకూడదు." serial: 4 తో, నాలుగు హోస్ట్‌లలో రెండు విఫలమైన తర్వాత ఆపాలనుకుంటే, 50 అని కాకుండా 49 అని రాయాలి.

చేరుకోలేని హోస్ట్‌లు స్వయంగా రన్‌ను ఆపే ఒక సందర్భం ఉంది. బ్యాచ్‌లోని ప్రతి హోస్ట్ విఫలమైనా లేదా చేరుకోలేకపోయినా, 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 అనేది ప్రతి బ్యాచ్‌కు లెక్కించబడుతుంది, కాబట్టి ఈ రెండు కలిసి పనిచేస్తాయి. మొదటి మెషీన్‌లో ఏదైనా లోపం వస్తే, నలభై మెషీన్లు దెబ్బతినకముందే రన్ ఆగిపోతుంది. ఒకే కమాండ్‌తో ఒక కంట్రోల్ మెషీన్ నుండి Linux సర్వర్ల ఫ్లీట్‌ను నిర్వహించడం సురక్షితంగా చేయడానికి ఇదే కారణం.

అందుబాటులో లేని హోస్ట్‌లను ఎప్పుడు విస్మరించాలి, ఎప్పుడు విస్మరించకూడదు

అవకాశవాద (opportunistic) పనుల కోసం వాటిని విస్మరించండి. ఒక హోస్ట్ డౌన్ అయినప్పుడు దానిని వదిలేయడం వల్ల ఫ్యాక్ట్ కలెక్షన్ రన్ లేదా గంటకోసారి చేసే డ్రిఫ్ట్ చెక్ (drift check) కు ఎటువంటి నష్టం జరగదు, ఎందుకంటే తదుపరి రన్‌లో అది కవర్ అవుతుంది. అక్కడ ignore_unreachable: true ప్లే లెవల్ సరైన సమాధానం, దీనిని పింగ్ స్టెప్‌తో జత చేయండి, తద్వారా స్కిప్ చేయబడిన పేర్లు ఎవరైనా చదవగలిగే చోట కనిపిస్తాయి.

సెక్యూరిటీ ప్యాచ్ రన్ కోసం వాటిని ఎప్పుడూ విస్మరించవద్దు. ప్రతి హోస్ట్‌కు ఫిక్స్ అందిందనే హామీయే ఆ రన్ యొక్క విలువ. అందుబాటులో లేని స్థితిని అణచివేయడం (suppress) వల్ల "ఒక సర్వర్ ఇంకా వల్నరబుల్‌గా ఉంది" అనే విషయాన్ని దాచిపెట్టి, అంతా బాగుందనే తప్పుడు సంకేతాన్ని ఇస్తుంది. రెండు వారాలుగా అందుబాటులో లేని హోస్టే అత్యంత వెనుకబడి ఉండే అవకాశం ఉంది. ఆ రన్ exit 4 తో ఆగిపోయేలా చేయండి మరియు ఒక వ్యక్తి దానిని పరిశీలించేలా చూడండి.

రెండు సందర్భాల్లోనూ ఒక నియమం వర్తిస్తుంది: ఆపరేషన్‌ను ఆపవద్దు, కానీ రికార్డును మాత్రం ఎప్పుడూ దాచవద్దు. ఒక హోస్ట్ స్కిప్ చేయబడితే, ఆ విషయం రీక్యాప్‌లో, CI లాగ్‌లో లేదా మానిటరింగ్ అలర్ట్‌లో ఎక్కడో ఒకచోట నమోదు కావాలి. ఒక హోస్ట్ పైన ప్లే రన్ అయ్యే కొన్ని సెకన్ల పాటు మాత్రమే Ansible కు ఆ హోస్ట్ ఉనికి తెలుస్తుంది, కాబట్టి మంగళవారం నుండి సర్వర్ డౌన్ అయిందనే విషయాన్ని తెలుసుకోవడానికి ఇది సరైన మార్గం కాదు. ఆ పని మానిటరింగ్‌కు చెందుతుంది, మరియు Zabbix ను ఇన్‌స్టాల్ చేసే Ansible playbook ద్వారా ఒక మధ్యాహ్నంలోనే మొత్తం ఫ్లీట్ (fleet) స్థితిని తెలుసుకోవచ్చు.

FAQ

Ansible లో ignore_errors మరియు ignore_unreachable మధ్య తేడా ఏమిటి?

ignore_errors: true అనేది హోస్ట్‌పై రన్ అయ్యి విఫలమైన టాస్క్‌కు వర్తిస్తుంది, ఉదాహరణకు ఒక కమాండ్ non-zero exit code తో ముగియడం. ignore_unreachable: true అనేది Ansible కనెక్ట్ అవ్వలేని హోస్ట్‌కు వర్తిస్తుంది, అక్కడ ఏ మాడ్యూల్ కూడా రన్ అవ్వదు. ఇవి టాస్క్ ఫలితంలోని వేర్వేరు ఫీల్డ్‌లను చదువుతాయి, కాబట్టి ఒకటి మరొకదాని స్థానాన్ని భర్తీ చేయలేదు. Ansible డాక్యుమెంటేషన్ ప్రకారం, ignore_errors అనేది "undefined variable errors, connection failures, execution issues (ఉదాహరణకు, ప్యాకేజీలు లేకపోవడం), లేదా syntax errors ను విస్మరించదు", మరియు SSH పోర్ట్ క్లోజ్ అయి ఉండటం అనేది ఒక connection failure.

ignore_unreachable ప్లే రీక్యాప్ (play recap) నుండి హోస్ట్‌ను దాచిపెడుతుందా?

వాస్తవానికి, అవును. ఈ కీవర్డ్‌ను సెట్ చేసినప్పుడు, Ansible ఆ హోస్ట్‌ను unreachable కింద లెక్కించడం ఆపివేస్తుంది మరియు ప్రతి టాస్క్‌కు ఒకసారి ok మరియు ignored గా లెక్కిస్తుంది, ఆపై రన్ 0 exit code తో ముగుస్తుంది. fatal: [host]: UNREACHABLE! లైన్లు ప్రింట్ అవుతూనే ఉంటాయి, కాబట్టి రీక్యాప్ మరియు exit code తప్పుగా ఉన్నప్పటికీ లాగ్ ఖచ్చితంగా ఉంటుంది. ignored కాలమ్‌ను గమనించండి, లేదా ansible all -m ansible.builtin.ping -o ను విడిగా రన్ చేయండి, తద్వారా కనెక్ట్ అవ్వలేని హోస్ట్ ఏదో ఒక చోట non-zero exit code ను ఇస్తుంది.

హోస్ట్ అందుబాటులో లేనప్పుడు ansible-playbook ఏ exit code ను ఇస్తుంది?

ఇది 4 ను ఇస్తుంది. కనీసం ఒక విఫలమైన హోస్ట్ ఉన్న రన్ 2 ను ఇస్తుంది, మరియు ఈ రెండు విలువలు bit flags కాబట్టి, ఫెయిల్యూర్ మరియు అన్‌రీచబుల్ హోస్ట్ రెండూ ఉన్న రన్ 6 ను ఇస్తుంది. విజయవంతమైన రన్ 0 ను ఇస్తుంది. ఈ కోడ్‌లను ఆగస్టు 2026 లో ansible-core సోర్స్ కోడ్‌తో సరిచూడడం జరిగింది. ignore_unreachable: true ను సెట్ చేయడం వల్ల 4 తొలగించబడుతుంది, అందుకే కేవలం exit code ను మాత్రమే పరీక్షించే పైప్‌లైన్ స్కిప్ అయిన మెషీన్‌ను గుర్తించలేదు.

స్పందించని హోస్ట్ కోసం ప్లే లోని మిగిలిన భాగాలను ఎలా స్కిప్ చేయాలి?

మొదటి టాస్క్‌ను ansible.builtin.ping గా, ignore_unreachable: true మరియు register: reachable తో సెట్ చేయండి, ఆపై when: reachable.unreachable | default(false) కండిషన్‌తో ansible.builtin.meta: end_host ను ఉపయోగించండి. end_host ఆ హోస్ట్ కోసం ప్లే ను విఫలం అని గుర్తించకుండానే ముగిస్తుంది. ప్లే పై gather_facts: false ను సెట్ చేయండి, తద్వారా మీ పింగ్ (ping) కనెక్షన్ తెగిపోయిన టాస్క్ అవుతుంది. ఈ పద్ధతి లేకపోతే, స్పందించని హోస్ట్ ప్లే లోనే ఉండిపోతుంది మరియు తర్వాతి ప్రతి టాస్క్ కనెక్షన్ టైమ్-అవుట్ అయ్యే వరకు వేచి ఉంటుంది.

సెక్యూరిటీ ప్యాచ్ రన్ చేసేటప్పుడు అన్‌రీచబుల్ హోస్ట్‌లను విస్మరించాలా?

వద్దు. ప్యాచ్ రన్ చేయడం వల్ల ప్రతి హోస్ట్‌కు అప్‌డేట్ అందిందని హామీ లభిస్తుంది, అన్‌రీచబుల్ హోస్ట్‌లను విస్మరించడం వల్ల ఆ హామీ స్థానంలో కేవలం గ్రీన్ రీక్యాప్ మాత్రమే కనిపిస్తుంది. రన్ 4 తో ముగియనివ్వండి, స్పందించని హోస్ట్‌ల పేర్లను చదవండి మరియు వాటిని సరిచేయండి. ఇలాంటి విస్మరణ (suppression) కేవలం పదేపదే చేసే రన్‌లకు మాత్రమే పరిమితం కావాలి, అక్కడ తర్వాతి ప్రయత్నంలో మిగిలిపోయినవి కవర్ అవుతాయి.