👇🏿 😖 🤾🏾 टारेंटूल कुबेरनेट्स ऑपरेटर 🧞 👨🏾‍🤝‍👨🏻 👩🏽‍🔬

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

हम आपके लिए प्रस्तुत करते हैं स्टेटसेंट क्लस्टर बनाने के लिए हमारा समाधान टारनटूल कार्ट्रिज : टारेंटूल कुबेरनेट्स ऑपरेटर , विवरण के लिए मैं बिल्ली के नीचे पूछता हूं।

सामग्री की तालिका:

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

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

टारेंटूल न केवल तकनीक है, बल्कि इंजीनियरों की एक टीम भी है जो टर्नकी एंटरप्राइज सिस्टम, बॉक्स समाधान और ओपनसोर्स घटकों के लिए समर्थन के विकास में लगे हुए हैं।

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

इन सभी प्रणालियों में एक चीज समान है: इन्हें संचालित करना काफी कठिन है। 3 डेटा केंद्रों के लिए अतिरेक के साथ 100+ इंस्टेंस का त्वरित रूप से रोल आउट करें, एक ऐसे एप्लिकेशन को अपडेट करें जो डाउनटाइम और मेंटेनेंस ड्रॉडाउन के बिना डेटा स्टोर करता है, तबाही या मानव निर्मित त्रुटियों के मामले में बैकअप रिस्टोर करता है, घटकों के विवेकपूर्ण बदलाव को सुनिश्चित करता है, कॉन्फ़िगरेशन प्रबंधन को व्यवस्थित करता है ... सामान्य तौर पर, बहुत कुछ है। दिलचस्प।

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

एक हजार शब्दों के बजाय

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

जहां:

राउटर - क्लस्टर का हिस्सा जो आने वाले HTTP अनुरोधों को स्वीकार करने और संसाधित करने के लिए जिम्मेदार है;
स्टोरेज उस क्लस्टर का हिस्सा है जो डेटा और भंडारण की प्रक्रिया के लिए जिम्मेदार है, प्रत्येक मास्टर और प्रतिकृति में बॉक्स से 3 शर्ड्स बढ़ते हैं।

रूटर्स पर आने वाले HTTP ट्रैफ़िक को संतुलित करने के लिए, कुबेरनेटियन इनग्रेड का उपयोग किया जाता है। डेटा को टारेंटूल के स्तर पर भंडारण में वितरित किया जाता है, जिसका उपयोग vshard घटक का उपयोग करके किया जाता है ।

हमें 1.14+ kubernetes की आवश्यकता है, मिनीक्यूब काम करेगा। इसके अलावा कुबेटेल की उपलब्धता को नुकसान नहीं होगा। ऑपरेटर शुरू करने के लिए, आपको इसके लिए एक ServiceAccount, भूमिका और भूमिका-निर्माण बनाने की आवश्यकता है:

$ kubectl create -f https://raw.githubusercontent.com/tarantool/tarantool-operator/0.0.1/deploy/service_account.yaml $ kubectl create -f https://raw.githubusercontent.com/tarantool/tarantool-operator/0.0.1/deploy/role.yaml $ kubectl create -f https://raw.githubusercontent.com/tarantool/tarantool-operator/0.0.1/deploy/role_binding.yaml

टारेंटूल ऑपरेटर अपनी संसाधन परिभाषाओं के साथ कुबेरनेट्स एपीआई का विस्तार करता है, हम उन्हें बनाएंगे:

 $ kubectl create -f https://raw.githubusercontent.com/tarantool/tarantool-operator/0.0.1/deploy/crds/tarantool_v1alpha1_cluster_crd.yaml $ kubectl create -f https://raw.githubusercontent.com/tarantool/tarantool-operator/0.0.1/deploy/crds/tarantool_v1alpha1_role_crd.yaml $ kubectl create -f https://raw.githubusercontent.com/tarantool/tarantool-operator/0.0.1/deploy/crds/tarantool_v1alpha1_replicasettemplate_crd.yaml

ऑपरेटर को लॉन्च करने के लिए सब कुछ तैयार है, आइए जाने:

 $ kubectl create -f https://raw.githubusercontent.com/tarantool/tarantool-operator/0.0.1/deploy/operator.yaml

हम ऑपरेटर के शुरू होने की प्रतीक्षा कर रहे हैं, और हम एप्लिकेशन लॉन्च करने के लिए आगे बढ़ सकते हैं:

 $ kubectl create -f https://raw.githubusercontent.com/tarantool/tarantool-operator/0.0.1/examples/kv/deployment.yaml

उदाहरण के साथ yaml फ़ाइल में, वेब UI पर Ingress घोषित किया गया है; यह cluster_ip/admin/cluster पर उपलब्ध है। जब इनग्रेड से कम से कम एक पोड ऊपर होता है, तो आप वहां जा सकते हैं और देख सकते हैं कि क्लस्टर में नए उदाहरण कैसे जोड़े जाते हैं और इसकी टोपोलॉजी कैसे बदलती है।

हम क्लस्टर के उपयोग की प्रतीक्षा कर रहे हैं:

 $ kubectl describe clusters.tarantool.io examples-kv-cluster

हम उम्मीद करते हैं कि क्लस्टर की स्थिति में निम्नलिखित होंगे:

 … Status: State: Ready …

सब कुछ, आवेदन का उपयोग करने के लिए तैयार है!

अधिक संग्रहण स्थान चाहिए? शार्क जोड़ें:

 $ kubectl scale roles.tarantool.io storage --replicas=3

शेयर लोड का सामना नहीं कर सकते? प्रतिकृति टेम्पलेट संपादित करके शार्क में उदाहरणों की संख्या बढ़ाएँ:

 $ kubectl edit replicasettemplates.tarantool.io storage-template

उदाहरण के लिए .spec.replicas सेट करें, उदाहरण के लिए, प्रत्येक प्रतिकृतियों में उदाहरणों की संख्या को दो तक बढ़ाने के लिए।

एक क्लस्टर की अब आवश्यकता नहीं है? हम सभी संसाधनों के साथ इसे हटाते हैं:

 $ kubectl delete clusters.tarantool.io examples-kv-cluster

क्या कुछ गलत हुआ? टिकट स्कोर करें , हम जल्दी से जुदा हो जाएंगे। :)

ऑपरेटर आखिर करता क्या है

टारनटूल कार्ट्रिज क्लस्टर का लॉन्च और संचालन एक निश्चित समय में, एक विशिष्ट क्रम में, कुछ कार्यों को करने की कहानी है।

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

हम टारेंटूल उदाहरणों की आवश्यक संख्या बढ़ाते हैं, उदाहरण के लिए, सिस्टमड के तहत।

सदस्यता में मर्ज करें:

 mutation { probe_instance: probe_server(uri: "storage:3301") }

उदाहरणों के लिए भूमिकाएँ सौंपे, उदाहरण और प्रतिकृतियों की पहचान करें। इसके लिए ग्राफकॉल एपीआई का भी उपयोग किया जाता है:
```
 mutation { join_server( uri:"storage:3301", instance_uuid: "cccccccc-cccc-4000-b000-000000000001", replicaset_uuid: "cccccccc-0000-4000-b000-000000000000", roles: ["storage"], timeout: 5 ) } 
```
हम तेज करने के लिए जिम्मेदार घटक का बूटस्ट्रैप करते हैं। एपीआई के माध्यम से भी:
```
 mutation { bootstrap_vshard cluster { failover(enabled:true) } } 
```

आसान है, है ना?

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

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

बारीकियों के बारे में थोड़ा

टारनटूल कार्ट्रिज एडमिन क्लस्टर एपीआई के साथ काम करते समय, दोनों कॉल का क्रम और जहां वे आते हैं, महत्वपूर्ण है। ऐसा क्यों?

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

 servers: d8a9ce19-a880-5757-9ae0-6a0959525842: uri: storage-2-0.examples-kv-cluster:3301 replicaset_uuid: 8cf044f2-cae0-519b-8d08-00a2f1173fcb 497762e2-02a1-583e-8f51-5610375ebae9: uri: storage-0-0.examples-kv-cluster:3301 replicaset_uuid: 05e42b64-fa81-59e6-beb2-95d84c22a435 … vshard: bucket_count: 30000 ...

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

इसके अलावा, प्रत्येक उदाहरण के पास एक निश्चित पहचान होनी चाहिए, अर्थात् उदाहरण_ instance_uuid और replicaset_uuid का एक सेट, साथ ही साथ advertise_uri । यदि भंडारण अचानक पुनरारंभ होता है और इनमें से एक पैरामीटर बदलता है, तो आप कोरम को तोड़ने का जोखिम चलाते हैं - ऑपरेटर भी ऐसा करता है।

ऑपरेटर कैसे काम करता है

ऑपरेटर का कार्य सिस्टम को उपयोगकर्ता द्वारा निर्धारित स्थिति में लाना और नई दिशाएँ प्राप्त होने तक इस स्थिति को बनाए रखना है। ऑपरेटर को अपना काम पूरा करने में सक्षम होने के लिए, उसकी आवश्यकता है:

सिस्टम की स्थिति का विवरण।
वह कोड जो सिस्टम को इस स्थिति में लाता है।
इस कोड को k8s में एकीकृत करने का एक तंत्र (उदाहरण के लिए, राज्य में परिवर्तनों की सूचनाएं प्राप्त करने के लिए)।

टारेंटूल कार्ट्रिज क्लस्टर को कस्टम संसाधन परिभाषा (CRD) के माध्यम से k8 के संदर्भ में वर्णित किया गया है; ऑपरेटर को 3 ऐसे कस्टम संसाधनों की आवश्यकता है, जो टारनटूल.io/v1alpha समूह के तहत एकजुट हैं:

क्लस्टर एक शीर्ष-स्तरीय संसाधन है जो एक टारेंटूल कार्ट्रिज क्लस्टर से मेल खाता है।
भूमिका - टारनटूल कारतूस के संदर्भ में, यह एक उपयोगकर्ता की भूमिका है ।
ReplicasetTemplate - एक टेम्पलेट जिसके द्वारा स्टेटफुलसेट बनाया जाएगा (क्यों स्टेटफुल - मैं आपको थोड़ा बाद में बताऊंगा; k8s प्रतिकृति के साथ भ्रमित नहीं होना चाहिए)।

ये सभी संसाधन सीधे टारेंटूल कार्ट्रिज क्लस्टर विवरण मॉडल को दर्शाते हैं। एक सामान्य शब्दकोष होने के बाद, एक ऑपरेटर के लिए डेवलपर्स के साथ संवाद करना और यह समझना आसान है कि वे ठेस में क्या देखना चाहते हैं।

कोड जो दिए गए राज्य में सिस्टम लाता है - k8s के संदर्भ में, यह नियंत्रक है। टारनटूल ऑपरेटर के मामले में, कई नियंत्रक हैं:

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

नियंत्रक की तरह क्या है? कोड का एक सेट जो क्रम में दुनिया को धीरे-धीरे आपके चारों ओर लाता है। ClusterController इस तरह योजनाबद्ध रूप से चित्रित किया जा सकता है:

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

सामान्य तौर पर, सब कुछ सरल है। प्रत्येक चरण को पारित करने के लिए सफलता के मानदंड निर्धारित करना महत्वपूर्ण है। उदाहरण के लिए, जब हम सशर्त सफलता नहीं लौटाते हैं तो क्लस्टर में शामिल होने के संचालन को सफल मानते हैं = सही, लेकिन जब यह "आप इसमें शामिल" जैसी त्रुटि लौटाते हैं।

और इस तंत्र का अंतिम भाग k8s के साथ नियंत्रक का एकीकरण है। हवाई दृश्य, पूरे k8 में नियंत्रकों का एक समूह होता है जो घटनाओं को उत्पन्न करते हैं और उनका जवाब देते हैं। घटनाएँ उन कतारों से गुज़रती हैं जिनकी हम सदस्यता ले सकते हैं। योजनाबद्ध रूप से, इसे निम्नानुसार दर्शाया जा सकता है:

उपयोगकर्ता kubectl create -f tarantool_cluster.yaml , इसी क्लस्टर संसाधन बनाया जाता है। ClusterController को क्लस्टर संसाधन के निर्माण के बारे में सूचित किया जाता है। और पहली चीज जो वह करने की कोशिश कर रहा है वह सभी भूमिका संसाधनों को ढूंढना है जो इस क्लस्टर का हिस्सा होना चाहिए। यदि यह पता चलता है, तो क्लस्टर को रोल के लिए मालिक के रूप में असाइन करता है और रोल संसाधन को अपडेट करता है। रोलकंट्रोलर को एक रोल अपडेट अधिसूचना प्राप्त होती है, यह देखता है कि संसाधन के पास एक स्वामी है, और स्टेटफुलसेट बनाने के लिए शुरू होता है। और इतने पर एक सर्कल में: दूसरे का पहला स्ट्राइगर, तीसरे का दूसरा स्ट्राइगर - और इतने पर जब तक कोई रुकता नहीं है। और आप समय पर भी ट्रिगर कर सकते हैं, उदाहरण के लिए, हर 5 सेकंड, जो कभी-कभी उपयोगी होता है।

वह पूरा ऑपरेटर है: एक कस्टम संसाधन बनाएँ और कोड लिखें जो संसाधनों पर होने वाली घटनाओं पर प्रतिक्रिया करता है।

ऑपरेटर क्या विस्तार करता है

ऑपरेटर की कार्रवाइयां अंततः k8s को पॉड्स और कंटेनर बनाने के लिए प्रेरित करती हैं। K8s पर तैनात टारनटूल कार्ट्रिज क्लस्टर में, सभी पॉड्स को स्टेटफुलसेट्स में मिला दिया जाता है।

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

जब सभी क्लस्टर संसाधन बनाए जाते हैं और उन्हें वांछित स्थिति में लाया जाता है, तो वे निम्नलिखित पदानुक्रम बनाते हैं:

तीर संसाधनों के बीच मालिक-निर्भर संबंध को इंगित करते हैं। यह आवश्यक है कि कचरा कलेक्टर हमारे मामले में सफाई करे, उदाहरण के लिए, क्लस्टर हटाने।

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

टारेंटूल ऑपरेटर के हुड के तहत ऑपरेटर फ्रेमवर्क निहित है, ऑपरेटर कोड ही गोलंग में है, यहां कुछ भी असाधारण नहीं है।

परिणाम

यह सब, सामान्य तौर पर! हम आपसे प्रतिक्रिया और टिकटों की प्रतीक्षा कर रहे हैं - जहां उनके बिना, अल्फा संस्करण सभी समान हैं। आगे क्या है? और फिर इस सब को ध्यान में लाने के लिए बहुत काम है:

यूनिट, ई 2 ई परीक्षण;
कैओस बंदर परीक्षण
तनाव परीक्षण;
बैकअप / पुनर्स्थापना;
बाहरी टोपोलॉजी प्रदाता।

इनमें से प्रत्येक विषय अपने आप में व्यापक है और एक अलग सामग्री का हकदार है, अपडेट की प्रतीक्षा करें!