🤾🏻 🌕 🕓 कठपुतली नमक बावर्ची पहनावा: Ansible, SaltStack, बावर्ची, और कठपुतली की तुलना करें 🖐🏿 🏵️ 💆🏼

आज हम इस बारे में बात करेंगे कि एससीएम क्या है और प्रिज्म के माध्यम से कुछ कहानियां बताएंगे, जिनमें से हम किसी विशेष कार्य के लिए सबसे अच्छा विकल्प चुनते हुए, ऐन्सिबल, साल्टस्टैक, शेफ और पपेट पर विचार करेंगे।

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

SCM क्या है और इसके साथ क्या खाया जाता है?

SCM क्या है? सबसे पहले, यह एक ऐसी चीज है जो राज्य ए से हमारे बुनियादी ढांचे को कुछ कोड को निष्पादित करके राज्य बी को निष्पादित करने की अनुमति देती है। कई डेवलपर्स जो व्यवहार में DevOps इंजीनियर नहीं हैं, वे सोचते हैं कि कुछ "स्वचालित" तरीके से हो रहा है। बुनियादी सुविधाओं पर।

"स्वचालित" पद्धति हमें SCM (सिस्टम कॉन्फ़िगरेशन प्रबंधन) लागू करती है। यह किस लिए है? मुख्य रूप से दोहराने योग्य और सुसंगत बुनियादी ढांचे के निर्माण के लिए। SCM CI / CD प्रक्रियाओं का अच्छी तरह से विस्तार करता है। चूंकि यह कोड है, इसे किसी भी संस्करण नियंत्रण प्रणाली में संग्रहीत किया जा सकता है: Git, Mercurial। यह विकसित करने और बनाए रखने के लिए काफी सरल है।

अंतिम बंद स्वचालन चक्र है: बुनियादी ढांचे के निर्माण से लेकर इसे तैनात करने और कोड को तैनात करने तक, सब कुछ स्वचालित रूप से किया जा सकता है।

SCM क्या है: Ansible

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

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

- block: - name: "SlackNotify : Deploy Start" local_action: module: slack token: "{{ slack_url }}" attachments: - title: "Deploy to {{ inventory_hostname }} has been Started" text: "<!here> :point_up_2:" color: "#551a8b" - include: configure.yml tags: - configure - include: remote-fetch.yml tags: - remote - include: assets.yml

एससीएम क्या है: बावर्ची

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

 # # Cookbook Name:: dg-app-edl # Recipe::fe # node.normal[:jetty][:home] = "/usr/share/jetty" node.normal[:jetty][:group] = "deploy" include_recipe "dg-auth::deploy" include_recipe "newrelic::repository" include_recipe "newrelic::server-monitor" include_recipe "dg-jetty::jetty9" include_recipe "newrelic::java-agent" directory "edl" do action :create owner group "deploy" mode "0775" path "/usr/share/where/edl" recursive true end

SCM क्या है: SaltStack

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

 #ntp-packages: pkg.installed: - pkgs: - ntp - ntpdate #/etc/ntp.conf: file: - managed - source: salt://common/ntpd/ntp.conf - template: jinja - mode: 644 #/etc/sysconfig/ntpd: file: - managed - source: salt://common/ntpd/ntpd - template: jinja - mode: 644 #ntp-service: service.running: - name: ntpd

एससीएम क्या है: कठपुतली

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

 class { 'mysql::server' : root_password => 'password' } mysql::db{ ['test', 'test2', 'test3']: ensure => present, charset => 'utf8', require => Class['mysql::server'], } mysql::db{ 'test4': ensure => present, charset => 'latin1', } mysql::db{ 'test5': ensure => present, charset => 'binary', collate => 'binary', }

व्यवहार में एस.सी.एम.

एक ध्वस्त वातावरण में साल्टस्टैक

सबसे पहले, मैं एक परियोजना साझा करना चाहूंगा जो साल्टस्टैक पर लिखा गया था। यह हमारी पिछली परियोजना और सबसे ताज़ा दर्द है, और सबसे ताज़ा दर्द हमेशा सबसे दर्दनाक होता है। हमारा ग्राहक डेटा संग्रहण में लगा हुआ है - यह GPFS, GlusterFS पर डेटा संग्रहीत करने के लिए लोहे के सर्वर का उत्पादन है, लेकिन कस्टम बनाता है। वह निम्नलिखित कार्यों के साथ हमारे पास आया:

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

ग्राहक की कई आवश्यकताएं थीं। सबसे पहले, उसके पास पायथन विशेषज्ञता की एक बड़ी मात्रा है, वास्तव में केवल सी और पायथन डेवलपर्स। ग्राहक ने तुरंत कहा: "हम साल्टस्टैक चाहते हैं", कोई विकल्प नहीं छोड़ते।

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

दूसरी समस्या जो हमें मिली, वह थी टीम वर्क: साल्टस्टैक में रनर और मॉड्यूल। मॉड्यूल एक विस्तार है जो मशीन की तरफ से नमक मिनियन पर चलता है। रनर सर्वर साइड पर चलता है। हमारे बीच अक्सर लड़ाइयाँ होती थीं: रनर को क्या करना है, और मॉड्यूल्स को क्या करना है।

तब हमें cache.mine से एक छोटा सा आश्चर्य हुआ:

 ime = ImeActions() id = __grains__['id'] if id == ime.master_id: ret = __salt__['mine.get'](id, 'ime_actions.make_bfs_uuid') ime_dict = ret.get(id, None) if not ime_dict: try: result = __salt__['mine.send']('ime_actions.make_bfs_uuid') except Exeption, e: log.error("Failed to generate uuid: {0}.".format(str(e))) result = False else:

हमारे पास एक उपयोगिता है जो सी में लिखा है। हम इसे चलाते हैं, यह एक यादृच्छिक आईडी उत्पन्न करता है। यह क्लस्टर में सभी प्रतिभागियों के बीच अद्वितीय होना चाहिए, क्रमशः, हमें मास्टर पर एक बार ऐसा करने की आवश्यकता है, और फिर इसे मशीनों के बीच वितरित करें। हमने इसके लिए cache.mine का उपयोग किया। जैसा कि यह निकला, वह एक रिबूट का अनुभव नहीं कर रहा है।

"दौड़ की हालत।" समानांतरकरण अच्छा है, लेकिन बुनियादी कॉन्फ़िगरेशन में स्थिति। ऑर्केस्ट्रेट राज्य में आता है। अगर लंबी प्रक्रिया होती है तो सीएल चल रहा है। टाइमआउट तक, उनका मानना है कि राज्य पहले ही पूरा कर चुका है, हालांकि यह अभी भी चल रहा है, और अगले एक को शुरू करने की कोशिश कर रहा है। एक त्रुटि होती है। और यह समस्या अभी तक ठीक नहीं हुई है।

आप GitHub को देख सकते हैं ।

साल्टस्टैक के अलावा हम क्या इस्तेमाल कर सकते हैं?

एक DMZ वातावरण में SaltStack

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

एक बड़े और गतिशील वातावरण में बावर्ची

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

वे पूरी तरह से गतिशील संसाधन प्रबंधन चाहते थे, और यह भी कि यदि आवश्यक हो तो उनके आवेदन स्वयं में क्षमता जोड़ सकते हैं। यही है, हमें एक संपूर्ण गतिशील बुनियादी ढाँचे की आवश्यकता है और पूरी तरह से गतिशील वातावरण दोनों को ऊपर और नीचे की ओर।

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

तदनुसार, जब हमारे साथ कुछ गलत होता है, तो हम, नेटफ्लिक्स के लोगों की तरह, दोषपूर्ण संसाधनों को मारने और उनके स्थान पर नए और गारंटीकृत श्रमिकों को बहाल करने में सक्षम होना चाहिए।

हमें किन समस्याओं का सामना करना पड़ा:

यह 2013 था, शेफ 10 का उपयोग किया गया था, जिसमें धीमी गति से खोज की गई थी। हमने खोज शुरू की, सभी कारों के चारों ओर घूमते हुए, और इसे हमेशा के लिए ले लिया। हमने नामकरण सम्मेलन के साथ-साथ चयन और fqdn के लिए खोज के साथ समस्या को हल करने की कोशिश की। इसने खोज के दायरे को कम कर दिया, जिसकी वजह से इसमें तेजी आई।

लेकिन कुछ ऑपरेशन पूरे पर्यावरण पर किए जाने की आवश्यकता है। तदनुसार, खोज को बहुत शुरुआत में एक बार चलाया गया था, परिणाम को विशेषता में संग्रहीत किया गया था, और रूबी का उपयोग करके हमने परिणामों को फ़िल्टर किया: हमने उन टुकड़ों को पार्स किया जिनकी हमें ज़रूरत थी और जो आवश्यक था वह किया।
```
 if !Chef::Config[:solo] search(:node, "fqdn:*metro-#{node[:env]}-mongodb*").each do |mongo| @mongodbs << mongo.fqdn end else @mongodbs = ["lvs-metro-#{node[:env]}-mongodb3001.qa.example.com"] end 
```
नीचे पंक्ति: नामकरण सम्मेलनों का उपयोग करें, खोज को एक बार चलाएं, वांछित परिणामों को फ़िल्टर करने के लिए रूबी का उपयोग करें।
"Node.save" का उपयोग करना असुरक्षित है, सावधान और सावधान रहें। MySQL क्लस्टर को तैनात करते समय हमें इस समस्या का सामना करना पड़ा, और अधूरा रूप से कॉन्फ़िगर MySQL नोड पर नुस्खा के अंदर नोड। Save का उपयोग किया। और स्केल-अप के समय, कुछ अनुप्रयोगों ने 500 त्रुटि दी। यह पता चला कि हम गलत समय पर नोड को बचा रहे थे: यह शेफ सर्वर पर जाता है, वहीं यूआई पर शेफ क्लाइंट एक नया नोड चुनता है जो ऑपरेटिंग मोड से पहले कॉन्फ़िगर नहीं किया गया था।
"स्प्ले" का अभाव शेफ सर्वर को मार सकता है। Splay एक शेफ क्लाइंट पैरामीटर है जो आपको क्लाइंट के कॉन्फ़िगरेशन के लिए सर्वर पर जाने पर सीमा निर्धारित करने की अनुमति देता है। भारी भार के साथ, जब आपको एक ही समय में कई नोड्स को तैनात करने की आवश्यकता होती है, तो यह सर्वर को नहीं मारेगा।

हम शेफ के बजाय क्या उपयोग कर सकते हैं?

गतिशील प्रावधान SaltStack सही है क्योंकि इसमें SaltCloud है जो पूरी तरह से कहीं भी एकीकृत करता है। कठपुतली में समान कार्यक्षमता है, लेकिन यह केवल कठपुतली उद्यम में उपलब्ध है, पैसे के लिए। यदि कंपनी अमेजन में "रहती" है, तो अन्सिबल अच्छी तरह से अनुकूल है, अगर कुछ और - आप इसे विकल्पों में बाँध सकते हैं, लेकिन यह इतना सुविधाजनक नहीं है।
SDLC। एकीकरण परीक्षण के लिए उपकरण चुनने के लिए शेफ के पास टेस्ट किचन से लेकर सब कुछ है। साल्टस्टैक में अजगर के सभी उपकरण उपलब्ध हैं, अब कठपुतली के पास सब कुछ है। Ansible में एक रोल स्पेस है, आप शेफ की टेस्ट किचन का उपयोग कर सकते हैं, लेकिन यह एक देशी उपकरण नहीं है।
संसाधन प्रतिस्थापन। शेफ में सब कुछ ठीक है, साल्टस्टैक में आप सॉल्टक्लाउड को वांछित स्थिति में समाप्त कर सकते हैं, कठपुतली टूल्स में केवल एंटरप्राइज संस्करण में हैं, और Ansible केवल अमेज़ॅन के साथ अच्छी तरह से काम करता है।

शेफ के साथ EPAM प्राइवेट क्लाउड

AWS OpsWorks के आगमन से डेढ़ साल पहले, हम Chef को एकीकृत करके एक उन्नत Amazon CloudFormation बनाना चाहते थे ताकि संसाधनों को न केवल तैनात किया जा सके, बल्कि कॉन्फ़िगर भी किया जा सके।

दूसरा वैश्विक कार्य एक सेवा कैटलॉग बनाना है ताकि ग्राहक और उपयोगकर्ता उदाहरण के लिए पूरी तरह से तैयार एलएएमपी स्टैक को तैनात करने के लिए सीएलआई का उपयोग कर सकें।

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

CloudFormation + OpsWork को लागू करने के लिए किसी भी SCM का उपयोग किया जा सकता है, हर कोई उपयुक्त है। एक कैटलॉग बनाने के लिए - साल्टस्टैक को छोड़कर हर कोई यह अच्छी तरह से करेगा। साल्टस्टैक की अपनी बारीकियां हैं: एक विशेषज्ञ को खोजना बहुत मुश्किल है जो साल्टस्टैक को अच्छी तरह से जानता है और एक सेवा बना सकता है और कैटलॉग को भर सकता है।

EPAM में SCM की लोकप्रियता

ये EPAM के भीतर SCM लोकप्रियता के आँकड़े हैं। साल्टस्टैक बहुत पीछे है। पहली जगह में, यह सबसे सरल और प्रवेश की कम सीमा के साथ है। जब हम SCM के ज्ञान के साथ बाजार में किसी को खोजने की कोशिश करते हैं, तो बाजार उसी के बारे में देखता है।

Ansible के साथ काम करें

टिप्स जो मैं दे सकता हूं जब मैं साथ काम कर सकता हूं:

'गति' का प्रयोग करें, यह विन्यास को SSH की तुलना में 2-6 गुना तेजी से बढ़ाता है (el6 के लिए)। बाकी सभी के लिए, 'पाइपलाइनिंग' है। यह पिछड़े संगतता के लिए बंद है, लेकिन पाइप लाइनिंग को चालू करना बहुत आसान है, मैं इसे करने की सलाह देता हूं।
'With_items' का उपयोग करें
```
 - name: project apt dependencies installed apt: name: "{{ item }}" become: yes with_items: - build-essential - acl - git - curl - gnupg2 - libpcre3-dev - python-apt - python-pycurl - python-boto - imagemagick - libmysqlclient-dev # needed for data import 
```
इस उदाहरण में, हम पैकेज स्थापित करते हैं, इस योजना का उपयोग उपयोगकर्ताओं और इसी तरह के संचालन बनाने के लिए किया जा सकता है।
ध्यान से 'local_action' और 'प्रत्यायोजित' का उपयोग करें। पहला आपको साल्टस्टैक रनर के समान कुछ पाने की अनुमति देता है, दूसरा विशिष्ट मशीनों को कार्यों को सौंपने में सक्षम है।
```
 - name: create postgresql database postgresql_db: name: "{{ database_name }}" login_host: "{{ database_host }}" login_user: "{{ database_master_user }}" login_password: "{{ database_master_password }}" encoding: "UTF-8" lc_collate: "en_US.UTF-8" lc_ctype: "en_US.UTF-8" template: "template0" state: present delegate_to: "{{ groups.pg_servers|random}}" 
```
यह डेटाबेस निर्माण का एक टुकड़ा है। अंतिम पंक्ति के बिना, ऑपरेशन कई बार किया जाएगा और उसी डेटाबेस को बनाने के दूसरे प्रयास में गिर गया।
टैग के साथ अपनी भूमिकाओं और प्रदर्शन को अनुकूलित करें। यह लीड समय को काफी कम कर सकता है।

निष्कर्ष

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

विज्ञापन का मिनट। यदि आपको देवओप्स सम्मेलन से यह रिपोर्ट पसंद आई - ध्यान दें कि 14 अक्टूबर को सेंट पीटर्सबर्ग में नया देवओप्स 2018 आयोजित किया जाएगा, इसके कार्यक्रम में बहुत सारी दिलचस्प चीजें होंगी। साइट में पहले से ही स्पीकर और रिपोर्ट हैं।

कठपुतली नमक बावर्ची पहनावा: Ansible, SaltStack, बावर्ची, और कठपुतली की तुलना करें