ایک کنٹینر میں سسٹمڈ چل رہا ہے۔

ہم ایک طویل عرصے سے کنٹینرز میں systemd استعمال کرنے کے موضوع کی پیروی کر رہے ہیں۔ 2014 میں، ہمارے سیکورٹی انجینئر ڈینیئل والش نے ایک مضمون لکھا ڈوکر کنٹینر کے اندر سسٹمڈ چل رہا ہے۔، اور چند سال بعد - ایک اور، جسے بلایا گیا تھا۔ غیر مراعات یافتہ کنٹینر میں سسٹمڈ چل رہا ہے۔جس میں انہوں نے کہا کہ صورتحال زیادہ بہتر نہیں ہوئی۔ خاص طور پر، انہوں نے لکھا کہ "بدقسمتی سے، یہاں تک کہ دو سال بعد، اگر آپ "ڈوکر سسٹم" گوگل کرتے ہیں، تو سب سے پہلے جو چیز سامنے آتی ہے وہ ان کا وہی پرانا مضمون ہے۔ تو یہ کچھ بدلنے کا وقت ہے۔" اس کے علاوہ، ہم نے پہلے ہی بات کی ہے ڈوکر اور سسٹمڈ ڈویلپرز کے مابین تنازعہ.

اس آرٹیکل میں ہم دکھائیں گے کہ وقت کے ساتھ ساتھ کیا تبدیلی آئی ہے اور پوڈ مین اس معاملے میں ہماری مدد کیسے کر سکتا ہے۔

کنٹینر کے اندر سسٹمڈ چلانے کی بہت سی وجوہات ہیں، جیسے:

1. ملٹی سروس کنٹینرز - بہت سے لوگ اپنی ملٹی سروس ایپلیکیشنز کو ورچوئل مشینوں سے نکال کر کنٹینرز میں چلانا چاہتے ہیں۔ یقیناً بہتر ہوگا کہ ایسی ایپلی کیشنز کو مائیکرو سروسز میں توڑ دیا جائے، لیکن ہر کوئی نہیں جانتا کہ یہ کیسے کرنا ہے یا اس کے پاس وقت نہیں ہے۔ لہذا، یونٹ فائلوں سے systemd کے ذریعہ شروع کردہ خدمات کے طور پر اس طرح کی ایپلی کیشنز کو چلانا بالکل معنی خیز ہے۔
2. سسٹمڈ یونٹ فائلیں۔ - کنٹینرز کے اندر چلنے والی زیادہ تر ایپلیکیشنز کوڈ سے بنائی گئی ہیں جو پہلے ورچوئل یا فزیکل مشینوں پر چلتی تھیں۔ ان ایپلی کیشنز میں ایک یونٹ فائل ہے جو ان ایپلی کیشنز کے لیے لکھی گئی تھی اور یہ سمجھتی ہے کہ انہیں کیسے لانچ کیا جانا چاہیے۔ لہٰذا یہ اب بھی بہتر ہے کہ آپ اپنی ابتدائی سروس کو ہیک کرنے کے بجائے معاون طریقوں کا استعمال کرتے ہوئے خدمات شروع کریں۔
3. Systemd ایک پروسیس مینیجر ہے۔ یہ کسی بھی دوسرے ٹول سے بہتر سروس مینجمنٹ (شٹ ڈاؤن، سروسز کو دوبارہ شروع کرتا ہے، یا زومبی عمل کو ختم کرتا ہے) انجام دیتا ہے۔

اس نے کہا، کنٹینرز میں سسٹمڈ نہ چلانے کی بہت سی وجوہات ہیں۔ سب سے اہم یہ ہے کہ systemd/journald کنٹینرز اور ٹولز جیسے آؤٹ پٹ کو کنٹرول کرتا ہے۔ Kubernetes یا اوپن شفٹ۔ توقع ہے کہ کنٹینرز لاگ ان کو براہ راست stdout اور stderr پر لکھیں گے۔ لہذا، اگر آپ اوپر بیان کردہ آرکیسٹریشن ٹولز کے ذریعے کنٹینرز کا انتظام کرنے جا رہے ہیں، تو آپ کو سنجیدگی سے سسٹمڈ بیسڈ کنٹینرز کے استعمال پر غور کرنا چاہیے۔ مزید برآں، ڈوکر اور موبی ڈویلپرز اکثر کنٹینرز میں سسٹمڈ استعمال کرنے کے سخت مخالف رہے ہیں۔

پوڈ مین کی آمد

ہمیں یہ اطلاع دیتے ہوئے خوشی ہو رہی ہے کہ صورتحال آخر کار آگے بڑھ گئی ہے۔ Red Hat میں کنٹینرز چلانے کی ذمہ دار ٹیم نے تیار کرنے کا فیصلہ کیا۔ آپ کا اپنا کنٹینر انجن. اسے ایک نام ملا پوڈ مین اور ڈوکر جیسا کمانڈ لائن انٹرفیس (CLI) پیش کرتا ہے۔ اور تقریباً تمام ڈوکر کمانڈز کو پوڈ مین میں اسی طرح استعمال کیا جا سکتا ہے۔ ہم اکثر سیمینار منعقد کرتے ہیں، جنہیں اب کہا جاتا ہے۔ ڈوکر کو پوڈ مین میں تبدیل کرنا، اور پہلی ہی سلائیڈ لکھنے کا مطالبہ کرتی ہے: عرف ڈاکر = پوڈ مین۔

بہت سے لوگ ایسا کرتے ہیں۔

میرا پوڈ مین اور میں کسی بھی طرح سے سسٹمڈ بیسڈ کنٹینرز کے خلاف نہیں ہیں۔ بہر حال، Systemd سب سے زیادہ استعمال ہونے والا Linux init سب سسٹم ہے، اور اسے کنٹینرز میں ٹھیک سے کام کرنے کی اجازت نہ دینے کا مطلب یہ نظر انداز کرنا ہے کہ کس طرح ہزاروں لوگ کنٹینرز چلانے کے عادی ہیں۔

پوڈ مین جانتا ہے کہ کنٹینر میں سسٹمڈ کو صحیح طریقے سے کام کرنے کے لیے کیا کرنا ہے۔ اسے /رن اور /tmp پر tmpfs کو بڑھانے جیسی چیزوں کی ضرورت ہے۔ وہ "کنٹینرائزڈ" ماحول کو فعال کرنا پسند کرتی ہے اور اسے cgroup ڈائریکٹری کے اپنے حصے اور /var/log/journald فولڈر میں لکھنے کی اجازت کی توقع ہے۔

جب آپ ایک کنٹینر شروع کرتے ہیں جس میں پہلی کمانڈ init یا systemd ہوتی ہے، Podman خود بخود tmpfs اور Cgroups کو ترتیب دیتا ہے تاکہ یہ یقینی بنایا جا سکے کہ systemd بغیر کسی پریشانی کے شروع ہوتا ہے۔ اس آٹو لانچ موڈ کو بلاک کرنے کے لیے، --systemd=false آپشن استعمال کریں۔ براہ کرم نوٹ کریں کہ پوڈ مین صرف سسٹمڈ موڈ استعمال کرتا ہے جب وہ دیکھتا ہے کہ اسے سسٹمڈ یا انیٹ کمانڈ چلانے کی ضرورت ہے۔

یہاں دستی سے ایک اقتباس ہے:

آدمی پوڈ مین دوڑتا ہے۔
...

-systemd=true|false

سسٹمڈ موڈ میں کنٹینر چلانا۔ بطور ڈیفالٹ فعال۔

اگر آپ کسی کنٹینر کے اندر systemd یا init کمانڈ چلاتے ہیں، تو Podman مندرجہ ذیل ڈائریکٹریوں میں tmpfs ماؤنٹ پوائنٹس کو ترتیب دے گا۔

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

نیز ڈیفالٹ اسٹاپ سگنل SIGRTMIN+3 ہوگا۔

یہ سب systemd کو بغیر کسی ترمیم کے بند کنٹینر میں چلانے کی اجازت دیتا ہے۔

نوٹ: systemd سی گروپ فائل سسٹم کو لکھنے کی کوشش کرتا ہے۔ تاہم، SELinux کنٹینرز کو بطور ڈیفالٹ ایسا کرنے سے روکتا ہے۔ تحریر کو فعال کرنے کے لیے، کنٹینر_منیج_سی گروپ بولین پیرامیٹر کو فعال کریں:

setsebool -P کنٹینر_مینیج_سی گروپ سچ ہے۔

اب دیکھیں کہ پوڈ مین کا استعمال کرتے ہوئے کنٹینر میں سسٹمڈ چلانے کے لئے ڈاکر فائل کیسا لگتا ہے:

# 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 کو کہتے ہیں کہ systemd کو 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>

نوٹ: اسے ڈوکر پر نہ آزمائیں! وہاں آپ کو اب بھی ڈیمن کے ذریعے اس قسم کے کنٹینرز کو لانچ کرنے کے لیے دف کے ساتھ رقص کرنے کی ضرورت ہے۔ (اضافی فیلڈز اور پیکجز کی ضرورت ہوگی تاکہ یہ سب ڈوکر میں بغیر کسی رکاوٹ کے کام کر سکے، یا اسے مراعات یافتہ کنٹینر میں چلانے کی ضرورت ہوگی۔ تفصیلات کے لیے، دیکھیں آرٹیکل.)

پوڈ مین اور سسٹمڈ کے بارے میں کچھ اور عمدہ چیزیں

پوڈ مین سسٹمڈ یونٹ فائلوں میں ڈوکر سے بہتر کام کرتا ہے۔

اگر سسٹم کے بوٹ ہونے پر کنٹینرز کو شروع کرنے کی ضرورت ہے، تو آپ آسانی سے سسٹمڈ یونٹ فائل میں مناسب پوڈ مین کمانڈز داخل کر سکتے ہیں، جو سروس شروع کرے گی اور اس کی نگرانی کرے گی۔ پوڈ مین معیاری فورک-ایگزیک ماڈل کا استعمال کرتا ہے۔ دوسرے لفظوں میں، کنٹینر کے عمل پوڈ مین کے عمل کے بچے ہیں، لہذا systemd آسانی سے ان کی نگرانی کر سکتا ہے۔

Docker ایک کلائنٹ سرور ماڈل استعمال کرتا ہے، اور Docker CLI کمانڈز کو بھی براہ راست یونٹ فائل میں رکھا جا سکتا ہے۔ تاہم، ایک بار جب ڈوکر کلائنٹ ڈوکر ڈیمون سے جڑ جاتا ہے، تو یہ (کلائنٹ) stdin اور stdout کو سنبھالنے کا ایک اور عمل بن جاتا ہے۔ بدلے میں، systemd کو Docker کلائنٹ اور کنٹینر کے درمیان تعلق کے بارے میں کوئی اندازہ نہیں ہے جو Docker ڈیمون کے کنٹرول میں چلتا ہے، اور اس وجہ سے، اس ماڈل کے اندر، systemd بنیادی طور پر سروس کی نگرانی نہیں کر سکتا۔

ساکٹ کے ذریعے systemd کو چالو کرنا

پوڈ مین ساکٹ کے ذریعے ایکٹیویشن کو صحیح طریقے سے ہینڈل کرتا ہے۔ چونکہ پوڈ مین فورک-ایگزیک ماڈل کا استعمال کرتا ہے، اس لیے یہ ساکٹ کو اپنے چائلڈ کنٹینر کے عمل میں آگے بڑھا سکتا ہے۔ ڈوکر ایسا نہیں کرسکتا کیونکہ یہ کلائنٹ سرور ماڈل استعمال کرتا ہے۔

ورلنک سروس جو پوڈ مین دور دراز کے کلائنٹس کے ساتھ کنٹینرز تک بات چیت کرنے کے لیے استعمال کرتا ہے دراصل ساکٹ کے ذریعے چالو کیا جاتا ہے۔ Cockpit-podman پیکیج، Node.js میں لکھا گیا اور کاک پٹ پروجیکٹ کا حصہ، لوگوں کو ویب انٹرفیس کے ذریعے Podman کنٹینرز کے ساتھ بات چیت کرنے کی اجازت دیتا ہے۔ کاک پٹ پوڈ مین چلانے والا ویب ڈیمون ورلنک ساکٹ پر پیغامات بھیجتا ہے جسے سسٹم سنتا ہے۔ سسٹمڈ پھر پیغامات وصول کرنے اور کنٹینرز کا انتظام شروع کرنے کے لیے پوڈ مین پروگرام کو چالو کرتا ہے۔ ساکٹ پر سسٹم ڈی کو چالو کرنے سے ریموٹ APIs کو لاگو کرتے وقت مسلسل چلنے والے ڈیمون کی ضرورت ختم ہوجاتی ہے۔

مزید برآں، ہم ایک اور Podman کلائنٹ تیار کر رہے ہیں جسے podman-remote کہتے ہیں، جو اسی Podman CLI کو لاگو کرتا ہے لیکن کنٹینرز کو چلانے کے لیے varlink کو کال کرتا ہے۔ Podman-remote SSH سیشنز کے اوپر چل سکتا ہے، جس سے آپ مختلف مشینوں پر کنٹینرز کے ساتھ محفوظ طریقے سے بات چیت کر سکتے ہیں۔ وقت گزرنے کے ساتھ، ہم لینکس کے ساتھ ساتھ MacOS اور Windows کو سپورٹ کرنے کے لیے podman-remote کو فعال کرنے کا ارادہ رکھتے ہیں، تاکہ ان پلیٹ فارمز پر ڈویلپرز Podman varlink کے ساتھ Linux کی ورچوئل مشین چلا سکیں اور انہیں پورا تجربہ ہو کہ کنٹینرز مقامی مشین پر چل رہے ہیں۔

SD_NOTIFY

Systemd آپ کو معاون خدمات کے آغاز کو اس وقت تک موخر کرنے کی اجازت دیتا ہے جب تک کہ کنٹینرائزڈ سروس شروع نہ ہو جائے۔ پوڈ مین SD_NOTIFY ساکٹ کو کنٹینرائزڈ سروس کو بھیج سکتا ہے تاکہ سروس سسٹم کو مطلع کرے کہ یہ کام کرنے کے لیے تیار ہے۔ اور ایک بار پھر، Docker، جو کلائنٹ-سرور ماڈل استعمال کرتا ہے، ایسا نہیں کر سکتا۔

منصوبوں میں

ہم podman generate systemd CONTAINERID کمانڈ شامل کرنے کا ارادہ رکھتے ہیں، جو مخصوص کنٹینر کو منظم کرنے کے لیے ایک systemd یونٹ فائل بنائے گا۔ یہ غیر مراعات یافتہ کنٹینرز کے لیے روٹ اور روٹ لیس دونوں طریقوں میں کام کرے۔ ہم نے OCI-مطابقت مند systemd-nspawn رن ٹائم کی درخواست بھی دیکھی ہے۔

حاصل يہ ہوا

کنٹینر میں سسٹمڈ چلانا ایک قابل فہم ضرورت ہے۔ اور Podman کا شکریہ، آخر کار ہمارے پاس ایک کنٹینر رن ٹائم ہے جو systemd سے متصادم نہیں ہے، لیکن اسے استعمال میں آسان بناتا ہے۔

ماخذ: www.habr.com