Mir hunn d'Thema vun der Benotzung vu Systemd a Container fir eng laang Zäit gefollegt. Zréck am Joer 2014 huet eise Sécherheetsingenieur Daniel Walsh en Artikel geschriwwen , an e puer Joer méi spéit - eng aner, déi genannt gouf , an deem hie sot, datt d'Situatioun sech net vill verbessert hätt. Besonnesch huet hien geschriwwen datt "leider, och zwee Joer méi spéit, wann Dir "Docker System" googlet, dat éischt wat opkënnt ass säin selwechten alen Artikel. Also et ass Zäit eppes ze änneren." Ausserdeem hu mir scho geschwat .
An dësem Artikel wäerte mir weisen wat iwwer Zäit geännert huet a wéi Podman eis an dëser Matière hëllefe kann.
Et gi vill Grënn fir Systemd an engem Container ze lafen, sou wéi:
- Multiservice Container - Vill Leit wëllen hir Multi-Service Uwendungen aus virtuelle Maschinnen zéien a se a Container lafen. Et wier natierlech besser esou Applikatiounen a Mikroservicer ze briechen, awer net jidderee weess wéi dat nach ze maachen oder huet einfach keng Zäit. Dofir mécht sou Uwendungen wéi Servicer, déi vu systemd aus Eenheetsdateien lancéiert ginn, perfekt Sënn.
- Systemd Eenheet Dateien - Déi meescht Uwendungen, déi a Container lafen, ginn aus Code gebaut, dee virdru op virtuellen oder kierperleche Maschinnen lafen. Dës Uwendungen hunn eng Eenheetsdatei déi fir dës Uwendungen geschriwwe gouf a versteet wéi se solle lancéiert ginn. Also et ass nach ëmmer besser fir Servicer mat ënnerstëtzte Methoden unzefänken, anstatt Ären eegenen Init Service ze hacken.
- Systemd ass e Prozessmanager. Et mécht Servicemanagement (Shutdown, Restart Servicer oder killt Zombieprozesser) besser wéi all aner Tool.
Dat gesot, et gi vill Grënn net systemd a Container ze lafen. Den Haapt ass datt systemd / journald d'Ausgab vu Container kontrolléiert, an Tools wéi oder erwaart Container fir Logbuch direkt op stdout a stderr ze schreiwen. Dofir, wann Dir Container duerch Orchestratiounsinstrumenter wéi déi hei uewen erwähnt gitt, sollt Dir eescht betruechten Systemd-baséiert Container ze benotzen. Zousätzlech sinn Docker a Moby Entwéckler dacks staark géint d'Benotzung vu Systemd a Container.
De Coming of Podman
Mir si frou ze mellen datt d'Situatioun endlech no vir komm ass. D'Team verantwortlech fir d'Container am Red Hat ze lafen huet decidéiert sech z'entwéckelen . Hien krut en Numm a bitt déiselwecht Kommandozeil-Interface (CLI) wéi Docker. A bal all Docker Kommandoen kënnen am Podman op déiselwecht Manéier benotzt ginn. Mir maachen dacks Seminairen, déi elo genannt ginn , an déi alleréischt Rutsch fuerdert Schreiwen: alias docker=podman.
Vill Leit maachen dëst.
Mäi Podman an ech sinn op kee Fall géint systemd-baséiert Container. No allem ass Systemd dat am meeschte benotzt Linux Init Subsystem, an et net erlaabt an Containeren richteg ze schaffen heescht ignoréieren wéi Dausende vu Leit gewinnt sinn Container ze lafen.
Podman weess wat ze maachen fir Systemd an engem Container richteg ze maachen. Et brauch Saachen wéi Montéierung tmpfs op /run an /tmp. Si huet gär dat "containeriséiert" Ëmfeld aktivéiert an erwaart Schreifrechter fir hiren Deel vum cgroup Verzeichnis an an den /var/log/journald Dossier.
Wann Dir e Container start an deem den éischte Kommando init oder systemd ass, konfiguréiert Podman automatesch tmpfs a Cgroups fir sécherzestellen datt systemd ouni Probleemer ufänkt. Fir dësen Autostartmodus ze blockéieren, benotzt d' --systemd = falsch Optioun. Notéiert w.e.g. datt Podman nëmme Systemd Modus benotzt wann et gesäit datt et e Systemd oder init Kommando muss lafen.
Hei ass en Auszich aus dem Handbuch:
Mann podman lafen
...–systemd=true|falsch
Lafen e Container am systemd Modus. Par défaut aktivéiert.
Wann Dir e Systemd oder Init Kommando an engem Container leeft, konfiguréiert Podman tmpfs Mount Punkten an de folgende Verzeichnisser:
/run, /run/lock, /tmp, /sys/fs/cgroup/systemd, /var/lib/journal
Och de Standardstoppsignal wäert SIGRTMIN + 3 sinn.
All dëst erlaabt Systemd an engem zouenen Container ouni Ännerungen ze lafen.
NOTÉIERT: systemd probéiert an de cgroup Dateiesystem ze schreiwen. Wéi och ëmmer, SELinux verhënnert datt Container dëst als Standard maachen. Fir Schreiwen z'aktivéieren, aktivéiert de Container_manage_cgroup boolean Parameter:
setsebool -P container_manage_cgroup richteg
Elo kuckt wéi d'Dockerfile ausgesäit fir Systemd an engem Container mat Podman ze lafen:
# cat Dockerfile
FROM fedora
RUN dnf -y install httpd; dnf clean all; systemctl enable httpd
EXPOSE 80
CMD [ "/sbin/init" ]
Dat ass alles.
Elo montéiere mir de Container:
# podman build -t systemd .
Mir soen SELinux fir Systemd z'erméiglechen d'Cgroups Konfiguratioun z'änneren:
# setsebool -P container_manage_cgroup true
Vill Leit vergiessen iwwregens dëse Schrëtt. Glécklecherweis muss dëst nëmmen eemol gemaach ginn an d'Astellung gëtt gespäichert nodeems de System nei gestart gouf.
Elo starten mir just de Container:
# 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.
Dat ass et, de Service ass op a leeft:
$ curl localhost
<html xml_lang="en" lang="en">
…
</html>
NOTÉIERT: Probéiert dëst net op Docker! Do musst Dir nach ëmmer mat enger Tambourin danzen fir dës Aarte vu Container duerch den Daemon ze lancéieren. (Zousätzlech Felder a Pakete sinn erfuerderlech fir dëst alles nahtlos am Docker ze maachen, oder et muss an engem privilegiéierte Container lafen. Fir Detailer, kuckt w.e.g. .)
E puer méi cool Saachen iwwer Podman a Systemd
Podman funktionnéiert besser wéi Docker a systemd Eenheetsdateien
Wann d'Container musse gestart ginn wann de System boott, da kënnt Dir einfach déi entspriechend Podman Kommandoen an d'Systemd Eenheetsdatei setzen, déi de Service starten an iwwerwaachen. Podman benotzt de Standard Gabel-exec Modell. An anere Wierder, Containerprozesser si Kanner vum Podman-Prozess, sou datt Systemd se einfach iwwerwaache kann.
Docker benotzt e Client-Server Modell, an Docker CLI Kommandoen kënnen och direkt an enger Eenheetsdatei plazéiert ginn. Wéi och ëmmer, wann den Docker Client mam Docker Daemon verbënnt, gëtt et (de Client) just en anere Prozess deen stdin a stdout behandelt. Am Géigendeel huet systemd keng Ahnung iwwer d'Verbindung tëscht dem Docker Client an dem Container deen ënner der Kontroll vum Docker Daemon leeft, an dofir, an dësem Modell, kann systemd grondsätzlech de Service net iwwerwaachen.
Aktivéiert systemd iwwer Socket
Podman geréiert Aktivatioun via Socket korrekt. Well Podman de Fork-exec Modell benotzt, kann et de Socket op seng Kannerbehälterprozesser weiderginn. Docker kann dëst net maachen well et e Client-Server Modell benotzt.
De varlink Service dee Podman benotzt fir mat Fernclienten op Container ze kommunizéieren ass tatsächlech iwwer e Socket aktivéiert. De Cockpit-Podman Package, geschriwwen an Node.js an en Deel vum Cockpitprojet, erlaabt d'Leit mat Podman Container duerch eng Webinterface ze interagéieren. De Web Daemon Lafen Cockpit-Podman schéckt Messagen op eng varlink Socket datt systemd nolauschtert. Systemd aktivéiert dann de Podman Programm fir Messagen ze kréien an d'Container ze managen. Aktivéiert Systemd iwwer e Socket eliminéiert de Besoin fir e konstant lafende Daemon wann Dir Remote APIen implementéiert.
Zousätzlech entwéckelen mir en anere Podman Client genannt Podman-Remote, deen dee selwechte Podman CLI implementéiert awer varlink nennt fir Container ze lafen. Podman-Remote kann uewen op SSH Sessiounen lafen, wat Iech erlaabt Iech sécher mat Container op verschiddene Maschinnen ze interagéieren. Mat der Zäit plangen mir Podman-Remote z'erméiglechen fir MacOS a Windows niewent Linux z'ënnerstëtzen, sou datt Entwéckler op dëse Plattformen eng virtuell Linux Maschinn mat Podman varlink lafen kënnen an déi voll Erfahrung hunn datt Container op der lokaler Maschinn lafen.
SD_NOTIFY
Systemd erlaabt Iech de Start vun Hilfsservicer auszeleeën bis de containeriséierte Service deen se brauchen ufänkt. Podman kann den SD_NOTIFY Socket op de containeriséierte Service weiderginn, sou datt de Service Systemd matdeelt datt et prett ass ze bedreiwen. An nach eng Kéier, Docker, deen e Client-Server Modell benotzt, kann dëst net maachen.
An de Pläng
Mir plangen de Kommando podman generéieren systemd CONTAINERID ze addéieren, déi eng systemd Eenheetsdatei generéiert fir e spezifesche Container ze verwalten. Dëst sollt souwuel a root- a rootless Modi fir onprivilegéiert Container funktionnéieren. Mir hu souguer eng Ufro fir eng OCI-kompatibel Systemd-nspawn Runtime gesinn.
Konklusioun
Systemd an engem Container lafen ass e verständleche Besoin. An dank Podman hu mir endlech e Container Runtime, deen net mat systemd konflikt ass, awer et einfach ze benotzen mécht.
Source: will.com