सिस्टमडी के साथ माइक्रो-डेवऑप्स: किसी भी सामान्य लिनक्स सर्वर को सुपरचार्ज करें

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

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

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

एक सिस्टमड प्राइमर

एक ही होस्ट पर, systemd .service फ़ाइल लिखना एक प्रबंधित प्रक्रिया को चलाने का एक आदर्श तरीका है। अधिकांश समय, आपको एप्लिकेशन को बदलने की बिल्कुल भी आवश्यकता नहीं होती है: सिस्टमडी विभिन्न प्रकार की सेवाओं का समर्थन करता है और तदनुसार अनुकूलित हो सकता है।

उदाहरण के लिए, इस सरल .service पर विचार करें जो परिभाषित करती है कि एक साधारण वेब सेवा कैसे चलायी जाए:

 [Unit] Description=a simple web service [Service] ExecStart=/usr/bin/python3 -m http.server 8080

जब इसे /etc/systemd/system/webapp.service जैसी फ़ाइल में रखा जाता है, तो यह एक सेवा बनाता है जिसे आप systemctl से नियंत्रित कर सकते हैं:

• systemctl start webapp प्रक्रिया प्रारंभ करेगा।
• systemctl status webapp प्रदर्शित करेगा कि सेवा चल रही है या नहीं, इसका अपटाइम, और stderr और stdout से आउटपुट, साथ ही प्रक्रिया की आईडी और अन्य जानकारी।
• systemctl stop webapp सेवा समाप्त कर देगा।

इसके अलावा, stderr और stdout पर मुद्रित सभी आउटपुट को जर्नल द्वारा एकत्रित किया जाएगा और सिस्टम जर्नल के माध्यम से पहुंच योग्य होगा ( journalctl के साथ) या विशेष रूप से --unit ध्वज का उपयोग करके लक्षित किया जाएगा:

 journalctl --unit webapp

क्योंकि जर्नल डिफ़ॉल्ट रूप से अपने स्टोरेज को घुमाता और प्रबंधित करता है, जर्नल के माध्यम से लॉग एकत्र करना लॉग स्टोरेज को प्रबंधित करने के लिए एक अच्छी रणनीति है।

इस लेख के शेष भाग में इस जैसी सेवा को बढ़ाने के विकल्पों का पता लगाया जाएगा।

रहस्य

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

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

किसी सिस्टमडी सेवा में एक रहस्य डालने के लिए, गुप्त मान वाली फ़ाइल को फ़ाइल सिस्टम पर एक पथ में रखकर प्रारंभ करें। उदाहरण के लिए, एक एपीआई कुंजी को .service इकाई में प्रदर्शित करने के लिए, फ़ाइल को रिबूट के दौरान बनाए रखने के लिए /etc/credstore/api-key पर या फ़ाइल को स्थायी रूप से बनाए रखने से बचने के लिए /run/credstore/api-key पर एक फ़ाइल बनाएं ( पथ मनमाना हो सकता है, लेकिन सिस्टमडी इन credstore पथों को डिफ़ॉल्ट के रूप में मानेगा)। किसी भी स्थिति में, फ़ाइल chmod 400 /etc/credstore/api-key जैसे कमांड का उपयोग करके प्रतिबंधित अनुमतियाँ होनी चाहिए।

.service फ़ाइल के [Service] अनुभाग के अंतर्गत, LoadCredential= विकल्प को परिभाषित करें और इसे कोलन ( : ) द्वारा अलग किए गए दो मानों को पास करें: क्रेडेंशियल का नाम और उसका पथ। उदाहरण के लिए, हमारी /etc/credstore/api-key फ़ाइल को "टोकन" कहने के लिए, निम्नलिखित सिस्टमडी सेवा विकल्प को परिभाषित करें:

 LoadCredential=token:/etc/credstore/api-key

जब सिस्टमडी आपकी सेवा शुरू करता है, तो रहस्य फॉर्म ${CREDENTIALS_DIRECTORY}/token के पथ के तहत चल रही सेवा के सामने आ जाता है, जहां ${CREDENTIALS_DIRECTORY} सिस्टमडी द्वारा पॉप्युलेट किया गया एक पर्यावरण चर है। आपके एप्लिकेशन कोड को लाइब्रेरी या कोड में उपयोग के लिए इस तरह से परिभाषित प्रत्येक रहस्य को पढ़ना चाहिए जिसके लिए एपीआई टोकन या पासवर्ड जैसे सुरक्षित मानों की आवश्यकता होती है। उदाहरण के लिए, पायथन में, आप इस रहस्य को निम्नलिखित कोड के साथ पढ़ सकते हैं:

 from os import environ from pathlib import Path credentials_dir = Path(environ["CREDENTIALS_DIRECTORY"]) with Path(credentials_dir / "token").open() as f: secret = f.read().strip()

फिर आप किसी भी पुस्तकालय के लिए अपने रहस्य की सामग्री के साथ secret चर का उपयोग कर सकते हैं जिसके लिए एपीआई टोकन या पासवर्ड की आवश्यकता हो सकती है।

पुनरारंभ

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

Restart= systemd विकल्प नियंत्रित करता है कि क्या systemd स्वचालित रूप से चल रही प्रक्रिया को पुनरारंभ करेगा। इस विकल्प के लिए कई संभावित मूल्य हैं, लेकिन बुनियादी सेवाओं के लिए, अधिकांश उपयोग के मामलों को पूरा करने के लिए on-failure सेटिंग उपयुक्त है।

ऑटो-रीस्टार्ट को कॉन्फ़िगर करते समय विचार करने के लिए एक और सेटिंग RestartSec RestartSec= विकल्प है, जो यह तय करती है कि सिस्टम फिर से सेवा शुरू करने से पहले कितनी देर तक इंतजार करेगा। आमतौर पर, इस मान को टाइट लूप में विफल सेवाओं को फिर से शुरू करने और प्रक्रियाओं को फिर से शुरू करने में संभावित रूप से बहुत अधिक सीपीयू समय खर्च करने से बचने के लिए अनुकूलित किया जाना चाहिए। एक छोटा मान जो बहुत लंबे समय तक प्रतीक्षा नहीं करता जैसे 5s आमतौर पर पर्याप्त होता है।

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

 StartLimitBurst=5 StartLimitIntervalSec=10

यह एक इकाई को 10 सेकंड की अवधि में अधिकतम 5 बार स्टार्ट करने का प्रयास करने की अनुमति देगा। यदि कॉन्फ़िगर की गई सेवा 10 सेकंड की अवधि के भीतर छठी बार शुरू करने का प्रयास करती है, तो सिस्टमडी यूनिट को पुनरारंभ करने का प्रयास बंद कर देगा और इसके बजाय इसे failed के रूप में चिह्नित करेगा।

इन सभी सेटिंग्स को मिलाकर, आप स्वचालित पुनरारंभ को कॉन्फ़िगर करने के लिए अपनी .service इकाई के लिए निम्नलिखित विकल्प शामिल कर सकते हैं:

 [Unit] StartLimitBurst=5 StartLimitIntervalSec=10 [Service] Restart=on-failure RestartSec=1

यदि सेवा विफल हो जाती है तो यह कॉन्फ़िगरेशन एक सेवा को पुनरारंभ कर देगा - यानी, यह अप्रत्याशित रूप से बाहर निकल जाता है, जैसे गैर-शून्य निकास कोड के साथ - एक सेकंड के इंतजार के बाद और यदि यह पाठ्यक्रम के दौरान पांच से अधिक बार शुरू करने का प्रयास करता है तो सेवा को पुनरारंभ करने का प्रयास करना बंद कर देगा। 10 सेकंड का.

सेवा सख्त करना

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

आप समान प्रतिबंधों को लागू करने के लिए कई सिस्टमडी विकल्पों को सक्षम कर सकते हैं जो अप्रत्याशित कार्यभार व्यवहार के खिलाफ अंतर्निहित होस्ट की रक्षा करने में मदद कर सकते हैं:

• ProtectSystem= /boot और /usr जैसे संवेदनशील सिस्टम पथों तक लेखन पहुंच को प्रतिबंधित कर सकता है। इस विकल्प के लिए दस्तावेज़ीकरण सभी उपलब्ध विकल्पों की गणना करता है, लेकिन आम तौर पर बोलते हुए, इस विकल्प को full पर सेट करना इन फ़ाइल सिस्टम पथों की सुरक्षा के लिए एक उचित डिफ़ॉल्ट है।
• ProtectHome= /home , /root , और /run/user निर्देशिकाओं को केवल read-only सेटिंग के साथ पढ़ने के लिए सेट कर सकता है या, जब true पर सेट किया जाता है, तो उन्हें खाली निर्देशिकाओं के रूप में सेवा के फ़ाइल सिस्टम में माउंट कर सकता है। जब तक आपके एप्लिकेशन को इन निर्देशिकाओं तक पहुंचने की विशिष्ट आवश्यकता न हो, इसे true पर सेट करने से उन निर्देशिकाओं तक अवैध पहुंच के खिलाफ सिस्टम को सुरक्षित रूप से सख्त किया जा सकता है।
• PrivateTmp= कॉन्फ़िगर की गई सेवा के लिए एक अलग /tmp और /var/tmp बनाए रखता है ताकि इस सेवा और अन्य प्रक्रियाओं के लिए अस्थायी फ़ाइलें निजी रहें। जब तक प्रक्रियाओं के लिए अस्थायी फ़ाइलों के माध्यम से जानकारी साझा करने का कोई अनिवार्य कारण न हो, इसे सक्षम करना एक उपयोगी विकल्प है।
• NoNewPrivileges= किसी सेवा को सख्त करने का एक और सुरक्षित और सीधा तरीका है, यह सुनिश्चित करके कि निष्पादित प्रक्रिया उसके विशेषाधिकारों को बढ़ा नहीं सकती है। यदि आप अन्य सख्त विकल्पों का उपयोग करने की क्षमता के बारे में अनिश्चित हैं, तो इसे सक्षम करना आम तौर पर सबसे कम समस्याग्रस्त में से एक है।

Systemd.exec के लिए मैनुअल पेज सेवाओं जैसे निष्पादन योग्य कार्यभार पर लागू होने वाले विभिन्न विकल्पों की खोज के लिए एक सहायक संसाधन है।

अग्रिम पठन

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