Ons volg al lank die onderwerp van die gebruik van systemd in houers. In 2014 het ons sekuriteitsingenieur Daniel Walsh 'n artikel geskryf , en 'n paar jaar later - 'n ander, wat genoem is , waarin hy verklaar het dat die situasie nie veel verbeter het nie. Hy het veral geskryf dat "ongelukkig, en twee jaar later, as jy "Docker-stelsel" google, dieselfde ou artikel van hom eerste opduik. Dit is dus tyd vir 'n verandering." Daarbenewens het ons reeds gepraat oor .
In hierdie artikel sal ons wys wat sedertdien verander het en hoe Podman ons in hierdie saak kan help.
Daar is baie redes om systemd binne 'n houer te laat loop, soos:
- Multidiens houers – baie mense wil hul multi-diens toepassings uit virtuele masjiene trek en dit in houers laat loop. Dit sal natuurlik beter wees om sulke toepassings in mikrodienste op te breek, maar nie almal weet nog hoe om dit te doen nie of daar is eenvoudig nie tyd nie. Om hierdie toepassings as dienste wat deur systemd vanaf eenheidlêers bestuur word, maak dus volkome sin.
- Systemd eenheid lêers - meeste toepassings wat binne houers loop, is gebou uit kode wat voorheen op virtuele of fisiese masjiene uitgevoer is. Hierdie toepassings het 'n eenheidlêer wat vir hierdie toepassings geskryf is en verstaan hoe hulle uitgevoer moet word. Dit is dus steeds beter om dienste te begin deur ondersteunde metodes te gebruik eerder as om jou eie init-diens te hack.
- Systemd is 'n prosesbestuurder. Dit bestuur dienste (skakel af, herbegin dienste of maak zombies dood) beter as enige ander instrument.
Dit gesê, daar is baie redes om nie systemd in houers te laat loop nie. Die belangrikste een is dat systemd/journald die uitset van houers beheer, en gereedskap soos of houers verwag om logs direk na stdout en stderr te skryf. As jy dus houers gaan bestuur deur orkestrasie-nutsmiddels soos dié hierbo, moet jy dit ernstig oorweeg om systemd-gebaseerde houers te gebruik. Boonop was die Docker- en Moby-ontwikkelaars dikwels sterk gekant teen die gebruik van systemd in houers.
Podman kom
Ons is bly om aan te kondig dat die situasie uiteindelik vorentoe beweeg het. Die span verantwoordelik vir die bestuur van houers by Red Hat het besluit om te ontwikkel . Hy het 'n naam gekry en bied dieselfde opdragreëlkoppelvlak (CLI) as Docker. En byna alle Docker-opdragte kan op dieselfde manier in Podman gebruik word. Ons hou dikwels seminare, wat nou genoem word , en die heel eerste skyfie vra vir skryf: alias docker=podman.
Baie mense doen net dit.
Ek en my Podman is geensins teen sisteemgebaseerde houers nie. Systemd word immers meer dikwels gebruik as die init-substelsel van Linux, en om te verhoed dat dit behoorlik in houers werk, beteken dat die manier waarop duisende mense gewoond is om houers te bestuur, te ignoreer.
Podman weet wat gedoen moet word om systemd behoorlik in 'n houer te laat werk. Sy het dinge nodig soos om tmpfs op /run en /tmp te monteer. Sy hou daarvan om 'n "containerized" omgewing te aktiveer en wag vir skryftoestemmings vir haar deel van die cgroup-gids en na die /var/log/journald-lêergids.
Wanneer 'n houer met init of systemd as die eerste opdrag begin word, stel Podman outomaties tmpfs en Cgroups op sodat systemd glad begin. Om hierdie outostart-modus te deaktiveer, gebruik die --systemd=false opsie. Let daarop dat Podman slegs systemd-modus gebruik wanneer dit sien dat dit 'n systemd- of init-opdrag moet uitvoer.
Hier is 'n uittreksel uit die handleiding:
man podman hardloop
...–systemd=waar|onwaar
Begin 'n houer in systemd-modus. By verstek geaktiveer.
As 'n systemd- of init-opdrag binne 'n houer loop, sal Podman tmpfs-monteerpunte in die volgende gidse opstel:
/run, /run/lock, /tmp, /sys/fs/cgroup/systemd, /var/lib/journal
Ook SIGRTMIN+3 sal as die verstekstopsein gebruik word.
Dit alles laat systemd toe om in 'n geslote houer te werk sonder enige veranderinge.
LET WEL: systemd probeer om na die cgroup-lêerstelsel te skryf. SELinux verhoed egter dat houers dit by verstek doen. Om skryf toe te laat, aktiveer die container_manage_cgroup boolean parameter:
setsebool -P container_manage_cgroup waar
Kyk nou hoe die Dockerfile lyk om systemd in 'n houer te laat loop met Podman:
# cat Dockerfile
FROM fedora
RUN dnf -y install httpd; dnf clean all; systemctl enable httpd
EXPOSE 80
CMD [ "/sbin/init" ]
Dit is alles.
Nou versamel ons die houer:
# podman build -t systemd .
Sê vir SELinux om systemd toe te laat om die Cgroups-konfigurasie te verander:
# setsebool -P container_manage_cgroup true
Baie, terloops, vergeet van hierdie stap. Gelukkig is dit genoeg om dit net een keer te doen en die instelling word gestoor na 'n stelsel herlaai.
Nou begin ons net die houer:
# 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.
Dit is dit, die diens is aan die gang:
$ curl localhost
<html xml_lang="en" lang="en">
…
</html>
LET WEL: Moenie dit op Docker probeer nie! Daar moet nog met 'n tamboeryn gedans word om hierdie soort houers deur 'n demoon te laat loop. (Bykomende velde en pakkette sal vereis word om dit naatloos in Docker te laat werk, of dit sal in 'n bevoorregte houer uitgevoer moet word. Sien besonderhede in .)
Nog 'n paar oulike dinge oor Podman en systemd
Podman presteer beter as Docker in systemd-eenheidlêers
As houers by stelsellaai begin moet word, kan u eenvoudig die toepaslike Podman-opdragte in die systemd-eenheidlêer invoeg, wat die diens sal begin en dit monitor. Podman gebruik die standaard vurk-exec-model. Met ander woorde, houerprosesse is kinders van die Podman-proses, so systemd kan dit maklik monitor.
Docker gebruik 'n kliënt-bediener-model, en Docker CLI-opdragte kan ook direk in 'n eenheidlêer geplaas word. Nadat die Docker-kliënt egter aan die Docker-demon gekoppel is, word dit (die kliënt) net nog 'n proses wat stdin en stdout hanteer. Systemd het op sy beurt geen idee oor die verband tussen die Docker-kliënt en die houer wat die Docker-daemon bestuur nie, en daarom kan systemd, binne hierdie model, nie die diens in beginsel monitor nie.
Aktiveer stelseld via sok
Podman hanteer sokaktivering korrek. Omdat Podman die fork-exec-model gebruik, kan dit die sok na sy kinderhouerprosesse aanstuur. Docker kan dit nie doen nie, want dit gebruik 'n kliënt-bediener-model.
Die varlink-diens wat Podman gebruik om afgeleë kliënte toe te laat om met houers te kommunikeer, word eintlik oor 'n sok aangeroep. Die kajuit-podman-pakket, geskryf in Node.js en deel van die kajuitprojek, stel mense in staat om met Podman-houers te kommunikeer deur middel van 'n webkoppelvlak. Die webdaemon wat cockpit-podman loop, stuur boodskappe na die varlink-sok waarna systemd luister. Systemd aktiveer dan die Podman-program om boodskappe te ontvang en houers te begin bestuur. Aktivering van systemd oor 'n sok elimineer die behoefte aan 'n konstante daemon wanneer afgeleë API's geïmplementeer word.
Ons ontwikkel ook 'n ander Podman-kliënt genaamd podman-remote wat dieselfde Podman CLI implementeer, maar varlink roep om houers te begin. Podman-afstandsbediening kan bo-op SSH-sessies loop, waardeur u veilig met houers op verskillende masjiene kan kommunikeer. Met verloop van tyd beplan ons om podman-remote te gebruik om MacOS en Windows saam met Linux te ondersteun, sodat ontwikkelaars op daardie platforms 'n Linux virtuele masjien met Podman varlink kan bestuur en die volle gevoel kan hê dat houers op 'n plaaslike masjien loop.
SD_KENNISGEWING
Systemd laat jou toe om die aanvang van hulpdienste uit te stel totdat die houerdiens wat hulle benodig, begin. Podman kan 'n SD_NOTIFY-sok na 'n houerdiens aanstuur sodat die diens systemd in kennis stel dat dit gereed is om te gaan. En weer, Docker, wat die kliënt-bediener-model gebruik, weet nie hoe nie.
In die planne
Ons beplan om 'n podman genereer systemd CONTAINERID-opdrag by te voeg wat 'n systemd-eenheidlêer sal genereer om 'n gegewe houer te bestuur. Dit moet in beide wortel- en wortellose modus werk vir onbevoorregte houers. Ons het selfs 'n versoek gesien vir 'n OCI-voldoende systemd-nspawn-looptyd.
Gevolgtrekking
Om systemd in 'n houer te laat loop is 'n verstaanbare behoefte. En te danke aan Podman, het ons uiteindelik 'n houerlooptyd wat nie systemd antagoniseer nie, maar dit maklik maak om te gebruik.
Bron: will.com