🤶🏼 ⬇️ 😑 कठपुतली + हिरे। अधिकतम निचोड़ें 👨🏽‍⚕️ 🙋🏾 💦

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

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

जिनके लिए यह लेख उपयोगी होगा

हैं:

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

यह लेख आपके लिए है।

शुरू करने से पहले

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

यहां पढ़ें कि कठपुतली यहां क्या है: शुरुआती के लिए कठपुतली ।
हिएरा कैसे काम करती है - हिरा में पेश किया गया ।

इनपुट डेटा

हमारे पास SEMrush में लगभग 30 विकास दल हैं, जिनमें से प्रत्येक का अपना सर्वर है
प्रत्येक टीम अपने स्वयं के प्रौद्योगिकियों (पीएल, डीबीएमएस, आदि) के साथ काम करती है।
टीमें विशिष्ट परियोजनाओं के लिए एक सामान्य विन्यास (आदर्श रूप से) का उपयोग कर सकती हैं और करना चाहिए (कोड का पुन: उपयोग)
टीमें स्वयं अपने सर्वरों को अनुप्रयोगों की तैनाती का प्रबंधन करती हैं (यह पपेट के माध्यम से नहीं किया जाता है)

थोड़ा सा इतिहास

प्रारंभ में, हमारे पास संस्करण 3 पपेट में सब कुछ था, फिर हमने 4 वें पपेट को लागू करने का फैसला किया, और सभी नए सर्वरों को इसमें रखा जाने लगा, और पुराने को धीरे-धीरे 4 वें पर रखा गया।

तीसरे पपेट में, हम नोड फाइलों और मॉड्यूल की क्लासिक प्रणाली का उपयोग करते थे। मॉड्यूल गीतालाब में परियोजनाओं के एक विशेष समूह में बनाए गए थे, उन्हें एक पपेट सर्वर ( r10k का उपयोग करके ) पर क्लोन किया गया था, फिर पपेट एजेंट विज़ार्ड में आए और इसे सर्वर पर लागू करने के लिए एक निर्देशिका प्राप्त की।

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

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

जब आपके पास एक प्रौद्योगिकी चिड़ियाघर के साथ 30 टीमें हों, तो> 1000 सर्वरों के साथ इस menagerie को कैसे बनाए रखने की समस्या विशेष रूप से तीव्र हो जाती है। आगे मैं बताऊंगा कि कैसे हिरा हमें इसमें मदद करता है।

अनुक्रम

हियरा (वास्तव में, जिससे इसे इसका नाम मिला) एक पदानुक्रम सेट करता है। हमारे साथ, ऐसा दिखता है:

--- :hierarchy: - "nodes/%{::fqdn}" - "teams/%{::team}_team/nodes/%{::fqdn}" - "teams/%{::team}_team/projects/%{::project}/tiers/%{::tier}" - "teams/%{::team}_team/projects/%{::project}/%{::role}" - "teams/%{::team}_team/projects/%{::project}" - "teams/%{::team}_team/roles/%{::role}" - "teams/%{::team}_team/%{::team}" - "projects/%{::project}/tiers/%{::tier}/%{::role}" - "projects/%{::project}/tiers/%{::tier}" - "projects/%{::project}/%{::role}" - "projects/%{::project}" - "tiers/%{::tier}" - "virtual/%{::virtual}" - "os/%{::operatingsystem}/%{::operatingsystemmajrelease}" - "os/%{::operatingsystem}" - users - common

पहले, अस्पष्ट चर (तथ्यों) से निपटते हैं।

SEMrush में प्रत्येक सर्वर को आदर्श रूप से 4 उजागर करना चाहिए, विशेष तथ्य जो इसकी संबद्धता का वर्णन करते हैं:

team तथ्य - यह किस टीम से संबंधित है
तथ्य project - यह किस परियोजना से संबंधित है
role तथ्य - इस परियोजना की क्या भूमिका है
वास्तविक तथ्य - यह किस प्रकार का मंचन करता है (ठेस, परीक्षण, देव)

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

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

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

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

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

यदि हमें एक ही भूमिका में दो समान सर्वरों को तैनात करने की आवश्यकता है, लेकिन उनमें कुछ अलग होना चाहिए, उदाहरण के लिए, कॉन्फ़िगरेशन में कुछ लाइनें, तो पदानुक्रम का एक और हिस्सा बचाव में आएगा। हम फ़ाइलों को प्रारूप {fqdn }.yaml के नाम से सही जगह पर रखते हैं (उदाहरण के लिए, nodes/myserver.domain.net ), एक विशिष्ट सर्वर के स्तर पर चर के आवश्यक मान सेट करें, और भूमिका के लिए दोनों सर्वर के लिए एक ही कॉन्फ़िगरेशन लागू करेगा, और प्रत्येक के लिए अद्वितीय है। सर्वर से।

उदाहरण: php कोड वाले दो बैकएंड एक ही भूमिका में हैं और पूरी तरह समान हैं। यह स्पष्ट है कि हम दोनों सर्वर का बैकअप नहीं लेना चाहते हैं - इसका कोई मतलब नहीं है। हम दोनों सर्वरों के लिए एक ही विन्यास का वर्णन करने के लिए एक भूमिका बना सकते हैं, और फिर एक और nodes/backend1.semrush.net फ़ाइल बना सकते हैं जिसमें बैकअप के लिए कॉन्फ़िगरेशन रखना है।

बैच फ़ाइल teams/team-name.yaml संबंधित सभी सर्वरों के लिए कॉन्फ़िगरेशन को इंगित करता है। सबसे अधिक बार, यह उन उपयोगकर्ताओं का वर्णन करता है जो इन सर्वरों के साथ बातचीत कर सकते हैं, साथ ही साथ उनके एक्सेस अधिकार भी।

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

यह इस प्रकार है कि चर इस पदानुक्रम के आधार पर ओवरराइड कर सकते हैं । अर्थात्, भूमिका फ़ाइल " projects/%{::project}/%{::role} " में चर प्रोजेक्ट फ़ाइल " projects/%{::project} " में चर पर पूर्वता लेता है। चर भी पदानुक्रम के सभी स्तरों पर विलय कर सकते हैं यदि आपके पास एक मॉड्यूल और / या प्रोफ़ाइल / भूमिका इस तरह से लिखी गई है जो आपको ऐसा करने की अनुमति देती है। सभी प्रोजेक्ट सर्वर के लिए mysql config के सामान्य भाग को निर्दिष्ट करके, आप विशेष भागों को जोड़ सकते हैं, जिनका इस भूमिका के लिए वजन पदानुक्रम के अन्य स्तरों पर समान चर में हो (दास के लिए कॉन्फ़िगरेशन में एक अतिरिक्त अनुभाग होगा)।

यह पता चलता है कि " hieradata/nodes/%{::fqdn} " पथ के साथ स्थित विशिष्ट नोड की फ़ाइल की सर्वोच्च प्राथमिकता है। अगला नोड फ़ाइल आता है, लेकिन पहले से ही कमांड स्तर पर। नीचे वह ब्लॉक है जो अन्य, अधिक सामान्य तथ्यों का वर्णन करता है:

  - "virtual/%{::virtual}" - "os/%{::operatingsystem}/%{::operatingsystemmajrelease}" - "os/%{::operatingsystem}" - users - common

तदनुसार, फ़ाइल में common.yaml हमारे पास एक कॉन्फ़िगरेशन है जो निश्चित रूप से सभी सर्वरों में आना चाहिए, फ़ाइल users.yaml सभी उपयोगकर्ताओं को वर्णित किया जाता है (लेकिन उनमें से सभी सर्वरों पर नहीं बनाए जाते हैं, निश्चित रूप से), os/%{::operatingsystem} एक विशिष्ट OS (तथ्य ::operatingsystem ) और इसी तरह सर्वर के लिए सामान्य कॉन्फ़िगरेशन विशिष्ट है।

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

प्रोफाइल

मॉड्यूल का उपयोग कर सर्वर को कॉन्फ़िगर करने में एक महत्वपूर्ण बिंदु प्रोफाइल का उपयोग है। वे पथ site/profiles पर स्थित हैं और मॉड्यूल के लिए प्रवेश बिंदु हैं। उनके लिए धन्यवाद, आप सर्वर पर हैंगिंग मॉड्यूल को अधिक सूक्ष्मता से कॉन्फ़िगर कर सकते हैं और आवश्यक संसाधन बना सकते हैं।

एक साधारण उदाहरण पर विचार करें। एक मॉड्यूल है जो रेडिस को स्थापित और कॉन्फ़िगर करता है। और हम इस मॉड्यूल को जोड़ने पर sysctl पैरामीटर vm.overcommit_memory को 1 पर सेट करना चाहते हैं, क्योंकि यहाँ । फिर हम एक छोटी प्रोफ़ाइल लिखते हैं जो इस कार्यक्षमता को प्रदान करती है:

 # standalone redis server class profiles::db::redis ( Hash $config = {}, String $output_buffer_limit_slave = '256mb 64mb 60', ) { # https://redis.io/topics/faq#background-saving-fails-with-a-fork-error-under-linux-even-if-i-have-a-lot-of-free-ram sysctl { 'vm.overcommit_memory': ensure => present, value => '1', } class { '::redis': * => $config, } }

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

हिरा में रहस्य छिपा

नंगे पपेट की तुलना में हिरा का एक महत्वपूर्ण लाभ रिपॉजिटरी में एन्क्रिप्टेड रूप में कॉन्फ़िगरेशन फ़ाइलों में संवेदनशील डेटा को संग्रहीत करने की क्षमता है। आपके पासवर्ड सुरक्षित रहेंगे।

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

क्लाइंट (काम करने वाले कंप्यूटर) पर, उपकरण केवल gem install hiera-eyaml का उपयोग करके स्थापित किया जाता है। इसके अलावा, प्रपत्र eyaml encrypt --pkcs7-public-key=/path/to/public_key.pkcs7.pem -s 'hello' की एक कमांड का उपयोग करते हुए eyaml encrypt --pkcs7-public-key=/path/to/public_key.pkcs7.pem -s 'hello' आप डेटा एन्क्रिप्ट कर सकते हैं और इसे एक्सटेंशन eyaml या सिर्फ yaml के साथ फाइल में पेस्ट कर सकते हैं, जो आप पर निर्भर करता है। कॉन्फ़िगर करें, और फिर पपेट यह पता लगाएगा। आपको कुछ ऐसा मिलता है:

 roles::postrgresql::password: 'ENC[PKCS7,MIIBeQYJKoZIhvcNAQcDoIIBajCCAWYCAQAxggEhMIIBHQIBADAFMAACAQEwDQYJKoZIhvcNAQEBBQAEggEAbIz1ihQlThMWa9T+Lq194Y6QdElMD1XTev5y+VPSHtkPTu6Al6TJaSrXF+7phJIjue+NF4ZVtJCLkHxUR6nJJqks0fcGS1vF2+6mmM9cy69sIU1A3HqpOHZLuqHAc7jUqljYxpwWSIGOK6I2FygdAp5FfOTewqfcVVmXj97EJdcv3DKrbAlSrIMO2iZRYwQvyv+qnptnZ7pilR2veOCPW2UMm6zagDLutX9Ft5vERbdaiCiEfTOpVa9Qx0GqveNRVJLV/5lfcL5ajdNBJXkvKqDbx8d3ZBtEVAAqeKlw0LqzScgmCbWQx2kUzukX5LSxbTpT0Th984Vp1sl7iPk7UTA8BgkqhkiG9w0BBwEwHQYJYIZIAWUDBAEqBBCp5GcwidcEMA+0wjAMblkKgBCR/f9KGXUgLh3/Ok60OIT5]'

या एक बहु-पंक्ति स्ट्रिंग:

 roles::postgresql::password: > ENC[PKCS7,MIIBeQYJKoZIhvcNAQcDoIIBajCCAWYCAQAxggEhMIIBHQIBADAFMAACAQEw DQYJKoZIhvcNAQEBBQAEggEAbIz1ihQlThMWa9T+Lq194Y6QdElMD1XTev5y +VPSHtkPTu6Al6TJaSrXF+7phJIjue+NF4ZVtJCLkHxUR6nJJqks0fcGS1vF 2+6mmM9cy69sIU1A3HqpOHZLuqHAc7jUqljYxpwWSIGOK6I2FygdAp5FfOTe wqfcVVmXj97EJdcv3DKrbAlSrIMO2iZRYwQvyv+qnptnZ7pilR2veOCPW2UM m6zagDLutX9Ft5vERbdaiCiEfTOpVa9Qx0GqveNRVJLV/5lfcL5ajdNBJXkv KqDbx8d3ZBtEVAAqeKlw0LqzScgmCbWQx2kUzukX5LSxbTpT0Th984Vp1sl7 iPk7UTA8BgkqhkiG9w0BBwEwHQYJYIZIAWUDBAEqBBCp5GcwidcEMA+0wjAM blkKgBCR/f9KGXUgLh3/Ok60OIT5]

ऐसा लगता है कि हम तैयारी के साथ कर रहे हैं, अब हम एक उदाहरण पर विचार कर सकते हैं।

उंगली का उदाहरण

Spoiler : कई और कॉन्फ़िगरेशन होंगे, इसलिए जो लोग विशुद्ध रूप से सैद्धांतिक रुचि के इस लेख में रुचि रखते हैं वे इस अनुभाग को छोड़ सकते हैं और अंत में जा सकते हैं।

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

कार्य यह है: हमें तैनात करने की आवश्यकता है:

दो समान डीबी सर्वर, जिस पर पोस्टग्रैस्कल तैनात है
दो और सर्वर - नगनेक्स के साथ सामने
पांचवें और छठे सर्वर - अजगर docker में समर्थन करता है
कुछ सर्वर कॉन्फ़िगरेशन को छोड़कर, देव वातावरण पर सब कुछ समान है

हम क्रम में अपनी पदानुक्रम बनाएंगे और हम परियोजना फ़ाइल के साथ शुरू करेंगे।

परियोजना

प्रोजेक्ट फ़ाइल projects/kicker.yaml बनाएं projects/kicker.yaml । हमने इसमें लिखा है कि सभी सर्वरों के लिए क्या सामान्य है: हमें तैनाती के लिए कुछ रिपॉजिटरी और फ़ोल्डर्स की आवश्यकता होती है, साथ ही उपयोगकर्ता खुद को भी तैनात करता है।

 --- classes: - apt::debian::semrush files: "/srv/data": ensure: 'directory' owner: 'deploy' group: 'www-data' mode: '0755' '/srv/data/shared_temp': ensure: 'directory' owner: 'deploy' group: 'www-data' mode: '0775' user_management::present: - deploy

डीबी की भूमिका

projects/kicker/db.yaml डेटाबेस सर्वर के लिए एक भूमिका फ़ाइल बनाएँ। अब तक, हम सर्वर को पर्यावरण में विभाजित किए बिना करेंगे:

 --- classes: - profiles::db::postgresql profiles::db::postgresql::globals: manage_package_repo: true version: '10' profiles::db::postgresql::db_configs: 'listen_addresses': value: '*' profiles::db::postgresql::databases: kicker: {} profiles::db::postgresql::hba_rules: 'local connect to kicker': type: 'local' database: 'kicker' user: 'kicker' auth_method: 'md5' order: '001' 'allow connect from 192.168.1.100': type: 'host' database: 'kicker' user: 'kicker' auth_method: 'md5' address: '192.168.1.100/32' order: '002'

यहां हम उन सभी लोगों द्वारा सामान्य उपयोग के लिए लिखी गई एक प्रोफ़ाइल को कनेक्ट करते हैं जो अपने सर्वर पर पोस्टग्रेज स्थापित करना चाहते हैं। प्रोफ़ाइल कॉन्फ़िगर करने योग्य है और आपको इसे लागू करने से पहले लचीले ढंग से मॉड्यूल को कॉन्फ़िगर करने की अनुमति देता है।

इस प्रोफ़ाइल के लिए बिल्ली कोड के नीचे सबसे जिज्ञासु के लिए:

प्रोफ़ाइल :: db :: postgresql

 class profiles::db::postgresql ( Hash $globals = {}, Hash $params = {}, Hash $recovery = {}, Hash[String, Hash[String, Variant[String, Boolean, Integer]]] $roles = {}, Hash[String, Hash[String, Variant[String, Boolean]]] $db_configs = {}, Hash[String, Hash[String, Variant[String, Boolean]]] $databases = {}, Hash[String, String] $db_grants = {}, Hash[String, Hash[String, String]] $extensions = {}, Hash[String, String] $table_grants = {}, Hash[String, Hash[String, String]] $hba_rules = {}, Hash[String, String] $indent_rules = {}, Optional[String] $role = undef, # 'master', 'slave' Optional[String] $master_host = undef, Optional[String] $replication_password = undef, Integer $master_port = 5432, String $replication_user = 'repl', String $trigger_file = '/tmp/pg_trigger.file', ){ case $role { 'slave': { $_params = { manage_recovery_conf => true, } if $globals['datadir'] { file { "${globals['datadir']}/recovery.done": ensure => absent, } } $_recovery = { 'recovery config' => { standby_mode => 'on', primary_conninfo => "host=${master_host} port=${master_port} user=${replication_user} password=${replication_password}", trigger_file => $trigger_file, } } $_conf = { 'hot_standby' => { value => 'on', }, } file { $trigger_file: ensure => absent, } } 'master': { $_conf = { 'wal_level' => { value => 'replica', }, 'max_wal_senders' => { value => 5, }, 'wal_keep_segments' => { value => 32, }, } file { $trigger_file: ensure => present, } } default: { $_params = {} $_recovery = {} $_conf = {} } } class { '::postgresql::globals': * => $globals, } class { '::postgresql::server': * => deep_merge($_params, $params), } create_resources('::postgresql::server::config_entry', deep_merge($_conf, $db_configs)) create_resources('::postgresql::server::role', $roles) create_resources('::postgresql::server::database', $databases) create_resources('::postgresql::server::database_grant', $db_grants) create_resources('::postgresql::server::extension', $extensions) create_resources('::postgresql::server::table_grant', $table_grants) create_resources('::postgresql::server::pg_hba_rule', $hba_rules) create_resources('::postgresql::server::pg_indent_rule', $indent_rules) create_resources('::postgresql::server::recovery', deep_merge($_recovery, $recovery)) }

इस प्रकार, हम Postgresql 10 एक गिर गए झपट्टा Postgresql 10 स्थापित करते हैं, कॉन्फ़िगर ( listen ) को कॉन्फ़िगर करते हैं, kicker डेटाबेस बनाते हैं, और pg_hba.conf में इस डेटाबेस तक पहुंचने के लिए दो नियम भी लिखते हैं। कूल!

सामने की भूमिका

हम frontend उठाते हैं। निम्नलिखित सामग्री के साथ projects/kicker/frontend.yaml फ़ाइल बनाएँ:

 --- classes: - profiles::webserver::nginx profiles::webserver::nginx::servers: 'kicker.semrush.com': use_default_location: false listen_port: 80 server_name: - 'kicker.semrush.com' profiles::webserver::nginx::locations: 'kicker-root': location: '/' server: 'kicker.semrush.com' proxy: 'http://kicker-backend.semrush.com:8080' proxy_set_header: - 'X-Real-IP $remote_addr' - 'X-Forwarded-for $remote_addr' - 'Host kicker.semrush.com' location_cfg_append: 'proxy_next_upstream': 'error timeout invalid_header http_500 http_502 http_503 http_504' proxy_connect_timeout: '5'

यहां सब कुछ सरल है। हम profiles::webserver::nginx प्रोफाइल कनेक्ट करते हैं, जो nginx मॉड्यूल में प्रवेश को तैयार करता है, और इस साइट के लिए चर, विशेष रूप से server और location को भी परिभाषित करता है।

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

डॉकटर की भूमिका

projects/kicker/docker.yaml की भूमिका projects/kicker/docker.yaml :

 --- classes: - profiles::docker profiles::docker::params: version: '17.05.0~ce-0~debian-stretch' packages: 'python3-pip': provider: apt 'Fabric3': provider: pip3 ensure: 1.12.post1 user_management::users: deploy: groups: - docker

profiles/docker.pp बहुत ही सरल और सुरुचिपूर्ण है। मैं उसका कोड दूंगा:

प्रोफ़ाइल :: docker

 class profiles::docker ( Hash $params = {}, Boolean $install_kernel = false, ){ class { 'docker': * => $params, } if ($install_kernel) { include profiles::docker::kernel } }

सब कुछ तैयार है। यह पहले से ही कई सर्वरों पर हमारे द्वारा आवश्यक उत्पाद को तैनात करने के लिए पर्याप्त है, बस उन्हें एक विशिष्ट परियोजना और भूमिका (उदाहरण के लिए, फ़ाइल को facts.d निर्देशिका में वांछित प्रारूप में डालना, जिसका स्थान कठपुतली स्थापित करने की विधि पर निर्भर करता है) को निर्दिष्ट करने के लिए पर्याप्त है।

अब हमारे पास निम्न फ़ाइल संरचना है:

 . ├── kicker │ ├── db.yaml │ ├── docker.yaml │ └── frontend.yaml └── kicker.yaml 1 directory, 4 files

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

पर्यावरण और ओवरराइड

चलो सभी बिक्री के लिए सामान्य कॉन्फ़िगरेशन बनाते हैं। फ़ाइल projects/kicker/tiers/prod.yaml में एक संकेत होता है कि हमें एक वर्ग को फ़ायरवॉल के साथ इस वातावरण से जोड़ने की आवश्यकता है (अच्छी तरह से, सभी समान), साथ ही एक निश्चित वर्ग जो सुरक्षा का एक बढ़ा स्तर प्रदान करता है:

 --- classes: - semrush_firewall - strict_security_level

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

अगला, आपको अभी भी देव वातावरण में frontend भूमिका के नेगनेक्स कॉन्फ़िगरेशन के लिए चर को फिर से परिभाषित करने की आवश्यकता है। ऐसा करने के लिए, आपको फ़ाइल projects/kicker/tiers/dev/frontend.yaml बनाने की आवश्यकता है। पदानुक्रम के एक नए स्तर पर ध्यान दें।

 --- profiles::webserver::nginx::servers: 'kicker-dev.semrush.com': use_default_location: false listen_port: 80 server_name: - 'kicker-dev.semrush.com' profiles::webserver::nginx::locations: 'kicker-root': location: '/' server: 'kicker-dev.semrush.com' proxy: 'http://kicker-backend-dev.semrush.com:8080' proxy_set_header: - 'X-Real-IP $remote_addr' - 'X-Forwarded-for $remote_addr' - 'Host kicker-dev.semrush.com' location_cfg_append: 'proxy_next_upstream': 'error timeout invalid_header http_500 http_502 http_503 http_504' proxy_connect_timeout: '5'

अब आपको एक वर्ग निर्दिष्ट करने की आवश्यकता नहीं है, यह पदानुक्रम के पिछले स्तरों से विरासत में मिला है। यहां हमने proxy_pass और proxy_pass बदल दिया है। एक सर्वर जिसमें तथ्यों की भूमिका होती है = frontend और tier = dev को पहले अपने लिए projects/kicker/frontend.yaml फाइल मिल जाएगी, लेकिन फिर इस फाइल के वैरिएबल को projects/kicker/tiers/dev/frontend.yaml फाइल से अधिक प्राथमिकता के साथ ओवरराइड किया जाएगा। ।

PostgreSQL के लिए पासवर्ड छिपा रहा है

और इसलिए हमारे पास एजेंडा पर अंतिम आइटम है - पोस्टग्रेएसक्यूएल के लिए पासवर्ड सेट करें।

वातावरण में पासवर्ड अलग-अलग होने चाहिए। हम पासवर्ड को सुरक्षित रूप से संग्रहीत करने के लिए आईमैल का उपयोग करेंगे। पासवर्ड बनाएँ:

 eyaml encrypt -s 'verysecretpassword' eyaml encrypt -s 'testpassword'

हम फ़ाइलों में परिणामी पंक्तियों को पेस्ट करते हैं **projects/kicker/tiers/prod/db.yaml** और **projects/kicker/tiers/dev/db.yaml** (या आप आईलैम एक्सटेंशन का उपयोग कर सकते हैं, यह अनुकूलन योग्य है)। यहाँ एक उदाहरण है:

 --- profiles::db::postgresql::roles: 'kicker': password_hash: > 'ENC[PKCS7,MIIBeQYJKoZIhvcNAQcDoIIBajCCAWYCAQAxggEhMIIBHQIBADAFMAACAQEwDQYJKoZIhvcNAQEBBQAEggEAsdpb2P0axUJzyWr2duRKAjh0WooGYUmoQ5gw0nO9Ym5ftv6uZXv25DRMKh7vsbzrrOR5/lLesx/pAVmcs2qbhd/y0Vr1oc2ohHlZBBKtCSEYwem5VN+kTMhWPvlt93x/S9ERoBp8LrrsIvicSYZByNfpS2DXCFbogSXCfEPxTTmCOtlOnxdjidIc9Q1vfAXv7FRQanYIspr2UytScm56H/ueeAc/8RYK51/nXDMtdPOiAP5VARioUKyTDSk8FqNvdUZRqA3cl+hA+xD5PiBHn5T09pnH8HyE/39q09gE0pXRe5+mOnU/4qfqFPc/EvAgAq5mVawlCR6c/cCKln5wJTA8BgkqhkiG9w0BBwEwHQYJYIZIAWUDBAEqBBDNKijGHBLPCth0sfwAjfl/gBAaPsfvzZQ/Umgjy1n+im0s]'

इसके बाद, kicker भूमिका के लिए पासवर्ड आएगा, डिक्रिप्ट किया जाएगा और पोस्टग्रेएसक्यूएल में डेटाबेस सर्वर पर लागू किया जाएगा।

वह, वास्तव में, सब है। हां, उदाहरण बड़े पैमाने पर निकला, लेकिन, मुझे उम्मीद है कि कार्यात्मक, सवाल नहीं छोड़ रहा है, स्पष्ट और उपयोगी है। हाइर में परिणामी पदानुक्रम यह है:

 . ├── db.yaml ├── docker.yaml ├── frontend.yaml └── tiers ├── dev │ ├── db.yaml │ └── frontend.yaml ├── prod │ └── db.yaml └── prod.yaml 3 directories, 7 files

आप इन फ़ाइलों को एक विशेष रूप से बनाए गए भंडार क्लोन द्वारा लाइव देख सकते हैं

निष्कर्ष

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

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

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

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

क्रेडिट

धन्यवाद:

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

कठपुतली + हिरे। अधिकतम निचोड़ें