Комментарии 30
На мой взгляд проблема перехода с docker на podman как раз в отсутствии строить кластер встроенными средствами, как docker swarm.
Так и получается, у тебя ничего (просто контейнер), либо чугунный мост в виде кубера - что как бы не очень удобно.
Справедливое замечание, пусть и корявый, но готовый инструмент оркестрации из коробки, для большей части простых задач будет скорее всего быстрее и проще, чем развёртка полноценного и самостоятельного.
Подскажите, а в чем кривость swarm?
Использую его как простой и легковесный способ поднять кластер и настроить деплой с хелфчеками.
Куча перспективных проектов, пилящихся в своё время под Swarm загнулось. Кубер победил, увы. Это я говорю как человек, только недавно поднявший дома кластер Swarm для своих сервисов - как раз по причине того, что для трех нод с достаточно ограниченной оперативкой кубер на мой взгляд - это перебор.
В кубере как - хочешь общий сторадж? Вот тебе 100500 готовых вариантов разной степени паршивости.
А в Swarm - будь добр готовить это сам. Если у тебя УЖЕ есть, например, CephFS(которую нынче можно даже мышкой накликать в том же Proxmox, разве что отдельного юзера и права к нему отдельно из консоли покрутить придется) - то это конечно не проблема. А если нет?
Если бы автор так яростно не кривлялся, статья была бы лучше.
Пол года пользуюсь podman + podman desktop (компания получила "письмо счастья" от Docker inc с просьбой купить подписочку всем сотрудникам с Docker Desktop и все пересели на альтернативы).
Есть ещё некоторые шероховатости в запуске yaml'ов docker-compose через podman compose, но в целом для большинства задач подходит отлично.
Самый жырный минус пока что - не получится запустить в podman проект docker compose, в котором контейнерам назначены gpu-ресурсы. Просто не умеет в такой формат. Так что приходится извращаться с общими сетями для запуска какой-нибудь ollama и open-webui локально.
Вечное проклятие UNIX-подобных систем, GPU-вычисления. Надеюсь что в скором времени это допилят и прокинуть доступ к GPU будет также просто и на Docker, чтобы окончательно забыть про "письма счастья".
Самый жырный минус пока что - не получится запустить в podman проект docker compose
podman-compose или standalone бинарь docker-compose
Команда `podman compose` по сути врапппер для провайдера compose функционала (дока)
в то время как Docker для FreeBSD в нативном-виде скорее мёртв, чем жив
Использование Docker с FreeBSD через bhyve(реализация, аналогичная MacOS/xhyve, но на FreeBSD/bhyve)
https://www.bsdstore.ru/ru/articles/docker_on_freebsd.html
Podman желательно использовать с buildah и skopeo
Когда в конце мая заблокировали Docker Hub, я и не заметил. Настроено проксирование через mirror.gcr.io.
https://github.com/containers/podman/blob/main/test/registries.conf
Freebsd, увы, мертв уже лет 15 как.
А podman я пользую, есть некоторые моменты неприятностей, запуск systemd внутри контейнера, но вроде бы сейчас все нормально.
А мне очень понравилась их новая интеграция контейнеров с systemd - пишешь systemd unit который запускает контейнер: https://docs.podman.io/en/latest/markdown/podman-systemd.unit.5.html
Держу на подмане пачку домашних контейнеров(ha+обвязка,minecraft, и прочее) хорошая штука когда для k3s ресурсов маловато.
Ceph на podman прекрасно бегает. Не то чтоб осознанный выбор, просто на момент первого знакомства, самый актуальный вариант был именно по такому варианту запуска.
Но как же тогда он запускается, сам себе демон, что-ли? Нет, просто, в отличие от Docker, Podman использует не демона, а ДЕМОНЮГУ, на миллион+ строк кода, имя которому Сот… SystemD.
Как это относится к скачиванию и запуску контейнеров? Для работы podman под пользователем не нужно дополнительных сервисов и прав.
я ещё не встречал тех, кто бы использовал Podman
Для разработки использую и на линукс, и на виндовс, потому как проще поставить.
Использую на домашнем Docker, потому что у него есть в комплекте тот же Scout и есть docker compose. Не знаю аналогов Docker compose в Podman. Вот чтобы compose, но без swarm
Nerdctl - это не совсем podman, но позволяет работать с compose-файлами без набора инструментов от docker. У себя на проекте перевёл сборку образов на podman. Пришлось правда сделать свою сборку sbt-плагина, для сборки образов. И не могу сказать, что работает сильно стабильнее докера.
Так, какова выгода?
Агент ci/cd-сервера теперь не требует лишних прав и доступов к сокету демону докера. Соответственно, нет необходимости тащить его на все ноды, где кубер может запустить агента. На миньёнах и мастерах кластера теперь только containerd стоит, который в дальнейшем тоже можно будет заменить по необходимости, без большого влияния на ресурсы, развёрнутые в кластере.
В плане автоматизации настройки ноды для кластера - упрощение плейбуков ansible, используемых в компании.
swarm отличная и удобная штука для небольших проектов. Особенно в условиях, когда кубер начал сдуваться в России с огромной скоростью. Иностранных компаний которые его пушали нет, спецы разбежались, короче кубер остался в прошлом на мой взгляд.
По мелочи пробовал запускать всякое в подмане, столкнулся с тем, что не работает проброс портов средствами самого подмана. Приходилось использовать виндовую утилиту netsh для этого, пока я не столкнулся с тем, что она не может пробрасывать udp траффик.. в итоге пришлось городить велосипед с использованием опенсорсной утилиты sudpipe. В общем, в итоге всё работало довольно некрасиво (но работало, да), так в итоге докером и пользуюсь.
Недавно как раз на macos переехал с Docker Desktop (который homebrew cask) на docker (который formula) в связке с podman и limactl, и Podman Desktop в качестве «красивого окошка» (к моему сожалению Podman Companion как будто перестали развивать).
В целом полет нормальный, потерял разве что в каких-то свистелках, типа cli-plugins (и то их можно доставить дополнительно (можно добавить их в homebrew-core и станет сильно проще)), но и не сказать чтобы прям выиграл.
Могу сказать что стало удобнее делить окружения и управлять выделенными ресурсами - например minikibe/kind запускаю только в podman или например авторизацию в приватные registry храню только в lima машине.
В целом, как по мне, это было в довольно развлекательно-образовательно, потраченного времени не жалею.
Недавно как раз на macos переехал с Docker Desktop (который homebrew cask) на docker (который formula) в связке с podman и limactl, и Podman Desktop в качестве «красивого окошка» (к моему сожалению Podman Companion как будто перестали развивать).
В целом полет нормальный, потерял разве что в каких-то свистелках, типа cli-plugins (и то их можно доставить дополнительно (можно добавить их в homebrew-core и станет сильно проще)), но и не сказать чтобы прям выиграл.
Могу сказать что стало удобнее делить окружения и управлять выделенными ресурсами - например minikibe/kind запускаю только в podman или например авторизацию в приватные registry храню только в lima машине.
В целом, как по мне, это было в довольно развлекательно-образовательно, потраченного времени не жалею.
Как только Docker Desktop стал платным и коллеги отправились в путешествие в разные стороны (кто-то к менеджменту за лицензиями, кто-то к Rancher), я перешёл на Podman в WSL на своей рабочей машине, и до сих пор на нём сижу, не испытывая серьезных проблем. Когда появился Podman Desktop, стало вообще кайфово. Даже очень сложные компоузы от коллег прекрасно запускаются и работают.
Испытываю весьма теплые чувствства к redhat, мне кажется они много прекрасного делают
Использую podman на Ubuntu self-hosted сервере домашнем. Для Cockpit есть плагин, который заменяет часть функционала Portainer.
В статье ни слова о концепции собственно подов в Podman, которые с одной стороны позволяет использовать некоторый функционал группировки контейнеров без k8s, а с другой стороны облегчает переезд на k8s, когда проект к нему созреет.
Вы должны перейти на Podman сейчас же. Но это не точно…