Kita wis ngetutake topik nggunakake systemd ing wadhah kanggo wektu sing suwe. Mbalik ing 2014, insinyur keamanan kita Daniel Walsh nulis artikel , lan saperangan saka taun mengko - liyane, kang diarani , ing ngendi dheweke nyatakake yen kahanan kasebut durung saya apik. Utamane, dheweke nulis yen "sayange, sanajan rong taun mengko, yen sampeyan google" sistem Docker ", sing pisanan muncul yaiku artikel lawas sing padha. Dadi iki wektu kanggo ngganti soko. Kajaba iku, kita wis ngomong babagan .
Ing artikel iki, kita bakal nuduhake apa sing wis owah saka wektu lan carane Podman bisa mbantu kita ing perkara iki.
Ana akeh alasan kanggo mbukak systemd ing wadhah, kayata:
- kontaner multiservice - akeh wong pengin narik aplikasi multi-layanan saka mesin virtual lan mbukak ing kontaner. Mesthi wae, luwih becik ngilangi aplikasi kasebut dadi layanan mikro, nanging ora kabeh wong ngerti carane nindakake iki utawa mung ora duwe wektu. Mulane, nglakokake aplikasi kayata layanan sing diluncurake dening systemd saka file unit ndadekake pangertèn sing sampurna.
- File Unit Systemd - Umume aplikasi sing mlaku ing wadhah dibangun saka kode sing sadurunge digunakake ing mesin virtual utawa fisik. Aplikasi kasebut duwe file unit sing ditulis kanggo aplikasi kasebut lan ngerti carane kudu diluncurake. Dadi isih luwih apik kanggo miwiti layanan nggunakake metode sing didhukung, tinimbang hack layanan init sampeyan dhewe.
- Systemd minangka manajer proses. Ngatur layanan (mati, miwiti maneh layanan, utawa mateni proses zombie) luwih apik tinimbang alat liyane.
Ngandika, ana akeh alasan kanggo ora mbukak systemd ing kontaner. Sing utama yaiku systemd / jurnal ngontrol output kontainer, lan alat kaya utawa nyana kontaner nulis log langsung menyang stdout lan stderr. Mulane, yen sampeyan arep ngatur kontaner liwat alat orkestrasi kaya sing kasebut ing ndhuwur, sampeyan kudu nimbang kanthi serius nggunakake wadhah berbasis systemd. Kajaba iku, pangembang Docker lan Moby asring banget nentang nggunakake systemd ing wadhah.
Rawuhipun Podman
Kita seneng nglaporake manawa kahanan pungkasane maju. Tim sing tanggung jawab kanggo mbukak kontainer ing Red Hat mutusake kanggo berkembang . Dheweke entuk jeneng lan nawakake antarmuka baris printah padha (CLI) minangka Docker. Lan meh kabeh perintah Docker bisa digunakake ing Podman kanthi cara sing padha. Kita asring nganakake seminar, sing saiki diarani , lan slide sing paling pisanan kudu nulis: alias docker = podman.
Akeh wong sing nglakoni kaya ngono.
Aku lan Podman ora nglawan kontaner adhedhasar systemd. Sawise kabeh, Systemd minangka subsistem init Linux sing paling umum digunakake, lan ora ngidini supaya bisa digunakake kanthi bener ing kontaner tegese ora nggatekake kepiye ewonan wong wis biasa nganggo wadah.
Podman ngerti apa sing kudu ditindakake supaya systemd bisa digunakake kanthi bener ing wadhah. Perlu kaya masang tmpfs ing /run lan /tmp. Dheweke seneng ngaktifake lingkungan "wadhah" lan ngarepake ijin nulis menyang bagean direktori cgroup lan menyang folder /var/log/journald.
Nalika sampeyan miwiti wadhah kanthi printah pisanan yaiku init utawa systemd, Podman kanthi otomatis ngatur tmpfs lan Cgroups kanggo mesthekake yen systemd diwiwiti tanpa masalah. Kanggo mblokir mode peluncuran otomatis iki, gunakake pilihan --systemd=false. Wigati dimangerteni manawa Podman mung nggunakake mode systemd nalika ndeleng manawa kudu mbukak perintah systemd utawa init.
Mangkene kutipan saka manual:
wong podman mlayu
...βsystemd=bener|palsu
Mbukak wadhah ing mode systemd. Diaktifake kanthi gawan.
Yen sampeyan mbukak perintah systemd utawa init ing njero wadhah, Podman bakal ngatur titik gunung tmpfs ing direktori ing ngisor iki:
/run, /run/lock, /tmp, /sys/fs/cgroup/systemd, /var/lib/journal
Uga sinyal mandeg standar yaiku SIGRTMIN + 3.
Kabeh iki ngidini systemd mbukak ing wadhah sing ditutup tanpa modifikasi.
CATETAN: systemd nyoba nulis menyang sistem file cgroup. Nanging, SELinux nyegah kontainer nindakake iki kanthi standar. Kanggo ngaktifake nulis, aktifake parameter boolean container_manage_cgroup:
setsebool -P container_manage_cgroup bener
Saiki deleng apa Dockerfile katon kanggo mbukak systemd ing wadhah nggunakake Podman:
# cat Dockerfile
FROM fedora
RUN dnf -y install httpd; dnf clean all; systemctl enable httpd
EXPOSE 80
CMD [ "/sbin/init" ]
Mekaten.
Saiki kita ngumpulake wadah:
# podman build -t systemd .
Kita ngandhani SELinux supaya ngidini systemd ngowahi konfigurasi Cgroups:
# setsebool -P container_manage_cgroup true
Miturut cara, akeh wong lali babagan langkah iki. Untunge, iki mung kudu ditindakake sapisan lan setelan kasebut disimpen sawise reboot sistem.
Saiki kita mung miwiti wadhah:
# 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.
Mekaten, layanan wis aktif:
$ curl localhost
<html xml_lang="en" lang="en">
β¦
</html>
CATETAN: Aja nyoba iki ing Docker! Ing kana sampeyan isih kudu nari nganggo rebana kanggo ngluncurake wadhah kasebut liwat daemon. (Kotak lan paket tambahan bakal dibutuhake supaya kabeh iki bisa digunakake kanthi lancar ing Docker, utawa kudu mbukak ing wadhah khusus. Kanggo rincian, deleng .)
A saperangan liyane kelangan bab Podman lan systemd
Podman luwih apik tinimbang Docker ing file unit systemd
Yen kontaner kudu diwiwiti nalika sistem boot, sampeyan mung bisa nglebokake perintah Podman sing cocog menyang file unit systemd, sing bakal miwiti layanan lan ngawasi. Podman nggunakake model fork-exec standar. Ing tembung liyane, pangolahan wadhah minangka anak saka proses Podman, supaya systemd bisa ngawasi kanthi gampang.
Docker nggunakake model klien-server, lan perintah Docker CLI uga bisa diselehake langsung ing file unit. Nanging, yen klien Docker nyambung menyang daemon Docker, iku (klien) dadi mung proses pangolahan stdin lan stdout. Sabanjure, systemd ora ngerti babagan sambungan antarane klien Docker lan wadhah sing ana ing kontrol daemon Docker, lan mulane, ing model iki, systemd dhasar ora bisa ngawasi layanan kasebut.
Ngaktifake systemd liwat soket
Podman nangani aktivasi liwat soket kanthi bener. Amarga Podman nggunakake model fork-exec, bisa nerusake soket menyang proses wadhah anak. Docker ora bisa nindakake iki amarga nggunakake model klien-server.
Layanan varlink sing digunakake Podman kanggo komunikasi karo klien remot menyang kontaner bener-bener diaktifake liwat soket. Paket kokpit-podman, ditulis ing Node.js lan bagΓ©an saka project kokpit, ngidini wong kanggo sesambungan karo wadhah Podman liwat antarmuka web. Daemon web sing mlaku kokpit-podman ngirim pesen menyang soket varlink sing dirungokake systemd. Systemd banjur ngaktifake program Podman kanggo nampa pesen lan miwiti ngatur wadhah. Ngaktifake systemd liwat soket ngilangi kabutuhan daemon sing terus-terusan nalika ngetrapake API remot.
Kajaba iku, kita ngembangake klien Podman liyane sing diarani podman-remote, sing ngetrapake Podman CLI sing padha nanging nelpon varlink kanggo mbukak kontaner. Podman-remote bisa mbukak ing ndhuwur mau SSH, ngijini sampeyan kanggo aman sesambungan karo kontaner ing mesin beda. Swara wektu, kita rencana kanggo ngaktifake podman-remote ndhukung MacOS lan Windows bebarengan Linux, supaya pangembang ing platform sing bisa mbukak mesin virtual Linux karo Podman varlink mlaku lan duwe pengalaman lengkap sing kontaner mlaku ing mesin lokal.
SD_NOTIFY
Systemd ngidini sampeyan nundha peluncuran layanan tambahan nganti layanan kontaner sing dibutuhake diwiwiti. Podman bisa nerusake soket SD_NOTIFY menyang layanan containerized supaya layanan ngabari systemd sing wis siyap kanggo operate. Lan maneh, Docker, sing nggunakake model klien-server, ora bisa nindakake iki.
Ing rencana
We rencana kanggo nambah printah podman generate systemd CONTAINERID, kang bakal generate file unit systemd kanggo ngatur wadhah tartamtu kasebut. Iki kudu bisa digunakake ing mode root lan rootless kanggo wadhah sing ora duwe hak istimewa. Kita malah wis ndeleng panjalukan kanggo runtime systemd-nspawn sing kompatibel karo OCI.
kesimpulan
Mlaku systemd ing wadhah minangka kabutuhan sing bisa dingerteni. Lan thanks kanggo Podman, pungkasanipun kita duwe runtime wadhah sing ora konflik karo systemd, nanging nggampangake nggunakake.
Source: www.habr.com