Docker vagy Podman: a rootless módért nem kell sebességet áldozni

Linuxon a rootless Podmanra váltást önmagában nem indokolja a konténerindítás sebessége. Egy előre letöltött Alpine-képpel végzett, 20 futásos melegindítási mérésben a root jogosultsággal futó Docker Engine 352 ms, a rootless Podman 342 ms átlagot ért el; a szerző a különbséget mérési zajon belülinek értékelte. A próba egy Linux Mint gépre és egy rövid életű konténerre vonatkozott, így a két érték nem általános teljesítménysorrend.

A választás gyakorlati kérdése az, hogy a meglévő munka mennyire függ a Docker Compose-tól és a Docker-socketet használó eszközöktől. Erős függésnél a Docker megtartása, szükség esetén rootless beállítással, kisebb átállást jelenthet. Felhasználónként elkülönített Linux-szolgáltatásoknál és közvetlen systemd-kezelésnél a Podman kínál kézenfekvőbb munkafolyamatot; a biztonsági döntést azonban a tényleges jogosultsági beállítások határozzák meg.

Jogosultságok: mit jelent valójában a rootless működés?

A szokásos Docker Engine központi daemonra épül. A Docker rootless módjában a daemon és a konténerek egyaránt nem root felhasználóként, felhasználói névtérben futnak. Ez különbözik a userns-remap beállítástól, amely mellett maga a daemon továbbra is root jogosultságú. Aki megtartaná a Dockerre épülő eszközeit, annak ezért a Podmanra váltás mellett a rootless Docker is érdemi lehetőség.

A Docker rootless telepítéséhez a gazdagépen szükség van a newuidmap és newgidmap programokra, továbbá a felhasználó alárendelt UID- és GID-tartományára az /etc/subuid és /etc/subgid fájlban. A telepítő felhasználói systemd-szolgáltatást és külön Docker-környezetet állít be; az ügyfélprogramnak ehhez a daemonhoz kell kapcsolódnia. Ha a korábbi, rendszerszintű Docker-daemon tovább fut, az új klienskörnyezet önmagában nem szünteti meg annak root jogosultságú működését.

A Podman kézikönyve daemon nélküli működést és a Dockeréhez hasonló parancssort ír le; a legtöbb parancs külön jogosultság nélkül futtatható. Rootless módban a Podman felhasználói névteret hoz létre, és az egyik nem root felhasználó konténerei nem jelennek meg a másik felhasználó Podman-nézetében. Ehhez is megfelelő alárendelt azonosítótartomány kell, a képek pedig alapértelmezés szerint a felhasználó saját tárhelyére kerülnek. Több felhasználónál az elkülönítés mellé így külön tárhelyigény is társulhat.

A rootless jelző egyik rendszernél sem helyettesíti a kötetekhez szükséges fájlhozzáférést és a hálózati feltételek tisztázását. Egy konténernek továbbra is hozzá kell férnie azokhoz a gazdagépen lévő könyvtárakhoz, amelyeket csatolni szeretnél, a felhasználói névtér pedig önmagában nem ad a felhasználónak rendszergazdai jogosultságot. Ez különösen a meglévő szolgáltatások átvitelénél számít, ahol az adatkönyvtárak tulajdonosa már adott.

Parancsok és Compose: hol kezdődik a valódi migráció?

A képek letöltése, a konténerek indítása és a futó példányok kezelése ismerős marad Docker után. A docker=podman alias azonban csak a parancs nevét cseréli le: a tárolás, a socket és az automatizálás mögötti működés ettől nem válik azonossá. Egy egyszerű konténer sikeres indítása ezért keveset mond arról, hogy egy teljes fejlesztői vagy üzemeltetési folyamat változtatás nélkül átvihető-e.

A podman compose leírása szerint a parancs egy külső Compose-szolgáltatót, például a docker-compose vagy a podman-compose programot hívja meg, és azt a helyi Podman-sockethez kapcsolja. A tényleges viselkedés így a telepített szolgáltatótól is függ. A meglévő Compose-fájloknál a hálózatokat, köteteket, buildbeállításokat és az alkalmazás indulási feltételeit a célgépen használt szolgáltatóval érdemes kipróbálni.

A másik töréspontot azok a fejlesztői és CI-eszközök jelentik, amelyek a Docker API-ját vagy egy meghatározott socketútvonalat várnak. Ilyenkor a parancsnév lecserélése nem oldja meg a kapcsolatot: az eszköz beállítását és az általa használt műveleteket is át kell nézni. Kevés, önálló konténernél ez rövid munka lehet; sok egymásra épülő szolgáltatásnál a kompatibilitás döntőbb szempont, mint a mért indítási idő.

systemd: mikor előny a Quadlet?

A Podman Quadlet-fájlokból systemd-szolgáltatásokat hoz létre. A Quadlet dokumentációja szerint egy .container fájlból megfelelő .service egység keletkezik; a generátor rendszer- és felhasználói egységeket is kezel, működéséhez pedig cgroup v2 szükséges. Ez egy olyan Linux-szerveren hasznos, ahol a szolgáltatások indítását, függőségeit és naplóit eleve systemd-vel szervezik.

Rootless Quadlet esetén az egységfájlt a megfelelő felhasználói keresési útvonalra kell tenni. Egy rendszerszintű egység User beállítása nem alakítja át azt rootless Quadletté. A Docker rootless daemonja szintén futtatható felhasználói systemd-szolgáltatásként, de ott a systemd elsősorban a daemont kezeli; a Quadletnél maga a konténeres szolgáltatás kap deklaratív egységet.

Az automatikus indulás részlete is eltér a közönséges systemd-egységektől: a Quadlet generátora az egységfájl [Install] részét dolgozza fel. Ha a konténer indításakor még képet kell letölteni vagy építeni, az indítás tovább tarthat a systemd alapértelmezett időkorlátjánál. Ezért egy szerverre szánt Quadletnél a képek rendelkezésre állása és az indulási beállítások ugyanúgy részei az üzemeltetési döntésnek, mint a kényelmes systemd-integráció.

Mit mond el a melegindítási eredmény?

A vizsgált feladat egy már letöltött képből induló, azonnal befejeződő konténer volt. Ez alkalmas az indítási többlet szűk összevetésére, de nem méri egy tartós alkalmazás CPU-terhelését, lemezműveleteit, képépítését vagy hálózati forgalmát. A mérés ráadásul root jogosultságú Dockert állított rootless Podman mellé, ezért nem mutatja meg külön, mennyivel változna a Docker indítási ideje rootless módban.

Az eredményből az a visszafogott következtetés adódik, hogy ebben a melegindítási próbában a rootless Podman nem járt érdemi sebességhátránnyal. A daemon nélküli felépítésből sem következett kimutatható indítási előny. Hálózati vagy tárolási teljesítmény alapján csak az adott terhelés és konfiguráció mellett lehet választani; az egygépes indítási próba ezeket a kérdéseket nyitva hagyja.

Döntési mátrix három Linux-helyzetre

A parancskompatibilitás, a rootless előfeltételek és a mért indítási idő külön szempont. Az egyes környezetekben másik kerül előre, ezért ugyanaz a melegindítási eredmény nem vezet minden gépen azonos választáshoz.

• Fejlesztői gép. Parancsok: az alapvető konténerparancsok átvihetők, de a Compose-szolgáltatót, a buildfolyamatot és a Docker-socketet használó fejlesztői eszközöket külön kell kipróbálni. Rootless feltételek: az alárendelt azonosítótartományok mellett a projektkönyvtárak és a csatolt fájlok hozzáférése számít. Indítási mérés: a vizsgált melegindítás nem indokol önmagában migrációt, ha a meglévő munkafolyamat Dockerrel már jól működik.
• Egyfelhasználós szerver. Parancsok: kevés, jól ismert szolgáltatásnál a Quadlet közvetlen systemd-kezelést kínálhat a Compose-alapú működés helyett. Rootless feltételek: a szolgáltatásfiók azonosítótartományát, tárhelyét, hálózatát és felhasználói systemd-környezetét elő kell készíteni. Indítási mérés: a közel azonos eredmény helyett az indulás, az újraindítás és a szolgáltatások közötti függések kezelése dönthet.
• Többfelhasználós Linux-gép. Parancsok: a Podman felhasználónkénti konténernézete hasznos elkülönítést ad, míg a közös Docker-socketre épülő szkriptek átállítása külön munka. Rootless feltételek: minden érintett fiókhoz megfelelő azonosítótartomány és működő helyi tárolás kell; az elkülönült képtárolók lemezhasználatát is számításba kell venni. Indítási mérés: egyetlen felhasználó rövid konténerindítása nem írja le a párhuzamos, többfelhasználós terhelést.

Olvassa el ezt is:

• Pinecone vagy Qdrant: a 2,1× sebességelőnyért üzemeltetni kell
• Üzleti angyal vagy kockázati tőke: nem csak a csekk mérete különbözik
• MI-jártasság az AI Act szerint: tanúsítvány nem kell, belső nyom igen