هڪ ڪنٽينر ۾ هلندڙ سسٽم

اسان هڪ ڊگهي وقت تائين ڪنٽينرز ۾ سسٽم ڊي استعمال ڪرڻ جي موضوع تي عمل ڪيو آهي. 2014 ۾ واپس، اسان جي سيڪيورٽي انجنيئر ڊينيئل والش هڪ مضمون لکيو ڊاکر ڪنٽينر اندر هلندڙ سسٽم، ۽ ڪجهه سالن کان پوء - ٻيو، جنهن کي سڏيو ويندو هو هڪ غير استحقاق واري ڪنٽينر ۾ هلندڙ سسٽمجنهن ۾ هن چيو ته حالتون گهڻو بهتر نه ٿيون آهن. خاص طور تي، هن لکيو ته ”بدقسمتي سان، ٻن سالن کان پوءِ به، جيڪڏهن توهان گوگل ڪريو ٿا ”ڊاڪر سسٽم“، ته پهرين شيءِ جيڪا سامهون اچي ٿي اها آهي سندس ساڳيو پراڻو مضمون. تنهنڪري اهو ڪجهه تبديل ڪرڻ جو وقت آهي. " ان کان علاوه، اسان اڳ ۾ ئي ڳالهايو آهي Docker ۽ systemd ڊولپرز جي وچ ۾ تڪرار.

هن آرٽيڪل ۾ اسين ڏيکارينداسين ته ڇا وقت سان تبديل ٿي چڪو آهي ۽ ڪيئن پوڊمن هن معاملي ۾ اسان جي مدد ڪري سگهي ٿي.

ڪنٽينر اندر سسٽم کي هلائڻ جا ڪيترائي سبب آهن، جهڙوڪ:

1. Multiservice containers - گھڻا ماڻھو پنھنجي ملٽي سروس ايپليڪيشنن کي ورچوئل مشينن مان ڪڍڻ چاھين ٿا ۽ انھن کي ڪنٽينر ۾ ھلائين ٿا. اهو بهتر ٿيندو، يقينا، اهڙين ايپليڪيشنن کي مائڪرو سروسز ۾ ٽوڙڻ لاء، پر هرڪو اهو ڄاڻي ٿو ته اهو ڪيئن ڪجي يا صرف وقت نه آهي. تنهن ڪري، اهڙين ايپليڪيشنن کي هلائڻ جهڙوڪ سسٽم طرفان شروع ڪيل خدمتون يونٽ فائلن مان مڪمل احساس پيدا ڪري ٿي.
2. Systemd يونٽ فائلون - اڪثر ايپليڪيشنون جيڪي ڪنٽينرز جي اندر هلنديون آهن اهي ڪوڊ مان ٺهيل هونديون آهن جيڪي اڳي ورچوئل يا فزيڪل مشينن تي هلنديون هيون. انهن ايپليڪيشنن ۾ هڪ يونٽ فائل آهي جيڪا انهن ايپليڪيشنن لاءِ لکيل هئي ۽ سمجهي ٿي ته انهن کي ڪيئن شروع ڪيو وڃي. تنهن ڪري اهو اڃا به بهتر آهي ته توهان جي پنهنجي شروعاتي خدمت کي هيڪ ڪرڻ جي بجاءِ ، سپورٽ ٿيل طريقا استعمال ڪندي خدمتون شروع ڪرڻ.
3. Systemd هڪ پروسيس مينيجر آهي. اهو خدمتن کي منظم ڪري ٿو (بند ڪري ٿو، خدمتون ٻيهر شروع ڪري ٿو، يا زومبي عمل کي ماريندو آهي) ڪنهن ٻئي اوزار کان بهتر.

اهو چيو ته، ڪنٽينرز ۾ سسٽم نه هلائڻ جا ڪيترائي سبب آهن. مکيه هڪ آهي ته systemd/journald ڪنٽرول ڪنٽينرز جي پيداوار، ۽ اوزار وانگر ڪوبنيٿس يا اوپن شفٽ توقع رکو ته ڪنٽينرز لاگ لکندا سڌو سنئون stdout ۽ stderr ڏانهن. تنهن ڪري، جيڪڏهن توهان ڪنٽينرز کي منظم ڪرڻ وارا آهيو آرڪيسٽريشن ٽولز ذريعي جيئن مٿي ذڪر ڪيل آهن، توهان کي سنجيدگي سان غور ڪرڻ گهرجي سسٽم تي ٻڌل ڪنٽينرز استعمال ڪرڻ. اضافي طور تي، ڊاکر ۽ موبي ڊولپرز اڪثر ڪري سختي سان ڪنٽينرز ۾ سسٽم ڊي استعمال ڪرڻ جي مخالفت ڪئي وئي آهي.

پوڊمن جو اچڻ

اسان کي رپورٽ ڪرڻ ۾ خوشي ٿي آهي ته صورتحال آخرڪار اڳتي وڌي وئي آهي. Red Hat تي ڪنٽينر هلائڻ جي ذميوار ٽيم ترقي ڪرڻ جو فيصلو ڪيو توهان جي پنهنجي ڪنٽينر انجڻ. هن کي هڪ نالو مليو پوڊيم ۽ پيش ڪري ٿو ساڳيو ڪمانڊ لائن انٽرفيس (CLI) Docker وانگر. ۽ لڳ ڀڳ سڀ Docker حڪم Podman ۾ ساڳيء طرح استعمال ڪري سگهجي ٿو. اسان اڪثر سيمينار منعقد ڪندا آهيون، جن کي هاڻي سڏيو ويندو آهي Docker کي Podman کي تبديل ڪرڻ، ۽ پهرين سلائڊ لکڻ لاءِ سڏين ٿا: عرف ڊڪر = پوڊمين.

ڪيترائي ماڻھو ائين ڪندا آھن.

منهنجو پوڊمين ۽ مان ڪنهن به طريقي سان سسٽم تي ٻڌل ڪنٽينرز جي خلاف نه آهيون. آخرڪار، Systemd سڀ کان عام استعمال ٿيل لينڪس init سبسسٽم آهي، ۽ ان کي ڪنٽينرز ۾ صحيح ڪم ڪرڻ جي اجازت نه ڏيڻ جو مطلب آهي نظر انداز ڪرڻ ته ڪيئن هزارين ماڻهو ڪنٽينر هلائڻ جا عادي آهن.

پوڊمان ڄاڻي ٿو ته سسٽم کي صحيح طريقي سان ڪنٽينر ۾ ڪم ڪرڻ لاءِ ڇا ڪجي. ان کي شين جي ضرورت آهي جيئن tmpfs کي /رن ۽ /tmp تي چڙهڻ. هوءَ پسند ڪري ٿي ته ”ڪنٽينرائزڊ“ ماحول کي فعال ڪيو وڃي ۽ سي گروپ ڊاريڪٽري جي پنهنجي حصي ۽ /var/log/journald فولڊر ڏانهن لکڻ جي اجازت جي توقع رکي ٿي.

جڏهن توهان هڪ ڪنٽينر شروع ڪيو جنهن ۾ پهريون حڪم init يا systemd آهي، Podman خودڪار طريقي سان ترتيب ڏئي ٿو tmpfs ۽ Cgroups انهي کي يقيني بڻائڻ لاءِ ته سسٽم ڊي بغير ڪنهن پريشاني جي شروع ٿئي. ھن آٽو لانچ موڊ کي بلاڪ ڪرڻ لاءِ، استعمال ڪريو --systemd=false آپشن. مهرباني ڪري نوٽ ڪريو ته پوڊمان صرف سسٽم ڊي موڊ استعمال ڪندو آهي جڏهن اهو ڏسي ٿو ته ان کي هلائڻ جي ضرورت آهي systemd يا init حڪم.

هتي دستياب مان هڪ اقتباس آهي:

مرد پوڊمان ڊوڙندو
...

-systemd=سچو|غلط

سسٽم ڊي موڊ ۾ ڪنٽينر کي هلائڻ. ڊفالٽ طور تي چالو ڪيو ويو.

جيڪڏهن توهان هڪ ڪنٽينر اندر سسٽم ڊي يا انٽ ڪمانڊ هلائيندا آهيو، پوڊمن هيٺ ڏنل ڊائريڪٽرن ۾ tmpfs ماؤنٽ پوائنٽن کي ترتيب ڏيندو:

/رن، /رن/تالا، /tmp، /sys/fs/cgroup/systemd، /var/lib/journal

پڻ ڊفالٽ اسٽاپ سگنل هوندو SIGRTMIN+3.

هي سڀ سسٽم ڊي کي بغير ڪنهن به ترميم جي بند ڪنٽينر ۾ هلائڻ جي اجازت ڏئي ٿو.

نوٽ: systemd ڪوشش ڪري ٿو لکڻ لاءِ cgroup فائل سسٽم. بهرحال، SELinux ڪنٽينرز کي ڊفالٽ طور ائين ڪرڻ کان روڪي ٿو. لکڻ کي چالو ڪرڻ لاء، ڪنٽينر_منيج_cgroup بوليان پيراميٽر کي فعال ڪريو:

setsebool -P container_manage_cgroup صحيح

ھاڻي ڏسو ته ڊاڪر فائل ڇا ڏسڻ ۾ ايندي آھي سسٽم ڊي کي هلائڻ لاءِ ڪنٽينر ۾ پوڊمن استعمال ڪندي:

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

نوٽ: ڊڪر تي هن جي ڪوشش نه ڪريو! اتي توھان کي اڃا تائين ھڪڙي ٽمبر سان ناچ ڪرڻ جي ضرورت آھي ھن قسم جي ڪنٽينرز کي ڊيمن ذريعي لانچ ڪرڻ لاءِ. (اضافي شعبن ۽ پيڪيجز جي ضرورت پوندي ته هي سڀ ڪم ڊاکر ۾ بيحد ڪم ڪرڻ لاءِ، يا ان کي هڪ مراعات يافته ڪنٽينر ۾ هلائڻ جي ضرورت پوندي. تفصيل لاءِ، ڏسو مضمون.)

Podman ۽ systemd بابت ڪجھ وڌيڪ سٺيون شيون

پوڊمن سسٽم ڊي يونٽ فائلن ۾ ڊڪر کان بهتر ڪم ڪري ٿو

جيڪڏهن ڪنٽينرز کي شروع ڪرڻ جي ضرورت آهي جڏهن سسٽم بوٽن، پوء توهان صرف سسٽم ڊي يونٽ فائل ۾ مناسب پوڊمن ڪمانڊ داخل ڪري سگهو ٿا، جيڪو خدمت شروع ڪندو ۽ ان جي نگراني ڪندو. پوڊمان معياري فورڪ-ايڪسڪس ماڊل استعمال ڪري ٿو. ٻين لفظن ۾، ڪنٽينر پروسيس پوڊمن پروسيس جا ٻار آهن، تنهنڪري سسٽم انهن کي آساني سان مانيٽر ڪري سگهي ٿو.

Docker هڪ ڪلائنٽ-سرور ماڊل استعمال ڪري ٿو، ۽ Docker CLI حڪم پڻ سڌو سنئون يونٽ فائل ۾ رکيل آهن. جڏهن ته، هڪ دفعو ڊاڪر ڪلائنٽ ڊاڪر ڊيمن سان ڳنڍيندو آهي، اهو (ڪلائنٽ) صرف هڪ ٻيو عمل بڻجي ويندو آهي اسٽين ۽ اسٽڊ آئوٽ. موڙ ۾، سسٽمڊ کي ڊاکر ڪلائنٽ ۽ ڪنٽينر جي وچ ۾ ڪنيڪشن بابت ڪا ڄاڻ ناهي جيڪا ڊڪر ڊيمن جي ڪنٽرول هيٺ هلندي آهي، ۽ تنهن ڪري، هن ماڊل جي اندر، سسٽمڊ بنيادي طور تي خدمت جي نگراني نٿو ڪري سگهي.

سسٽم ڊي کي ساکٽ ذريعي چالو ڪرڻ

پوڊمان ساکٽ ذريعي چالو ڪرڻ کي صحيح طريقي سان سنڀاليندو آهي. ڇاڪاڻ ته پوڊمان فورڪ-ايڪسڪس ماڊل استعمال ڪري ٿو، اهو ساکٽ کي اڳتي وڌائي سگھي ٿو ان جي ٻار ڪنٽينر جي عملن ڏانهن. Docker اهو نٿو ڪري سگهي ڇاڪاڻ ته اهو استعمال ڪري ٿو ڪلائنٽ-سرور ماڊل.

ورلنڪ سروس جيڪا پوڊمن استعمال ڪري ٿي ريموٽ ڪلائنٽ سان ڪنٽينرز سان رابطو ڪرڻ لاءِ اصل ۾ هڪ ساکٽ ذريعي چالو ڪئي وئي آهي. Cockpit-podman پيڪيج، Node.js ۾ لکيل آهي ۽ ڪاڪپٽ پروجيڪٽ جو حصو، ماڻهن کي اجازت ڏئي ٿو پوڊمين ڪنٽينرز سان ويب انٽرفيس ذريعي رابطو ڪري. ويب ڊيمون هلائيندڙ ڪاڪپٽ-پڊمين پيغام موڪلي ٿو هڪ ورلنڪ ساکٽ تي جيڪو سسٽم ٻڌي ٿو. Systemd وري چالو ڪري ٿو Podman پروگرام پيغام وصول ڪرڻ ۽ ڪنٽينرز کي منظم ڪرڻ شروع ڪرڻ لاءِ. هڪ ساکٽ تي سسٽم ڊي کي چالو ڪرڻ هڪ مسلسل هلندڙ ڊيمن جي ضرورت کي ختم ڪري ٿو جڏهن ريموٽ APIs کي لاڳو ڪرڻ.

اضافي طور تي، اسان ترقي ڪري رهيا آهيون هڪ ٻيو Podman ڪلائنٽ جنهن کي سڏيو ويندو آهي پوڊمان-ريموٽ، جيڪو ساڳيو Podman CLI لاڳو ڪري ٿو پر ڪنٽينرز کي هلائڻ لاء varlink سڏي ٿو. Podman-remote SSH سيشن جي چوٽي تي هلائي سگھي ٿو، توهان کي مختلف مشينن تي ڪنٽينرز سان محفوظ طور تي رابطو ڪرڻ جي اجازت ڏئي ٿي. وقت سان گڏ، اسان لينڪس سان گڏ MacOS ۽ ونڊوز کي سپورٽ ڪرڻ لاءِ پوڊمين-ريموٽ کي فعال ڪرڻ جو منصوبو ٺاهيو، ته جيئن انهن پليٽ فارمن تي ڊولپرز هڪ لينڪس ورچوئل مشين هلائي سگهن Podman varlink سان هلندڙ ۽ مڪمل تجربو آهي ته ڪنٽينر مقامي مشين تي هلندا آهن.

SD_NOTIFY

Systemd توهان کي اجازت ڏئي ٿو ته معاون خدمتن جي شروعات کي ملتوي ڪرڻ جي جيستائين ڪنٽينر ٿيل خدمت انهن کي شروع ڪرڻ جي ضرورت آهي. پوڊمين اڳتي ڪري سگھي ٿو SD_NOTIFY ساکٽ کي ڪنٽينرائزڊ سروس ڏانهن ته جيئن خدمت سسٽم کي اطلاع ڏئي ته اهو هلائڻ لاءِ تيار آهي. ۽ ٻيهر، ڊڪر، جيڪو استعمال ڪري ٿو ڪلائنٽ-سرور ماڊل، اهو نٿو ڪري سگهي.

منصوبن ۾

اسان ڪمانڊ شامل ڪرڻ جي رٿابندي ڪريون ٿا podman generate systemd CONTAINERID، جيڪو ھڪڙي مخصوص ڪنٽينر کي منظم ڪرڻ لاءِ سسٽم ڊي يونٽ فائل ٺاھيندو. اهو ڪم ڪرڻ گهرجي ٻنهي روٽ ۽ روٽ بيس موڊس لاءِ غير امتيازي ڪنٽينرز لاءِ. اسان هڪ OCI-مطابقت رکندڙ systemd-nspawn رن ٽائم جي درخواست به ڏٺي آهي.

ٿڪل

هڪ ڪنٽينر ۾ سسٽم کي هلائڻ هڪ سمجھڻ جي ضرورت آهي. ۽ پوڊمن جي مهرباني، اسان وٽ آخرڪار هڪ ڪنٽينر رن ٽائم آهي جيڪو سسٽم سان تڪرار نٿو ڪري، پر استعمال ڪرڻ آسان بڻائي ٿو.

جو ذريعو: www.habr.com