Docker ці Podman: хуткасць амаль роўная, але 29 МБ мяняюць выбар

Для новага Linux-сервера, дзе сэрвісы павінны працаваць без правоў root, Podman — зручны зыходны выбар. Калі разгортванне ўжо абапіраецца на Docker Compose або інструменты, якія чакаюць Docker Engine, прасцей захаваць Docker і пры патрэбе наладзіць яго rootless-рэжым. Розніца ў хуткасці цёплага запуску сама па сабе не дае пераканаўчай прычыны пераходзіць з аднаго рухавіка на другі.

У вымярэнні Botmonster на Linux Mint 22.3 з Ryzen 9 5900X, 64 ГБ памяці і ядром 6.17 Docker Engine 29.5 з прывілеяваным дэманам і rootless Podman 4.9.3 паказалі адпаведна 352 ± 12 і 342 ± 31 мс за 20 цёплых запускаў загадзя загружанага вобраза alpine; у тэсце iperf3 праз апублікаваны порт ўваходная прапускная здольнасць складала 21–52 Гбіт/с для Docker bridge і 60–65 Гбіт/с для Podman з pasta, а працэсы pasta і slirp4netns спажывалі каля 29 і 3,6 МБ на кантэйнер. Розніца ў часе запуску ўкладалася ў ваганні замераў. Лічбы сеткі і памяці апісваюць канкрэтныя налады аднаго хоста: прывілеяваны Docker тут не служыць замерам rootless Docker.

Архітэктура і rootless: якія правы патрэбныя рухавіку

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

Дакументацыя Podman тлумачыць, што пры запуску ад звычайнага карыстальніка аўтаматычна ствараецца карыстальніцкая прастора імёнаў; карыстальніку патрэбныя адпаведныя дыяпазоны ідэнтыфікатараў у /etc/subuid і /etc/subgid. Кантэйнеры такога карыстальніка не бачаць іншыя карыстальнікі праз свае асобнікі Podman. Гэта варта ўлічыць на серверы, дзе разгортваннем і абслугоўваннем займаюцца розныя ўліковыя запісы: патрэбна адназначна вызначыць, каму належаць сэрвісы.

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

Запуск: што азначае амаль роўны час

Замер датычыўся кароткай каманды ў вобразе, які ўжо быў на хосце. Ён добра адлюстроўвае цёплы старт у названых умовах, але ў ім няма загрузкі вобраза, зборкі, ініцыялізацыі базы даных або чакання гатоўнасці ўсяго стэка. Таму перавага Podman у архітэктуры без дэмана не ператварылася ў надзейную перавагу па гэтай метрыцы.

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

Сетка: вынік належыць канкрэтнаму маршруту трафіку

У апісанай канфігурацыі rootless Podman з pasta меў больш высокую і раўнамерную ўваходную прапускную здольнасць праз апублікаваны порт, чым bridge-сетка Docker з прывілеяваным дэманам. Гэта маршруты, якія могуць быць важныя для сэрвісу за зваротным проксі. Вынік не характарызуе ўсю сеткавую працу кантэйнераў: сувязь паміж сэрвісамі або іншы механізм публікацыі портаў могуць мець іншы кошт.

Сеткавы механізм і рэжым прывілеяў трэба разглядаць разам. Замена pasta на slirp4netns мяняе склад працэсаў rootless Podman, а ўключэнне rootless-рэжыму ў Docker мяняе сеткавы шлях адносна прывілеяванага bridge. Адсюль практычная мяжа параўнання: вынік аднаго апублікаванага порта дапамагае выбраць канфігурацыю для падобнага трафіку, але не ранжыруе рухавікі для кожнага Linux-сервера.

Памяць: расход сеткі залежыць ад колькасці кантэйнераў

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

Меншы расход slirp4netns паказвае, што выбар сеткавага механізму ўнутры Podman таксама можа быць істотным. Ён не дае бясплатнай замены: трэба ўлічыць патрабаванні да прапускной здольнасці і паводзін апублікаваных портаў. Гэтак жа некарэктна непасрэдна супастаўляць расход дэмана Docker з расходам pasta на адзін працоўны кантэйнер. Першы з'яўляецца фонавым кампанентам рухавіка, другі павялічваецца разам з колькасцю асобных сеткавых прастор.

Калі звязаныя сэрвісы можна размясціць у pod, яны могуць дзяліць сеткавую прастору імёнаў. Апісанне pod у Podman паказвае, што сумесная сеткавая прастора ўваходзіць у стандартную канфігурацыю pod. Гэта дазваляе размеркаваць расход сеткавага працэсу паміж яго кантэйнерамі, але змяняе мяжу іх сеткавай ізаляцыі. Для сэрвісаў, якім патрэбныя асобныя сеткавыя прасторы, такі спосаб эканоміі не падыдзе.

Матрыца выбару для каманды

• Лакальная распрацоўка. Docker зручнейшы, калі ў праекце ўжо працуюць Compose-файлы, скрыпты і інструменты, разлічаныя на Docker Engine. Podman мае сэнс, калі каманда хоча запускаць кантэйнеры ад звычайнага карыстальніка і гатовая праверыць паводзіны менавіта свайго працоўнага працэсу.
• Адзін Linux-сервер. Для новых асобных сэрвісаў пад непрывілеяваным уліковым запісам Podman дае простую мадэль валодання працэсамі і кіраванне праз systemd. Існуючы стабільны сервер на Docker няма падстаў пераносіць толькі дзеля чаканай эканоміі часу цёплага старту.
• Rootless-хостынг. Podman зручны як зыходны варыянт, але пры абмежаванай памяці вызначальным можа стаць кошт сеткавага працэсу на кожную асобную сеткавую прастору. Rootless Docker застаецца варыянтам для каманды, якой патрэбны яго інструменты і якая можа выканаць неабходную наладу.
• Залежнасць ад Docker Compose. Захаваць Docker прасцей, калі важна, каб наяўныя файлы і аўтаматызацыя працавалі без адаптацыі. Пераход на Podman патрабуе праверкі канкрэтнага стэка, уключаючы сетку, томы і інструменты, якія падключаюцца да сокета рухавіка.

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

Чытайце таксама:

• Docker ці Podman: rootless не вызначае пераможцу па хуткасці
• Сакрэт у Docker ENV застаецца ў вобразе: перанясіце яго ў secret mount
• HeyGen ці Synthesia: хвіліны і крэдыты мяняюць таннейшы выбар