Aspalditik ari gara systemd edukiontzietan erabiltzearen gaia jarraitzen. 2014an, gure segurtasun ingeniari Daniel Walsh artikulu bat idatzi zuen , eta pare bat urte geroago - beste bat, deitzen zena , eta bertan adierazi zuen egoera ez dela asko hobetu. Bereziki, idatzi zuen: "zoritxarrez, bi urte geroago ere, "Docker sistema" Googlen bilatzen baduzu, ateratzen den lehen gauza bere artikulu zaharra da. Beraz, zerbait aldatzeko garaia daΒ». Horrez gain, dagoeneko hitz egin dugu .
Artikulu honetan denboran zehar zer aldatu den eta Podman-ek gai honetan nola lagundu diezagukeen erakutsiko dugu.
Systemd edukiontzi baten barruan exekutatzeko arrazoi asko daude, hala nola:
- Zerbitzu anitzeko edukiontziak - Jende askok zerbitzu anitzeko aplikazioak makina birtualetatik atera eta edukiontzietan exekutatu nahi ditu. Hobe litzateke, noski, horrelako aplikazioak mikrozerbitzuetan apurtzea, baina denek ez daki oraindik nola egin edo, besterik gabe, ez dute denborarik. Hori dela eta, systemd-ek abiarazitako zerbitzuak bezalako aplikazioak unitate-fitxategietatik exekutatzeak oso zentzuzkoa du.
- Systemd unitate-fitxategiak β Edukiontzi barruan exekutatzen diren aplikazio gehienak aurrez makina birtualetan edo fisikoetan exekutatzen ziren kodetik eraikitzen dira. Aplikazio hauek unitate-fitxategi bat dute, aplikazio horietarako idatzitakoa eta nola abiarazi behar diren ulertzen du. Beraz, oraindik hobe da zerbitzuak onartzen diren metodoak erabiliz hastea, zure init zerbitzua pirateatzea baino.
- Systemd prozesu kudeatzailea da. Beste edozein tresna baino hobeto kudeatzen ditu zerbitzuak (itzali, zerbitzuak berrabiarazi edo zonbi prozesuak hiltzen ditu).
Hori bai, arrazoi asko daude systemd edukiontzietan ez exekutatzeko. Nagusia da systemd/journald-ek edukiontzien eta antzeko tresnen irteera kontrolatzen duela edo espero edukiontziak erregistroa zuzenean idaztea stdout eta stderr-en. Hori dela eta, goian aipatutakoak bezalako orkestrazio tresnen bidez edukiontziak kudeatuko badituzu, serioski kontuan hartu beharko zenuke systemd-en oinarritutako edukiontziak erabiltzea. Gainera, Docker eta Moby garatzaileek askotan systemd edukiontzietan erabiltzearen aurka agertu dira.
Podmanen etorrera
Pozik gaude egoerak azkenean aurrera egin duela jakinarazteko. Red Hat-en edukiontziak martxan jartzeaz arduratzen den taldeak garatzea erabaki zuen . Izen bat lortu zuen eta Dockerren komando lerroko interfazea (CLI) bera eskaintzen du. Eta ia Docker komando guztiak Podman-en erabil daitezke modu berean. Askotan egiten ditugu mintegiak, gaur egun deitzen direnak , eta lehen diapositibak idazteko deia egiten du: alias docker=podman.
Jende askok egiten du hau.
Nire Podman eta ni ez gaude inolaz ere systemd-en oinarritutako edukiontzien aurka. Azken finean, Systemd Linux init azpisistema erabiliena da, eta edukiontzietan behar bezala funtzionatzen ez uzteak milaka pertsona edukiontziak exekutatzen nola ohituta dauden alde batera utzi behar du.
Podman-ek badaki zer egin behar den sistemak edukiontzi batean behar bezala funtziona dezan. Gauzak behar ditu /run eta /tmp-en tmpfs muntatzea. Ingurune "edukiontziz" gaituta izatea gustatzen zaio eta idazteko baimenak espero ditu cgroup direktorioko bere zatian eta /var/log/journald karpetan.
Lehenengo komandoa init edo systemd den edukiontzi bat abiarazten duzunean, Podman-ek automatikoki konfiguratzen ditu tmpfs eta Cgroups, systemd arazorik gabe abiarazten dela ziurtatzeko. Abiarazteko modu automatiko hau blokeatzeko, erabili --systemd=false aukera. Kontuan izan Podman-ek systemd modua soilik erabiltzen duela systemd edo init komando bat exekutatu behar duela ikusten duenean.
Hona hemen eskuliburuaren pasarte bat:
gizon podman korrika
...βsystemd=egia|gezurra
Edukiontzi bat exekutatzen systemd moduan. Lehenespenez gaituta.
Edukiontzi baten barruan systemd edo init komando bat exekutatzen baduzu, Podman-ek tmpfs muntaketa-puntuak konfiguratuko ditu direktorio hauetan:
/run, /run/lock, /tmp, /sys/fs/cgroup/systemd, /var/lib/journal
Gainera, gelditzeko seinale lehenetsia SIGRTMIN+3 izango da.
Horri guztiari esker, systemd edukiontzi itxi batean exekutatzen da inolako aldaketarik gabe.
OHARRA: systemd cgroup fitxategi-sisteman idazten saiatzen da. Dena den, SELinux-ek edukiontziei hori egitea eragozten die lehenespenez. Idazketa gaitzeko, gaitu container_manage_cgroup parametro boolearra:
setsebool -P container_manage_cgroup egia
Begiratu orain Dockerfile-a nolakoa den Podman erabiliz edukiontzi batean systemd exekutatzeko:
# cat Dockerfile
FROM fedora
RUN dnf -y install httpd; dnf clean all; systemctl enable httpd
EXPOSE 80
CMD [ "/sbin/init" ]
Hori da dena.
Orain ontzia muntatzen dugu:
# podman build -t systemd .
SELinux-i esaten diogu systemd-i Cgroups konfigurazioa aldatzeko baimena emateko:
# setsebool -P container_manage_cgroup true
Bide batez, jende askok ahazten du urrats hau. Zorionez, behin bakarrik egin behar da eta ezarpena sistema berrabiarazi ondoren gordetzen da.
Orain edukiontzia hasiko dugu:
# 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.
Hori da, zerbitzua martxan dago:
$ curl localhost
<html xml_lang="en" lang="en">
β¦
</html>
OHARRA: Ez probatu hau Docker-en! Han oraindik danbolinarekin dantza egin behar duzu deabruaren bidez edukiontzi mota hauek abiarazteko. (Eremu eta pakete gehigarriak beharko dira hau guztia ondo funtzionatzeko Docker-en, edo edukiontzi pribilegiatu batean exekutatu beharko da. Xehetasunetarako, ikus .)
Podman eta systemd-i buruzko gauza polit bat gehiago
Podman Docker baino hobeto funtzionatzen du systemd unitate fitxategietan
Sistema abiaraztean edukiontziak martxan jarri behar badira, Podman komando egokiak txerta ditzakezu systemd unitate-fitxategian, eta horrek zerbitzua abiarazi eta kontrolatuko du. Podman-ek fork-exec eredu estandarra erabiltzen du. Beste era batera esanda, edukiontzi-prozesuak Podman prozesuko seme-alabak dira, beraz, systemd-ek erraz kontrola ditzake.
Docker-ek bezero-zerbitzari eredua erabiltzen du, eta Docker CLI komandoak ere zuzenean jar daitezke unitate-fitxategi batean. Hala ere, Docker bezeroa Docker daemonera konektatzen denean, (bezeroa) stdin eta stdout kudeatzen dituen beste prozesu bat bihurtzen da. Era berean, systemd-ek ez du Docker bezeroaren eta Docker deabruaren kontrolpean exekutatzen den edukiontziaren arteko konexioari buruz, eta, beraz, eredu honen barruan, systemd-ek ezin du zerbitzua kontrolatu.
Systemd socket bidez aktibatzen
Podman-ek socket bidezko aktibazioa behar bezala kudeatzen du. Podman-ek fork-exec eredua erabiltzen duenez, socket-a bere edukiontzi haur-prozesuetara birbidal dezake. Docker-ek ezin du hau egin bezero-zerbitzari eredua erabiltzen duelako.
Podman-ek urruneko bezeroekin edukiontzietara komunikatzeko erabiltzen duen varlink zerbitzua socket baten bidez aktibatzen da benetan. Cockpit-podman paketeak, Node.js-en idatzita eta cockpit proiektuaren parte den, jendeak Podman edukiontziekin elkarreragiteko aukera ematen du web-interfaze baten bidez. Cockpit-podman exekutatzen ari den web daemonak sistemak entzuten duen varlink socket batera bidaltzen ditu mezuak. Systemd-ek Podman programa aktibatzen du mezuak jasotzeko eta edukiontziak kudeatzen hasteko. Socket baten bidez systemd aktibatzea etengabe exekutatzen den daemon baten beharra ezabatzen du urruneko APIak ezartzerakoan.
Gainera, podman-remote izeneko beste Podman bezero bat garatzen ari gara, Podman CLI bera inplementatzen duena baina varlink deitzen duena edukiontziak exekutatzeko. Podman-remote SSH saioen gainean exekutatu daiteke, makina ezberdinetako edukiontziekin modu seguruan elkarreragiteko aukera emanez. Denborarekin, podman-remote Linux-ekin batera MacOS eta Windows-ek onartzen dituen gaitzeko asmoa dugu, plataforma horietako garatzaileek Linux makina birtual bat exekutatu dezaten Podman varlink martxan dagoela eta edukiontziak tokiko makinan exekutatzen ari diren esperientzia osoa izan dezaten.
SD_NOTIFY
Systemd-ek zerbitzu osagarrien abiarazte atzeratzea ahalbidetzen du, behar duten edukiontzidun zerbitzua hasi arte. Podman-ek SD_NOTIFY socket-a edukiontzidun zerbitzura birbidal dezake, zerbitzuak systemd-i funtzionatzeko prest dagoela jakinarazteko. Eta berriro ere, bezero-zerbitzari eredua erabiltzen duen Docker-ek ezin du hori egin.
Planoetan
Podman generate systemd CONTAINERID komandoa gehitzeko asmoa dugu, zehazten den edukiontzi jakin bat kudeatzeko systemd unitate fitxategi bat sortuko duena. Honek erro eta errorik gabeko moduetan funtzionatu beharko luke pribilegiorik gabeko edukiontzietarako. OCI-rekin bateragarria den systemd-nspawn exekuzio-denbora baten eskaera ere ikusi dugu.
Ondorioa
Systemd edukiontzi batean exekutatu beharra ulergarria da. Eta Podman-i esker, azkenik, systemd-ekin gatazkarik ez duen edukiontziaren exekuzio-denbora dugu, baina erabiltzeko erraza egiten duena.
Iturria: www.habr.com