ដំណើរការប្រព័ន្ធនៅក្នុងធុង

យើងបានតាមដានប្រធានបទនៃការប្រើប្រាស់ systemd នៅក្នុង containers អស់រយៈពេលជាយូរមកហើយ។ ត្រលប់ទៅឆ្នាំ 2014 វិស្វករសន្តិសុខរបស់យើង Daniel Walsh បានសរសេរអត្ថបទមួយ។ កំពុងដំណើរការប្រព័ន្ធនៅក្នុង Docker Containerហើយពីរបីឆ្នាំក្រោយមក - មួយទៀតដែលត្រូវបានគេហៅថា កំពុងដំណើរការប្រព័ន្ធនៅក្នុងកុងតឺន័រដែលមិនមានសិទ្ធិក្នុង​នោះ​លោក​បញ្ជាក់​ថា ស្ថានការណ៍​មិន​បាន​ធូរស្រាល​ច្រើន​ទេ។ ជាពិសេសគាត់បានសរសេរថា "ជាអកុសលសូម្បីតែពីរឆ្នាំក្រោយមកប្រសិនបើអ្នក google "ប្រព័ន្ធ Docker" រឿងដំបូងដែលកើតឡើងគឺអត្ថបទចាស់របស់គាត់ដូចគ្នា។ ដូច្នេះ​ដល់​ពេល​ត្រូវ​ផ្លាស់​ប្តូរ​អ្វី​មួយ​ហើយ»។ លើសពីនេះទៀតយើងបាននិយាយរួចហើយ ជម្លោះរវាង Docker និងអ្នកអភិវឌ្ឍន៍ប្រព័ន្ធ.

នៅក្នុងអត្ថបទនេះយើងនឹងបង្ហាញពីអ្វីដែលបានផ្លាស់ប្តូរតាមពេលវេលា និងរបៀបដែល Podman អាចជួយយើងក្នុងបញ្ហានេះ។

មានហេតុផលជាច្រើនដើម្បីដំណើរការប្រព័ន្ធនៅក្នុងកុងតឺន័រ ដូចជា៖

1. ធុងពហុសេវាកម្ម - មនុស្សជាច្រើនចង់ទាញកម្មវិធីពហុសេវាកម្មរបស់ពួកគេចេញពីម៉ាស៊ីននិម្មិត ហើយដំណើរការវានៅក្នុងកុងតឺន័រ។ ជាការពិតណាស់ វាជាការប្រសើរជាងក្នុងការបំបែកកម្មវិធីបែបនេះទៅជាសេវាកម្មមីក្រូ ប៉ុន្តែមិនមែនគ្រប់គ្នាដឹងពីរបៀបធ្វើវានៅឡើយទេ ឬគ្រាន់តែមិនមានពេលនោះទេ។ ដូច្នេះ ការដំណើរការកម្មវិធីដូចជាសេវាកម្មដែលដំណើរការដោយ systemd ពីឯកតាឯកសារគឺមានន័យល្អឥតខ្ចោះ។
2. ឯកសារឯកតាប្រព័ន្ធ - កម្មវិធីភាគច្រើនដែលដំណើរការនៅខាងក្នុងកុងតឺន័រត្រូវបានបង្កើតឡើងពីកូដដែលពីមុនបានដំណើរការលើម៉ាស៊ីននិម្មិត ឬរូបវន្ត។ កម្មវិធីទាំងនេះមានឯកតាឯកសារដែលត្រូវបានសរសេរសម្រាប់កម្មវិធីទាំងនេះ ហើយយល់ពីរបៀបដែលពួកគេគួរតែត្រូវបានចាប់ផ្តើម។ ដូច្នេះវានៅតែប្រសើរជាងក្នុងការចាប់ផ្តើមសេវាកម្មដោយប្រើវិធីសាស្ត្រដែលបានគាំទ្រ ជាជាងការលួចចូលសេវាកម្ម init ផ្ទាល់ខ្លួនរបស់អ្នក។
3. Systemd គឺជាកម្មវិធីគ្រប់គ្រងដំណើរការ។ វាគ្រប់គ្រងសេវាកម្ម (បិទ ចាប់ផ្តើមសេវាកម្មឡើងវិញ ឬសម្លាប់ដំណើរការ zombie) ប្រសើរជាងឧបករណ៍ផ្សេងទៀត។

ដែលបាននិយាយថាមានហេតុផលជាច្រើនដែលមិនដំណើរការប្រព័ន្ធនៅក្នុងកុងតឺន័រ។ ចំណុចសំខាន់មួយគឺថា systemd/journald គ្រប់គ្រងលទ្ធផលនៃកុងតឺន័រ និងឧបករណ៍ដូចជា Kubernetes ឬ អូលហ្វីស រំពឹងថាធុងនឹងសរសេរកំណត់ហេតុដោយផ្ទាល់ទៅ stdout និង stderr ។ ដូច្នេះហើយ ប្រសិនបើអ្នកនឹងគ្រប់គ្រងកុងតឺន័រតាមរយៈឧបករណ៍ orchestration ដូចអ្វីដែលបានរៀបរាប់ខាងលើ អ្នកគួរតែពិចារណាឱ្យបានហ្មត់ចត់អំពីការប្រើប្រាស់ធុងដែលផ្អែកលើប្រព័ន្ធ។ លើសពីនេះទៀត អ្នកអភិវឌ្ឍន៍ Docker និង Moby ជារឿយៗត្រូវបានប្រឆាំងយ៉ាងខ្លាំងចំពោះការប្រើប្រាស់ systemd នៅក្នុង containers។

ការមកដល់របស់ Podman

យើង​រីករាយ​ក្នុង​ការ​រាយការណ៍​ថា ទីបំផុត​ស្ថានការណ៍​បាន​ឈាន​ទៅ​មុខ​ហើយ។ ក្រុមដែលទទួលខុសត្រូវក្នុងការដំណើរការកុងតឺន័រនៅ Red Hat បានសម្រេចចិត្តអភិវឌ្ឍ ម៉ាស៊ីនកុងតឺន័រផ្ទាល់ខ្លួនរបស់អ្នក។. គាត់បានទទួលឈ្មោះមួយ។ ផូមេន និងផ្តល់នូវចំណុចប្រទាក់បន្ទាត់ពាក្យបញ្ជាដូចគ្នា (CLI) ដូច Docker ។ ហើយពាក្យបញ្ជា Docker ស្ទើរតែទាំងអស់អាចត្រូវបានប្រើនៅក្នុង Podman តាមរបៀបដូចគ្នា។ ជាញឹកញាប់យើងធ្វើសិក្ខាសាលា ដែលឥឡូវនេះត្រូវបានគេហៅថា ការផ្លាស់ប្តូរ Docker ទៅ Podmanហើយស្លាយដំបូងហៅការសរសេរ៖ alias docker=podman ។

មនុស្សជាច្រើនធ្វើបែបនេះ។

Podman របស់ខ្ញុំ និងខ្ញុំមិនមានវិធីប្រឆាំងនឹងធុងដែលផ្អែកលើប្រព័ន្ធទេ។ យ៉ាងណាមិញ Systemd គឺជាប្រព័ន្ធរងលីនុចដែលប្រើជាទូទៅបំផុត ហើយការមិនអនុញ្ញាតឱ្យវាដំណើរការបានត្រឹមត្រូវនៅក្នុងកុងតឺន័រ មានន័យថាការមិនអើពើពីរបៀបដែលមនុស្សរាប់ពាន់នាក់ទម្លាប់ប្រើប្រាស់កុងតឺន័រដែលកំពុងដំណើរការ។

Podman ដឹងពីអ្វីដែលត្រូវធ្វើដើម្បីធ្វើឱ្យប្រព័ន្ធដំណើរការបានត្រឹមត្រូវនៅក្នុងកុងតឺន័រ។ វាត្រូវការអ្វីៗដូចជា ម៉ោន tmpfs នៅលើ /run និង /tmp ។ នាងចូលចិត្តបើកបរិយាកាស "containerized" ហើយរំពឹងថាមានការអនុញ្ញាតក្នុងការសរសេរទៅកាន់ផ្នែករបស់នាងនៃ cgroup directory និងទៅកាន់ /var/log/journald folder។

នៅពេលអ្នកចាប់ផ្តើមកុងតឺន័រដែលពាក្យបញ្ជាដំបូងគឺ init ឬ systemd Podman កំណត់រចនាសម្ព័ន្ធ tmpfs និង Cgroups ដោយស្វ័យប្រវត្តិ ដើម្បីធានាថា systemd ចាប់ផ្តើមដោយគ្មានបញ្ហា។ ដើម្បីទប់ស្កាត់របៀបបើកដំណើរការដោយស្វ័យប្រវត្តិនេះ សូមប្រើជម្រើស --systemd=false ។ សូមចំណាំថា Podman ប្រើតែរបៀប systemd នៅពេលដែលវាឃើញថាវាត្រូវការដំណើរការពាក្យបញ្ជា systemd ឬ init ។

នេះជាការដកស្រង់ចេញពីសៀវភៅណែនាំ៖

បុរស podman រត់
...

–systemd=true|false

កំពុងដំណើរការកុងតឺន័រនៅក្នុងរបៀបប្រព័ន្ធ។ បានបើកដំណើរការតាមលំនាំដើម។

ប្រសិនបើអ្នកដំណើរការពាក្យបញ្ជា systemd ឬ init នៅខាងក្នុងកុងតឺន័រ Podman នឹងកំណត់រចនាសម្ព័ន្ធចំណុចម៉ោន tmpfs នៅក្នុងថតខាងក្រោម៖

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

ផងដែរ សញ្ញាបញ្ឈប់លំនាំដើមនឹងមាន SIGRTMIN+3។

ទាំងអស់នេះអនុញ្ញាតឱ្យ systemd ដំណើរការនៅក្នុងធុងបិទជិតដោយគ្មានការកែប្រែណាមួយឡើយ។

ចំណាំ៖ systemd ព្យាយាមសរសេរទៅប្រព័ន្ធឯកសារ cgroup ។ ទោះយ៉ាងណាក៏ដោយ SELinux រារាំងកុងតឺន័រពីការធ្វើវាតាមលំនាំដើម។ ដើម្បីបើកការសរសេរ សូមបើកប៉ារ៉ាម៉ែត្រ boolean container_manage_cgroup៖

setsebool -P container_manage_cgroup ពិត

ឥឡូវនេះសូមក្រឡេកមើលអ្វីដែល Dockerfile មើលទៅដូចសម្រាប់ការដំណើរការ systemd នៅក្នុងកុងតឺន័រដោយប្រើ Podman:

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

ចំណាំ៖ កុំសាកល្បងវានៅលើ Docker! នៅទីនោះអ្នកនៅតែត្រូវរាំជាមួយ tambourine ដើម្បីបើកដំណើរការកុងតឺន័រប្រភេទទាំងនេះតាមរយៈដេមិន។ (វាល និងកញ្ចប់បន្ថែមនឹងត្រូវបានទាមទារដើម្បីធ្វើឱ្យវាដំណើរការយ៉ាងរលូននៅក្នុង Docker ឬវានឹងចាំបាច់ត្រូវដំណើរការនៅក្នុងកុងតឺន័រដែលមានសិទ្ធិ។ សម្រាប់ព័ត៌មានលម្អិតសូមមើល អត្ថបទ.)

របស់ល្អមួយចំនួនទៀតអំពី Podman និង systemd

Podman ដំណើរការបានល្អជាង Docker នៅក្នុងឯកសារឯកតាប្រព័ន្ធ

ប្រសិនបើកុងតឺន័រត្រូវចាប់ផ្តើមនៅពេលប្រព័ន្ធចាប់ផ្តើម នោះអ្នកអាចបញ្ចូលពាក្យបញ្ជា Podman ដែលសមស្របទៅក្នុងឯកសារឯកតាប្រព័ន្ធ ដែលនឹងចាប់ផ្តើមសេវាកម្ម និងត្រួតពិនិត្យវា។ Podman ប្រើគំរូ fork-exec ស្តង់ដារ។ ម្យ៉ាងវិញទៀត ដំណើរការកុងតឺន័រគឺជាកូននៃដំណើរការ Podman ដូច្នេះប្រព័ន្ធអាចត្រួតពិនិត្យពួកវាយ៉ាងងាយស្រួល។

Docker ប្រើគំរូម៉ាស៊ីនភ្ញៀវ ហើយពាក្យបញ្ជា Docker CLI ក៏អាចត្រូវបានដាក់ដោយផ្ទាល់នៅក្នុងឯកតាឯកសារផងដែរ។ ទោះយ៉ាងណាក៏ដោយ នៅពេលដែលម៉ាស៊ីនភ្ញៀវ Docker ភ្ជាប់ទៅដេមិន Docker វា (ម៉ាស៊ីនភ្ញៀវ) ក្លាយជាដំណើរការមួយផ្សេងទៀតដែលគ្រប់គ្រង stdin និង stdout ។ នៅក្នុងវេន systemd មិនមានគំនិតអំពីការតភ្ជាប់រវាងម៉ាស៊ីនភ្ញៀវ Docker និងកុងតឺន័រដែលដំណើរការក្រោមការគ្រប់គ្រងរបស់ដេមិន Docker ទេ ដូច្នេះហើយនៅក្នុងគំរូនេះ ប្រព័ន្ធដែលបង្កើតជាមូលដ្ឋានមិនអាចត្រួតពិនិត្យសេវាកម្មបានទេ។

កំពុងធ្វើឱ្យប្រព័ន្ធដំណើរការតាមរយៈរន្ធ

Podman គ្រប់គ្រងការធ្វើឱ្យសកម្មតាមរយៈរន្ធបានត្រឹមត្រូវ។ ដោយសារតែ Podman ប្រើគំរូ fork-exec វាអាចបញ្ជូនរន្ធទៅដំណើរការកុងតឺន័រកូនរបស់វា។ Docker មិន​អាច​ធ្វើ​ដូច្នេះ​បាន​ទេ​ព្រោះ​វា​ប្រើ​គំរូ​ម៉ាស៊ីន​ភ្ញៀវ​-ម៉ាស៊ីន​បម្រើ។

សេវា varlink ដែល Podman ប្រើដើម្បីទំនាក់ទំនងជាមួយអតិថិជនពីចម្ងាយទៅកាន់កុងតឺន័រគឺពិតជាត្រូវបានធ្វើឱ្យសកម្មតាមរយៈរន្ធមួយ។ កញ្ចប់ cockpit-podman ដែលសរសេរក្នុង Node.js និងជាផ្នែកមួយនៃគម្រោង cockpit អនុញ្ញាតឱ្យមនុស្សធ្វើអន្តរកម្មជាមួយធុង Podman តាមរយៈចំណុចប្រទាក់គេហទំព័រ។ ដេមិនគេហទំព័រដែលកំពុងដំណើរការកាប៊ីនយន្ដហោះ-ផតមែន ផ្ញើសារទៅកាន់រន្ធ varlink ដែលប្រព័ន្ធស្តាប់តាមប្រព័ន្ធ។ បន្ទាប់មក Systemd ដំណើរការកម្មវិធី Podman ដើម្បីទទួលសារ និងចាប់ផ្តើមគ្រប់គ្រងកុងតឺន័រ។ ការធ្វើឱ្យសកម្មប្រព័ន្ធនៅលើរន្ធមួយលុបបំបាត់តម្រូវការសម្រាប់ដេមិនដែលកំពុងដំណើរការឥតឈប់ឈរនៅពេលអនុវត្ត APIs ពីចម្ងាយ។

លើសពីនេះទៀត យើងកំពុងបង្កើតម៉ាស៊ីនភ្ញៀវ Podman មួយផ្សេងទៀតដែលហៅថា podman-remote ដែលអនុវត្ត Podman CLI ដូចគ្នា ប៉ុន្តែហៅ varlink ដើម្បីដំណើរការកុងតឺន័រ។ Podman-remote អាចដំណើរការនៅលើកំពូលនៃវគ្គ SSH ដែលអនុញ្ញាតឱ្យអ្នកធ្វើអន្តរកម្មដោយសុវត្ថិភាពជាមួយកុងតឺន័រនៅលើម៉ាស៊ីនផ្សេងៗគ្នា។ យូរៗទៅ យើងមានគម្រោងបើកដំណើរការ podman-remote ដើម្បីគាំទ្រ MacOS និង Windows រួមជាមួយនឹង Linux ដូច្នេះអ្នកអភិវឌ្ឍន៍នៅលើវេទិកាទាំងនោះអាចដំណើរការម៉ាស៊ីននិម្មិត Linux ជាមួយ Podman varlink កំពុងដំណើរការ និងមានបទពិសោធន៍ពេញលេញដែលកុងតឺន័រកំពុងដំណើរការនៅលើម៉ាស៊ីនមូលដ្ឋាន។

SD_NOTIFY

Systemd អនុញ្ញាត​ឱ្យ​អ្នក​ពន្យារ​ការ​បើក​ដំណើរការ​សេវាកម្ម​ជំនួយ​រហូត​ដល់​សេវា​កុងតឺន័រ​ដែល​ពួក​គេ​តម្រូវ​ឱ្យ​ចាប់​ផ្តើម។ Podman អាចបញ្ជូនរន្ធ SD_NOTIFY ទៅកាន់សេវាកុងតឺន័រ ដើម្បីឱ្យសេវាកម្មជូនដំណឹងដល់ប្រព័ន្ធថាវារួចរាល់ដើម្បីដំណើរការ។ ហើយម្តងទៀត Docker ដែលប្រើគំរូម៉ាស៊ីនភ្ញៀវមិនអាចធ្វើដូចនេះបានទេ។

នៅក្នុងផែនការ

យើងគ្រោងនឹងបន្ថែមពាក្យបញ្ជា podman បង្កើត CONTAINERID ដែលបង្កើតប្រព័ន្ធ ដែលនឹងបង្កើតឯកសារឯកតាប្រព័ន្ធ ដើម្បីគ្រប់គ្រងកុងតឺន័រជាក់លាក់ដែលបានបញ្ជាក់។ វា​គួរ​តែ​ដំណើរការ​ទាំង​របៀប​ជា root និង​គ្មាន​ឫស​សម្រាប់​ធុង​ដែល​មិន​មាន​សិទ្ធិ។ យើងថែមទាំងបានឃើញសំណើសម្រាប់ពេលដំណើរការ OCI-compatible systemd-nspawn ផងដែរ។

សេចក្តីសន្និដ្ឋាន

ការដំណើរការប្រព័ន្ធនៅក្នុងកុងតឺន័រគឺជាតម្រូវការដែលអាចយល់បាន។ ហើយអរគុណដល់ Podman ទីបំផុតយើងមានកុងតឺន័រដំណើរការដែលមិនមានជម្លោះជាមួយប្រព័ន្ធ ប៉ុន្តែធ្វើឱ្យវាងាយស្រួលប្រើ។

ប្រភព: www.habr.com