🥇एक कंटेनर में सिस्टम चलाना

हम लंबे समय से कंटेनरों में सिस्टमडी के उपयोग के विषय पर नज़र रख रहे हैं। 2014 में, हमारे सुरक्षा इंजीनियर डेनियल वॉल्श ने एक लेख लिखा था डॉकर कंटेनर के भीतर सिस्टमडी चलाना, और कुछ साल बाद - दूसरा, जिसे बुलाया गया था एक गैर-विशेषाधिकार प्राप्त कंटेनर में सिस्टमडी चलानाजिसमें उन्होंने कहा कि स्थिति में ज्यादा सुधार नहीं हुआ है. विशेष रूप से, उन्होंने लिखा है कि "दुर्भाग्य से, दो साल बाद भी, यदि आप गूगल पर "डॉकर सिस्टम" खोजते हैं, तो सबसे पहली चीज़ जो सामने आती है वह उनका वही पुराना लेख है। तो अब कुछ बदलने का समय आ गया है।” इसके अलावा, हम पहले ही बात कर चुके हैं डॉकर और सिस्टमड डेवलपर्स के बीच संघर्ष.

इस लेख में हम दिखाएंगे कि समय के साथ क्या बदलाव आया है और पॉडमैन इस मामले में हमारी कैसे मदद कर सकता है।

किसी कंटेनर के अंदर सिस्टमड चलाने के कई कारण हैं, जैसे:

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

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

पॉडमैन का आगमन

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

बहुत से लोग ऐसा करते हैं.

मेरा पॉडमैन और मैं किसी भी तरह से सिस्टमड-आधारित कंटेनरों के खिलाफ नहीं हैं। आख़िरकार, Systemd सबसे अधिक इस्तेमाल किया जाने वाला Linux init सबसिस्टम है, और इसे कंटेनरों में ठीक से काम करने की अनुमति नहीं देने का मतलब यह अनदेखा करना है कि हजारों लोग कंटेनर चलाने के आदी हैं।

पॉडमैन को पता है कि एक कंटेनर में सिस्टमड को ठीक से काम करने के लिए क्या करना है। इसके लिए /run और /tmp पर tmpfs माउंट करने जैसी चीज़ों की आवश्यकता होती है। वह "कंटेनरीकृत" वातावरण को सक्षम करना पसंद करती है और सीग्रुप निर्देशिका के अपने हिस्से और /var/log/journald फ़ोल्डर में लिखने की अनुमति की अपेक्षा करती है।

जब आप एक कंटेनर शुरू करते हैं जिसमें पहला कमांड init या systemd होता है, तो पॉडमैन स्वचालित रूप से tmpfs और Cgroups को कॉन्फ़िगर करता है ताकि यह सुनिश्चित हो सके कि सिस्टमडी बिना किसी समस्या के शुरू हो। इस ऑटो लॉन्च मोड को ब्लॉक करने के लिए --systemd=false विकल्प का उपयोग करें। कृपया ध्यान दें कि पॉडमैन केवल सिस्टमडी मोड का उपयोग करता है जब उसे लगता है कि उसे सिस्टमडी या इनिट कमांड चलाने की आवश्यकता है।

यहां मैनुअल से एक अंश दिया गया है:

मैन पॉडमैन रन
...

–systemd=सत्य|झूठा

सिस्टमडी मोड में एक कंटेनर चलाना। डिफ़ॉल्ट रूप से सक्षम.

यदि आप किसी कंटेनर के अंदर सिस्टमडी या इनिट कमांड चलाते हैं, तो पॉडमैन निम्नलिखित निर्देशिकाओं में tmpfs माउंट पॉइंट को कॉन्फ़िगर करेगा:

/रन, /रन/लॉक, /tmp, /sys/fs/cgroup/systemd, /var/lib/जर्नल

साथ ही डिफ़ॉल्ट स्टॉप सिग्नल SIGRTMIN+3 होगा।

यह सब सिस्टमडी को बिना किसी संशोधन के एक बंद कंटेनर में चलने की अनुमति देता है।

ध्यान दें: systemd cgroup फ़ाइल सिस्टम पर लिखने का प्रयास करता है। हालाँकि, SELinux कंटेनरों को डिफ़ॉल्ट रूप से ऐसा करने से रोकता है। लेखन सक्षम करने के लिए, कंटेनर_मैनेज_सीग्रुप बूलियन पैरामीटर सक्षम करें:

सेट्सबूल -पी कंटेनर_मैनेज_सीग्रुप सत्य

अब देखें कि पॉडमैन का उपयोग करके कंटेनर में सिस्टमडी चलाने के लिए डॉकरफाइल कैसा दिखता है:

# cat Dockerfile

FROM fedora

RUN dnf -y install httpd; dnf clean all; systemctl enable httpd

EXPOSE 80

CMD [ "/sbin/init" ]

बस इतना ही।

अब हम कंटेनर को इकट्ठा करते हैं:

# podman build -t systemd .

हम SELinux को सिस्टमड को Cgroups कॉन्फ़िगरेशन को संशोधित करने की अनुमति देने के लिए कहते हैं:

# setsebool -P container_manage_cgroup true

वैसे, बहुत से लोग इस कदम के बारे में भूल जाते हैं। सौभाग्य से, इसे केवल एक बार करने की आवश्यकता है और सिस्टम को रीबूट करने के बाद सेटिंग सहेज ली जाती है।

अब हम बस कंटेनर शुरू करते हैं:

# podman run -ti -p 80:80 systemd

systemd 239 running in system mode. (+PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=hybrid)

Detected virtualization container-other.

Detected architecture x86-64.

Welcome to Fedora 29 (Container Image)!

Set hostname to <1b51b684bc99>.

Failed to install release agent, ignoring: Read-only file system

File /usr/lib/systemd/system/systemd-journald.service:26 configures an IP firewall (IPAddressDeny=any), but the local system does not support BPF/cgroup based firewalling.

Proceeding WITHOUT firewalling in effect! (This warning is only shown for the first loaded unit using IP firewalling.)

[  OK ] Listening on initctl Compatibility Named Pipe.

[  OK ] Listening on Journal Socket (/dev/log).

[  OK ] Started Forward Password Requests to Wall Directory Watch.

[  OK ] Started Dispatch Password Requests to Console Directory Watch.

[  OK ] Reached target Slices.

…

[  OK ] Started The Apache HTTP Server.

बस, सेवा चालू है और चल रही है:

$ curl localhost

<html  xml_lang="en" lang="en">

…

</html>

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

पॉडमैन और सिस्टमडी के बारे में कुछ और अच्छी बातें

सिस्टमडी यूनिट फाइलों में पॉडमैन डॉकर से बेहतर काम करता है

यदि सिस्टम बूट होने पर कंटेनरों को शुरू करने की आवश्यकता है, तो आप बस सिस्टमडी यूनिट फ़ाइल में उपयुक्त पॉडमैन कमांड डाल सकते हैं, जो सेवा शुरू करेगा और इसकी निगरानी करेगा। पॉडमैन मानक फोर्क-एक्ज़ीक्यूटिव मॉडल का उपयोग करता है। दूसरे शब्दों में, कंटेनर प्रक्रियाएं पॉडमैन प्रक्रिया की संतान हैं, इसलिए सिस्टमडी आसानी से उनकी निगरानी कर सकता है।

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

सॉकेट के माध्यम से सिस्टमडी को सक्रिय करना

पॉडमैन सॉकेट के माध्यम से सक्रियण को सही ढंग से संभालता है। क्योंकि पॉडमैन फोर्क-एक्ज़िक मॉडल का उपयोग करता है, यह सॉकेट को अपने चाइल्ड कंटेनर प्रक्रियाओं में अग्रेषित कर सकता है। डॉकर ऐसा नहीं कर सकता क्योंकि यह क्लाइंट-सर्वर मॉडल का उपयोग करता है।

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

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

SD_सूचित करें

सिस्टमड आपको सहायक सेवाओं के लॉन्च को तब तक स्थगित करने की अनुमति देता है जब तक कि उनके लिए आवश्यक कंटेनरीकृत सेवा शुरू न हो जाए। पॉडमैन SD_NOTIFY सॉकेट को कंटेनरीकृत सेवा में अग्रेषित कर सकता है ताकि सेवा सिस्टमडी को सूचित कर सके कि वह संचालित करने के लिए तैयार है। और फिर, डॉकर, जो क्लाइंट-सर्वर मॉडल का उपयोग करता है, ऐसा नहीं कर सकता।

योजनाओं में

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

निष्कर्ष

एक कंटेनर में सिस्टमड चलाना एक समझने योग्य आवश्यकता है। और पॉडमैन को धन्यवाद, आखिरकार हमारे पास एक कंटेनर रनटाइम है जो सिस्टमडी के साथ संघर्ष नहीं करता है, लेकिन इसे उपयोग करना आसान बनाता है।

स्रोत: www.habr.com

एक कंटेनर में सिस्टमड चलाना