मुझे भी यह समस्या हो रही है, ऐसा लगता है कि जैसे कि वेर को समूह के साथ रहने के बजाय मेजबान से पार्स और संलग्न किया गया है।

प्रजनन करने कि प्रक्रिया:

होस्ट फ़ाइल:

[aaa]
host1
host2

[bbb]
host2
host3

[aaa:vars]
foo=aaa

[bbb:vars]
foo=bbb

प्रत्येक समूह पर एक कमांड चलाएँ:

$ ansible -i hosts aaa -m shell -a "echo {{ foo }}"
host1 | success | rc=0 >>
aaa

host2 | success | rc=0 >>
bbb

$ ansible -i hosts bbb -m shell -a "echo {{ foo }}"
host2 | success | rc=0 >>
bbb

host3 | success | rc=0 >>
bbb

अपेक्षित परिणाम:

चर foo=aaa समूह के लिए asigned है aaa और जब समूह के खिलाफ आदेशों चल उत्पादन होना चाहिए aaa

वास्तविक परिणाम:

host2 समूह bbb से चर का उत्पादन करता है

एक ही समस्या है।

उदाहरण:

./group_vars/group1:

---
name: group1

./group_vars/group2

---
name: group2-default

मेजबान फ़ाइल:

[group1]
host1

[group2]
host1

इसलिए, जब मैं केवल ग्रुप 1 के लिए प्लेबुक चलाने की कोशिश कर रहा हूं, तो मुझे यह परिणाम मिल रहा है:
"नाम" चर एक मूल्य "समूह 2-डिफ़ॉल्ट" है, लेकिन यह `एक मूल्य" GROUP1 "होने की संभावना।

क्या इसके समाधान की कोई युक्ति है?

यदि आप उस समूह, अंतिम समूह का उपयोग नहीं कर रहे हैं, तब भी इन्वेंट्री var का विलय हो जाता है
मर्ज की जीत

ब्रायन कोका

@bcoca क्यों यह उस तरह से काम करता है? क्या यह अपेक्षित व्यवहार है, या वास्तविक बग?

आपके पास var / सेवा (1,2,3, ...) फाइलें हो सकती हैं

और सेवा = 1 को अतिरिक्त संस्करण के रूप में पास करें

तब होस्ट्स के लिए प्लेबुक में आपका लक्ष्यीकरण सेवा चर का उपयोग करता है,
साथ ही आप कौन सी vars फ़ाइल आयात कर रहे हैं

हम एक पर्यावरण अतिरिक्त संस्करण के आधार पर आयात करने के लिए एक समान काम करते हैं
26 नवंबर 2014 को 3:12 PM, "arianitu" नोटिफिकेशन @github.com ने लिखा:

@bcoca https://github.com/bcoca यह उस तरह से काम क्यों करता है? क्या इस
अपेक्षित व्यवहार, या एक वास्तविक बग?

-
इस ईमेल का उत्तर सीधे दें या इसे GitHub पर देखें
https://github.com/ansible/ansible/issues/9065#issuecomment -64718173

मैं आज 1.8.4 पर एक ही मुद्दा है।
आखिरकार, यह एक सही व्यवहार है या नहीं?
किसी को प्रगति पता है?

हम्म। यहां 'Bug_report' जैसे टैग गलत हैं। यह एक बग नहीं है लेकिन .. एक सुविधा :-)
तो हाँ, यह सही व्यवहार है।

जैसा कि @shnnz ने कहा, "

विभिन्न समूहों में चर जहां एक ही मेजबान सदस्य होते हैं, केवल तभी समझ में आता है जब वे समूह एक माता-पिता-बच्चे के संबंध में होते हैं, जीतने वाला बच्चा, और यह वैर लागू होता है। यदि समूह समान स्तर पर हैं, तो वास्तव में यह निर्धारित करने का तरीका नहीं है कि कौन जीतेगा।

प्लेबुक समय पर एक समूह को लक्षित करना वास्तव में केवल यह निर्धारित करता है कि मेजबान कौन से रन में हैं, यह चर स्तर पर कुछ भी नहीं बदलता है।

यहाँ पर मौजूद तरीका डेटाबेस होस्ट और पोर्ट को एक सूची में सेट करना होगा, और कार्यों में इसके बारे में पुनरावृति होगी।

@bcoca @ jimi-c मुझे लगता है कि यह मुद्दा बंद हो सकता है।

@srvg बहुत बहुत धन्यवाद! मैं समझ गया। मैं group_vars का उपयोग किए बिना प्रयास करूंगा।

बंद करना क्योंकि यह बग नहीं है, लेकिन डिज़ाइन के अनुसार, समूह संस्करण प्रति होस्ट के समतल हो जाते हैं और इस कारण से भिन्न नहीं होते हैं कि आप होस्ट का चयन कैसे करते हैं

किसी को भी इस के लिए एक समाधान मिला?

हम प्लेबुक में स्टेटिक वर्जन का उपयोग नहीं कर सकते हैं, क्योंकि हमें अलग-अलग वातावरण (अलग-अलग इन्वेंट्री फाइल्स द्वारा हैंडल) के बीच अंतर करने की जरूरत है और अलग-अलग वैरिएबल के साथ चलने की जरूरत है, जो ग्रुप रन के आधार पर समान होस्ट के रूप में चलते हैं। एक और समूह

समान होस्टनाम या IP पते के लिए CNAME का उपयोग करें। यही एकमात्र है
वर्कअराउंड मैंने पाया। समस्या तब प्रकट होती है जब आप Ansible Tower का उपयोग कर रहे हैं,
क्योंकि आप ऐसे CNAME के ​​साथ एक लाइसेंस बर्बाद कर रहे हैं। अन्सिबल नहीं करना चाहते हैं
इस बग को "सुविधा" कहकर ठीक करें, लेकिन वास्तव में यह एक वास्तविक बग है जो अवश्य होना चाहिए
निर्धारित होना।
28 Апр 2015 г. 17:16 пользователь "SkaveRat" सूचनाएं @github.com
написал:

किसी को भी इस के लिए एक समाधान मिला?

प्लेबुक में हम स्थैतिक संस्करण का उपयोग नहीं कर सकते, क्योंकि हमें अंतर करने की आवश्यकता है
विभिन्न वातावरणों (विभिन्न इन्वेंट्री फ़ाइलों द्वारा हैंडल) और के बीच
अलग-अलग चर के साथ चलाने की जरूरत है, समूह चलाने पर निर्भर करता है, यहां तक ​​कि
कठिन वे एक ही समूह पर दूसरे समूह के रूप में चलाए जाते हैं

-
इस ईमेल का उत्तर सीधे दें या इसे GitHub पर देखें
https://github.com/ansible/ansible/issues/9065#issuecomment -97077453

इसे ठीक कर दिया गया है लेकिन खारिज कर दिया गया है। https://github.com/ansible/ansible/pull/6666

कष्टप्रद बात यह है कि अनुशीलन मार्गदर्शक उन्हें भूमिकाओं के अनुसार समूह बनाने की सलाह देते हैं

http://docs.ansible.com/playbooks_best_practices.html

यह सुझाव दिया जाता है कि आप मेजबान (भूमिकाओं) के उद्देश्य के आधार पर समूहों को परिभाषित करते हैं और भूगोल या डेटासेंटर स्थान (यदि लागू हो)

लेकिन अगर एक ही मेजबान में एक ही चर के साथ कई भूमिकाएँ हैं, तो आप समूह चर का उपयोग नहीं कर सकते क्योंकि आपको पता नहीं है कि किसका उपयोग किया जाएगा।

मुझे अभी भी समझ में नहीं आ रहा है कि एक विशिष्ट प्लेबुक के लिए एक विशेष मेजबान के लिए एक चर को कैसे बांधें। मैं एक ही टेम्पलेट का उपयोग करने की क्षमता चाहता हूं, लेकिन मैं जिस वातावरण पर तैनात हूं, उसके आधार पर विभिन्न कॉन्फ़िगरेशन मानों के साथ।

हम पहले से ही http://docs.ansible.com/ansible/playbooks_best_practices.html#staging -vs- उत्पादन का अनुसरण कर रहे हैं, हमारे विभिन्न वातावरणों के लिए अलग-अलग आविष्कार करके

ऐसा करना मुश्किल क्यों लगता है Ansible के साथ? क्या पर्यावरण आधारित परिनियोजन करने के लिए Ansible केवल बुरा है?

कृपया एक पूर्ण उदाहरण प्रदान करें, क्योंकि "यहाँ तरीका एक सूची में डेटाबेस होस्ट और पोर्ट सेट करने के लिए होगा, और कार्यों में इस पर पुनरावृति होगी।" मुझे इससे कोई मतलब नहीं है। यहाँ पर्यावरण कहाँ निर्दिष्ट है?

उदाहरण के लिए, मेरे पास एक प्रमाणीकरण सेवा है जिसमें चर के लिए authentication_db_host: 127.0.0.1 मंच के लिए, और authentication_db_host: 192.168.2.4 लाइव के लिए है। क्या आप चाहते हैं कि मेरे पास 2 चर हों?

authentication_db_host_stage: 127.0.0.1
authentication_db_host_live: 192.168.2.4

अब मेरे लिए एक सामान्य टेम्पलेट फ़ाइल को खिलाना मुश्किल है। मुझे यह जोड़ने की आवश्यकता है कि मेरी पूरी j2 फ़ाइल में और क्या जांच हुई (और हम उस रास्ते पर चले गए, लेकिन यह बहुत अधिक दोहराव था और हमें इससे छुटकारा मिल गया।)

मुझे ऐसा कोई दस्तावेज नहीं मिला है जो इस मामले को संभालता हो, और ऐसा लगता है कि ऐसा करना मुश्किल नहीं होना चाहिए।

यहाँ हम इसे कैसे करते हैं:

AWS उदाहरण के रूप में चिह्नित:

सोमपी: ठेस

playbook someapi.yml

• होस्ट: tag_someapi _ {{env}}
  इकट्ठा_फैक्ट्स: सच है
  उपयोगकर्ता: ec2- उपयोगकर्ता
  vars_files:

  • vars / aws _ {{env}}

  कार्य:

  • विफल: संदेश = "Env परिभाषित किया जाना चाहिए"
    कब: एनवी परिभाषित नहीं है
    भूमिकाएँ:
  • सोमपती
    ...

अतिरिक्त संस्करणों के साथ निष्पादन

ansible-playbook -vv someapi.yml -e "env = prod"

भूमिकाएं / सोमेपी / कार्य / main.yml

• नाम: केवल vareapi के लिए विशिष्ट vars शामिल करें।
  शामिल करें_कार: सोमपेई _ {{env}}। yml
• नाम: जगह विन्यास
  साँचा: src = config.j2
  भाग्य = {{someapi_install_directory}} / configuration.properties
  ...

भूमिकाएँ / सोम्पेई / वर्स / सोमेपी_प्रोड.इम्ल

ऑथेंटिकेशन_डब्लू_होस्ट: 192.168.2.4

भूमिकाएँ / सोम्पेई / वर्स / सोमेपी_स्टैग.आईएमएल

प्रमाणीकरण_डब्लू_होस्ट: 127.0.0.1
...

भूमिकाएं / सोमेपी / टेम्प्लेट / config.j2

ऑथेंटिकेशन_डब्लू_होस्ट = {{ऑथेंटिकेशन_db_host}}
...

HTH,

इयान राइट

यह ईमेल संदेश गोपनीय है, जिसका उद्देश्य केवल प्राप्तकर्ता के लिए है
ऊपर नाम दिया गया है और इसमें ऐसी जानकारी हो सकती है जो विशेषाधिकार प्राप्त है, इससे छूट दी गई है
लागू कानून के तहत प्रकटीकरण। यदि आप इच्छित प्राप्तकर्ता नहीं हैं, तो करें
इच्छित उद्देश्य को छोड़कर किसी को भी संदेश का खुलासा या प्रसार न करें
प्राप्त करने वाला। यदि आपको यह संदेश गलती से मिला है, या नाम नहीं है
प्राप्तकर्ता (ओं), कृपया प्रेषक को तुरंत वापसी ईमेल द्वारा सूचित करें, और
इस संदेश की सभी प्रतियां हटा दें।

शुक्र पर, 16 अक्टूबर 2015 को दोपहर 12:42 बजे, arianitu सूचनाएं @github.com ने लिखा:

मुझे अभी भी समझ में नहीं आया है कि किसी खास होस्ट के लिए वैरिएबल को कैसे बांधें
विशिष्ट प्लेबुक। मैं एक ही टेम्पलेट का उपयोग करने की क्षमता चाहता हूं, लेकिन साथ
मैं जिस वातावरण पर तैनाती कर रहा हूं, उसके आधार पर विभिन्न कॉन्फ़िगरेशन मान
सेवा।

हम पहले से ही अनुसरण कर रहे हैं
http://docs.ansible.com/ansible/playbooks_best_practices.html#staging -vs-production,
हमारे विभिन्न वातावरणों के लिए अलग-अलग आविष्कार करके

ऐसा करना मुश्किल क्यों लगता है Ansible के साथ? क्या करने के लिए उत्तर केवल खराब है
पर्यावरण आधारित तैनाती

कृपया एक पूर्ण उदाहरण प्रदान करें, क्योंकि "यहाँ पर एक निश्चित तरीका होगा
डेटाबेस होस्ट और पोर्ट को एक सूची में सेट करें, और कार्यों में इसे पुन: व्यवस्थित करें। "
मुझे इससे कोई मतलब नहीं है। यहाँ पर्यावरण कहाँ निर्दिष्ट है?

उदाहरण के लिए, मेरे पास एक प्रमाणीकरण सेवा है, जिसमें एक वैरिएबल है, जिसे प्रमाणीकरण_डब्‍ल्‍यूहोस्‍ट कहा जाता है:
स्टेज के लिए 127.0.0.1, और प्रमाणीकरण_डीबी_होस्ट: लाइव के लिए 192.168.2.4। कर
आप मुझे 2 चर देना चाहते हैं?

प्रमाणीकरण_db_host_stage: 127.0.0.1
प्रमाणीकरण_db_host_live: 192.168.2.4

अब मेरे लिए एक सामान्य टेम्पलेट फ़ाइल को खिलाना मुश्किल है। मुझे जरूरत है
जोड़ने के लिए अगर मेरी j2 फ़ाइल में और जाँच हो (और हम उस रास्ते से नीचे चले गए,
लेकिन यह बहुत अधिक दोहराव था और हमने इससे छुटकारा पा लिया।)

मुझे ऐसा कोई दस्तावेज नहीं मिला है जो इस मामले को संभालता हो, और ऐसा लगता है
उस चीज की तरह जिसे करना मुश्किल नहीं होना चाहिए।

-
इस ईमेल का उत्तर सीधे दें या इसे GitHub पर देखें
https://github.com/ansible/ansible/issues/9065#issuecomment -148816278

विभिन्न समूहों में चर जहां एक ही मेजबान सदस्य होते हैं, केवल तभी समझ में आता है जब वे समूह एक माता-पिता-बच्चे के संबंध में होते हैं, जीतने वाला बच्चा, और यह वैर लागू होता है। यदि समूह समान स्तर पर हैं, तो वास्तव में यह निर्धारित करने का तरीका नहीं है कि कौन जीतेगा।

क्या अन्सिबल ऐसे मामलों का पता लगा सकता है और संभावित समाधान संकेत के साथ चेतावनी दे सकता है?

अगर मैं सही ढंग से समझता हूं कि यह कैसे काम करता है - भविष्य के पाठकों के लिए जो खुद को समझने के लिए संघर्ष करते हैं:

1. इन्वेंट्री फ़ाइलों में होस्ट समूह होस्ट के समूहों को परिभाषित करते हैं। समूह चर इस समूह में मेजबानों के लिए क्या चर निर्धारित किया जाना चाहिए परिभाषित करते हैं।
2. जब मैं एक समूह को प्लेबुक खेलने के लिए उपयोग करने के लिए निर्दिष्ट करता हूं, तो इसका मतलब उन सभी होस्ट को लेना है जो उस समूह से संबंधित हैं।
3. प्रत्येक नाटक प्रत्येक मेजबान के लिए अलग से खेला जाता है - कोई संदर्भ नहीं है कि किस समूह को तैनात किया जा रहा है। समूह का उपयोग समूह होस्ट और समूह संस्करण के लिए किया जाता है - उन होस्ट को सामान्य चर सेट करने के लिए।
4. इसलिए यदि किसी समूह का उल्लेख कई समूहों में किया जाता है और इन समूहों के विभिन्न मानों के साथ एक ही चर होता है, तो मेजबान को यह बताया जाता है कि यह पहले समूह से संबंधित है - इसके लिए चर समूह मान पर सेट है; तब क्योंकि होस्ट दूसरे समूह से संबंधित है, एक ही चर भिन्न मान के साथ पिछले मान को सेट कर रहा है।

मुख्य समस्या यह है कि जिन समूहों से मैं नहीं हूं, उनमें से भी योग्य मर्ज चर
अभी खेलना चाहते हैं। मुझे उस समूह से चर की जाँच करने की आवश्यकता नहीं है जो मैं नहीं हूँ
इस समय खेल रहा है। हो सकता है, सेमी सॉल्यूशन वेरिएबल्स के लिए जांचना हो
केवल वह समूह, जिसे प्लेबुक चलाने के लिए निर्धारित किया गया था।

вс, 17 внв 2016, 20:00, विक्टर वर्वारुक सूचनाएँ @github.com:

अगर मैं सही ढंग से समझता हूं कि यह कैसे काम करता है - भविष्य के पाठकों के लिए
जो समझने के लिए संघर्ष करते हैं:

1. इन्वेंट्री फ़ाइलों में होस्ट समूह होस्ट के समूहों को परिभाषित करते हैं। समूह
   वैरिएबल इस बात को परिभाषित करते हैं कि इसमें मेजबानों के लिए कौन से वैरिएबल सेट किए जाने चाहिए
   समूह।
2. जब मैं प्लेबुक खेलने के लिए उपयोग किए जाने वाले समूह को निर्दिष्ट करता हूं, तो इसका मतलब है
   सभी मेजबान लें जो उस समूह के हैं।
3. प्रत्येक नाटक प्रत्येक मेजबान के लिए अलग से खेला जाता है - कोई संदर्भ नहीं है
   कौन सा समूह तैनात किया जा रहा है। समूह मेजबान और समूह को समूह के लिए उपयोग किया जाता है
   vars - उन यजमानों को सामान्य चर सेट करने के लिए।
4. इसलिए यदि एक मेजबान का उल्लेख कई समूहों में किया जाता है और इन समूहों के पास है
   विभिन्न मूल्यों के साथ एक ही चर, मेजबान को बताया जाता है कि क्योंकि यह
   पहले समूह से संबंधित है - इसके लिए चर समूह के लिए सेट है
   मूल्य; तब क्योंकि होस्ट दूसरे समूह के समान चर का है
   पिछले मान को अलग करते हुए एक अलग मान सेट किया जाता है।

-
इस ईमेल का उत्तर सीधे दें या इसे GitHub पर देखें
https://github.com/ansible/ansible/issues/9065#issuecomment -172353019

यह बहुत ही सहज ज्ञान युक्त लगता है।

मेरे पास एक इन्वेंट्री है जिसमें परीक्षण प्रयोजनों के लिए प्रत्येक समूह में मेरा वैग्रेंट बॉक्स है।

लेकिन यहां तक ​​कि जब मैं एक प्लेबुक चलाता हूं जो सिर्फ एक समूह का संदर्भ देता है, तो अन्सिबल अन्य समूहों से चर में खींच रहा है जो कि उनके परीक्षण को तोड़ रहा है।

28 अप्रैल 2016 को 17:55 पर, फिलिप विग ने सूचनाएं @github.com को लिखा:

यह बहुत ही सहज ज्ञान युक्त लगता है।

ऐसा इसलिए है क्योंकि इन्वेंट्री को देखने के लिए आप जिस मानसिक मॉडल का उपयोग करते हैं, वह नहीं है
एक सही।

मेरे पास एक इन्वेंट्री है जिसके लिए प्रत्येक समूह में सिर्फ मेरा वैग्रेंट बॉक्स है
परीक्षण के उद्देश्य।

लेकिन यहां तक ​​कि जब मैं एक प्लेबुक चलाता हूं, जो सिर्फ एक समूह का संदर्भ देता है,
अन्सिबल अन्य समूहों से चर में खींच रहा है जो टूट रहा है
मेरा परीक्षण।

इन्वेंट्री को कसकर मत देखो जैसे कि प्लेबुक के साथ युग्मित है। इन्वेंटरी
एक बहुत अलग बात है, जहां

• मेजबान कई समूहों के सदस्य हो सकते हैं, और जैसे कि इससे लक्षित किया जा सकता है
  ansible (ad-hoc) या ansible-playbook (playbooks) में से किसी एक को इंगित करके
  समूह जो होस्ट के सदस्य हैं।
• वैरिएबल-वाइडिंग को हल किया जा रहा है, चाहे आप लक्ष्य करें
  विशिष्ट समूह, या ऑलमाइटी बिल्ट-इन 'सभी' समूह, वह नहीं बदलता है
  चर सभी को देखते हुए विरासत में मिले, हल किए गए और गणना किए गए हैं
  सूची में मौजूद समूह परिभाषाएँ और सभी समूह चर।

HTH,

एक प्रकार का कपड़ा

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

एक विकल्प यह होगा कि समूह में बजाय मेजबान में vhosts डाले, लेकिन यह साफ नहीं लगता क्योंकि मुझे उन सभी सर्वरों के लिए डुप्लिकेट करना होगा जो एक ही समूह में हैं।

क्या कोई मुझे ऐसा करने या इसके आसपास काम करने के बेहतर तरीके की दिशा में इशारा कर सकता है? मुझे ऐसा लगता है कि मैं अपनी "vhosts" भूमिका निभाकर भूमिकाओं या सूची की अवधारणा का दुरुपयोग कर सकता हूं, vhosts की एक सरणी को स्वीकार करता है (एक vhost इस अर्थ में "भूमिका" नहीं है कि आप सर्वर से नहीं कहते हैं "आप हैं" a vhost ")। क्या कोई इसे करने या अपने विचारों को साझा करने का एक बेहतर तरीका प्रदान कर सकता है?

वैसे, @ एसआरवीजी , ने मुझे जवाब देने के लिए समय निकालने के लिए धन्यवाद - इसकी बहुत सराहना की और मेरी समझ को स्पष्ट किया है।

मेरा समाधान है

[सेवा १]
host1 ansible_ssh_user = host1.com

[सेवा २]
host2 ansible_ssh_user = host1.com

यह तो बेवकूफ है। मैंने केवल एक चर मुद्दे को डिबग करने के लिए कई घंटे बिताए, केवल यह पता लगाने के लिए कि यह कुछ बेवकूफ डिजाइन दर्शन (यह) के कारण था। बहुत कम से कम, एक ही होस्ट के लिए कई group_var फाइलें लोड होने पर चेतावनी होनी चाहिए।

यह मुझे बहुत पसंद आया कि group_vars को अनियमित रूप से लोड किया जाए। यह संभव है कि ऐसे मामले में वंशानुक्रम होना संभव है> डेटासेटर> पर्यावरण (इंटिग, डेवेल, प्रोडक्ट्स)> एप्लीकेशन> होस्ट

कठपुतली हिरा के साथ करना बहुत आसान है, लेकिन इसके साथ एक दर्द है, और, जब आपके पास बनाए रखने के लिए> 100 प्लेबुक / भूमिकाएं होती हैं, तो वैरिएबल को लोड करना महत्वपूर्ण नहीं होता है क्योंकि आपको एक ही फ़ंक्शन के लिए एक vars_file + group_vars फ़ाइल को बनाए रखना चाहिए। ।
हो सकता है कि फ़ाइल (vars_priority) में कोई टैग हो या लोडिंग ऑर्डर को ठीक करने के लिए फ़ाइल नाम का उपयोग अच्छा हो (उदाहरण के लिए अपाचे)

• all.yml
• 10_डाटासेंटर_ए.मल
• 10_डाटासेंटर_ बी.आईएमएल
• 20_env_production.yml
• 40_app_gitlab.yml

उसके बाद gitlab समूह नाम प्रति लोड करें, यहाँ datacenters, env के बाद, और ऐप को लास्ट करें।

मैं यह देखकर बहुत खुश हूँ कि मैं इस बकवास में अकेला नहीं हूँ! समूह संस्करण को होस्ट अवधि के HIS समूह पर लागू होना चाहिए। दुनिया में कैसे - प्रारंभिक निर्देश की तुलना में समझाया जाना चाहिए? सोचने का स्वाभाविक तरीका यह है: ठीक है कि मैं इस नाटकपुस्तक को "उस" समूह में होस्ट करने के लिए "सीमित" करता हूं, ताकि इस प्रकार के विभिन्न प्रकारों को चुना जा सके !!!! एक ही मेजबान के लिए अन्य समूहों में चर परिभाषित नहीं है, जो किसी भी चीज को नहीं बनाता है!

मुझे उम्मीद है कि यह ठीक हो जाएगा और इस बीच, मैं एक ही मेजबान के लिए कई DNS प्रविष्टि का उपयोग करने के लिए वापस आ गया हूं।

बस इस मुद्दे पर घूमने की कोशिश में मेरा सिर पीटने में कई घंटे लगे। चटकारे की मात्रा के साथ यह मुद्दा मिल रहा है कि मैं वास्तव में हैरान हूं

क्यों var_vars अमूर्तता पर निर्भर होकर vars को मिलाते हैं और निर्धारित करते हैं कि क्या है
पहली जगह में जरूरत है?

मैं एक अच्छे कारण के बारे में स्पष्ट रूप से परिभाषित नहीं कर पा रहा हूं और जिसमें var शामिल हैं
(सबसे आसान उदाहरण धागे में ऊपर शामिल है)

इयान राइट

यह ईमेल संदेश गोपनीय है, जिसका उद्देश्य केवल प्राप्तकर्ता के लिए है
ऊपर नाम दिया गया है और इसमें ऐसी जानकारी हो सकती है जो विशेषाधिकार प्राप्त है, इससे छूट दी गई है
लागू कानून के तहत प्रकटीकरण। यदि आप इच्छित प्राप्तकर्ता नहीं हैं, तो करें
इच्छित उद्देश्य को छोड़कर किसी को भी संदेश का खुलासा या प्रसार न करें
प्राप्त करने वाला। यदि आपको यह संदेश गलती से मिला है, या नाम नहीं है
प्राप्तकर्ता (ओं), कृपया प्रेषक को तुरंत वापसी ईमेल द्वारा सूचित करें, और
इस संदेश की सभी प्रतियां हटा दें।

Tue पर, 27 सितंबर, 2016 को सुबह 11:53 बजे, Jason Hane सूचनाएं @github.com
लिखा था:

बस कई घंटे बिताए और मेज पर सिर पटकने की कोशिश की
इस मुद्दे। चटकारे की मात्रा के साथ यह मुद्दा मुझे मिल रहा है
आश्चर्यचकित करने योग्य Ansible (या Red Hat) इसे जारी रखने की अनुमति दे रहा है।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की है।
इस ईमेल का उत्तर सीधे दें, इसे GitHub पर देखें
https://github.com/ansible/ansible/issues/9065#issuecomment -249961581,
या धागा म्यूट करें
https://github.com/notifications/unsubscribe-auth/AATjccSt7D7FJfzdA8r86kb1GQvxLBnaks5quWY4gaJpZM4Cjj4
।

इस मुद्दे का हिस्सा यह है कि यह तुरंत स्पष्ट नहीं है कि अंसिबल पार्स चर कैसे। एक व्यक्ति सोचता है (जैसा कि इस समस्या से ग्रस्त लोगों की संख्या से पता चलता है) जो एक समूह को एक मेजबान प्रदान करता है, और केवल उस समूह को चला रहा है, केवल उस समूह के लिए चर का वारिस करेगा और उन सभी समूहों का नहीं जो मेजबान में है।

सभी मेजबानों को चलाना एक अलग कहानी है, लेकिन कम से कम तब यह स्पष्ट धारणा होनी चाहिए कि एंज़िबल उन सभी समूहों के लिए सभी चर पकड़ लेगा जो होस्ट में हैं। ।

क्यों var_vars अमूर्तता पर निर्भर होकर vars को मिलाते हैं और निर्धारित करते हैं कि क्या है
पहली जगह में जरूरत है?

यह बिल्कुल एक अमूर्त की बात है! यदि उपकरण मुझे अलग-अलग समूहों में अपने वातावरण को अमूर्त करने देता है और फिर अनुमान के स्पष्ट नियमों को लागू करके यह घटाता है कि किस चर का उपयोग किया जाना चाहिए, तो इसका उपयोग क्यों न करें?! इसलिए यहां 2 समस्याएं हैं: नियम स्पष्ट नहीं हैं या अमूर्त काम नहीं कर रहा है। यदि मुझे स्पष्ट रूप से परिभाषित करने और vars शामिल करने की आवश्यकता है, तो मुझे group_vars का उद्देश्य समझाएं?

मुझे कहना होगा कि प्रलेखन में एक ही मेजबान के इस विशिष्ट मामले का उल्लेख नहीं किया गया है जिसमें कई group_vars शामिल हैं। लेकिन यह मामला मेजबान में बहुत वास्तविक है जहां सेवा के कई उदाहरण मौजूद हैं (उदा। अपाचे)। मैं वास्तव में उम्मीद करता हूं कि यह समस्या जल्द सुलझ जाएगी।

हमने उपसर्ग का उपयोग करते हुए समूहों के बीच चर को परिभाषित करके चर वंशानुक्रम के साथ हमारी ऐप / एनवी समस्या को हल करने का एक तरीका ढूंढ लिया है।
उदाहरण के लिए

app_collectd.yml
collectd_host: "{{env_collectd_host}}"

env_production.yml
env_collectd_host: 1.1.1.1

तब यह अब कोई समस्या नहीं है, हमारे पास एक स्पष्ट ऐप वैरिएबल है + क्रास कॉलिंग वैरिएबल का उपयोग करके वैरिएबल

मैं कठपुतली-भूमि से आ रहा हूँ जहाँ अमूर्त और कोड का पुन: उपयोग सरल और स्पष्ट है। शायद मैं सही ढंग से समझ नहीं पा रहा हूँ कि अगर यह एक बेहतर तरीका है जिससे Group_vars शामिल नहीं होता है तो मैं सभी कानों के पास पहुँचता हूँ। मुझे यह नहीं करना चाहिए कि प्रत्येक होस्ट या समूह के लिए चर का एक और सेट बनाए रखना है, यह निर्दिष्ट करने के लिए कि उसे कहां चर मिलना चाहिए। मेरे लिए जो ढांचे की जिम्मेदारी होनी चाहिए। यह कठपुतली में हिरा की सुंदरता है।

@hyojinbae

मेरा समाधान है

[सेवा १]
host1 ansible_ssh_user = host1.com

[सेवा २]
host2 ansible_ssh_user = host1.com

क्या आप इसे विस्तार से बता सकते हैं?

मैं इसे इस तरह से परीक्षण करता हूं, यह आपके जैसा नहीं है, लेकिन यह काम करता है!

[service1]
host1 ansible_host=192.168.0.10

[service2]
host2 ansible_host=192.168.0.10

एक और शिकार यहाँ।

किसी को भी निम्न परिदृश्य के लिए एक अच्छा समाधान है?

मान लीजिए कि मेरे पास वेब एप्लिकेशन (ऐप-ए, ऐप-बी, ऐप-सी) की एक सूची है। और DR / लोड-बैलेंसिंग के लिए 2 DC में 4 होस्ट हैं। मैं तैनाती को आसान बनाने के लिए ansible का उपयोग करना चाहता हूं।

मेरी पहली वृत्ति समूह संस्करणों का उपयोग करने के लिए है, जाहिर है मैं असफल रहा, लेकिन वैकल्पिक क्या प्रदान करता है?

सूची

[dc1]
host1
host2

[dc2]
host3
host4

[cluster:children]
dc1
dc2

[app-a:children]
cluster

[app-b:children]
cluster

[app-c:children]
cluster

group_vars
एप्लिकेशन-एक

http_port: 8081

ऐप-बी

http_port: 8082

ऐप-सी

http_port: 8083

प्लेबुक मूल रूप से अपेक्षा करती है कि मेजबानों को कमांडलाइन के माध्यम से पारित किया जाए:

- host: {{app-name}}
- tasks: 
  # deploy application with given {{http_port}}....

यह वही है जो मैं इसे पाने के लिए करता हूं

- hosts: "{{ app-name }}"

vars_files:
    - "vars/{{ app-name }}.yml"

@ थैंज थैंक्स , यह निश्चित रूप से एक दिशा की ओर
हालाँकि, अब मैं कोड पुन: उपयोग के लिए भूमिकाओं का उपयोग करने के लिए अधिक इच्छुक हूं, और सीधे प्लेबुक में चर घोषित करता हूं। भले ही इसका मतलब है कि मेरे पास प्रति ऐप में एक प्लेबुक होगी, लेकिन भूमिका के ठीक बगल में वैरिएबल घोषित करके जो इसका उपयोग करेगा, पूरे कॉन्फिग को समझने में बहुत आसान बना देगा।

@ शहजाद धन्यवाद, यह वर्कअराउंड शानदार है। तुमने मुझे बचाया।

@ शहज जीनियस!

मैं बहुत हैरान हूं कि यह एक मुद्दा भी है। मैं इसमें चल रहा हूं क्योंकि मेरे पास एक ही भूमिका है जिसका उपयोग मैं कई इन्वेंट्री समूहों के साथ करता हूं जिनके पास group_var फाइलें हैं। क्यूए / प्रोडक्ट में, यह एक मुद्दा नहीं है, क्योंकि प्रत्येक इन्वेंट्री समूह में अलग-अलग सर्वर हैं। लेकिन एकीकरण स्तर के वातावरण के लिए, हम सिंगल सर्वर पर सब कुछ एक साथ तोड़ते हैं (यही कारण है कि मैं इस मुद्दे को देख रहा हूं)।

Hanej की सलाह के बाद, मैंने अपनी playbook yml को स्पष्ट रूप से group_var फ़ाइल में लोड करने के लिए संशोधित किया:

hosts: publish
vars_files:
  - group_vars/publish.yml

"यह बहुत बेवकूफ है। मैंने केवल एक चर मुद्दे को डिबग करने के लिए कई घंटे बिताए, केवल यह पता लगाने के लिए कि यह कुछ बेवकूफ डिजाइन दर्शन (यह) के कारण था। बहुत कम से कम, एक चेतावनी होनी चाहिए जब कई group_var फाइलें लोड होती हैं। उसी मेजबान के लिए। "

बस इस "ISSUE" / "सीमा" को अद्यतन करने के लिए
ठीक है, हम संघर्ष को खत्म करने के लिए वर्कअराउंड का उपयोग कर सकते हैं, (मेजबान के साथ या अन्य तरीके से)
लेकिन इसका सबसे अच्छा तरीका यह होना चाहिए कि इसे परिभाषित करने के लिए ansible.cfg में उद्देश्य चर हो:
"समूह_कार संलग्न करें" या "समूह_कार विलय करें"

मैं इस कारण से group_vars का उपयोग नहीं कर सकता। हमारे पास कई समूहों (डीसी, पर्यावरण, अनुप्रयोग, आदि) में मेजबान हैं और चर कैसे पढ़े जाते हैं, इस पर हमारा कोई नियंत्रण नहीं है। हिरे का उपयोग कर कठपुतली से आगे आना एक बहुत बड़ी बात है। मेरी राय में, अंसिबल को "भूमिकाओं और प्रोफाइल" पैटर्न का उपयोग करते हुए हिरे की तरह कुछ को अपनाना चाहिए, जहां आप तथ्यों या समूहों के आधार पर चर का उपभोग करने के क्रम को निर्दिष्ट कर सकते हैं। मैं इस तरह से अब ऊपर के दृष्टिकोण का उपयोग कर रहा हूं।

उदाहरण के लिए, यदि आपके पास "/ लिनक्स होस्ट्स / एप्लिकेशन / जावा / वेबसाइट" नामक भूमिका में एक होस्ट है, तो आपको लिनक्स होस्ट्स से वेरिएबल विरासत में प्राप्त करने में सक्षम होना चाहिए (वैश्विक स्तर चर जैसे sysctl, DNS, NTP, आदि), एप्लिकेशन (वैश्विक) अनुप्रयोग स्तर चर), जावा (जावा विशिष्ट संस्करण जैसे JDK संस्करण, JAVA_HOME, आदि), और वेबसाइट (विशेष रूप से वेबसाइट अनुप्रयोग से संबंधित चर)। आगे आप पेड़ में नीचे जाते हैं और अधिक विशिष्ट चर बन जाते हैं, जो कि चर को अधिक से अधिक ओवरराइड कर सकते हैं।

इवेंट संचालित या एडहॉक रन के लिए Ansible का उपयोग करना बहुत अच्छा है और यह बहुत अच्छी तरह से काम करता है, लेकिन मुझे पता चल रहा है कि कॉन्फ़िगरेशन प्रबंधन के लिए Ansible का उपयोग करना अधिकतर पुपपेट और हिएरा के रूप में उपयोग करने के लिए साफ या आसान नहीं है।

2 साल बाद, मैं अभी भी इस मुद्दे पर ई-मेल की एक स्थिर धारा प्राप्त कर रहा हूं (यह इस गीथूब में सबसे अधिक टिप्पणी की गई समस्याओं में से एक है।) क्या अभी भी ऐसा लगता है कि मौजूदा व्यवहार सही है, भले ही यह बहुत है अचूक?

आप लोगों को इस बात पर गंभीरता से प्रलेख करने की आवश्यकता है कि एंसेबल के साथ कॉन्फ़िगरेशन प्रबंधन कैसे किया जाए क्योंकि इस परियोजना के साथ आवेदन परिनियोजन करने की कोशिश करने वाले किसी व्यक्ति के पास भयानक समय है।

हमने पूरी तरह से Ansible का उपयोग बंद करने का फैसला किया है। यह कॉन्फ़िगरेशन प्रबंधन, अवधि में बेकार है।

इस प्रोजेक्ट के लिए शुभकामनाएं।

हाँ, एक ही समस्या में भाग लिया जब एक ही होस्ट पर परीक्षण करते समय, विभिन्न वातावरणों के लिए फ़ाइलों के लिए तैनाती की प्रक्रिया को कॉन्फ़िगर करना। मैं पूरे {{ऐप-नाम}} - {{env}} को अपनाने जा रहा हूं। @ मिंज द्वारा प्रस्तावित yml विधि, लेकिन कम से कम विन्यास के लिए group_vars व्यवहार के लिए प्यार करता हूँ।

हैप्पी मुझे इस मुद्दे पर दीवार के खिलाफ मेरे सिर पर कई घंटों तक पीटने के बाद मिला ... और मैं इसे "फीचर" कहकर इस बग के बारे में बनाए रखने वाले रवैये से बेहद हैरान हूं, यह पहचान से परे बेवकूफी है।

मैं एक गतिशील सूची का उपयोग करके एक सामान्य तैनाती प्लेबुक / भूमिका स्थापित करने की कोशिश कर रहा हूं। इन्वेंट्री आउटपुट इस तरह दिखता है:

{
  "resource-service_ci": {
    "vars": {
      "nginxpool": "resource_pool",
      "httpport": "8800"
    },
    "hosts": ["host1.example.com", "host2.example.com"]
  },
  "example-service_ci": {
    "vars": {
      "nginxpool": "example_pool",
      "httpport": "8100"
    },
    "hosts": ["host1.example.com","host3.example.com"
    ]
  }
}

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

मैंने इस तरह से json को लागू करके @hanej वर्कअराउंड की कोशिश की:

_ "होस्ट": ["host1 ansible_host = host1.example.com", "host2 ansible_host = host2.example.com"] _

लेकिन Ansible को स्पष्ट रूप से समझ में नहीं आता है कि host1 ansible_host = host1.example.com को ssh करने की कोशिश की जा रही है

किसी और को एक ही समस्या का सामना करना पड़ रहा है, और यदि ऐसा संभव है तो एक संभव समाधान?

मैं कमांड लाइन पर पोर्ट और पूल वेरिएबल को पास कर सकता हूं क्योंकि वे पूर्वता लेते हैं, लेकिन फिर मुझे पहले कुछ बदसूरत लुकअप करना होगा।

इस बग से टकराने तक Ansible के साथ बहुत अच्छा समय था।

मेरे पास एक सही अमूर्तता थी जो एक बहु-स्तरीय वातावरण पर समान एप्लिकेशन के कॉन्फ़िगरेशन की अनुमति देगा, और एक सभी में एक परीक्षण वातावरण पर भी - अफसोस, मैं गलत था।

ऐसा लगता है कि अंसिबल की सबसे शक्तिशाली विशेषताओं में से एक ऐसा काम नहीं करता है जैसे हर कोई इसकी उम्मीद करता है।

कृपया, इसे ठीक करवा दें।

इस मुद्दे पर घूमने की कोशिश में घंटों मेरे सिर को पीटते रहे। कृपया इस समस्या को ठीक करें।

इस "सुविधा" ने मेरे दिन का बेहतर हिस्सा बर्बाद कर दिया। खुश नहीं।

@ शहजादे बल्कि शानदार वर्कअराउंड के लिए धन्यवाद। अब हम पर्यावरण के नाम पर अपने environment/group_vars/all फ़ाइलों में env चर सेट कर रहे हैं।

हमारी playbooks में हम फिर यह करते हैं:

- hosts: group
  vars_files:
    - "{{ env }}/group_vars/group.yml
  roles:
    - ...

मुझे पता है कि यह 2.5 साल हो गया है और यह संभव है कि एंसिबल इस पर कभी ध्यान नहीं देगा, लेकिन मैं सिर्फ इसके साथ अपनी निराशा जोड़ने जा रहा हूं। यदि आप अलग-अलग समूहों का उपयोग नहीं कर सकते हैं, तो उपयोगकर्ताओं को कई समूहों में होस्ट करने की अनुमति क्यों दें?

उपयोगकर्ताओं को कई समूहों में होस्ट रखने की अनुमति क्यों दें

अन्सिबल देवों के साथ मेरी यही समस्या है। लगता है कि वे केवल अपने बारे में सोचते हैं। वे कम से कम कुछ चेतावनियां जारी कर हताशा को कम करने की कोशिश कर सकते थे। वे इसके बजाय थूकना पसंद करते हैं।

हम बंद मुद्दों को फ़िल्टर करते हैं और उन पर टिप्पणियां नहीं देखते हैं, लेकिन किसी ने मुझे इनमें से कुछ सवालों के जवाब देने के लिए पिंग किया है। यदि आप देवों से ध्यान आकर्षित करना चाहते हैं तो मेलिंग सूची या आईआरसी बंद टिकटों की तुलना में बेहतर कंडेस्ट हैं।

एक समूह के गुणों के रूप में समूह को देखने योग्य है। उदाहरण के लिए, आप एक होस्ट वेबसर्वर समूह का हिस्सा हो सकते हैं (एक वेबसर्वर रीक्स स्थापित करने के लिए) और उत्तर-पूर्व_डेटाकेटर समूह का हिस्सा है (इसलिए आप जानते हैं कि नेटवर्क गेटवे, ntp और डीएनएस सर्वर सेट करने के लिए भी dev_group का हिस्सा देव उपकरण स्थापित करने के लिए है। और गैर-उत्पादन डेटाबेस, आदि, की ओर इशारा करते हैं।

आप मेजबान को लक्षित करने के तरीके के रूप में समूहों का उपयोग कर सकते हैं लेकिन इसका मतलब यह नहीं है कि अन्य 'मेजबान गुण' गायब हो जाते हैं। मैं 'नर' समूह में और 'प्रोग्रामर' समूह में हूँ, सिर्फ इसलिए कि आप एक प्रोग्रामर के रूप में मुझे चुनते हैं, मैं पुरुष होने से नहीं रोकता।

अंत में यह एक डिजाइन निर्णय (बग नहीं) है कि समूहों से कैसे निपटें, मेजबानों को वर्गीकृत करने और जोड़ने का एक तरीका। मुझे पता है कि अन्य उपकरण उन्हें अलग तरह से उपयोग करते हैं, लेकिन यह बदलने का एक कारण नहीं है कि वे अंसिबल में कैसे काम करते हैं, क्योंकि कोई समान तरीका नहीं है अन्य सभी उपकरण समूहों का उपयोग करते हैं, कई अन्य उन्हें इस तरह से देखते हैं कई नहीं।

इसमें परिवर्तनशील नामों का पुन: उपयोग न करने की सीमा होती है और केवल 'वर्तमान समूह लागू होता है' लेकिन इसका हमेशा फायदा यह होता है कि मेजबान को कैसे परिभाषित किया जाता है और इसके समाधान या समाधान के लिए संघर्ष आसान हो जाता है। Vars_files या शामिल_vars के उपयोग से ऊपर के अधिकांश मामलों में, समूह के रूप में स्थापित करने से अधिक उपयुक्त लगता है, जब अनुप्रयोग विशिष्ट चर के बारे में बात करते हैं।

Group_vars पर do_vars शामिल करना ... अच्छी तरह से यह नहीं है कि हमने इसे कैसे डिज़ाइन किया है, लेकिन अगर यह आपके लिए काम करता है ... चेतावनी यह है कि आप 'डबल लोडिंग' कर रहे हैं क्योंकि group_vars स्वचालित रूप से खींच लिए जाते हैं, इससे बड़े पैमाने पर प्रदर्शन समस्याएँ हो सकती हैं आविष्कार। हम और अधिक विशिष्ट, vars_files: vars/app1.vars.yml या ऐसा ही कुछ शामिल करने की सलाह देते हैं।

मुझे उम्मीद है कि यह स्पष्ट करता है कि समूह अंसिब्ल में काम करने के तरीके को क्यों और 'अन्य विशिष्ट उपकरण' से अलग क्यों है, मुझे बताएं कि क्या कुछ है जो मैं अपने डॉक्स http://docs.ansible.com/ansible/ में जोड़ सकता हूं

मैं हर किसी के काम करने के तरीके को समायोजित करना पसंद करूंगा, कुछ क्षेत्रों में अन्सिबल बहुत लचीला है, लेकिन इस संबंध में नहीं है और मुझे इसे बनाने के लिए एक अच्छा तरीका नहीं दिखता है और न ही बाद में प्लेबुक साझा करने का एक अच्छा तरीका है।
अगर मैं गलत हूं, तो मैं आपके पुल अनुरोध का इंतजार कर रहा हूं।

@bcoca ऐसे मामलों का पता लगाना संभव है जब समूह के

@bococa मेरे लिए क्या अस्पष्ट है, और मुझे लगता है कि इस मुद्दे पर बाकी टिप्पणीकारों में से अधिकांश, ग्रुपिवर पूर्वता / संकल्प जिस तरह से है, उसे ध्यान में रखते हुए, अंसिबल टीम को संरक्षित करने के लिए क्या मूल्य है।

क्या आप एक ऐसे मामले का उदाहरण दे सकते हैं जो वर्तमान समाधान से अच्छी तरह संतुष्ट है, लेकिन ऐसा हो जाएगा कि अगर समूचे इन्वेंट्री के बजाए किसी दिए गए नाटक के लिए चुने गए समूहों के लिए group_vars को केवल लोड किया गया / माना जाए?

यह उन उदाहरणों के साथ आने में काफी आसान लगता है जो इस तरह से टूट गए हैं जैसे कि अब।

मुझे समझ में आता है @bcoca बिंदु के रूप में हम इसे भी इस तरह का उपयोग करें। Ansible के साथ मेरी सबसे बड़ी निराशा यह है कि यह कॉन्फ़िगरेशन प्रबंधन या तदर्थ वर्कफ़्लोज़ के लिए ज्यादातर अच्छा काम करता है। यह या तो बहुत अच्छा काम नहीं करता है, लेकिन यह बेहतर हो रहा है और इसमें प्लगइन सपोर्ट है जो मुझे लगता है कि मैं इसे बेहतर बनाने के लिए एक और मुद्दा बनाने के लिए उपयोग करूंगा। ज्यादातर दिन मैं अभी भी कठपुतली को केवल कॉन्फ़िगरेशन प्रबंधन के लिए याद करता हूं ...

संभवत: group_vars के लिए सबसे अच्छा उपयोग मामला कई डेटासेन्टर्स है। मान लीजिए कि आपकी इन्वेंट्री फ़ाइल इस प्रकार दिखती है:

[dc1]
host1
host2

[dc2]
host3
host4

[app1]
host1
host3

[app2]
host2
host4

आप डेटासेंटर विशिष्ट चर सेट करने के लिए group_vars का उपयोग कर सकते हैं जो कि उस डेटासेंटर में सभी मेजबानों को विरासत में मिलेंगे।

group_vars/
    dc1.yml
    dc2.yml
    app1.yml
    app2.yml

dc1.yml

---
ntp_servers:
  - 10.10.10.10
  - 10.10.10.11

dc2.yml

---
ntp_servers:
  - 10.11.10.10
  - 10.11.10.11

इस तरह group_vars का उपयोग करना तब तक ठीक है जब तक आपको किसी अन्य group_var फ़ाइल में एक चर को मर्ज या ओवरराइड करने की आवश्यकता नहीं है। यह एक और मामला है जहां group_vars टूट जाता है। उस क्रम को सेट करने का कोई तरीका नहीं है जिसमें group_vars में चर पढ़े जाते हैं। एक पदानुक्रमित लेआउट (जैसे हिरा) जो तथ्यों द्वारा निर्धारित किया जा सकता है और पर्यावरण चर जैसी चीजों के लिए समूहों द्वारा नहीं, यहाँ ध्यान में आता है, लेकिन मैं पचाता हूं।

मेरे दृष्टिकोण से, यह उपयोग का मामला ज्यादातर सीधे कॉन्फ़िगरेशन प्रबंधन के लिए अच्छा है, लेकिन यह तैनाती या तदर्थ लिपियों में बहुत अच्छा नहीं है। यही कारण है कि मैं कुछ प्लेबुक के लिए इस सुविधा को अक्षम करने के लिए एक स्विच देखना पसंद करूंगा जहां आप ऐसा नहीं करना चाहते हैं।

@ मिंज मुझे यकीन नहीं है कि मेरी पिछली टिप्पणी में सुझाए गए डिजाइन परिवर्तन से यह उदाहरण कैसे टूट गया?

आपके द्वारा सूचीबद्ध इन्वेंट्री को देखते हुए, यदि मैं ansible-playbook -i /my-inventory -v some_playbook.yml -l dc1:&app2 किसी भी some_playbook.yml को उस इन्वेंट्री के खिलाफ लिखूंगा, तो इसे dc1.yml से वैरिएबल होने पर इसे तोड़ने के लिए काफी वंचित होना पड़ेगा। app1.yml केवल लोड किए गए थे।

मैं मानता हूं कि तैनाती एक मुद्दा है। विशेष रूप से बहु-किराएदार तैनाती।

मेरे काम करने के तरीके से दो चिंताएँ हैं:

सबसे पहले, कॉन्फ़िगरेशन नेमस्पेसिंग की कमी। विशेष रूप से, अगर मैं एक बहु-किराए वाले वातावरण में कुछ अनुप्रयोगों के लिए कॉन्फ़िगरेशन बनाए रख रहा हूं, तो मैं यह कैसे सुनिश्चित कर सकता हूं कि कोई व्यक्ति जो एक अलग ऐप बनाए रखता है जो एक ही मशीनों पर चलता है वह एक चर नाम जोड़ने वाला नहीं है जो मेरा साथ देता है, या यह कि मैं उनके साथ संघर्ष नहीं करूंगा

दूसरा, मामला हर कोई यहाँ बात करता रहता है। मुझे उम्मीद है कि नीचे दी गई इन्वेंट्री के साथ, मैं /data/prod लिखी गई फ़ाइलों के साथ कभी भी विंड नहीं ansible-playbook -i inventory -v data_deploy.yml -l app1_staging , और वह फाइलें कभी भी /data/staging नहीं लिखी जाएंगी जब मैं ansible-playbook -i inventory -v data_deploy.yml -l app1_prod चलाता हूं

ये दोनों मुद्दे अपने आप में काफी खराब हैं, लेकिन एक बड़ी कंपनी में जहां अलग-अलग टाइमज़ोन में कई लोग एक ही इन्वेंट्री का संपादन कर रहे हैं, वर्तमान समाधान थोड़ा जोखिम भरा है।

उदाहरण सूची।

[dc1]
host1
host2

[dc2]
host3
host4

[app1_staging]
host1
host2
host3
host4

[app1_prod]
host1
host2
host3
host4

app1_staging.yml:

---
  data_path: /data/staging

app1_prod.yml:

---
  data_path: /data/prod

पता नहीं अगर संपादन ने अधिसूचना को समायोजित करने के लिए काम किया, तो मेरी आखिरी टिप्पणी का उद्देश्य @ जंज को निर्देशित करना था।

@benjamincburns आप group_vars उपयोग का एक उदाहरण के लिए कहा है कि संतुष्ट करता है वर्तमान लोड हो रहा है विधि लेकिन टूटता ही तत्काल समूहों का उपयोग करता है, तो। मैंने यह प्रदान किया कि डेटासेन्ट उदाहरण के साथ। यदि Ansible सभी समूहों के लिए चर लोड नहीं करता है, तो आप चर को सेट नहीं कर सकते हैं, उदाहरण के लिए, डेटासेंटर स्तर पर।

मेरा मानना ​​है कि यह ansible.cfg में या कमांड लाइन पर एक टॉगल होना चाहिए ताकि आप यह निर्दिष्ट कर सकें कि कैसे group_vars को लोड किया जाए ताकि यह मौजूदा उपयोग के मामलों को तोड़ न सके। हमारे यहाँ बहु-किरायेदार वातावरण हैं और जब तक मैं group_vars का उपयोग करना बंद नहीं कर देता, तब तक इसके लिए थोड़ा सा उपयोग किया जाता था।

मुझे यकीन नहीं है कि आपने भूमिका और प्रोफाइल पैटर्न के बारे में सुना है, लेकिन यह वास्तव में अच्छा पढ़ा है और यदि आप किसी भी प्रकार के कॉन्फ़िगरेशन उपकरण का उपयोग कर रहे हैं तो मैं इस दृष्टिकोण की अत्यधिक अनुशंसा करता हूं। यह पपेट के लिए लिखा गया था लेकिन यह सभी उपकरणों के लिए लागू होता है। आप शायद इसका उपयोग तैनाती या तदर्थ सामग्री के लिए नहीं करेंगे, लेकिन सीधे कॉन्फ़िगरेशन प्रबंधन के लिए यह बहुत अच्छा है।

http://www.craigdunn.org/2012/05/239/

मैं डॉकटर मेजबानों का उपयोग करता हूं, इसलिए मेजबानों में फैले अलग-अलग वातावरणों में कंटेनरों के अलग-अलग उदाहरणों में यह सामान्य है और यह थोड़ा मुझे।

वर्कअराउंड के लिए @ मिंज का धन्यवाद और मैं यह भी ग्रुप वर्जन विज्ञापन के रूप में काम नहीं करता है और डिजाइन से टूटता हुआ प्रतीत होता है।

मेरा काम एक नाटक को इस प्रकार परिभाषित करना है:

- hosts: "{{ group }}"
  vars_files:
    - "vars/{{ group }}.yml" 
  roles:
    - role1 etc

प्लेबुक डीआईआर में var1 निर्देशिका को ग्रुप 1।yml, group2.yml के साथ रखें।

यह भयानक होगा यदि आपके कॉन्फ़िगरेशन केवल इसलिए बदल गए क्योंकि वे _accessed अलग थे_। बस उस प्रभाव के बारे में सोचें जो अभिसरण वास्तुकला में प्रयासों पर होगा। संभव के रूप में संगत चर रखने के लिए Ansible टीम के लिए +1।

अधिक दिलचस्प सवाल यह है कि आप एक ही भूमिका को कई बार कैसे लागू कर सकते हैं, जबकि _extending_ (और प्रतिस्थापित नहीं) को होस्ट के दौरान कुछ कॉन्फ़िगरेशन साझा कर रहे हैं। मुझे लगता है कि भूमिका निर्भरता की अनुमति है, अर्थात्:

• "रैपर भूमिकाएं" बनाएं जिसमें वे भूमिकाएं शामिल हैं जिन्हें आप निर्भरता के रूप में विस्तारित करना चाहते हैं।
• अपने रैपर के meta/main.yml allow_duplicates: true निर्दिष्ट करें।
• भूमिका घोषणा के लिए अपने कॉन्फिगर एक्सटेंशन को पास करें (नीचे देखें)।
• सेट साझा किया गया, group/host_vars में स्थिर कॉन्फ़िगरेशन।

तो संक्षेप में, आपकी आवरण भूमिका में meta.yml :

---
# roles/my-app/meta.yml
allow_duplicates: true
dependencies:
  - role: nginx
    nginx_servers:
      - name: server-myapp
        contents: |
          ...

जब आप आवरण भूमिका लागू करते हैं, तो केवल "विस्तार योग्य" कॉन्फ़िगरेशन वास्तव में बदल जाते हैं। डेवलपर्स पर बोझ इस तरह से अपनी भूमिकाओं को डिजाइन करने के लिए है जो इस पैटर्न का समर्थन करता है।

अन्सिबल टीम: यह आपकी मंशा थी कि भूमिकाओं का उपयोग कैसे किया जाएगा? मैंने ईमानदारी से निर्भरता के लिए बेहतर उपयोग-मामला नहीं देखा है; सब कुछ कोड सूप का नेतृत्व करने के लिए लगता है।

मैं सिर्फ 1 घंटे की डिबगिंग के बाद आज पीड़ित सूची में शामिल हुआ और इस पद को पाने के लिए काफी भाग्यशाली रहा।
मुझे लगता है कि यह केवल प्रलेखन समस्या है, कोई भी शिकायत नहीं करेगा अगर यह स्पष्ट रूप से यहां नोट किया गया है:
http://docs.ansible.com/ansible/intro_inventory.html#group -variables
तथ्य यह है कि चर मेजबान के साथ जुड़े हुए हैं, और समूह केवल एक सुविधा तरीका है जो सभी मेजबान को चर सेट करने के लिए है। यदि एक ही होस्ट को कई समूहों में उपयोग किया जाता है, तो चर को ओवरराइड किया जाएगा।

+1 यह समस्या हमारी सॉफ्टवेयर टीम को प्रभावित करती है।

दुर्भाग्य से हम भी आज इस मुद्दे पर भाग गए। समान कहानी, हालांकि हमारे पास एक सामान्य "टोमैट" रोएल है हम उस समूह के आधार पर पोर्ट संख्याओं जैसे चर का उपयोग करते हैं जो भिन्न होते हैं।
हालाँकि, कई टॉमकैट इंस्टेंस को एक ही भौतिक सर्वर पर तैनात किया जा सकता है, इसलिए हमने उन इन्वेंट्री में कई समूह बनाए जिनमें सर्वर का एक ही सेट होता है।

हालाँकि यह दृष्टिकोण काम नहीं करता है। मुझे अभी तक पता नहीं है कि इसे कैसे डिजाइन किया जाए। मैं आवरण भूमिकाएँ बनाता हूँ जिनके चर होते हैं क्योंकि कुछ चर वास्तव में सूची के लिए विशिष्ट होते हैं। उदाहरण के लिए एक डेटाबेस पासवर्ड ओड के लिए सोचो।

मुझे हाल ही में यह मिला जिसने इस मुद्दे के साथ मेरे दर्द को कम कर दिया:
https://github.com/leapfrogonline/ansible-merge-vars

यह चर के विलय को अनुमति नहीं देता है, जहां वे परिभाषित किए गए थे, इसलिए आप उदाहरण के लिए दो अलग-अलग समूहों में दो dicts / सूचियों को मर्ज कर सकते हैं, जैसे कि एक समूह जीत और दूसरे समूहों में परिभाषित चर को अधिलेखित करना जैसा कि वर्तमान व्यवहार है। प्लगइन केवल Ansible 2+ के साथ काम करता है।

अवधारणा और उपयोग के मामले को समझाने वाला एक अच्छा लेख यहां पाया जा सकता

हम हाल ही में इस मुद्दे पर भी आए। हमारे पास एक ही होस्ट पर विभिन्न उपयोगकर्ताओं के रूप में कई एप्लिकेशन चल रहे हैं। उदाहरण के लिए:

[group_a]
host1

[group_b]
host1

हमारे पास ansible_user को var के साथ ठीक से निर्दिष्ट करने का कोई तरीका नहीं है, न ही host_vars और न ही group_vars । नवीनतम परिभाषा हमेशा दोनों मामलों में जीतती है।

हमारा वर्तमान समाधान, नाटक में विभिन्न ansible_user साथ कई नाटकों को परिभाषित करना है:

- hosts: group_a
  ansible_user: user_a
  roles:
    - my-role

- hosts: group_b
  ansible_user: user_b
  roles:
    - my-role

@hyojinbae ने इसे हल करने के लिए ऊपर एक स्मार्ट तरीका सुझाया:

[group_a]
user_a<strong i="8">@host1</strong> ansible_user=user_a ansible_host=host1

[group_b]
user_b<strong i="9">@host1</strong> ansible_user=user_b ansible_host=host1

इसलिए अब प्रत्येक होस्ट का इन्वेंट्री में एक अनूठा नाम है। इन्वेंट्री में होस्ट संस्करण डालने के लिए एक बड़ा प्रशंसक नहीं है, लेकिन यह अब तक मैंने देखा सबसे अच्छा समाधान है।

@hyojinbae मुझे लगता है कि आप hostvars और निर्देश के अंक याद कर रहे हैं:

- hosts: group_a
  remote_user: user_a
  roles:
    - my-role

- hosts: group_b
  remote_user: user_b
  roles:
    - my-role

जब तक आप ansible_user सेट नहीं करते तब तक काम करना चाहिए। समूह मेजबान की एक संपत्ति हैं, न कि खुद के लिए एक इकाई।

इन्वेंट्री प्रबंधन के लिए उचित प्लगइन्स लिखना संभव बनाने के लिए एक प्रस्ताव था। मुझे अब संदेह है कि यह प्रस्ताव बंद / समाप्त हो गया था, एक गतिशील इन्वेंट्री प्लगइन को लागू करना संभव हो जाना चाहिए जो इस भ्रम के बिंदु के आसपास काम करता है।

+1 करने जा रहे हैं यहाँ डिज़ाइन योग्य डिज़ाइन पर सवाल उठाएँ।
वास्तविक दुनिया में, कई अलग-अलग एप्लिकेशन एक ही होस्ट पर चल सकते हैं।
होस्ट-स्तर पर स्कोपिंग group_vars बस इस उपयोग-मामले को कवर नहीं करता है।

बस एक सोचा प्रयोग के रूप में:

• मान लेते हैं कि डिफ़ॉल्ट व्यवहार को संशोधित किया गया था, ताकि "-l" विकल्प के साथ चल-चलनपुस्तिका चल रही हो, जिसमें group_vars चाइल्ड फ़ाइल (यदि यह मौजूद है) का उपयोग किया जाता है।
• आप अभी भी "डेटासेंटर" उपयोग-मामले को संभाल सकते हैं जो कि मूल समूहों के माध्यम से उल्लेख किया गया था।
• यह सब बदल जाएगा कि एक मेजबान मैच के लिए "नाम" बाल समूह एक मेजबान मैच के लिए "अंतिम" बाल समूह के बजाय विरासत लड़ाई जीत जाएगा।

इस छोटे से बदलाव से सैकड़ों DevOps-y लोग खुश होंगे, और किसी को भी दुख नहीं होगा।

मेरी पिछली टिप्पणी से, संभावित एवेन्यू के लिए https://github.com/ansible/proposals/issues/41 यहां और अधिक प्लग-इन व्यवहार की अनुमति देने के लिए देखें।

विश्वास नहीं कर सकता कि अन्सिबल इस मुद्दे पर (संकेत देते हैं, चेतावनी) ठीक नहीं करते हैं या अधिक जवाब देते हैं।
मुझे डिबग करने में कुछ घंटे लगे।

मैंने इसका भी सामना किया। एक दृष्टिकोण नेस्टेड चर का उपयोग करना था। इसलिए उदाहरण के लिए इन्वेंट्री समूह my_app_servers लें, और यह आपके group_vars के अंदर my_app_servers.yml फ़ाइल के साथ लाइन करता है, और आपको एक आम होस्ट पर प्रबंधित करने के लिए एक से अधिक एप्लिकेशन मिले हैं। मैंने उन्हें इस तरह नेस्ट किया

उदाहरण: my_app_servers.yml

application_env:
  - application1
  - application2

application_environments:
  application1: 
    app_port: 8080
    app_conf_dir: "/somedirectory/conf"
    app_logs_dir: "/somedirectory/logs"
    app_install_name: app1prd

   application2: 
     app_port: 8081
     app_conf_dir: "/somedirectory/conf"
     app_logs_dir: "/somedirectory/logs"
     app_install_name: app2prd

अपने main.yml में, लूप को परिभाषित करें, और नेस्टेड वैरिएबल लिस्ट पर इस तरह से,

with_items: "{{application_env}}"
लूप_कंट्रोल:
loop_var: application_env_item

फिर अपने कार्यों में, आप नेस्टेड चर को पकड़ सकते हैं जो आप चाहते हैं, कुछ निष्पादित करने के लिए।
{{Application_en परिवेश [application_env_item] ['app_install_name']}}
(यदि आप उस सूची में से एक संस्करण निकाल सकते हैं, तो आप बाकी प्राप्त कर सकते हैं।) उम्मीद है की वो मदद करदे।

यह मुद्दा (# 9065) 2015 में वापस बंद कर दिया गया था। समान # 6538। वही # 6666। और बहुत सारे।
यहां कई मुद्दों के खुलने के 4 साल बाद 2018 है, और जाहिर तौर पर शुरुआत के मुकाबले यह अधिक गर्म है, और हर कोई काउंटर-सहज ज्ञान युक्त डिजाइन के कारण घंटों खो गया।
IMHO यह डिजाइन टीम द्वारा समीक्षा की आवश्यकता की तरह लगता है।

अगर हर कोई प्रस्तावित प्रस्तावित हैक का उपयोग करना जारी रखेगा, तो यह कोड को बदसूरत बना देगा:

• सशर्त var फ़ाइल में शामिल हैं: https://github.com/ansible/ansible/issues/9065#issuecomment -282040497
• या "[service1] host1 ansible_ssh_user = host1.com" जैसे आविष्कार:: https://github.com/ansible/ansible/issues/9065#issuecomment -256384769
• एक कोर कार्यक्षमता पर अतिरिक्त काम: https://github.com/eggsby/oroboros
• delegate_to https://github.com/ansible/ansible/pull/6666#issuecomment -+१४,६७,५९,९८०

IMHO ये हैक्स इसे कम आकर्षक बनाते हैं न कि पूरी तरह से खुद को " सिंपल आईटी ऑटोमेशन" आदर्श वाक्य;

@bococa -> कृपया मार्गदर्शन करें कि (समुदाय से) ट्रिगर क्या होना चाहिए कि किसी ने PR # 6666 या # 17236 का पुनर्मूल्यांकन किया हो या ऐसा ही कुछ "बस सहज रूप से काम करता है"?

मुझे लगता है कि group_vars को खुद को प्राथमिकता देने में सक्षम होना चाहिए। पपेट के लिए हियरा ने इसे सही पाया। आप यह बता सकते हैं कि तथ्यों या समूहों के आधार पर लुकअप कैसे किया जाता है। अंतिम उपयोगकर्ता को अनुकूलित करने में सक्षम होने दें कि group_vars को कैसे संसाधित किया जाना चाहिए और उन चर को लागू करने के क्रम को आसानी से देखने के लिए एक तंत्र प्रदान करें।

FYI करें, हम सामान्य रूप से बंद मुद्दों पर सूचनाएं नहीं देख रहे हैं, यहाँ जवाब दे रहे हैं क्योंकि किसी ने मुझे इस पर इशारा किया है, मैं भी ताला लगाने जा रहा हूं ताकि लोग मंच के रखवालों में टिप्पणी न करें।

@ मिन्ज मुझे लगता है कि आप ansible_group_priority और [defaults]precedence कॉन्फ़िगरेशन चाहते हैं, जैसा कि अभी आत्मनिरीक्षण के लिए आपके पास ansible-inventory जो आपको अंतिम परिणाम दिखाता है, हम अभी भी लोगों को एक बेहतर देने पर काम कर रहे हैं। एक चर के अंतिम मूल्य को कहां / क्या सेट करें, यह देखें।

@ReSearchITEng एक प्रस्ताव खोलता है (http://github.com/ansible/proposals), लेकिन यह प्रत्येक भिन्न ऐप के एक मूलभूत फ़ोकस के बारे में है। एक मेजबान के लिए एक कार्य पर ध्यान केंद्रित करने योग्य है, अन्य उपकरण जो आप अधिक जटिल संरचना पर ध्यान केंद्रित करते हैं।

के लिए ansible 'समूहों' एक मेजबान की एक संपत्ति हैं, एक प्रमुख संस्था नहीं, अन्य उपकरण समूहों पर 'मुख्य संदर्भ' के रूप में ध्यान केंद्रित करते हैं और बाकी सब उस पर जोड़ा जाता है।

मैं या तो दृष्टिकोण को 'गलत' के रूप में नहीं देखता, बस अलग है। इस तरह से अंसिबल काम करने की कोशिश करने से सादगी प्रतिमान टूट जाएगा, ए होस्ट और ए टास्क पर ध्यान केंद्रित करें जो कि सिर्फ एक संगठनात्मक फोकस है और जिसे मैं अन्य तरीकों से लाती हूं उसे 'सोचने के आदी तरीके' के रूप में देखें।

मेरा तर्क है कि यह केवल डेटा संगठन और आदतों पर एक धारणा है, लेकिन यह सिर्फ मेरी राय है। एक प्रस्ताव प्रस्तुत करने के लिए स्वतंत्र महसूस करें, यदि आप मना करते हैं और अनुरक्षकों के साथ पर्याप्त कर्षण प्राप्त करते हैं, तो आप जो बदलाव चाहते हैं वह प्राप्त कर सकते हैं, मुझे नहीं लगता कि यह एक ऐसा बदलाव है जिसकी हमें आवश्यकता है।