Fabric: v2-संगत 'भूमिकाएं' या समान

को निर्मित 22 अप्रैल 2017 · 7टिप्पणियाँ · स्रोत: fabric/fabric

सार

लेखन के समय, v2 शाखा में Group वर्ग होता है जो पूर्व में 'भूमिकाओं' के रूप में जानी जाने वाली इकाइयों के रूप में सेवा करने में सक्षम होना चाहिए, उर्फ "मेजबानों का एक समूह जो सामान के साथ/चालू करता है"।

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

एक और तरीका रखो, जब तक कि आप पूरी तरह से एपीआई के साथ रोल नहीं कर रहे हैं, अगर सीएलआई या टास्क-कॉलिंग बिट्स के पास उन्हें खोजने का कोई तरीका नहीं है, तो ग्रुप ऑब्जेक्ट कहीं न कहीं बेकार है!

पृष्ठभूमि

v1 में, भूमिकाएं प्रभावी रूप से एक फ्लैट नेमस्पेस थीं जो सरल स्ट्रिंग लेबल को मैप करती थीं जो कि v2 में समूह होंगे, और उन्हें रनटाइम पर सीएलआई पर चुना जा सकता है ( fab --roles=web,db ) और/या कार्यों के लिए डिफ़ॉल्ट लक्ष्य के रूप में पंजीकृत ( @task('db') \n def migrate(): ), बहुत कुछ मेजबानों की तरह।

उपयोगकर्ताओं ने उन्हें env.roledefs में परिभाषित किया, एक साधारण निर्देश; उन्नत कार्यक्षमता के लिए कोई भी मध्यवर्ती इसे संशोधित करने के इर्द-गिर्द घूमता है, आमतौर पर रनटाइम पर (पूर्व-कार्य या सबरूटीन के माध्यम से), कभी-कभी मॉड्यूल लोड समय पर।

विशिष्ट उपयोग के मामले / ज़रूरतें / उप-सुविधाएँ

सिस्टम में कहीं और उपयोग/संदर्भ के लिए बुनियादी, अनुभवहीन मैपिंग: एक नाम डालें, Group s और/या Connection s के कुछ चलने योग्य वापस प्राप्त करें।
- अलियासिंग अक्सर इसके साथ जाना चाहता है, उदाहरण के लिए Lexicon बजाय dict ।
- यहां तक कि गहरी संरचनाएं, जैसे 'बंडलिंग', उदाहरण के लिए आपके पास db , web , lb नामक प्रत्यक्ष मैपिंग है, लेकिन फिर prod नामक एक द्वितीय-स्तरीय नाम है Lexicon जोड़ा है। संभव है कि वहाँ अन्य मानचित्र उपवर्ग हों जो पहले से ही ऐसा करते हों।
- इसके अतिरिक्त/वैकल्पिक रूप से, ग्लोबिंग या अन्य स्ट्रिंग सिंटैक्स जैसी चीजें, हालांकि मैं व्यक्तिगत रूप से इस तथ्य का लाभ उठाना पसंद करूंगा कि पायथन "स्ट्रिंग टाइप" नहीं है ...
उपयोगी 'रिवर्स मैपिंग' ताकि आप यह पहचान सकें कि दिया गया कनेक्शन किन समूहों से संबंधित है।
- समस्याग्रस्त: क्योंकि वर्तमान में कोई वैश्विक साझा स्थिति नहीं है, इसका भोली उत्तर - पहचान का उपयोग करना - नीचे गिर जाता है क्योंकि आप तकनीकी रूप से कई समान कनेक्शन ऑब्जेक्ट बना सकते हैं।
- खासकर जब से समूह उन्हें आपकी ओर से परोक्ष रूप से बना सकता है यदि आप इसे केवल शॉर्टहैंड होस्ट स्ट्रिंग देते हैं, हालांकि यह केवल एक सुविधा विकल्प है।
- हालांकि, कोई वैश्विक स्थिति की बाधा को देखते हुए, मैं इसके बजाय समानता परीक्षण का उपयोग करने के साथ स्पष्ट समस्याएं नहीं देख सकता, इसलिए यह करने योग्य होना चाहिए, उदाहरण के लिए if cxn in group काम करेगा भले ही cxn एक अलग वस्तु है अंदर बराबर सदस्य से group ।
- केवल एक चीज जो दिमाग में आती है वह यह है कि यदि कनेक्शन से किसी समूह से मजबूत, स्टेटफुल लिंक होते हैं (समूह, बहुवचन होना चाहिए), तो इसके विपरीत, लेकिन मुझे उस ऑफहैंड के महान कारण नहीं दिख रहे हैं।
पिछले से दृढ़ता से संबंधित: "वर्तमान में चल रही भूमिका" का निरीक्षण/प्रदर्शित करने की क्षमता (कुछ लोग v1 में लंबे समय से चाहते थे जो इसके डिजाइन के कारण गैर-तुच्छ था)
- मुख्य मुद्दा यह है कि यह वास्तव में दो अलग-अलग प्रश्न हैं: "वर्तमान में कौन सी भूमिका (भूमिकाओं) का वर्तमान मेजबान हिस्सा है, आम तौर पर बोल रहा है" (मूल रूप से, रिवर्स लुकअप का पिछला उपयोग मामला) लेकिन यह भी "क्या भूमिका थी निष्पादन मशीनरी ने विशेष रूप से इसके खिलाफ चलने के लिए कहा"।
- दूसरे शब्दों में, ए, बी और सी भूमिकाओं से संबंधित होस्ट 'फू' दिया गया है: किसी दिए गए कार्य के भीतर जिसका संदर्भ 'फू' है, लेकिन जिसे 'भूमिका ए पर निष्पादित' करने के अनुरोध के कारण चलाया गया था, वह उपयोगकर्ता है "ए, बी और सी" का उत्तर (भूमिकाएं 'फू' समग्र रूप से है) या सिर्फ "ए" (वर्तमान में निष्पादित भूमिका)?
- यह वास्तव में दो अलग-अलग एपीआई कॉलों की तरह लगता है, भले ही फीचर अनुरोध मुझे याद है कि दोनों को मिलाना है।
वैश्विक स्तर पर और/या प्रति-कार्य सीएलआई पर लक्ष्य चयन
- इनवोक के सीएलआई सिस्टम का विस्तार "झंडे जो सभी कार्यों को उनके द्वारा परिभाषित किए जाने के शीर्ष पर मिलता है" के लिए उपयोगी हो सकता है या इसके लिए आवश्यक हो सकता है। जो वास्तव में pyinvoke/invoke#205 क्षेत्र में मजबूती से गिरता है, ताकि पहले से ही उच्च प्राथमिकता प्राप्त हो (जो बहुत अधिक थी।)
ठीक इसी तरह कार्य-स्तर चूक
- हालांकि कार्य-स्तरीय लक्ष्य डिफ़ॉल्ट वास्तव में इनमें से कोई भी होना चाहते हैं: कनेक्शन, कनेक्शन, समूह obj, समूह objs, या _to_ समूह objs का मूल्यांकन करने वाला नाम (यही आखिरी चीज है जो सीधे इस टिकट से संबंधित है, तर्कसंगत रूप से)
डिट्टो संग्रह-स्तर डिफ़ॉल्ट (v2 में नया!)
- यानी "$ सबमॉड्यूल में सभी कार्य डिफ़ॉल्ट रूप से db भूमिका के विरुद्ध चल रहे हैं"
- पिछले बिंदु के समान सौदा - यह डिफ़ॉल्ट कई अलग-अलग मानों को अनुमति देना चाहता है, न कि केवल एक स्ट्रिंग कुंजी।
ओओ दृष्टिकोण द्वारा सक्षम कुछ और नया और रोमांचक जो वास्तव में इसके साथ जाना चाहता है? याद रखें कि ब्लॉक बनाने और उन्नत उपयोगकर्ताओं को सक्षम करने पर जोर दिया जाना चाहिए, उदाहरण के लिए शेफ या एन्सिबल जैसे सिस्टम को पूरी तरह से पुनर्निर्मित करने पर नहीं।

कार्यान्वयन के विचार/चिंताएं

यदि हम मुख्य भंडारण वेक्टर के रूप में कॉन्फ़िगरेशन सिस्टम का उपयोग करते हैं, तो मान "चाहते हैं" आदिम होने के लिए ताकि उन्हें यामल, जेसन इत्यादि में संग्रहीत किया जा सके, लेकिन यह "सभी समूह/कनेक्शन क्वार्ग को एक बड़े ओएल में स्टोर करें" के साथ समाप्त होने वाले कीड़े का एक कैन है। लिस्ट-ओ-डिक्ट्स", आदि।
यदि हम मुख्य रूप से पायथन में परिभाषाओं की अपेक्षा करते हैं, तो हम बस "तत्काल समूह ऑब्जेक्ट्स" कह सकते हैं, और फिर हमारे पास उस डेटा को कॉन्फ़िगरेशन सिस्टम में विलय करने या इसे किसी भी तरह स्टैंडअलोन छोड़ने का विकल्प होता है।
- मुझे लगता है कि मैं बाद वाले को पसंद करता हूं क्योंकि नेस्टेड कॉन्फिग डिक्ट्स में सचमुच सब कुछ भरना ऐसा लगता है कि इससे बुरी खबर आएगी।
अलियासिंग और बंडलिंग जैसे गहरे निर्माण जटिलता और आदेश देने वाले मुद्दों को जोड़ते हैं (अर्थात एक तुच्छ उपनाम सेटअप की कल्पना करें जहां key1 का मान एक समूह है लेकिन key2 का मान key1 है; अब आपको key2 को हल करने या जांचने के लिए संरचना को दो बार क्रॉल करना होगा)
- यद्यपि यदि हम अधिकतर "इसे इन-पायथन करें" दृष्टिकोण के लिए जाते हैं, तो यह कॉन्फ़िगरेशन सिस्टम के एपीआई की तरह बन जाता है, जहां आप एक घोषणात्मक संरचना के साथ शुरू कर सकते हैं लेकिन प्रारंभिक सेटअप के बाद विधि कॉल द्वारा कुछ और सक्षम किया जाता है। मुझे नहीं लगता कि यह भयानक है? संपादित करें: और मुझे लगता है कि ठीक इसी तरह लेक्सिकन वैसे भी काम करता है।
प्रारूप की परवाह किए बिना, हमें यह पता लगाना होगा कि उन्नत उपयोगकर्ता इसे बाहरी स्रोतों या इसी तरह से मक्खी पर कैसे उत्पन्न करना चाहेंगे; यह प्लस एलियासिंग और इस तरह के मुद्दों का तात्पर्य है कि हम इसे कहीं भी "संग्रहित" एक बेवकूफ संरचना में नहीं चाहते हैं, लेकिन किसी ऑब्जेक्ट या ऑब्जेक्ट्स पर एपीआई के रूप में इसे उत्पन्न करने के लिए कहा जाता है।
- मुझे संदेह है कि हम भूमिकाओं/समूहों के चयन से 'नीचे की ओर' काम करना चाहते हैं, जो कि उच्चतम स्तर के एपीआई पर पहुंचने के लिए "उपयोगकर्ता ने लक्ष्य की एक क्रियात्मक इकाई में क्या आपूर्ति की है" पर पहुंचने के लिए, क्योंकि सबसे उन्नत उपयोगकर्ता आवश्यक रूप से चाहते हैं उस एपीआई कॉल के कार्यान्वयन पर पूरा नियंत्रण है। तब हम हमेशा की तरह आपूर्ति कर सकते हैं जो एक उपयोगी सामान्य मामले की तरह लगता है लेकिन जिसे स्पष्ट रूप से "इसे करने का सिर्फ एक तरीका" के रूप में चिह्नित किया गया है।
- @RedKrieg के पास इन पंक्तियों के साथ एक निफ्टी विचार है जहां हमारे पास @group जैसे @task , और फ़ंक्शन कार्य की निष्पादन योग्य इकाइयां नहीं हैं, बल्कि इसके बजाय समूह ऑब्जेक्ट्स उत्पन्न करते हैं।
- यह दृष्टिकोण मूल रूप से कार्य पदानुक्रम (संग्रह) का पुन: उपयोग करता है, जो व्यावहारिक है (क्यों पहिया को फिर से शुरू करें) और सुरुचिपूर्ण (क्योंकि वास्तविक दुनिया के मामलों में, भूमिका/समूह परिभाषाएं अक्सर कार्यों का उपयोग करने के लिए बहुत बारीकी से मानचित्र करती हैं!)
  - यह तब भी अच्छी तरह से काम करता है, भले ही आपके समूह आपके कार्यों को मैप न करें, क्योंकि आप केवल अपने रूट संग्रह स्तर पर परिभाषाएँ लिख सकते हैं। बहुत आसान।
- यह मेरे लिए स्पष्ट नहीं है कि क्या यह प्रत्येक फ़ंक्शन से एक समूह को सबसे अच्छा लौटा रहा है, या यदि हम कई समूहों (या कनेक्शन) उत्पन्न करने की क्षमता चाहते हैं, या यदि इसे सजाया कार्यों के रूप में करना सबसे अच्छा है, लेकिन केवल एपीआई कॉल के रूप में संग्रह (जैसे संग्रह-स्तर के कॉन्फ़िगरेशन कैसे संग्रहीत किए जाते हैं)।
- उदाहरण के लिए, उपयोग का मामला जहां समूह/भूमिका डेटा गतिशील है और फैब्रिक के बाहर अभी भी यहां हल करने की आवश्यकता है (यही कारण है कि पहले मैंने नोट किया था कि हमें पहले इस स्थान के लिए उच्चतम-स्तरीय एपीआई की पहचान करनी चाहिए; फिर हमें यह देखने की जरूरत है कि कैसे जाल इस मध्यवर्ती स्तर के विचार के साथ।)

Feature

स्रोत

bitprophet

👍7

सबसे उपयोगी टिप्पणी

नमस्ते, मुझे नहीं पता कि कई वर्षों के बाद इस सॉफ़्टवेयर का क्या हुआ, लेकिन मैं वास्तव में फ़ैब्रिक@ 1. चूक गया , खासकर जब $ fab -R dev चल रहा हो

ibigbug 9 जन॰ 2020

👍4

सभी 7 टिप्पणियाँ

मेलिंग सूची से:

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

हमारे उपयोग के मामले हैं:

पर्यावरण मुक्त कोडबेस https://12factor.net/config। परिवेश (भूमिकाएं) और उनके संबंधित मेजबान तार एक केंद्रीकृत डेटाबेस में संग्रहीत किए जाते हैं। प्रत्येक fabfile.py में कुछ ऐसा होता है (फ़ाइल आयात होने पर यह env.roledefs को पॉप्युलेट करता है):

EnvironmentDatabaseAPIClient(
    'https://rest.api.url/schema/',
    env.service_name,
).apply_env()

सर्वर परिवेशों की संख्या - एकाधिक परीक्षण परिवेश (उनमें से कुछ निजी हैं, कुछ सार्वजनिक हैं) और एकाधिक उत्पादन परिवेश (विभिन्न ग्राहकों के लिए)। प्रत्येक वातावरण में एक या अधिक मेजबान होते हैं और इसे कपड़े की भूमिका के लिए मैप किया जाता है।
प्रत्येक सेवा ( env.service_name ऊपर के उदाहरण में) में अलग-अलग वातावरण हैं।
इसके अलावा हमारे पास मेटा-रोल्स (भूमिकाओं के समूह) हैं। उनके पहले group- : group-production , group-test , group-external , group-internal , group-all । यह हमें एकाधिक सर्वर भूमिकाओं को एक-एक करके निर्दिष्ट किए बिना परिनियोजित करने की अनुमति देता है, उदाहरण के लिए group-all उत्पादन और परीक्षण दोनों में सभी भूमिकाओं के लिए परिनियोजित करता है।
भूमिका समूहों, भूमिकाओं और मेजबानों के बारे में जानकारी मुद्रित करने के लिए हमारे पास विशेष कपड़े कार्य हैं।
हम रिवर्स मैपिंग होस्ट स्ट्रिंग्स पर रोल नामों पर भी बहुत अधिक भरोसा करते हैं (होस्ट स्ट्रिंग्स प्रति service_name अद्वितीय हैं)। इसका उपयोग परिनियोजन लॉगिंग और सूचनाओं के लिए किया जाता है। मूल रूप से, हम प्रत्येक होस्ट के लिए सेवा परिनियोजन लॉग करते हैं और एक भूमिका में सभी होस्टों के लिए सेवा तैनात किए जाने पर स्लैक सूचना भेजते हैं। EnvironmentDatabaseAPI सर्वर इसके लिए जिम्मेदार है (यह लॉग और परिनियोजन स्थिति रखता है)। यह एक डेकोरेटर के साथ कपड़े के कार्यों को सजाने के द्वारा किया जाता है जो env.host , env.port और env.service_name (साथ ही प्रतिबद्ध जानकारी) को वापस एपीआई सर्वर पर सबमिट करता है।
हम भविष्य में परिनियोजन प्रमाणीकरण जोड़ने की योजना बना रहे हैं, साथ ही सर्वर से अधिक env चर खींचने की संभावना है ताकि उन्हें कार्य संदर्भ में उपलब्ध कराया जा सके।

max-arnold 24 अप्रैल 2017

👍1

धन्यवाद @ मैक्स-अर्नोल्ड! मैं उनमें से कई को अतीत में अपने स्वयं के उपयोग के मामलों से भी पहचानता हूं। विशेष रूप से रिवर्स मैपिंग बिट मुझे याद है कि कुछ बार v1 में आ रहा है, इसलिए मैंने इसे सूची में जोड़ा।

bitprophet 24 अप्रैल 2017

मेरे लिए फ़ैब्रिक v2 के लिए उपयोगी बनने के लिए, मुझे fab यह बताने के लिए एक तरीके की आवश्यकता होगी कि किसी कार्य को निष्पादित करने के लिए मेजबानों का कौन सा सेट है।

पहले मैंने भूमिकाओं को परिभाषित किया और फिर fab -R ... चलाया। (वास्तव में भूमिकाओं को आईपी एड्रेस रेंज का उपयोग करके प्रोग्रामेटिक रूप से परिभाषित किया गया था, लेकिन इसकी कोई आवश्यकता नहीं है और वाईएएमएल फ़ाइल के अंदर एक स्थिर सूची ठीक होगी।)

मैं फैब्रिक v2 में एक समकक्ष खोजने में विफल रहा, और मैं इस सुविधा का उपयोग करके अनुकरण करने में भी विफल रहा:

एक fabric.yaml कॉन्फ़िगरेशन फ़ाइल युक्त

active_hostset: null
hostsets:
  myhostset:
  - ...

active_hostset = config["hostsets"][config["active_hostset"]] में fabfile.py
env INVOKE_ACTIVE_HOSTSET=myhostset fab ...

मेजबानों की अपेक्षित सूची के बजाय मुझे KeyError: 'active_hostset' ।

ghost 18 सित॰ 2018

हम फैब्रिक v1 में अपने प्रत्येक वातावरण के लिए प्रत्येक भूमिका के लिए मेजबानों के विभिन्न सेटों को मैप करते हैं, और पर्यावरण को निर्दिष्ट करने के लिए role.environment:staging कार्य चलाकर सेट किया जाता है। तो यह कार्य निम्नलिखित कार्यों द्वारा उपयोग किए जाने वाले मेजबानों को प्रभावित करता है।

V2 में हमने एक कस्टम टास्क का उपयोग करने की कोशिश की, लेकिन समस्या यह है कि Executor.expand_calls हमारे role.environment कार्य के चलने से पहले चलता है और इसलिए निम्न में से कोई भी कार्य गतिशील रूप से अपनी मेजबान सूची बनाने के लिए पर्यावरण को नहीं जानता है।

rectalogic 16 जन॰ 2019

👍1

Executor.expand_calls एक जनरेटर बनाना कार्य निष्पादन को बाद के कार्यों के निष्पादन को प्रभावित करने की अनुमति देता है। तो ऊपर मेरा उदाहरण काम करता है, जहां हमारे पास एक कस्टम Task जिसे मेजबानों को भूमिकाओं को ठीक से विस्तारित करने के लिए इसके पर्यावरण को जानने की जरूरत है। उदाहरण के लिए fab role.environment dev deploy.app - role.environment कार्य अब deploy.app के विस्तार से पहले चलाया जाता है, और इसलिए deploy.app पर्यावरण को जानता है और इसके मेजबानों को कॉन्फ़िगर कर सकता है और फिर इसमें विस्तार किया जाता है कार्यों का सही सेट।

मैंने इसे अपने कांटे में प्रोटोटाइप किया:
https://github.com/pyinvoke/invoke/compare/master...rectalogic :expand-generator
https://github.com/fabric/fabric/compare/master...rectalogic :expand-generator

rectalogic 17 जन॰ 2019

👍1

ibigbug 9 जन॰ 2020

👍4

हम विभिन्न परिवेशों में संचालन के एक ही सेट का प्रतिनिधित्व करने के लिए भूमिकाओं का भी उपयोग करते हैं। शायद नामित भूमिका और नामित पर्यावरण की अवधारणा को अलग करना उपयोगी होगा? के रूप में, देव वातावरण में वेब भूमिका।

adevore 17 दिस॰ 2020

क्या यह पृष्ठ उपयोगी था?

0 / 5 - 0 रेटिंग्स