साल्टस्टैक: लचीले विन्यास के लिए जिनजा टेम्प्लेट और स्तंभ भंडारण का उपयोग करना

यहाँ क्या दिलचस्प है?

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

साल्टस्टैक: राज्य विन्यास के निर्माण के लिए विचारधारा

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

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

प्राथमिक राज्य विवरण

इसलिए, मैं विस्तार से नहीं कहूंगा कि टाइनीप्रॉक्सी क्या है और इसकी आवश्यकता क्यों है (जानकार, और इतना समझने योग्य, जिज्ञासु - Google मदद करने के लिए), मैं केवल यह कह सकता हूं कि मैं अपने ग्राहकों को एक प्रॉक्सी सेवा प्रदान करने के लिए परियोजनाओं में से एक में इसका उपयोग करता हूं। योजना: दुनिया भर में बिखरे हुए टाइनीप्रॉक्सी के साथ 20-30 सर्वर। स्थापना और कॉन्फ़िगरेशन अत्यंत सरल है, इसलिए हम विस्तृत विवरण को याद करेंगे, और केवल उसी पर काम करेंगे जो कार्य के लिए महत्वपूर्ण है, और इस मामले में यह निम्नानुसार है: क्लाइंट आईपी पते के आधार पर प्रॉक्सी सेवाओं तक पहुंच को प्रतिबंधित करें। विन्यास के संदर्भ में, TinyProxy एक अनुमति निर्देश है।

वास्तव में राज्य जो सेवा (मेरे मॉडल के संदर्भ में) बनाता है TinyProxy:
tinyproxy.sls

tinyproxy-config: file.managed: - name: /etc/tinyproxy.conf - source: salt://__DEFAULT-CONFIGS/tinyproxy.conf - template: jinja - require: - pkg: tinyproxy-pkg tinyproxy-pkg: pkg.installed: - name: tinyproxy tinyproxy-service: service.running: - name: tinyproxy - full_restart: True - require: - pkg: tinyproxy-pkg - watch: - file: tinyproxy-config 

महत्वपूर्ण बिंदु:

• हम /etc/tinyproxy.conf फ़ाइल का नियंत्रण लेते हैं
• इसका प्रोटोटाइप (टेम्पलेट) नमक पर है: //__DEFAULT-CONFIGS/tinyproxy.conf विज़ार्ड
• हम राज्य को सूचित करते हैं कि इस फ़ाइल को जिंजा ( - टेम्पलेट: जिंजा) का उपयोग करके संसाधित करने की आवश्यकता है और इसमें टेम्प्लेट कमांड हैं (नीचे वर्णित है)

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

टिनपाक्सि.कॉन्फ़र भाग जिंजा टेम्पलेट के साथ

 . . . # # Allow: Customization of authorization controls. If there are any # access control keywords then the default action is to DENY. Otherwise, # the default action is ALLOW. # # The order of the controls are important. All incoming connections are # tested against the controls based on order. # {% for allowed_ip in pillar['tinyproxy']['allowed_ips'] -%} Allow {{ allowed_ip }} {% endfor %} . . . 

एक महत्वपूर्ण बिंदु: सही तरीके से टेम्प्लेट बनाने के बारे में और यहां % के पास डैश क्यों पढ़ा जा सकता है ; टेम्पलेट के लिए डेटा पिलर सिस्टम से लिया गया है।

इन मामलों के लिए स्वयं स्तंभ (मेरे मॉडल - संसाधन के संदर्भ में) इस प्रकार है:
tinyproxy-pillar.sls

 tinyproxy: allowed_ips: - 1.2.3.4 - 2.3.4.5 - 3.4.5.6 

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

 . . . # # Allow: Customization of authorization controls. If there are any # access control keywords then the default action is to DENY. Otherwise, # the default action is ALLOW. # # The order of the controls are important. All incoming connections are # tested against the controls based on order. # Allow 1.2.3.4 Allow 2.3.4.5 Allow 3.4.5.6 . . . 

परिणाम क्या है?

इन सभी जोड़तोड़ों को यह सुनिश्चित करने के लिए डिज़ाइन किया गया था कि अगर आपको क्लाइंट का आईपी पता (एक्सेस पॉलिसी के अनुसार) जोड़ना या निकालना है, तो यह पिलर फ़ाइल में डेटा को सही करने के लिए पर्याप्त है (एक लाइन जोड़ें या हटाएं) और सभी प्रॉक्सी के लिए स्थिति को चलाएँ। '* प्रॉक्सी *'।