Docker или Podman: rootless безбедност не доноси јасног брзинског победника

Docker и Podman могу да покрећу контејнере без root привилегија, али доступно мерење не даје јасног брзинског победника за такав избор. У раду Матијаса Кјелстеда из 2020. године Podman је био незнатно бржи у три од четири меморијска теста, док су дисковне разлике биле врло мале. То је поређење CPU-а, меморије и диска на једном рачунару, без упоредног мерења једнако подешених rootless инсталација.

За Linux сервер избор зато пре зависи од тога где стоје подаци, како се објављују портови и ко управља сервисима и ограничењима ресурса. Оба алата користе корисничке namespace-ове у rootless режиму, али се разликују по архитектури процеса и начину уклапања у постојеће окружење.

Шта се мења у безбедносној архитектури

Docker-ово упутство за rootless режим наводи да и daemon и контејнери раде у корисничком namespace-у, без root привилегија на хосту. Код подешавања userns-remap daemon и даље има root привилегије, па та два режима немају исту безбедносну границу. Ни покретање апликације као непривилегованог корисника у обичном Docker контејнеру није исто што и rootless daemon.

Podman нема стални централни daemon. То мења процес којим се управља и начин на који се контејнер укључује у корисничке сервисе, али само по себи не говори колико ће брзо радити апликација у већ покренутом контејнеру. За оба алата треба раздвојити привилегије на хосту од корисника унутар контејнера: назив root у контејнеру не описује аутоматски овлашћења тог процеса на хосту.

Корисничке мапе, NFS и OverlayFS

За Docker rootless потребни су newuidmap и newgidmap, као и најмање 65.536 подређених UID и GID вредности за корисника у /etc/subuid и /etc/subgid. Podman-ов приручник такође описује rootless кориснички namespace и мапе у тим датотекама. Пре преноса скрипти зато треба проверити да ли сервер уопште дозвољава потребну доделу корисничких и групних идентификатора.

Положај складишта може да одлучи избор пре било каквог теста брзине. Podman не подржава NFS као директно rootless складиште контејнера, јер тај систем датотека не разуме корисничке namespace-ове. Кориснички home ипак може бити на NFS-у ако се graphroot у корисничкој конфигурацији storage.conf усмери на локални диск. И Docker-ова подразумевана rootless фасцикла са подацима треба да буде ван NFS-а.

На Linux језгрима старијим од 5.12.9 Podman не може да користи rootless OverlayFS на исти начин као на новијим језгрима; fuse-overlayfs обезбеђује потребно монтирање у корисничком namespace-у. Podman га аутоматски бира као mount_program када је инсталиран, осим ако је кориснички storage.conf већ постојао. У том случају треба проверити и подешавање mount_program, а не само присуство пакета. За миграцију су зато битни стварни драјвер складишта, верзија језгра и физичко место graphroot-а.

Мрежа, systemd и ограничења ресурса

Rootless Podman за прављење засебног мрежног уређаја захтева slirp4netns или pasta. Ако ниједан није доступан, контејнер мора да користи мрежни namespace хоста. Мрежни режим, начин објављивања портова и приступ између сервиса зато треба упоредити одвојено од резултата теста CPU-а или диска; то су различити делови оптерећења.

Rootless Docker и даље има daemon, али се њиме може управљати као корисничким systemd сервисом. Docker-ова упутства за рад сервиса описују docker.service под корисничким systemd-ом и linger за покретање после рестарта без активне пријаве. Подразумевана фасцикла са Docker подацима је ~/.local/share/docker, а сокет се налази у корисничком runtime директоријуму. Скрипта која очекује системски Docker сокет зато може да захтева измену и када су њене основне команде исправне.

За rootless Docker ограничења као што су --cpus и --memory раде уз cgroup v2 и systemd. Ако docker info прикаже Cgroup Driver: none, одговарајуће опције се игноришу. И када је драјвер systemd, доступни су само контролери које је систем делегирао кориснику. Podman такође подржава управљање преко systemd-а и декларативне Quadlet јединице, али његов cgroup менаџер у rootless режиму није подржан на cgroup v1. Успешно покретање контејнера зато није доказ да је тражени лимит процесора или меморије примењен.

Команде и Compose нису цела миграција

Podman има командну линију сличну Docker-овој, па једноставне операције као што су повлачење слике, покретање, преглед и заустављање контејнера имају блиске облике. Сличност команди не преноси аутоматски сокете, корисничке сервисе, путање података и мрежна подешавања. Скрипте које подразумевају стално доступан Docker daemon траже посебну пажњу, јер Podman нема исти централни процес.

Опис команде podman compose каже да је она омотач око спољног Compose провајдера, као што су docker-compose или podman-compose. Команде се прослеђују изабраном провајдеру, који комуницира са локалним Podman сокетом. Зато назив команде сам по себи не гарантује да ће постојећа Compose конфигурација задржати исто понашање мреже, томова и покретања сервиса. Код миграције је важно знати који је провајдер стварно изабран.

Одлука за постојећи Linux сервер може да се сведе на ограничења окружења:

• Ако се тим ослања на Docker Compose и кориснички daemon се уклапа у правила приступа, rootless Docker задржава познат начин управљања. Потребно је обезбедити корисничке мапе, локално складиште и исправан systemd сервис.
• Ако је важан рад без сталног централног daemon-а, Podman је прикладан кандидат. Дуготрајне сервисе тада треба уклопити у кориснички systemd, а Compose конфигурацију проверити са стварним провајдером.
• Ако је home на NFS-у, Podman-ов graphroot и Docker-ове rootless податке треба сместити на локално складиште. На старијем језгру треба проверити и како је подешен fuse-overlayfs.
• Ако продукција захтева чврсте лимите CPU-а или меморије, верзија cgroups-а и делегација контролера постају услов избора, а не накнадно подешавање.

Где престаје домет објављеног мерења

Кјелстедово мерење користило је Y-cruncher за CPU, STREAM за меморију и Bonnie++ за диск на једном лаптопу. Мрежа није мерена, а рад не издваја rootless конфигурације као засебно поређење. Мала предност Podman-а у делу резултата зато не представља обећање да ће он бити бржи на серверу са другим драјвером складишта, мрежним режимом или оптерећењем.

За избор између две исправно подешене rootless инсталације најкорисније је мерити сопствену апликацију уз исту слику, упоредива ограничења и јасно забележене услове мреже и складишта. Време покретања треба посматрати одвојено од рада већ покренутог процеса: архитектура управљања контејнером и брзина апликације нису исто мерење.

Прочитајте и:

• Claude Code или Codex: врста задатка бира победника
• Паушалац или лична зарада: приход сам не одлучује победника