Ansible

उत्तर देने योग्य एक और विन्यास प्रबंधन प्रणाली है। एक विशिष्ट विशेषता सादगी है, जिसमें महान लचीलापन है। और ये केवल शब्द नहीं हैं - आगे मैं उदाहरणों के द्वारा कुछ सरल ऑपरेशन दिखाऊंगा और आपको कुछ सर्वोत्तम प्रथाओं से परिचित कराऊंगा।

तो हमारे पास मेजबान समूह हैं:

WebServersG1	webserver1-g1, webserver2-g1
WebServersG2	webserver1-g2, webserver2-g2
WebServersProxy	वेबसर्वर-प्रॉक्सी 1, वेबसर्वर-प्रॉक्सी 2
डाटाबेस	db1, db2
DataBaseSlave	dbs1, dbs2
SomeServers	someserver1, someserver2

हम सभी मेजबानों को पर्याप्त संचालन के लिए तैयार करना चाहते हैं - सॉफ़्टवेयर के आवश्यक सेट (htop, zsh, vim, iftop, sudo, mc, tmux, wget) स्थापित करें, हमारी कुंजियों को कॉपी करें और इस सर्वर के लिए विशिष्ट सॉफ़्टवेयर को कॉन्फ़िगर और इंस्टॉल और कॉन्फ़िगर करें।
आरंभ करने का अर्थ है कम से कम दो फाइलें शुरू करने के लिए - एक इन्वेंट्री फाइल जिसमें हम मेजबानों की एक सूची लिखते हैं और उन्हें समूहों में विभाजित करते हैं - इन्वेंट्री और एक टास्क फाइल - प्लेबुक ।
इनकी आवश्यकता इसलिए है कि जब हम सब कुछ करते हैं, तो हम हर चीज को खूबसूरती से चलाते हैं:

ansible-playbook -i _ playbook.yml 

आइए, हमारे मेजबानों के आधार पर " इन्फ्रास्ट्रक्चर " नामक एक इन्वेंट्री फ़ाइल बनाएं:

 [WebServersG1] webserver1-g1 webserver2-g1 [WebServersG2] webserver1-g2 webserver2-g2 [WebServersProxy] webserver-proxy1 webserver-proxy2 [DataBase] db1 db2 [DataBaseSlave] dbs1 dbs2 [SomeServers] someserver1 someserver2 

वास्तव में, सब कुछ बुरा नहीं है, लेकिन WebServersG1 और WebServersG2 समूहों से हमारे मेजबान केवल निर्देशिका संरचना, कनेक्शन की संख्या और रिपॉजिटरी में भिन्न हैं। और WebServersProxy उनसे केवल nginx config और किसी सॉफ़्टवेयर की अनुपस्थिति में भिन्न होता है। इसके अलावा, आपको तीनों समूहों में एक साथ कुछ कार्य करने की आवश्यकता हो सकती है। तो आइए इन तीन समूहों के बारे में सोचें और उन्हें एक अभिभावक दें :

 [WEB:children] WebServersG1 WebServersG2 WebServersProxy 

इन्वेंट्री फ़ाइल की संरचना द्वारा: ansible एक समूह के रूप में विचार करता है, जिसका सब कुछ विवरण में लाइन '[' से शुरू होता है और '' '' के साथ समाप्त होता है। इस पंक्ति के तहत और अगले समूह की शुरुआत से पहले सब कुछ मेजबान है। एक समूह में बच्चे हो सकते हैं - अन्य समूह जो [समूह नाम: बच्चों] के बाद सूचीबद्ध होते हैं और मौजूद होते हैं।
मैं उन चर पर भी संक्षेप में बात करूंगा जिन्हें इस सूची में तुरंत वर्णित किया जा सकता है।

 webserver1-g1 ansible_ssh_port=5555 ansible_ssh_host=192.168.1.50 

यहाँ हमने ssh port और ssh host को असाइन किया है। व्यवहार में, मैं कहूंगा कि इन्वेंट्री फ़ाइल के अन्य चर इसे अव्यवस्थित करते हैं और इसे अपठनीय बनाते हैं। हां, और गैर-मानक पोर्ट इस रूप में सूचीबद्ध करने के लिए बेहतर हैं:

 webserver1-g1:5555 

और जब से हम बंदरगाहों के बारे में बात कर रहे हैं - सभी मेजबानों के लिए डिफ़ॉल्ट पोर्ट (जैसे बहुत अधिक) ansible.cfg में असाइन किए जा सकते हैं , लेकिन बिंदु नहीं।
इसलिए, हमने केवल मेजबानों की एक सूची बनाई। अब चलो कार्यों की एक सूची बनाएं, और मैं यादों में डुबकी लगाऊंगा।
प्राचीन समय में (इस वर्ष के लगभग मई-जुलाई), संस्करण 1.2 की रिलीज़ से पहले, सिद्धांत रूप में कोई भूमिका नहीं थी, हम साधारण कार्यों से संतुष्ट थे और प्लेबुक एक क्रिसमस के पेड़ से भरा हुआ लग रहा था। तब भूमिकाएं दिखाई दीं, और हाल ही में, एक या दो सप्ताह पहले, संस्करण 1.3 में - भूमिका विरासत। और हम, सच्चे जेडी के रूप में, अब हमारे पास जो भी है उसका उपयोग करेंगे। और आइए अंत में समझते हैं कि ये प्लेबुक और भूमिकाएं क्या हैं, अन्यथा यह स्पष्ट नहीं है।

Playbooks किसी भी चीज का एक निष्पादन योग्य सेट है। वे, शेफ के विपरीत, एक बार और केवल आपकी आज्ञा पर चलते हैं। हालांकि कार्य को मुकुट में सेट होने से रोकने के लिए कुछ भी नहीं है। पहले, एक प्लेलिस्ट का अर्थ कार्यों की एक मूल सूची थी, लेकिन अब वे उन भूमिकाओं के लिए एक बिंदु बन गए हैं जिनकी हमें ज़रूरत है।
रोल्स , बदले में, एक मानक संरचना में निर्देशिकाओं में धकेल दिए गए कार्यों, टेम्पलेट्स, ट्रिगर हैंडलर, चर, फाइलें और लिंक का एक सेट हैं। रोल्स को सर्वश्रेष्ठ तार्किक समूहों में बांटा गया है। उदाहरण के लिए, ऊपर दिए गए कार्य के ढांचे के भीतर, मैं इस तरह की भूमिकाएं निभाऊंगा:
1) पूर्व प्रशिक्षण - विभिन्न व्यवस्थापक सॉफ्टवेयर स्थापित करना, कुंजी के साथ उपयोगकर्ता बनाना, स्थान बनाना, कॉन्फ़िगरेशन कॉपी करना, आदि।
2) परिणामस्वरूप वांछित सेवा के लिए सॉफ़्टवेयर स्थापित करना और इसके कॉन्फ़िगरेशन की प्रतिलिपि बनाना
3) आवश्यक निर्देशिका संरचना बनाना, गीता की नकल करना, आदि।

तो, चलिए अब तक केवल preconf भूमिका के साथ main.yml playbook बनाना शुरू करते हैं

 - hosts: all roles: - preconf tags: preconf 

यहां हमने सभी 'सभी' मेजबानों को प्रीकॉन भूमिका सौंपी और प्रीकोफ टैग को जोड़ा। बाद में प्लेबुक के कुछ हिस्से को निष्पादित करने में सक्षम होने के लिए टैग की आवश्यकता होती है।
इसके अलावा, जब ansible भूमिका असाइनमेंट देखता है, तो वह //les में उसी नाम की निर्देशिका के लिए खोज करना शुरू कर देता है। हमारे मामले में यह होगा ।/roles/preconf
पहले से ही भूमिका संरचना तैयार होनी चाहिए, अर्थात्: कार्य / main.yml
यह मुख्य फ़ाइल है जो कार्यों को सूचीबद्ध करती है।
इसके अलावा, 'टेम्प्लेट' नामक एक निर्देशिका मौजूद हो सकती है, जिसमें हम कॉन्फिग फाइल्स, 'फाइल्स' के लिए टेम्प्लेट जोड़ते हैं, जिसमें हमें अलग-अलग फाइल की जरूरत होगी, 'हैंडलर' - वही प्रसिद्ध ट्रिगर हैंडलर, साथ ही मेटा / main.yml जिसमें हम भूमिका संदर्भों का वर्णन करते हैं और चर भूमिका चर होते हैं।
मेरा सुझाव है कि इसे क्रम से सुलझाएं, लेकिन यदि आप चाहें, तो आप अपने सिर को दाएं से बाएं झटके के साथ नीचे सेर के पाठ को तेजी से पढ़ सकते हैं।
तो, कार्य।
हमारी पूर्व-भूमिका के लिए, फ़ाइल बनाएं ।/roles/preconf/tasks/main.yml
आमतौर पर, कार्य इस तरह दिखते हैं:

 - name:   :  . 

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

 - name: installing zsh apt: pkg=zsh 

इस मामले में, हमने अपने डेबियन सर्वर पर zsh प्रोग्राम को स्थापित करने के लिए apt मॉड्यूल का उपयोग किया।
बेशक, आप प्रत्येक कार्यक्रम को स्थापित करने के लिए एक अलग कार्य के रूप में कार्य सूची को स्पैम कर सकते हैं, लेकिन ऐसी फाइलें बहुत खराब तरीके से पढ़ी जाती हैं। इसलिए, हम एक कतार का उपयोग करेंगे जिसे ' with_items ' के माध्यम से बुलाया जा सकता है:

 - name: installing zsh apt: pkg=$item with_items: - zsh - htop - sudo - iftop - tcpdump - mc - wget - vim - tmux - facter 

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

 - name: Add User Pupkin user: name='pupkin' 

तो हमारे उपयोगकर्ता को एक धमाके के साथ जोड़ा जाएगा। लेकिन हम चाहते हैं कि उपयोगकर्ता पुपकिन ज़श का उपयोग करें और सुडो समूह का सदस्य बनें? और चलो इसे करते हैं, क्योंकि 'उपयोगकर्ता' मॉड्यूल सब कुछ का एक गुच्छा का समर्थन करता है।

 - name: Add User Pupkin user: name='pupkin' shell='/bin/zsh' groups='sudo' 

हमने पहले से ही with_items सीखा है, इसलिए हम इसका उपयोग कई उपयोगकर्ताओं को जोड़ने के लिए करेंगे ... लेकिन ... ऐसा इसलिए है क्योंकि आपको स्ट्रीम में दो चर पास करने की आवश्यकता है ...
कुछ भी जटिल नहीं है। उत्तर देने योग्य हैश - 'कुंजी: मान' के रूप में सरणियों का समर्थन करता है। यह jinja2 प्रारूप में हैश रिकॉर्ड करने के लिए सबसे सुविधाजनक है।

 - name: Add BestAdminsTeam user: name={{ item.user }} shell={{ item.shell }} groups='sudo' with_items: - { user: 'pupkin', shell: '/bin/zsh' } - { user: 'oldfag', shell: '/bin/sh' } 

वास्तव में हमने क्या किया? हमने इस तरह की एक सरणी बनाई:
{ {user: 'pupkin', shell: '/bin/zsh' }, { user: 'oldfag', shell: '/bin/sh' } } जिससे हम एक समय में एक तत्व लेंगे और उन्हें चर $ आइटम पर असाइन करेंगे। या, jinja2 भाषा में - {{आइटम}})। उसके बाद, हम क्रमशः हैश तत्वों - {{item.user}} और {{item.shell}} को खोलेंगे। यही है, हमें प्रत्येक उपयोगकर्ता के लिए चर की एक सुसंगत सूची मिलती है।
अब हम अपने उपयोगकर्ताओं के लिए कुंजियाँ जोड़ते हैं। इसके लिए एक उत्कृष्ट मॉड्यूल ' अधिकृत_की ' है।

 - name: Add BestAdminsKey authorized_key: user={{ item.user }} key="{{item.key}}" with_items: - { user: 'pupkin', key: 'ssh-rsa pupkin_pub_key' } - { user: 'oldfag', key: 'ssh-rsa oldfag_pub_key' } 

सिद्धांत रूप में, यह उसी तरह काम करेगा, लेकिन हर बार उपयोगकर्ताओं को सूचीबद्ध करने के लिए यह थोड़ा असुविधाजनक है: टीम के किसी नए सदस्य को जोड़ना भूल जाना बहुत आसान है और मुझे आपको किसी तरह चर के बारे में बताने की आवश्यकता है, और यहां यह है।
आइए एक चर प्राप्त करें जिसमें हम अपने सभी उपयोगकर्ताओं को उनकी कुंजियों, गोले के साथ रखते हैं, संभवतः कॉन्फ़िगर करने के लिए पथ और बाकी सब कुछ। उपयोगकर्ताओं को एक चर में लाना आसान है, लेकिन चर को स्वयं कहां रखा जाए?
इसके लिए Ansible के पास कई समाधान हैं।
आप विशेष रूप से फ़ोल्डर में प्रत्येक होस्ट के लिए चर निर्दिष्ट कर सकते हैं ।/host_vars/host_name - यह हमारे उद्देश्य के लिए उपयुक्त नहीं है
आप मेजबान के एक समूह के लिए चर बना सकते हैं (समूह, मैं आपको याद दिलाता हूं, हमने इन्वेंट्री फ़ाइल में किया था) और उन्हें / .group_vars/group_name में डाल दिया - आप निश्चित रूप से, सभी समूह के लिए यहां एक चर बना सकते हैं। लेकिन यह "शुद्ध कार्य" नहीं है।
आप चर को सीधे playbooks में असाइन कर सकते हैं। लेकिन यह अस्वाभाविक लगता है।
प्रत्येक भूमिका में डिफॉल्ट्स निर्देशिका में "डिफ़ॉल्ट मान" भी होते हैं, लेकिन यह वास्तव में हमारी आवश्यकता नहीं है।
और अंत में, चर भूमिकाएं - ऐसा लगता है कि यह है।

एक फ़ाइल बनाएँ ।/roles/main/variables/main.yml जिसमें हम लिखते हैं:

 ssh_super_team: - { user: 'pupkin', key: 'ssh-rsa pupkin_pub_key', shell: '/bin/zsh'} - { user: 'oldfag', key: 'ssh-rsa oldfag_pub_key', shell: '/bin/sh' } 

अब कार्य में हम इस तरह $ ssh_super_team चर का उपयोग कर सकते हैं:

 - name: Add BestAdminsTeam user: name={{ item.user }} shell={{ item.shell }} groups='sudo' with_items: - $ssh_super_team - name: Add BestAdminsKey authorized_key: user={{ item.user }} key="{{item.key}}" with_items: - $ssh_super_team 

खैर, हर किसी के लिए सब कुछ सुविधाजनक बनाने के लिए - हमारे .vimrc फ़ाइल की प्रतिलिपि बनाएँ - दोनों उपयोगकर्ताओं के लिए समान। 'Vimrc' नाम की फ़ाइल को ./roles/main/files/ निर्देशिका में रखें और इस कार्य को करें:

 - name: copy vimrc file copy: src=”vimrc” dest=”/home/{{item.user}}/.vimrc” with_items: - $ssh_super_team 

देखा।

वैसे, मैं कभी-कभी फिर से पढ़ता हूं जो मैं लिखता हूं - यह स्वेच्छा से निकला। यह सब कुछ बंद करने का समय है जो गोल नहीं है, इसलिए मैं तुरंत नगीन विन्यास पर कूद जाऊंगा:
ट्रेसिंग पेपर का उपयोग करते हुए, nginx भूमिका बनाएं और फ़ाइल में लिखें ।/roles/nginx/tasks/main.yml:

 - name: install nginx apt: pkg='nginx' 

हम्म, लेकिन यह सभी nginx सर्वरों पर समान कॉन्फ़िगरेशन के साथ नहीं हो सकता है? हो सकता है, ज़ाहिर है, लेकिन यह असुविधाजनक है। चलो एक टेम्पलेट के साथ आते हैं - ansible में आपको कई jinja2 से परिचित सिंटैक्स का उपयोग करने की आवश्यकता है।
/ .Les/nginx/templates/ में एक फ़ाइल बनाएं और इसे nginx_site_conf.p2 नाम दें
और इस तरह से सामग्री बनाते हैं:

 server { listen 80; server_name {{ item.sitename }}; root “/var/www” } 

अगला, हमें उन चर का विस्तार करने की आवश्यकता है जो प्रत्येक होस्ट के लिए अद्वितीय हैं: ./host_vars/host_name पर फ़ाइलें अपलोड करें

 nginx: - { sitename: “www.example.com” } 

और इस भूमिका के लिए डिफ़ॉल्ट चर को परिभाषित करें: फ़ाइल में ।/roles/nginx/defaults/main.yml

 nginx: - { sitename: “default” } 

अब एक कार्य बनाएँ:

 - name: nginx config for sites template: src=”nginx_site_conf.j2” dest=”/etc/nginx/sites-enabled/{{ item.sitename }} with_items: - $nginx notify: - restart nginx 

और ansible, जब इस कार्य को पास करते हैं, तो यह $ nginx चर के साथ "nginx_site_conf.j2" टेम्पलेट को कॉपी करने का प्रयास करेगा, जिसे या तो होस्ट चर से या डिफ़ॉल्ट भूमिका चर से पढ़ा जाएगा। और यदि कॉपी किया जाने वाला टेम्प्लेट मशीन पर मौजूद विन्यास से भिन्न होता है, तो एक हैंडलर निष्पादित होता है जो इस तरह दिखता है :/roles/nginx/handlers/main.yml

 - name: restart nginx action: service name=nginx state=reloaded 

अब हम इन दो जानबूझकर सरलीकृत भूमिकाओं में से एक को इकट्ठा करेंगे, जो होस्ट्स वेबसर्विसजी 1 के समूह के लिए अद्वितीय है। अब हम कुछ भी जटिल नहीं करेंगे, लेकिन इसमें दो तैयार भूमिकाओं की एक कड़ी बनाएं। भूमिका / myapp / मेटा / main.yml फ़ाइल के लिए निम्नलिखित पंक्तियाँ लिखें:

 --- dependencies: - { role: preconf } - { role: nginx } 

और अंत में, playbook.yml playbook:

 - hosts: WebServersG1 roles: - WebServersG1 

वैसे, निर्भरता के निर्माण के दौरान, आप विशेष रूप से इस भूमिका के लिए कुछ जानकारी को स्पष्ट करने के लिए चर का उपयोग कर सकते हैं। लेकिन हम अगली बार इस बारे में बात करेंगे, साथ ही निर्भरता, जटिल टेम्पलेट्स के बारे में, किसी कार्य के निष्पादन की जांच, निष्पादन को समानांतर, और बहुत कुछ।
इस बीच, आप उत्कृष्ट को पढ़ सकते हैं, दूसरों को नहीं, प्रलेखन: www.ansibleworks.com/docs

PS मेरा आंतरिक संपादक छुट्टी पर चला गया। मैं गलतियों और असमान लिखावट के लिए माफी मांगता हूं। मैं हमेशा पीएम को पढ़ता हूं और हमेशा सुधारों के लिए "धन्यवाद" कहता हूं।