Régóta követjük a systemd konténerekben való felhasználásának témáját. 2014-ben Daniel Walsh biztonsági mérnökünk írt egy cikket , és néhány évvel később - egy másik, amelyet úgy hívtak , amelyben kijelentette, hogy a helyzet nem sokat javult. Konkrétan azt írta, hogy „sajnos még két évvel később is, ha rákeresünk a google-ban a „Docker system” kifejezésre, az első dolog, ami előkerül, az a régi cikk. Szóval ideje változtatni valamin.” Ezen kívül már beszéltünk arról .
Ebben a cikkben bemutatjuk, mi változott az idők során, és hogyan segíthet nekünk a Podman ebben a kérdésben.
Számos oka van annak, hogy a systemd-t tárolóban futtassuk, például:
- Multiservice konténerek – sokan szeretnék kivonni a többszolgáltatást nyújtó alkalmazásaikat a virtuális gépekből, és konténerekben futtatni. Természetesen jobb lenne az ilyen alkalmazásokat mikroszolgáltatásokra bontani, de még nem mindenki tudja, hogyan kell ezt megtenni, vagy egyszerűen nincs ideje. Ezért az ilyen alkalmazások futtatása a systemd által egységfájlokból indított szolgáltatásokként teljesen logikus.
- Systemd Unit fájlok – A legtöbb konténerben futó alkalmazás olyan kódból épül fel, amely korábban virtuális vagy fizikai gépeken futott. Ezeknek az alkalmazásoknak van egy egységfájlja, amelyet ezekhez az alkalmazásokhoz írtak, és megérti, hogyan kell elindítani őket. Tehát még mindig jobb, ha a szolgáltatásokat támogatott módszerekkel indítja el, ahelyett, hogy feltörné a saját init szolgáltatását.
- A Systemd egy folyamatmenedzser. Bármely más eszköznél jobban teljesíti a szolgáltatáskezelést (leállítás, szolgáltatások újraindítása vagy zombifolyamatok megölése).
Ennek ellenére számos oka van annak, hogy ne futtassuk a systemd-t tárolókban. A legfontosabb az, hogy a systemd/journald vezérli a konténerek és hasonló eszközök kimenetét vagy elvárják, hogy a tárolók közvetlenül a naplót írják az stdout és az stderr fájlba. Ezért, ha a konténereket a fent említettekhez hasonló hangszerelési eszközökön keresztül kívánja kezelni, komolyan meg kell fontolnia a systemd-alapú tárolók használatát. Ezenkívül a Docker és a Moby fejlesztői gyakran határozottan ellenezték a systemd konténerekben történő használatát.
Podman eljövetele
Örömmel jelentjük, hogy a helyzet végre előrelépett. A Red Hat konténerek üzemeltetéséért felelős csapata a fejlesztés mellett döntött . Nevet kapott és ugyanazt a parancssori felületet (CLI) kínálja, mint a Docker. És szinte minden Docker-parancs ugyanúgy használható a Podmanben. Gyakran tartunk szemináriumokat, amelyeket ma ún , és a legelső dia írásra szólít fel: alias docker=podman.
Sokan csinálják ezt.
A Podmanem és én semmiképpen sem ellenezzük a rendszeralapú konténereket. Végül is a Systemd a leggyakrabban használt Linux init alrendszer, és ha nem engedi megfelelően működni a konténerekben, akkor figyelmen kívül kell hagyni, hogy emberek ezrei megszokták a konténerek futtatását.
A Podman tudja, mit kell tennie annak érdekében, hogy a rendszer megfelelően működjön egy konténerben. Olyan dolgokra van szükség, mint például a tmpfs csatolása a /run és a /tmp fájlokhoz. Szereti, ha engedélyezve van a "containerized" környezet, és írási jogosultságokat vár a cgroup könyvtár saját részére és a /var/log/journald mappára.
Amikor elindít egy tárolót, amelyben az első parancs az init vagy systemd, a Podman automatikusan konfigurálja a tmpfs-t és a Cgroups-t, hogy biztosítsa a systemd problémamentes elindulását. Az automatikus indítási mód letiltásához használja a --systemd=false kapcsolót. Kérjük, vegye figyelembe, hogy a Podman csak akkor használja a systemd módot, ha úgy látja, hogy systemd vagy init parancsot kell futtatnia.
Íme egy részlet a kézikönyvből:
ember podman futni
...–systemd=true|false
Konténer futtatása systemd módban. Alapértelmezés szerint engedélyezve.
Ha egy systemd vagy init parancsot futtat egy tárolón belül, a Podman a következő könyvtárakban konfigurálja a tmpfs csatolási pontokat:
/run, /run/lock, /tmp, /sys/fs/cgroup/systemd, /var/lib/journal
Az alapértelmezett leállítási jel is SIGRTMIN+3 lesz.
Mindez lehetővé teszi, hogy a systemd zárt konténerben, változtatás nélkül fusson.
MEGJEGYZÉS: a systemd megpróbál írni a cgroup fájlrendszerbe. A SELinux azonban alapértelmezés szerint megakadályozza, hogy a tárolók ezt megtegyék. Az írás engedélyezéséhez engedélyezze a container_manage_cgroup logikai paramétert:
setsebool -P container_manage_cgroup true
Most nézze meg, hogyan néz ki a Dockerfile a systemd futtatásához egy tárolóban a Podman használatával:
# cat Dockerfile
FROM fedora
RUN dnf -y install httpd; dnf clean all; systemctl enable httpd
EXPOSE 80
CMD [ "/sbin/init" ]
Ez minden.
Most összeállítjuk a tartályt:
# podman build -t systemd .
Megmondjuk a SELinux-nak, hogy engedélyezze a systemd-nek a Cgroups konfigurációjának módosítását:
# setsebool -P container_manage_cgroup true
Sokan egyébként megfeledkeznek erről a lépésről. Szerencsére ezt csak egyszer kell megtenni, és a beállítás mentésre kerül a rendszer újraindítása után.
Most csak elindítjuk a tárolót:
# 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.
Ez az, a szolgáltatás működik és működik:
$ curl localhost
<html xml_lang="en" lang="en">
…
</html>
MEGJEGYZÉS: Ne próbálkozzon ezzel a Dockerrel! Ott még mindig táncolni kell egy tamburával, hogy az ilyen típusú konténereket elindítsa a démonon keresztül. (További mezők és csomagok szükségesek ahhoz, hogy mindez zökkenőmentesen működjön a Dockerben, vagy egy privilegizált tárolóban kell futtatni. Részletekért lásd: .)
Még néhány jó dolog a Podmanről és a systemd-ről
A Podman jobban működik, mint a Docker a rendszeregységfájlokban
Ha a konténereket el kell indítani a rendszer indításakor, akkor egyszerűen beillesztheti a megfelelő Podman parancsokat a systemd unit fájlba, amely elindítja a szolgáltatást és figyeli azt. A Podman a szabványos fork-exec modellt használja. Más szavakkal, a konténerfolyamatok a Podman-folyamat gyermekei, így a systemd könnyen felügyeli őket.
A Docker kliens-szerver modellt használ, és a Docker CLI-parancsok közvetlenül egy egységfájlba is elhelyezhetők. Ha azonban a Docker-ügyfél csatlakozik a Docker-démonhoz, az (az ügyfél) csak egy másik folyamatkezelő stdin és stdout lesz. A systemd-nek viszont fogalma sincs a Docker kliens és a Docker démon irányítása alatt futó konténer kapcsolatáról, ezért ezen a modellen belül a systemd alapvetően nem tudja felügyelni a szolgáltatást.
A rendszer aktiválása aljzaton keresztül
A Podman megfelelően kezeli az aktiválást az aljzaton keresztül. Mivel a Podman a fork-exec modellt használja, továbbíthatja a socketet az alárendelt tárolófolyamatokhoz. A Docker ezt nem tudja megtenni, mert kliens-szerver modellt használ.
A Podman által a távoli kliensekkel a konténerekhez való kommunikációhoz használt varlink szolgáltatás valójában egy socketen keresztül aktiválódik. A Node.js-ben írt cockpit-podman csomag, amely a pilótafülke-projekt része, lehetővé teszi az emberek számára, hogy egy webes felületen keresztül kommunikáljanak a Podman-tárolókkal. A cockpit-podmant futtató webdémon üzeneteket küld egy varlink socketre, amelyet a systemd figyel. A Systemd ezután aktiválja a Podman programot az üzenetek fogadásához és a tárolók kezelésének megkezdéséhez. A systemd egy socketen keresztül történő aktiválása szükségtelenné teszi egy folyamatosan futó démon használatát a távoli API-k implementálásakor.
Ezenkívül fejlesztünk egy másik Podman-klienst, a podman-remote-t, amely ugyanazt a Podman CLI-t valósítja meg, de a konténerek futtatásához a varlinket hívja. A Podman-remote az SSH-munkamenetek tetején is futhat, így biztonságosan kommunikálhat a különböző gépeken lévő tárolókkal. Idővel azt tervezzük, hogy a podman-remote-ot engedélyezni fogjuk a MacOS és a Windows támogatására a Linux mellett, így a fejlesztők ezeken a platformokon futtathatnak egy Linux virtuális gépet Podman varlink futtatásával, és teljes körű tapasztalatot szerezhetnek arról, hogy a konténerek a helyi gépen futnak.
SD_NOTIFY
A Systemd lehetővé teszi a kiegészítő szolgáltatások elindításának elhalasztását, amíg az általuk igényelt konténeres szolgáltatás el nem indul. A Podman továbbíthatja az SD_NOTIFY socketet a konténeres szolgáltatásnak, hogy a szolgáltatás értesítse a rendszert, hogy készen áll a működésre. És ismét, a Docker, amely kliens-szerver modellt használ, ezt nem tudja megtenni.
A tervekben
Azt tervezzük, hogy hozzáadjuk a podman generate systemd CONTAINERID parancsot, amely egy systemd unit fájlt generál a megadott tároló kezelésére. Ennek működnie kell mind a gyökér, mind a gyökér nélküli módban a nem jogosult tárolóknál. Még egy OCI-kompatibilis systemd-nspawn futtatókörnyezet iránti kérelmet is láttunk.
Következtetés
A systemd konténerben való futtatása érthető igény. A Podmannek köszönhetően pedig végre van egy konténer futtatókörnyezetünk, amely nem ütközik a systemd-vel, de egyszerűvé teszi a használatát.
Forrás: will.com