Rydym wedi bod yn dilyn y pwnc o ddefnyddio systemd mewn cynwysyddion ers amser maith. Yn ôl yn 2014, ysgrifennodd ein peiriannydd diogelwch Daniel Walsh erthygl , ac ychydig flynyddoedd yn ddiweddarach - un arall, a gafodd ei alw , lle dywedodd nad oedd y sefyllfa wedi gwella llawer. Yn benodol, ysgrifennodd “yn anffodus, hyd yn oed ddwy flynedd yn ddiweddarach, os ydych chi'n google “Docker system”, y peth cyntaf sy'n dod i fyny yw ei un hen erthygl. Felly mae’n bryd newid rhywbeth.” Yn ogystal, rydym eisoes wedi siarad am .
Yn yr erthygl hon byddwn yn dangos beth sydd wedi newid dros amser a sut y gall Podman ein helpu yn y mater hwn.
Mae yna lawer o resymau dros redeg systemd y tu mewn i gynhwysydd, megis:
- Cynwysyddion aml-wasanaeth - mae llawer o bobl eisiau tynnu eu cymwysiadau aml-wasanaeth allan o beiriannau rhithwir a'u rhedeg mewn cynwysyddion. Byddai'n well, wrth gwrs, torri cymwysiadau o'r fath yn ficrowasanaethau, ond nid yw pawb yn gwybod sut i wneud hyn eto neu nid oes ganddynt yr amser. Felly, mae rhedeg cymwysiadau fel gwasanaethau a lansiwyd gan systemd o ffeiliau uned yn gwneud synnwyr perffaith.
- Ffeiliau Uned Systemd - Mae'r rhan fwyaf o gymwysiadau sy'n rhedeg y tu mewn i gynwysyddion wedi'u hadeiladu o god a oedd yn rhedeg yn flaenorol ar beiriannau rhithwir neu ffisegol. Mae gan y cymwysiadau hyn ffeil uned a ysgrifennwyd ar gyfer y ceisiadau hyn ac mae'n deall sut y dylid eu lansio. Felly mae'n dal yn well dechrau gwasanaethau gan ddefnyddio dulliau â chymorth, yn hytrach na hacio'ch gwasanaeth init eich hun.
- Mae Systemd yn rheolwr proses. Mae'n rheoli gwasanaethau (yn cau i lawr, yn ailgychwyn gwasanaethau, neu'n lladd prosesau zombie) yn well nag unrhyw offeryn arall.
Wedi dweud hynny, mae yna lawer o resymau i beidio â rhedeg systemd mewn cynwysyddion. Y prif un yw bod systemd/journald yn rheoli allbwn cynwysyddion, ac offer fel neu disgwyl i gynwysyddion ysgrifennu log yn uniongyrchol i stdout a stderr. Felly, os ydych chi'n mynd i reoli cynwysyddion trwy offer cerddorfaol fel y rhai a grybwyllir uchod, dylech ystyried o ddifrif defnyddio cynwysyddion systemd. Yn ogystal, mae datblygwyr Docker a Moby yn aml wedi bod yn gryf yn erbyn defnyddio systemd mewn cynwysyddion.
Dyfodiad Podman
Rydym yn hapus i adrodd bod y sefyllfa wedi symud ymlaen o’r diwedd. Penderfynodd y tîm sy'n gyfrifol am redeg cynwysyddion yn Red Hat ddatblygu . Cafodd enw ac yn cynnig yr un rhyngwyneb llinell orchymyn (CLI) â Docker. A gellir defnyddio bron pob gorchymyn Docker yn Podman yn yr un modd. Rydym yn aml yn cynnal seminarau, a elwir bellach , ac mae'r sleid gyntaf un yn galw am ysgrifennu: alias docker=podman.
Mae llawer o bobl yn gwneud hyn.
Nid yw fy Podman a minnau yn erbyn cynwysyddion systemd mewn unrhyw ffordd. Wedi'r cyfan, Systemd yw'r is-system init Linux a ddefnyddir amlaf, ac mae peidio â chaniatáu iddo weithio'n iawn mewn cynwysyddion yn golygu anwybyddu sut mae miloedd o bobl yn gyfarwydd â rhedeg cynwysyddion.
Mae Podman yn gwybod beth i'w wneud i wneud i systemd weithio'n iawn mewn cynhwysydd. Mae angen pethau fel gosod tmpfs ymlaen / rhedeg a /tmp. Mae hi'n hoffi cael yr amgylchedd "cynwysedig" wedi'i alluogi ac mae'n disgwyl caniatâd ysgrifennu i'w rhan hi o'r cyfeiriadur cgroup ac i'r ffolder /var/log/journald.
Pan ddechreuwch gynhwysydd lle mae'r gorchymyn cyntaf wedi'i fewnosod neu systemd, mae Podman yn ffurfweddu tmpfs a Cgroups yn awtomatig i sicrhau bod systemd yn cychwyn heb broblemau. I rwystro'r modd lansio ceir hwn, defnyddiwch yr opsiwn --systemd = ffug. Sylwch fod Podman ond yn defnyddio modd systemd pan fydd yn gweld bod angen iddo redeg gorchymyn systemd neu init.
Dyma ddyfyniad o'r llawlyfr:
rhed podman dyn
...-systemd = gwir | ffug
Rhedeg cynhwysydd yn y modd systemd. Wedi'i alluogi yn ddiofyn.
Os ydych chi'n rhedeg gorchymyn systemd neu init y tu mewn i gynhwysydd, bydd Podman yn ffurfweddu pwyntiau gosod tmpfs yn y cyfeiriaduron canlynol:
/ rhedeg, / rhedeg / cloi, /tmp, /sys/fs/cgroup/systemd, /var/lib/journal
Hefyd y signal stopio rhagosodedig fydd SIGRTMIN+3.
Mae hyn i gyd yn caniatáu i systemd redeg mewn cynhwysydd caeedig heb unrhyw addasiadau.
SYLWCH: ymdrechion systemd i ysgrifennu i'r system ffeiliau cgroup. Fodd bynnag, mae SELinux yn atal cynwysyddion rhag gwneud hyn yn ddiofyn. I alluogi ysgrifennu, galluogwch y paramedr boolean container_manage_cgroup:
setsebool -P container_manage_cgroup yn wir
Nawr edrychwch ar sut olwg sydd ar y Dockerfile ar gyfer rhedeg systemd mewn cynhwysydd gan ddefnyddio Podman:
# cat Dockerfile
FROM fedora
RUN dnf -y install httpd; dnf clean all; systemctl enable httpd
EXPOSE 80
CMD [ "/sbin/init" ]
Dyna i gyd.
Nawr rydym yn cydosod y cynhwysydd:
# podman build -t systemd .
Rydyn ni'n dweud wrth SELinux i ganiatáu i systemd addasu ffurfweddiad Cgroups:
# setsebool -P container_manage_cgroup true
Gyda llaw, mae llawer o bobl yn anghofio am y cam hwn. Yn ffodus, dim ond unwaith y mae angen gwneud hyn a chaiff y gosodiad ei gadw ar ôl ailgychwyn y system.
Nawr rydyn ni newydd ddechrau'r cynhwysydd:
# 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.
Dyna ni, mae'r gwasanaeth ar waith:
$ curl localhost
<html xml_lang="en" lang="en">
…
</html>
SYLWCH: Peidiwch â rhoi cynnig ar hyn ar Docker! Yno mae dal angen dawnsio gyda thambwrîn i lansio'r mathau hyn o gynwysyddion trwy'r ellyll. (Bydd angen meysydd a phecynnau ychwanegol i wneud i hyn oll weithio'n ddi-dor yn Docker, neu bydd angen ei redeg mewn cynhwysydd breintiedig. Am fanylion, gweler .)
Cwpl o bethau mwy cŵl am Podman a systemd
Mae Podman yn gweithio'n well na Docker mewn ffeiliau uned systemd
Os oes angen cychwyn cynwysyddion pan fydd y system yn cychwyn, yna gallwch chi fewnosod y gorchmynion Podman priodol yn y ffeil uned systemd, a fydd yn cychwyn y gwasanaeth ac yn ei fonitro. Mae Podman yn defnyddio'r model fforch-exec safonol. Mewn geiriau eraill, mae prosesau cynhwysydd yn blant o'r broses Podman, felly gall systemd eu monitro'n hawdd.
Mae Docker yn defnyddio model cleient-gweinydd, a gellir gosod gorchmynion CLI Docker hefyd yn uniongyrchol mewn ffeil uned. Fodd bynnag, unwaith y bydd y cleient Docker yn cysylltu â'r daemon Docker, daw (y cleient) yn broses arall sy'n trin stdin a stdout. Yn ei dro, nid oes gan systemd unrhyw syniad am y cysylltiad rhwng y cleient Docker a'r cynhwysydd sy'n rhedeg o dan reolaeth daemon y Docker, ac felly, o fewn y model hwn, ni all systemd fonitro'r gwasanaeth yn sylfaenol.
Ysgogi systemd trwy soced
Mae Podman yn trin actifadu trwy soced yn gywir. Oherwydd bod Podman yn defnyddio'r model fforch-exec, gall anfon y soced ymlaen at ei brosesau cynhwysydd plant. Ni all Docker wneud hyn oherwydd ei fod yn defnyddio model cleient-gweinydd.
Mae'r gwasanaeth varlink y mae Podman yn ei ddefnyddio i gyfathrebu â chleientiaid o bell i gynwysyddion yn cael ei actifadu mewn gwirionedd trwy soced. Mae'r pecyn talwrn-podman, a ysgrifennwyd yn Node.js ac yn rhan o'r prosiect talwrn, yn caniatáu i bobl ryngweithio â chynwysyddion Podman trwy ryngwyneb gwe. Mae'r daemon gwe sy'n rhedeg talwrn-podman yn anfon negeseuon i soced varlink y mae systemd yn gwrando arno. Yna mae Systemd yn actifadu'r rhaglen Podman i dderbyn negeseuon a dechrau rheoli cynwysyddion. Mae actifadu systemd dros soced yn dileu'r angen am ellyll sy'n rhedeg yn gyson wrth weithredu APIs o bell.
Yn ogystal, rydym yn datblygu cleient Podman arall o'r enw podman-remote, sy'n gweithredu'r un Podman CLI ond yn galw varlink i redeg cynwysyddion. Gall Podman-remote redeg ar ben sesiynau SSH, gan ganiatáu i chi ryngweithio'n ddiogel â chynwysyddion ar wahanol beiriannau. Dros amser, rydym yn bwriadu galluogi podman-remote i gefnogi MacOS a Windows ochr yn ochr â Linux, fel y gall datblygwyr ar y llwyfannau hynny redeg peiriant rhithwir Linux gyda Podman varlink yn rhedeg a chael y profiad llawn bod cynwysyddion yn rhedeg ar y peiriant lleol.
SD_NOTIFY
Mae Systemd yn caniatáu ichi ohirio lansio gwasanaethau ategol nes bod y gwasanaeth mewn cynhwysydd sydd ei angen arnynt yn dechrau. Gall Podman anfon y soced SD_NOTIFY ymlaen i'r gwasanaeth cynhwysydd fel bod y gwasanaeth yn hysbysu systemd ei fod yn barod i weithredu. Ac eto, ni all Docker, sy'n defnyddio model cleient-gweinydd, wneud hyn.
Yn y cynlluniau
Rydym yn bwriadu ychwanegu'r gorchymyn podman cynhyrchu CONTAINERID systemd, a fydd yn cynhyrchu ffeil uned systemd i reoli cynhwysydd penodol a nodir. Dylai hyn weithio mewn moddau gwraidd a di-wreiddyn ar gyfer cynwysyddion difreintiedig. Rydym hyd yn oed wedi gweld cais am amser rhedeg systemd-nspawn sy'n gydnaws â OCI.
Casgliad
Mae rhedeg systemd mewn cynhwysydd yn angen dealladwy. A diolch i Podman, o'r diwedd mae gennym ni amser rhedeg cynhwysydd nad yw'n gwrthdaro â systemd, ond sy'n ei gwneud hi'n hawdd ei ddefnyddio.
Ffynhonnell: hab.com