Ne e kemi ndjekur temën e përdorimit të systemd në kontejnerë për një kohë të gjatë. Në vitin 2014, inxhinieri ynë i sigurisë Daniel Walsh shkroi një artikull , dhe nja dy vjet më vonë - një tjetër, e cila u quajt , në të cilën ai deklaroi se situata nuk është përmirësuar shumë. Në veçanti, ai shkroi se "për fat të keq, edhe dy vjet më vonë, nëse google "Docker system", gjëja e parë që del është i njëjti artikull i tij i vjetër. Kështu që është koha për të ndryshuar diçka.” Përveç kësaj, ne kemi folur tashmë për .
Në këtë artikull do të tregojmë se çfarë ka ndryshuar me kalimin e kohës dhe si mund të na ndihmojë Podman në këtë çështje.
Ka shumë arsye për të ekzekutuar systemd brenda një kontejneri, si p.sh.
- Kontejnerë me shumë shërbime – Shumë njerëz duan të tërheqin aplikacionet e tyre me shumë shërbime nga makinat virtuale dhe t'i përdorin ato në kontejnerë. Do të ishte më mirë, sigurisht, që aplikacione të tilla të ndahen në mikroshërbime, por jo të gjithë e dinë ende se si ta bëjnë këtë ose thjesht nuk kanë kohë. Prandaj, ekzekutimi i aplikacioneve të tilla si shërbime të lëshuara nga systemd nga skedarët e njësisë ka kuptim të përsosur.
- Skedarët e njësive të sistemuara – Shumica e aplikacioneve që funksionojnë brenda kontejnerëve janë ndërtuar nga kodi që funksiononte më parë në makina virtuale ose fizike. Këto aplikacione kanë një skedar njësi që është shkruar për këto aplikacione dhe kupton se si duhet të lansohen. Pra, është akoma më mirë të filloni shërbimet duke përdorur metoda të mbështetura, në vend që të hakoni shërbimin tuaj init.
- Systemd është një menaxher procesi. Ai kryen menaxhimin e shërbimit (fikje, rinis shërbimet ose vret proceset e zombies) më mirë se çdo mjet tjetër.
Thënë kështu, ka shumë arsye për të mos funksionuar systemd në kontejnerë. Kryesorja është se systemd/journald kontrollon daljen e kontejnerëve dhe mjeteve si ose presin që kontejnerët të shkruajnë log direkt në stdout dhe stderr. Prandaj, nëse do të menaxhoni kontejnerët përmes mjeteve orkestruese si ato të përmendura më lart, duhet të konsideroni seriozisht përdorimin e kontejnerëve të bazuar në sistem. Për më tepër, zhvilluesit e Docker dhe Moby kanë qenë shpesh kundër përdorimit të systemd në kontejnerë.
Ardhja e Podmanit
Jemi të lumtur të raportojmë se situata më në fund ka ecur përpara. Ekipi përgjegjës për drejtimin e kontejnerëve në Red Hat vendosi të zhvillohej . Ai mori një emër dhe ofron të njëjtën ndërfaqe të linjës së komandës (CLI) si Docker. Dhe pothuajse të gjitha komandat Docker mund të përdoren në Podman në të njëjtën mënyrë. Ne shpesh zhvillojmë seminare, të cilat tani quhen , dhe rrëshqitja e parë kërkon shkrim: alias docker=podman.
Shumë njerëz e bëjnë këtë.
Podman im dhe unë nuk jemi në asnjë mënyrë kundër kontejnerëve të bazuar në sistem. Në fund të fundit, Systemd është nënsistemi init Linux më i përdorur, dhe të mos lejosh që ai të funksionojë siç duhet në kontejnerë do të thotë të injorosh se si mijëra njerëz janë mësuar të përdorin kontejnerët.
Podman e di se çfarë të bëjë për ta bërë systemd-in të funksionojë siç duhet në një enë. Ajo ka nevojë për gjëra të tilla si montimi i tmpfs në /run dhe /tmp. Asaj i pëlqen të aktivizohet mjedisi "containerized" dhe pret leje shkrimi në pjesën e saj të drejtorisë cgroup dhe në dosjen /var/log/journald.
Kur nisni një kontejner në të cilin komanda e parë është init ose systemd, Podman konfiguron automatikisht tmpfs dhe Cgroups për të siguruar që systemd të fillojë pa probleme. Për të bllokuar këtë modalitet të nisjes automatike, përdorni opsionin --systemd=false. Ju lutemi vini re se Podman përdor vetëm modalitetin systemd kur sheh se duhet të ekzekutojë një komandë systemd ose init.
Këtu është një fragment nga manuali:
njeri podman vrap
...–systemd=true|false
Drejtimi i një kontejneri në modalitetin systemd. Aktivizuar si parazgjedhje.
Nëse ekzekutoni një komandë systemd ose init brenda një kontejneri, Podman do të konfigurojë pikat e montimit tmpfs në drejtoritë e mëposhtme:
/run, /run/lock, /tmp, /sys/fs/cgroup/systemd, /var/lib/journal
Gjithashtu sinjali i parazgjedhur i ndalimit do të jetë SIGRTMIN+3.
E gjithë kjo lejon systemd-in të funksionojë në një enë të mbyllur pa asnjë modifikim.
SHËNIM: systemd përpiqet të shkruajë në sistemin e skedarëve cgroup. Megjithatë, SELinux parandalon kontejnerët që ta bëjnë këtë si parazgjedhje. Për të aktivizuar shkrimin, aktivizoni parametrin boolean container_manage_cgroup:
setsebool -P container_manage_cgroup true
Tani shikoni se si duket Dockerfile për ekzekutimin e systemd në një enë duke përdorur Podman:
# cat Dockerfile
FROM fedora
RUN dnf -y install httpd; dnf clean all; systemctl enable httpd
EXPOSE 80
CMD [ "/sbin/init" ]
Kjo eshte e gjitha.
Tani mbledhim enën:
# podman build -t systemd .
Ne i themi SELinux që të lejojë systemd të modifikojë konfigurimin e Cgroups:
# setsebool -P container_manage_cgroup true
Nga rruga, shumë njerëz e harrojnë këtë hap. Për fat të mirë, kjo duhet të bëhet vetëm një herë dhe cilësimi ruhet pas rindezjes së sistemit.
Tani thjesht fillojmë enën:
# 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ë e gjitha, shërbimi është në funksion:
$ curl localhost
<html xml_lang="en" lang="en">
…
</html>
SHËNIM: Mos e provoni këtë në Docker! Atje ju duhet ende të kërceni me një dajre për të nisur këto lloj kontejnerë përmes demonit. (Do të kërkohen fusha dhe paketa shtesë për ta bërë këtë të funksionojë pa probleme në Docker, ose do të duhet të ekzekutohet në një kontejner të privilegjuar. Për detaje, shih .)
Disa gjëra më interesante rreth Podman dhe systemd
Podman funksionon më mirë se Docker në skedarët e njësive systemd
Nëse kontejnerët duhet të nisen kur sistemi të niset, atëherë thjesht mund të futni komandat e duhura të Podman në skedarin e njësisë systemd, i cili do të nisë shërbimin dhe do ta monitorojë atë. Podman përdor modelin standard fork-exec. Me fjalë të tjera, proceset e kontejnerëve janë fëmijë të procesit Podman, kështu që systemd mund t'i monitorojë lehtësisht ato.
Docker përdor një model klient-server dhe komandat Docker CLI gjithashtu mund të vendosen drejtpërdrejt në një skedar njësi. Sidoqoftë, sapo klienti Docker të lidhet me daemonin Docker, ai (klienti) bëhet thjesht një proces tjetër që trajton stdin dhe stdout. Nga ana tjetër, systemd nuk ka asnjë ide për lidhjen midis klientit Docker dhe kontejnerit që funksionon nën kontrollin e daemonit Docker, dhe për këtë arsye, brenda këtij modeli, systemd në thelb nuk mund të monitorojë shërbimin.
Aktivizimi i sistemit përmes prizës
Podman e trajton si duhet aktivizimin nëpërmjet prizës. Për shkak se Podman përdor modelin fork-exec, ai mund ta përcjellë folenë në proceset e tij të kontejnerit fëmijë. Docker nuk mund ta bëjë këtë sepse përdor një model klient-server.
Shërbimi varlink që Podman përdor për të komunikuar me klientët në distancë në kontejnerë aktivizohet në të vërtetë nëpërmjet një prize. Paketa cockpit-podman, e shkruar në Node.js dhe pjesë e projektit të kabinës, i lejon njerëzit të ndërveprojnë me kontejnerët Podman përmes një ndërfaqeje në internet. Web-demon running cockpit-podman dërgon mesazhe në një prizë varlink që systemd dëgjon. Systemd më pas aktivizon programin Podman për të marrë mesazhe dhe për të filluar menaxhimin e kontejnerëve. Aktivizimi i systemd mbi një prizë eliminon nevojën për një demon që funksionon vazhdimisht gjatë zbatimit të API-ve në distancë.
Për më tepër, ne po zhvillojmë një klient tjetër Podman të quajtur podman-remote, i cili zbaton të njëjtin Podman CLI, por thërret varlink për të drejtuar kontejnerët. Podman-remote mund të funksionojë në krye të seancave SSH, duke ju lejuar të ndërveproni në mënyrë të sigurt me kontejnerët në makina të ndryshme. Me kalimin e kohës, ne planifikojmë të mundësojmë podman-remote që të mbështesë MacOS dhe Windows së bashku me Linux, në mënyrë që zhvilluesit në ato platforma të mund të ekzekutojnë një makinë virtuale Linux me Podman varlink që funksionon dhe të kenë përvojën e plotë që kontejnerët po funksionojnë në makinën lokale.
SD_NOTIFY
Systemd ju lejon të shtyni nisjen e shërbimeve ndihmëse derisa të fillojë shërbimi i kontejnerëve që ata kërkojnë. Podman mund ta përcjellë prizën SD_NOTIFY te shërbimi i kontejneruar në mënyrë që shërbimi të njoftojë systemd se është gati për të operuar. Dhe përsëri, Docker, i cili përdor një model klient-server, nuk mund ta bëjë këtë.
Në planet
Ne planifikojmë të shtojmë komandën "podman generate systemd CONTAINERID", e cila do të gjenerojë një skedar të njësisë systemd për të menaxhuar një kontejner specifik të specifikuar. Kjo duhet të funksionojë si në modalitetin rrënjë ashtu edhe në atë pa rrënjë për kontejnerët e paprivilegjuar. Ne kemi parë madje një kërkesë për një kohë ekzekutimi të përputhshme me OCI-në systemd-nspawn.
Përfundim
Drejtimi i sistemuar në një kontejner është një nevojë e kuptueshme. Dhe falë Podman, më në fund kemi një kohëzgjatje kontejneri që nuk bie ndesh me systemd, por e bën të lehtë për t'u përdorur.
Burimi: www.habr.com