Ansible check mode और --diff का उपयोग कैसे करें

Ansible check mode क्या करता है

Ansible check mode एक dry run है: ansible-playbook --check play में मौजूद प्रत्येक host से जुड़ता है, हर module से पूछता है कि क्या वर्तमान स्थिति आपके द्वारा मांगी गई स्थिति से मेल खाती है, और बिना कुछ लिखे यह रिपोर्ट करता है कि क्या बदलाव किए जाएंगे। --diff जोड़ने पर यह उन फाइलों की पहले और बाद की सामग्री भी प्रिंट करता है जिन्हें यह प्रभावित करेगा। ये दोनों मिलकर उस सवाल का जवाब देते हैं जिसे हर वास्तविक run से पहले पूछना चाहिए: इन servers पर क्या बदलने वाला है?

Check mode आपके playbook का simulation नहीं है। सर्वर का कोई model कहीं मौजूद नहीं होता। हर module से केवल लिखने के बजाय देखने के लिए कहा जाता है। जो module read-only जवाब दे सकता है, वह changed रिपोर्ट करता है और आगे बढ़ जाता है। जो module जवाब नहीं दे सकता, वह कुछ नहीं करता और कुछ भी रिपोर्ट नहीं करता। Ansible documentation इसे एक पंक्ति में स्पष्ट करता है: "जो modules check mode का समर्थन नहीं करते, वे कुछ भी रिपोर्ट नहीं करते और कुछ भी नहीं करते।" यही वह अंतर है जहाँ dry run आपको गलत जवाब दे सकता है, इसलिए इस guide का अधिकांश हिस्सा इसी अंतर के बारे में है।

Dry run चलाएं: --check और --diff

ansible-playbook -i inventory.ini site.yml --check --diff --limit web1

-C और -D इन दो flags के संक्षिप्त रूप हैं। --limit का उपयोग जानबूझकर किया गया है। एक host का diff पढ़ा जा सकता है। बीस hosts का diff केवल scroll करने के काम आता है।

चार परिणामी शब्द पूरी रिपोर्ट का सार बताते हैं।

• ok: [web1] का अर्थ है कि task चला और कोई बदलाव नहीं हुआ। state manage करने वाले module के लिए, जैसे कि apt या template, इसका मतलब है कि उसने जांच की और state पहले से ही मेल खाती है। debug या set_fact के लिए इसका केवल यह अर्थ है कि task चला।
• changed: [web1] का अर्थ है कि module का अनुमान है कि वह कुछ लिखता। --diff के साथ, इसके ऊपर की पंक्तियाँ दिखाती हैं कि क्या। अधिकांश modules सटीक अनुमान लगाते हैं, लेकिन कुछ जो आंशिक check mode support रखते हैं, अपने docs में चेतावनी देते हैं: get_url check mode में केवल HEAD request भेजता है और कहता है कि यह गलत changed status रिपोर्ट करेगा।
• skipping: [web1] का अर्थ है कि task नहीं चला। या तो उसका when evaluate हुआ और false निकला, या module check mode में नहीं चल सकता।
• fatal: [web1] का अर्थ है कि check करते समय task विफल हो गया। यह मानने से पहले कि playbook खराब है, संदेश को पढ़ें।

--diff file modules के लिए एक unified diff प्रिंट करता है, जिसमें हटाई गई पंक्तियाँ - और जोड़ी गई पंक्तियाँ + के रूप में चिह्नित होती हैं, एक header के नीचे जिसकी पंक्तियाँ --- before और +++ after से शुरू होती हैं और destination path का नाम बताती हैं। जो modules file नहीं लिखते, वे अपना before और after प्रिंट करते हैं, इसलिए ansible.builtin.user file content के बजाय उन attributes को दिखाता है जिन्हें वह बदलता।

ansible.cfg में diff को स्थायी रूप से चालू करें ताकि आप flag को कभी न भूलें:

[diff]
always = true
context = 5

Check mode से पहले दो सस्ते checks का उपयोग करें। ansible-playbook site.yml --syntax-check किसी भी host से संपर्क किए बिना YAML और play structure को parse करता है। ansible-playbook site.yml --list-tasks उन tasks को प्रिंट करता है जो चलेंगे, जिससे आपको पता चलता है कि जिस role को आप tagged समझ रहे थे, वह वास्तव में नहीं है। दोनों में से कोई भी connect नहीं करता, इसलिए दोनों तुरंत परिणाम देते हैं।

Check mode स्वयं connect करता है। यह pattern में मौजूद हर host के लिए SSH खोलता है और facts इकट्ठा करता है, इसलिए जो host down है, उसका dry run विफल हो जाता है। यह अपने आप में एक उपयोगी संकेत है, और यही कारण है कि CI में dry run डालने से पहले unreachable hosts के बारे में playbook को क्या करना चाहिए, यह तय करना महत्वपूर्ण है।

Check mode एक नए सर्वर पर विफल क्यों होता है

यह play सही है। इसे एक ऐसे सर्वर पर --check के साथ चलाएं जिसमें अभी तक nginx नहीं है, और इसका अधिकांश हिस्सा विफल हो जाएगा।

- name: Install nginx
  ansible.builtin.apt:
    name: nginx
    state: present

- name: Write the site config
  ansible.builtin.template:
    src: site.conf.j2
    dest: /etc/nginx/conf.d/site.conf

- name: Start and enable nginx
  ansible.builtin.service:
    name: nginx
    state: started
    enabled: true

apt task changed रिपोर्ट करता है, और यह सही है: package मौजूद नहीं है, इसलिए वास्तविक run इसे install कर देगा। Check mode ने इसे install नहीं किया। इसके बाद template task विफल हो जाता है, क्योंकि इस host पर /etc/nginx/conf.d/ मौजूद नहीं है और किसी भी चीज़ ने इसे बनाया नहीं है। service task भी विफल हो जाता है, क्योंकि query करने के लिए कोई nginx unit नहीं है। इनमें से कोई भी विफलता playbook में bug नहीं है। Dry run उस state से बाहर हो गया जिसकी उसे आवश्यकता थी, और documentation का यही अर्थ है जब वह चेतावनी देता है कि check mode उस task के लिए उपयोगी output नहीं दे सकता जिसका input किसी पिछले task के बदलाव पर निर्भर करता है।

इसलिए नियम का ईमानदार संस्करण यह है: check mode उस host पर सबसे सटीक होता है जिसे playbook पहले ही converge कर चुका है, और एक नए host पर यह बहुत अधिक शोर (noisy) करता है। एक --check run जहाँ हर task ok रिपोर्ट करता है, एक converged host के बारे में एक वास्तविक बयान है, क्योंकि इसका मतलब है कि कुछ भी नहीं बदलेगा, दो चेतावनियों के साथ जो किसी भी host पर लागू होती हैं: एक skipped command task एक उत्तर के बजाय एक खाली स्थान है, और आंशिक check mode support वाला module, जैसे get_url, अभी भी अपनी changed status की गलत रिपोर्ट दे सकता है। एक बिल्कुल नए host पर, --check मुख्य रूप से आपको बताता है कि host नया है। जब आप VPS पर अपनी पहली Ansible playbook लिखते हैं, तो उम्मीद करें कि पहला dry run लाल रंग की एक दीवार जैसा होगा, और playbook को दूसरे run से परखें।

Check mode में command और shell tasks क्यों छोड़ दिए जाते हैं

ansible.builtin.command और ansible.builtin.shell को यह जानकारी नहीं होती कि आपकी command क्या करती है। किसी भी arbitrary binary को चलाने का कोई read-only तरीका नहीं है, इसलिए check mode में module इसे चलाने से मना कर देता है। task के परिणाम में skipped: true होता है और संदेश Command would have run if not in check mode होता है, और आपका output skipping: [web1] दिखाता है।

module documentation इसके check mode support को "आंशिक" (partial) बताती है, और इसके लिए सुझाया गया workaround creates और removes है। task को एक creates path दें और check mode कम से कम file test का मूल्यांकन कर पाएगा:

- name: Extract the release bundle
  ansible.builtin.command: /usr/bin/tar xf /tmp/app.tar.gz -C /opt/app
  args:
    creates: /opt/app/bin/app

यदि /opt/app/bin/app पहले से मौजूद है, तो check mode Would not run command since '/opt/app/bin/app' exists रिपोर्ट करता है, जो एक सटीक उत्तर है। यदि path मौजूद नहीं है, तो आपको Command would have run if not in check mode मिलता है, जो कि एक सटीक उत्तर है। creates के बिना, वह task आपके dry run में एक खाली जगह की तरह होता है।

इसका दुष्प्रभाव खाली जगह से भी बुरा होता है। एक छोड़ा गया (skipped) command task अभी भी एक परिणाम दर्ज करता है, और उस परिणाम में stdout होता है, लेकिन वह एक खाली string होती है, क्योंकि कुछ भी run नहीं हुआ। अगले task की condition उस खाली string के आधार पर मूल्यांकन करती है और चुपचाप गलत branch चुन लेती है: एक version check को कोई version नहीं मिलता, और 'active' in svc.stdout जैसा test false हो जाता है। आपका playbook एक वास्तविक run में एक उत्तर देता है और dry run में दूसरा, बिना किसी error के, जो इस पूरे feature की सबसे भ्रमित करने वाली विफलता है। error 'dict object' has no attribute 'stdout' एक अलग प्रकार के skip से संबंधित है: एक task जिसे उसकी when के false होने के कारण छोड़ दिया गया है, वह एक ऐसा परिणाम दर्ज करता है जिसमें stdout key होती ही नहीं है।

check_mode: false, और इसका सही उपयोग

किसी task पर check_mode: false का अर्थ है "इसे वास्तव में चलाएं, भले ही --check सक्रिय हो"। यह skipped-command समस्या का समाधान है, और यह केवल उन्हीं tasks पर सुरक्षित है जो केवल डेटा पढ़ते हैं (read-only)।

- name: Read the installed app version
  ansible.builtin.command: /usr/local/bin/app --version
  register: app_version
  check_mode: false
  changed_when: false

वह task दोनों modes में ईमानदार रहता है। यह एक version पढ़ता है और कुछ भी लिखता नहीं है, changed_when: false इसे उस बदलाव की रिपोर्ट करने से रोकता है जो उसने नहीं किया है, और check_mode: false यह सुनिश्चित करता है कि dry run के दौरान app_version.stdout में खाली string के बजाय वास्तविक version मौजूद रहे, ताकि उस पर आधारित conditions सही ढंग से evaluate हो सकें।

किसी भी अन्य स्थान पर paste करने से पहले इस keyword को शाब्दिक रूप से समझें। check_mode: false वाला task ansible-playbook --check के दौरान आपके servers पर बदलाव लिखता है। इसे किसी apt task या template task पर लगाने से dry run तो साफ-सुथरा दिख सकता है, लेकिन वह फिर dry run नहीं रह जाता। जब किसी writing task को सुरक्षित नहीं बनाया जा सकता, तो उसे इसके बजाय guard करें:

- name: Apply the database migration
  ansible.builtin.command: /usr/local/bin/app migrate --apply
  when: not ansible_check_mode

ansible_check_mode एक magic variable है जिसे Ansible check run के दौरान true पर set करता है। इसका विपरीत keyword भी मौजूद है। check_mode: true किसी task को हमेशा check mode में ही रखता है, वास्तविक run के दौरान भी, जो इसे एक drift probe में बदल देता है: परिणाम को register करें, और changed रिपोर्ट का अर्थ है कि host अब उस स्थिति में नहीं है जो task द्वारा अपेक्षित है।

कोई task हर बार changed क्यों रिपोर्ट करता है

Playbook को लगातार दो बार चलाएं, बीच में कुछ भी न बदलें। दूसरी बार चलाने पर हर task को ok रिपोर्ट करना चाहिए। यदि कोई task अभी भी changed रिपोर्ट कर रहा है, तो इसका मतलब है कि या तो module उस state को देख नहीं पा रहा है जिसे वह manage करता है, या फिर आप जो input दे रहे हैं वह स्थिर नहीं है। दोनों ही समस्याओं को ठीक किया जा सकता है, और इन्हें नजरअंदाज नहीं किया जाना चाहिए।

• command और shell जिनमें creates, removes या changed_when न हो, वे हर बार changed रिपोर्ट करते हैं, क्योंकि module के पास यह जानने का कोई तरीका नहीं होता कि कुछ हुआ है या नहीं। इसमें creates जोड़ें, या output में किसी string के विरुद्ध changed_when सेट करें।
• ansible.builtin.file के साथ state: touch का उपयोग करने पर यह हर बार changed रिपोर्ट करता है, क्योंकि file को touch करने से उसका timestamp अपडेट हो जाता है। यदि आप केवल owner या mode सेट करना चाहते हैं, तो state: file का उपयोग करें।
• यदि किसी template का rendered output बदलता रहता है, तो वह हर बार file को फिर से लिखता है। ansible_date_time से प्राप्त timestamp, now() की कॉल, या हर बार नया generate होने वाला password, ये सभी अलग-अलग bytes उत्पन्न करते हैं, इसलिए module सही तरीके से बदलाव की रिपोर्ट करता है। बदलते हुए मान (moving value) को template से हटा दें।
• password: "{{ pw | password_hash('sha512') }}" के साथ ansible.builtin.user हर बार बदलता है, क्योंकि password_hash हर बार एक random salt चुनता है, इसलिए परिणामी hash कभी भी /etc/shadow में मौजूद hash से मेल नहीं खाता। किसी स्थिर मान से प्राप्त एक स्पष्ट salt का उपयोग करें।
• package module पर state: latest तब changed रिपोर्ट करता है जब कोई upgrade उपलब्ध होता है। यह सही व्यवहार है। यही कारण है कि state: latest का उपयोग करने पर आपको ऐसी playbook मिलती है जिसका परिणाम आप predict नहीं कर सकते। state: present का उपयोग करें और सोच-समझकर upgrade करें।
• बिना creates के किसी URL पर point किया गया ansible.builtin.unarchive हर बार archive को फिर से download करता है, और जिन archive types की वह destination से तुलना नहीं कर सकता, उन्हें वह फिर से unpack भी करता है। इसे एक creates path दें।

इनके बीच अंतर पता करने का सबसे तेज़ तरीका --diff है। यदि कोई task changed कहता है और diff में अलग bytes दिखाई देते हैं, तो आपका input अस्थिर है। यदि यह changed कहता है और diff में कुछ भी दिखाई नहीं देता, तो module यह नहीं बता पा रहा है कि उसने क्या बदला है, जिसका अर्थ आमतौर पर command task या timestamp जैसा केवल metadata लिखने वाला कार्य है।

किसी शोर मचाने वाले (noisy) task को शांत करने के लिए changed_when: false का उपयोग न करें। यह रिपोर्ट को दबा देता है, जिससे notify कभी trigger नहीं होता और service को restart करने वाला handler कभी नहीं चलता। इसके बजाय task को ठीक करें।

ब्लास्ट रेडियस को सीमित करना: --limit, --tags और --step

Check mode आपको बताता है कि क्या बदलाव होंगे। ये flags तय करते हैं कि एक बार में कितनी मशीनों पर बदलाव लागू होंगे।

--limit प्ले (play) को इन्वेंट्री के एक सबसेट तक सीमित कर देता है। यह वही patterns लेता है जो hosts: लेता है, इसलिए --limit web1 और --limit 'webservers:!web3' दोनों काम करते हैं। पैटर्न को quotes में लिखें। इंटरैक्टिव bash सेशन में बिना quotes वाला !, exclamation mark पर history expansion को ट्रिगर कर देता है, और Ansible के देखने से पहले ही आपका शेल कमांड को बदल देता है।

पैटर्न पर भरोसा करने से पहले उसे कन्फर्म करें। ansible-playbook site.yml --limit 'webservers:!web3' --list-hosts उन hosts को प्रिंट करता है जो मैच हुए हैं और किसी से भी कनेक्ट किए बिना बाहर निकल जाता है। जो पैटर्न किसी से मैच नहीं होता, वह सुरक्षित है, क्योंकि Ansible पूरी इन्वेंट्री पर वापस नहीं जाता है। यह एक चेतावनी प्रिंट करता है कि यह होस्ट पैटर्न से मैच नहीं कर सका, और फिर एक एरर के साथ बाहर निकल जाता है जिसमें कहा जाता है कि इन्वेंट्री, होस्ट पैटर्न और --limit के कारण कोई भी होस्ट टारगेट के लिए नहीं बचा है। इन्वेंट्री फाइल उन ग्रुप्स को कैसे परिभाषित करती है, यह जानना ही पैटर्न को पूर्वानुमानित बनाता है।

--tags deploy केवल टैग किए गए tasks को चलाता है, और --skip-tags packages बाकी सब कुछ चलाता है। --list-tags उपलब्ध टैग्स को प्रिंट करता है। जब कोई प्ले इतना बड़ा हो जाए कि आप उसे पूरा चलाने के इच्छुक न हों, तब टैग्स बहुत उपयोगी होते हैं, जो एक लंबे प्लेबुक को roles में विभाजित करने के कारणों में से एक है।

--start-at-task "Write the site config" एक विफल रन को किसी विशिष्ट task से फिर से शुरू करता है। रिकवरी के लिए इसका उपयोग करें, और इसके प्रभाव को समझें: उस task से पहले की हर चीज छोड़ दी जाती है, जिसमें वे tasks भी शामिल हैं जो facts सेट करते हैं या उन variables को रजिस्टर करते हैं जिन्हें बाद के tasks पढ़ते हैं।

--step प्रत्येक task से पहले प्रॉम्प्ट करता है और आपके yes, no, या continue कहने का इंतज़ार करता है। यह धीमा है, लेकिन जब आप पहली बार कुछ विनाशकारी (destructive) चला रहे हों, तो यह सही टूल है, क्योंकि आप बीस tasks के बाद रुकने के बजाय दो tasks के बीच में ही रुक सकते हैं।

serial के साथ बदलाव लागू करें

डिफ़ॉल्ट रूप से Ansible अगले task को शुरू करने से पहले play में मौजूद हर host पर एक task चलाता है। यह तेज़ है, लेकिन इसका मतलब यह है कि एक खराब task उसी सेकंड में पूरे fleet तक पहुँच जाता है। जब तक आप error पढ़कर Ctrl-C दबाते हैं, तब तक बदलाव हर जगह लागू हो चुका होता है।

serial play को batches में विभाजित करता है। पूरी play पहले batch पर चलती है, फिर अगले पर।

- name: Roll out the web tier
  hosts: webservers
  serial: [1, 5, "30%"]
  max_fail_percentage: 0
  tasks:
    - name: Deploy the release
      ansible.builtin.include_role:
        name: webapp

पहला batch एक host का होता है। यदि वह ठीक रहता है, तो दूसरा batch पाँच hosts का होता है, और उसके बाद के हर batch में play के कुल hosts का 30 प्रतिशत हिस्सा होता है। max_fail_percentage: 0 किसी भी batch में किसी भी host के fail होते ही बाकी play को abort कर देता है, क्योंकि threshold पार होना चाहिए और कोई भी failure शून्य से अधिक होता है। एक-मशीन की गारंटी पहले batch से मिलती है, उस setting से नहीं: एक ऐसा release जो हर जगह खराब हो, वह पहले batch के उस एक host पर fail हो जाएगा और वहीं रुक जाएगा। जो failure केवल पाँच-host वाले batch में दिखाई देता है, वह उस batch के अन्य hosts तक पहले ही पहुँच चुका होता है, क्योंकि Ansible अगले task को शुरू करने से पहले पूरे batch में हर task को चलाता है। any_errors_fatal: true अधिक सख्त संस्करण है, जो पहले host के fail होते ही सभी के लिए play को समाप्त कर देता है।

पहले एक host पर चलाना paranoia नहीं है, और इसका कारण विशिष्ट है। Inventory groups में बदलाव (drift) आ जाता है। दूसरों के छह महीने बाद जोड़ा गया कोई सर्वर शायद अलग distribution release चला रहा हो, या उसमें किसी ने हाथ से कोई service install की हो, या उसकी disks अलग तरह से व्यवस्थित हों। Playbook उस group के लिए सही हो सकती है लेकिन उस एक host के लिए गलत, और किसी converged host पर dry run करने से यह पता नहीं चलेगा। Linux servers के fleet को manage करना मुख्य रूप से बदलाव के असर से पहले उस अलग (odd) host को खोजने का अभ्यास है।

चीजों को चलाने का क्रम

1. ansible-playbook site.yml --syntax-check बिना किसी नेटवर्क के YAML और संरचना संबंधी गलतियों को पकड़ता है।
2. ansible-playbook site.yml --limit web1 --list-hosts यह सिद्ध करता है कि आपका पैटर्न उसी से मेल खाता है जिससे आप मेल खाना चाहते हैं।
3. ansible-playbook site.yml --limit web1 --check --diff यह एक ड्राई रन है। diff को पढ़ें।
4. ansible-playbook site.yml --limit web1 --diff इसे उस एक होस्ट पर लागू करें।
5. चरण 4 को फिर से चलाएँ। सब कुछ ok रिपोर्ट करना चाहिए। जो कुछ भी अभी भी changed है, वह एक ऐसा कार्य है जिसे बाकी फ्लीट (fleet) को प्रभावित करने से पहले ठीक करना आवश्यक है।
6. ansible-playbook site.yml --check --diff अब पूरे इन्वेंट्री में एक सार्थक उत्तर देता है, क्योंकि कन्वर्ज्ड (converged) होस्ट शांत हैं और जो शेष है वह वास्तविक डेल्टा (delta) है।

चरण 3 के बारे में एक चेतावनी। --diff फाइल की सामग्री को आपके टर्मिनल और आपके CI जॉब लॉग में प्रिंट करता है, इसलिए एक टेम्प्लेट जो डेटाबेस पासवर्ड रेंडर करता है, वह उस पासवर्ड को लॉग में रेंडर कर देता है। उस आउटपुट को दबाने के लिए उस टास्क पर diff: false सेट करें, या पूरे परिणाम को छिपाने के लिए no_log: true का उपयोग करें, और मान (value) को रिपॉजिटरी के बजाय एक एन्क्रिप्टेड Ansible Vault फाइल में रखें।

FAQ

क्या ansible-playbook --check सर्वर पर कुछ बदलता है?

नहीं, केवल एक अपवाद को छोड़कर जिसे आप नियंत्रित करते हैं। चेक मोड में हर module को लिखने के बजाय रिपोर्ट करने के लिए कहा जाता है, और जो modules ऐसा नहीं कर सकते वे कुछ भी रिपोर्ट नहीं करते और न ही कुछ करते हैं। अपवाद check_mode: false task keyword है, जो उस एक task को --check रन के दौरान भी वास्तव में निष्पादित (execute) होने के लिए मजबूर करता है। ड्राई रन पर भरोसा करने से पहले अपने playbooks और roles में check_mode: false खोजें, और पुष्टि करें कि प्रत्येक match केवल state को पढ़ने वाला task है।

--check और --diff के बीच क्या अंतर है?

--check यह तय करता है कि क्या कुछ वास्तव में रन होगा। --diff यह तय करता है कि आपको कितनी जानकारी दिखाई देगी। --check अकेले आपको यह बताता है कि कोई फाइल बदल जाएगी। --diff अकेले बदलाव को लागू करता है और आपको बदली हुई लाइनें दिखाता है। इन्हें एक साथ उपयोग करें ताकि आप ड्राई रन को वास्तव में पढ़ सकें, और --diff को वास्तविक रन के लिए भी चालू रखें, इसके लिए ansible.cfg में [diff] के तहत always = true सेट करें।

मेरा Ansible task हर रन पर changed क्यों रिपोर्ट करता है?

क्योंकि module उस state को नहीं देख पाता जिसे वह manage करता है, या जो value आप उसे देते हैं वह हर बार अलग होती है। command और shell हमेशा changed रिपोर्ट करते हैं जब तक कि आप creates या changed_when न जोड़ें। state: touch के साथ file डिजाइन के अनुसार बदलता है। एक template जो timestamp या नया जनरेट किया गया पासवर्ड रेंडर करता है, वह हर रन पर अलग bytes बनाता है, इसलिए फाइल वास्तव में हर बार फिर से लिखी जा रही है। playbook को लगातार दो बार चलाएं: दूसरे पास पर जो भी अभी भी changed है, वही वह task है जिसे ठीक करने की आवश्यकता है।

ड्राई रन के दौरान मेरे command और shell tasks क्यों छोड़ (skip) दिए जाते हैं?

क्योंकि किसी भी मनमानी command को चलाने का कोई read-only तरीका नहीं है। चेक मोड में command module Command would have run if not in check mode संदेश के साथ skipped: true सेट करता है। creates या removes जोड़ें ताकि चेक मोड फाइल टेस्ट का मूल्यांकन कर सके। केवल state पढ़ने वाले task के लिए, changed_when: false के साथ check_mode: false सेट करें, ताकि registered result में ड्राई रन के दौरान वास्तविक आउटपुट रहे और उस पर आधारित conditions काम करती रहें।

चेक मोड नए सर्वर पर विफल क्यों होता है लेकिन मौजूदा सर्वर पर पास हो जाता है?

क्योंकि चेक मोड वह state नहीं बनाता जिस पर बाद के tasks निर्भर करते हैं। nginx के बिना किसी host पर ड्राई रन install को changed रिपोर्ट करता है, फिर उस task पर विफल हो जाता है जो /etc/nginx/conf.d/ में लिखता है, क्योंकि वह directory कभी बनाई ही नहीं गई थी। यह अपेक्षित व्यवहार है। चेक मोड उन hosts के लिए drift detector है जिन्हें playbook पहले ही converge कर चुका है। यह पहले रन को validate नहीं कर सकता। नए host पर, playbook को एक मशीन पर लागू करें और दूसरे रन को पढ़ें।