ನಾವು ದೀರ್ಘಕಾಲದಿಂದ ಕಂಟೈನರ್‌ಗಳಲ್ಲಿ systemd ಅನ್ನು ಬಳಸುವ ವಿಷಯವನ್ನು ಅನುಸರಿಸುತ್ತಿದ್ದೇವೆ. 2014 ರಲ್ಲಿ, ನಮ್ಮ ಭದ್ರತಾ ಇಂಜಿನಿಯರ್ ಡೇನಿಯಲ್ ವಾಲ್ಷ್ ಒಂದು ಲೇಖನವನ್ನು ಬರೆದರು , ಮತ್ತು ಒಂದೆರಡು ವರ್ಷಗಳ ನಂತರ - ಇನ್ನೊಂದು, ಇದನ್ನು ಕರೆಯಲಾಯಿತು , ಇದರಲ್ಲಿ ಪರಿಸ್ಥಿತಿ ಹೆಚ್ಚು ಸುಧಾರಿಸಿಲ್ಲ ಎಂದು ಅವರು ಹೇಳಿದ್ದಾರೆ. ನಿರ್ದಿಷ್ಟವಾಗಿ ಹೇಳುವುದಾದರೆ, "ದುರದೃಷ್ಟವಶಾತ್, ಎರಡು ವರ್ಷಗಳ ನಂತರವೂ ನೀವು "ಡಾಕರ್ ಸಿಸ್ಟಮ್" ಅನ್ನು ಗೂಗಲ್ ಮಾಡಿದರೆ, ಮೊದಲು ಬರುವುದು ಅವರ ಅದೇ ಹಳೆಯ ಲೇಖನವಾಗಿದೆ. ಆದ್ದರಿಂದ ಏನನ್ನಾದರೂ ಬದಲಾಯಿಸುವ ಸಮಯ ಬಂದಿದೆ. ” ಜೊತೆಗೆ, ನಾವು ಈಗಾಗಲೇ ಮಾತನಾಡಿದ್ದೇವೆ .
ಈ ಲೇಖನದಲ್ಲಿ ನಾವು ಕಾಲಾನಂತರದಲ್ಲಿ ಏನು ಬದಲಾಗಿದೆ ಮತ್ತು ಈ ವಿಷಯದಲ್ಲಿ ಪಾಡ್ಮನ್ ನಮಗೆ ಹೇಗೆ ಸಹಾಯ ಮಾಡಬಹುದು ಎಂಬುದನ್ನು ತೋರಿಸುತ್ತೇವೆ.
ಕಂಟೇನರ್ ಒಳಗೆ systemd ಅನ್ನು ಚಲಾಯಿಸಲು ಹಲವು ಕಾರಣಗಳಿವೆ, ಅವುಗಳೆಂದರೆ:
- ಬಹುಸೇವಾ ಕಂಟೈನರ್‌ಗಳು - ಅನೇಕ ಜನರು ತಮ್ಮ ಬಹು-ಸೇವಾ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ವರ್ಚುವಲ್ ಯಂತ್ರಗಳಿಂದ ಹೊರತೆಗೆಯಲು ಮತ್ತು ಅವುಗಳನ್ನು ಕಂಟೇನರ್‌ಗಳಲ್ಲಿ ಚಲಾಯಿಸಲು ಬಯಸುತ್ತಾರೆ. ಅಂತಹ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಮೈಕ್ರೊ ಸರ್ವಿಸ್‌ಗಳಾಗಿ ಒಡೆಯುವುದು ಉತ್ತಮ, ಆದರೆ ಇದನ್ನು ಹೇಗೆ ಮಾಡಬೇಕೆಂದು ಎಲ್ಲರಿಗೂ ತಿಳಿದಿಲ್ಲ ಅಥವಾ ಸಮಯವಿಲ್ಲ. ಆದ್ದರಿಂದ, ಯುನಿಟ್ ಫೈಲ್‌ಗಳಿಂದ systemd ನಿಂದ ಪ್ರಾರಂಭಿಸಲಾದ ಸೇವೆಗಳಂತಹ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಚಲಾಯಿಸುವುದು ಪರಿಪೂರ್ಣ ಅರ್ಥವನ್ನು ನೀಡುತ್ತದೆ.
- Systemd ಯುನಿಟ್ ಫೈಲ್‌ಗಳು - ಕಂಟೇನರ್‌ಗಳ ಒಳಗೆ ಚಾಲನೆಯಲ್ಲಿರುವ ಹೆಚ್ಚಿನ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಹಿಂದೆ ವರ್ಚುವಲ್ ಅಥವಾ ಭೌತಿಕ ಯಂತ್ರಗಳಲ್ಲಿ ರನ್ ಮಾಡಿದ ಕೋಡ್‌ನಿಂದ ನಿರ್ಮಿಸಲಾಗಿದೆ. ಈ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಈ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗಾಗಿ ಬರೆಯಲಾದ ಯುನಿಟ್ ಫೈಲ್ ಅನ್ನು ಹೊಂದಿವೆ ಮತ್ತು ಅವುಗಳನ್ನು ಹೇಗೆ ಪ್ರಾರಂಭಿಸಬೇಕು ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತದೆ. ಆದ್ದರಿಂದ ನಿಮ್ಮ ಸ್ವಂತ init ಸೇವೆಯನ್ನು ಹ್ಯಾಕ್ ಮಾಡುವ ಬದಲು ಬೆಂಬಲಿತ ವಿಧಾನಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಸೇವೆಗಳನ್ನು ಪ್ರಾರಂಭಿಸುವುದು ಇನ್ನೂ ಉತ್ತಮವಾಗಿದೆ.
- Systemd ಒಂದು ಪ್ರಕ್ರಿಯೆ ನಿರ್ವಾಹಕ. ಇದು ಸೇವೆಗಳನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ (ಶಟ್ ಡೌನ್, ಸೇವೆಗಳನ್ನು ಮರುಪ್ರಾರಂಭಿಸುತ್ತದೆ, ಅಥವಾ ಜೊಂಬಿ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ಕೊಲ್ಲುತ್ತದೆ) ಇತರ ಯಾವುದೇ ಸಾಧನಕ್ಕಿಂತ ಉತ್ತಮವಾಗಿ.
ಕಂಟೈನರ್‌ಗಳಲ್ಲಿ systemd ಅನ್ನು ಚಲಾಯಿಸದಿರಲು ಹಲವು ಕಾರಣಗಳಿವೆ ಎಂದು ಅದು ಹೇಳಿದೆ. ಮುಖ್ಯವಾದುದೆಂದರೆ systemd/journald ಕಂಟೈನರ್‌ಗಳ ಔಟ್‌ಪುಟ್ ಅನ್ನು ನಿಯಂತ್ರಿಸುತ್ತದೆ ಮತ್ತು ಉಪಕರಣಗಳು ಅಥವಾ ಕಂಟೈನರ್‌ಗಳು ಲಾಗ್ ಅನ್ನು ನೇರವಾಗಿ stdout ಮತ್ತು stderr ಗೆ ಬರೆಯಲು ನಿರೀಕ್ಷಿಸಬಹುದು. ಆದ್ದರಿಂದ, ಮೇಲೆ ತಿಳಿಸಿದಂತಹ ಆರ್ಕೆಸ್ಟ್ರೇಶನ್ ಪರಿಕರಗಳ ಮೂಲಕ ನೀವು ಕಂಟೇನರ್‌ಗಳನ್ನು ನಿರ್ವಹಿಸಲು ಹೋದರೆ, ನೀವು systemd-ಆಧಾರಿತ ಕಂಟೈನರ್‌ಗಳನ್ನು ಬಳಸುವುದನ್ನು ಗಂಭೀರವಾಗಿ ಪರಿಗಣಿಸಬೇಕು. ಹೆಚ್ಚುವರಿಯಾಗಿ, ಡಾಕರ್ ಮತ್ತು ಮೊಬಿ ಡೆವಲಪರ್‌ಗಳು ಸಿಸ್ಟಮ್‌ಡಿಯನ್ನು ಕಂಟೈನರ್‌ಗಳಲ್ಲಿ ಬಳಸುವುದನ್ನು ಬಲವಾಗಿ ವಿರೋಧಿಸುತ್ತಾರೆ.
ದಿ ಕಮಿಂಗ್ ಆಫ್ ಪಾಡ್ಮನ್
ಪರಿಸ್ಥಿತಿಯು ಅಂತಿಮವಾಗಿ ಮುಂದಕ್ಕೆ ಸಾಗಿದೆ ಎಂದು ವರದಿ ಮಾಡಲು ನಾವು ಸಂತೋಷಪಡುತ್ತೇವೆ. Red Hat ನಲ್ಲಿ ಕಂಟೈನರ್‌ಗಳನ್ನು ನಡೆಸುವ ಜವಾಬ್ದಾರಿಯುತ ತಂಡವು ಅಭಿವೃದ್ಧಿಪಡಿಸಲು ನಿರ್ಧರಿಸಿದೆ . ಅವರು ಹೆಸರು ಪಡೆದರು ಮತ್ತು ಡಾಕರ್‌ನಂತೆಯೇ ಅದೇ ಕಮಾಂಡ್ ಲೈನ್ ಇಂಟರ್ಫೇಸ್ (CLI) ನೀಡುತ್ತದೆ. ಮತ್ತು ಬಹುತೇಕ ಎಲ್ಲಾ ಡಾಕರ್ ಆಜ್ಞೆಗಳನ್ನು ಪಾಡ್‌ಮ್ಯಾನ್‌ನಲ್ಲಿ ಅದೇ ರೀತಿಯಲ್ಲಿ ಬಳಸಬಹುದು. ನಾವು ಸಾಮಾನ್ಯವಾಗಿ ಸೆಮಿನಾರ್‌ಗಳನ್ನು ನಡೆಸುತ್ತೇವೆ, ಅದನ್ನು ಈಗ ಕರೆಯಲಾಗುತ್ತದೆ , ಮತ್ತು ಮೊದಲ ಸ್ಲೈಡ್ ಬರೆಯಲು ಕರೆ ಮಾಡುತ್ತದೆ: ಅಲಿಯಾಸ್ ಡಾಕರ್=ಪಾಡ್‌ಮ್ಯಾನ್.
ಅನೇಕ ಜನರು ಇದನ್ನು ಮಾಡುತ್ತಾರೆ.
ನನ್ನ ಪಾಡ್‌ಮ್ಯಾನ್ ಮತ್ತು ನಾನು ಯಾವುದೇ ರೀತಿಯಲ್ಲಿ systemd-ಆಧಾರಿತ ಕಂಟೈನರ್‌ಗಳಿಗೆ ವಿರುದ್ಧವಾಗಿಲ್ಲ. ಎಲ್ಲಾ ನಂತರ, Systemd ಸಾಮಾನ್ಯವಾಗಿ ಬಳಸುವ Linux init ಉಪವ್ಯವಸ್ಥೆಯಾಗಿದೆ, ಮತ್ತು ಅದನ್ನು ಕಂಟೇನರ್‌ಗಳಲ್ಲಿ ಸರಿಯಾಗಿ ಕೆಲಸ ಮಾಡಲು ಅನುಮತಿಸದಿರುವುದು ಎಂದರೆ ಸಾವಿರಾರು ಜನರು ಕಂಟೇನರ್‌ಗಳನ್ನು ಚಲಾಯಿಸಲು ಹೇಗೆ ಒಗ್ಗಿಕೊಂಡಿರುತ್ತಾರೆ ಎಂಬುದನ್ನು ನಿರ್ಲಕ್ಷಿಸುವುದು.
ಕಂಟೇನರ್‌ನಲ್ಲಿ ಸಿಸ್ಟಮ್‌ಡ್ ಸರಿಯಾಗಿ ಕೆಲಸ ಮಾಡಲು ಏನು ಮಾಡಬೇಕೆಂದು ಪಾಡ್‌ಮ್ಯಾನ್‌ಗೆ ತಿಳಿದಿದೆ. ಇದಕ್ಕೆ tmpfs ಅನ್ನು / ರನ್ ಮತ್ತು / tmp ನಲ್ಲಿ ಆರೋಹಿಸುವಂತಹ ವಿಷಯಗಳ ಅಗತ್ಯವಿದೆ. ಅವಳು "ಕಂಟೇನರೈಸ್ಡ್" ಪರಿಸರವನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಲು ಇಷ್ಟಪಡುತ್ತಾಳೆ ಮತ್ತು cgroup ಡೈರೆಕ್ಟರಿಯ ತನ್ನ ಭಾಗಕ್ಕೆ ಮತ್ತು /var/log/journald ಫೋಲ್ಡರ್‌ಗೆ ಬರೆಯಲು ಅನುಮತಿಗಳನ್ನು ನಿರೀಕ್ಷಿಸುತ್ತಾಳೆ.
ಮೊದಲ ಆಜ್ಞೆಯು init ಅಥವಾ systemd ಆಗಿರುವ ಧಾರಕವನ್ನು ನೀವು ಪ್ರಾರಂಭಿಸಿದಾಗ, systemd ತೊಂದರೆಗಳಿಲ್ಲದೆ ಪ್ರಾರಂಭವಾಗುವುದನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು Podman ಸ್ವಯಂಚಾಲಿತವಾಗಿ tmpfs ಮತ್ತು Cgroups ಅನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡುತ್ತದೆ. ಈ ಸ್ವಯಂ ಉಡಾವಣಾ ಕ್ರಮವನ್ನು ನಿರ್ಬಂಧಿಸಲು, --systemd=false ಆಯ್ಕೆಯನ್ನು ಬಳಸಿ. Podman ಇದು systemd ಅಥವಾ init ಆಜ್ಞೆಯನ್ನು ಚಲಾಯಿಸಬೇಕು ಎಂದು ನೋಡಿದಾಗ ಮಾತ್ರ systemd ಮೋಡ್ ಅನ್ನು ಬಳಸುತ್ತದೆ ಎಂಬುದನ್ನು ದಯವಿಟ್ಟು ಗಮನಿಸಿ.
ಕೈಪಿಡಿಯಿಂದ ಆಯ್ದ ಭಾಗ ಇಲ್ಲಿದೆ:
ಮನುಷ್ಯ ಪಾಡ್ಮನ್ ರನ್
...–systemd=true|false
systemd ಮೋಡ್‌ನಲ್ಲಿ ಧಾರಕವನ್ನು ಚಾಲನೆ ಮಾಡಲಾಗುತ್ತಿದೆ. ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ಸಕ್ರಿಯಗೊಳಿಸಲಾಗಿದೆ.
ನೀವು ಕಂಟೇನರ್‌ನಲ್ಲಿ systemd ಅಥವಾ init ಆಜ್ಞೆಯನ್ನು ಚಲಾಯಿಸಿದರೆ, Podman ಕೆಳಗಿನ ಡೈರೆಕ್ಟರಿಗಳಲ್ಲಿ tmpfs ಮೌಂಟ್ ಪಾಯಿಂಟ್‌ಗಳನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡುತ್ತದೆ:
/ರನ್, /ರನ್/ಲಾಕ್, /ಟಿಎಂಪಿ, /sys/fs/cgroup/systemd, /var/lib/journal
ಹಾಗೆಯೇ ಡೀಫಾಲ್ಟ್ ಸ್ಟಾಪ್ ಸಿಗ್ನಲ್ SIGRTMIN+3 ಆಗಿರುತ್ತದೆ.
ಇವೆಲ್ಲವೂ systemd ಅನ್ನು ಯಾವುದೇ ಮಾರ್ಪಾಡುಗಳಿಲ್ಲದೆ ಮುಚ್ಚಿದ ಕಂಟೇನರ್‌ನಲ್ಲಿ ಚಲಾಯಿಸಲು ಅನುಮತಿಸುತ್ತದೆ.
ಸೂಚನೆ: systemd cgroup ಕಡತ ವ್ಯವಸ್ಥೆಗೆ ಬರೆಯಲು ಪ್ರಯತ್ನಿಸುತ್ತದೆ. ಆದಾಗ್ಯೂ, SELinux ಕಂಟೈನರ್‌ಗಳು ಇದನ್ನು ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ಮಾಡುವುದನ್ನು ತಡೆಯುತ್ತದೆ. ಬರವಣಿಗೆಯನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಲು, ಕಂಟೈನರ್_ಮ್ಯಾನೇಜ್_ಸಿಗ್ರೂಪ್ ಬೂಲಿಯನ್ ಪ್ಯಾರಾಮೀಟರ್ ಅನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಿ:
setsebool -P container_manage_cgroup true
Podman ಅನ್ನು ಬಳಸಿಕೊಂಡು ಕಂಟೈನರ್‌ನಲ್ಲಿ systemd ಅನ್ನು ಚಲಾಯಿಸಲು ಡಾಕರ್‌ಫೈಲ್ ಹೇಗೆ ಕಾಣುತ್ತದೆ ಎಂಬುದನ್ನು ಈಗ ನೋಡಿ:
# cat Dockerfile
FROM fedora
RUN dnf -y install httpd; dnf clean all; systemctl enable httpd
EXPOSE 80
CMD [ "/sbin/init" ]
ಅಷ್ಟೇ.
ಈಗ ನಾವು ಕಂಟೇನರ್ ಅನ್ನು ಜೋಡಿಸುತ್ತೇವೆ:
# podman build -t systemd .
Cgroups ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಮಾರ್ಪಡಿಸಲು systemd ಗೆ ಅನುಮತಿಸಲು ನಾವು SELinux ಗೆ ಹೇಳುತ್ತೇವೆ:
# 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 ಯುನಿಟ್ ಫೈಲ್‌ಗಳಲ್ಲಿ ಡಾಕರ್‌ಗಿಂತ ಪಾಡ್‌ಮ್ಯಾನ್ ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ
ಸಿಸ್ಟಮ್ ಬೂಟ್ ಮಾಡಿದಾಗ ಕಂಟೇನರ್‌ಗಳನ್ನು ಪ್ರಾರಂಭಿಸಬೇಕಾದರೆ, ನೀವು ಸೂಕ್ತವಾದ ಪಾಡ್‌ಮ್ಯಾನ್ ಆಜ್ಞೆಗಳನ್ನು systemd ಯುನಿಟ್ ಫೈಲ್‌ಗೆ ಸೇರಿಸಬಹುದು, ಅದು ಸೇವೆಯನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತದೆ ಮತ್ತು ಅದನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುತ್ತದೆ. ಪಾಡ್‌ಮ್ಯಾನ್ ಪ್ರಮಾಣಿತ ಫೋರ್ಕ್-ಎಕ್ಸೆಕ್ ಮಾದರಿಯನ್ನು ಬಳಸುತ್ತಾರೆ. ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಹೇಳುವುದಾದರೆ, ಕಂಟೇನರ್ ಪ್ರಕ್ರಿಯೆಗಳು ಪಾಡ್‌ಮ್ಯಾನ್ ಪ್ರಕ್ರಿಯೆಯ ಮಕ್ಕಳು, ಆದ್ದರಿಂದ systemd ಅವುಗಳನ್ನು ಸುಲಭವಾಗಿ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಬಹುದು.
ಡಾಕರ್ ಕ್ಲೈಂಟ್-ಸರ್ವರ್ ಮಾದರಿಯನ್ನು ಬಳಸುತ್ತದೆ ಮತ್ತು ಡಾಕರ್ CLI ಆಜ್ಞೆಗಳನ್ನು ನೇರವಾಗಿ ಯುನಿಟ್ ಫೈಲ್‌ನಲ್ಲಿ ಇರಿಸಬಹುದು. ಆದಾಗ್ಯೂ, ಒಮ್ಮೆ ಡಾಕರ್ ಕ್ಲೈಂಟ್ ಡಾಕರ್ ಡೀಮನ್‌ಗೆ ಸಂಪರ್ಕಗೊಂಡರೆ, ಅದು (ಕ್ಲೈಂಟ್) stdin ಮತ್ತು stdout ಅನ್ನು ನಿರ್ವಹಿಸುವ ಮತ್ತೊಂದು ಪ್ರಕ್ರಿಯೆಯಾಗುತ್ತದೆ. ಪ್ರತಿಯಾಗಿ, ಡಾಕರ್ ಕ್ಲೈಂಟ್ ಮತ್ತು ಡಾಕರ್ ಡೀಮನ್‌ನ ನಿಯಂತ್ರಣದಲ್ಲಿ ಚಲಿಸುವ ಕಂಟೇನರ್ ನಡುವಿನ ಸಂಪರ್ಕದ ಬಗ್ಗೆ systemd ಗೆ ಯಾವುದೇ ಕಲ್ಪನೆಯಿಲ್ಲ ಮತ್ತು ಆದ್ದರಿಂದ, ಈ ಮಾದರಿಯಲ್ಲಿ, systemd ಮೂಲಭೂತವಾಗಿ ಸೇವೆಯನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ.
ಸಾಕೆಟ್ ಮೂಲಕ systemd ಅನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಲಾಗುತ್ತಿದೆ
ಪಾಡ್‌ಮ್ಯಾನ್ ಸಾಕೆಟ್ ಮೂಲಕ ಸಕ್ರಿಯಗೊಳಿಸುವಿಕೆಯನ್ನು ಸರಿಯಾಗಿ ನಿರ್ವಹಿಸುತ್ತಾನೆ. ಪಾಡ್‌ಮ್ಯಾನ್ ಫೋರ್ಕ್-ಎಕ್ಸಿಕ್ ಮಾದರಿಯನ್ನು ಬಳಸುವುದರಿಂದ, ಅದು ಸಾಕೆಟ್ ಅನ್ನು ತನ್ನ ಚೈಲ್ಡ್ ಕಂಟೈನರ್ ಪ್ರಕ್ರಿಯೆಗಳಿಗೆ ಫಾರ್ವರ್ಡ್ ಮಾಡಬಹುದು. ಕ್ಲೈಂಟ್-ಸರ್ವರ್ ಮಾದರಿಯನ್ನು ಬಳಸುವುದರಿಂದ ಡಾಕರ್ ಇದನ್ನು ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ.
ಕಂಟೈನರ್‌ಗಳಿಗೆ ರಿಮೋಟ್ ಕ್ಲೈಂಟ್‌ಗಳೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸಲು Podman ಬಳಸುವ varlink ಸೇವೆಯನ್ನು ವಾಸ್ತವವಾಗಿ ಸಾಕೆಟ್ ಮೂಲಕ ಸಕ್ರಿಯಗೊಳಿಸಲಾಗುತ್ತದೆ. ಕಾಕ್‌ಪಿಟ್-ಪಾಡ್‌ಮ್ಯಾನ್ ಪ್ಯಾಕೇಜ್, Node.js ನಲ್ಲಿ ಬರೆಯಲಾಗಿದೆ ಮತ್ತು ಕಾಕ್‌ಪಿಟ್ ಯೋಜನೆಯ ಭಾಗವಾಗಿದೆ, ಜನರು ವೆಬ್ ಇಂಟರ್ಫೇಸ್ ಮೂಲಕ ಪಾಡ್‌ಮ್ಯಾನ್ ಕಂಟೇನರ್‌ಗಳೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸಲು ಅನುಮತಿಸುತ್ತದೆ. ವೆಬ್ ಡೀಮನ್ ಚಾಲನೆಯಲ್ಲಿರುವ ಕಾಕ್‌ಪಿಟ್-ಪಾಡ್‌ಮ್ಯಾನ್ ಸಿಸ್ಟಮ್‌ಡಿ ಆಲಿಸುವ ವಾರ್‌ಲಿಂಕ್ ಸಾಕೆಟ್‌ಗೆ ಸಂದೇಶಗಳನ್ನು ಕಳುಹಿಸುತ್ತದೆ. Systemd ನಂತರ ಸಂದೇಶಗಳನ್ನು ಸ್ವೀಕರಿಸಲು ಮತ್ತು ಕಂಟೈನರ್‌ಗಳ ನಿರ್ವಹಣೆಯನ್ನು ಪ್ರಾರಂಭಿಸಲು Podman ಪ್ರೋಗ್ರಾಂ ಅನ್ನು ಸಕ್ರಿಯಗೊಳಿಸುತ್ತದೆ. ಸಾಕೆಟ್‌ನಲ್ಲಿ systemd ಅನ್ನು ಸಕ್ರಿಯಗೊಳಿಸುವುದರಿಂದ ರಿಮೋಟ್ API ಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವಾಗ ನಿರಂತರವಾಗಿ ಚಾಲನೆಯಲ್ಲಿರುವ ಡೀಮನ್‌ನ ಅಗತ್ಯವನ್ನು ನಿವಾರಿಸುತ್ತದೆ.
ಹೆಚ್ಚುವರಿಯಾಗಿ, ನಾವು ಪಾಡ್‌ಮ್ಯಾನ್-ರಿಮೋಟ್ ಎಂಬ ಮತ್ತೊಂದು ಪಾಡ್‌ಮ್ಯಾನ್ ಕ್ಲೈಂಟ್ ಅನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುತ್ತಿದ್ದೇವೆ, ಇದು ಅದೇ ಪಾಡ್‌ಮ್ಯಾನ್ ಸಿಎಲ್‌ಐ ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತದೆ ಆದರೆ ಕಂಟೇನರ್‌ಗಳನ್ನು ಚಲಾಯಿಸಲು ವರ್ಲಿಂಕ್ ಅನ್ನು ಕರೆಯುತ್ತದೆ. ಪಾಡ್‌ಮ್ಯಾನ್-ರಿಮೋಟ್ SSH ಸೆಷನ್‌ಗಳ ಮೇಲ್ಭಾಗದಲ್ಲಿ ಚಲಿಸಬಹುದು, ವಿಭಿನ್ನ ಯಂತ್ರಗಳಲ್ಲಿನ ಕಂಟೇನರ್‌ಗಳೊಂದಿಗೆ ಸುರಕ್ಷಿತವಾಗಿ ಸಂವಹನ ನಡೆಸಲು ನಿಮಗೆ ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ. ಕಾಲಾನಂತರದಲ್ಲಿ, Linux ಜೊತೆಗೆ MacOS ಮತ್ತು Windows ಅನ್ನು ಬೆಂಬಲಿಸಲು podman-remote ಅನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಲು ನಾವು ಯೋಜಿಸುತ್ತೇವೆ, ಇದರಿಂದಾಗಿ ಆ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ಗಳಲ್ಲಿನ ಡೆವಲಪರ್‌ಗಳು Podman varlink ಚಾಲನೆಯಲ್ಲಿರುವ Linux ವರ್ಚುವಲ್ ಯಂತ್ರವನ್ನು ರನ್ ಮಾಡಬಹುದು ಮತ್ತು ಕಂಟೇನರ್‌ಗಳು ಸ್ಥಳೀಯ ಗಣಕದಲ್ಲಿ ರನ್ ಆಗುತ್ತಿರುವ ಸಂಪೂರ್ಣ ಅನುಭವವನ್ನು ಹೊಂದಬಹುದು.
SD_NOTIFY
Systemd ನಿಮಗೆ ಅಗತ್ಯವಿರುವ ಕಂಟೈನರೈಸ್ಡ್ ಸೇವೆ ಪ್ರಾರಂಭವಾಗುವವರೆಗೆ ಸಹಾಯಕ ಸೇವೆಗಳ ಪ್ರಾರಂಭವನ್ನು ಮುಂದೂಡಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಪಾಡ್‌ಮ್ಯಾನ್ SD_NOTIFY ಸಾಕೆಟ್ ಅನ್ನು ಕಂಟೈನರೈಸ್ ಮಾಡಿದ ಸೇವೆಗೆ ಫಾರ್ವರ್ಡ್ ಮಾಡಬಹುದು ಇದರಿಂದ ಸೇವೆಯು ಕಾರ್ಯನಿರ್ವಹಿಸಲು ಸಿದ್ಧವಾಗಿದೆ ಎಂದು systemd ಗೆ ತಿಳಿಸುತ್ತದೆ. ಮತ್ತೊಮ್ಮೆ, ಕ್ಲೈಂಟ್-ಸರ್ವರ್ ಮಾದರಿಯನ್ನು ಬಳಸುವ ಡಾಕರ್ ಇದನ್ನು ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ.
ಯೋಜನೆಗಳಲ್ಲಿ
ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ ನಿರ್ದಿಷ್ಟ ಕಂಟೇನರ್ ಅನ್ನು ನಿರ್ವಹಿಸಲು systemd ಯುನಿಟ್ ಫೈಲ್ ಅನ್ನು ರಚಿಸುವ, systemd CONTAINERID ಅನ್ನು ರಚಿಸುವ ಆಜ್ಞೆಯನ್ನು podman ಅನ್ನು ಸೇರಿಸಲು ನಾವು ಯೋಜಿಸುತ್ತೇವೆ. ಇದು ಸವಲತ್ತು ಇಲ್ಲದ ಕಂಟೈನರ್‌ಗಳಿಗೆ ರೂಟ್ ಮತ್ತು ರೂಟ್‌ಲೆಸ್ ಮೋಡ್‌ಗಳಲ್ಲಿ ಕೆಲಸ ಮಾಡಬೇಕು. OCI-ಹೊಂದಾಣಿಕೆಯ systemd-nspawn ರನ್‌ಟೈಮ್‌ಗಾಗಿ ನಾವು ವಿನಂತಿಯನ್ನು ಸಹ ನೋಡಿದ್ದೇವೆ.
ತೀರ್ಮಾನಕ್ಕೆ
ಧಾರಕದಲ್ಲಿ systemd ರನ್ ಮಾಡುವುದು ಅರ್ಥವಾಗುವಂತಹ ಅಗತ್ಯವಾಗಿದೆ. ಮತ್ತು Podman ಗೆ ಧನ್ಯವಾದಗಳು, ನಾವು ಅಂತಿಮವಾಗಿ systemd ನೊಂದಿಗೆ ಸಂಘರ್ಷಿಸದ ಕಂಟೇನರ್ ರನ್ಟೈಮ್ ಅನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಆದರೆ ಅದನ್ನು ಬಳಸಲು ಸುಲಭಗೊಳಿಸುತ್ತದೆ.
ಮೂಲ: www.habr.com