Ansible-এ unreachable host কীভাবে উপেক্ষা করবেন

Unreachable host মানেই task ব্যর্থ নয়

Ansible-এ unreachable host উপেক্ষা করতে ignore_unreachable: true সেট করুন। এতে switch কাজ করবে। তবে এটি কখন ব্যবহার করতে হবে, সেটি বোঝা গুরুত্বপূর্ণ। কারণ Ansible এই দুই ধরনের সমস্যা আলাদাভাবে পরিচালনা করে। কোনো host-এ task চালানোর পর error ফেরত এলে সেটি 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 থেকে বাদ দিয়ে বাকি host-গুলোর কাজ চালিয়ে গেছে। ওই play যদি security update ইনস্টল করত, তাহলে আপনার একটি server-এ সেটি ইনস্টল হয়নি।

কোন কারণে একটি host অপ্রাপ্য হয়

Unreachable বলতে বোঝায়, কোনো module host-এ পৌঁছানোর আগেই connection ব্যর্থ হয়েছে। পড়ার মতো কোনো module output থাকে না। শুধু একটি connection error দেখা যায়। মেশিনে কাজ করা প্রথম 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 field-এ প্রকৃত কারণ থাকে। আপনি সাধারণত নিচের কারণগুলো দেখবেন:

• Connection refused: TCP connection প্রত্যাখ্যাত হয়েছে। ওই port-এ কিছু listening করছে না। sshd বন্ধ আছে, অথবা SSH অন্য port-এ সরানো হয়েছে কিন্তু inventory-তে এখনও 22 দেওয়া আছে।
• Connection timed out: কোনো উত্তরই পাওয়া যায়নি। Firewall packet drop করছে, অথবা server বন্ধ আছে। প্রতিটি প্রচেষ্টায় সম্পূর্ণ connection timeout সময় লাগে, যা default হিসেবে 10 seconds।
• Host key verification failed.: ~/.ssh/known_hosts-এ থাকা key server যে key উপস্থাপন করেছে, তার সঙ্গে মেলে না। Rebuilt VPS তার IP address ধরে রাখে কিন্তু নতুন host key পায়। তাই reinstall-এর পরে এটি প্রত্যাশিত। অন্য সময় এটি গুরুতর বিষয়।
• Permission denied (publickey): SSH উত্তর দিয়েছে এবং আপনার key প্রত্যাখ্যান করেছে। Port ঠিক আছে। এটি authentication সমস্যা, সাধারণত ভুল ansible_user দেওয়া হয়েছে অথবা key loaded নেই।
• Timeout (12s) waiting for privilege escalation prompt: connection সফল হয়েছে, কিন্তু become সফল হয়নি। sudo এমন একটি password-এর জন্য অপেক্ষা করছে যা কখনো আসছে না।

এই তালিকায় missing Python interpreter-কে অনেকে কারণ হিসেবে আশা করেন। কিন্তু এটি এখানে অন্তর্ভুক্ত নয়। SSH connection সফল হয়েছে। তাই host reachable। এরপর module চালানোর মতো কোনো interpreter নেই:

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}

এই line-এ FAILED! বলা হয়েছে। Recap-এ এটিকে failed-এর অধীনে গণনা করা হয়েছে। তাই ignore_unreachable কখনো এটিতে কাজ করবে না। ওই host-এর জন্য ansible_python_interpreter সেট করুন, অথবা সেখানে python3 install করুন।

কোনো 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 পরিবর্তন না করলে timeout 10 seconds থাকে। একটি dead server-এর বিরুদ্ধে বিশটি task থাকা play চলতে প্রায় 200 seconds অতিরিক্ত লাগে এবং log-এ বিশটি red line যোগ হয়।

তাই একবার পরীক্ষা করে 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

এতে dead host প্রতি task-এ একবারের পরিবর্তে প্রতি host-এ একবার connection attempt হয়। Ansible 2.8-এ যোগ হওয়া end_host বর্তমান host-এর জন্য play শেষ করে, তবে সেটিকে failed হিসেবে চিহ্নিত করে না। সংযোগ ব্যর্থ হলেই registered result-এ unreachable key থাকে। তাই উত্তর দেওয়া প্রতিটি host-এ শর্তটি কার্যকর রাখতে default(false) ব্যবহার করা হয়। play স্তরে fact gathering বন্ধ রাখা হয়েছে, কারণ তা না হলে implicit Gathering Facts task-ই বিচ্ছিন্ন সংযোগের মুখোমুখি হতো। এখানে আপনি নিজের ping task-টিকেই সেই পরীক্ষা করতে দিতে চান।

ignore_unreachable একটি play keyword এবং task keyword—দুইভাবেই ব্যবহার করা যায়। এটি playbook-এ এমন জায়গায় রাখুন যেখানে পাঠক সহজে দেখতে পারেন, role-এর ভেতরে নয়। কারণ কোনো run কোন host বাদ দিতে পারবে, সেটি এই keyword নির্ধারণ করে। playbook এবং role-এর বিভাজন-এ এ ধরনের setting কোন layer-এর অধীনে থাকা উচিত, তা ব্যাখ্যা করা হয়েছে।

এখানে ignore_errors ব্যবহার করা কেন সঠিক পদ্ধতি নয়

Ansible-এর documentation এই সীমাবদ্ধতা স্পষ্টভাবে উল্লেখ করে। ignore_errors "এটি তখনই কাজ করে, যখন task চালানো যায় এবং তা 'failed' মানের একটি ফলাফল ফেরত দেয়। এটি Ansible-কে undefined variable error, connection failure, execution সমস্যা (যেমন package না থাকা) বা syntax error উপেক্ষা করায় না।"

Connection failure কখনো failed: true-সহ task result-এ পরিণত হয় না। এটি আলাদা একটি flag হিসেবে আসে, এবং Ansible প্রথমে সেই flag অনুযায়ী কাজ করে: host-টি unreachable তালিকায় যায় এবং play থেকে বাদ পড়ে। একটি play-এর সব বারোটি task-এ ignore_errors: true বসালেও SSH port বন্ধ থাকা host প্রথম task-এই থেমে যায়। এই বিষয়টিই এখানে সবচেয়ে সাধারণ বিভ্রান্তির কারণ। তাই পুরোনো playbook-গুলোতে এটি খুঁজে দেখা ভালো, বিশেষ করে যেগুলো VPS-এর বিরুদ্ধে প্রথম playbook লেখা শেখার সময় তৈরি করেছিলেন।

দমন করার আগে ডিবাগ করুন

স্থায়ীভাবে suppression ব্যবহার করলে fleet-এর অবস্থা ধীরে ধীরে বিচ্যুত হয়। কারণ যে host-এ কেউ পৌঁছাতে পারে না, সেটিতে কেউ patch-ও করে না। আগে নিচের ক্রমে পরীক্ষা করুন। এখানে প্রতিটি command শুধু তথ্য পড়ে।

1. ansible web2 -i inventory.ini -m ansible.builtin.ping -o একটি host-এর বিরুদ্ধে একটি module চালায় এবং একটি line output দেয়।
2. একই command-এ -vvvv যোগ করুন। Ansible যে পূর্ণ ssh command তৈরি করে তা দেখাবে। এতে target user, port, private key এবং প্রয়োগ করা options থাকবে।
3. -v ব্যবহার করে সেই ssh command নিজে চালান। সাধারণ ssh দিয়ে প্রবেশ করা না গেলে সমস্যা Ansible-এর নিচের স্তরে রয়েছে। কোনো playbook keyword এটি ঠিক করতে পারবে না।
4. msg string পড়ে উপরের তালিকার সঙ্গে মিলিয়ে দেখুন। Connection refused এবং Connection timed out দুটি ভিন্ন জায়গার দিকে নির্দেশ করে। একটি SSH service এবং অন্যটি network path।
5. Host key verification failed.-এর ক্ষেত্রে ssh-keygen -F web2.example.com দিয়ে কী সংরক্ষণ করা আছে তা দেখুন। server পুনর্নির্মাণ করা হয়ে থাকলে ssh-keygen -R web2.example.com দিয়ে পুরোনো entry মুছে দিন। এরপর provider console-এ যাচাই করে নতুন key গ্রহণ করুন। ansible.cfg-এ host_key_checking = False সেট করলে error দূর হয়। তবে ওই address-এ অন্য machine উত্তর দিচ্ছে কি না তা জানানোর check-টিও বন্ধ হয়ে যায়।
6. Permission denied (publickey)-এর ক্ষেত্রে Ansible কোনটি ব্যবহার করবে বলে মনে করছে তা নিশ্চিত করুন। ansible-inventory -i inventory.ini --host web2 কার্যকর variables প্রিন্ট করে। এর মধ্যে ansible_user এবং ansible_port-ও থাকে।
7. SSH কাজ করলেও module কাজ না করলে ansible web2 -m ansible.builtin.raw -a 'command -v python3 || echo none' দিয়ে interpreter পরীক্ষা করুন। raw module shell-এর মাধ্যমে command চালায় এবং target-এ python থাকা প্রয়োজন হয় না।

এর পরেই host উপেক্ষা করা একটি অভ্যাস নয়, বরং একটি সিদ্ধান্ত হয়ে ওঠে।

সংক্ষিপ্তসারে unreachable আলাদাভাবে গণনা করা হয়, আর CI সাধারণত এটি শনাক্ত করতে পারে না

ansible-playbook সাফল্যের ক্ষেত্রে 0, অন্তত একটি host ব্যর্থ হলে 2 এবং অন্তত একটি host unreachable হলে 4 দিয়ে শেষ হয়। Source code-এ এই দুটি মান bit flag হিসেবে ব্যবহৃত হয়। তাই কোনো run-এ একটি host ব্যর্থ এবং একটি host unreachable হলে exit code হয় 6। ansible command একই code ফেরত দেয়। এগুলো August 2026-এ ansible-core source-এর সঙ্গে মিলিয়ে যাচাই করা হয়েছে।

এখন ignore_unreachable: true সেট করুন এবং একই dead host-এর বিরুদ্ধে একই সাতটি task-এর 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 এবং সাতটি task-এর ok রিপোর্ট করে, আর run 0 দিয়ে শেষ হয়। Keyword সেট করা থাকলে Ansible ওই host-এর জন্য dark নামে পরিচিত counter-এর পরিবর্তে ok এবং ignored counter বাড়ায়। এই counter-টিই unreachable column পূরণ করে। লাল UNREACHABLE! line-গুলো তবুও দেখানো হয়। তাই log সঠিক তথ্য দেয়, কিন্তু recap এবং exit code দেয় না।

কোনো CI job playbook চালিয়ে শুধু $? পরীক্ষা করলে সেটি run-টিকে সফল হিসেবে গণ্য করে। Summary-তে কোনো machine-কে কখনো contact করা যায়নি—এমন তথ্য থাকে না। Play চালানোর আগে reachability check-কে আলাদা step হিসেবে রাখুন:

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

এটি প্রতিটি host-এর জন্য একটি করে line দেখায় এবং কোনো host unreachable হলে 4 দিয়ে শেষ হয়। ফলে pipeline ব্যর্থ করার মতো একটি নির্দিষ্ট ফলাফল এবং log-এ host-গুলোর নাম—দুটিই পাওয়া যায়। ping চালানোর জন্য target-এ কার্যকর Python interpreter প্রয়োজন। তাই এটি শুধু connection-এর চেয়ে কিছুটা বেশি যাচাই করে, যা সাধারণত আপনার প্রয়োজনীয় বিষয়। এরপর ignore_unreachable ব্যবহার করে playbook চালান, যাতে চালু থাকা host-গুলো তাদের পরিবর্তন পায়।

একটি batch জুড়ে any_errors_fatal এবং max_fail_percentage

এই দুটি play keyword fleet-এর কোনো অংশে সমস্যা হলে কী ঘটবে তা নির্ধারণ করে। তবে unreachable host-এর ক্ষেত্রে এগুলো ভিন্নভাবে কাজ করে।

any_errors_fatal: true unreachable host শনাক্ত হলে প্রতিক্রিয়া জানায়। Ansible batch-এর বাকি host-গুলোর বর্তমান task শেষ করে। এরপর ওই batch-এর প্রতিটি host-এর জন্য play বন্ধ করে। কোনো run সম্পূর্ণভাবে সফল হতে হবে এমন ক্ষেত্রে এটি ব্যবহার করুন, যেমন সমন্বিত schema পরিবর্তনের সময়।

max_fail_percentage: 30 unreachable host শনাক্ত হলে প্রতিক্রিয়া জানায় না। এই যাচাইয়ে failed host-এর সংখ্যা batch-এর আকার দিয়ে ভাগ করা হয়। unreachable host আলাদা তালিকায় রাখা হয়, তাই তারা ওই সংখ্যায় যোগ হয় না। max_fail_percentage: 10 ব্যবহার করলে 10টি host-এর মধ্যে 4টি unreachable হলেও কাজ চলতে থাকে। কিন্তু 2টি host কোনো task-এ ব্যর্থ হলে play বন্ধ হয়। Documentation-এ আরও একটি গুরুত্বপূর্ণ সতর্কতা আছে: "The percentage set must be exceeded, not equaled." serial: 4 ব্যবহার করে 4টির মধ্যে 2টি ব্যর্থ হলে play বন্ধ করতে 50 নয়, 49 লিখতে হবে।

একটি ক্ষেত্রে unreachable host নিজেরাই run বন্ধ করে। Batch-এর প্রতিটি host failed অথবা unreachable হলে Ansible-এর কাজ চালিয়ে যাওয়ার মতো কোনো host অবশিষ্ট থাকে না। তখন Ansible NO MORE HOSTS LEFT দিয়ে play শেষ করে।

একটি পরিবর্তন ধাপে ধাপে পুরো 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 পুরো play একসঙ্গে দুইটি host-এ চালিয়ে শেষ করে, তারপর পরবর্তী দুইটি host-এ শুরু করে। serial: "25%" group-এর আকার অনুযায়ী পরিবর্তিত হয়। একটি list, serial: [1, 5, 10], canary পদ্ধতি নির্দেশ করে: প্রথমে একটি host, তারপর পাঁচটি, তারপর দশটি; এরপর অবশিষ্ট host-গুলো শেষ আকারের batch-এ চালানো হয়। max_fail_percentage প্রতিটি batch অনুযায়ী গণনা করা হয়, তাই দুটিকে একসঙ্গে ব্যবহার করা হয়। প্রথম machine-এ সমস্যা হলে run থেমে যায়, চল্লিশটি machine-এ সমস্যা হওয়ার আগেই। এ কারণেই একটি command থেকে একটি control machine থেকে Linux server fleet পরিচালনা করা নিরাপদ।

কখন unreachable host উপেক্ষা করবেন, আর কখন করবেন না

অনিয়মিত বা সুযোগসাপেক্ষ কাজের ক্ষেত্রে এগুলো উপেক্ষা করুন। কোনো fact collection run বা ঘণ্টাভিত্তিক drift check-এ কোনো host বন্ধ থাকলে সেটি বাদ দিলেও ক্ষতি হয় না, কারণ পরবর্তী pass-এ সেটি আবার পরীক্ষা করা হবে। সেখানে play level ignore_unreachable: true-ই সঠিক সমাধান। এর সঙ্গে ping step ব্যবহার করুন, যাতে বাদ পড়া host-এর নাম এমন কোথাও লেখা থাকে যা কোনো ব্যক্তি দেখবেন।

Security patch run-এর ক্ষেত্রে কখনও এগুলো উপেক্ষা করবেন না। এই run-এর মূল্য হলো প্রতিটি host-এ fix প্রয়োগ হয়েছে—এমন নিশ্চয়তা। unreachable state গোপন করলে “একটি server এখনও vulnerable” বিষয়টি একটি সম্পূর্ণ সফল recap হিসেবে দেখা যায়। যে host দুই সপ্তাহ ধরে unreachable, সেটিই সর্বাধিক পিছিয়ে থাকার সম্ভাবনা রাখে। সেই run-এর exit code 4 হওয়া উচিত, যাতে কোনো ব্যক্তি বিষয়টি পরীক্ষা করেন।

উভয় ক্ষেত্রেই একটি নিয়ম প্রযোজ্য: stop দমন করুন, record নয়। কোনো host বাদ পড়লে recap, CI log বা monitoring alert-এ তা অবশ্যই উল্লেখ থাকতে হবে। কোনো play কোনো host-এর বিরুদ্ধে চলার কয়েক সেকেন্ডের সময়েই Ansible জানে যে host-টি রয়েছে। তাই Tuesday থেকে কোনো server বন্ধ আছে কি না জানার জন্য Ansible উপযুক্ত স্থান নয়। এই কাজ monitoring-এর। আর Zabbix ইনস্টল করে এমন একটি Ansible playbook ব্যবহার করলে এক বিকেলেই পুরো fleet-এর দৃশ্যমানতা তৈরি করা যায়।

FAQ

Ansible-এ ignore_errors এবং ignore_unreachable-এর মধ্যে পার্থক্য কী?

ignore_errors: true এমন task-এর ক্ষেত্রে প্রযোজ্য, যা host-এ চলেছে এবং ব্যর্থতার ফল দিয়েছে, যেমন কোনো command non-zero exit status নিয়ে শেষ হয়েছে। ignore_unreachable: true এমন host-এর ক্ষেত্রে প্রযোজ্য, যার সঙ্গে Ansible সংযোগ করতে পারেনি এবং যেখানে কোনো module-ই চলেনি। এগুলো task result-এর ভিন্ন field পড়ে, তাই একটি অন্যটির ক্ষেত্র কভার করে না। Ansible documentation-এ বলা হয়েছে, ignore_errors “undefined variable error, connection failure, execution issue (যেমন missing package) অথবা syntax error উপেক্ষা করায় না”; আর বন্ধ SSH port একটি connection failure।

ignore_unreachable কি play recap থেকে host-কে আড়াল করে?

কার্যত, হ্যাঁ। এই keyword সেট করলে Ansible unreachable-এর অধীনে ওই host-কে গণনা করা বন্ধ করে এবং প্রতি task-এ একবার করে তাকে ok ও ignored হিসেবে গণনা করে। এরপর run 0 exit code নিয়ে শেষ হয়। fatal: [host]: UNREACHABLE! লাইনগুলো তবুও print হয়। তাই recap এবং exit code সঠিক না হলেও log সঠিক থাকে। ignored column দেখুন, অথবা ansible all -m ansible.builtin.ping -o আলাদা step হিসেবে চালান, যাতে unreachable host কোনো না কোনো পর্যায়ে non-zero exit code তৈরি করে।

কোনো host unreachable হলে ansible-playbook কী exit code ফেরত দেয়?

এটি 4 ফেরত দেয়। অন্তত একটি failed host থাকলে run 2 ফেরত দেয়। এই দুই মান bit flag হিসেবে কাজ করে। তাই failure এবং unreachable host উভয়ই থাকলে run 6 ফেরত দেয়। সফল run 0 ফেরত দেয়। এই code-গুলো August 2026-এ ansible-core source-এর সঙ্গে মিলিয়ে যাচাই করা হয়েছিল। ignore_unreachable: true সেট করলে 4 বাদ যায়। এ কারণেই শুধু exit code পরীক্ষা করা pipeline কোনো skipped machine শনাক্ত করতে পারে না।

কোনো host সাড়া না দিলে কীভাবে সেই host-এর জন্য play-এর বাকি অংশ skip করব?

প্রথম task-টিকে ansible.builtin.ping করুন এবং তার সঙ্গে ignore_unreachable: true ও register: reachable ব্যবহার করুন। এরপর ansible.builtin.meta: end_host-কে when: reachable.unreachable | default(false) condition-এর অধীনে রাখুন। end_host ওই host-এর জন্য play শেষ করে, তবে host-টিকে failed হিসেবে চিহ্নিত করে না। play-এ gather_facts: false সেট করুন, যাতে connection failure শনাক্ত করার task হিসেবে আপনার ping কাজ করে। এই pattern ব্যবহার না করলে মৃত host play-তে থেকে যায় এবং পরের প্রতিটি task-কে আবার connection timeout পর্যন্ত অপেক্ষা করতে হয়।

Security patch run-এর সময় কি unreachable host-গুলো উপেক্ষা করা উচিত?

না। Patch run-এর উদ্দেশ্য হলো প্রতিটি host update পেয়েছে—এমন নিশ্চয়তা তৈরি করা। Unreachable host উপেক্ষা করলে সেই নিশ্চয়তার বদলে green recap পাওয়া যায়। Run-কে 4 exit code নিয়ে শেষ হতে দিন, যে host-গুলো সাড়া দেয়নি তাদের নাম দেখুন এবং সমস্যাগুলো ঠিক করুন। Suppression কেবল বারবার চালানো opportunistic run-এর ক্ষেত্রে ব্যবহার করুন, যেখানে পরের pass-এ বাদ পড়া host ধরা পড়বে।