उबंटू 16.04 (नई एलटीएस रिलीज) की रिहाई के बाद, सिस्टमड सर्वर पर उपयोग किए जाने वाले सभी प्रमुख लिनक्स वितरणों की वास्तविकता बन गया। इसका मतलब यह है कि आप सिस्टम के उन्नत फीचर्स पर कुछ उपयोक्ता "ओवरबोर्ड" को छोड़ने के लिए जोखिम के बिना ले सकते हैं।

यह पोस्ट सिस्टमड का उपयोग करके बहु-टर्मिनल एप्लिकेशन को कैसे लागू किया जाए, इसके बारे में है।

सार: कई सेवा उदाहरणों ("श्रमिकों" के कार्यान्वयन) को लॉन्च करने के लिए सेवा टेम्पलेट्स और लक्ष्यों का उपयोग करना। PartOf निर्भरता। इकाइयों के [स्थापित] अनुभाग के बारे में थोड़ा।

प्रविष्टि

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

लेकिन इस दृष्टिकोण के लिए एक "पर्यवेक्षक" की आवश्यकता होती है, जो प्रतियों को लॉन्च करने के लिए जिम्मेदार होता है, उनकी स्थिति की निगरानी करता है, त्रुटियों को रोकता है, किसी भी तरह के स्टॉप / रीलोड आदि के साथ समाप्त होता है। तुच्छता के साथ, यह पूरी तरह से तुच्छ कार्य नहीं है, बारीकियों से भरा हुआ है (उदाहरण के लिए, यदि श्रमिकों में से एक को TASK_UNINTERRUPTIBLE में मिला या SIGSTOP प्राप्त हुआ, तो समस्याएँ तब पैदा हो सकती हैं जब एक बहुत अच्छी तरह से लिखे गए माता-पिता के साथ पुनरारंभ नहीं होता है)।

एक पर्यवेक्षक के बिना शुरू करने का विकल्प है, लेकिन इस मामले में, पुनः लोड / पुनरारंभ कार्य प्रशासक को स्थानांतरित कर दिया जाता है। "प्रति कोर एक प्रक्रिया" मॉडल के साथ, 24-कोर सर्वर पर एक सेवा को फिर से शुरू करना स्वचालन के लिए एक उम्मीदवार बन जाता है, जिसके बदले सभी समान SIGSTOP और अन्य जटिल बारीकियों को संसाधित करने की आवश्यकता होती है।

समस्या का एक समाधान सामान्य लक्ष्य पर निर्भरता के साथ सिस्टमड सर्विस टेम्प्लेट का उपयोग करना है।

सिद्धांत

टेम्पलेट्स

systemd सेवाओं को लॉन्च करने के लिए "टेम्प्लेट" का समर्थन करता है। ये टेम्पलेट एक पैरामीटर को स्वीकार करते हैं जो तब कमांड लाइन के तर्कों (मैन systemd.service) में कहीं भी डाला जा सकता है। पैरामीटर को सेवा नाम में '@' प्रतीक के माध्यम से पारित किया जाता है। % @ या% I द्वारा एन्कोडेड '@' के बाद का हिस्सा (लेकिन बिंदु से पहले) को 'उदाहरण का नाम' कहा जाता है। मापदंडों की एक पूरी सूची www.freedesktop.org/software/systemd/man/systemd.unit.html#Spidifiers है । सेवा नाम में '@' की उपस्थिति (डॉट से पहले) इंगित करती है कि यह एक टेम्पलेट है।

आइए सरलतम टेम्प्लेट लिखने का प्रयास करें:

/etc/systemd/system/foobar-worker@.service

 [यूनिट]
 वर्णन = फ़ोबार संख्या% I
 [सेवा]
 प्रकार = सरल
 ExecStart = / bin / नींद 3600% I

और इनमें से कुछ चलाएं:

 systemctl शुरू फ़ॉबर-वर्कर @ 1
 systemctl शुरू फ़ॉबर-वर्कर @ 2
 systemctl शुरू फ़ॉबर-वर्कर @ 300

हम देखते हैं:

 ps aux | grep नींद
 रूट 13313 0.0 0.0 8516 748?  एसएस 17:29 0:00 / बिन / नींद 3600 1
 रूट 13317 0.0 0.0 8516 804?  एसएस 17:29 0:00 / बिन / नींद 3600 2
 रूट 13321 0.0 0.0 8516 764?  एसएस 17:29 0:00 / बिन / नींद 3600 300

अब हम किसी तरह इन सभी को सामान्य तरीके से शुरू करना चाहते हैं। इसके लिए लक्ष्य हैं।

Target'y

लक्ष्य एक सिस्टम यूनिट है जो कुछ भी नहीं करता है, लेकिन एक निर्भरता तत्व के रूप में इस्तेमाल किया जा सकता है (लक्ष्य कई सेवाओं पर निर्भर कर सकता है, या सेवाएं लक्ष्य पर निर्भर हो सकती हैं, जो सेवाओं पर भी निर्भर करती हैं)।

लक्ष्य का एक्सटेंशन .target है।

आइए हमारा सरलतम लक्ष्य लिखें:
vim /etc/systemd/system/foobar.target

 [यूनिट]
 Wants=foobar-worker@1.service foobar-worker@2.service
 Wants=foobar-worker@300.service

(.service पर ध्यान देना, यह आवश्यक है!)
'वांट्स' के बारे में हम कुछ कम बात करते हैं।

अब हम एक ही समय में सभी तीन फोबोर-वर्कर्स को चला सकते हैं:
systemctl start foobar.target
(लक्ष्य पर ध्यान - .service के मामले में इसे छोड़ा जा सकता है, .get के मामले में - नहीं)।

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

पर निर्भर करता है

सिस्टमड निर्भरता का एक व्यापक सेट प्रदान करता है कि हम क्या चाहते हैं। हम इस सूची से 'पार्टऑफ' में रुचि रखते हैं। इससे पहले, हम चाहते थे।
उनके व्यवहार की तुलना करें:
चाहता है (जो हमने उपयोग किया) - उल्लेखित सेवा मुख्य इकाई शुरू होने पर शुरू करने की कोशिश करती है। यदि उल्लिखित सेवा क्रैश हो जाती है या शुरू नहीं हो सकती है, तो यह मुख्य सेवा को प्रभावित नहीं करता है। यदि मुख्य सेवा बंद / पुनरारंभ हो जाती है, तो निर्भरता में उल्लिखित सेवाएं अप्रभावित रहती हैं।
PartOf - यदि उपर्युक्त बंद हो जाता है / पुनरारंभ होता है, तो मुख्य सेवा भी बंद / पुनरारंभ हो जाती है।

बस हमें जो चाहिए।

कार्यकर्ता के विवरण पर निर्भरता जोड़ें:

 <Pre>
 [यूनिट]
 वर्णन = फ़ोबार संख्या% I
 PartOf = foobar.target
 [सेवा]
 प्रकार = सरल
 ExecStart = / bin / नींद 3600% I

वह सब है। यदि हम systemd stop foobar.target बनाते हैं, तो हमारे सभी कर्मचारी बंद हो जाएंगे।

निर्भरता स्थापित करें

सिस्टमड की एक और दिलचस्प विशेषता स्थापित निर्भरता है। Sysv-init में सेवाओं को सक्षम / अक्षम करने की क्षमता थी, लेकिन यह स्पष्ट करना बहुत मुश्किल था कि वहां कैसे सक्षम होना चाहिए। रनलेवल क्या? क्या निर्भरताएँ?

सिस्टमड में, सब कुछ सरल है। जब हम 'सक्षम' कमांड का उपयोग करते हैं, तो सेवा "स्लाईस मैकेनिज्म" (स्लाइस मैकेनिज्म के माध्यम से) के आधार पर होती है, जो कि हम उस "इंस्टॉल" सेक्शन पर निर्भर करते हैं। हमारी सुविधा के लिए, एक निर्भरता वांटेडबी है, जो अर्थ में वांटेड के विपरीत है।

वहाँ कई टन मानक लक्ष्य हैं जिनसे हम चिपक सकते हैं। यहाँ उनमें से कुछ हैं (सभी आदमी हैं systemd.special):
* multi-user.target ("शुरू करने की आवश्यकता" के लिए मानक, sysv-init के लिए अंतिम रनवे के बराबर)।
* default.target - बहु उपयोगकर्ता के लिए उपनाम
* graphical.target - X'ov के लॉन्च का क्षण

मल्टी-user.target पर हुक करते हैं।

नई सामग्री foobar.target:

 [यूनिट]
 Wants=foobar-worker@1.service foobar-worker@2.service
 Wants=foobar-worker@300.service
 [स्थापित]
 WantedBy = बहु-user.target

अब, यदि हम इसे सक्षम करते हैं:

 # systemctl foobar.target सक्षम करें
 बनाया गया सिमलिंक /etc/systemd/system/multi-user.target.wants/foobar.target → /etc/systemd/system/foobar.target।

सब कुछ, हमारी सेवा, कई श्रमिकों से एक साथ मिलकर, एक पूरे के रूप में शुरू / पुनः आरंभ करने के लिए तैयार है, साथ ही यह हमारे कंप्यूटर / सर्वर की शुरुआत में लॉन्च किया जाएगा।