LINUX.ORG.RU

Podman vs docker

 , ,


0

4

А расскажите, кто лучше? Вот так, по лоровски, чтобы с огоньком.

Выглядит, что докер худо бедно работает, а подман ориентировался на то, чтобы отладить под на локалхосте и потом пихнуть в кубер не одиночный образ, а сразу с pod.yaml, т.е. методологически он лучше.

И я так понимаю, что podman сразу замена бастарду docker-compose, правильно?

По-мне докер лучше. Сколько подман пробовал - вроде на 99% работает, но на 1% вечно что-то недоработано. Хотя пользоваться можно и тем и другим, но при прочих равных выберу докер.

Про подман и кубер ничего не понял.

podman-compose это копия docker-compose, да. Про бастарда тоже не очень понял.

vbr ★★★★
()

Если речь про https://docs.podman.io/en/v4.0.0/markdown/podman-play-kube.1.html то хз, выглядит как ненужное. Нужен кубер - ну и запусти его на локалхосте и не парь мозги с «Currently, the supported Kubernetes kinds are …». Там даже секреты не поддерживаются, чего там запустишь. В докер десктопе кубер запускается одной кнопкой. Да и без него тоже несложно.

vbr ★★★★
()
Последнее исправление: vbr (всего исправлений: 1)
Ответ на: комментарий от max_lapshin

В качестве cri там containerd же обычно, такой же, как в докере, в чем именно будет заключаться отладка? Гораздо полезнее бывает всю приложеньку поднять и интеграционные/e2e тесты погонять. Ну и доступ к кубу сейчас есть почти у любого, даже условный remote debug вполне распространённая практика.

George
()
Ответ на: комментарий от George

Смотри, я это всё расцениваю с точки зрения отчуждаемого софта. Возможно тебе привычнее концепция работы с экземпляром развернутого кластера, а я чаще сталкиваюсь с подготовкой софта так, что бы он потом уехал в чьи-то чужие ручки.

Поэтому для меня pod.yaml это часть контейнера, но да, операторы то всё равно надо отлаживать.

max_lapshin ★★★★★
() автор топика
Ответ на: комментарий от temak

Что значит взамен? Если ты про ещё одну реализацию того же самого мусора то нет, ни ещё одна, ни ещё десять реализаций докероподобного не нужны.

firkax ★★★★★
()

С докером попроще, если уже хорошо умеешь, но хуже по безопасности, если без sudo им пользоваться, то любая программа может запустить свой контейнер с примонтированным рутом с правами рута и делать что хочет:

docker run --rm -it --mount 'type=bind,src=/,dst=/mnt/root' alpine:3.18

Такой же трюк с подманом таки позволит смонтировать /, но там сработает uid remapping, контейнеру будет казаться что он рут, на деле nobody. Но эта же фича усложняет случай, когда нужно чтобы процесс в контейнере записывал примонтированные файлы с нужными uid/gid.

Говорят есть ещё какие-то ещё проблемы с сетью в юзерспейсе, как у подмана, так и у рутлесс докера, но я пока подробно не трогал.

Документация подмана намного хуже. Подман-компоуза в коробке нет, надо как-то компоуз докера приспосабливать.

neumond
()
Ответ на: комментарий от George

Но в реальной жизни в кубе никто не использует контроллер pod, а разве подман умеет деплойменты/стс? Хэлмы? Если нет, то в плане «поиграть с кубом» от него никакого толка

Container runtime не имеет никакого отношения к поддерживаемым в Kubernetes типам развёртываний и прочих ресурсов. Ни Podman, ни Docker не «умеют деплойменты/стс/хэлмы» и не должны.

intelfx ★★★★★
()
Ответ на: комментарий от intelfx

Да я и не говорю, что должны, я говорю, что в плане «проверки, как это будет работать в реальной жизни с оркестратором» замена докера подманом тебе ни в чем не поможет.

George
()
Ответ на: комментарий от max_lapshin

Тогда почему не докерфайл/чарт? Многие идут именно по этому пути, у многих в репах на гитхабе именно так организовано, и это достаточно удобно. Ну и для тестирования, хотел предложить любое доступное облако рядом + терраформом раскатывать кубик/лб/остальные нужные ресурсы, и прекрасно отладится в похожем на реальное окружение, а terraform destroy поможет не тратить лишних денег, решение по цене чашки кофе в неделю. Но не всем такое надо, конечно.

George
()

docker. podman — это редхатовское заместительное поделие для openshift чтобы не платить разрабам докера миллиарды. у него раньше фишкой были непривелегированные контейнеры… но они в и докер теперь есть, и чуть менее чем полностью эта фича бесполезна. есть еще архитектурные решения, которые не дают ровным счетом никакого выигрыша

rtxtxtrx ★★
()

Запустить rootless docker прям заметно сложнее чем подман. По крайней мере на убунте 24.04.

Потребовалось найти два скрипта dockerd-rootless.sh и dockerd-rootless-setuptool.sh, которые есть в гите докера. Для них вроде бы существует какой-то extras пакадж, но я не нашёл в родных репах убунты ничего похожего. Их можно глазами пробежать и подредактировать (к примеру пофиксить пути), они небольшие. Первый это обёртка для запуска dockerd рутлесскитом, второй это инсталлятор systemd юнита в юзерспейс, запускающего эту обёртку:

dockerd-rootless-setuptool.sh install

Далее нужно поставить россыпь всяких утилит, требующиеся впрочем и подманом (slirp4netns, uidmap, etc). Инсталлятор при запуске сообщит чего не хватает.

Далее нужно создать контекст, это штатный способ в докере общаться с множеством демонов. По сути создаёт файлы с конфигами, но это отдельные от config.json.

docker context create rootless
docker context update rootless --description "Rootless context" --docker 'host=unix:///run/user/1001/docker.sock'
docker context use rootless

Если всё получилось, то docker ps отработает без проблем. Можно ещё юниту разрешить автозапуск.

neumond
()
Ответ на: комментарий от firkax

я lxc + ansible использовал, сейчас по привычке и не умения в докер контейнер доустановку ssh юзаю, хотя value и прочим инструментам научился, баги докера с работой itable научился избегать.
Докер это быстро и удобно, хотя умение разобрать контейнер в проложение пока осталось, и иногда жутко полезно.

s-warus ★★★
()

подман однозначно лучше докера. Без дополнительных усилий запускается от юзера, не требует отдельный демон, есть (почти) встроенный композ, есть интеграция с сустемд для фанатов, есть опенсорсные клиенты под винду с макосью.

Подами я не пользуюсь, и что это такое вообще не знаю.

Из недостатков - раньше там требовалось отдельно настраивать сеть и маунты, но сейчас вся эта функциональность уже допилена до работающего из коробки состояния.

Lrrr ★★★★★
()
Ответ на: комментарий от Lrrr

встроенный композ

там композа нет, подман-композ это сторонний проект не редхатовский. скорее эксперимент. я пробовал им пользоваться, да оно как бы работает. но полную совместимость с композом он обеспечить не сможет, а без этого он не нужен

asdpm
()

если кто знает, подскажите, есть ли для подмана какая-то «более лучшая» удобная альтернатива докер-композу чтоб и локально и на сервере использовать? в частности композ может по up понять, что поменялось и все нужно пересоздать - после доставки на сервер нужных образов этого хватает чтобы «обновить версию на проде». для подмана я не понял какой инструмент это умеет. как-то пытался разобраться в подманоских кажется «кубелетах», но не понял, оно вообще призвано покрывать типовые паттерны использования композа или это что-то другое

asdpm
()
Ответ на: комментарий от neumond

спасибо за информацию. я как-то смотрел на подман, заметил, что он по дефолту никакого рута не требует, но много где говорят, мол сто лет уже как в докере то же самое, но насколько оно так проверить пока сил не находилось

asdpm
()

podman не замена docker-compose, а прозрачная замена самого докера. История такая. Red Hat очень сильно хотели запускать systemd внутри контейнеров, но для этого нужно было модифицировать код докера. В Docker Inc навстречу шапке не пошли. Тогда в Роли попросили Дэна Уолша запилить им замену с блекджеком и системд. И пошло-поехало. Кроме поддержки системд подман значительно улучшил безопасность контейнеров. Он работал без демона и не требовал рута. При этом сохранялась совместимость на уровне CLI. Потом podman оброс дополнительными фичами, такими как генерация ямлов для кубернетса, новые рантаймы и утилиты buildah и skopeo. Подман идеологически и методологически лучше.

kukuruku ★★
()

Podman лучше, почему - сверху раза 3-4 уже расписали, но скажу, что совместимость с Docker, а тем более с Docker Compose у него бывает очень хромает: приходилось переделывать сам docker-compose.yaml, еще больше понравились свистопляски с подбором флагов, чтобы работали точно также, как и с Docker CLI. Кэш помню по-другому работает, документация отвратительная, качество кода видимо тоже, потому что в разных версиях разные баги вылезали. Сетевое подключение из каких-то обрубков сделано (установи 3 пакета и настрой 2 конфига), хотя и Docker тут недалеко ушел: до сих пор перезаписывает iptables сам по себе лол. Так и сижу пока на обычном Docker + Docker Compose, подумываю про Rancher.

ac130kz ★★
()
Ответ на: комментарий от asdpm

встроенный композ

там композа нет,

Пчёл, подман натурально запускает тот же самый docker-compose, что и сам докер.

это сторонний проект не редхатовский

RHCE в треде, все на курсы «специалиста» при бауманке!

LamerOk ★★★★★
()
Ответ на: комментарий от ac130kz

совместимость с Docker, а тем более с Docker Compose у него бывает очень хромает:

Подман безрутовый, он априори не может всё тоже, что и докер.

Сетевое подключение из каких-то обрубков сделано (установи 3 пакета и настрой 2 конфига),

У него официальный способ создания сетей и прочего - через systemd. Читай доку.

LamerOk ★★★★★
()
Ответ на: комментарий от LamerOk

Подман безрутовый

Не в этом дело, между ними есть различия в различных переключалках, внутренней работе, из-за чего иногда создаются оказии.

Через systemd

Где искать? По systemd-networkd в их репозитории ничего нет. Есть только туториал, как я и говорил, DIY.

ac130kz ★★
()
Ответ на: комментарий от LamerOk

подман натурально запускает тот же самый docker-compose, что и сам докер

кроме https://github.com/containers/podman-compose я ничего не обнаружил, покрутил его пару дней и пришел к выводу что это не годится, потому что приходилось менять файлы именно под него и был еще какой-то момент.

похоже что я на тот момент запутался в их документации проглядел это.

тот же самый docker-compose

но docker inc. compose теперь же не существует как отдельно устанавливаемая программа и вшит в сам докер. получается подману чтобы это работало нужна будет инсталляция докера?

asdpm
()
Ответ на: комментарий от ac130kz

Сетевое подключение из каких-то обрубков сделано (установи 3 пакета и настрой 2 конфига)

я так понял там всё на этапе развития было, какие-то плагины прописывать нужно было, какие-то user id маппинги или что-то типа того. внутренняя резолюция вроде так у меня и не заработала.

asdpm
()
Ответ на: комментарий от ac130kz

Через systemd

Где искать?

Quadlet

Есть только туториал

Нужен туториал по системд, а не по подману.

DIY

Ну, написание конфигов в каком-то виде всё равно будет. Частично можно автоматизировать через podlet

LamerOk ★★★★★
()
Ответ на: комментарий от firkax

учавствовал в одном проекте, где нужно было готовый работающий проект докер-композа распотрошить и установить на виртуалки так сказать по классике, с установкой всех зависимостей в систему, их модулей, с созданием директорий проекта, разграничением прав и прочими изобретаниями велосипеда. просто потому что докер там не положен по каким-то идейным соображениям менеджера. наверно он твой единомышленник.

вот такой дурной «реверс-инжиниринг».

одинаково ненужны

как раз они НЕодинаково (не)нужны.

конечно, есть истории, когда докер запихивают в проект просто чтоб был (совсем как в начале моего сообщения, только наоборот), но есть и другие примеры, когда докер выручает. например, когда нужно иметь 100500 версий какого-то софта, допустим компилятора, или когда нужно что-то поставить на легаси с безнадёжно устаревшими зависимостями.

flant ★★★★
()
Ответ на: комментарий от flant

Ну, нормальный софт может работать без контейнеризации несколько версий одновременно. Но допустим софт не совсем нормальный, да и вообще тебе лень возиться с его рассовыванием по файловой системе. Да, тогда может пригодиться контейнер, но НЕ докер. Докер - это наглядный пример того как делать не надо. Хорошие контейнеры есть например в freebsd (jail) - они сделаны в виде понятного прозрачного chroot-а к которому добавлены ограничения на видимость процессов, сеть и ещё всякие мелочи. В линуксе такого из коробки нет, в большинстве случаев можно обойтись просто chroot-ом. Ещё есть unshare но там неподъёмный ман (не самого unshare а всего того что вместе с ним надо прочитать чтоб понять как им пользоваться) со всеми этими ненужными неймспейсами (докер на его основе сделан и ещё дальше всё запутал в своей работе).

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 1)
Ответ на: комментарий от firkax

Как насчет задачи собрать по пакету для 10 разных дистрибутивов? Через chroot можно, но это надо сначала его подготовить. А через Docker это можно сделать даже на другой системе.

MOPKOBKA ★★★★
()
Ответ на: комментарий от flant

тоже потрошил докер контейнеры, так как с мудрёным iptable глючил, сейчас он меня победил, потихоньку смирился, и надеюсь правильно использую, но старые велосипеды типо установки внутрь контейнера ssh для правки и доступа в ещё кое где остались, что грусно и обидно.

s-warus ★★★
()
Ответ на: комментарий от firkax

да кому в здравом уме нужно тратить силы на то, чтобы на компе держать несколько версий одного софта?

Ну и твои эти рассказы про «настрой чрут, ещё cgroups, ещё что-то нибудь» - вот и выходит docker/containerd/podman.

Прекращай нести эти старперские бредни или предлагай какую-то конкретику.

max_lapshin ★★★★★
() автор топика