MÄs jau sen sekojam tÄmai par systemd izmantoÅ”anu konteineros. VÄl 2014. gadÄ mÅ«su droŔības inženieris Daniel Walsh uzrakstÄ«ja rakstu , bet pÄris gadus vÄlÄk ā citu, kas saucÄs , kurÄ viÅÅ” norÄdÄ«ja, ka situÄcija nemaz nav uzlabojusies. Proti, viÅÅ” rakstÄ«ja, ka 'diemžÄl, pat divus gadus vÄlÄk, ja googlÄ Ā«Docker systemĀ», tad pirmais, kas parÄdÄs, ir viÅa vecais raksts. TÄtad, ir pienÄcis laiks kaut ko mainÄ«t'. TurklÄt mÄs jau reiz stÄstÄ«jÄm par .
Å ajÄ rakstÄ mÄs parÄdÄ«sim, kas ir mainÄ«jies pagÄjuÅ”ajÄ laikÄ un kÄ mums var palÄ«dzÄt Å”ajÄ jautÄjumÄ Podman.
Ir daudz iemeslu, lai palaistu systemd iekÅ”Äjos konteineros, piemÄram:
- Multiservisa konteineri ā daudzi vÄlas izÅemt savas multiservisa lietotnes no virtuÄlajÄm maŔīnÄm un palaist tÄs konteineros. Protams, bÅ«tu labÄk Å”Ädas lietotnes sadalÄ«t mikroservisos, bet ne visi to spÄj vai vienkÄrÅ”i nav laika. TÄpÄc palaist Å”Ädas lietotnes kÄ pakalpojumus, ko palaidÄ«s systemd no vienÄ«bas failiem, ir pilnÄ«gi saprÄtÄ«gi.
- Systemd vienÄ«bas faili ā lielÄkÄ daļa lietotÅu, kas darbojas iekÅ”Äjos konteineros, ir saliktas no koda, kas iepriekÅ” tika palaists uz virtuÄlajÄm vai fiziskÄm maŔīnÄm. Å Ä«m lietotnÄm ir vienÄ«bas fails, kas tika rakstÄ«ts Ŕīm lietotnÄm un saprot, kÄ tÄs jÄsÄk. TÄdÄjÄdi, pakalpojumus ir labÄk palaist, izmantojot atbalstÄ«tus risinÄjumus, nevis laužot savu paÅ”u init dienestu.
- Systemd ir procesu vadÄ«tÄjs. Tas pÄrvalda pakalpojumus (izbeidz, restarts pakalpojumus vai iznÄ«cina zÄ«mobrisus) labÄk nekÄ jebkurÅ” cits instruments.
TomÄr ir arÄ« daudzi iemesli, lai nepalaistu systemd konteineros. Galvenais ir tas, ka systemd/journald kontrolÄ konteineru izvadi, un tÄdas rÄ«ces kÄ vai paredz, ka konteineri rakstÄ«s žurnÄlus tieÅ”i stdout un stderr. TÄpÄc, ja plÄnojat pÄrvaldÄ«t konteinerus, izmantojot minÄtos orÄ·estrÄcijas rÄ«kus, tad ir nopietni jÄdomÄ par systemd pamata konteineru izmantoÅ”anu. TurklÄt Docker un Moby izstrÄdÄtÄji bieži ir bijuÅ”i kategoriski pret systemd izmantoÅ”anu konteineros.
Podman ienÄkÅ”ana
Ar prieku paziÅojam, ka situÄcija beidzot ir pÄrvietojusies no miruÅ”Äs punktu. Komanda, kas Red Hat ir atbildÄ«ga par konteineru palaiÅ”anu, ir nolÄmusi izstrÄdÄt . Tas saÅÄmis nosaukumu un piedÄvÄ tÄdu paÅ”u komandu rindu (CLI) saskarni kÄ Docker. Un praktiski visas Docker komandas var izmantot arÄ« Podman. MÄs bieži rÄ«kojam seminÄrus, kas tagad saucas , un pirmajÄ slaidÄ aicina rakstÄ«t: alias docker=podman.
Daudzi to arī dara.
MÄs ar savu Podman neesam pret konteineriem, kas balstÄs uz systemd. Galu galÄ Systemd biežÄk tiek izmantots kÄ init-sistÄma Linux, un ļaut tam normÄli nedarboties konteineros nozÄ«mÄ ignorÄt, kÄ tÅ«kstoÅ”iem cilvÄku ir pieraduÅ”i palaist konteinerus.
Podman zina, ko darÄ«t, lai systemd normÄli darbotos konteinerÄ. Tam nepiecieÅ”amas tÄdas lietas kÄ tmpfs montÄÅ”ana uz /run un /tmp. Tam patÄ«k, kad ir aktivizÄta "konteineru" vide, un tas gaida rakstÄ«Å”anas tiesÄ«bas savÄ cgroup kataloga daÄ¼Ä un mapÄ /var/log/journald.
Palaidot konteineru, kurÄ pirmÄ komanda ir init vai systemd, Podman automÄtiski konfigurÄ tmpfs un Cgroups, lai systemd palaiÅ”ana noritÄtu bez problÄmÄm. Lai bloÄ·Ätu Å”o automÄtisko palaiÅ”anas režīmu, tiek izmantota opcija āsystemd=false. Å emiet vÄrÄ, ka Podman izmanto systemd režīmu tikai tad, kad redz, ka jÄpaveic systemd vai init komanda.
Å eit ir izvilkums no rokasgrÄmatas:
man podman run
ā¦āsystemd=true|false
Konteinera palaiÅ”ana systemd režīmÄ. PÄc noklusÄjuma ir ieslÄgta.
Ja konteinerÄ tiek izpildÄ«ta systemd vai init komanda, Podman konfigurÄs tmpfs montÄÅ”anas punktus Å”Ädos katalogos:
/run, /run/lock, /tmp, /sys/fs/cgroup/systemd, /var/lib/journal
ArÄ« kÄ apstÄÅ”anÄs signÄls pÄc noklusÄjuma tiks izmantots SIGRTMIN+3.
Viss tas ļauj systemd darboties slÄgtÄ konteinerÄ bez jebkÄdÄm modifikÄcijÄm.
PiezÄ«me: systemd mÄÄ£ina veikt ierakstus cgroup failu sistÄmÄ. TomÄr SELinux pÄc noklusÄjuma aizliedz konteineriem to darÄ«t. Lai atļautu ierakstus, ieslÄdziet loÄ£isko parametru container_manage_cgroup:
setsebool -P container_manage_cgroup true
Tagad aplÅ«kosim, kÄ izskatÄs Dockerfile systemd palaiÅ”anai konteinerÄ, izmantojot Podman:
# cat Dockerfile
FROM fedora
RUN dnf -y install httpd; dnf clean all; systemctl enable httpd
EXPOSE 80
CMD [ "/sbin/init" ]
Tas arī viss.
Tagad uzkrÄjam konteineru:
# podman build -t systemd .
SakÄm SELinux atļaut systemd modificÄt Cgroups konfigurÄciju:
# setsebool -P container_manage_cgroup true
Daudzi, starp citu, aizmirst par Å”o soli. Par laimi, to nepiecieÅ”ams izdarÄ«t tikai vienu reizi, un iestatÄ«jumi tiek saglabÄti arÄ« pÄc sistÄmas restartÄÅ”anas.
Tagad vienkÄrÅ”i uzsÄkam konteineru:
# 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.
Viss, pakalpojums ir uzsÄcies un darbojas:
$ curl localhost
<html xml_lang="en" lang="en">
…
</html>
PIEZÄŖME: Neaizmirstiet to izmÄÄ£inÄt DockerāÄ! Tur joprojÄm ir nepiecieÅ”amas dažÄdas manipulÄcijas, lai palaiž Å”Äda veida konteinerus caur demonizÄto. (NepiecieÅ”ami papildu lauki un pakotnes, lai viss bez problÄmÄm darbotos Docker, vai arÄ« tas bÅ«s jÄpalaiž privileÄ£ÄtÄ konteinerÄ. SÄ«kÄk skatiet .)
VÄl pÄris interesantu lietu par Podman un systemd
Podman darbojas labÄk nekÄ Docker systemd vienÄ«bas failos
Ja konteinerus jÄuzsÄk pie sistÄmas ielÄdes, var vienkÄrÅ”i ievietot attiecÄ«gÄs Podman komandas systemd vienÄ«bas failÄ, kas uzsÄks pakalpojumu un uzraudzÄ«s to. Podman izmanto standarta izpildes modeli (fork-exec). Citiem vÄrdiem sakot, konteineru procesi ir meitas procesi attiecÄ«bÄ pret Podman procesu, tÄpÄc systemd to viegli var uzraudzÄ«t.
Docker izmanto klienta-servera modeli, un Docker CLI komandas var arÄ« ievietot tieÅ”i vienÄ«bas failÄ. TomÄr, kad Docker klients pieslÄdzas Docker demonam, tas (klients) kļūst par vÄl vienu procesu, kas apstrÄdÄ stdin un stdout. SavukÄrt, systemd vispÄr nezina par saikni starp Docker klientu un konteineru, kas darbojas Docker demona vadÄ«bÄ, tÄpÄc Å”ajÄ modelÄ« systemd principÄ nevar uzraudzÄ«t pakalpojumu.
systemd aktivÄcija caur soketu
Podman pareizi apstrÄdÄ aktivÄciju caur soketu. TÄ kÄ Podman izmanto fork-exec modeli, tas var nodot soketu saviem meitas konteineru procesiem. Docker tÄ nemÄk, jo izmanto klienta-servera modeli.
Varlink serviss, ko Podman izmanto, lai mijiedarbotos ar attÄlajiem klientiem un konteineriem, patiesÄ«bÄ tiek aktivizÄts caur soketu. Pakotne cockpit-podman, kas ir rakstÄ«ta Node.js un ietilpst cockpit projekta sastÄvÄ, ļauj cilvÄkiem mijiedarboties ar Podman konteineriem caur tÄ«mekļa interfeisu. TÄ«mekļa demons, uz kura darbojas cockpit-podman, sÅ«ta ziÅojumus uz varlink soketu, kuru klausÄs systemd. PÄc tam systemd aktivizÄ Podman programmu, lai saÅemtu ziÅojumus un sÄktu pÄrvaldÄ«t konteinerus. Systemd aktivizÄcija caur soketu ļauj iztikt bez pastÄvÄ«ga darba demona attÄlinÄto API realizÄcijÄ.
TurklÄt mÄs izstrÄdÄjam vÄl vienu klientu Podmanam, ko sauc podman-remote, kas Ä«steno to paÅ”u Podman CLI, bet izmanto varlink, lai palaistu konteinerus. Podman-remote var darboties virs SSH sesijÄm, ļaujot droÅ”i mijiedarboties ar konteineriem dažÄdÄs maŔīnÄs. Laika gaitÄ mÄs plÄnojam izmantot podman-remote, lai atbalstÄ«tu MacOS un Windows kopÄ ar Linux, lai izstrÄdÄtÄji Å”ajÄs platformÄs varÄtu palaist Linux virtuÄlo maŔīnu ar darbojoÅ”os Podman varlink un iegÅ«t pilnÄ«gu sajÅ«tu, ka konteineri izpildÄs uz vietÄjÄs maŔīnas.
SD_NOTIFY
Systemd ļauj atlikt palÄ«gservisu uzsÄkÅ”anu lÄ«dz brÄ«dim, kad ir uzsÄkts nepiecieÅ”amais tiem konteinerizÄtais serviss. Podman var nodot SD_NOTIFY soketu konteinerizÄtajam servisam, lai tas paziÅotu systemd par savu gatavÄ«bu strÄdÄt. Un atkal, Docker, kas izmanto klienta-servera modeli, tÄ nedara.
PlÄni
MÄs plÄnojam pievienot komandu podman generate systemd CONTAINERID, kas Ä£enerÄs systemd vienÄ«bas failu konkrÄta noteikta konteinca pÄrvaldÄ«bai. Tam jÄdarbojas gan root-, gan rootless režīmos nepilnvarotiem konteineriem. MÄs pat esam redzÄjuÅ”i pieprasÄ«jumu izveidot OCI savietojamu systemd-nspawn izpildes vidi.
SecinÄjums
Systemd palaiÅ”ana konteinerÄ ir pilnÄ«gi saprotama vajadzÄ«ba. Un, pateicoties Podman, mums beidzot ir konteineru palaiÅ”anas vide, kas nav naidÄ«ga pret systemd, bet ļauj to vienkÄrÅ”i izmantot.
Avots: habr.com
