आईये शुरूआत से आरंभ करते हैं। मेरे पिछले ग्राहकों में से एक में एडब्ल्यूएस क्लाउड इंजीनियर के रूप में मेरी भूमिका में, एक इवेंट-संचालित आर्किटेक्चर का उपयोग किया गया था जहां तीसरे पक्ष ने लगातार इवेंटब्रिज के माध्यम से हमारे एडब्ल्यूएस वातावरण में कई इवेंट भेजे थे। प्रत्येक तीसरे पक्ष के लिए, हमने विभिन्न इवेंटब्रिज नियमों के साथ एक इवेंट बस प्रदान की।
यहां चुनौती कार्यक्रम की संरचना पर नज़र रखने की थी - यह कैसे आयोजित किया गया था। घटनाओं को बार-बार अद्यतन किया गया, जिससे चीजों को स्पष्ट करने के लिए कई बैठकें हुईं।
2019 के अंत में, इवेंटब्रिज स्कीमा डिस्कवरी की बदौलत हमारी समस्या का एक बड़ा हिस्सा हल हो गया। इवेंट बसों पर इसे सक्षम करने से, प्राप्त इवेंट के आधार पर स्कीमा स्वचालित रूप से उत्पन्न होते थे। इससे हमें इन स्कीमाओं से कोड बाइंडिंग उत्पन्न करने की अनुमति मिली, जो हमारे ऑब्जेक्ट-ओरिएंटेड वातावरण में एक बड़ी मदद थी।
नीचे आप किसी तीसरे पक्ष की एक बहुत ही बुनियादी उदाहरण घटना देख सकते हैं।
{ "version": "0", "id": "ef21d5fc-a5ba-e2c6-fc4b-a8807455c64d", "detail-type": "orderType", "source": "com.company.A", "account": "xxx", "time": "2024-08-22T08:04:26Z", "region": "eu-west-1", "resources": [], "detail": { "orderId": 123456789, "customer": { "customerId": "C001", "name": "John Doe" }, "orderDate": "2024-08-22" } }
AWS ने इस प्रकार के आयोजनों के लिए एक स्कीमा खोजा:
विजुअल स्टूडियो कोड के लिए AWS टूलकिट का उपयोग करके, हम आसानी से अपने इवेंट को अपने कोड में दृढ़ता से टाइप की गई वस्तुओं के रूप में प्रस्तुत कर सकते हैं।
नीचे एक बहुत ही बुनियादी उदाहरण दिया गया है कि हमने कोड बाइंडिंग का उपयोग कैसे किया।
आउटपुट:
123456789 C001
इससे हमारे काम करने के तरीके में सुधार हुआ, लेकिन फिर भी हमें एक समस्या का सामना करना पड़ा। समय-समय पर, तृतीय पक्ष अपने आयोजनों में नई विशेषताएँ जोड़ेंगे। इवेंटब्रिज इन परिवर्तनों की खोज करेगा, लेकिन डेवलपर्स अक्सर नई स्कीमा के लिए कोड बाइंडिंग को अपडेट करना भूल जाते हैं। यद्यपि हमारा कार्यान्वयन नई विशेषताओं को जोड़ने पर टूटने से रोकने के लिए पर्याप्त मजबूत था, लेकिन इसके परिणामस्वरूप नया डेटा प्राप्त हुआ जिसका हम उपयोग नहीं कर रहे थे। हमें समय-समय पर अपने कोड बाइंडिंग को अपडेट करने के लिए डेवलपर्स पर निर्भर रहना पड़ता था, और इसे प्रबंधित करने के लिए कोई स्पष्ट प्रक्रिया नहीं थी।
कभी-कभी एक कोड बाइंडिंग को महीनों तक अपडेट नहीं किया जाता था, और कभी-कभी, दो डेवलपर इसे एक साथ अपडेट करते थे, जिससे टकराव या डुप्लिकेट कार्य होता था।
इसे बेहतर ढंग से संभालने के लिए, हमने एक ऐसा समाधान बनाने का निर्णय लिया जो जब भी कोई तीसरा पक्ष अपने ईवेंट को अपडेट करता है और एक नया स्कीमा खोजा जाता है तो स्वचालित रूप से जीरा टिकट बनाता है।
समाधान मेरे GitHub पर CloudFormation में उपलब्ध है। README की जाँच करें।
पहला कदम हमारी डिफ़ॉल्ट बस पर एक इवेंटब्रिज नियम बनाना था जो कि जब भी कोई नया स्कीमा या स्कीमा संस्करण अपडेट खोजा जाता था तो ट्रिगर हो जाता था। इस इवेंट को इवेंटब्रिज पाइप के लिए इनपुट के रूप में काम करने के लिए एक एसक्यूएस कतार में भेजा गया था। यहां, हम अतिरिक्त फ़िल्टरिंग (इस उदाहरण में वैकल्पिक) जोड़ सकते हैं और लैम्ब्डा फ़ंक्शन का उपयोग करके अपने ईवेंट को समृद्ध कर सकते हैं।
संवर्द्धन के लिए, हमने boto3 का उपयोग करके डिस्क्रिप्शन_स्कीमा का उपयोग किया।
data = event[0]["input"]["detail"] try: response = client.describe_schema( RegistryName=data["RegistryName"], SchemaName=data["SchemaName"], SchemaVersion=data["Version"], ) except ClientError as e: raise e return_data = { "SchemaName": response["SchemaName"], "SchemaVersion": response["SchemaVersion"], "SchemaArn": response["SchemaArn"], "Content": json.loads(response["Content"]), }
अपने डेटा को समृद्ध करने के बाद, हमने इसे स्टेप फ़ंक्शन वर्कफ़्लो में भेजा। बदले में, इस वर्कफ़्लो ने AWS-प्रदत्त AWS-CreateJiraIssue SSM ऑटोमेशन को ट्रिगर किया, जिसने स्वचालित रूप से एक जीरा टिकट बनाया।
टिकट में स्कीमा नाम, नया स्कीमा संस्करण और स्कीमा का एआरएन जैसे विवरण शामिल थे। (आवश्यकता पड़ने पर इवेंट से अतिरिक्त सामग्री भी जोड़ी जा सकती है।)
---------------- -------- ------------------------- ---------------- ------------------------- | EventBridge | ---> | SQS | ---> | EventBridge Pipe | ---> | Step Function | ---> | SSM Automation Document | | Rule | | | | (Filtering & Enrichment)| | | | | ---------------- -------- ------------------------- ---------------- -------------------------
आइए इस समाधान का प्रदर्शन करें। यहां आप मूल के आधार पर एक अद्यतन घटना देखते हैं। विशेषता स्थिति नई है.
{ "version": "0", "id": "dffbd38b-9258-d028-21f3-da0ba3c9e314", "detail-type": "orderType", "source": "com.company.A", "account": "xxx", "time": "2024-08-22T08:04:26Z", "region": "eu-west-1", "resources": [], "detail": { "orderId": 123456789, "status": "Completed", "customer": { "customerId": "C001", "name": "John Doe" }, "orderDate": "2024-08-22" } }
एक नई स्कीम की खोज की जाएगी। इससे संपूर्ण समाधान प्रारंभ हो जाएगा. लैम्ब्डा द्वारा हमारे ईवेंट को समृद्ध करने के बाद, उस अद्यतन ईवेंट का उपयोग हमारे स्टेप फ़ंक्शन के लिए इनपुट के रूप में किया जाएगा।
हमारे स्टेप फ़ंक्शन का इनपुट इवेंट समृद्ध है और इस तरह दिखता है।
[ { "statusCode": 200, "data": { "SchemaName": "com.company.A@OrderType", "SchemaVersion": "2", "SchemaArn": "arn:aws:schemas:eu-west-1:xxx:schema/discovered-schemas/com.company.A@OrderType", "Content": { "openapi": "3.0.0", "info": { "version": "1.0.0", "title": "OrderType" }, "paths": {}, "components": { "schemas": { "AWSEvent": { "type": "object", "required": [ "detail-type", "resources", "detail", "id", "source", "time", "region", "version", "account" ], "x-amazon-events-detail-type": "orderType", "x-amazon-events-source": "com.company.A", "properties": { "detail": { "$ref": "#/components/schemas/OrderType" }, "account": { "type": "string" }, "detail-type": { "type": "string" }, "id": { "type": "string" }, "region": { "type": "string" }, "resources": { "type": "array", "items": { "type": "object" } }, "source": { "type": "string" }, "time": { "type": "string", "format": "date-time" }, "version": { "type": "string" } } }, "OrderType": { "type": "object", "required": [ "orderId", "orderDate", "customer", "status" ], "properties": { "customer": { "$ref": "#/components/schemas/Customer" }, "orderDate": { "type": "string", "format": "date" }, "orderId": { "type": "number" }, "status": { "type": "string" } } }, "Customer": { "type": "object", "required": [ "customerId", "name" ], "properties": { "customerId": { "type": "string" }, "name": { "type": "string" } } } } } } } } ]
स्टेप फंक्शन वर्कफ़्लो, बदले में, एसएसएम ऑटोमेशन को ट्रिगर करेगा और एक जीरा टिकट बनाएगा।
सुविधा के लिए, मैंने टिकट सामग्री को संक्षिप्त रखा है। हालाँकि, चूंकि सामग्री को स्टेप फ़ंक्शन में इनपुट के रूप में भी भेजा जाता है, इसलिए इसे टिकट में भी शामिल किया जा सकता है। इस तरह, आप सीधे अपने टिकट में स्कीमा में नई विशेषताओं या परिवर्तनों का उल्लेख कर सकते हैं।
यह समाधान तब भी ट्रिगर किया जाएगा जब एक पूरी तरह से नया ईवेंट खोजा जाएगा, क्योंकि यह नए ईवेंट का संस्करण 1 बनाएगा, जिससे इवेंटब्रिज नियम सक्रिय हो जाएगा।
इस तरह, हमें अपडेट के बारे में सूचित किया गया और हम उन्हें अपने स्प्रिंट में शेड्यूल कर सकते हैं। इससे हमारे विकास चक्र में तेजी आती है।
मुझे पता है कि यह काफी विशिष्ट मामला है, लेकिन वांछित घटनाओं को ट्रिगर करने के लिए इवेंटब्रिज नियम स्थापित करके और फिर आगे ऑटोमेशन बनाने के लिए एसएसएम के साथ संयोजन में संवर्धन और चरण कार्यों का उपयोग करके समान समाधान बनाए जा सकते हैं।
अस्वीकरण: उपलब्ध कराए गए सभी संसाधन आंशिक रूप से इंटरनेट से हैं। यदि आपके कॉपीराइट या अन्य अधिकारों और हितों का कोई उल्लंघन होता है, तो कृपया विस्तृत कारण बताएं और कॉपीराइट या अधिकारों और हितों का प्रमाण प्रदान करें और फिर इसे ईमेल पर भेजें: [email protected] हम इसे आपके लिए यथाशीघ्र संभालेंगे।
Copyright© 2022 湘ICP备2022001581号-3