Ansible-ல் unreachable host-களை கையாள்வது எப்படி?

அணுக முடியாத host என்பது தோல்வியடைந்த task அல்ல

Ansible-ல் அணுக முடியாத host-களைத் தவிர்க்க நீங்கள் ignore_unreachable: true-ஐ அமைக்க வேண்டும், இந்த switch சரியாகச் செயல்படும். இதை எப்போது பயன்படுத்த வேண்டும் என்பதை அறிவதே முக்கியமானது, ஏனெனில் Ansible இரண்டு வெவ்வேறு சிக்கல்களை இரண்டு வெவ்வேறு வழிகளில் கையாளுகிறது. ஒரு host-ல் இயங்கி பிழையைத் தரும் task என்பது failure ஆகும். Ansible-ஆல் ஒரு host-உடன் இணைப்பை ஏற்படுத்த முடியவில்லை என்றால் அது unreachable ஆகும். ignore_errors முதல் வகையை மட்டுமே கையாளும். ignore_unreachable இரண்டாவது வகையை மட்டுமே கையாளும்.

play recap-ல் உள்ள வேறுபாடு இதோ.

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-உடன் இணைந்து ஏழு task-களை இயக்கியது. web2-ல் unreachable=1 மற்றும் failed=0 காட்டப்படுகிறது, அதாவது அந்த host-ல் எந்த task-ம் இயங்கவில்லை என்று பொருள். Ansible-ஆல் இணைப்பு பெற முடியவில்லை, எனவே அது அந்த host-ஐ play-லிருந்து நீக்கிவிட்டு மற்றவற்றுடன் தொடர்ந்தது. அந்த play ஒரு security update-ஐ நிறுவுவதாக இருந்தால், உங்கள் server-களில் ஒன்றில் அந்த update இல்லை என்று அர்த்தம்.

ஒரு host-ஐ ஏன் அணுக முடியவில்லை

அணுக முடியவில்லை (Unreachable) என்றால், எந்தவொரு module-ம் அந்த host-ஐச் சென்றடைவதற்கு முன்பே இணைப்பு தோல்வியடைந்தது என்று பொருள். இதில் வாசிப்பதற்கு module வெளியீடு எதுவும் இருக்காது, இணைப்புப் பிழை மட்டுமே இருக்கும். அந்த இயந்திரத்தைத் தொடும் முதல் task-இலேயே இது தோன்றும்.

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 இணைப்பு நிராகரிக்கப்பட்டது, எனவே அந்த port-இல் எதுவும் இயங்கவில்லை. sshd நிறுத்தப்பட்டிருக்கலாம் அல்லது SSH வேறொரு port-க்கு மாற்றப்பட்டிருக்கலாம், ஆனால் உங்கள் inventory-இல் இன்னும் 22 என்றே இருக்கலாம்.
• Connection timed out: எந்தப் பதிலும் வரவில்லை. Firewall பாக்கெட்டுகளைத் தடுத்துக்கொண்டிருக்கலாம் அல்லது server அணைக்கப்பட்டிருக்கலாம். ஒவ்வொரு முயற்சியும் முழு இணைப்பு காலாவதி நேரத்தை (connection timeout) எடுத்துக்கொள்ளும், இது இயல்பாக 10 வினாடிகள் ஆகும்.
• Host key verification failed.: ~/.ssh/known_hosts-இல் உள்ள key, server வழங்கிய key-உடன் பொருந்தவில்லை. ஒரு VPS மறுசீரமைக்கப்படும்போது (rebuilt) அதன் IP முகவரி அப்படியே இருக்கும், ஆனால் புதிய host key கிடைக்கும். எனவே, மறுநிறுவலுக்குப் பிறகு இது எதிர்பார்க்கப்படுவதுதான், ஆனால் மற்ற நேரங்களில் இது தீவிரமான சிக்கல்.
• Permission denied (publickey): SSH பதிலளித்து உங்கள் key-ஐ நிராகரித்தது. Port சரியாக உள்ளது, எனவே இது அங்கீகாரச் சிக்கல் (authentication). பொதுவாக தவறான ansible_user அல்லது ஏற்றப்படாத (not loaded) key காரணமாக இது நிகழும்.
• Timeout (12s) waiting for privilege escalation prompt: இணைப்பு வேலை செய்தது, ஆனால் become வேலை செய்யவில்லை. sudo கடவுச்சொல்லுக்காகக் காத்திருக்கிறது, ஆனால் அது கிடைக்கவில்லை.

Python interpreter இல்லை என்பதுதான் மக்கள் இந்த பட்டியலில் எதிர்பார்க்கும் காரணம், ஆனால் அது இதில் சேராது. SSH இணைக்கப்படுவதால், அந்த host-ஐ அணுக முடியும். ஆனால், அந்த module-ஐ இயக்குவதற்கு அங்கே சூழல் இல்லை:

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! என்று கூறுகிறது மற்றும் recap அதை failed-இன் கீழ் கணக்கிடுகிறது, எனவே ignore_unreachable அதை ஒருபோதும் தொடாது. அந்த host-க்கு ansible_python_interpreter-ஐ அமைக்கவும் அல்லது அதில் python3-ஐ நிறுவவும்.

ஒரு play-ல் அணுக முடியாத host-களைத் தவிர்ப்பது எப்படி

Task நிலையில், இந்த keyword module-க்கு அருகிலேயே அமையும்:

- 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-களுக்கும் default அமைப்பை உருவாக்குகிறது, ஒரு குறிப்பிட்ட 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 வினாடிகள் ஆகும். ஒரு செயலிழந்த 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-க்கும் ஒரு இணைப்பு முயற்சி செய்வதற்குப் பதிலாக, செயலிழந்த ஒவ்வொரு host-க்கும் ஒருமுறை மட்டுமே முயற்சி செய்யும். Ansible 2.8-ல் சேர்க்கப்பட்ட end_host, தற்போதைய host-க்கான play-ஐ அது தோல்வியடைந்ததாகக் குறிக்காமல் முடித்துவிடும். இணைப்பு தோல்வியடைந்தால் மட்டுமே registered result-ல் unreachable key இருக்கும், எனவே default(false) நிபந்தனையை பதிலளித்த அனைத்து host-களிலும் செல்லுபடியாகும் வகையில் வைத்திருக்கும். Play நிலையில் fact gathering முடக்கப்பட்டுள்ளது, ஏனெனில் இல்லையெனில் மறைமுகமாக இயங்கும் Gathering Facts task, உடைந்த இணைப்பைச் சந்திக்கும் முதல் task-ஆக இருக்கும்; அதற்குப் பதிலாக உங்கள் சொந்த ping task-ஐ நீங்கள் பயன்படுத்த விரும்புகிறீர்கள்.

ignore_unreachable என்பது ஒரு play keyword மற்றும் task keyword ஆகும். இதை ஒரு role-க்குள் வைப்பதற்குப் பதிலாக, playbook-ல் வாசகர்கள் பார்க்கும் வகையில் வைக்கவும், ஏனெனில் எந்தெந்த host-களை ஒரு run-ல் தவிர்க்கலாம் என்பதை இதுவே தீர்மானிக்கிறது. Playbooks மற்றும் roles-க்கு இடையிலான வேறுபாடு இத்தகைய அமைப்புகளை எந்த அடுக்கில் கையாள வேண்டும் என்பதை விளக்குகிறது.

ignore_errors ஏன் தவறான அணுகுமுறை

Ansible ஆவணங்கள் இதன் வரம்பைப் பற்றி தெளிவாகக் கூறுகின்றன. ignore_errors "ஒரு task இயங்கி 'failed' என்ற மதிப்பைத் தரும்போது மட்டுமே இது செயல்படும். வரையறுக்கப்படாத மாறிகள் (undefined variables), இணைப்புத் தோல்விகள் (connection failures), இயக்கச் சிக்கல்கள் (உதாரணமாக, விடுபட்ட packages), அல்லது syntax பிழைகள் போன்றவற்றை Ansible புறக்கணிக்க இது உதவாது."

ஒரு இணைப்புத் தோல்வி ஒருபோதும் failed: true கொண்ட task முடிவாக மாறாது. இது ஒரு தனி flag-ஆகவே வரும், Ansible முதலில் அந்த flag-ன் அடிப்படையிலேயே செயல்படும்: அந்த host 'unreachable' பட்டியலில் சேர்க்கப்பட்டு, play-லிருந்து வெளியேற்றப்படும். ஒரு play-ல் உள்ள பன்னிரண்டு task-களிலும் ignore_errors: true-ஐச் சேர்த்தாலும், SSH port மூடப்பட்டிருக்கும் host முதல் task-லேயே நின்றுவிடும். இதுவே இப்பகுதியில் ஏற்படும் பொதுவான குழப்பமாகும். பழைய playbooks-களில், குறிப்பாக முதல் playbook-ஐ VPS-ல் இயக்கும்போது எழுதப்பட்டவற்றில், இதைத் தேடி (grep) சரிபார்ப்பது நல்லது.

தடுக்கும் முன் பிழைத்திருத்தம் செய்யுங்கள்

நிரந்தரமான தடுப்பு (suppression) என்பது ஒரு fleet-ன் செயல்பாட்டைச் சிதைக்கும்; ஏனெனில், அணுக முடியாத host-க்கு யாரும் patch செய்வதில்லை. முதலில் இந்த வரிசையில் செயல்படுங்கள். இங்குள்ள அனைத்து கட்டளைகளும் தரவை வாசிப்பதற்கு மட்டுமே.

1. ansible web2 -i inventory.ini -m ansible.builtin.ping -o ஒரு module-ஐ ஒரு host-ல் இயக்கி ஒரு வரியை வெளியீடாகத் தரும்.
2. அதே கட்டளையுடன் -vvvv-ஐச் சேர்க்கவும். Ansible தான் உருவாக்கும் முழுமையான ssh கட்டளையை அச்சிடும்; இதில் target user, port, private key மற்றும் அது பயன்படுத்தும் விருப்பங்கள் (options) அனைத்தும் அடங்கும்.
3. அந்த ssh கட்டளையை நீங்களே -v மூலம் இயக்கிப் பாருங்கள். சாதாரண ssh மூலம் நுழைய முடியவில்லை என்றால், பிரச்சினை Ansible-க்குக் கீழே உள்ளது; எந்த playbook keyword-ம் அதைச் சரிசெய்யாது.
4. msg சரத்தை வாசித்து, மேலே உள்ள பட்டியலுடன் ஒப்பிட்டுப் பாருங்கள். Connection refused மற்றும் Connection timed out ஆகிய இரண்டும் வெவ்வேறு இடங்களைக் குறிக்கின்றன; ஒன்று SSH service-ஐயும், மற்றொன்று network பாதையையும் குறிக்கும்.
5. Host key verification failed.-க்கு, ssh-keygen -F web2.example.com மூலம் நீங்கள் சேமித்துள்ளதைச் சரிபார்க்கவும். server மீண்டும் கட்டமைக்கப்பட்டிருந்தால் (rebuilt), பழைய entry-ஐ ssh-keygen -R web2.example.com மூலம் நீக்கிவிட்டு, provider console-ல் சரிபார்த்த பிறகு புதிய key-ஐ ஏற்கவும். ansible.cfg-ல் host_key_checking = False-ஐ அமைப்பது பிழையை நீக்கும், ஆனால் அதே முகவரியில் வேறொரு machine பதிலளிக்கும்போது எச்சரிக்கும் சோதனையையும் அது நீக்கிவிடும்.
6. Permission denied (publickey)-க்கு, Ansible எதைப் பயன்படுத்த வேண்டும் என்று கருதுகிறது என்பதை உறுதிப்படுத்தவும். ansible-inventory -i inventory.ini --host web2, ansible_user மற்றும் ansible_port உள்ளிட்ட நடைமுறையில் உள்ள மாறிகளை (variables) அச்சிடும்.
7. SSH வேலை செய்கிறது, ஆனால் modules வேலை செய்யவில்லை என்றால், ansible web2 -m ansible.builtin.raw -a 'command -v python3 || echo none' மூலம் interpreter-ஐச் சரிபார்க்கவும். raw module ஒரு கட்டளையை shell வழியாக இயக்கும், இதற்கு target-ல் python தேவையில்லை.

இதற்குப் பிறகு மட்டுமே, ஒரு host-ஐப் புறக்கணிப்பது என்பது ஒரு பழக்கமாக இல்லாமல், ஒரு முடிவாக இருக்க வேண்டும்.

மீள்பார்வை (recap) அடைய முடியாத ஹோஸ்ட்களைத் தனித்தனியாகக் கணக்கிடுகிறது, CI பெரும்பாலும் இதைத் தவறவிடுகிறது

ansible-playbook வெற்றிகரமாக முடிந்தால் 0-ஐயும், குறைந்தது ஒரு ஹோஸ்ட் தோல்வியடைந்தால் 2-ஐயும், குறைந்தது ஒரு ஹோஸ்டை அடைய முடியாவிட்டால் 4-ஐயும் வெளியீடாகத் தரும். இந்த இரண்டு மதிப்புகளும் மூலக் குறியீட்டில் (source) பிட் ஃபிளாகளாக (bit flags) இருப்பதால், தோல்வியடைந்த ஹோஸ்ட் மற்றும் அடைய முடியாத ஹோஸ்ட் ஆகிய இரண்டையும் கொண்ட ஒரு இயக்கம் 6 என்ற வெளியீட்டைக் கொடுக்கும். ansible கட்டளையும் அதே குறியீடுகளைத் திருப்பித் தரும். இவை ஆகஸ்ட் 2026-ல் ansible-core மூலக் குறியீட்டுடன் சரிபார்க்கப்பட்டன.

இப்போது ignore_unreachable: true-ஐ அமைத்து, அதே ஏழு பணிகளைக் கொண்ட பிளே-ஐ (play) அதே செயலிழந்த ஹோஸ்டில் இயக்கவும்:

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 என்ற வெளியீட்டைக் கொடுக்கிறது. இந்த முக்கியச் சொல் (keyword) அமைக்கப்படும்போது, Ansible அந்த ஹோஸ்டுக்கான ok மற்றும் ignored எண்ணிக்கையை உயர்த்துகிறது; மாறாக dark என்று அது அழைக்கும் எண்ணிக்கையை அல்ல, இதுவே unreachable நிரப்பியை நிரப்புகிறது. சிவப்பு நிற UNREACHABLE! வரிகள் இன்னும் அச்சிடப்படுகின்றன, எனவே மீள்பார்வை மற்றும் வெளியேறும் குறியீடு தவறாக இருந்தாலும், பதிவு (log) உண்மையாகவே இருக்கும்.

பிளேபுக்கை இயக்கி $?-ஐ மட்டும் சரிபார்க்கும் ஒரு CI பணி, அந்த இயக்கத்தை வெற்றிகரமாகக் கருதும், மேலும் ஒரு இயந்திரம் அணுகப்படவில்லை என்பதை அதன் சுருக்கம் எங்கும் குறிப்பிடாது. பிளே-க்கு முன்னதாக, அடையக்கூடிய தன்மையைச் சரிபார்ப்பதை ஒரு தனிப் படியாக மாற்றவும்:

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

இது ஒவ்வொரு ஹோஸ்டுக்கும் ஒரு வரியை அச்சிடும், மேலும் ஏதேனும் ஒரு ஹோஸ்டை அடைய முடியாவிட்டால் 4 என்ற குறியீட்டை வெளியிடும். இது பைப்லைனில் (pipeline) தோல்வியடைவதற்கான ஒரு புள்ளியை உருவாக்குவதுடன், பதிவில் ஹோஸ்டின் பெயர்களையும் உங்களுக்கு வழங்கும். ping-க்கு இலக்கு கணினியில் செயல்படும் Python interpreter தேவை, எனவே இது இணைப்பை விடக் கூடுதல் விஷயங்களை உறுதிப்படுத்துகிறது, இதுவே பொதுவாக உங்களுக்குத் தேவைப்படும். பின்னர், செயல்பாட்டில் உள்ள ஹோஸ்ட்கள் மாற்றங்களைப் பெறுவதை உறுதிசெய்ய, ignore_unreachable உடன் பிளேபுக்கை இயக்கவும்.

any_errors_fatal மற்றும் max_fail_percentage ஆகியவற்றின் தொகுதி அளவிலான செயல்பாடுகள்

ஒரு தொகுப்பில் ஏதேனும் தவறு நடக்கும்போது என்ன செய்ய வேண்டும் என்பதை இந்த இரண்டு முக்கியச் சொற்களும் (keywords) தீர்மானிக்கின்றன. இவை அணுக முடியாத (unreachable) hosts-களை வெவ்வேறு விதமாகக் கையாளுகின்றன.

any_errors_fatal: true அணுக முடியாத host-க்கு எதிர்வினையாற்றுகிறது. அந்தத் தொகுதியில் உள்ள மற்ற hosts-களில் தற்போதைய பணியை Ansible முடித்துவிட்டு, அந்தத் தொகுதியில் உள்ள அனைத்து hosts-களுக்கும் play-ஐ நிறுத்திவிடும். ஒருங்கிணைந்த schema மாற்றம் போன்ற, அனைத்தும் சரியாக நடந்தால் மட்டுமே பயனுள்ள பணிகளுக்கு இதைப் பயன்படுத்தவும்.

max_fail_percentage: 30 அணுக முடியாத host-க்கு எதிர்வினையாற்றுவதில்லை. இந்தச் சரிபார்ப்பு, தோல்வியடைந்த (failed) hosts-களின் எண்ணிக்கையைத் தொகுதியின் அளவால் வகுக்கிறது. அணுக முடியாத hosts தனிப் பட்டியலில் வைக்கப்படுவதால், அவை அந்த எண்ணிக்கையில் எந்த மாற்றத்தையும் ஏற்படுத்தாது. பத்து hosts-களில் நான்கு அணுக முடியாத நிலையில் இருந்தாலும் max_fail_percentage: 10-ன் கீழ் செயல்பாடு தொடரும், ஆனால் இரண்டு hosts-களில் பணி தோல்வியடைந்தால் play நின்றுவிடும். ஆவணங்கள் மற்றொரு முக்கியமான குறிப்பைத் தருகின்றன: "நிர்ணயிக்கப்பட்ட சதவீதத்தை விட அதிகமாக இருக்க வேண்டும், சமமாக இருக்கக்கூடாது." serial: 4-ஐப் பயன்படுத்தும்போது, நான்கில் இரண்டு தோல்விகளுக்குப் பிறகு நிறுத்த வேண்டுமென்றால், 50 என்று குறிப்பிடாமல் 49 என்று எழுத வேண்டும்.

அணுக முடியாத hosts-களே ஒரு செயல்பாட்டை நிறுத்தும் ஒரு சூழல் உள்ளது. தொகுதியில் உள்ள அனைத்து hosts-களும் தோல்வியடைந்தாலோ அல்லது அணுக முடியாத நிலையில் இருந்தாலோ, Ansible-க்கு வேலை செய்ய எதுவும் இருக்காது, எனவே அது NO MORE HOSTS LEFT உடன் play-ஐ முடித்துவிடும்.

serial: fleet முழுவதும் மாற்றங்களைச் செயல்படுத்துதல்

- 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 ஆனது இரண்டு hosts-ல் முழு play-ஐயும் இயக்கி, அதை முடித்த பிறகு அடுத்த இரண்டு hosts-க்குச் செல்லும். serial: "25%" ஆனது குழுவின் அளவைப் பொறுத்து விரிவடையும். ஒரு பட்டியல், serial: [1, 5, 10], canary வடிவமாகும்: முதலில் ஒரு host, பிறகு ஐந்து, அதன் பிறகு பத்து என இயங்கும்; மீதமுள்ள hosts கடைசி தொகுதியின் அளவில் இயங்கும். max_fail_percentage என்பது ஒரு தொகுதிக்கு அளவிடப்படுகிறது, எனவே இவை இரண்டும் இணைந்து செயல்படுகின்றன. முதல் machine-ல் பிழை ஏற்பட்டால், நாற்பது machine-களில் பாதிப்பு ஏற்படுவதற்கு முன்பே செயல்பாடு நின்றுவிடும். இதுவே ஒரே control machine-லிருந்து Linux servers-ன் fleet-ஐ நிர்வகிப்பதை ஒரே கட்டளையின் மூலம் பாதுகாப்பானதாக மாற்றுகிறது.

எப்போது unreachable hosts-ஐ புறக்கணிக்க வேண்டும், எப்போது தவிர்க்க வேண்டும்

தற்செயலான பணிகளுக்கு (opportunistic work) அவற்றை புறக்கணிக்கலாம். ஒரு host செயலிழந்து இருக்கும்போது, அதைத் தவிர்ப்பதால் தரவு சேகரிப்பு (fact collection) அல்லது அவ்வப்போது செய்யப்படும் drift check ஆகியவற்றில் எந்த பாதிப்பும் ஏற்படாது; ஏனெனில் அடுத்த சுழற்சியில் அது சரிசெய்யப்படும். இதற்கு ignore_unreachable: true play level சரியான தீர்வாகும். இதனுடன் ping step-ஐ இணைப்பதன் மூலம், தவிர்க்கப்பட்ட host-களின் பெயர்கள் பயனருக்குத் தெரியும் வகையில் பதிவாகும்.

பாதுகாப்பு patch-களைப் பதிவேற்றும் போது அவற்றை ஒருபோதும் புறக்கணிக்கக்கூடாது. ஒவ்வொரு host-லும் அந்தத் திருத்தம் இருப்பதை உறுதி செய்வதே இந்தச் செயல்பாட்டின் நோக்கம். unreachable நிலையை மறைப்பது, "ஒரு server இன்னும் பாதிப்புக்குள்ளாகவே உள்ளது" என்ற உண்மையை மறைத்து, அனைத்தும் சரியாக இருப்பதாகத் தவறான பிம்பத்தைக் காட்டும். இரண்டு வாரங்களாக unreachable நிலையில் இருக்கும் ஒரு host-தான், மிக மோசமான நிலையில் இருக்க அதிக வாய்ப்புள்ளது. அந்தப் பணியை exit 4 நிலையில் முடிவடையச் செய்து, ஒரு நபர் அதை ஆய்வு செய்ய அனுமதிக்க வேண்டும்.

இரண்டு சூழல்களுக்கும் ஒரு பொதுவான விதி உண்டு: செயல்பாட்டைத் தடுத்தாலும், பதிவுகளை ஒருபோதும் மறைக்கக்கூடாது. ஒரு host தவிர்க்கப்பட்டால், அது recap-ல், CI log-ல் அல்லது monitoring alert-ல் பதிவாக வேண்டும். ஒரு play இயங்கும் சில நொடிகள் மட்டுமே Ansible-க்கு அந்த host-ன் இருப்பு தெரியும். எனவே, செவ்வாய்க்கிழமை முதல் ஒரு server செயலிழந்துள்ளதை அறிய இது சரியான இடம் அல்ல. அந்தப் பணி monitoring-க்கு உரியது. Zabbix-ஐ நிறுவும் Ansible playbook மூலம், ஒரு மதியத்திற்குள் முழு நெட்வொர்க்கையும் கண்காணிக்கும் வசதியைப் பெற முடியும்.

FAQ

Ansible-ல் ignore_errors மற்றும் ignore_unreachable ஆகியவற்றுக்கு இடையே உள்ள வேறுபாடு என்ன?

ignore_errors: true என்பது ஹோஸ்டில் இயங்கி தோல்வியடைந்த ஒரு பணிக்கு (உதாரணமாக, command non-zero exit code-ஐத் தருவது) பொருந்தும். ignore_unreachable: true என்பது Ansible-ஆல் இணைக்க முடியாத ஒரு ஹோஸ்டிற்குப் பொருந்தும்; அங்கு எந்த ஒரு module-ம் இயங்கியிருக்காது. இவை பணி முடிவுகளின் வெவ்வேறு புலங்களை (fields) ஆய்வு செய்கின்றன, எனவே ஒன்று மற்றொன்றின் நிலையை ஈடுசெய்யாது. Ansible ஆவணங்களின்படி, ignore_errors என்பது "வரையறுக்கப்படாத மாறிகள் (undefined variables), இணைப்புத் தோல்விகள், செயல்பாட்டுச் சிக்கல்கள் (உதாரணமாக, விடுபட்ட packages) அல்லது syntax பிழைகளை Ansible புறக்கணிக்கச் செய்யாது", மேலும் SSH port மூடப்பட்டிருப்பது ஒரு இணைப்புத் தோல்வியாகும்.

ignore_unreachable, play recap-லிருந்து ஹோஸ்டை மறைத்துவிடுமா?

உண்மையில், ஆம். இந்த keyword-ஐ அமைக்கும்போது, அந்த ஹோஸ்டை unreachable கணக்கில் சேர்ப்பதை Ansible நிறுத்திவிட்டு, ஒவ்வொரு பணிக்கும் ஒருமுறை ok மற்றும் ignored என கணக்கிடுகிறது, இதனால் run-ன் exit code 0 என முடிகிறது. fatal: [host]: UNREACHABLE! வரிகள் தொடர்ந்து அச்சிடப்படும், எனவே recap மற்றும் exit code தவறாக இருந்தாலும் log துல்லியமாக இருக்கும். ignored நெடுவரிசையைக் கவனிக்கவும் அல்லது ansible all -m ansible.builtin.ping -o-ஐ ஒரு தனிப் படியாக இயக்கவும், அப்போதுதான் இணைக்க முடியாத ஹோஸ்ட் non-zero exit code-ஐ உருவாக்கும்.

ஒரு ஹோஸ்டை அணுக முடியாதபோது ansible-playbook என்ன exit code-ஐத் தரும்?

அது 4-ஐத் தரும். குறைந்தது ஒரு ஹோஸ்ட் தோல்வியடைந்தால் 2-ஐத் தரும். இந்த இரண்டு மதிப்புகளும் bit flags என்பதால், தோல்வியும் அணுக முடியாத ஹோஸ்டும் இருந்தால் 6-ஐத் தரும். வெற்றிகரமான run 0-ஐத் தரும். இந்த குறியீடுகள் ஆகஸ்ட் 2026-ல் ansible-core மூலக் குறியீட்டில் சரிபார்க்கப்பட்டன. ignore_unreachable: true-ஐ அமைப்பது 4-ஐ நீக்கிவிடும், இதனால்தான் exit code-ஐ மட்டும் சோதிக்கும் pipeline-ஆல் விடுபட்ட இயந்திரத்தைக் கண்டறிய முடியாது.

பதிலளிக்காத ஹோஸ்டிற்காக ஒரு play-ன் மீதமுள்ள பகுதிகளை எப்படித் தவிர்ப்பது?

முதல் பணியை ansible.builtin.ping மற்றும் ignore_unreachable: true, register: reachable ஆகியவற்றுடன் அமைக்கவும், பின்னர் when: reachable.unreachable | default(false) நிபந்தனையின் கீழ் ansible.builtin.meta: end_host-ஐச் சேர்க்கவும். end_host அந்த ஹோஸ்டிற்கான play-ஐ தோல்வியடைந்ததாகக் குறிக்காமல் முடித்துவிடும். play-ல் gather_facts: false-ஐ அமைக்கவும், அப்போதுதான் உங்கள் ping பணி இணைப்பில் உள்ள சிக்கலைக் கண்டறியும். இந்த முறை இல்லையென்றால், செயலிழந்த ஹோஸ்ட் play-ல் தொடர்ந்து இருக்கும், மேலும் ஒவ்வொரு அடுத்த பணியும் connection timeout முடியும் வரை காத்திருக்கும்.

பாதுகாப்பு patch run-ன் போது அணுக முடியாத ஹோஸ்ட்களைப் புறக்கணிக்க வேண்டுமா?

கூடாது. ஒரு patch run என்பது அனைத்து ஹோஸ்ட்களிலும் update இருப்பதை உறுதி செய்யவே செய்யப்படுகிறது. அணுக முடியாத ஹோஸ்ட்களைப் புறக்கணிப்பது அந்த உத்தரவாதத்தை நீக்கிவிட்டு, recap-ஐ மட்டும் பச்சை நிறத்தில் காட்டும். run 4-ல் முடியட்டும்; பதிலளிக்காத ஹோஸ்ட்களின் பெயர்களைப் படித்து அவற்றைச் சரிசெய்யவும். பிழைகளை மறைப்பது (suppression) மீண்டும் மீண்டும் செய்யப்படும் தற்காலிக run-களுக்கு மட்டுமே பொருந்தும், அங்கு அடுத்தடுத்த முயற்சிகளில் விடுபட்டவை சரிசெய்யப்படும்.