Docker или Podman во rootless режим: мрежата може да го смени победникот

29 септември 2026 г., во 13:00|Автор: Уредувачки тим на QUASA|6 мин. читање| 1

Ако сервисите веќе зависат од Docker Engine и неговиот API, rootless Docker обично бара помалку промени при миграција. Ако сакате локалните контејнери да ги управувате без постојан daemon, Podman е соодветен кандидат. Упатството за Docker rootless наведува дека и daemon-от и контејнерите работат во кориснички namespace без root-привилегии. Документацијата за Podman го опишува како алатка без постојан daemon, која во rootless режим автоматски создава кориснички namespace.

За веб-сервис, конечниот избор може да зависи од мрежната патека повеќе отколку од имињата на командите. Мрежниот backend, препраќањето порти и оптоварувањето влијаат врз резултатот што го гледа клиентот. Затоа споредувајте ја поставеноста што навистина ќе ја користите, а при преселба одделно проверете ги socket-от, Compose, системските сервиси и пристапот до податоците.

Што менува безбедносниот модел

Rootless не е посебна гаранција дека секој контејнер е безбеден. Корисничкиот namespace ги мапира идентификаторите на процесите така што нивните привилегии во контејнерот не стануваат root-привилегии на домаќинот. Кај Docker ова важи и за daemon-от, што е суштинска разлика од режим во кој само контејнерот користи кориснички namespace.

Podman нема постојан daemon за локалните команди. Неговите rootless контејнери се одвоени по корисник: контејнерите што ги создал еден непривилегиран корисник не се појавуваат во прегледот на друг корисник, ниту во root-инстанцата на Podman. Тоа е важно при оперативна поддршка: администратор што извршува Podman како root може да добие празен список, иако сервисот работи под корисничка сметка. Кај двата алата дозволите за монтирани директориуми и пристапот до управувачкиот socket остануваат посебни безбедносни прашања.

Матрица за преселба на сервис

Сличната синтакса на основните команди не значи дека околните интеграции ќе се преселат без промена. За секој сервис, проверката има неколку одделни делови:

Daemon: Docker rootless го задржува односот клиент–daemon. Podman ги извршува локалните команди без постојан централен daemon. Автоматизација што ја следи состојбата на Docker сервисот затоа бара преглед пред замена.
Socket и API: Rootless Docker користи кориснички socket, а rootless Podman има сопствена патека за socket. Пренасочувањето на клиентот кон друга патека е само почеток; проверете дали повиците од конкретниот клиент го даваат очекуваното однесување.
systemd: Docker daemon-от може да работи како кориснички сервис. Podman нуди Quadlet за декларативно управување со контејнери преку systemd. Ако сервисот мора да остане активен по одјавување, проверете како е поставена корисничката systemd-сесија.
Compose: „podman compose“ користи надворешен Compose provider. Постојната Compose-датотека пробајте ја со provider-от што ќе биде инсталиран на серверот, особено ако користи сопствени мрежи, здравствени проверки или bind mounts.
Мрежа: Забележете ги активниот backend, port driver-от и адресата на која е објавен сервисот. Проверете и дали апликацијата ја гледа изворната IP-адреса на клиентот, ако таа е потребна за дневници или правила за пристап.
Складирање: Запишете го активниот storage driver и локацијата на сликите и податоците. Корисничкото складиште на едниот алат не станува автоматски складиште на другиот.

Каде мрежата го менува резултатот

Кај Docker rootless, табелата за мрежните поставки ги разликува пропусноста на мрежата, пропусноста на објавената порта и преносот на изворната IP-адреса за различни комбинации на network и port driver. Ова се различни својства: конфигурација што е погодна за сообраќај низ објавена порта не мора да го има истото однесување за секоја друга мрежна патека. Документацијата наведува и дека стандардниот backend зависи од инсталираните компоненти, па самото име Docker не ја опишува целата мрежна поставеност.

Разликата се гледа и во корисничко мерење со nginx, во кое барањата до rootless Podman биле испраќани од друга физичка машина. При еден истовремен клиент, pasta постигнала околу 1.699 барања во секунда, а slirp4netns околу 1.148; при 32 истовремени клиенти, редоследот се свртел на околу 15.166 наспроти 28.931. Тоа е резултат за опишаната поставеност, а не директен тест Docker против Podman. Сепак, јасно покажува зошто прогласувањето победник според еден backend или едно оптоварување би било погрешно.

Верзијата дополнително ги ограничува старите споредби. Белешките за Podman 6.0 наведуваат дека поддршката за rootless стекот slirp4netns е отстранета и упатуваат на pasta. Затоа команда или benchmark-сценарио што бара slirp4netns од постара инсталација не може без измена да се повтори со тоа издание. При избор за нова инсталација, споредувајте ги достапните поставки, а не само историските резултати.

Дозволи и складирање

Успешен мрежен тест не открива дали апликацијата може да запишува во постојните податоци. Кај bind mount, дозволите на директориумот на домаќинот и мапирањето на корисничките идентификатори одредуваат што може да направи процесот во контејнерот. При преселба, проверете го сопственикот на директориумот, корисникот со кој работи апликацијата и можноста таа да создаде и повторно да прочита датотека.

Не претпоставувајте дека секој rootless контејнер користи fuse-overlayfs. Поддршката за storage driver зависи од јадрото и конфигурацијата, а алатките можат да пријават различни поставки на ист домаќин. Ако сервисот многу запишува, мерете со истиот bind mount или volume што ќе го користи по миграцијата. Тест само во привремениот слој на контејнерот одговара на друго прашање.

Мало повторливо мерење

За прва споредба на објавена порта, користете ја истата слика nginx на истиот Linux домаќин и под истиот непривилегиран корисник. Претходно преземете ја сликата за повлекувањето од регистар да не влезе во мерењето. Со „docker context show“ и „docker info“ потврдете дека Docker клиентот навистина користи rootless daemon; со „podman info“ забележете ги верзијата и storage driver-от.

За Podman стартувајте „podman run -d --name net-test --network=pasta -p 18080:80 docker.io/library/nginx:alpine“. За Docker rootless користете „docker run -d --name net-test -p 18080:80 docker.io/library/nginx:alpine“. Извршувајте ги варијантите една по една, бидејќи ја користат истата порта.
Од друга машина што може да ја достигне адресата на серверот, извршете „ab -n 5000 -c 8 http://АДРЕСА_НА_СЕРВЕРОТ:18080/“, па повторете со „-c 32“. Запишете ги барањата во секунда, времето на одговор и грешките; на клиентската машина треба да биде инсталиран Apache Benchmark.
Отстранете го тест-контејнерот со „podman rm -f net-test“ или „docker rm -f net-test“, стартувајте ја другата варијанта и повторете ги мерењата. Чувајте ги исти клиентската машина, сликата и патеката низ мрежата.

Овој условен тест ги споредува двете работни поставености што би ги добиле на серверот, вклучувајќи ги нивните мрежни патеки; не ја изолира брзината на самиот runtime. За вистински сервис повторете го со неговите одговори, конкурентни барања и пристап до податоци. Ако постојните интеграции тежат повеќе од разликата во управувањето, rootless Docker е поедноставниот избор; ако Podman ги исполнува тие барања, мрежниот резултат и однесувањето при преселба можат да ја наклонат одлуката кон него.

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