इन्फ्रास्ट्रक्चर कोड की 300,000 से अधिक लाइनें लिखकर हमने 5 सबक सीखे

बुनियादी ढांचा कोड विकसित करने पर एक संक्षिप्त मास्टर वर्ग

इस वर्ष के अक्टूबर में, मैंने HashiConf 2018 सम्मेलन में एक प्रस्तुति दी, जहाँ मैंने 5 प्रमुख पाठों के बारे में बात की, जो कि ग्रंटवर्क के मेरे सहयोगियों ने किए और मैंने उत्पादन प्रणालियों में सैकड़ों कंपनियों के बुनियादी ढांचे के कोड की 300,000 से अधिक लाइनों के निर्माण और रखरखाव की प्रक्रिया को सीखा। इस प्रकाशन में, मैं प्रस्तुति से वीडियो और स्लाइड साझा करूंगा, साथ ही 5 मुख्य पाठों के वर्णन का संक्षिप्त पाठ संस्करण भी।

वीडियो और स्लाइड

परिचय: पाषाण युग में देवो अब

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

व्यक्तिगत रूप से, DevOps मुझे इसकी और अधिक याद दिलाता है:

उत्पादन-स्तरीय बुनियादी ढाँचा बनाना मुश्किल है। यह वास्तविक तनाव है। और बहुत समय खाता है। बहुत समय।

यह दिखाता है कि अगली बुनियादी ढांचा परियोजना को लागू करने में कितना समय लगेगा। हम अनुभवजन्य डेटा पर भरोसा करते हैं जो हमने सैकड़ों विभिन्न कंपनियों के साथ काम के दौरान एकत्र किया था:

पाठ 1. विनिर्माण अवसंरचना के लिए चेकलिस्ट

DevOps प्रोजेक्ट हमेशा आपकी अपेक्षा से अधिक समय लेते हैं। हमेशा। ऐसा क्यों?
पहला कारण एक याक बाल कटवाने है । नीचे इस घटना का एक विशद चित्रण है, (यह "स्पॉटलाइट में मैल्कम इन द स्पॉटलाइट" श्रृंखला का एक अंश है)

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

बुनियादी ढांचे के प्रत्येक व्यक्ति के लिए सूची के सभी तत्वों की आवश्यकता नहीं होगी, लेकिन आपको सचेत रूप से और स्पष्ट रूप से दस्तावेज़ में होना चाहिए कि आपने किन तत्वों को लागू किया है, और जिन्हें आपने छोड़ने का फैसला किया है और क्यों।

पाठ 2. टूलबॉक्स

हम बुनियादी उपकरणों की सूची बनाते हैं जिनका उपयोग हम बुनियादी ढांचे को बनाने और प्रबंधित करने के लिए 2018 के अनुसार करते हैं:

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

ये सभी उपकरण उपयोगी हैं, लेकिन यह बात नहीं है। आपको यह समझने की आवश्यकता है कि कुछ उपकरण पर्याप्त नहीं हैं। टीम के व्यवहार को बदलना भी आवश्यक है।

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

पाठ 3. बड़े मॉड्यूल बुराई हैं

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

यहाँ इस दृष्टिकोण के कुछ नुकसान हैं:

• कम गति यदि पूरे बुनियादी ढांचे को एक ही स्थान पर परिभाषित किया गया है, तो किसी भी कमांड के निष्पादन में बहुत समय लगेगा। हमें कंपनियों में स्थितियों का सामना करना पड़ा जब terraform plan टीम को पूरा करने में 5-6 मिनट लगे!
• कम सुरक्षा । यदि आप एक साथ पूरे बुनियादी ढांचे का प्रबंधन करते हैं, तो कुछ को बदलने के लिए आपको सब कुछ एक्सेस करने के लिए अनुमतियों की आवश्यकता होती है। यही है, लगभग हर उपयोगकर्ता को एक व्यवस्थापक होना चाहिए, और यह भी बहुत असुविधाजनक है।
• उच्च जोखिम । यदि आप अपने सभी अंडे एक टोकरी में रखते हैं, तो एक ऐसी स्थिति बनाएं जहां एक स्थानीय त्रुटि पूरे बुनियादी ढांचे के संचालन को बाधित कर सकती है। उदाहरण के लिए, जब आप विकास के वातावरण में एक बाहरी अनुप्रयोग में मामूली बदलाव करते हैं, तो एक एकल टाइपो या गलत कमांड उत्पादन डेटाबेस को हटाने का कारण बन सकता है।
• इसे समझना कठिन है । जितना अधिक कोड एक स्थान पर रखा जाता है, उतना ही एक व्यक्ति के लिए यह सब समझना जितना मुश्किल होता है। और जब यह सब जुड़ा होगा, तो समझ से बाहर के हिस्से आपके साथ एक क्रूर मजाक करेंगे।
• कठिन परीक्षा है । परीक्षण अवसंरचना कोड कठिन है; बड़ी मात्रा में इन्फ्रास्ट्रक्चर कोड का परीक्षण लगभग असंभव है। हम बाद में इस पर वापस आएंगे।
• इसका विश्लेषण करना कठिन है । टेराफॉर्म प्लान जैसी कमांड का आउटपुट बेकार हो जाता है, क्योंकि कोई भी हजारों लाइनों को देखने के लिए परेशान नहीं करता है। इसके अलावा, कोड विश्लेषण बेकार हो जाता है।

संक्षेप में, आपको अपना कोड छोटे, स्टैंड-अलोन और पुन: प्रयोज्य समग्र मॉड्यूल से बनाना होगा। यह न तो खबर है और न ही खोज। आपने इसे हजार बार सुना है, हालांकि थोड़ी अलग स्थितियों में:

"एक काम करो और इसे अच्छे से करो" - यूनिक्स दर्शन।
“कार्यों का पहला नियम यह है कि वे छोटे होने चाहिए। दूसरा नियम कहता है कि कार्य और भी छोटे होने चाहिए। " - "अपना नया कोड"

पाठ 4. स्वचालित परीक्षणों के बिना इन्फ्रास्ट्रक्चर कोड दोषपूर्ण है

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

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

यूनिट परीक्षण एक ही प्रकार के (उदाहरण के लिए, एकल डेटाबेस के लिए मॉड्यूल) एक या अधिक बारीकी से संबंधित अवसंरचना मॉड्यूल की तैनाती और परीक्षण करते हैं।

एकीकरण परीक्षण यह सुनिश्चित करने के लिए कि वे एक साथ काम करते हैं (उदाहरण के लिए, डेटाबेस मॉड्यूल और वेब सेवा मॉड्यूल) के कई बुनियादी ढांचे के मॉड्यूल को तैनात और परीक्षण करते हैं।

एंड-टू-एंड टेस्ट (e2e) संपूर्ण आर्किटेक्चर की तैनाती और परीक्षण करता है।
कृपया ध्यान दें कि आरेख एक पिरामिड है: हमारे पास कई इकाई परीक्षण, कम एकीकरण परीक्षण और बहुत कम e2e परीक्षण हैं। क्यों? यह प्रत्येक प्रकार के परीक्षण की अवधि पर निर्भर करता है:

बुनियादी ढांचे के परीक्षणों में बहुत समय लगता है, खासकर पिरामिड के ऊपरी स्तरों पर, और निश्चित रूप से, आप बहुत कम से कम त्रुटियों को ढूंढना और ठीक करना चाहेंगे। ऐसा करने के लिए, आपको चाहिए:

1. छोटे और सरल स्टैंडअलोन मॉड्यूल बनाएं (पाठ 3 देखें) और उनके लिए बहुत सारे यूनिट परीक्षण लिखें - सुनिश्चित करें कि वे सही ढंग से काम करते हैं।
2. इन छोटे, सरल और सिद्ध ब्लॉकों को मिलाकर एक अधिक परिष्कृत बुनियादी ढाँचा तैयार करें जिसे आप कम एकीकरण और E2E परीक्षणों के साथ परखते हैं।

पाठ 5. रिलीज की प्रक्रिया

उपरोक्त सभी को संक्षेप में प्रस्तुत करना। यहां बताया गया है कि अब आप अपने बुनियादी ढांचे का निर्माण और प्रबंधन कैसे करेंगे:

• उत्पादन-श्रेणी के बुनियादी ढांचे के लिए चेकलिस्ट की जांच करें और सुनिश्चित करें कि आप सही दिशा में काम कर रहे हैं।
• Terraform, Packer, और Docker जैसे उपकरणों के साथ अपने "बुनियादी ढांचे को कोड के रूप में परिभाषित करें"। सुनिश्चित करें कि आपकी टीम के पास इन उपकरणों को सीखने के लिए पर्याप्त समय है ( DevOps Resources देखें)।
• छोटे और स्टैंड-अलोन कंपोजिट मॉड्यूल से कोड बनाएं (या कोड लाइब्रेरी के रूप में इन्फ्रास्ट्रक्चर से मानक मॉड्यूल का उपयोग करें)।
• Terratest के साथ अपने मॉड्यूल के लिए स्वचालित परीक्षण तैयार करें।
• अपने कोड की समीक्षा करने के लिए अपने परिवर्तनों को शामिल करने के अनुरोध को पूरा करें।
• कोड का नया संस्करण जारी करें।
• एक पर्यावरण से दूसरे में कोड के नए संस्करण की प्रतिलिपि बनाएँ।