Ne kemi ndjekur prej kohësh temën e përdorimit të systemd në kontejnerë. Që në vitin 2014, inxhinieri ynë i sigurisë, Daniel Walsh, shkroi një artikull , dhe disa vjet më vonë – një tjetër, që quhej , ku ai konstatonte se situata nuk kishte përmirësuar shumë. Në veçanti, ai shkruante se «fatkeqësisht, dhe dy vjet më vonë, nëse i kërkon “Docker system” në Google, artikulli i tij i vjetër shpërfaqet si i pari. Kjo tregon se është koha për të bërë ndryshime». Për më tepër, ne kemi folur ndonjëherë për .
. Në këtë artikull, do të tregojmë se çfarë ka ndryshuar gjatë këtij kohë dhe si mund të na ndihmojë në këtë çështje Podman.
Ka shumë arsye për të funksionuar systemd brenda një kontejneri, si p.sh.:
- Konteinerë me shumë shërbime – shumë dëshirojnë të nxjerrin aplikacionet e tyre me shumë shërbime nga makinat virtuale dhe t’i funksionojnë ato në kontejnerë. Sigurisht, do të ishte më mirë të ndaheshin këto aplikacione në mikrosisteme, por jo të gjithë e dinë si ta bëjnë këtë ose nuk kanë kohë. Prandaj, funksionimi i tillë i aplikacioneve si shërbime, të funksionuara nga systemd nga skedarët e njësive, ka kuptim.
- Skedarët e njësive të Systemd – shumica e aplikacioneve që funksionojnë brenda kontejnerëve janë ndërtuar nga kodi që më parë ishte ekzekutuar në makina virtuale ose fizike. Këto aplikacione kanë një njësinë e skedarit, e cila është shkruar për këto aplikacione dhe kupton si duhet t'i ekzekutojë ato. Prandaj, është më mirë të ekzekutoni shërbimet duke përdorur metoda të mbështetura, në vend që të keni një shërbim init të piratizuar.
- Systemd është menaxheri i proceseve. Ai menaxhon shërbimet (ndalon, ribalon shërbimet ose eliminon proceset zombie) më mirë se çdo mjet tjetër.
Megjithatë, ka shumë arsye për të mos e ekzekutuar systemd në konteinerë. Arsyja kryesore është se systemd/journald kontrollon daljen e konteinerëve, ndërsa mjete si ose presin që konteinerët të shkruajnë log direkt në stdout dhe stderr. Prandaj, nëse planifikoni të menaxhoni konteinerët përmes mjeteve të orkestrimit të tipit të përmendur më lart, duhet ta mendoni seriozisht përdorimin e konteinerëve të bazuar në systemd. Për më tepër, zhvilluesit e Docker dhe Moby shpesh ishin të ashpër kundër përdorimit të systemd në konteinerë.
Ardhja e Podman
Me vjen mirë të njoftojmë se situata përfundimisht ka bërë një hap përpara. Ekipa në Red Hat që merret me nisjen e konteinerëve ka vendosur të zhvillojë . Ai mori emrin dhe ofron të njëjtin ndërfaqe të komandave (CLI) si Docker. Praktikisht të gjitha komandat e Docker përdoren gjithashtu në Podman. Ne shpesh organizojmë seminare, tani të quajtura , dhe slajdi i parë fton për të shkruar: alias docker=podman.
Shumë e bëjnë këtë.
Për ne, Podman-i ynë nuk është aspak kundër konteinerëve të bazuar në systemd. Sepse Systemd përdoret më shpesh si nën-sistem init në Linux, dhe mos t'i lejojmë të funksionojë siç duhet në konteinerë do të thotë të injorojmë se si mijëra njerëz janë mësuar të nisin konteinerë.
Podman di se çfarë duhet të bëjë që systemd të funksionojë siç duhet në një konteiner. Ajo ka nevojë për gjëra si montimi i tmpfs në /run dhe /tmp. Ajo pëlqen kur mjedisi "konteiner" është aktiv, dhe pret të ketë të drejtat e shkruar në pjesën e saj të katalogut cgroup dhe në dosjen /var/log/journald.
Kur nisni një kontejner, në të cilin komanda e parë është init ose systemd, Podman automatikisht konfiguronte tmpfs dhe Cgroups për të siguruar që nisja e systemd të kalojë pa probleme. Për ta bllokuar këtë automatikisht, përdoret opsioni —systemd=false. Vini re se Podman përdor modalitetin systemd vetëm kur sheh se duhet të ekzekutojë komandën systemd ose init.
Ja një përmbledhje nga manuali:
man podman run
…–systemd=true|false
Nisja e kontejnerit në modalitetin systemd. Aktivizuar sipas parazgjedhjes.
Nëse brenda kontejnerit ekzekutohet komanda systemd ose init, Podman do të konfigurojë pikat e montimit tmpfs në këto katalogë:
/run, /run/lock, /tmp, /sys/fs/cgroup/systemd, /var/lib/journal
Gjithashtu, si sinjal ndalimi, do të përdoret për default SIGRTMIN+3.
Të gjitha këto lejojnë që systemd të funksionojë në një kontejner të mbyllur pa asnjë modifikim.
VËMENDJE: systemd përpiqet të shkruajë në sistemin e skedarëve cgroup. Megjithatë, SELinux, sipas parazgjedhjes, e ndalon këtë për kontejnerët. Për të lejuar shkrimin, aktivizoni parametrin logjik container_manage_cgroup:
setsebool -P container_manage_cgroup true
Tani shikoni si duket Dockerfile për nisjen e systemd në kontejner duke përdorur Podman-in:
# cat Dockerfile
FROM fedora
RUN dnf -y install httpd; dnf clean all; systemctl enable httpd
EXPOSE 80
CMD [ "/sbin/init" ]
Këtu është gjithçka.
Tani po ndërtuam kontejnerin:
# podman build -t systemd .
Lejohim SELinux të lejojë systemd të modifikojë konfigurimin e Cgroups:
# setsebool -P container_manage_cgroup true
Shumë, për fat të keq, e harrojnë këtë hap. Fatmirësisht, është mjaft të bëhet vetëm një herë dhe konfigurimi ruhet pas rinisjes së sistemit.
Tani thjesht filloni kontejnerin:
# 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.
Kjo është, shërbimi nisi dhe funksionon:
$ curl localhost
<html xml_lang="en" lang="en">
…
</html>
SHËNIM: Mos u përpiqni ta përsërisni këtë në Docker! Aty ende nevojiten disa manovra për të nisur këtë lloj kontejnerësh përmes demonit. (Do të nevojiten fusha dhe paketa të tjera për ta bërë këtë të punojë pa probleme në Docker, ose duhet ta nisni në një kontejner me privilegje. Shihni detajet në .)
Dy gjëra të tjera të shkëlqyera rreth Podman dhe systemd
Podman punon më mirë se Docker në skedarët e njësive systemd
Nëse kontejnerët duhet të nisin me ngarkimin e sistemit, thjesht mund të vendosni komandat përkatëse të Podman në skedarin e njësisë systemd, që do të nisë shërbimin dhe do ta monitorojë atë. Podman përdor modelin standard të bifurkimit gjatë ekzekutimit (fork-exec). Me fjalë të tjera, proceset e kontejnerëve janë nënproçese të procesit të Podman, kështu që systemd i monitoron lehtësisht.
Docker përdor modelin klient-server, dhe komandat CLI të Docker-it gjithashtu mund të vendosen drejtpërdrejt në skedarin e njësisë. Megjithatë, pasi klienti Docker të lidhet me demonin Docker, ai (klienti) bëhet thjesht një proces tjetër që përpunon stdin dhe stdout. Nga ana e tij, systemd nuk ka asnjë ide për lidhjen midis klientit Docker dhe kontejnerit që funksionon nën menaxhimin e demonit Docker, dhe prandaj, në këtë model, systemd në thelb nuk mund të monitorojë shërbimin.
Aktivizimi i systemd përmes soketit
Podman funksionon saktësisht me aktivizimin përmes soketit. Duke qenë se Podman përdor modelin fork-exec, ai mund të kalojë soketin në proceset e tij të kontejnerëve të birësuar. Docker nuk mund ta bëjë këtë, pasi përdor modelin klient-server.
Shërbimi varlink, i cili Podman e përdor për të bashkëvepruar me klientët e largët dhe kontejnerët, aktivizohet në të vërtetë përmes një socketi. Paketa cockpit-podman, e shkruar në Node.js dhe pjesë e projektit cockpit, u mundëson përdoruesve të bashkëveprojnë me kontejnerët Podman përmes një ndërfaqeje në web. Demon web-i, mbi të cilin funksionon cockpit-podman, dërgon mesazhe në socket-in varlink, të cilin e dëgjon systemd. Më pas, systemd aktivizon programin Podman për të marrë mesazhet dhe për të filluar menaxhimin e kontejnerëve. Aktivizimi i systemd përmes socketit lejon shmangien e nevojës për një demon që punon vazhdimisht gjatë realizimit të API-ve të largëta.
Për më tepër, ne jemi duke zhvilluar një klient tjetër për Podman, i quajtur podman-remote, i cili implementon të njëjtin Podman CLI, por përdor varlink për të nisur kontejnerët. Podman-remote mund të funksionojë mbi seancat SSH, duke lejuar ndërveprimin në mënyrë të sigurt me kontejnerët në makina të ndryshme. Me kalimin e kohës, ne planifikojmë të aktivizojmë podman-remote për të mbështetur MacOS dhe Windows së bashku me Linux, në mënyrë që zhvilluesit në këto platforma të mund të nisin një makinë virtuale Linux me Podman varlink të funksionojë dhe të kenë një ndjenjë të plotë se kontejnerët po ekzekutohen në makinën lokale.
SD_NOTIFY
Systemd lejon që nisja e shërbimeve ndihmëse të shtyhet deri në momentin kur shërbimi i nevojshëm i kontejnerizuar të niste. Podman mund të kalojë soketin SD_NOTIFY në shërbimin e kontejnerizuar në mënyrë që ky shërbim ta njoftojë systemd për gatishmërinë e tij për të punuar. Edhe një herë, Docker, që përdor modelin klient-server, nuk e bën këtë.
Në planet
Ne do të shtojmë komandën podman generate systemd CONTAINERID, e cila do të gjenerojë një skedar uniti systemd për menaxhimin e një kontejneri të caktuar. Kjo duhet të funksionojë si në modin root, ashtu edhe në modin pa privilegje për kontejnerët e paprivilegjuar. Madje kemi parë kërkesën për të krijuar një mjedis përzhgimi të përputhshëm me OCI për systemd-nspawn.
Përfundimi
Të nisësh systemd në një kontejner është një nevojë krejtësisht e arsyeshme. Dhe falë Podman, për herë të parë kemi një ambient lançimi kontejnerësh që nuk është në konflikt me systemd, por lejon një përdorim të lehtë të tij.
Burimi: habr.com
