नवीन वर्ष जवळ येत होते. देशभरातील मुलांनी आधीच सांताक्लॉजला पत्रे पाठवली होती किंवा स्वतःसाठी भेटवस्तू बनवल्या होत्या आणि त्यांचा मुख्य कार्यकारी, प्रमुख किरकोळ विक्रेत्यांपैकी एक, विक्रीच्या अपोथेसिसची तयारी करत होता. डिसेंबरमध्ये, त्याच्या डेटा सेंटरवरील भार अनेक वेळा वाढतो. म्हणून, कंपनीने डेटा सेंटरचे आधुनिकीकरण करण्याचा निर्णय घेतला आणि त्याच्या सेवा आयुष्याच्या शेवटच्या टप्प्यावर पोहोचलेल्या उपकरणांऐवजी अनेक डझन नवीन सर्व्हर कार्यान्वित केले. त्यामुळे फिरणाऱ्या स्नोफ्लेक्सच्या पार्श्वभूमीवर कथा संपते आणि थ्रिलर सुरू होते.

उपकरणे विक्रीच्या शिखरावर अनेक महिने आधी साइटवर आली. ऑपरेशन्स सेवेला अर्थातच, त्यांना उत्पादन वातावरणात आणण्यासाठी सर्व्हरवर कसे आणि काय कॉन्फिगर करावे हे माहित असते. परंतु आम्हाला हे स्वयंचलित करणे आणि मानवी घटक दूर करणे आवश्यक आहे. याव्यतिरिक्त, कंपनीसाठी गंभीर असलेल्या SAP प्रणालीच्या संचाच्या स्थलांतरापूर्वी सर्व्हर बदलले गेले.

नवीन सर्व्हरचे कार्यान्वित करणे हे काटेकोरपणे अंतिम मुदतीशी जोडलेले होते. आणि ते हलवण्याचा अर्थ अब्जावधी भेटवस्तूंची शिपमेंट आणि सिस्टीमचे स्थलांतर दोन्ही धोक्यात आणणे होय. फादर फ्रॉस्ट आणि सांताक्लॉज यांचा समावेश असलेला संघ देखील तारीख बदलू शकला नाही - आपण वर्षातून एकदाच वेअरहाऊस व्यवस्थापनासाठी एसएपी प्रणाली हस्तांतरित करू शकता. 31 डिसेंबर ते 1 जानेवारी या कालावधीत, किरकोळ विक्रेत्याची प्रचंड गोदामे, एकूण 20 फुटबॉल मैदाने, त्यांचे काम 15 तास थांबवतात. आणि सिस्टम हलवण्याचा हा एकमेव कालावधी आहे. सर्व्हर सादर करताना आमच्याकडे त्रुटीसाठी जागा नव्हती.

मला स्पष्ट करू द्या: माझी कथा आमचा कार्यसंघ वापरत असलेली साधने आणि कॉन्फिगरेशन व्यवस्थापन प्रक्रिया प्रतिबिंबित करते.

कॉन्फिगरेशन व्यवस्थापन कॉम्प्लेक्समध्ये अनेक स्तर असतात. मुख्य घटक CMS प्रणाली आहे. औद्योगिक ऑपरेशनमध्ये, स्तरांपैकी एकाची अनुपस्थिती अपरिहार्यपणे अप्रिय चमत्कारांना कारणीभूत ठरेल.

ओएस स्थापना व्यवस्थापन

प्रथम स्तर भौतिक आणि आभासी सर्व्हरवर ऑपरेटिंग सिस्टमची स्थापना व्यवस्थापित करण्यासाठी एक प्रणाली आहे. हे मूलभूत OS कॉन्फिगरेशन तयार करते, मानवी घटक काढून टाकते.

या प्रणालीचा वापर करून, आम्हाला पुढील ऑटोमेशनसाठी योग्य OS सह मानक सर्व्हर उदाहरणे मिळाली. "ओतणे" दरम्यान त्यांना स्थानिक वापरकर्त्यांचा किमान संच आणि सार्वजनिक SSH की, तसेच एक सुसंगत OS कॉन्फिगरेशन प्राप्त झाले. आम्हाला CMS द्वारे सर्व्हर व्यवस्थापित करण्याची हमी देण्यात आली होती आणि OS स्तरावर "खाली" कोणतेही आश्चर्य नाही याची खात्री होती.

इन्स्टॉलेशन मॅनेजमेंट सिस्टीमचे "जास्तीत जास्त" कार्य म्हणजे BIOS/फर्मवेअर स्तरावरून OS पर्यंत सर्व्हर आपोआप कॉन्फिगर करणे. येथे बरेच काही उपकरणे आणि सेटअप कार्यांवर अवलंबून असते. विषम उपकरणांसाठी, आपण विचार करू शकता REDFISH API. जर सर्व हार्डवेअर एकाच विक्रेत्याकडून असतील, तर बहुतेकदा तयार व्यवस्थापन साधने वापरणे अधिक सोयीचे असते (उदाहरणार्थ, HP ILO अॅम्प्लीफायर, DELL OpenManage इ.).

भौतिक सर्व्हरवर OS स्थापित करण्यासाठी, आम्ही सुप्रसिद्ध कोब्बलर वापरला, जो ऑपरेशन सेवेशी सहमत असलेल्या इंस्टॉलेशन प्रोफाइलचा संच परिभाषित करतो. इन्फ्रास्ट्रक्चरमध्ये नवीन सर्व्हर जोडताना, इंजिनियरने सर्व्हरचा MAC पत्ता कोब्बलरमधील आवश्यक प्रोफाइलशी जोडला. प्रथमच नेटवर्कवर बूट करताना, सर्व्हरला तात्पुरता पत्ता आणि एक नवीन OS प्राप्त झाला. नंतर ते लक्ष्य VLAN/IP पत्त्यावर हस्तांतरित केले गेले आणि तेथे काम चालू ठेवले. होय, VLAN बदलण्यासाठी वेळ लागतो आणि समन्वयाची आवश्यकता असते, परंतु ते उत्पादन वातावरणात सर्व्हरच्या अपघाती स्थापनेपासून अतिरिक्त संरक्षण प्रदान करते.

आम्ही HashiSorp Packer वापरून तयार केलेल्या टेम्प्लेटवर आधारित व्हर्च्युअल सर्व्हर तयार केले. कारण समान होते: ओएस स्थापित करताना संभाव्य मानवी चुका टाळण्यासाठी. परंतु, फिजिकल सर्व्हरच्या विपरीत, पॅकर PXE, नेटवर्क बूटिंग आणि VLAN बदलांची गरज काढून टाकतो. यामुळे आभासी सर्व्हर तयार करणे सोपे आणि सोपे झाले आहे.

तांदूळ. 1. ऑपरेटिंग सिस्टमची स्थापना व्यवस्थापित करणे.

रहस्ये व्यवस्थापित करणे

कोणत्याही कॉन्फिगरेशन व्यवस्थापन प्रणालीमध्ये डेटा असतो जो सामान्य वापरकर्त्यांपासून लपविला पाहिजे, परंतु सिस्टम तयार करण्यासाठी आवश्यक असतो. हे स्थानिक वापरकर्ते आणि सेवा खाती, सर्टिफिकेट की, विविध API टोकन इ.साठी पासवर्ड आहेत. त्यांना सहसा "गुप्त" असे म्हणतात.

ही रहस्ये कोठे आणि कशी संग्रहित करायची हे आपण अगदी सुरुवातीपासूनच ठरवत नसल्यास, माहिती सुरक्षा आवश्यकतांच्या तीव्रतेनुसार, खालील स्टोरेज पद्धतींची शक्यता आहे:

• थेट कॉन्फिगरेशन कंट्रोल कोडमध्ये किंवा रेपॉजिटरीमधील फाइल्समध्ये;
• विशेष कॉन्फिगरेशन व्यवस्थापन साधनांमध्ये (उदाहरणार्थ, उत्तरदायी व्हॉल्ट);
• CI/CD सिस्टीममध्ये (Jenkins/TeamCity/GitLab/etc.) किंवा कॉन्फिगरेशन मॅनेजमेंट सिस्टम्समध्ये (Ansible Tower/Ansible AWX);
• रहस्ये "स्वतः" देखील हस्तांतरित केली जाऊ शकतात. उदाहरणार्थ, ते एका विशिष्ट ठिकाणी ठेवलेले असतात आणि नंतर ते कॉन्फिगरेशन व्यवस्थापन प्रणालीद्वारे वापरले जातात;
• वरील विविध संयोजन.

प्रत्येक पद्धतीचे स्वतःचे तोटे आहेत. मुख्य म्हणजे रहस्यांमध्ये प्रवेश करण्यासाठी धोरणांचा अभाव: विशिष्ट रहस्ये कोण वापरू शकेल हे ठरवणे अशक्य किंवा कठीण आहे. आणखी एक तोटा म्हणजे प्रवेश ऑडिटिंगचा अभाव आणि संपूर्ण जीवन चक्र. त्वरीत कसे बदलायचे, उदाहरणार्थ, कोडमध्ये आणि अनेक संबंधित सिस्टममध्ये लिहिलेली सार्वजनिक की?

आम्ही केंद्रीकृत गुप्त स्टोरेज HashiCorp Vault वापरले. हे आम्हाला अनुमती देते:

• गुपिते सुरक्षित ठेवा. ते एन्क्रिप्ट केलेले आहेत, आणि जरी एखाद्याने व्हॉल्ट डेटाबेसमध्ये प्रवेश मिळवला (उदाहरणार्थ, बॅकअपमधून पुनर्संचयित करून), ते तेथे संग्रहित रहस्ये वाचण्यास सक्षम होणार नाहीत;
• गुपितांमध्ये प्रवेश करण्यासाठी धोरणे आयोजित करा. केवळ त्यांना "वाटप केलेले" रहस्ये वापरकर्ते आणि अनुप्रयोगांसाठी उपलब्ध आहेत;
• गुपिते ऑडिट प्रवेश. गुपिते असलेली कोणतीही क्रिया व्हॉल्ट ऑडिट लॉगमध्ये रेकॉर्ड केली जाते;
• रहस्यांसह कार्य करण्याचे पूर्ण वाढलेले "जीवन चक्र" आयोजित करा. ते तयार केले जाऊ शकतात, रद्द केले जाऊ शकतात, कालबाह्यता तारीख सेट करू शकतात.
• गुपितांमध्ये प्रवेश आवश्यक असलेल्या इतर सिस्टमसह समाकलित करणे सोपे आहे;
• आणि एंड-टू-एंड एन्क्रिप्शन, OS आणि डेटाबेससाठी वन-टाइम पासवर्ड, अधिकृत केंद्रांची प्रमाणपत्रे इ. देखील वापरा.

आता केंद्रीय प्रमाणीकरण आणि अधिकृतता प्रणालीकडे वळू. त्याशिवाय हे करणे शक्य होते, परंतु अनेक संबंधित प्रणालींमध्ये वापरकर्त्यांचे व्यवस्थापन करणे खूप क्षुल्लक आहे. आम्ही LDAP सेवेद्वारे प्रमाणीकरण आणि अधिकृतता कॉन्फिगर केली आहे. अन्यथा, व्हॉल्टला सतत जारी करावे लागेल आणि वापरकर्त्यांसाठी प्रमाणीकरण टोकन्सचा मागोवा ठेवावा लागेल. आणि वापरकर्ते हटवणे आणि जोडणे हे शोधात बदलेल “मी हे वापरकर्ता खाते सर्वत्र तयार/हटवले आहे का?”

आम्ही आमच्या सिस्टममध्ये आणखी एक स्तर जोडतो: रहस्ये व्यवस्थापन आणि केंद्रीय प्रमाणीकरण/अधिकृतीकरण:

तांदूळ. 2. गुपिते व्यवस्थापन.

कॉन्फिगरेशन व्यवस्थापन

आम्ही मुख्य - CMS प्रणालीवर पोहोचलो. आमच्या बाबतीत, हे Ansible आणि Red Hat Ansible AWX चे संयोजन आहे.

Ansible च्या ऐवजी शेफ, पपेट, सॉल्टस्टॅक वापरता येईल. आम्ही अनेक निकषांवर आधारित उत्तरदायी निवडले.

• प्रथम, ते अष्टपैलुत्व आहे. नियंत्रणासाठी तयार मॉड्यूलचा संच ते प्रभावी आहे. आणि तुमच्याकडे ते पुरेसे नसल्यास, तुम्ही GitHub आणि Galaxy वर शोधू शकता.
• दुसरे म्हणजे, व्यवस्थापित उपकरणांवर एजंट स्थापित करण्याची आणि त्यांना समर्थन देण्याची आवश्यकता नाही, ते लोडमध्ये व्यत्यय आणत नाहीत हे सिद्ध करा आणि "बुकमार्क" च्या अनुपस्थितीची पुष्टी करा.
• तिसरे म्हणजे, Ansible ला प्रवेशासाठी कमी अडथळा आहे. एक सक्षम अभियंता उत्पादनासह काम करण्याच्या पहिल्या दिवशी अक्षरशः कार्यरत प्लेबुक लिहितो.

पण उत्पादन वातावरणात एकटे उत्तरदायी आमच्यासाठी पुरेसे नव्हते. अन्यथा, प्रवेश प्रतिबंधित करणे आणि प्रशासकांच्या कृतींचे ऑडिट करून अनेक समस्या उद्भवतील. प्रवेश कसा प्रतिबंधित करायचा? शेवटी, प्रत्येक विभागासाठी सर्व्हरचा “स्वतःचा” संच व्यवस्थापित करणे (वाचा: उत्तरदायी प्लेबुक चालवा) आवश्यक होते. विशिष्ट कर्मचार्‍यांना विशिष्ट उत्तरदायी प्लेबुक चालवण्याची परवानगी कशी द्यावी? किंवा Ansible चालू असलेल्या सर्व्हर आणि उपकरणांवर बरेच स्थानिक ज्ञान सेट न करता प्लेबुक कोणी लॉन्च केले याचा मागोवा कसा घ्यावा?

अशा समस्यांचा सिंहाचा वाटा रेड हॅटने सोडवला आहे उत्तरदायी टॉवर, किंवा त्याचा ओपन-सोर्स अपस्ट्रीम प्रकल्प उत्तरदायी AWX. म्हणूनच आम्ही ग्राहकांसाठी त्याला प्राधान्य दिले.

आणि आमच्या CMS प्रणालीच्या पोर्ट्रेटला आणखी एक स्पर्श. उत्तरदायी प्लेबुक कोड रेपॉजिटरी व्यवस्थापन प्रणालीमध्ये संग्रहित केले जावे. आमच्याकडे आहे GitLab CE.

तर, कॉन्फिगरेशन स्वतःच Ansible/Ansible AWX/GitLab च्या संयोजनाद्वारे व्यवस्थापित केले जातात (चित्र 3 पहा). अर्थात, AWX/GitLab एकाच प्रमाणीकरण प्रणालीसह एकत्रित केले आहे, आणि उत्तरदायी प्लेबुक HashiCorp Vault सह एकत्रित केले आहे. कॉन्फिगरेशन केवळ उत्तरदायी AWX द्वारे उत्पादन वातावरणात प्रवेश करतात, ज्यामध्ये सर्व “गेमचे नियम” निर्दिष्ट केले जातात: कोण काय कॉन्फिगर करू शकते, CMS साठी कॉन्फिगरेशन व्यवस्थापन कोड कोठे मिळवायचा इ.

तांदूळ. 3. कॉन्फिगरेशन व्यवस्थापन.

चाचणी व्यवस्थापन

आमचे कॉन्फिगरेशन कोड स्वरूपात सादर केले आहे. म्हणून, आम्हाला सॉफ्टवेअर विकसकांप्रमाणेच नियमांनुसार खेळण्यास भाग पाडले जाते. आम्हाला विकास प्रक्रिया, सतत चाचणी, वितरण आणि कॉन्फिगरेशन कोड उत्पादन सर्व्हरवर लागू करणे आवश्यक आहे.

जर हे त्वरित केले नाही, तर कॉन्फिगरेशनसाठी लिहिलेल्या भूमिका एकतर समर्थित आणि सुधारित केल्या जातील किंवा उत्पादनात लॉन्च करणे थांबवेल. या वेदनेचा इलाज ज्ञात आहे, आणि तो या प्रकल्पात सिद्ध झाला आहे:

• प्रत्येक भूमिका युनिट चाचण्यांद्वारे कव्हर केली जाते;
• कॉन्फिगरेशन व्यवस्थापित करणार्‍या कोडमध्ये जेव्हाही बदल होतो तेव्हा चाचण्या आपोआप चालतात;
• कॉन्फिगरेशन मॅनेजमेंट कोडमधील बदल सर्व चाचण्या आणि कोड पुनरावलोकन यशस्वीरित्या उत्तीर्ण झाल्यानंतरच उत्पादन वातावरणात सोडले जातात.

कोड डेव्हलपमेंट आणि कॉन्फिगरेशन मॅनेजमेंट शांत आणि अधिक अंदाज करण्यायोग्य बनले आहे. सतत चाचणी आयोजित करण्यासाठी, आम्ही GitLab CI/CD टूलकिट वापरले आणि घेतले उत्तरदायी रेणू.

जेव्हा जेव्हा कॉन्फिगरेशन मॅनेजमेंट कोडमध्ये बदल होतो तेव्हा GitLab CI/CD मॉलिक्युलला कॉल करते:

• ते कोड वाक्यरचना तपासते,
• डॉकर कंटेनर वाढवतो,
• तयार केलेल्या कंटेनरवर सुधारित कोड लागू करतो,
• इडम्पोटेन्सीची भूमिका तपासते आणि या कोडसाठी चाचण्या चालवते (येथे ग्रॅन्युलॅरिटी उत्तरदायी भूमिका स्तरावर आहे, चित्र 4 पहा).

आम्ही Ansible AWX वापरून उत्पादन वातावरणात कॉन्फिगरेशन वितरित केले. ऑपरेशन इंजिनीअर्सनी पूर्वनिर्धारित टेम्पलेट्सद्वारे कॉन्फिगरेशन बदल लागू केले. AWX ने GitLab मास्टर शाखेकडून कोडची नवीनतम आवृत्ती प्रत्येक वेळी वापरताना स्वतंत्रपणे "विनंती" केली. अशा प्रकारे आम्ही उत्पादन वातावरणात न तपासलेला किंवा कालबाह्य कोडचा वापर वगळला. साहजिकच, चाचणी, पुनरावलोकन आणि मंजुरीनंतरच कोड मास्टर शाखेत दाखल झाला.

तांदूळ. 4. GitLab CI/CD मधील भूमिकांची स्वयंचलित चाचणी.

उत्पादन प्रणालीच्या ऑपरेशनशी संबंधित समस्या देखील आहे. वास्तविक जीवनात, केवळ CMS कोडद्वारे कॉन्फिगरेशन बदल करणे खूप कठीण आहे. आपत्कालीन परिस्थिती उद्भवते जेव्हा अभियंत्याने कोड संपादन, चाचणी, मंजूरी इत्यादीची वाट न पाहता “येथे आणि आता” कॉन्फिगरेशन बदलणे आवश्यक आहे.

परिणामी, मॅन्युअल बदलांमुळे, समान प्रकारच्या उपकरणांवरील कॉन्फिगरेशनमध्ये विसंगती दिसून येतात (उदाहरणार्थ, HA क्लस्टर नोड्सवर sysctl सेटिंग्ज वेगळ्या पद्धतीने कॉन्फिगर केल्या आहेत). किंवा उपकरणावरील वास्तविक कॉन्फिगरेशन सीएमएस कोडमध्ये निर्दिष्ट केलेल्यापेक्षा भिन्न आहे.

म्हणून, सतत चाचणी व्यतिरिक्त, आम्ही कॉन्फिगरेशन विसंगतींसाठी उत्पादन वातावरण तपासतो. आम्ही सर्वात सोपा पर्याय निवडला: CMS कॉन्फिगरेशन कोड “ड्राय रन” मोडमध्ये चालवणे, म्हणजे बदल लागू न करता, परंतु नियोजित आणि वास्तविक कॉन्फिगरेशनमधील सर्व विसंगतींच्या सूचनांसह. आम्ही प्रॉडक्शन सर्व्हरवर “—चेक” पर्यायासह सर्व उत्तरदायी प्लेबुक्स वेळोवेळी चालवून याची अंमलबजावणी केली. नेहमीप्रमाणे, प्लेबुक लॉन्च करण्यासाठी आणि अद्ययावत ठेवण्यासाठी Ansible AWX जबाबदार आहे (चित्र 5 पहा):

तांदूळ. 5. उत्तरदायी AWX मधील कॉन्फिगरेशन विसंगती तपासते.

तपासणीनंतर, AWX प्रशासकांना विसंगतीचा अहवाल पाठवते. ते समस्याप्रधान कॉन्फिगरेशनचा अभ्यास करतात आणि नंतर समायोजित प्लेबुकद्वारे त्याचे निराकरण करतात. अशा प्रकारे आम्ही उत्पादन वातावरणात कॉन्फिगरेशन राखतो आणि CMS नेहमी अद्ययावत आणि सिंक्रोनाइझ केले जाते. जेव्हा "उत्पादन" सर्व्हरवर CMS कोड वापरला जातो तेव्हा हे अप्रिय "चमत्कार" काढून टाकते.

आमच्याकडे आता Ansible AWX/GitLab/Molecule (आकृती 6) चा एक महत्त्वाचा चाचणी स्तर आहे.

तांदूळ. 6. चाचणी व्यवस्थापन.

अवघड? मी वाद घालत नाही. परंतु कॉन्फिगरेशन व्यवस्थापनाचे असे कॉम्प्लेक्स सर्व्हर कॉन्फिगरेशनच्या ऑटोमेशनशी संबंधित अनेक प्रश्नांचे सर्वसमावेशक उत्तर बनले आहे. आता किरकोळ विक्रेत्याच्या मानक सर्व्हरमध्ये नेहमीच काटेकोरपणे परिभाषित कॉन्फिगरेशन असते. सीएमएस, अभियंता विपरीत, आवश्यक सेटिंग्ज जोडण्यास, वापरकर्ते तयार करण्यास आणि डझनभर किंवा शेकडो आवश्यक सेटिंग्ज करण्यास विसरणार नाही.

आज सर्व्हर आणि वातावरणाच्या सेटिंग्जमध्ये कोणतेही "गुप्त ज्ञान" नाही. सर्व आवश्यक वैशिष्ट्ये प्लेबुकमध्ये प्रतिबिंबित होतात. आणखी सर्जनशीलता आणि अस्पष्ट सूचना नाहीत: "ते नेहमीच्या ओरॅकलप्रमाणे स्थापित करा, परंतु तुम्हाला काही sysctl सेटिंग्ज निर्दिष्ट करणे आणि आवश्यक UID सह वापरकर्ते जोडणे आवश्यक आहे. ऑपरेशनमध्ये असलेल्या लोकांना विचारा, त्यांना माहित आहे».

कॉन्फिगरेशन विसंगती शोधण्याची आणि त्यांना सक्रियपणे दुरुस्त करण्याची क्षमता मनःशांती प्रदान करते. कॉन्फिगरेशन व्यवस्थापन प्रणालीशिवाय, हे सहसा वेगळे दिसते. एक दिवस ते उत्पादनात "शूट" होईपर्यंत समस्या जमा होतात. नंतर डीब्रीफिंग केले जाते, कॉन्फिगरेशन तपासले जातात आणि दुरुस्त केले जातात. आणि चक्र पुन्हा पुनरावृत्ती होते

आणि अर्थातच, आम्ही सर्व्हरच्या लाँचला अनेक दिवसांपासून तासांपर्यंत गती दिली.

बरं, नवीन वर्षाच्या पूर्वसंध्येला, जेव्हा मुलं आनंदाने भेटवस्तू उघडत होती आणि प्रौढ लोक झंकार वाजल्याप्रमाणे शुभेच्छा देत होते, तेव्हा आमच्या अभियंत्यांनी SAP प्रणाली नवीन सर्व्हरवर स्थलांतरित केली. अगदी सांताक्लॉजही म्हणेल की सर्वोत्तम चमत्कार तेच आहेत जे चांगले तयार आहेत.

PS आमच्या कार्यसंघाला अनेकदा हे तथ्य आढळते की ग्राहकांना कॉन्फिगरेशन व्यवस्थापन समस्या शक्य तितक्या सोप्या पद्धतीने सोडवायच्या आहेत. आदर्शपणे, जणू जादूद्वारे - एका साधनासह. परंतु जीवनात सर्व काही अधिक क्लिष्ट आहे (होय, चांदीच्या बुलेट पुन्हा वितरित केल्या गेल्या नाहीत): तुम्हाला ग्राहकाच्या टीमसाठी सोयीस्कर साधनांचा वापर करून संपूर्ण प्रक्रिया तयार करावी लागेल.

लेखक: सेर्गेई आर्टेमोव्ह, विभाग आर्किटेक्ट DevOps उपाय "जेट इन्फोसिस्टम्स"

स्त्रोत: www.habr.com