කන්ටේනරයක systemd ධාවනය කිරීම

අපි දිගු කාලයක් තිස්සේ කන්ටේනර් තුළ systemd භාවිතා කිරීමේ මාතෘකාව අනුගමනය කරමින් සිටිමු. 2014 දී අපේ ආරක්ෂක ඉංජිනේරු ඩැනියෙල් වොල්ෂ් ලිපියක් ලිවීය ඩොකර් කන්ටේනරයක් තුළ systemd ධාවනය වේ, සහ වසර කිහිපයකට පසු - තවත් එකක්, එය හැඳින්විණි වරප්‍රසාද නොලබන කන්ටේනරයක systemd ධාවනය කිරීම, එහි ඔහු ප්‍රකාශ කළේ තත්ත්වය එතරම් යහපත් වී නොමැති බවයි. විශේෂයෙන්ම ඔහු ලිව්වේ "අවාසනාවකට, වසර දෙකකට පසුවත්, ඔබ "Docker system" ගූගල් කළහොත්, මුලින්ම මතුවන්නේ ඔහුගේ පැරණි ලිපිය බවයි. එබැවින් යමක් වෙනස් කිරීමට කාලයයි. ” ඊට අමතරව, අපි දැනටමත් කතා කර ඇත Docker සහ systemd සංවර්ධකයින් අතර ගැටුම.

මෙම ලිපියෙන් අපි කාලයත් සමඟ වෙනස් වී ඇති දේ සහ මේ කාරණයේදී Podman අපට උපකාර කළ හැකි ආකාරය පෙන්වනු ඇත.

කන්ටේනරයක් තුළ systemd ධාවනය කිරීමට බොහෝ හේතු තිබේ, උදාහරණයක් ලෙස:

1. බහු සේවා බහාලුම් - බොහෝ දෙනෙකුට ඔවුන්ගේ බහු සේවා යෙදුම් අථත්‍ය යන්ත්‍රවලින් ඉවතට ගෙන ඒවා බහාලුම්වල ධාවනය කිරීමට අවශ්‍ය වේ. ඇත්ත වශයෙන්ම, එවැනි යෙදුම් ක්ෂුද්‍ර සේවා බවට බිඳ දැමීම වඩා හොඳය, නමුත් මෙය කරන්නේ කෙසේදැයි සෑම දෙනාම තවමත් නොදනිති හෝ සරලව කාලය නොමැත. එබැවින්, ඒකක ගොනු වලින් systemd විසින් දියත් කරන ලද සේවාවන් වැනි යෙදුම් ධාවනය කිරීම පරිපූර්ණ අර්ථවත් කරයි.
2. Systemd ඒකක ගොනු - බහාලුම් තුළ ධාවනය වන බොහෝ යෙදුම් ගොඩනඟා ඇත්තේ කලින් අතථ්‍ය හෝ භෞතික යන්ත්‍ර මත ධාවනය වූ කේතයෙනි. මෙම යෙදුම්වල මෙම යෙදුම් සඳහා ලියා ඇති ඒකක ගොනුවක් ඇති අතර ඒවා දියත් කළ යුතු ආකාරය තේරුම් ගනී. එබැවින් ඔබගේම init සේවාව හැක් කරනවාට වඩා සහය දක්වන ක්‍රම භාවිතයෙන් සේවා ආරම්භ කිරීම තවමත් වඩා හොඳය.
3. Systemd යනු ක්‍රියාවලි කළමනාකරුවෙකි. එය වෙනත් ඕනෑම මෙවලමකට වඩා හොඳින් සේවා කළමනාකරණය කරයි (වසා දැමීම, සේවා නැවත ආරම්භ කිරීම හෝ සොම්බි ක්‍රියාවලීන් විනාශ කරයි).

ඒ කිව්වේ systemd කන්ටේනර් වල ක්‍රියාත්මක නොකිරීමට ගොඩක් හේතු තියෙනවා. ප්‍රධාන එක තමයි systemd/journald මගින් බහාලුම්වල ප්‍රතිදානය පාලනය කිරීම සහ මෙවලම් වැනි කුබර්නෙට්ස් හෝ openshift බහාලුම් කෙලින්ම stdout සහ stderr වෙත ලොගය ලිවීමට බලාපොරොත්තු වේ. එමනිසා, ඔබ ඉහත සඳහන් කර ඇති වාද්‍ය වෘන්දය මෙවලම් හරහා බහාලුම් කළමනාකරණය කිරීමට යන්නේ නම්, ඔබ systemd-පාදක බහාලුම් භාවිතා කිරීම බැරෑරුම් ලෙස සලකා බැලිය යුතුය. මීට අමතරව, Docker සහ Moby සංවර්ධකයින් නිතරම systemd බහාලුම්වල භාවිතා කිරීමට දැඩි ලෙස විරුද්ධ වී ඇත.

පොඩ්මන්ගේ පැමිණීම

තත්ත්වය අවසානයේ ඉදිරියට ගොස් ඇති බව සතුටින් දන්වන්නෙමු. Red Hat හි බහාලුම් ධාවනය සඳහා වගකිව යුතු කණ්ඩායම සංවර්ධනය කිරීමට තීරණය කළේය ඔබේම බහාලුම් එන්ජිම. ඔහුට නමක් ලැබුණා පොඩ්මන් සහ Docker ලෙස එකම විධාන රේඛා අතුරුමුහුණත (CLI) ඉදිරිපත් කරයි. ඒවගේම Podman වලත් Docker commands සියල්ලම පාහේ ඒ ආකාරයෙන්ම භාවිතා කරන්න පුළුවන්. අපි නිතරම සම්මන්ත්‍රණ පවත්වනවා, ඒවා දැන් හඳුන්වනවා Docker Podman ලෙස වෙනස් කිරීම, සහ පළමු ස්ලයිඩය ලිවීම සඳහා කැඳවුම් කරයි: අන්වර්ථය docker=podman.

ගොඩක් අය මේක කරනවා.

මගේ Podman සහ මම කිසිම ආකාරයකින් systemd මත පදනම් වූ බහාලුම්වලට විරුද්ධ නැත. සියල්ලට පසු, Systemd යනු බහුලව භාවිතා වන Linux init උප පද්ධතිය වන අතර, එය බහාලුම්වල නිසි ලෙස ක්‍රියා කිරීමට ඉඩ නොදීම යනු දහස් ගණන් මිනිසුන් බහාලුම් ධාවනය කිරීමට පුරුදු වී සිටින ආකාරය නොසලකා හැරීමයි.

කන්ටේනරයක systemd නිසි ලෙස ක්‍රියා කිරීමට කුමක් කළ යුතු දැයි Podman දන්නවා. ඒකට tmpfs on /run සහ /tmp වගේ දේවල් ඕන. ඇය "බහාලීකරණය කරන ලද" පරිසරය සක්‍රීය කිරීමට කැමති අතර cgroup බහලුමේ ඇගේ කොටසට සහ /var/log/journald ෆෝල්ඩරයට ලිවීමේ අවසර බලාපොරොත්තු වේ.

ඔබ පළමු විධානය init හෝ systemd වන බහාලුමක් ආරම්භ කරන විට, Podman විසින් tmpfs සහ Cgroups ස්වයංක්‍රීයව වින්‍යාස කර systemd ගැටළු නොමැතිව ආරම්භ වන බව සහතික කරයි. මෙම ස්වයංක්‍රීය දියත් කිරීමේ මාදිලිය අවහිර කිරීමට, --systemd=false විකල්පය භාවිතා කරන්න. Podman එය systemd හෝ init විධානයක් ක්‍රියාත්මක කිරීමට අවශ්‍ය බව දුටු විට පමණක් systemd මාදිලිය භාවිතා කරන බව කරුණාවෙන් සලකන්න.

මෙන්න අත්පොතෙන් උපුටා ගැනීමක්:

මිනිසා podman ධාවනය
...

–systemd=ඇත්ත|අසත්‍යය

systemd මාදිලියේ බහාලුමක් ධාවනය කිරීම. පෙරනිමියෙන් සක්රිය කර ඇත.

ඔබ කන්ටේනරයක් තුළ systemd හෝ init විධානයක් ක්‍රියාත්මක කරන්නේ නම්, Podman පහත නාමාවලි තුළ tmpfs mount point වින්‍යාස කරනු ඇත:

/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 true

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 .

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>

සටහන: Docker මත මෙය උත්සාහ නොකරන්න! ඩීමන් හරහා මෙවැනි බහාලුම් දියත් කිරීමට ඔබට තවමත් රබන් සමඟ නටන්නට අවශ්‍ය වේ. (මේ සියල්ල Docker හි බාධාවකින් තොරව ක්‍රියා කිරීමට අමතර ක්ෂේත්‍ර සහ පැකේජ අවශ්‍ය වනු ඇත, නැතහොත් එය වරප්‍රසාද ලත් බහාලුමක ධාවනය කිරීමට අවශ්‍ය වනු ඇත. විස්තර සඳහා, බලන්න ලිපියයි.)

Podman සහ systemd ගැන තවත් රසවත් කරුණු කිහිපයක්

Podman systemd ඒකක ගොනු වල Docker වලට වඩා හොඳින් ක්‍රියා කරයි

පද්ධතිය ආරම්භ වන විට බහාලුම් ආරම්භ කිරීමට අවශ්‍ය නම්, ඔබට සුදුසු Podman විධානයන් systemd ඒකක ගොනුවට ඇතුළු කළ හැකිය, එමඟින් සේවාව ආරම්භ කර එය අධීක්ෂණය කරනු ඇත. Podman සම්මත fork-exec ආකෘතිය භාවිතා කරයි. වෙනත් වචන වලින් කිවහොත්, බහාලුම් ක්‍රියාවලීන් Podman ක්‍රියාවලියේ දරුවන් වන අතර, එම නිසා systemd හට පහසුවෙන් ඒවා නිරීක්ෂණය කළ හැක.

Docker විසින් සේවාදායක-සේවාදායක ආකෘතියක් භාවිතා කරන අතර, Docker CLI විධාන සෘජුවම ඒකක ගොනුවක තැබිය හැක. කෙසේ වෙතත්, Docker සේවාදායකයා Docker daemon වෙත සම්බන්ධ වූ පසු, එය (සේවාදායකයා) stdin සහ stdout හැසිරවීමේ තවත් ක්‍රියාවලියක් බවට පත් වේ. අනෙක් අතට, ඩොකර් ග්‍රාහකයා සහ ඩොකර් ඩීමන් පාලනය යටතේ ක්‍රියාත්මක වන බහාලුම අතර සම්බන්ධය ගැන systemd හට කිසිදු අදහසක් නැත, එබැවින්, මෙම ආකෘතිය තුළ, systemd හට මූලික වශයෙන් සේවාව නිරීක්ෂණය කළ නොහැක.

සොකට් හරහා systemd සක්රිය කිරීම

Podman සොකට් හරහා සක්රිය කිරීම නිවැරදිව හසුරුවයි. Podman fork-exec ආකෘතිය භාවිතා කරන නිසා, එයට සොකට් එක එහි ළමා බහාලුම් ක්‍රියාවලීන් වෙත යොමු කළ හැකිය. එය සේවාදායක-සේවාදායක ආකෘතියක් භාවිතා කරන නිසා Docker හට මෙය කළ නොහැක.

Podman විසින් දුරස්ථ සේවාදායකයින් සමඟ බහාලුම් වෙත සන්නිවේදනය කිරීමට භාවිතා කරන varlink සේවාව සැබවින්ම සොකට් එකක් හරහා සක්‍රිය කර ඇත. Cockpit-podman පැකේජය, Node.js හි ලියා ඇති සහ නියමු කුටි ව්‍යාපෘතියේ කොටසක් වන අතර, වෙබ් අතුරු මුහුණතක් හරහා Podman බහාලුම් සමඟ අන්තර් ක්‍රියා කිරීමට මිනිසුන්ට ඉඩ සලසයි. cockpit-podman ධාවනය වන වෙබ් ඩීමන්, systemd සවන් දෙන varlink socket වෙත පණිවිඩ යවයි. Systemd පසුව පණිවිඩ ලබා ගැනීමට සහ බහාලුම් කළමනාකරණය කිරීමට Podman වැඩසටහන සක්‍රීය කරයි. සොකට් එකක් හරහා systemd සක්‍රිය කිරීම දුරස්ථ API ක්‍රියාත්මක කිරීමේදී නිරන්තරයෙන් ධාවනය වන ඩීමන් අවශ්‍යතාවය ඉවත් කරයි.

මීට අමතරව, අපි Podman-remote නමින් තවත් Podman සේවාලාභියෙකු සංවර්ධනය කරමින් සිටිමු, එය එම Podman CLI ක්‍රියාත්මක කරන නමුත් බහාලුම් ධාවනය කිරීමට varlink අමතන්න. Podman-remote SSH සැසි මත ධාවනය කළ හැකි අතර, විවිධ යන්ත්‍රවල බහාලුම් සමඟ ආරක්ෂිතව අන්තර් ක්‍රියා කිරීමට ඔබට ඉඩ සලසයි. කාලයත් සමඟ, අපි Linux සමඟ MacOS සහ Windows සඳහා podman-remote සක්‍රීය කිරීමට සැලසුම් කරමු, එවිට එම වේදිකාවල සංවර්ධකයින්ට Podman varlink ධාවනය වන Linux අතථ්‍ය යන්ත්‍රයක් ධාවනය කළ හැකි අතර දේශීය යන්ත්‍රය මත බහාලුම් ක්‍රියාත්මක වන බවට සම්පූර්ණ අත්දැකීමක් ලබා ගත හැකිය.

SD_NOTIFY

Systemd ඔබට අවශ්‍ය බහාලුම් සේවාව ආරම්භ වන තෙක් සහායක සේවා දියත් කිරීම කල් දැමීමට ඔබට ඉඩ සලසයි. Podman හට SD_NOTIFY සොකට් එක කන්ටේනරීකරණය කරන ලද සේවාව වෙත යොමු කළ හැක, එවිට සේවාව එය ක්‍රියාත්මක වීමට සූදානම් බව systemd වෙත දැනුම් දෙයි. නැවතත්, සේවාදායක-සේවාදායක ආකෘතියක් භාවිතා කරන ඩොකර්ට මෙය කළ නොහැක.

සැලසුම් තුළ

නිශ්චිත බහාලුමක් කළමනාකරණය කිරීම සඳහා systemd ඒකක ගොනුවක් උත්පාදනය කරන, systemd CONTAINERID උත්පාදනය කරන විධානය podman එක් කිරීමට අපි සැලසුම් කරමු. මෙය වරප්‍රසාද නොලත් බහාලුම් සඳහා root සහ rootless ආකාර දෙකෙහිම ක්‍රියා කළ යුතුය. OCI-අනුකූල systemd-nspawn ධාවන කාලය සඳහා ඉල්ලීමක් පවා අපි දැක ඇත්තෙමු.

නිගමනය

කන්ටේනරයක systemd ධාවනය කිරීම තේරුම් ගත හැකි අවශ්යතාවකි. Podman ට ස්තූතියි, අපට අවසානයේ systemd සමඟ ගැටෙන්නේ නැති නමුත් එය භාවිතා කිරීමට පහසු වන බහාලුම් ධාවන කාලයක් ඇත.

මූලාශ්රය: www.habr.com