xenvman: लचीले माइक्रोसिस्ट सेवा परीक्षण वातावरण (और अधिक)

सभी को नमस्कार!

मैं उस परियोजना के बारे में थोड़ी बात करना चाहूंगा जिसे मैं पिछले छह महीनों से काम कर रहा हूं। मैं अपने खाली समय में प्रोजेक्ट करता हूं, लेकिन इसके निर्माण की प्रेरणा मुख्य कार्य में किए गए टिप्पणियों से मिली।

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

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

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

मुख्य बात यह है कि xenvman क्या कर सकता है:

• सरल जावास्क्रिप्ट स्क्रिप्ट के साथ पर्यावरण सामग्री का लचीले ढंग से वर्णन करें
• मक्खी पर चित्र बनाएँ
• कंटेनरों की सही संख्या बनाएं और उन्हें एक पृथक नेटवर्क में संयोजित करें
• बाहर के पर्यावरण के आंतरिक बंदरगाहों को आगे बढ़ाएं, ताकि परीक्षण अन्य मेजबानों से भी आवश्यक सेवाओं तक पहुंच सकें
• काम के माहौल को रोकने के बिना, पर्यावरण की संरचना को गतिशील रूप से बदलें (बंद करो, शुरू करो और नए कंटेनर जोड़ें)।

प्रतिवेश

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

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

टेम्पलेट्स

पर्यावरण का हिस्सा सीधे तौर पर टेम्प्लेट द्वारा निर्धारित किया जाता है, जो जेएस में छोटी स्क्रिप्ट हैं। xenvman में इस भाषा का एक अंतर्निर्मित दुभाषिया है, और जब इसे एक नया वातावरण बनाने के लिए अनुरोध प्राप्त होता है, तो यह केवल निर्दिष्ट टेम्पलेट्स को निष्पादित करता है, जिनमें से प्रत्येक निष्पादन के लिए सूची में एक या एक से अधिक कंटेनर जोड़ता है।

जावास्क्रिप्ट को सर्वर के पुनर्निर्माण के बिना गतिशील रूप से बदलने / जोड़ने की अनुमति देने के लिए चुना गया था। इसके अलावा, आमतौर पर टेम्प्लेट केवल भाषा की मूल विशेषताओं और डेटा प्रकारों (अच्छे पुराने ES5, कोई DOM, प्रतिक्रिया और अन्य जादू) का उपयोग नहीं करते हैं, इसलिए टेम्प्लेट के साथ काम करना उन लोगों के लिए भी विशेष कठिनाइयों का कारण नहीं होना चाहिए जो JS को बिल्कुल जानते हैं।

टेम्प्लेट पैरामीटर योग्य हैं, अर्थात हम अपने HTTP अनुरोध में कुछ मापदंडों को पास करके टेम्प्लेट के तर्क को पूरी तरह से नियंत्रित कर सकते हैं।

मक्खी पर चित्र बनाएँ

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

और अगर हम सक्रिय रूप से अपनी सेवा में नई सुविधाओं को देख रहे हैं, या यह समझने की कोशिश कर रहे हैं कि यह क्यों काम नहीं करता है, तो अच्छे पुराने fmt.Printf को आगे या पीछे कोड बदलना, या किसी भी तरह कोड को बदलना, यहां तक ​​कि 5 मिनट की देरी प्रदर्शन को बुझाने के लिए बहुत अच्छा होगा ( कोड लेखकों के रूप में हमारा)। इसके बजाय, हम कोड में सभी आवश्यक डिबगिंग जोड़ सकते हैं, इसे स्थानीय रूप से संकलित कर सकते हैं, और फिर समाप्त बिनार को HTTP अनुरोध में संलग्न कर सकते हैं।

इस तरह की स्वीकृति प्राप्त करने के बाद, टेम्पलेट इस बिनार को ले जाएगा और चलते-फिरते एक अस्थायी छवि बनाएगा, जिसमें से हम पहले से ही कंटेनर लॉन्च कर सकते हैं जैसे कि कुछ भी नहीं हुआ था।

हमारी परियोजना पर, सेवाओं के लिए मुख्य टेम्पलेट में, उदाहरण के लिए, हम जांचते हैं कि क्या बिनार मापदंडों में मौजूद है, और यदि ऐसा है, तो हम छवि को चलते हैं, अन्यथा हम dev शाखा के latest संस्करण को डाउनलोड करते हैं। कंटेनर बनाने के लिए आगे का कोड दोनों विकल्पों के लिए समान है।

एक छोटा सा उदाहरण

स्पष्टता के लिए, आइए माइक्रो-उदाहरण देखें।

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

तो हम Mongo चलाने और हमारे wut सर्वर के साथ एक वातावरण बनाने के लिए xenvman का उपयोग करने का प्रयास करेंगे।

सबसे पहले, हमें एक आधार निर्देशिका बनाने की जरूरत है जिसमें सभी टेम्पलेट संग्रहीत किए जाएंगे:

$ mkdir xenv-templates && cd xenv-templates

अगला, दो टेम्प्लेट बनाएं, एक मानगो के लिए, दूसरा हमारे सर्वर के लिए:

$ touch mongo.tpl.js wut.tpl.js

mongo.tpl.js

mongo.tpl.js खोलें और वहां निम्नलिखित लिखें:

 function execute(tpl, params) { var img = tpl.FetchImage(fmt("mongo:%s", params.tag)); var cont = img.NewContainer("mongo"); cont.SetLabel("mongo", "true"); cont.SetPorts(27017); cont.AddReadinessCheck("net", { "protocol": "tcp", "address": '{{.ExternalAddress}}:{{.Self.ExposedPort 27017}}' }); } 

टेम्पलेट में दो मापदंडों के साथ एक निष्पादन () फ़ंक्शन होना चाहिए।
पहला tpl ऑब्जेक्ट का एक उदाहरण है जिसके माध्यम से पर्यावरण कॉन्फ़िगर किया गया है। दूसरा तर्क (परम) सिर्फ एक JSON ऑब्जेक्ट है जिसके साथ हम अपने टेम्पलेट को पैरामीटर करेंगे।

लाइन में

 var img = tpl.FetchImage(fmt("mongo:%s", params.tag)); 

हम xenvman को docker mongo छवि डाउनलोड करने के लिए कहते हैं mongo:<tag> , जहां <tag> उस छवि का संस्करण है जिसका हम उपयोग करना चाहते हैं। सिद्धांत रूप में, यह रेखा docker pull mongo:<tag> बराबर है, एकमात्र अंतर यह है कि tpl ऑब्जेक्ट के सभी कार्य अनिवार्य रूप से घोषणात्मक हैं, अर्थात, छवि को वास्तव में केवल डाउनलोड किया जाएगा जब xenvman पर्यावरण कॉन्फ़िगरेशन में निर्दिष्ट सभी टेम्पलेट्स को निष्पादित करेगा।

हमारे पास छवि होने के बाद, हम एक कंटेनर बना सकते हैं:

 var cont = img.NewContainer("mongo"); 

फिर से, कंटेनर को तुरंत इस स्थान पर नहीं बनाया जाएगा, हम बस इसे बनाने के इरादे की घोषणा करते हैं, इसलिए बोलने के लिए।

अगला, हमने अपने कंटेनर पर एक लेबल लगाया:

 cont.SetLabel("mongo", "true"); 

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

अब हमें आंतरिक Mongo पोर्ट (27017) को हैंग करने की आवश्यकता है। यह आसानी से इस तरह किया जाता है:

  cont.SetPorts(27017); 

ज़ेनवमैन पर्यावरण के सफल निर्माण पर रिपोर्ट करने से पहले, यह सुनिश्चित करना बहुत अच्छा होगा कि सभी सेवाएँ न केवल चल रही हैं, बल्कि अनुरोधों को स्वीकार करने के लिए तैयार हैं। Xenvman ने इसके लिए तत्परता जाँच की है।
हमारे आम कंटेनर के लिए ऐसा जोड़ें:

  cont.AddReadinessCheck("net", { "protocol": "tcp", "address": '{{.ExternalAddress}}:{{.Self.ExposedPort 27017}}' }); 

जैसा कि हम देख सकते हैं, यहां पता बार में स्टब्स हैं जिनमें आवश्यक मूल्यों को कंटेनरों के लॉन्च से ठीक पहले गतिशील रूप से प्रतिस्थापित किया जाएगा।

इसके बजाय {{.ExternalAddress}} होस्ट चलाने वाले xenvman {{.ExternalAddress}} बाहरी पते को प्रतिस्थापित किया जाएगा, और {{.Self.ExposedPort 27017}} बजाय {{.Self.ExposedPort 27017}} आंतरिक 27017 को अग्रेषित किया गया बाहरी पोर्ट प्रतिस्थापित किया जाएगा।

यहाँ प्रक्षेप के बारे में और पढ़ें।

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

wut.tpl.js

तो, ग, मोंगा के साथ निपटा, हम अपने wut सर्वर के लिए एक और टेम्पलेट लिखेंगे।
चूँकि हम चलते-चलते छवि एकत्र करना चाहते हैं, इसलिए टेम्प्लेट थोड़ा अलग होगा:

 function execute(tpl, params) { var img = tpl.BuildImage("wut-image"); img.CopyDataToWorkspace("Dockerfile"); // Extract server binary var bin = type.FromBase64("binary", params.binary); img.AddFileToWorkspace("wut", bin, 0755); // Create container var cont = img.NewContainer("wut"); cont.MountData("config.toml", "/config.toml", {"interpolate": true}); cont.SetPorts(params.port); cont.AddReadinessCheck("http", { "url": fmt('http://{{.ExternalAddress}}:{{.Self.ExposedPort %v}}/', params.port), "codes": [200] }); } 

चूँकि हम यहाँ चित्र का BuildImage() कर रहे हैं, इसलिए हम BuildImage() बजाय FetchImage() :

  var img = tpl.BuildImage("wut-image"); 

छवि को इकट्ठा करने के लिए, हमें कई फ़ाइलों की आवश्यकता होगी:
Dockerfile - वास्तव में कैसे एक छवि को इकट्ठा करने के लिए निर्देश
config.toml - हमारे wut सर्वर के लिए विन्यास फाइल

img.CopyDataToWorkspace("Dockerfile"); विधि का उपयोग करना img.CopyDataToWorkspace("Dockerfile"); हम अस्थायी डेटा निर्देशिका से टेम्पलेट डेटा निर्देशिका से डॉकरफ़ाइल की प्रतिलिपि बनाते हैं।

डेटा निर्देशिका एक निर्देशिका है जिसमें हम अपने टेम्पलेट के लिए आवश्यक सभी फाइलों को काम करने के लिए स्टोर कर सकते हैं।

अस्थायी कार्य निर्देशिका में, हम उन फ़ाइलों की प्रतिलिपि बनाते हैं (जो img.CopyDataToWorkspace () का उपयोग करके) छवि में मिलती हैं।

निम्न प्रकार हैं:

  // Extract server binary var bin = type.FromBase64("binary", params.binary); img.AddFileToWorkspace("wut", bin, 0755); 

हम अपने सर्वर के बिनर को सीधे मापदंडों में, एन्कोडेड (बेस 64) फॉर्म में पास करते हैं। और टेम्प्लेट में, हम बस इसे डिकोड करते हैं, और परिणामी स्ट्रिंग को wut नाम के तहत फाइल के रूप में कार्यशील डायरेक्टरी में सेव करते हैं।

फिर एक कंटेनर बनाएं और उसमें कॉन्फ़िगरेशन फ़ाइल माउंट करें:

  var cont = img.NewContainer("wut"); cont.MountData("config.toml", "/config.toml", {"interpolate": true}); 

MountData() लिए एक कॉल का अर्थ है कि डेटा निर्देशिका से config.toml फ़ाइल को कंटेनर के अंदर /config.toml नाम से /config.toml । interpolate फ्लैग xenvman को सर्वर से कहता है कि फ़ाइल में बढ़ते से पहले वहां मौजूद सभी स्टब्स को बदल दिया जाए।

यहाँ विन्यास कैसा दिखता है:

 {{with .ContainerWithLabel "mongo" "" -}} mongo = "{{.Hostname}}/wut" {{- end}} 

यहाँ हम mongo लेबल वाले कंटेनर की तलाश करते हैं, और इसके पर्यावरण में जो भी हो, इसके होस्ट नाम को प्रतिस्थापित करते हैं।

प्रतिस्थापन के बाद, फ़ाइल इस तरह दिख सकती है:

 mongo = “mongo.0.mongo.xenv/wut” 

अगला, हम फिर से पोर्ट पोस्ट करते हैं और एक तत्परता जांच शुरू करते हैं, इस बार HTTP:

 cont.SetPorts(params.port); cont.AddReadinessCheck("http", { "url": fmt('http://{{.ExternalAddress}}:{{.Self.ExposedPort %v}}/', params.port), "codes": [200] }); 

हमारे टेम्प्लेट इसके लिए तैयार हैं, और हम उन्हें एकीकरण परीक्षण कोड में उपयोग कर सकते हैं:

 import "github.com/syhpoon/xenvman/pkg/client" import "github.com/syhpoon/xenvman/pkg/def" //  xenvman  cl := client.New(client.Params{}) //      env := cl.MustCreateEnv(&def.InputEnv{ Name: "wut-test", Description: "Testing Wut", // ,      Templates: []*def.Tpl{ { Tpl: "wut", Parameters: def.TplParams{ "binary": client.FileToBase64("wut"), "port": 5555, }, }, { Tpl: "mongo", Parameters: def.TplParams{"tag": “latest”}, }, }, }) //      defer env.Terminate() //     wut  wutCont, err := env.GetContainer("wut", 0, "wut") require.Nil(t, err) //      mongoCont, err := env.GetContainer("mongo", 0, "mongo") require.Nil(t, err) //    wutUrl := fmt.Sprintf("http://%s:%d/v1/wut/", env.ExternalAddress, wutCont.Ports[“5555”]) mongoUrl := fmt.Sprintf("%s:%d/wut", env.ExternalAddress, mongoCont.Ports["27017"]) // !      ,            ,   

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

इस छोटे से उदाहरण में, ज़ेनमैन की सभी विशेषताओं से दूर दिखाया गया है, एक अधिक विस्तृत चरण-दर-चरण मार्गदर्शिका यहां उपलब्ध है।

ग्राहकों

वर्तमान में दो भाषाओं के ग्राहक हैं:

जाओ
अजगर

लेकिन नए जोड़ना मुश्किल नहीं है, क्योंकि प्रदान की गई एपीआई बहुत सरल है।

वेब इंटरफ़ेस

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

Xenvman डॉकटर-कंपोज़ से कैसे अलग है?

बेशक, बहुत सारी समानताएं हैं, लेकिन फ़ाइल में स्टेटिक कॉन्फ़िगरेशन की तुलना में, ज़ेनवमैन मुझे थोड़ा अधिक लचीला और गतिशील दृष्टिकोण लगता है।
यहाँ मेरी राय में, मुख्य विशिष्ट विशेषताएं हैं:

• HTTP API के माध्यम से पूरी तरह से नियंत्रण किया जाता है, इसलिए हम HTTP को समझने वाली किसी भी भाषा के कोड से वातावरण बना सकते हैं
• चूँकि xenvman को एक अलग होस्ट पर चलाया जा सकता है, हम इसकी सभी विशेषताओं का उपयोग एक होस्ट से भी कर सकते हैं, जिस पर docker स्थापित नहीं है।
• मक्खी पर गतिशील रूप से चित्र बनाने की क्षमता
• अपने संचालन के दौरान पर्यावरण की संरचना (कंटेनरों को जोड़ना / रोकना) को बदलने की क्षमता
• बॉयलरप्लेट कोड, बेहतर रचना और पैरामीटर कोडिंग टेम्प्लेट के उपयोग के माध्यम से कॉन्फ़िगरेशन कोड का पुन: उपयोग करने की क्षमता में कमी

संदर्भ

गिथब प्रोजेक्ट पेज
विस्तृत चरण-दर-चरण उदाहरण, अंग्रेजी में।

निष्कर्ष

बस इतना ही। निकट भविष्य में मैं अवसर जोड़ने की योजना बना रहा हूं
टेम्प्लेट से कॉल करें और इस तरह आप उन्हें अधिक दक्षता के साथ जोड़ सकते हैं।

मैं किसी भी प्रश्न का उत्तर देने की कोशिश करूंगा, और मुझे खुशी होगी अगर कोई और इस परियोजना को उपयोगी पाता है।