उबंटू के पीछे की कंपनी ये आश्चर्यजनक रूप से उपयोगी डेवलपर टूल भी बनाती है
जब आप "कैननिकल" सुनते हैं, तो सबसे पहले शायद उबंटू का ख्याल आता है, जो दुनिया का सबसे लोकप्रिय क्लाउड ऑपरेटिंग सिस्टम है। लेकिन लंदन स्थित इस कंपनी ने चुपचाप ओपन-सोर्स टूल्स का एक ऐसा शस्त्रागार इकट्ठा कर लिया है जो डेवलपर्स के सॉफ्टवेयर बनाने, परीक्षण करने और वितरित करने के तरीके को नया आकार दे रहा है। इंस्टेंट लोकल वीएम से लेकर प्रोडक्शन-ग्रेड कुबरनेटीज़ तक, कैननिकल के साइड प्रोजेक्ट अपने वजन वर्ग से कहीं अधिक प्रभाव डालते हैं। यह गहन विश्लेषण कैननिकल के पोर्टफोलियो में छिपे तीन रत्नों की पड़ताल करता है जो हर फ्रंटएंड डेवलपर, डेवऑप्स इंजीनियर और सिस्टम आर्किटेक्ट के टूलकिट में होने चाहिए।
मल्टीपास: किसी भी प्लेटफॉर्म पर इंस्टेंट उबंटू वीएम
क्रॉस-प्लेटफॉर्म डेवलपर के अस्तित्व का अभिशाप एनवायरनमेंट पैरिटी है। आप मैकओएस पर कोड करते हैं, लिनक्स पर डिप्लॉय करते हैं, और प्रार्थना करते हैं कि सीआई पाइपलाइन वह पकड़ ले जो आपकी लोकल मशीन नहीं पकड़ पाई। मल्टीपास इस घर्षण को खत्म करता है। यह एक हल्का वीएम मैनेजर है जो एक ही टर्मिनल कमांड से एक नया उबंटू इंस्टेंस स्पिन करता है। कोई वेग्रेंट फ़ाइलें नहीं, कोई वर्चुअलबॉक्स जीयूआई नहीं, कोई जटिल नेटवर्किंग विजार्ड्री नहीं।
मल्टीपास नेटिव हाइपरवाइज़र का उपयोग करता है, विंडोज़ पर हाइपर-वी, मैकओएस पर क्यूईएमयू और लिनक्स पर केवीएम, जो इसे वर्चुअलबॉक्स-आधारित विकल्पों की तुलना में काफी तेज़ बनाता है। आधुनिक हार्डवेयर पर बूट का समय तीन सेकंड से भी कम होता है।
शुद्ध लिनक्स वर्कलोड के लिए मल्टीपास डॉकर से कैसे बेहतर प्रदर्शन करता है
कंटेनर शानदार हैं, लेकिन वे होस्ट कर्नेल साझा करते हैं। जब आपको वास्तविक लिनक्स कर्नेल वातावरण की आवश्यकता होती है, जैसे कर्नेल मॉड्यूल का परीक्षण, स्नैप चलाना या सिस्टमडी का उपयोग करना, तो मल्टीपास एक पूर्ण ओएस प्रदान करता है, न कि कोई सजा-धजा प्रोसेस। सीएलआई आधुनिक वर्कफ़्लो के लिए स्वाभाविक लगता है:
# 'dev-node' नाम का एक VM लॉन्च करें जिसमें 4GB RAM और 2 CPU हों
multipass launch --name dev-node --memory 4G --cpus 2
# सीधे एक कमांड निष्पादित करें
multipass exec dev-node -- sudo apt update
# अपना होस्ट प्रोजेक्ट डायरेक्टरी VM के अंदर माउंट करें
multipass mount ~/my-project dev-node:/home/ubuntu/workसर्वर-साइड रेंडरिंग या नोड.जेएस बैकएंड पर काम करने वाले फ्रंटएंड डेवलपर्स के लिए, स्थानीय स्तर पर प्रोडक्शन इंफ्रास्ट्रक्चर की सटीक प्रतिकृति पर परीक्षण करने की क्षमता परिवर्तनकारी है। अब कोई "मेरी मशीन पर काम करता है" बहस नहीं।
LXD: सिस्टम कंटेनर जो VMs जैसे लगते हैं
LXD कंटेनरों और वर्चुअल मशीनों के बीच की रेखा को धुंधला करता है। ये "सिस्टम कंटेनर" हैं, ये एक पूर्ण इनिट सिस्टम चलाते हैं, इनमें लगातार स्टोरेज होता है, और ये बिल्कुल एक स्टैंडअलोन लिनक्स सर्वर की तरह व्यवहार करते हैं। फिर भी ये पारंपरिक वीएम की तुलना में काफी कम संसाधनों का उपभोग करते हैं क्योंकि ये होस्ट कर्नेल साझा करते हैं। LXD कैननिकल के इस प्रश्न का उत्तर है: "क्या होगा अगर डॉकर के अंदर एक पूर्ण ओएस होता?"
वास्तविक दुनिया का वर्कफ़्लो: स्थानीय माइक्रोसर्विस आर्किटेक्चर
कल्पना करें कि आप एक रिएक्ट फ्रंटएंड, एक पायथन एपीआई, एक रेडिस कैश और एक पोस्टग्रेएसक्यूएल डेटाबेस के साथ एक आधुनिक वेब एप्लिकेशन बना रहे हैं। LXD के साथ, आप स्थानीय स्तर पर संपूर्ण प्रोडक्शन टोपोलॉजी का मॉडल बना सकते हैं:
# डेटाबेस के लिए एक कंटेनर बनाएं
lxc launch ubuntu:22.04 db-server
lxc exec db-server -- apt install postgresql -y
# API के लिए एक कंटेनर बनाएं
lxc launch ubuntu:22.04 api-server
lxc exec api-server -- apt install python3-pip -y
# स्थिर IP असाइन करें और उन्हें लिंक करें
lxc network attach lxdbr0 db-server eth0
lxc config device set db-server eth0 ipv4.address=10.0.0.10प्रत्येक कंटेनर को अपना नेटवर्क इंटरफ़ेस, फ़ायरवॉल नियम और संसाधन सीमाएँ मिलती हैं। आप नेटवर्क विलंबता, पैकेट हानि का अनुकरण कर सकते हैं, या लचीलापन का परीक्षण करने के लिए किसी सेवा का प्लग खींच भी सकते हैं।
LXD क्लाउड-इनिट के साथ मूल रूप से एकीकृत होता है, जिसका अर्थ है कि आप AWS, Azure और Google Cloud में उपयोग किए जाने वाले समान कॉन्फ़िगरेशन प्रबंधन टूल के साथ कंटेनरों को प्रोविज़न कर सकते हैं। आपका स्थानीय परीक्षण वातावरण ओएस पैकेज संस्करणों तक आपके प्रोडक्शन इंफ्रास्ट्रक्चर से मेल खाता है।
जूजू: YAML स्प्रॉल से परे एप्लिकेशन मॉडलिंग
इंफ्रास्ट्रक्चर ऐज़ कोड का आमतौर पर मतलब होता है विशाल YAML फ़ाइलें और बैश स्क्रिप्ट जो महीनों के भीतर अनुरक्षणीय नहीं रह जाती हैं। जूजू एक मौलिक रूप से अलग दृष्टिकोण अपनाता है: यह सेवाओं के बीच संबंधों का मॉडल बनाता है, न कि केवल उनके कॉन्फ़िगरेशन का। एक जूजू "बंडल" आपके पूरे स्टैक की घोषणा है और यह कि टुकड़े कैसे जुड़ते हैं।
चार्म इकोसिस्टम ऑप्स ज्ञान को स्वचालित करता है
एक "चार्म" एक ऑपरेटर है, कोड का एक टुकड़ा जो किसी सेवा को डिप्लॉय और प्रबंधित करने के परिचालन ज्ञान को समाहित करता है। क्या आपको स्वचालित फ़ेलओवर के साथ एक उच्च-उपलब्धता वाले पोस्टग्रेएसक्यूएल क्लस्टर की आवश्यकता है? इसके लिए एक चार्म है, जो डेटाबेस विशेषज्ञों द्वारा बनाए रखा जाता है। इसे डिप्लॉय करना एक ही कमांड है:
juju deploy postgresql --channel 14/stable -n 3
juju deploy my-django-app
juju relate my-django-app postgresql:dbअंतिम पंक्ति जादू है। juju relate जूजू को बताता है कि आपके Django ऐप को एक डेटाबेस चाहिए। जूजू स्वचालित रूप से पोस्टग्रेएसक्यूएल को कॉन्फ़िगर करता है, डेटाबेस और उपयोगकर्ता बनाता है, और आपके Django ऐप के एनवायरनमेंट वेरिएबल्स में कनेक्शन स्ट्रिंग इंजेक्ट करता है। शून्य मैन्युअल कॉन्फ़िगरेशन।
डेवलपर-प्रोडक्शन गैप को पाटना
कैननिकल के इकोसिस्टम की असली शक्ति तब उभरती है जब आप इन टूल्स का एक साथ उपयोग करते हैं। एक सामान्य वर्कफ़्लो इस तरह दिखता है:
- स्थानीय रूप से विकसित करें अपने लक्ष्य उबंटू संस्करण से मेल खाने वाले मल्टीपास वीएम के साथ।
- पूर्ण टोपोलॉजी का अनुकरण करें प्रत्येक सेवा के लिए LXD कंटेनरों का उपयोग करके।
- डिप्लॉयमेंट का मॉडल बनाएं जूजू बंडलों के साथ जो संबंधों और स्केलिंग नियमों को परिभाषित करते हैं।
- समान रूप से डिप्लॉय करें किसी भी सार्वजनिक या निजी क्लाउड, या बेयर मेटल पर।
