Keyrir systemd í gámi

Við höfum fylgst með efninu að nota systemd í gámum í langan tíma. Árið 2014 skrifaði öryggisverkfræðingur okkar Daniel Walsh grein Keyrir systemd innan Docker Container, og nokkrum árum síðar - annað, sem kallað var Keyrir systemd í gám sem ekki hefur forréttindi, þar sem hann sagði að ástandið hefði ekki batnað mikið. Sérstaklega skrifaði hann að „því miður, jafnvel tveimur árum síðar, ef þú googlar „Docker system“, er það fyrsta sem kemur upp sama gamla greinin hans. Svo það er kominn tími til að breyta einhverju." Að auki höfum við þegar talað um átök milli Docker og systemd forritara.

Keyrir systemd í gámi

Í þessari grein munum við sýna hvað hefur breyst í gegnum tíðina og hvernig Podman getur hjálpað okkur í þessu máli.

Það eru margar ástæður til að keyra systemd inni í gámi, svo sem:

  1. Fjölþjónustugámar – margir vilja draga fjölþjónustuforritin sín úr sýndarvélum og keyra þau í gámum. Það væri auðvitað betra að skipta slíkum forritum í örþjónustur, en það vita ekki allir hvernig á að gera þetta ennþá eða hafa einfaldlega ekki tíma. Þess vegna er fullkomlega skynsamlegt að keyra slík forrit eins og þjónustu sem er hleypt af stokkunum af systemd úr einingaskrám.
  2. Systemd Unit Files - Flest forrit sem keyra inni í gámum eru byggð úr kóða sem áður keyrði á sýndar- eða líkamlegum vélum. Þessi forrit eru með einingaskrá sem var skrifuð fyrir þessi forrit og skilur hvernig þau ættu að vera ræst. Svo það er samt betra að hefja þjónustu með studdum aðferðum, frekar en að hakka inn þína eigin init þjónustu.
  3. Systemd er vinnslustjóri. Það sér um þjónustustjórnun (að loka, endurræsa þjónustu eða drepa uppvakningaferla) betur en nokkurt annað tól.

Sem sagt, það eru margar ástæður fyrir því að keyra ekki systemd í gámum. Aðalatriðið er að systemd/journald stjórnar framleiðslu gáma og verkfærum eins og Kubernetes eða opnunarvakt búast við að gámar skrifi log beint í stdout og stderr. Þess vegna, ef þú ætlar að stjórna gámum í gegnum hljómsveitarverkfæri eins og þau sem nefnd eru hér að ofan, ættir þú alvarlega að íhuga að nota kerfisbundna gáma. Að auki hafa Docker og Moby verktaki oft verið mjög á móti því að nota systemd í gámum.

Koma Podman

Það gleður okkur að segja frá því að ástandið hefur loksins færst lengra. Teymið sem ber ábyrgð á rekstri gáma á Red Hat ákvað að þróa þinn eigin gámavél. Hann fékk nafn Podman og býður upp á sama skipanalínuviðmót (CLI) og Docker. Og næstum allar Docker skipanir er hægt að nota í Podman á sama hátt. Við höldum oft málstofur, sem nú heita Breytir Docker í Podman, og fyrsta glæran kallar á skrif: alias docker=podman.

Margir gera þetta.

Podman minn og ég erum á engan hátt á móti kerfisbundnum gámum. Þegar öllu er á botninn hvolft er Systemd algengasta Linux init undirkerfið og að leyfa því ekki að virka almennilega í gámum þýðir að hunsa hvernig þúsundir manna eru vanir að keyra gáma.

Podman veit hvað á að gera til að láta systemd virka rétt í gámi. Það þarf hluti eins og að tengja tmpfs á /run og /tmp. Henni finnst gaman að hafa „containerized“ umhverfið virkt og býst við skrifheimildum á sinn hluta af cgroup möppunni og í /var/log/journald möppuna.

Þegar þú ræsir gám þar sem fyrsta skipunin er init eða systemd, stillir Podman sjálfkrafa tmpfs og Cgroups til að tryggja að systemd ræsist án vandræða. Til að loka fyrir þessa sjálfvirku ræsingarstillingu skaltu nota --systemd=false valkostinn. Vinsamlegast athugaðu að Podman notar aðeins systemd ham þegar það sér að það þarf að keyra systemd eða init skipun.

Hér er útdráttur úr handbókinni:

maður podman hlaupa
...

–systemd=true|false

Keyrir gám í systemd ham. Sjálfgefið virkt.

Ef þú keyrir systemd eða init skipun inni í gámi mun Podman stilla tmpfs tengipunkta í eftirfarandi möppum:

/run, /run/lock, /tmp, /sys/fs/cgroup/systemd, /var/lib/journal

Einnig verður sjálfgefið stöðvunarmerki SIGRTMIN+3.

Allt þetta gerir systemd kleift að keyra í lokuðum íláti án nokkurra breytinga.

ATH: systemd reynir að skrifa í cgroup skráarkerfið. Hins vegar kemur SELinux í veg fyrir að gámar geri þetta sjálfgefið. Til að virkja ritun, virkjaðu container_manage_cgroup boolean færibreytuna:

setsebool -P container_manage_cgroup satt

Skoðaðu nú hvernig Dockerfile lítur út til að keyra systemd í gámi með Podman:

# cat Dockerfile

FROM fedora

RUN dnf -y install httpd; dnf clean all; systemctl enable httpd

EXPOSE 80

CMD [ "/sbin/init" ]

Það er allt og sumt.

Nú setjum við saman ílátið:

# podman build -t systemd .

Við segjum SELinux að leyfa systemd að breyta Cgroups stillingum:

# setsebool -P container_manage_cgroup true

Við the vegur, margir gleyma þessu skrefi. Sem betur fer þarf þetta aðeins að gera einu sinni og stillingin er vistuð eftir að kerfið er endurræst.

Nú er bara að byrja ílátinu:

# 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.

Það er það, þjónustan er í gangi:

$ curl localhost

<html  xml_lang="en" lang="en">

…

</html>

ATH: Ekki reyna þetta á Docker! Þar þarftu samt að dansa við bumbuna til að hleypa svona gámum í gegnum púkann. (Viðbótarreitir og pakkar verða nauðsynlegir til að allt virki óaðfinnanlega í Docker, eða það verður að keyra það í forréttindagámi. Fyrir frekari upplýsingar, sjá grein.)

Nokkrir flottir hlutir í viðbót um Podman og systemd

Podman virkar betur en Docker í systemd einingaskrám

Ef ræsa þarf gáma þegar kerfið ræsir, þá geturðu einfaldlega sett viðeigandi Podman skipanir inn í systemd einingaskrána, sem mun ræsa þjónustuna og fylgjast með henni. Podman notar staðlaða gaffal-exec líkanið. Með öðrum orðum, gámaferli eru börn Podman ferlisins, svo systemd getur auðveldlega fylgst með þeim.

Docker notar biðlara-miðlara líkan og Docker CLI skipanir er einnig hægt að setja beint í einingaskrá. Hins vegar, þegar Docker viðskiptavinurinn tengist Docker púknum, verður hann (viðskiptavinurinn) bara enn eitt ferli vinnslu stdin og stdout. Aftur á móti hefur systemd enga hugmynd um tenginguna milli Docker biðlarans og gámsins sem keyrir undir stjórn Docker púkans, og því innan þessa líkans getur systemd í grundvallaratriðum ekki fylgst með þjónustunni.

Virkjar systemd í gegnum fals

Podman sér um virkjun í gegnum fals á réttan hátt. Vegna þess að Podman notar fork-exec líkanið getur það framsent innstunguna í undirgámaferli þess. Docker getur ekki gert þetta vegna þess að það notar biðlara-miðlara líkan.

Varlink þjónustan sem Podman notar til að hafa samskipti við ytri viðskiptavini til gáma er í raun virkjuð í gegnum fals. Cockpit-podman pakkinn, skrifaður í Node.js og hluti af cockpit verkefninu, gerir fólki kleift að hafa samskipti við Podman gáma í gegnum vefviðmót. Vefpúkinn sem keyrir cockpit-podman sendir skilaboð í varlink tengi sem systemd hlustar á. Systemd virkjar síðan Podman forritið til að taka á móti skilaboðum og byrja að stjórna gámum. Að virkja systemd yfir fals útilokar þörfina fyrir stöðugt keyrandi púka þegar innleiðing á ytri API er framkvæmd.

Að auki erum við að þróa annan Podman viðskiptavin sem heitir podman-remote, sem útfærir sama Podman CLI en kallar varlink til að keyra gáma. Podman-fjarstýring getur keyrt ofan á SSH lotur, sem gerir þér kleift að hafa örugg samskipti við ílát á mismunandi vélum. Með tímanum ætlum við að gera podman-remote kleift að styðja MacOS og Windows samhliða Linux, svo að forritarar á þeim kerfum geti keyrt Linux sýndarvél með Podman varlink í gangi og haft fulla reynslu af því að gámar eru í gangi á staðbundinni vél.

SD_NOTIFY

Systemd gerir þér kleift að fresta opnun aukaþjónustu þar til gámaþjónustan sem þeir þurfa hefst. Podman getur framsent SD_NOTIFY falsið til gámaþjónustunnar þannig að þjónustan tilkynni systemd að hún sé tilbúin til notkunar. Og aftur, Docker, sem notar biðlara-miðlara líkan, getur ekki gert þetta.

Í áætlunum

Við ætlum að bæta við skipuninni podman generate systemd CONTAINERID, sem mun búa til systemd einingaskrá til að stjórna tilteknum íláti sem tilgreint er. Þetta ætti að virka bæði í rótar- og rótlausum stillingum fyrir óforréttinda ílát. Við höfum meira að segja séð beiðni um OCI-samhæfðan systemd-nspawn keyrslutíma.

Ályktun

Að keyra systemd í gámi er skiljanleg þörf. Og þökk sé Podman, höfum við loksins gámakeyrslu sem stangast ekki á við systemd, en gerir það auðvelt í notkun.

Heimild: www.habr.com

Bæta við athugasemd