Docker või Podman: rootless-režiim ei tee jõudlusest automaatset võitjat

3. oktoober 2026, kell 03:00|Autor: QUASA toimetus|5 min lugemist| 1

Juurõigusteta käitus ei sunni Dockeri juurest Podmanile üle minema: Dockeri rootless-režiim käitab nii taustateenust kui ka konteinereid tavakasutaja kasutajanimeruumis ning Podmani käsiraamat kirjeldab juurõigusteta kasutust ilma püsiva taustateenuseta. Kui olemasolev Dockeri töövoog sobib, saab õigusi vähendada tööriista vahetamata. Podman on põhjendatud valik siis, kui Linuxi hostil soovitakse hallata konteinereid püsiva konteineritaustateenuseta.

Kiiruse üle ei otsusta tööriista nimi ega rootless-režiim üksi. Konteineri loomise aega mõjutavad muu hulgas tõmmise kihid, salvestusdraiver ja OCI käitusprogramm; teenuse töö ajal lisandub võrgutee mõju. Avaldatud paketiehituse mõõtmine näitab, kui kergesti võib üks lühem etapp anda siiski pikema kogutööaja.

Õiguste mudel ja taustateenus

Dockeri rootless-režiimi puhul töötab daemon tavakasutaja õigustes. See erineb Dockeri seadest userns-remap: viimane teisendab konteineri kasutajatunnused hosti kasutajatunnusteks, kuid daemon ise jääb juurõigustega tööle. Rootless-käituseks vajab Docker kasutajatunnuste vahemikke ning programme newuidmap ja newgidmap; pelgalt käsu käivitamine tavakasutajana ei tõenda, et klient on ühendatud rootless-daemon’iga.

Podmani kohalik käsurida ei vaja püsivat konteineridaemon’it ning juurõigusteta käivitamisel luuakse kasutajale nimeruum. Tavakasutaja loodud konteinereid hallatakse tema kasutajakontekstis. See muudab õiguste ja protsesside haldamise viisi, kuid ei tähenda, et iga Podmani käivitatud konteiner oleks automaatselt juurõigusteta: tulemus sõltub ka sellest, millise kasutajana käsk käivitatakse.

Serveris loeb lisaks käivitamisõigusele teenuse elutsükkel. Podmani puhul saab konteinerite ja teenuste haldamiseks kasutada systemd üksusi; Dockeri rootless-daemon’it saab samuti juhtida kasutaja systemd teenusena. Mõlema korral tuleb otsustada, kas teenus peab jätkama tööd pärast kasutaja väljalogimist ja käivituma koos hostiga. Seega on püsiva daemon’i puudumine arhitektuuriline erinevus, mitte lubadus, et serveriteenus toimib ilma elutsükli seadistamiseta.

Salvestusdraiver ja OCI käitusprogramm

Podmani jõudlusjuhend nimetab jõudlust mõjutavate teguritena OCI käitusprogrammi, hosti failisüsteemi ja konteineritõmmist ning järjestab salvestuslahendused üldjuhul nii: native overlayfs, fuse-overlayfs, vfs. See järjestus kirjeldab salvestuse tavapärast mõju, mitte Dockeri ja Podmani üldist paremusjärjestust. Kui tõmmise kihte tuleb rohkesti lugeda või kirjutada, võib draiveri erinevus kaaluda üles konteinerikäsu enda väikese ajavahe.

Oluline erand puudutab Podmani esimest konteineriloomist kindla tõmmise ja muudetud UID/GID vastendusega. Sellisel rootless-juhul võib native overlayfs-i kasutav loomine võtta kauem kui fuse-overlayfs-iga, kuigi see erand ei puuduta juba töötava konteineri kiirust. Juhend eristab ka draiveri nime selle tegelikust teostusest: teade „overlay” võib tähendada nii native overlayfs-i kui ka fuse-overlayfs-i kasutamist.

OCI käitusprogramm täidab konteineri loomise ja käivitamisega seotud töö, mistõttu võib selle valik eriti lühikeste käskude mõõtmisel nähtavaks saada. Rakenduse pikema töö korral võivad olulisemaks osutuda selle enda protsessid, failide ligipääs ja võrk. Ka sama käsu võrdlus muutub eksitavaks, kui ühes katses on tõmmis juba olemas ning teises tuleb see alles alla laadida või salvestusse importida.

Juurõigusteta võrk ja avaldatud pordid

Võrgumahuka teenuse puhul tuleb vaadata liiklust pärast konteineri käivitumist. Podmani juurõigusteta võrk kasutab tavaliselt pasta võrgudraiverit, mis suunab liiklust kasutajaruumis ja lisab kulu. See ei anna iseenesest teenuse latentsuse või läbilaskevõime arvu: mõju sõltub liikluse laadist ja sellest, kas ühendus läbib sama võrguteed.

Dockeri rootless-võrgu juhend seob võrgu ja avaldatud pordi läbilaskevõime ning kliendi lähteaadressi säilimise kasutatavate võrgu- ja pordidraiveritega. Kasutajaruumis töötav TCP/IP kiht on üldjuhul aeglasem kui kerneli võrk, ent draiverite võimalused erinevad. Sama dokumentatsioon selgitab, et juurõigusteta kasutaja ei saa vaikimisi avaldada hostil privilegeeritud madalat porti; teenuse võib selle asemel avaldada lubatud kõrgemal pordil.

Veebiteenuse valikul on need eristused olulisemad kui paketiehituse sekundid. Kui üks lahendus kasutab teist pordidraiverit või läheb hosti võrgunimeruumi kaudu, ei mõõda võrreldud päringuajad enam ainult konteineritööriista mõju. Võrgutee muutmine võib muuta ka eraldatust, mistõttu tuleb läbilaskevõimet hinnata koos soovitud õiguste mudeliga.

Mida OBS-i ehitusaeg tegelikult mõõtis?

Tampere ülikooli OBS-i lõputöö mõõtmistabelis kestis täidetud paketivahemälu ja eelseadistatud baastõmmisega kordusjooksu OBS-i ehitusetapp Podmani lahenduses 16 ja Dockeri lahenduses 17 sekundit; kogu käsu ajad olid vastavalt 21,65 ja 21,49 sekundit. Ehitusetapis oli Podmani lahendus napilt kiirem, kuid sama kordusjooksu koguaeg oli Dockeri lahendusel napilt lühem. Need on konkreetsete konfiguratsioonide ühe jooksu tulemused, mitte tööriistade püsivad kiirusnäitajad.

Katse tehti sülearvuti WSL-keskkonnas avaliku openSUSE Open Build Service’iga. Koguaeg hõlmas lisaks ehitusele ettevalmistust, sõltuvuste käsitlemist ja lõpetamist. Eelseadistatud baastõmmis oli kordusjooksuks juba imporditud, nii et esimese käivituse lisakulu sellesse võrdlusse ei mahtunud. Töö käsitles OBS-i Dockeriga juurõigustes ja Podmaniga juurõigusteta käitamise võimalusi; see mõõtmine ei ole kahe samamoodi rootless-seadistatud mootori otsene katse.

Vahemälu ja tõmmise ettevalmistus muudavad siin tulemust rohkem kui ühesekundiline ehitusetapi vahe lubab arvata. Töö tabelis eristati ka tavapärast paketiehitust lahendusest, mis kasutab eelseadistatud tõmmist konteineri baastõmmisena. Nende ridade vahele jääb töövoo muudatus: tõmmise import, sõltuvuste olemasolu ja kasutatav ehitusviis. Veebiteenuse käivitumise või andmebaasi päringute kohta OBS-i paketiehituse ajad järeldust ei anna.

Valik kohaliku arenduse ja serveri jaoks

Olemasolev Dockeri arendustöövoog. Kui käsud ja automatiseerimine juba sobivad ning eesmärk on vähendada daemon’i õigusi, on Dockeri rootless-režiim otsene võimalus. Tööriista vahetus vajab eraldi põhjust, näiteks soovitud muutust teenuse halduses.
Linuxi host, kus püsivat konteineridaemon’it ei soovita. Podmani kohalik tööviis vastab sellele nõudele. Serveriteenuse puhul jäävad siiski vajalikuks otsused kasutajaõiguste, salvestuse ja systemd kaudu käivitamise kohta.
Failimahukas arendus või sagedased tõmmise ehitused. Võrdle sama tõmmisega külma käivitust ja kordusjooksu ning pane tähele salvestusdraiverit ja OCI käitusprogrammi. Rootless-režiimi nimi ei ütle, kas kasutatakse native overlayfs-i või fuse-overlayfs-i.
Avaliku pordiga või võrgumahukas teenus. Otsustavaks võib saada juurõigusteta võrgu- ja pordidraiver. Võrdlus on mõtestatud siis, kui mõlemad lahendused teenindavad sama liiklust soovitud eraldatuse juures.

Kui peamine vajadus on juurõigusteta konteiner, on mõlemad valikud olemas. Kui määrav on püsiva daemon’ita haldus, on Podmanil selge arhitektuuriline eelis; kui määrav on olemasoleva töövoo jätkamine, saab Dockeriga õiguste mudelit muuta ilma migratsioonita. Jõudlusotsus sõltub seejärel sellest, kas konkreetses töös kulub aeg konteineri loomisele, failisüsteemile, võrgule või rakendusele endale.

Loe ka:

Jaga: