Docker ці Podman: rootless не вызначае пераможцу па хуткасці

Выбар паміж Docker і Podman пачынаецца з асяроддзя, у якім будуць працаваць кантэйнеры. Для праекта, што ўжо залежыць ад Docker Compose і інструментаў з Docker API, прасцей захаваць Docker. Для Linux-сэрвісаў, якімі зручна кіраваць праз systemd ад імя звычайнага карыстальніка, Podman можа быць лепшым выбарам. Абодва рухавікі падтрымліваюць rootless; сам гэты рэжым не паказвае, які з іх хутчэйшы.

На працоўнай станцыі і ў CI кошт пераходу часта вызначаюць файлы Compose, зборка вобразаў і доступ да сокета. На невялікім VPS да іх далучаюцца запуск пасля перазагрузкі, памяць сеткавых працэсаў і размяшчэнне сховішча. Апублікаваны замер запуску не выявіў перавагі, на падставе якой варта было б ігнараваць гэтыя адрозненні.

Rootless і адсутнасць дэмана — розныя ўласцівасці

Rootless азначае, што кантэйнерныя працэсы працуюць на хосце без правоў root; адсутнасць пастаяннага дэмана апісвае спосаб кіравання імі. Паводле інструкцыі Docker па rootless-рэжыме, без root запускаюцца і дэман, і кантэйнеры; выключэнне сярод SETUID-бінарнікаў складаюць newuidmap і newgidmap. Такім чынам, дэман у Docker застаецца, але яго наяўнасць не азначае абавязковую працу з правамі root.

Дакументацыя Podman апісвае рухавік без пастаяннага дэмана, які дазваляе запускаць большасць каманд ад звычайнага карыстальніка. Rootless-карыстальніку патрэбна адпаведная канфігурацыя прасторы імёнаў і сховішча. На ядрах ранейшых за 5.12.9 звычайны OverlayFS у гэтым рэжыме не падтрымліваецца: для такіх умоў дакументацыя рэкамендуе fuse-overlayfs. Калі хатні каталог знаходзіцца на NFS, сховішча даных кантэйнераў трэба размясціць на лакальнай файлавай сістэме.

Пры падключэнні каталога з хоста важныя і правы на файлы, створаныя працэсам у кантэйнеры. Падчас міграцыі варта высветліць, ці зможа карыстальнік сервісу прачытаць іх, змяніць і захаваць пасля перазапуску. Меншыя прывілеі працэсу не выпраўляюць аўтаматычна няўдалую схему доступу да каталогаў або API.

Compose і сокеты вызначаюць сумяшчальнасць

Падобныя каманды для аднаго кантэйнера не гарантуюць аднолькавай працы шматкантэйнернага праекта. Паводле апісання podman compose, каманда перадае працу знешняму пастаўшчыку Compose, напрыклад docker-compose або podman-compose. Ад таго, які пастаўшчык усталяваны і выбраны, залежаць даступныя паводзіны. Таму сапраўдным выпрабаваннем міграцыі будзе ўласны файл праекта: яго сеткі, тамы, зборка, зменныя асяроддзя і каманда абнаўлення.

Інструменты распрацоўкі і CI могуць звяртацца непасрэдна да Docker API. Апісанне API-сэрвісу Podman паказвае сумяшчальны пласт Docker API і карыстальніцкі сокет, які systemd можа актываваць пры падключэнні кліента. Доступ да гэтага сокета дазваляе выконваць дзеянні з правамі карыстальніка сэрвісу. Замена адраса сокета патрабуе праверыць і патрэбныя выклікі API, і тое, хто атрымае да яго доступ.

Для пастаянных сэрвісаў Podman прапануе дэкларатыўныя файлы Quadlet, з якіх systemd стварае сэрвісы. Rootless Docker таксама можна запускаць як карыстальніцкі сэрвіс, але кіравацца ў такім выпадку будзе яго дэман. На VPS гэта розніца ў спосабе эксплуатацыі: істотныя паводзіны пасля перазагрузкі, парадак запуску залежных службаў, журналы і права на перазапуск.

Што насамрэч вымяралі ў тэсце

У замерах Botmonster Tech на адным хосце з Linux Mint і Ryzen 9 5900X загадзя спампаваны вобраз Alpine за 20 прагонаў запускаўся ў сярэднім за 352 мс праз Docker Engine 29.5 і за 342 мс праз rootless Podman 4.9.3. Docker працаваў з правамі root; аўтар палічыў розніцу ў часе запуску шумам. Гэта вынік канкрэтных канфігурацый і кароткай каманды ў кантэйнеры, а не замер усіх тыпаў нагрузкі.

У тым жа тэсце бяздзейныя dockerd і containerd разам займалі 144 МБ памяці. Пры гэтым для кантэйнера Podman з сеткавым рэжымам pasta аўтар вымераў асобны працэс памерам каля 29 МБ. Адсутнасць пастаяннага дэмана таму можа мець значэнне для маленькага VPS, але яе выгаду трэба разглядаць разам з працэсамі запушчаных кантэйнераў.

На апублікаваным порце загрузка ў гэтым тэсце дасягала 21–52 Гбіт/с праз rootful Docker з bridge і 60–65 Гбіт/с праз rootless Podman з pasta. Параўноўваліся розныя сеткавыя шляхі і рэжымы правоў, таму гэтыя значэнні нельга прыпісаць толькі выбару рухавіка. Для сэрвісу з вялікім аб'ёмам трафіку менавіта сеткавая канфігурацыя можа быць больш істотнай за невялікую розніцу ў часе запуску.

Матрыца міграцыі для рэальнага праекта

Пераход мае сэнс ацэньваць на тым самым праекце і асяроддзі, дзе рухавік будзе выкарыстоўвацца. Такая праверка аддзяляе несумяшчальнасць каманд ад выдаткаў сеткі і сховішча. Вынікі аднаго лакальнага тэста не варта пераносіць на VPS або CI з іншымі правамі і сеткавымі наладамі.

• Compose. Запусціце існы файл з выбраным пастаўшчыком Compose. Праверце стварэнне сэрвісаў, сетак і тамоў, зборку вобразаў, зменныя асяроддзя і звычайны спосаб абнаўлення праекта.
• Сокеты і CI. Вызначце інструменты, якія чакаюць Docker API або пэўны шлях да сокета. Праверце іх з сокетам Podman ад імя таго карыстальніка, які запускае задачу, і абмяжуйце доступ адпаведна яе патрэбам.
• systemd. Для VPS праверце запуск пасля перазагрузкі, залежнасці паміж службамі, журнал і аднаўленне пасля збою. Для карыстальніцкага сэрвісу асобна важная праца без актыўнага ўваходу карыстальніка ў сістэму.
• Сетка. Параўноўвайце запыты праз рэжым і апублікаваны порт, якія сапраўды будуць выкарыстоўвацца. Фіксуйце затрымку, прапускную здольнасць і памяць сеткавых працэсаў пры сваёй колькасці кантэйнераў.
• Файлавая сістэма. Праверце запіс у падключаныя каталогі, уладальнікаў новых файлаў і месца для вобразаў. Асабліва важна ўлічыць версію ядра і размяшчэнне хатняга каталога пры rootless Podman.

Выбар для працоўнай станцыі, CI і VPS

На працоўнай станцыі з працоўным Docker Compose пераход апраўданы, калі патрэбныя магчымасці Podman і праект прайшоў праверку сумяшчальнасці. Калі задача заключаецца толькі ў запуску без root, можна спачатку ацаніць rootless Docker, захаваўшы знаёмыя інструменты. У CI рашэнне больш залежыць ад таго, як задача будуе вобразы, да якога API звяртаецца і што захоўвае паміж запускамі.

На невялікім VPS Podman прывабны, калі сэрвісамі плануецца кіраваць праз systemd ад імя звычайнага карыстальніка. Docker застаецца разумным выбарам для ўжо наладжанага стэка Compose або інструментаў, якія разлічваюць на яго API. У абодвух выпадках рашэнне вызначаюць правераная сумяшчальнасць і выдаткі канкрэтнага сеткавага ды файлавага рэжыму, а не адна лічба запуску.