Ansible: फ़ीचर: ब्लॉकों पर लूप तक की अनुमति दें या शामिल करें

को निर्मित 27 सित॰ 2018 · 29टिप्पणियाँ · स्रोत: ansible/ansible

सारांश

यह काफी उपयोगी होगा यदि आप एक से अधिक एकल कार्यों पर लूप कर सकते हैं।

उदाहरण के लिए यदि आपको कुछ प्रगति के लिए रिमोट सिस्टम को मतदान करना है और साथ ही आप इस प्रगति को किसी अन्य बैकएंड पर धक्का देना चाहते हैं, तो आप यह कर सकते हैं:

- hosts: localhost
  tasks:
  - name: Start a long-running task
    uri:
      url: https://some-service/v1/put/new_job
      body: { foo: bar }
    register: new_job

  - until: job_status.json.message in ['Finished', 'Failed']
    block:
    - name: Get job status
      uri:
        url: https://some-service/v1/get/new_job
      register: job_status

    - name: Report job status to web service
      uri:
        url: https://backend-system/v1/post/job_status
        body: '{{ job_status.json }}'

इसके कई उपयोग हैं।

विषय वर्ग

फ़ीचर आइडिया

घटक का नाम

सार

affects_2.8 feature has_pr core

स्रोत

dagwieers

👍69 ❤8

सबसे उपयोगी टिप्पणी

यह स्वाभाविक है कि एक ब्लॉक दोहराने योग्य होना चाहिए। अन्यथा, यह बहुत उल्टा है। यह भ्रमित करता है।

और ऐसा लगता है कि एक से अधिक कथन वाली लूप वाली प्लेबुक लिखने का कोई तरीका नहीं है। कोई प्रोग्रामिंग भाषा इतनी सीमित नहीं है।

ramon-garcia 30 नव॰ 2018

👍25

सभी 29 टिप्पणियाँ

https://github.com/ansible/ansible/issues/13262

mkrizek 27 सित॰ 2018

@mkrizek हम्म, मैंने कीवर्ड के विभिन्न संयोजनों की खोज की, और वह बाहर नहीं रहा :-(

उस ने कहा, मैंने until: के साथ block: , include: और include_tasks उपयोग करने का प्रयास किया, लेकिन पहला विफल रहता है, और 2 अन्य केवल एक बार शामिल फ़ाइल चलाते हैं .

- hosts: localhost
  tasks:
  - include: taskboot.yml
    until: 5|random == 5

लेकिन स्पष्ट रूप से लूपिंग केवल loop: का उपयोग करते समय काम करता है?

- hosts: localhost
  tasks:
  - include: taskboot.yml
    loop: [ 1, 2, 3, 4, 5 ]

dagwieers 27 सित॰ 2018

मैं जो कुछ भी कोशिश करता हूं, until: का उपयोग करके $ include: और include_tasks: के साथ काम नहीं करता है।

- hosts: localhost
  tasks:
  - include: taskbook.yml
    until: false
    retries: 5
    delay: 1

dagwieers 27 सित॰ 2018

हाँ, until शामिल करने के लिए मान्य तर्क नहीं है, https://github.com/ansible/ansible/pull/46177 देखें।

mkrizek 27 सित॰ 2018

@mkrizek दूसरे शब्दों में, हमें जो चाहिए वह संभव नहीं है, न तो ब्लॉक पर या न ही शामिल है।

इसलिए मैं इसे खुला रखूंगा, लेकिन शीर्षक बदल दिया।

dagwieers 27 सित॰ 2018

👎1

हमारे पास "टास्किफाई" करने के लिए एक खुला प्रस्ताव है, जो चीजों को उन पर काम करने तक की अनुमति देगा।

https://github.com/ansible/proposals/issues/136

हालाँकि, मुझे विश्वास नहीं है कि इस सुविधा का समर्थन करने के लिए ब्लॉकों को बढ़ाया जाना चाहिए।

sivel 27 सित॰ 2018

@sivel और कार्यक्षमता को ब्लॉक में विस्तारित न करने का क्या कारण होगा? जैसा कि अगर यह काम करेगा तो यह एक स्वाभाविक बात होगी। (यानी एक नाटक के भीतर हर निर्माण को लूप करने में सक्षम होना)

dagwieers 27 सित॰ 2018

👍6

ब्लॉक वर्तमान में 'स्थैतिक' समूह हैं, उन पर लूप को सक्षम करना (न कि केवल कार्य उन्हें विरासत में मिला है) उन्हें गतिशील बनाने की आवश्यकता होगी ... जैसा कि हमने include: के साथ देखा, इसके कई परिणाम हैं जो तुरंत स्पष्ट नहीं होते हैं।

bcoca 27 सित॰ 2018

❤1

@bcoca का उल्लेख करने के लिए, ऐसा करने के लिए हमें block को पदावनत करना होगा और block_dynamic और block_static जैसी किसी चीज़ से बदलना होगा।

साथ ही, ansible का _प्रत्येक_ उपयोगकर्ता ब्लॉक का उपयोग करता है, चाहे वह स्पष्ट हो, या हमारा आंतरिक निहित उपयोग। वे एक मौलिक बिल्डिंग ब्लॉक हैं कि कैसे कार्यों का प्रतिनिधित्व और निष्पादन किया जाता है। इस तरह की एक अभिन्न विशेषता को बदलने से अप्रत्याशित मुद्दों को जन्म देना निश्चित है।

sivel 27 सित॰ 2018

👍3 👎1

किसी भी मामले में, दस्तावेज़ीकरण कोई विवरण नहीं देता है, या यह भी चर्चा नहीं करता है कि क्या काम करना चाहिए और क्या नहीं। "लूप" और जब तक-लूप के बीच कोई वास्तविक अंतर नहीं है, यह सुनिश्चित नहीं है कि हम इसे और अधिक स्पष्ट समग्र कैसे बना सकते हैं। उम्मीद यह है कि "लूप" के लिए जो काम करता है वह भी लूप तक काम करता है।

dagwieers 28 सित॰ 2018

👍6

मैं दोनों करता हूं, लूप को शामिल करने के लिए/पुनः प्रयास करने की अनुमति देता हूं और फिर स्पष्ट रूप से दस्तावेज करता हूं कि वे कैसे काम करते हैं ...

bcoca 28 सित॰ 2018

👍1

काम को शामिल करने के तरीके के बारे में थोड़ी सी जानकारी प्रदान करने के लिए, यह है कि गतिशील शामिल एक आंतरिक ट्रिगर के अधिक होते हैं, जो निष्पादन को लपेटने वाली किसी चीज़ के विपरीत होता है।

जैसे, टास्क_एक्ज़ीक्यूटर शॉर्ट सर्किट में शामिल होता है, जो रणनीति को दर्शाता है कि उसे एक फ़ाइल को पढ़ना चाहिए और टीक्यूएम में टास्क ब्लॉक डालना चाहिए, जिसे बाद में टास्क_एक्सक्यूटर द्वारा संसाधित किया जाएगा।

इसके कारण, माता-पिता में रोल अप के रूप में राज्य की कोई ट्रैकिंग नहीं है। तो एक लूप तक, जो असफल/सफलता परिदृश्य के कुछ संस्करण पर भरोसा करेगा, केवल यह संदर्भित करेगा कि रणनीति को ऊपर वर्णित अनुसार करने के लिए कहा गया था या नहीं। किस मामले में, इसे हमेशा सफल होना चाहिए।

किसी भी मामले में, ऑपरेशन का तरीका यह है कि जब तक शर्तों का निरीक्षण नहीं किया जाता है, तब तक हम शॉर्ट सर्किट करते हैं। अगर हमने अभी "इसे काम किया" है, तो यह निश्चित रूप से वह नहीं करेगा जो एक व्यक्ति अपेक्षा करता है। लोग जो अपेक्षा करते हैं, उसे करने के लिए, उत्तर/प्रस्ताव#136 को क्रियान्वित करने की आवश्यकता होगी।

sivel 28 सित॰ 2018

जब तक इस मामले में शामिल कार्यों से सेट या पंजीकृत वर्र्स पर भरोसा करना होगा क्योंकि इसमें शामिल होने का पंजीकरण बेकार होगा ...

bcoca 28 सित॰ 2018

@dagwieers दूसरा धागा अब बंद है। लेकिन यह हालिया सुझाव (उपरोक्त @sivel टिप्पणी) बिल्कुल नया है:

https://github.com/ansible/ansible/issues/46203#issuecomment -425111123

और आप कह रहे हैं कि हम बाद में किसी और के साथ आने की संभावना को खुला छोड़ना चाहते हैं, ताकि वे अपनी पीठ से ब्लॉकों को लूप करने के लिए पीआर कर सकें। तब कम से कम हम उनके लिए इसे बिल्कुल स्पष्ट कर सकते थे, ताकि इसे एक अलग और नया block_dynamic: बनाया जा सके, और पारंपरिक स्थिर block: बरकरार न रखा जा सके? क्या यह सभी के लिए अधिक अर्थपूर्ण नहीं होगा ? क्या हम सब समय से पहले इस पर सहमत हो सकते हैं? क्योंकि मैं इस विचार से सहमत हूं। सभी समान कारणों से - यह उन अन्य मौजूदा सामानों को तोड़ने से रोकने में मदद करने वाला है जिन पर हम भरोसा करते हैं। अभी भी किसी के साथ आने की संभावना की अनुमति देते हुए, वास्तव में इसे लागू करने के लिए पीआर बनाने का प्रयास करें। क्या हम वास्तव में चाहते हैं कि वे सर्वोत्तम संभव कार्य करें और ऐसे। तब हमें कम से कम इसे स्पष्ट रूप से निर्दिष्ट करना चाहिए। अगर हम पहले से ही जानते हैं कि समय से पहले। ऐसा लगता है कि अब क्या हो रहा है?

dreamcat4 28 सित॰ 2018

इसे यहाँ लिंक करना https://github.com/ansible/ansible/issues/16621

mkrizek 31 अक्तू॰ 2018

+1 इस सुविधा को लागू करने के लिए

deatheros 5 नव॰ 2018

👎2

ramon-garcia 30 नव॰ 2018

👍25

ऐसा लगता है कि Ansible में, अगर किसी को कुछ जटिल करने की ज़रूरत है, तो उसे एक एक्शन प्लगइन लिखना चाहिए। यही हम करने जा रहे हैं।

यहाँ एक के कई उदाहरण हैं:
https://github.com/ansible/ansible/tree/devel/lib/ansible/plugins/action

सादर

ramon-garcia 30 नव॰ 2018

यह बिल्कुल कमी है। Ansible अब तक मेरी अधिकांश ज़रूरतों के लिए एकदम सही रहा है, लेकिन ऐसा लगता है कि ब्लॉक की क्षमताओं का विस्तार करने से Ansible बहुत बेहतर समाधान हो जाएगा।

Freeze 26 मार्च 2019

👍7

मैंने until को include_tasks में उपयोग करने का प्रयास किया और यह काम नहीं किया।

वर्कअराउंड के रूप में मैंने जो किया वह एक वाईएमएल फ़ाइल बनाना था जिसमें कार्य शामिल था ( loop.yml ) और खुद को रिकर्सिवली कॉल करें ( recursive.yml ) जबकि स्थिति अभी भी संतुष्ट नहीं है।

_recursive.yml:_

---

- name: 'checking {{ watch_job }} status (recursive)'
  include_tasks: 'loop.yml'

- name: 'count ({{ watch_count | int + 1 }})'
  set_fact:
    watch_count: '{{ watch_count | int + 1 }}'

- name: 'retries ({{ (watch_timeout | int / watch_poll | int) | int }})'
  set_fact:
    watch_retries: '{{ (watch_timeout | int / watch_poll | int) | int }}'

- name: 'timeout ({{ watch_timeout }} seconds)'
  fail: 
    msg: "Timeout of {{ watch_timeout }} seconds exceeded ({{ watch_retries }} retries)"
  when: (not watch_status.finished) and (watch_count | int > watch_retries | int)

- name: 'wait for {{ watch_poll }} seconds'
  wait_for:
    timeout: '{{ watch_poll | int }}'
  when: not watch_status.finished

- name: 'call itself recursively'
  include_tasks: 'recursive.yml'
  when: not watch_status.finished

उपरोक्त फ़ाइल में, मैंने बहुत अधिक समय लेने के मामले में एक टाइमआउट शामिल किया है (यह एक ऐसी भूमिका में है जो मेजबानों में चल रहे आउटपुट को दिखाता है )।

आदर्श समाधान नहीं, लेकिन मेरे लिए काम किया और उपरोक्त करने के लिए until का उपयोग करके बदलना अपेक्षाकृत आसान था।

lucasbasquerotto 27 मार्च 2019

👍12 ❤1

इस सुविधा के लिए +1!

efazenda 7 मई 2019

👍6 👎5

woopstar 7 मई 2019

👍6 👎5

+1 के लिए ब्लॉक पर लूप होने तक

wahab-icp 27 मई 2019

👎5 👍1

मैं ब्लॉक पर सभी मॉड्यूल पर सफलता के लिए until (असीम रूप से) करने का एक तरीका खोज रहा हूं और मैं इसे rescue के साथ rescue include_tasks के साथ करने में कामयाब रहा

मैं नियमित until का उपयोग नहीं कर सका क्योंकि आईपी समय के साथ बदल रहा है और इसे रन पर संशोधित करना पड़ा

Wait_until_success.yml

- name: 'Wait until success'
  block:
    - name: Get server updated ip
      uri:
        url: https://localhost/ip
        return_content: yes
        status_code: 200
      register: ip

    - name: ssh to the server
      wait_for:
        host: "{{ ip }}"
        port: 22
        timeout: 30
        state: started
  rescue:
    - debug:
        msg: "Failed to connect - Retrying..."
    - include_tasks: wait_until_success.yml

matanbaru 28 मई 2019

❤18

कई बार कोशिश करने के बाद विफल होने के तरीके के साथ @matanbaru के समान

- name: 'Wait until success'
  block:
    - name: Set the retry count
      set_fact:
        retry_count: "{{ 0 if retry_count is undefined else retry_count|int + 1 }}"

    - name: Get server updated ip
      uri:
        url: https://localhost/ip
        return_content: yes
        status_code: 200
      register: ip

    - name: ssh to the server
      wait_for:
        host: "{{ ip }}"
        port: 22
        timeout: 30
        state: started
  rescue:
    - fail:
        msg: Ended after 5 retries
      when: retry_count|int == 5

    - debug:
        msg: "Failed to connect - Retrying..."

    - include_tasks: wait_until_success.yml

Ovski4 20 नव॰ 2019

🚀12 👍2 ❤1

+1 क्या आप कृपया पुनः प्रयास करें-लूप में जोड़ सकते हैं!
बिल्कुल "होना चाहिए" सुविधा!

frsauvage 21 जून 2020

👍1

chris93111 4 जुल॰ 2020

👎2 👍1

karolyi 29 जुल॰ 2020

मैंने इसे अभी के लिए योगदानकर्ताओं के लिए बंद कर दिया है। +1 टिप्पणियां जोड़ना बहुत शोरगुल वाला है। भविष्य के संदर्भ के लिए, समस्या के मुख्य भाग पर प्रतिक्रिया जोड़ें, और टिप्पणी न करें।

sivel 29 जुल॰ 2020

क्या यह पृष्ठ उपयोगी था?

0 / 5 - 0 रेटिंग्स

Ansible: फ़ीचर: ब्लॉकों पर लूप तक की अनुमति दें या शामिल करें

सारांश

विषय वर्ग

घटक का नाम

सबसे उपयोगी टिप्पणी

सभी 29 टिप्पणियाँ

संबंधित मुद्दों