ແລ່ນລະບົບໃນຖັງ

ພວກເຮົາໄດ້ປະຕິບັດຕາມຫົວຂໍ້ຂອງການນໍາໃຊ້ systemd ໃນ containers ສໍາລັບເວລາດົນນານ. ກັບໄປໃນປີ 2014, ວິສະວະກອນຄວາມປອດໄພຂອງພວກເຮົາ Daniel Walsh ຂຽນບົດຄວາມ ແລ່ນລະບົບພາຍໃນ Docker Container, ແລະສອງສາມປີຕໍ່ມາ - ອື່ນ, ເຊິ່ງເອີ້ນວ່າ ແລ່ນລະບົບຢູ່ໃນຖັງທີ່ບໍ່ມີສິດທິພິເສດ, ໃນ​ນັ້ນ​ທ່ານ​ໄດ້​ກ່າວ​ວ່າ​ສະ​ຖາ​ນະ​ການ​ບໍ່​ໄດ້​ປັບ​ປຸງ​ຫຼາຍ​. ໂດຍສະເພາະ, ລາວຂຽນວ່າ "ຫນ້າເສຍດາຍ, ເຖິງແມ່ນວ່າສອງປີຕໍ່ມາ, ຖ້າທ່ານ google "ລະບົບ Docker", ສິ່ງທໍາອິດທີ່ເກີດຂື້ນແມ່ນບົດຄວາມເກົ່າຂອງລາວ. ສະນັ້ນມັນເຖິງເວລາທີ່ຈະປ່ຽນແປງບາງສິ່ງບາງຢ່າງ." ນອກຈາກນັ້ນ, ພວກເຮົາໄດ້ສົນທະນາແລ້ວ ຂໍ້ຂັດແຍ່ງລະຫວ່າງ Docker ແລະຜູ້ພັດທະນາລະບົບ.

ໃນບົດຄວາມນີ້ພວກເຮົາຈະສະແດງສິ່ງທີ່ມີການປ່ຽນແປງໃນໄລຍະເວລາແລະວິທີທີ່ Podman ສາມາດຊ່ວຍພວກເຮົາໃນເລື່ອງນີ້.

ມີຫຼາຍເຫດຜົນໃນການດໍາເນີນການ systemd ພາຍໃນ container, ເຊັ່ນ:

1. Multiservice containers – ຫຼາຍຄົນຕ້ອງການດຶງແອັບພລິເຄຊັນຫຼາຍອັນຂອງເຂົາເຈົ້າອອກຈາກເຄື່ອງ virtual ແລະແລ່ນມັນຢູ່ໃນຖັງ. ມັນຈະເປັນການດີກວ່າ, ແນ່ນອນ, ທີ່ຈະທໍາລາຍຄໍາຮ້ອງສະຫມັກດັ່ງກ່າວເຂົ້າໄປໃນ microservices, ແຕ່ບໍ່ແມ່ນທຸກຄົນຮູ້ວິທີເຮັດແນວນີ້ຫຼືພຽງແຕ່ບໍ່ມີເວລາ. ດັ່ງນັ້ນ, ການໃຊ້ແອັບພລິເຄຊັນດັ່ງກ່າວເປັນການບໍລິການທີ່ເປີດຕົວໂດຍ systemd ຈາກໄຟລ໌ຫນ່ວຍນັ້ນເຮັດໃຫ້ຄວາມຮູ້ສຶກທີ່ສົມບູນແບບ.
2. ໄຟລ໌ຫນ່ວຍງານລະບົບ - ແອັບພລິເຄຊັນສ່ວນໃຫຍ່ທີ່ແລ່ນພາຍໃນກ່ອງບັນຈຸແມ່ນສ້າງຂຶ້ນຈາກລະຫັດທີ່ເຄີຍແລ່ນຢູ່ໃນເຄື່ອງ virtual ຫຼືຕົວຈິງ. ແອັບພລິເຄຊັນເຫຼົ່ານີ້ມີໄຟລ໌ຫນ່ວຍງານທີ່ຖືກຂຽນໄວ້ສໍາລັບແອັບພລິເຄຊັນເຫຼົ່ານີ້ແລະເຂົ້າໃຈວ່າພວກເຂົາຄວນຈະຖືກເປີດຕົວແນວໃດ. ສະນັ້ນມັນຍັງດີກວ່າທີ່ຈະເລີ່ມຕົ້ນການບໍລິການໂດຍໃຊ້ວິທີການທີ່ສະຫນັບສະຫນູນ, ແທນທີ່ຈະ hack ການບໍລິການ init ຂອງທ່ານເອງ.
3. Systemd ເປັນຜູ້ຈັດການຂະບວນການ. ມັນຄຸ້ມຄອງການບໍລິການ (ປິດລົງ, ເປີດບໍລິການໃຫມ່, ຫຼືຂ້າຂະບວນການ zombie) ດີກວ່າເຄື່ອງມືອື່ນໆ.

ທີ່ເວົ້າວ່າ, ມີຫຼາຍເຫດຜົນທີ່ຈະບໍ່ດໍາເນີນການ systemd ໃນ containers. ອັນຕົ້ນຕໍແມ່ນວ່າ systemd / journald ຄວບຄຸມຜົນຜະລິດຂອງບັນຈຸ, ແລະເຄື່ອງມືເຊັ່ນ: Kubernetes ຫຼື openshift ຄາດຫວັງວ່າບັນຈຸຈະຂຽນບັນທຶກໂດຍກົງກັບ stdout ແລະ stderr. ດັ່ງນັ້ນ, ຖ້າທ່ານກໍາລັງຈະຈັດການຕູ້ຄອນເທນເນີໂດຍຜ່ານເຄື່ອງມື orchestration ດັ່ງທີ່ໄດ້ກ່າວມາຂ້າງເທິງ, ທ່ານຄວນພິຈາລະນາຢ່າງຈິງຈັງກັບການນໍາໃຊ້ຕູ້ຄອນເທນເນີທີ່ອີງໃສ່ລະບົບ. ນອກຈາກນັ້ນ, ຜູ້ພັດທະນາ Docker ແລະ Moby ມັກຈະຖືກຄັດຄ້ານຢ່າງແຂງແຮງຕໍ່ກັບການໃຊ້ systemd ໃນ containers.

ການມາຂອງ Podman

ພວກເຮົາຍິນດີທີ່ຈະລາຍງານວ່າສະຖານະການໄດ້ກ້າວໄປຂ້າງຫນ້າໃນທີ່ສຸດ. ທີມງານທີ່ຮັບຜິດຊອບສໍາລັບການແລ່ນຕູ້ຄອນເທນເນີຢູ່ Red Hat ຕັດສິນໃຈພັດທະນາ ເຄື່ອງຈັກບັນຈຸຂອງທ່ານເອງ. ລາວໄດ້ຮັບຊື່ podman ແລະສະຫນອງການໂຕ້ຕອບເສັ້ນຄໍາສັ່ງດຽວກັນ (CLI) ເປັນ Docker. ແລະເກືອບທຸກຄໍາສັ່ງ Docker ສາມາດຖືກນໍາໃຊ້ໃນ Podman ໃນທາງດຽວກັນ. ພວກເຮົາມັກຈະດໍາເນີນການສໍາມະນາ, ເຊິ່ງປະຈຸບັນເອີ້ນວ່າ ປ່ຽນ Docker ເປັນ Podman, ແລະສະໄລ້ທໍາອິດຮຽກຮ້ອງໃຫ້ຂຽນ: alias docker=podman.

ຫຼາຍຄົນເຮັດແນວນີ້.

Podman ຂອງຂ້ອຍແລະຂ້ອຍບໍ່ມີວິທີທີ່ຈະຕ້ານກັບ containers ທີ່ອີງໃສ່ລະບົບ. ຫຼັງຈາກທີ່ທັງຫມົດ, Systemd ແມ່ນລະບົບຍ່ອຍ Linux init ທີ່ໃຊ້ທົ່ວໄປທີ່ສຸດ, ແລະການບໍ່ໃຫ້ມັນເຮັດວຽກຢ່າງຖືກຕ້ອງໃນ containers ຫມາຍຄວາມວ່າການບໍ່ສົນໃຈວ່າປະຊາຊົນຫຼາຍພັນຄົນມີຄວາມຄຸ້ນເຄີຍກັບ container ແລ່ນແນວໃດ.

Podman ຮູ້ວ່າຈະເຮັດແນວໃດເພື່ອເຮັດໃຫ້ລະບົບເຮັດວຽກຢ່າງຖືກຕ້ອງຢູ່ໃນຖັງ. ມັນຕ້ອງການສິ່ງຕ່າງໆເຊັ່ນການຕິດຕັ້ງ tmpfs ໃນ /run ແລະ /tmp. ນາງມັກໃຫ້ສະພາບແວດລ້ອມ "containerized" ເປີດໃຊ້ງານແລະຄາດຫວັງວ່າການອະນຸຍາດໃຫ້ຂຽນສ່ວນຂອງນາງຂອງ cgroup directory ແລະໂຟນເດີ /var/log/journald.

ເມື່ອທ່ານເລີ່ມຕົ້ນ container ທີ່ຄໍາສັ່ງທໍາອິດແມ່ນ init ຫຼື systemd, Podman ຈະ configure tmpfs ແລະ Cgroups ໂດຍອັດຕະໂນມັດເພື່ອຮັບປະກັນວ່າລະບົບເລີ່ມຕົ້ນໂດຍບໍ່ມີບັນຫາ. ເພື່ອບລັອກໂໝດເປີດອັດຕະໂນມັດນີ້, ໃຫ້ໃຊ້ຕົວເລືອກ --systemd=false. ກະລຸນາສັງເກດວ່າ Podman ພຽງແຕ່ໃຊ້ໂຫມດ systemd ເມື່ອມັນເຫັນວ່າມັນຈໍາເປັນຕ້ອງດໍາເນີນການຄໍາສັ່ງ systemd ຫຼື init.

ນີ້ແມ່ນບົດຄັດຫຍໍ້ຈາກຄູ່ມື:

ຜູ້ຊາຍ podman ແລ່ນ
...

–systemd=true|false

ແລ່ນກ່ອງບັນຈຸຢູ່ໃນໂຫມດລະບົບ. ເປີດໃຊ້ໂດຍຄ່າເລີ່ມຕົ້ນ.

ຖ້າທ່ານດໍາເນີນການຄໍາສັ່ງ systemd ຫຼື init ພາຍໃນ container, Podman ຈະ configure ຈຸດ tmpfs mount ໃນໄດເລກະທໍລີຕໍ່ໄປນີ້:

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

ນອກຈາກນີ້ສັນຍານຢຸດເລີ່ມຕົ້ນຈະເປັນ SIGRTMIN+3.

ທັງຫມົດນີ້ອະນຸຍາດໃຫ້ systemd ດໍາເນີນການຢູ່ໃນຖັງປິດໂດຍບໍ່ມີການດັດແປງໃດໆ.

ໝາຍເຫດ: systemd ພະຍາຍາມຂຽນໃສ່ລະບົບໄຟລ໌ cgroup. ຢ່າງໃດກໍຕາມ, SELinux ປ້ອງກັນບໍ່ໃຫ້ containers ດໍາເນີນການນີ້ໂດຍຄ່າເລີ່ມຕົ້ນ. ເພື່ອເປີດໃຊ້ງານການຂຽນ, ເປີດໃຊ້ຕົວກໍານົດການ boolean container_manage_cgroup:

setsebool -P container_manage_cgroup true

ຕອນນີ້ເບິ່ງວ່າ Dockerfile ມີລັກສະນະແນວໃດສໍາລັບການແລ່ນ systemd ໃນ container ໂດຍໃຊ້ 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 ເພື່ອເປີດຕົວປະເພດຂອງບັນຈຸເຫຼົ່ານີ້ຜ່ານ daemon. (ຊ່ອງຂໍ້ມູນ ແລະແພັກເກັດເພີ່ມເຕີມຈະຕ້ອງເຮັດໃຫ້ສິ່ງນີ້ເຮັດວຽກໄດ້ຢ່າງບໍ່ຢຸດຢັ້ງໃນ Docker, ຫຼືມັນຈະຕ້ອງຖືກແລ່ນຢູ່ໃນຖັງທີ່ມີສິດທິພິເສດ. ສໍາລັບລາຍລະອຽດ, ເບິ່ງ. ບົດຄວາມ.)

ສອງສາມສິ່ງທີ່ດີຫຼາຍກ່ຽວກັບ Podman ແລະ systemd

Podman ເຮັດວຽກດີກວ່າ Docker ໃນໄຟລ໌ຫນ່ວຍງານລະບົບ

ຖ້າຕູ້ຄອນເທນເນີຕ້ອງເລີ່ມຕົ້ນໃນເວລາທີ່ລະບົບເລີ່ມຕົ້ນ, ຫຼັງຈາກນັ້ນທ່ານພຽງແຕ່ສາມາດໃສ່ຄໍາສັ່ງ Podman ທີ່ເຫມາະສົມເຂົ້າໄປໃນໄຟລ໌ຫນ່ວຍງານ systemd, ເຊິ່ງຈະເລີ່ມຕົ້ນການບໍລິການແລະຕິດຕາມມັນ. Podman ໃຊ້ຮູບແບບ fork-exec ມາດຕະຖານ. ໃນຄໍາສັບຕ່າງໆອື່ນໆ, ຂະບວນການບັນຈຸແມ່ນເດັກນ້ອຍຂອງຂະບວນການ Podman, ດັ່ງນັ້ນລະບົບສາມາດຕິດຕາມພວກມັນໄດ້ງ່າຍ.

Docker ໃຊ້ຮູບແບບເຊີບເວີລູກຄ້າ, ແລະຄໍາສັ່ງ Docker CLI ຍັງສາມາດຖືກຈັດໃສ່ໂດຍກົງໃນໄຟລ໌ຫນ່ວຍ. ຢ່າງໃດກໍຕາມ, ເມື່ອລູກຄ້າ Docker ເຊື່ອມຕໍ່ກັບ daemon Docker, ມັນ (ລູກຄ້າ) ກາຍເປັນພຽງແຕ່ຂະບວນການອື່ນໃນການຈັດການ stdin ແລະ stdout. ໃນທາງກັບກັນ, systemd ບໍ່ມີຄວາມຄິດກ່ຽວກັບການເຊື່ອມຕໍ່ລະຫວ່າງລູກຄ້າ Docker ແລະ container ທີ່ດໍາເນີນການພາຍໃຕ້ການຄວບຄຸມຂອງ Docker daemon, ແລະດັ່ງນັ້ນ, ພາຍໃນຮູບແບບນີ້, systemd ໂດຍພື້ນຖານແລ້ວບໍ່ສາມາດກວດສອບການບໍລິການໄດ້.

ກຳລັງເປີດໃຊ້ລະບົບຜ່ານຊັອກເກັດ

Podman ຈັດການການເປີດໃຊ້ງານຜ່ານຊັອກເກັດຢ່າງຖືກຕ້ອງ. ເນື່ອງຈາກວ່າ Podman ໃຊ້ຮູບແບບ fork-exec, ມັນສາມາດສົ່ງຕໍ່ຊັອກເກັດໄປຫາຂະບວນການບັນຈຸລູກຂອງມັນ. Docker ບໍ່ສາມາດເຮັດສິ່ງນີ້ໄດ້ເພາະວ່າມັນໃຊ້ຕົວແບບ client-server.

ການບໍລິການ varlink ທີ່ Podman ໃຊ້ເພື່ອຕິດຕໍ່ສື່ສານກັບລູກຄ້າຫ່າງໄກສອກຫຼີກເພື່ອບັນຈຸແມ່ນເປີດໃຊ້ຕົວຈິງຜ່ານເຕົ້າຮັບ. ຊຸດ cockpit-podman, ລາຍລັກອັກສອນໃນ Node.js ແລະສ່ວນຫນຶ່ງຂອງໂຄງການ cockpit, ອະນຸຍາດໃຫ້ປະຊາຊົນສາມາດພົວພັນກັບ Podman containers ຜ່ານການໂຕ້ຕອບເວັບໄຊຕ໌. web daemon ແລ່ນ cockpit-podman ສົ່ງຂໍ້ຄວາມໄປຫາເຕົ້າຮັບ varlink ທີ່ລະບົບຟັງ. ຫຼັງຈາກນັ້ນ, Systemd ເປີດໃຊ້ໂປຣແກຣມ Podman ເພື່ອຮັບຂໍ້ຄວາມ ແລະເລີ່ມຈັດການບັນຈຸ. ການເປີດໃຊ້ງານລະບົບຜ່ານຊັອກເກັດຈະລົບລ້າງຄວາມຕ້ອງການສໍາລັບ daemon ທີ່ເຮັດວຽກຢ່າງຕໍ່ເນື່ອງໃນເວລາທີ່ປະຕິບັດ APIs ຫ່າງໄກສອກຫຼີກ.

ນອກຈາກນັ້ນ, ພວກເຮົາກໍາລັງພັດທະນາລູກຄ້າ Podman ອື່ນທີ່ເອີ້ນວ່າ podman-remote, ເຊິ່ງປະຕິບັດ Podman CLI ດຽວກັນແຕ່ໂທຫາ varlink ເພື່ອດໍາເນີນການບັນຈຸ. Podman-remote ສາມາດແລ່ນຢູ່ເທິງສຸດຂອງ SSH sessions, ຊ່ວຍໃຫ້ທ່ານສາມາດຕິດຕໍ່ພົວພັນຢ່າງປອດໄພກັບ containers ໃນເຄື່ອງຕ່າງໆ. ເມື່ອເວລາຜ່ານໄປ, ພວກເຮົາວາງແຜນທີ່ຈະເປີດໃຊ້ podman-remote ເພື່ອສະຫນັບສະຫນູນ MacOS ແລະ Windows ຄຽງຄູ່ກັບ Linux, ເພື່ອໃຫ້ນັກພັດທະນາໃນເວທີເຫຼົ່ານັ້ນສາມາດແລ່ນເຄື່ອງ virtual Linux ທີ່ມີ Podman varlink ແລ່ນແລະມີປະສົບການຢ່າງເຕັມທີ່ທີ່ containers ເຮັດວຽກຢູ່ໃນເຄື່ອງທ້ອງຖິ່ນ.

SD_NOTIFY

Systemd ອະນຸຍາດໃຫ້ທ່ານເລື່ອນການເປີດຕົວການບໍລິການຊ່ວຍຈົນກ່ວາການບໍລິການບັນຈຸທີ່ເຂົາເຈົ້າຕ້ອງການເລີ່ມຕົ້ນ. Podman ສາມາດສົ່ງຕໍ່ຊັອກເກັດ SD_NOTIFY ໄປຫາບໍລິການບັນຈຸບັນຈຸເພື່ອໃຫ້ບໍລິການແຈ້ງເຕືອນ systemd ວ່າມັນພ້ອມໃຫ້ບໍລິການແລ້ວ. ແລະອີກເທື່ອຫນຶ່ງ, Docker, ເຊິ່ງໃຊ້ຕົວແບບ client-server, ບໍ່ສາມາດເຮັດສິ່ງນີ້ໄດ້.

ໃນແຜນການ

ພວກເຮົາວາງແຜນທີ່ຈະເພີ່ມຄໍາສັ່ງ podman ສ້າງ CONTAINERID ທີ່ມີລະບົບ, ເຊິ່ງຈະສ້າງໄຟລ໌ຫນ່ວຍງານລະບົບເພື່ອຈັດການຖັງສະເພາະທີ່ລະບຸໄວ້. ອັນນີ້ຄວນໃຊ້ໄດ້ທັງໃນໂຫມດຮາກ ແລະບໍ່ມີຮາກສຳລັບບັນຈຸທີ່ບໍ່ມີສິດທິພິເສດ. ພວກເຮົາຍັງເຫັນການຮ້ອງຂໍສໍາລັບ runtime systemd-nspawn ທີ່ເຂົ້າກັນໄດ້ OCI.

ສະຫລຸບ

ການແລ່ນລະບົບໃນຖັງແມ່ນຄວາມຕ້ອງການທີ່ເຂົ້າໃຈໄດ້. ແລະຂໍຂອບໃຈກັບ Podman, ສຸດທ້າຍພວກເຮົາມີ container runtime ທີ່ບໍ່ຂັດແຍ້ງກັບ systemd, ແຕ່ເຮັດໃຫ້ມັນງ່າຍຕໍ່ການໃຊ້.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com