🥇 कन्टेनरमा प्रणाली चलाउँदै

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

यस लेखमा हामी समयको साथ के परिवर्तन भएको छ र पोडम्यानले यस मामिलामा हामीलाई कसरी मद्दत गर्न सक्छ भनेर देखाउनेछौं।

कन्टेनर भित्र systemd चलाउने धेरै कारणहरू छन्, जस्तै:

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

त्यसले भन्यो, कन्टेनरहरूमा प्रणाली चलाउन नपर्ने धेरै कारणहरू छन्। मुख्य एउटा हो कि systemd/journald ले कन्टेनरहरूको आउटपुट, र उपकरणहरू जस्तै नियन्त्रण गर्दछ कुबर्नेट्स वा ओपनशिफ्ट कन्टेनरहरूले stdout र stderr मा सीधै लग लेख्ने अपेक्षा गर्दछ। तसर्थ, यदि तपाइँ माथि उल्लेखित जस्तै अर्केस्ट्रेशन उपकरणहरू मार्फत कन्टेनरहरू व्यवस्थापन गर्न जाँदै हुनुहुन्छ भने, तपाइँले प्रणालीमा आधारित कन्टेनरहरू प्रयोग गर्ने बारे गम्भीरतापूर्वक विचार गर्नुपर्छ। थप रूपमा, डकर र मोबी विकासकर्ताहरू प्राय: कन्टेनरहरूमा systemd प्रयोग गर्न कडा विरोध गर्दै आएका छन्।

पोडम्यानको आगमन

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

धेरैले यो गर्छन्।

मेरो पोडम्यान र म प्रणालीमा आधारित कन्टेनरहरूको विरुद्धमा छैनौं। आखिर, Systemd सबैभन्दा सामान्य रूपमा प्रयोग हुने Linux init सबसिस्टम हो, र यसलाई कन्टेनरहरूमा राम्ररी काम गर्न नदिनुको अर्थ हजारौं मानिसहरू कन्टेनरहरू चलाउन अभ्यस्त छन् भनेर बेवास्ता गर्नु हो।

पोडम्यानलाई कन्टेनरमा प्रणालीगत काम ठीकसँग गर्न के गर्ने भन्ने थाहा छ। यसलाई माउन्ट tmpfs मा /run र /tmp जस्ता चीजहरू चाहिन्छ। उसलाई "कन्टेनराइज्ड" वातावरण सक्षम पारिएको मनपर्छ र cgroup डाइरेक्टरीको आफ्नो भाग र /var/log/journald फोल्डरमा लेख्ने अनुमतिको अपेक्षा गर्दछ।

जब तपाइँ कन्टेनर सुरु गर्नुहुन्छ जसमा पहिलो आदेश init वा systemd छ, Podman ले स्वचालित रूपमा tmpfs र Cgroups कन्फिगर गर्दछ कि systemd समस्या बिना सुरु हुन्छ। यो स्वत: सुरुवात मोड रोक्नको लागि, --systemd=false विकल्प प्रयोग गर्नुहोस्। कृपया ध्यान दिनुहोस् कि पोडम्यानले systemd वा init आदेश चलाउन आवश्यक देख्दा मात्र systemd मोड प्रयोग गर्दछ।

यहाँ म्यानुअल बाट एक अंश छ:

मान्छे पोडम्यान दौड
...

-systemd=true|false

Systemd मोडमा कन्टेनर चलाउँदै। पूर्वनिर्धारित रूपमा सक्षम।

यदि तपाइँ कन्टेनर भित्र systemd वा init आदेश चलाउनुहुन्छ भने, Podman ले निम्न डाइरेक्टरीहरूमा tmpfs माउन्ट बिन्दुहरू कन्फिगर गर्नेछ:

/run, /run/lock, /tmp, /sys/fs/cgroup/systemd, /var/lib/journal

साथै पूर्वनिर्धारित स्टप सिग्नल SIGRTMIN+3 हुनेछ।

यो सबैले systemd लाई कुनै परिमार्जन बिना बन्द कन्टेनरमा चलाउन अनुमति दिन्छ।

नोट: systemd ले cgroup फाइल प्रणालीमा लेख्ने प्रयास गर्छ। यद्यपि, SELinux ले कन्टेनरहरूलाई पूर्वनिर्धारित रूपमा यो गर्नबाट रोक्छ। लेखन सक्षम गर्न, कन्टेनर_म्यानेज_सीग्रुप बुलियन प्यारामिटर सक्षम गर्नुहोस्:

setsebool -P कन्टेनर_manage_cgroup true

अब हेर्नुहोस् डकरफाइल पोडम्यान प्रयोग गरेर कन्टेनरमा systemd चलाउनको लागि कस्तो देखिन्छ:

# 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 कन्फिगरेसन परिमार्जन गर्न systemd लाई अनुमति दिन भन्छौं:

# 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>

नोट: डकरमा यो प्रयास नगर्नुहोस्! त्यहाँ तपाईंले अझै पनि डेमन मार्फत यस प्रकारका कन्टेनरहरू सुरू गर्न खैंबोरिनसँग नाच्नु पर्छ। (अतिरिक्त फिल्डहरू र प्याकेजहरू यो सबै डकरमा निर्बाध रूपमा काम गर्न आवश्यक हुनेछ, वा यसलाई विशेषाधिकार प्राप्त कन्टेनरमा चलाउन आवश्यक हुनेछ। विवरणहरूको लागि, हेर्नुहोस्। लेख.)

Podman र systemd को बारे मा केहि थप राम्रो चीजहरु

पोडम्यानले systemd एकाइ फाइलहरूमा डकर भन्दा राम्रो काम गर्दछ

यदि प्रणाली बुट हुँदा कन्टेनरहरू सुरू गर्न आवश्यक छ भने, त्यसपछि तपाइँ सजिलैसँग उपयुक्त पोडम्यान आदेशहरू systemd एकाइ फाइलमा घुसाउन सक्नुहुन्छ, जसले सेवा सुरु गर्नेछ र यसलाई निगरानी गर्नेछ। Podman मानक फोर्क-exec मोडेल प्रयोग गर्दछ। अर्को शब्दमा, कन्टेनर प्रक्रियाहरू पोडम्यान प्रक्रियाका बच्चाहरू हुन्, त्यसैले systemd ले तिनीहरूलाई सजिलै निगरानी गर्न सक्छ।

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

सकेट मार्फत प्रणाली सक्रिय गर्दै

पोडम्यानले सकेट मार्फत सक्रियतालाई सही रूपमा ह्यान्डल गर्छ। किनभने पोडम्यानले फोर्क-एक्सेक्स मोडेल प्रयोग गर्दछ, यसले सकेटलाई यसको बाल कन्टेनर प्रक्रियाहरूमा फर्वार्ड गर्न सक्छ। डकरले यो गर्न सक्दैन किनभने यसले क्लाइन्ट-सर्भर मोडेल प्रयोग गर्दछ।

पोडम्यानले टाढाका ग्राहकहरूसँग कन्टेनरहरूमा सञ्चार गर्न प्रयोग गर्ने varlink सेवा वास्तवमा सकेट मार्फत सक्रिय हुन्छ। Cockpit-podman प्याकेज, Node.js मा लेखिएको र ककपिट परियोजनाको अंशले मानिसहरूलाई वेब इन्टरफेस मार्फत पोडम्यान कन्टेनरहरूसँग अन्तर्क्रिया गर्न अनुमति दिन्छ। ककपिट-पडम्यान चलिरहेको वेब डेमनले varlink सकेटमा सन्देशहरू पठाउँछ जुन systemd ले सुन्छ। Systemd त्यसपछि सन्देशहरू प्राप्त गर्न र कन्टेनरहरू प्रबन्ध गर्न सुरु गर्न पोडम्यान कार्यक्रम सक्रिय गर्दछ। सकेटमा systemd सक्रिय गर्दा टाढाको API हरू लागू गर्दा निरन्तर चलिरहेको डेमनको आवश्यकता हटाउँछ।

थप रूपमा, हामी पोडम्यान-रिमोट भनिने अर्को पोडम्यान क्लाइन्ट विकास गर्दैछौं, जसले उही पोडम्यान CLI लागू गर्दछ तर कन्टेनरहरू चलाउन varlink कल गर्दछ। पोडम्यान-रिमोट SSH सत्रहरूको शीर्षमा चल्न सक्छ, तपाईंलाई विभिन्न मेसिनहरूमा कन्टेनरहरूसँग सुरक्षित रूपमा अन्तरक्रिया गर्न अनुमति दिन्छ। समय बित्दै जाँदा, हामीले Linux सँगै MacOS र Windows लाई समर्थन गर्न podman-remote सक्षम गर्ने योजना बनायौं, ताकि ती प्लेटफर्महरूमा विकासकर्ताहरूले Podman varlink चलिरहेको Linux भर्चुअल मेसिन चलाउन सकून् र स्थानीय मेसिनमा कन्टेनरहरू चलिरहेको पूर्ण अनुभव पाउन सकून्।

SD_NOTIFY

Systemd ले तपाईंलाई आवश्यक कन्टेनराइज्ड सेवा सुरु नभएसम्म सहायक सेवाहरूको सुरुवातलाई स्थगित गर्न अनुमति दिन्छ। पोडम्यानले SD_NOTIFY सकेटलाई कन्टेनराइज्ड सेवामा फर्वार्ड गर्न सक्छ ताकि सेवाले प्रणालीलाई यो सञ्चालन गर्न तयार छ भनेर सूचित गर्दछ। र फेरि, डकर, जसले क्लाइन्ट-सर्भर मोडेल प्रयोग गर्दछ, यो गर्न सक्दैन।

योजनाहरूमा

हामी कमाण्ड थप्ने योजना गर्छौं podman generate systemd CONTAINERID, जसले निर्दिष्ट कन्टेनर व्यवस्थापन गर्न systemd एकाइ फाइल उत्पन्न गर्नेछ। यसले विशेषाधिकार नभएका कन्टेनरहरूको लागि रूट र रूटलेस मोडहरूमा काम गर्नुपर्छ। हामीले OCI-compatible systemd-nspawn रनटाइमको लागि अनुरोध पनि देखेका छौं।

निष्कर्षमा

कन्टेनरमा प्रणाली चलाउनु एक बुझ्न योग्य आवश्यकता हो। र पोडम्यानलाई धन्यवाद, हामीसँग अन्ततः एउटा कन्टेनर रनटाइम छ जुन systemd सँग विवाद गर्दैन, तर यसलाई प्रयोग गर्न सजिलो बनाउँछ।

स्रोत: www.habr.com

कन्टेनरमा चलिरहेको प्रणाली