Kuendesha mfumo kwenye chombo

Tumekuwa tukifuata mada ya kutumia systemd kwenye vyombo kwa muda mrefu. Huko nyuma mnamo 2014, mhandisi wetu wa usalama Daniel Walsh aliandika nakala Kuendesha mfumo ndani ya Chombo cha Docker, na miaka michache baadaye - nyingine, ambayo iliitwa Kuendesha mfumo katika chombo kisicho na upendeleo, ambapo alisema kuwa hali haijaimarika sana. Hasa, aliandika kwamba "kwa bahati mbaya, hata miaka miwili baadaye, ikiwa una google "mfumo wa Docker", jambo la kwanza linalokuja ni makala yake ya zamani. Kwa hivyo ni wakati wa kubadilisha kitu." Kwa kuongeza, tumezungumza tayari mzozo kati ya Docker na watengenezaji wa mfumo.

Katika makala hii tutaonyesha nini kimebadilika kwa muda na jinsi Podman inaweza kutusaidia katika suala hili.

Kuna sababu nyingi za kuendesha systemd ndani ya chombo, kama vile:

1. Vyombo vya huduma nyingi - watu wengi wanataka kuvuta programu zao za huduma nyingi kutoka kwa mashine pepe na kuziendesha kwenye vyombo. Itakuwa bora, kwa kweli, kuvunja programu kama hizo kwa huduma ndogo, lakini sio kila mtu anajua jinsi ya kufanya hivyo bado au hana wakati. Kwa hivyo, kuendesha programu kama vile huduma zilizozinduliwa na systemd kutoka kwa faili za kitengo kunaleta maana kamili.
2. Faili za Kitengo cha Mfumo - Programu nyingi zinazoendeshwa ndani ya kontena hujengwa kutoka kwa msimbo ambao hapo awali uliendeshwa kwenye mashine pepe au halisi. Programu hizi zina faili ya kitengo ambayo iliandikwa kwa programu hizi na inaelewa jinsi zinapaswa kuzinduliwa. Kwa hivyo bado ni bora kuanza huduma kwa kutumia njia zinazotumika, badala ya kudukua huduma yako ya init.
3. Systemd ni msimamizi wa mchakato. Inadhibiti huduma (huzima, kuanzisha upya huduma, au kuua michakato ya zombie) bora kuliko zana nyingine yoyote.

Hiyo ilisema, kuna sababu nyingi za kutoendesha mfumo kwenye vyombo. Ya kuu ni kwamba systemd/journald inadhibiti matokeo ya vyombo, na zana kama Mabernet au openshift tarajia kontena kuandika logi moja kwa moja kwa stdout na stderr. Kwa hivyo, ikiwa utadhibiti vyombo kupitia zana za upangaji kama zile zilizotajwa hapo juu, unapaswa kuzingatia kwa umakini kutumia vyombo vyenye mfumo. Kwa kuongeza, watengenezaji wa Docker na Moby mara nyingi wamekuwa wakipinga vikali kutumia systemd kwenye vyombo.

Kuja kwa Podman

Tuna furaha kuripoti kwamba hali hatimaye imesonga mbele. Timu inayohusika na kuendesha vyombo kwenye Red Hat iliamua kuunda injini yako ya kontena. Alipata jina podman na inatoa kiolesura sawa cha mstari wa amri (CLI) kama Docker. Na karibu amri zote za Docker zinaweza kutumika katika Podman kwa njia ile ile. Mara nyingi tunafanya semina, ambazo sasa zinaitwa Kubadilisha Docker kuwa Podman, na slaidi ya kwanza kabisa inahitaji kuandikwa: alias docker=podman.

Watu wengi hufanya hivi.

Podman yangu na mimi sio kwa njia yoyote dhidi ya vyombo vilivyo na mfumo. Baada ya yote, Systemd ndio mfumo mdogo wa Linux init unaotumika sana, na kutouruhusu kufanya kazi vizuri kwenye kontena inamaanisha kupuuza jinsi maelfu ya watu wamezoea kuendesha vyombo.

Podman anajua nini cha kufanya ili kufanya systemd kufanya kazi vizuri kwenye kontena. Inahitaji vitu kama kuweka tmpfs kwenye /run na /tmp. Anapenda kuwa na mazingira ya "containerized" na anatarajia ruhusa za kuandika kwa sehemu yake ya saraka ya kikundi na kwa /var/log/journald folda.

Unapoanzisha chombo ambamo amri ya kwanza ni init au systemd, Podman husanidi kiotomatiki tmpfs na Cgroups ili kuhakikisha kuwa systemd inaanza bila matatizo. Ili kuzuia hali hii ya uzinduzi otomatiki, tumia --systemd=false chaguo. Tafadhali kumbuka kuwa Podman hutumia hali ya mfumo tu inapoona kwamba inahitaji kutekeleza amri ya systemd au init.

Hapa kuna nukuu kutoka kwa mwongozo:

mtu podman kukimbia
...

-systemd=kweli|uongo

Kuendesha chombo katika hali ya mfumo. Imewashwa kwa chaguomsingi.

Ukiendesha systemd au init amri ndani ya kontena, Podman itasanidi sehemu za kuweka tmpfs katika saraka zifuatazo:

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

Pia ishara ya kusimamisha chaguo-msingi itakuwa SIGRTMIN+3.

Yote hii inaruhusu systemd kukimbia kwenye chombo kilichofungwa bila marekebisho yoyote.

KUMBUKA: systemd inajaribu kuandika kwa mfumo wa faili wa kikundi. Walakini, SELinux inazuia vyombo kufanya hivi kwa chaguo-msingi. Ili kuwezesha uandishi, wezesha kigezo cha boolean cha container_manage_cgroup:

setsebool -P container_manage_cgroup kweli

Sasa angalia jinsi Dockerfile inavyoonekana kwa kuendesha systemd kwenye chombo kwa kutumia Podman:

# cat Dockerfile

FROM fedora

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

EXPOSE 80

CMD [ "/sbin/init" ]

Ni hayo tu.

Sasa tunakusanya chombo:

# podman build -t systemd .

Tunaiambia SELinux kuruhusu systemd kurekebisha usanidi wa Cgroups:

# setsebool -P container_manage_cgroup true

Kwa njia, watu wengi husahau kuhusu hatua hii. Kwa bahati nzuri, hii inahitaji kufanywa mara moja tu na mpangilio huhifadhiwa baada ya kuanzisha upya mfumo.

Sasa tunaanza tu chombo:

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

Hiyo ndiyo yote, huduma inaendelea na inaendelea:

$ curl localhost

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

…

</html>

KUMBUKA: Usijaribu hii kwenye Docker! Huko bado unahitaji kucheza na tari kuzindua aina hizi za vyombo kupitia daemon. (Nyuga na vifurushi vya ziada vitahitajika ili kufanya haya yote kufanya kazi bila mshono katika Docker, au itahitaji kuendeshwa katika chombo maalum. Kwa maelezo, angalia Ibara ya.)

Mambo kadhaa mazuri kuhusu Podman na systemd

Podman inafanya kazi vizuri zaidi kuliko Docker katika faili za kitengo cha systemd

Ikiwa vyombo vinahitaji kuanza wakati boti za mfumo, basi unaweza tu kuingiza amri zinazofaa za Podman kwenye faili ya kitengo cha mfumo, ambayo itaanza huduma na kuifuatilia. Podman hutumia mfano wa kawaida wa fork-exec. Kwa maneno mengine, michakato ya chombo ni watoto wa mchakato wa Podman, kwa hivyo systemd inaweza kuwafuatilia kwa urahisi.

Docker hutumia mfano wa seva ya mteja, na amri za Docker CLI pia zinaweza kuwekwa moja kwa moja kwenye faili ya kitengo. Walakini, mara tu mteja wa Docker akiunganishwa na daemon ya Docker, (mteja) inakuwa mchakato mwingine wa usindikaji stdin na stdout. Kwa upande mwingine, systemd haina wazo juu ya muunganisho kati ya mteja wa Docker na kontena inayoendeshwa chini ya udhibiti wa daemon ya Docker, na kwa hivyo, ndani ya modeli hii, systemd kimsingi haiwezi kufuatilia huduma.

Inawasha mfumo kupitia soketi

Podman hushughulikia kuwezesha kupitia soketi kwa usahihi. Kwa sababu Podman hutumia mfano wa fork-exec, inaweza kusambaza tundu kwa michakato ya kontena la mtoto. Docker haiwezi kufanya hivi kwa sababu inatumia mfano wa seva ya mteja.

Huduma ya varlink ambayo Podman hutumia kuwasiliana na wateja wa mbali kwa kontena imeamilishwa kupitia soketi. Kifurushi cha cockpit-podman, kilichoandikwa katika Node.js na sehemu ya mradi wa chumba cha rubani, huruhusu watu kuingiliana na vyombo vya Podman kupitia kiolesura cha wavuti. Daemon ya wavuti inayoendesha cockpit-podman hutuma ujumbe kwa soketi ya varlink ambayo systemd inasikiliza. Systemd kisha huwasha programu ya Podman ili kupokea ujumbe na kuanza kudhibiti vyombo. Kuamilisha mfumo juu ya soketi huondoa hitaji la daemon inayoendelea kila wakati wakati wa kutekeleza API za mbali.

Zaidi ya hayo, tunatengeneza mteja mwingine wa Podman aitwaye podman-remote, ambayo hutekeleza Podman CLI sawa lakini huita varlink kuendesha vyombo. Kidhibiti cha mbali cha Podman kinaweza kufanya kazi juu ya vipindi vya SSH, kukuwezesha kuingiliana kwa usalama na vyombo kwenye mashine tofauti. Baada ya muda, tunapanga kuwezesha podman-remote ili kutumia MacOS na Windows pamoja na Linux, ili wasanidi programu kwenye mifumo hiyo waweze kuendesha mashine pepe ya Linux inayoendeshwa na Podman varlink na kuwa na utumiaji kamili wa vyombo vinavyotumika kwenye mashine ya ndani.

SD_TAARIFA

Systemd hukuruhusu kuahirisha uzinduzi wa huduma za usaidizi hadi huduma iliyojumuishwa wanayohitaji ianze. Podman inaweza kusambaza soketi ya SD_NOTIFY kwa huduma iliyo kwenye kontena ili huduma ijulishe systemd kuwa iko tayari kufanya kazi. Na tena, Docker, ambayo hutumia mfano wa seva ya mteja, haiwezi kufanya hivi.

Katika mipango

Tunapanga kuongeza amri podman generate systemd CONTAINERID, ambayo itazalisha faili ya kitengo cha mfumo ili kudhibiti kontena maalum iliyobainishwa. Hii inapaswa kufanya kazi kwa njia zote mbili za mizizi na zisizo na mizizi kwa vyombo visivyo na bahati. Tumeona hata ombi la wakati wa utekelezaji wa systemd-nspawn unaooana na OCI.

Hitimisho

Kuendesha mfumo kwenye chombo ni hitaji linaloeleweka. Na shukrani kwa Podman, hatimaye tunayo wakati wa kukimbia wa kontena ambao haupingani na systemd, lakini hurahisisha kutumia.

Chanzo: mapenzi.com