LINUX.ORG.RU

Выпуск Podman 2.0

 ,


0

3

Разработчики анонсировали первый выпуск «Podman 2», мажорного обновления проекта podman – утилиты создания, запуска и управления контейнерами стандарта OCI. Podman является альтернативой проекту Docker и позволяет управлять контейнерами без наличия фонового системного сервиса и не требуя root-прав.

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

Основным отличием второй версии является полнофункциональный REST API. Экспериментальная реализация API на основе varlink была доступна и в первой ветке, но в новой версии она была полностью переработана. Вместо varlink-интерфейса теперь используется стандартный HTTP API.

Новый REST API имеет два слоя: интерфейс к функциям библиотеки libpod и слой совместимости частично реализующий функции Docker API. Для новых приложений, разумеется, рекомендуется использовать «родной» интерфейс libpod.

Новый REST API позволил существенно уменьшить размер клиентского приложения podman для Mac и Windows.

Основные изменения:

  • REST API и podman system service больше не считаются экспериментальными и готовы для использования.
  • Команда podman может подключаться к удаленному сервису podman с помощью флага --remote.
  • Клиент podman был полностью переписан и теперь использует HTTP API вместо Varlink.
  • Добавлена команда podman system connection для конфигурирования удаленных подключений, которые затем используются командами podman-remote и podman --remote.
  • Команда podman generate systemd теперь поддерживает флаг --new, и может создавать systemd-сервисы для подов.
  • Команда podman play kube поддерживает запуск deployment-объектов Kubernetes.
  • Команда podman exec command получила флаг --detach для выполнения команд в фоне.
  • Флаг -p для команд podman run и podman create теперь поддерживает форвардинг портов на IPv6-адреса.
  • Команды podman run, podman create и podman pod теперь поддерживают флаг --replace для пересоздания контейнера с тем же именем.
  • Флаг --restart-policy для команд podman run и podman create теперь поддерживает политику unless-stopped.
  • Флаг --log-driver для команд podman run и podman create может принимать значение none, которое отключает запись логов контейнера.
  • Команда podman generate systemd принимает аргументы --container-prefix, --pod-prefix и --separator, управляющие создаваемыми юнитами.
  • Команда podman network ls поддерживает флаг --filter для отсеивания результатов.
  • Команда podman auto-update поддерживает указание файла authfile для контейнера.

>>> Подробности

★★★★★

Ответ на: комментарий от eR

дома оно ненужно

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

Как минимум можно забыть про проблемы управления правами на примонтирвоанные данные.

alpha ★★★★★ ()

Podman является альтернативой проекту Docker и позволяет управлять контейнерами без наличия фонового системного сервиса и не требуя root-прав.

Он требует создавать свои собственные образы, или совместим с докеровскими? Если совместим, то в обе ли стороны?

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

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

Т.е. по сути миграция будет максимально простой.

mx__ ★★★★★ ()

У докера обнаружили фатальный недостаток? Не считать же этим «Podman является альтернативой проекту Docker и позволяет управлять контейнерами без наличия фонового системного сервиса и не требуя root-прав.». В нормальных дистрибутивах для работы с контейнерами достаточно добавить пользователя в группу docker, а в то, что наличие демона является проблемой мне крайне сложно поверить.

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

Раньше я тоже думал, что список возможностей сам по себе продаёт решение. Если продукт А обладает набором возможностей S, а продукт Б — S+S1, то нужно немедленно выкинуть А и прейти на Б. Но потом я понял, что это так не работает. Информационные продукты нужны, чтобы решать проблемы. Если программа решает мою проблему, то это хорошая годная программа, бегу устанавливать. А если не решает — то она мне безразлична. При этом она может быть хорошей и замечательно решать проблемы, которых у меня нет, мне всё равно.

Поэтому правильная аргументация в сторону подмана должна быть такая: у тебя есть проблема. Нет, ты не понял, у тебя ЕСТЬ проблема. И сейчас мы её решим за скромную сумму денег.

Вот я и спрашиваю, какую мою проблему решает переход с docker’а на podman? Я может не знаю чего, интересно же.

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

Для нормальных ответов надо нормально задавать вопросы. А так - как спрашиваешь так и получаешь.

Разумеется, один централизованный сервис в фоне - это проблема.

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

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

Опять же с Docker нельзя не только применять стандартное управление сервисами через systemd, но и встраивать контейнеры в другие системы. Например OpenMPI (https://podman.io/blogs/2019/09/26/podman-in-hpc.html)

И т.д. и т.п.

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

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

https://docs.docker.com/engine/security/security/#docker-daemon-attack-surface

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

Для нормальных ответов надо нормально задавать вопросы.

Т.е. вопрос «какие преимущества ваша альтернатива имеет перед уже имеющимися решениями?» не считается нормальным. Отличное начало, продолжайте.

Разумеется, один централизованный сервис в фоне - это проблема.

Не припомню ни одного инцидента, причиной бы которого было управление контейнерами через демон докера.

он дублирует функции системного управления процессами

Аргумент. С другой стороны всё равно нужен какой-то оркестратор. Так что следующим шагом у вас будет: смотрите все, в версии podman3 мы добавили podman-manager, который будет мониторить наши чудесные контейнеры, перезапускать их и т.д.

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

Да и это решается так:

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

  2. Иногда есть группы пользователей с ограниченными правами. Например fron-dev имеет доступ к контейнерам front*, back-dev — к back*, админы — ко всему. Решается на уровне sudo. Может не самое изящное решение, но отлично работает.

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

Занятная возможность. Однако,как правило, если меня это беспокоит, у меня уже есть k8s со всеми вытекающими.

с Docker нельзя не только применять стандартное управление сервисами через systemd

systemd — это проблема.

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

Кстати, а как в podman ставить образы с hub.docker.com?

Как обычно.

В отличие от Docker, который хардкодит DockerHub и не принимает патчи чтобы сделать дефолтный реп конфигурируемым, podman позволяет сконфигурировать несколько источников образов и ищет по ним по очереди.

Источники можно настроить в системном конфиге или в пользовательском.

Посмотреть настроенные репы можно с помощью

$ podman info --format={{".Registries"}}
map[search:[registry.fedoraproject.org registry.access.redhat.com registry.centos.org docker.io]]
alpha ★★★★★ ()