ကွန်တိန်နာထဲမှာ စနစ်တကျ လုပ်ဆောင်နေပါတယ်။

ကျွန်ုပ်တို့သည် ကွန်တိန်နာများတွင် systemd အသုံးပြုခြင်းဆိုင်ရာ ခေါင်းစဉ်ကို လိုက်နာနေသည်မှာ ကြာပါပြီ။ 2014 ခုနှစ်တွင် ကျွန်ုပ်တို့၏လုံခြုံရေးအင်ဂျင်နီယာ Daniel Walsh က ဆောင်းပါးတစ်ပုဒ်ရေးခဲ့သည်။ Docker ကွန်တိန်နာအတွင်း စနစ်ဖြင့် လုပ်ဆောင်ခြင်း။, နှင့်နှစ်အနည်းငယ်အကြာတွင် - နောက်တစ်ခု, ဟုခေါ်ခဲ့သည် အခွင့်ထူးခံမဟုတ်သော ကွန်တိန်နာတွင် စနစ်ဖြင့် လုပ်ဆောင်နေသည်။အခြေအနေတွေ အများကြီး မတိုးတက်သေးဘူးလို့ ပြောပါတယ်။ အထူးသဖြင့်၊ "ကံမကောင်းစွာပဲ၊ နောက်နှစ်နှစ်လောက်ကြာတော့ မင်း google "Docker system" မှာ ပေါ်လာတဲ့ ပထမဆုံးအရာက သူ့ရဲ့ ဆောင်းပါးဟောင်းနဲ့အတူတူပါပဲ။ ဒါဆို တစ်ခုခုကို ပြောင်းလဲဖို့ အချိန်ရောက်ပြီ” နောက်ပြီး ကျွန်တော်တို့ ပြောထားပြီးသားပါ။ Docker နှင့် systemd developer များအကြား ပဋိပက္ခ.

ဤဆောင်းပါးတွင် ကျွန်ုပ်တို့သည် အချိန်နှင့်အမျှ ပြောင်းလဲလာခဲ့ရာနှင့် ဤကိစ္စရပ်တွင် Podman က ကျွန်ုပ်တို့ကို မည်သို့ကူညီပေးနိုင်သည်ကို ပြသပါမည်။

ကွန်တိန်နာအတွင်း systemd လည်ပတ်ရန် အကြောင်းရင်းများစွာရှိသည်၊

1. Multiservice ကွန်တိန်နာများ - လူများစွာသည် ၎င်းတို့၏ ဝန်ဆောင်မှုပေါင်းစုံ အက်ပ်လီကေးရှင်းများကို virtual machine များမှ ဆွဲထုတ်ပြီး ကွန်တိန်နာများတွင် လည်ပတ်လိုကြသည်။ ဤကဲ့သို့သောအပလီကေးရှင်းများကို မိုက်ခရိုဝန်ဆောင်မှုများအဖြစ် ချိုးဖျက်ခြင်းသည် ပိုကောင်းလိမ့်မည်၊ သို့သော် ၎င်းကို မည်သို့လုပ်ဆောင်ရမည်ကို လူတိုင်းမသိသေး သို့မဟုတ် အချိန်မရှိသလောက်ပင် ဖြစ်သည်။ ထို့ကြောင့်၊ ယူနစ်ဖိုင်များမှ systemd မှစတင်သောဝန်ဆောင်မှုများကဲ့သို့ထိုကဲ့သို့သောအပလီကေးရှင်းများကိုလည်ပတ်ခြင်းသည်ပြီးပြည့်စုံသောအဓိပ္ပာယ်ဖြစ်သည်။
2. Systemd Unit ဖိုင်များ - ကွန်တိန်နာအတွင်း လုပ်ဆောင်နေသည့် အပလီကေးရှင်းအများစုသည် ယခင်က virtual သို့မဟုတ် ရုပ်ပိုင်းဆိုင်ရာစက်များတွင် လုပ်ဆောင်ခဲ့သော ကုဒ်များမှ တည်ဆောက်ထားသည်။ ဤအက်ပ်လီကေးရှင်းများတွင် ဤအပလီကေးရှင်းများအတွက် ရေးသားထားသည့် ယူနစ်ဖိုင်တစ်ခုရှိပြီး ၎င်းတို့ကို မည်သို့စတင်သင့်သည်ကို နားလည်သည်။ ထို့ကြောင့် သင့်ကိုယ်ပိုင် init ဝန်ဆောင်မှုကို ဟက်ကင်းလုပ်မည့်အစား ပံ့ပိုးပေးထားသော နည်းလမ်းများကို အသုံးပြု၍ ဝန်ဆောင်မှုများကို စတင်ခြင်းက ပိုကောင်းသေးသည်။
3. Systemd သည် လုပ်ငန်းစဉ်မန်နေဂျာဖြစ်သည်။ ၎င်းသည် အခြားကိရိယာများထက် ဝန်ဆောင်မှုများ (ပိတ်ခြင်း၊ ဝန်ဆောင်မှုများ ပြန်လည်စတင်ခြင်း သို့မဟုတ် ဖုတ်ကောင်လုပ်ငန်းစဉ်များကို သတ်ခြင်း) ကို စီမံခန့်ခွဲသည်။

ဆိုလိုသည်မှာ၊ ကွန်တိန်နာများတွင် systemd မလုပ်ဆောင်ရန်အကြောင်းပြချက်များစွာရှိသည်။ အဓိကအချက်မှာ systemd/journald သည် containers များ၏ output ကို control လုပ်ပြီး tools များကဲ့သို့ဖြစ်သည်။ Kubernetes သို့မဟုတ် openshift ကွန်တိန်နာများသည် stdout နှင့် stderr သို့ တိုက်ရိုက် မှတ်တမ်းရေးရန် မျှော်လင့်သည်။ ထို့ကြောင့်၊ သင်သည် အထက်ဖော်ပြပါကဲ့သို့ စုစည်းမှုကိရိယာများမှတစ်ဆင့် ကွန်တိန်နာများကို စီမံခန့်ခွဲမည်ဆိုပါက၊ systemd-based containers များကို အလေးအနက်ထား စဉ်းစားသင့်သည်။ ထို့အပြင်၊ Docker နှင့် Moby developer များသည် ကွန်တိန်နာများတွင် systemd ကိုအသုံးပြုခြင်းကို မကြာခဏ ပြင်းပြင်းထန်ထန် ဆန့်ကျင်ခဲ့ကြသည်။

Podman ၏ကြွလာခြင်း

အခြေအနေက နောက်ဆုံးမှာ ရှေ့ကို တိုးသွားတယ်လို့ သတင်းရလို့ ဝမ်းသာပါတယ်။ Red Hat တွင် ကွန်တိန်နာများ လည်ပတ်ရန် တာဝန်ရှိသော အဖွဲ့သည် တီထွင်ရန် ဆုံးဖြတ်ခဲ့သည်။ သင်၏ကိုယ်ပိုင်ကွန်တိန်နာအင်ဂျင်. သူနာမည်ရသွားတယ်။ podman Docker ကဲ့သို့တူညီသော command line interface (CLI) ကိုပေးသည်။ Docker command အားလုံးကို Podman တွင် အလားတူနည်းလမ်းဖြင့် အသုံးပြုနိုင်သည်။ ကျွန်ုပ်တို့သည် ယခုခေါ်ဝေါ်သော ဆွေးနွေးပွဲများ ပြုလုပ်လေ့ရှိသည်။ Docker ကို Podman သို့ပြောင်းခြင်း။နှင့် ပထမဆလိုက်သည် စာရေးရန် တောင်းဆိုသည်- alias docker=podman။

လူတော်တော်များများက ဒီလိုလုပ်ကြတယ်။

ကျွန်ုပ်၏ Podman နှင့် ကျွန်ုပ်သည် စနစ်အခြေခံကွန်တိန်နာများကို မည်သို့မျှ မဆန့်ကျင်ပါ။ နောက်ဆုံးအနေနှင့်၊ Systemd သည် အသုံးအများဆုံး Linux init subsystem ဖြစ်ပြီး ၎င်းကို containers များတွင် ကောင်းစွာအလုပ်လုပ်ခွင့်မပြုခြင်းသည် ထောင်ပေါင်းများစွာသောလူများကို ကွန်တိန်နာများလည်ပတ်နေပုံအား လျစ်လျူရှုခြင်းပင်ဖြစ်သည်။

ကွန်တိန်နာတစ်ခုတွင် systemd ကောင်းစွာအလုပ်လုပ်စေရန် Podman သည်ဘာလုပ်ရမည်ကိုသိသည်။ ၎င်းသည် /run နှင့် /tmp တွင် tmpfs တပ်ဆင်ခြင်းကဲ့သို့သော အရာများ လိုအပ်သည်။ သူမသည် "containerized" ပတ်ဝန်းကျင်ကို ဖွင့်ထားရတာကို နှစ်သက်ပြီး cgroup directory ၏ တစ်စိတ်တစ်ပိုင်းနှင့် /var/log/journald folder သို့ စာရေးခွင့်များကို မျှော်လင့်ထားသည်။

ပထမဆုံး command ကို init သို့မဟုတ် systemd ဖြစ်သည့် container တစ်ခုကို သင်စတင်သောအခါ၊ Podman သည် systemd ကို ပြဿနာမရှိဘဲ စတင်ကြောင်းသေချာစေရန် Podman သည် tmpfs နှင့် Cgroups ကို အလိုအလျောက် configure လုပ်ပါသည်။ ဤအလိုအလျောက်စတင်ခြင်းမုဒ်ကို ပိတ်ဆို့ရန် --systemd=false ရွေးချယ်မှုကို အသုံးပြုပါ။ systemd သို့မဟုတ် init command ကို run ရန်လိုအပ်ကြောင်း Podman သည် systemd mode ကိုသာအသုံးပြုသည်ကို ကျေးဇူးပြု၍ သတိပြုပါ။

ဤသည်မှာ လက်စွဲစာအုပ်မှ ကောက်နုတ်ချက်ဖြစ်သည်။

လူ podman ပြေး
...

–systemd=true|false

စနစ်စနစ်မုဒ်တွင် ကွန်တိန်နာကို လုပ်ဆောင်ခြင်း။ မူရင်းအတိုင်း ဖွင့်ထားသည်။

အကယ်၍ သင်သည် ကွန်တိန်နာတစ်ခုအတွင်း systemd သို့မဟုတ် init command ကို run ပါက၊ Podman သည် အောက်ပါလမ်းညွှန်များတွင် tmpfs mount point များကို configure လုပ်လိမ့်မည်-

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

မူလ ရပ်တန့် အချက်ပြမှုမှာလည်း SIGRTMIN+3 ဖြစ်လိမ့်မည်။

ဤအရာအားလုံးသည် ပြုပြင်မွမ်းမံခြင်းမရှိဘဲ systemd ကို ပိတ်ထားသော ကွန်တိန်နာတွင် လုပ်ဆောင်နိုင်စေပါသည်။

မှတ်ချက်- systemd သည် cgroup ဖိုင်စနစ်သို့ စာရေးရန် ကြိုးစားသည်။ သို့သော်၊ SELinux သည် ကွန်တိန်နာများကို ပုံမှန်အားဖြင့် ၎င်းကိုလုပ်ဆောင်ခြင်းမှ တားဆီးသည်။ စာရေးခြင်းကို ဖွင့်ရန် container_manage_cgroup boolean ဘောင်ကို ဖွင့်ပါ-

setsebool -P container_manage_cgroup မှန်ပါသည်။

ယခု Podman ကိုအသုံးပြုသည့်ကွန်တိန်နာတွင် systemd လုပ်ဆောင်ခြင်းအတွက် Dockerfile သည်မည်သို့ပုံသည်ကိုကြည့်ပါ-

# 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 configuration ကို မွမ်းမံပြင်ဆင်ရန် 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>

မှတ်ချက်- Docker တွင် ၎င်းကို မစမ်းပါနှင့်။ ထိုနေရာတွင် daemon မှတဆင့်ဤကွန်တိန်နာအမျိုးအစားများကိုဖွင့်ရန် tambourine နှင့်ကခုန်ရန်လိုအပ်နေသေးသည်။ (ဤအရာအားလုံးကို Docker တွင် ချောမွေ့စွာလုပ်ဆောင်နိုင်ရန် နောက်ထပ်အကွက်များနှင့် ပက်ကေ့ဂျ်များ လိုအပ်ပါမည်၊ သို့မဟုတ် ၎င်းကို အခွင့်ထူးခံကွန်တိန်နာတစ်ခုတွင် လုပ်ဆောင်ရန် လိုအပ်ပါမည်။ အသေးစိတ်အချက်အလက်များအတွက် ကြည့်ပါ၊ ဆောင်းပါး.)

Podman နှင့် systemd နှင့်ပတ်သက်သော နောက်ထပ်အမိုက်စားအရာများ

Podman သည် systemd ယူနစ်ဖိုင်များတွင် Docker ထက်ပိုမိုကောင်းမွန်သည်။

စနစ်စတင်သောအခါတွင်ကွန်တိန်နာများကိုစတင်ရန်လိုအပ်ပါက၊ ထို့နောက်ဝန်ဆောင်မှုကိုစတင်ပြီးစောင့်ကြည့်မည့် systemd unit ဖိုင်ထဲသို့သင့်လျော်သော Podman အမိန့်များကိုရိုးရှင်းစွာထည့်သွင်းနိုင်သည်။ Podman သည် ပုံမှန် fork-exec မော်ဒယ်ကို အသုံးပြုသည်။ တစ်နည်းဆိုရသော် ကွန်တိန်နာလုပ်ငန်းစဉ်များသည် Podman လုပ်ငန်းစဉ်၏ ကလေးများဖြစ်သည်၊ ထို့ကြောင့် systemd သည် ၎င်းတို့ကို အလွယ်တကူ စောင့်ကြည့်နိုင်သည်။

Docker သည် client-server မော်ဒယ်ကိုအသုံးပြုပြီး Docker CLI အမိန့်များကို ယူနစ်ဖိုင်တစ်ခုတွင် တိုက်ရိုက်ထည့်သွင်းနိုင်သည်။ သို့သော်၊ Docker client သည် Docker daemon သို့ ချိတ်ဆက်သည်နှင့်၊ ၎င်းသည် (ကလိုင်းယင့်) သည် အခြားသော လုပ်ငန်းစဉ်များကို လုပ်ဆောင်နေသည့် stdin နှင့် stdout တစ်ခုသာ ဖြစ်လာသည်။ တစ်ဖန်၊ systemd သည် Docker client နှင့် Docker daemon ၏ထိန်းချုပ်မှုအောက်တွင်လည်ပတ်နေသောကွန်တိန်နာကြားချိတ်ဆက်မှုအကြောင်းမသိသောကြောင့်ဤမော်ဒယ်အတွင်းတွင် systemd သည်အခြေခံအားဖြင့်ဝန်ဆောင်မှုကိုစောင့်ကြည့်လို့မရပါ။

socket မှတဆင့်စနစ်တကျအသက်သွင်းနေသည်။

Podman သည် socket မှတဆင့် activation ကိုမှန်ကန်စွာကိုင်တွယ်သည်။ Podman သည် fork-exec မော်ဒယ်ကို အသုံးပြုသောကြောင့်၊ ၎င်းသည် socket ကို ၎င်း၏ ကလေးကွန်တိန်နာလုပ်ငန်းစဉ်များသို့ ပေးပို့နိုင်သည်။ Docker သည် ကလိုင်းယင့်-ဆာဗာ မော်ဒယ်ကို အသုံးပြုသောကြောင့် ၎င်းကို မလုပ်ဆောင်နိုင်ပါ။

Podman သည် အဝေးထိန်းဖောက်သည်များနှင့် ကွန်တိန်နာများသို့ ဆက်သွယ်ရန်အတွက် အသုံးပြုသည့် varlink ဝန်ဆောင်မှုကို socket မှတဆင့် အမှန်တကယ် အသက်သွင်းထားသည်။ Node.js တွင်ရေးသားထားသော cockpit-podman ပက်ကေ့ဂျ်သည် လူများအား ဝဘ်အင်တာဖေ့စ်မှတဆင့် Podman ကွန်တိန်နာများနှင့် အပြန်အလှန်ဆက်သွယ်နိုင်စေပါသည်။ cockpit-podman လည်ပတ်နေသော web daemon သည် systemd နားထောင်သည့် varlink socket သို့ မက်ဆေ့ချ်များ ပေးပို့သည်။ ထို့နောက် Systemd သည် မက်ဆေ့ချ်များလက်ခံရရှိရန်နှင့် ကွန်တိန်နာများကို စတင်စီမံခန့်ခွဲရန်အတွက် Podman ပရိုဂရမ်ကို အသက်သွင်းသည်။ socket တစ်ခုပေါ်တွင် systemd ကိုအသက်သွင်းခြင်းသည် remote APIs များကိုအကောင်အထည်ဖော်သောအခါတွင်အဆက်မပြတ်လည်ပတ်နေသော daemon လိုအပ်မှုကိုဖယ်ရှားပေးသည်။

ထို့အပြင်၊ ကျွန်ုပ်တို့သည် Podman-remote ဟုခေါ်သော အခြား Podman ဖောက်သည်အား ပြုစုနေသည်၊ ၎င်းသည် တူညီသော Podman CLI ကို အသုံးပြုသော်လည်း ကွန်တိန်နာများလည်ပတ်ရန်အတွက် varlink ကိုခေါ်ဆိုပါသည်။ Podman-remote သည် သင့်အား မတူညီသော စက်များတွင် ကွန်တိန်နာများနှင့် လုံခြုံစွာ အပြန်အလှန်ဆက်သွယ်နိုင်စေမည့် SSH စက်ရှင်များထိပ်တွင် လုပ်ဆောင်နိုင်သည်။ အချိန်ကြာလာသည်နှင့်အမျှ၊ ကျွန်ုပ်တို့သည် Linux နှင့်အတူ MacOS နှင့် Windows တို့ကို ပံ့ပိုးပေးရန်အတွက် podman-remote ကိုဖွင့်ရန်စီစဉ်ထားပြီး၊ သို့မှသာ အဆိုပါပလပ်ဖောင်းများရှိ developer များသည် Podman varlink ဖြင့်လည်ပတ်နေသော Linux virtual machine ကို run နိုင်ပြီး local machine တွင် containers များလည်ပတ်နေသည့်အတွေ့အကြုံအပြည့်ရှိသည်။

SD_NOTIFY

Systemd သည် ၎င်းတို့လိုအပ်သည့် ကွန်တိန်နာဝန်ဆောင်မှုမစတင်မီအထိ အရန်ဝန်ဆောင်မှုများ စတင်ခြင်းကို ရွှေ့ဆိုင်းနိုင်စေပါသည်။ Podman သည် SD_NOTIFY socket ကို ကွန်တိန်နာထည့်ထားသော ဝန်ဆောင်မှုသို့ ပေးပို့နိုင်သည်၊ သို့မှသာ ဝန်ဆောင်မှုသည် systemd ကို လည်ပတ်ရန် အဆင်သင့်ဖြစ်ပြီဟု အကြောင်းကြားပါသည်။ ထို့အပြင်၊ ကလိုင်းယင့်-ဆာဗာ မော်ဒယ်ကို အသုံးပြုသည့် Docker သည် ၎င်းကို မလုပ်နိုင်ပါ။

အစီအစဥ်များတွင်

သတ်မှတ်ထားသော ကွန်တိန်နာကို စီမံခန့်ခွဲရန်အတွက် systemd ယူနစ်ဖိုင်ကို ထုတ်လုပ်မည့် systemd CONTAINERID ဟူသော command podman ကို ထည့်သွင်းရန် ကျွန်ုပ်တို့ စီစဉ်ပါသည်။ ၎င်းသည် အခွင့်ထူးမထားသော ကွန်တိန်နာများအတွက် အမြစ်နှင့် အမြစ်မဲ့မုဒ်နှစ်ခုလုံးတွင် အလုပ်လုပ်သင့်သည်။ OCI-သဟဇာတဖြစ်သော systemd-nspawn runtime အတွက် တောင်းဆိုမှုကိုပင် ကျွန်ုပ်တို့တွေ့ခဲ့ရသည်။

ကောက်ချက်

ကွန်တိန်နာတွင် စနစ်တကျလုပ်ဆောင်ခြင်းသည် နားလည်နိုင်သော လိုအပ်ချက်တစ်ခုဖြစ်သည်။ Podman ၏ကျေးဇူးကြောင့်၊ နောက်ဆုံးတွင် systemd နှင့်မဆန့်ကျင်ဘဲ အသုံးပြုရလွယ်ကူစေသည့် container runtime တစ်ခုရှိသည်။

source: www.habr.com