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 для контейнера.

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

★★★★★

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

Так вот вы о чём. Действительно, разрешать кому попало полный доступ к докеру не лучшая идея.

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

так создаю же в toolbox контейнер, или в подман качает другие контейенры? ничё не понимаю

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

Вот казалось бы, какая разница чем демоны запускать? Кому вообще кроме отъявленных гиков есть дело до этой мелкой технической детали реализации? Ан нет, приходится всю систему перепахивать от DE до оркестратора контейнеров.

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

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

Это говорит только об ограниченности опыта.

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

Нет.

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

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

Может не самое изящное решение, но отлично работает.

Смешно.

у меня уже есть k8s со всеми вытекающими

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

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

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

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

Насколько я знаю toolbox это просто надстройка над podman которое использует только 1 тип контейнеров равный оси хозяина.

mx__ ★★★★★ ()

Альфа, сделай плз снап пакет для убунты. Очень хочу свалить с докера, достали проблемы с правами.

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

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

И все из-за невменяемой системы распространения софта, в том числе дурной fhs, криворуких разработчиков…

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

криворуких разработчиков

Выключи компьютер, пожалуйста.

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

alias docker='podman'

осталось придумать алиас для docker-compose и будет норм

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

На самом деле не всегда работает, чего бы там редхат не говорил.

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

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

Полностью совместим с докерным.

Это ложь. На чем-то сложнее, чем hello world, podman работает иначе, чем docker, и прямое использование прошлой архитектуры становится невозможно.

Сделано намеренно, чтобы люди, переходящие на podman, больше не могли использовать Docker, а RedHat захватывал бы рынок.

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

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

На самом деле не всегда работает, чего бы там редхат не говорил.

Это наверняка @alpha от анонимуса. Она любит тут продвигать проекты, за продвижение которых ей платят.

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

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

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

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

alias docker=‘podman’

То есть полная совместимость и по ключам командной строки?

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

Это говорит только об ограниченности опыта.

Может быть. Я всего лишь человек и этого не скрываю. Может быть вы поделитесь вашим богатым опытом, приведёте пример когда наличие выделенного демона привело к возникновению инцидента?

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

На своём ПК пользователь — полновластный хозяин. На production ему хода нет.

Смешно.

Сражён аргументацией. Что ещё расскажете?

k8s «со всеми вытекающими» максимально заинтересован

Всё это замечательно, но это общие рассуждения «мы стали более лучше оркестрировать». А я спрашивал какую мою проблему podman может решить здесь и сейчас. Чувствуете разницу?

нужен KISS-подход, окажется хейтером systemd.

Согласно последней редакции русского языка запрещается использовать KISS и systemd в одном предложении.

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

А я спрашивал какую мою проблему podman может решить здесь и сейчас.

Ты спрашивал зачем нужно rootless и serverless-управление контейнерами. Я тебе на это ответила.

То что у тебя use case ни о чём, и тебе ничего не нужно, это твоё личное дело.

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

По многим ключам, но некоторые расхождения могут вылезти.

Ну и у podman больше интересных ключей и фишечек, так что имхо использовать алиас нет смысла, лучше учить podman и его возможности.

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

На своём ПК пользователь — полновластный хозяин. На production ему хода нет.

Какой-то тупняк. Что в проде, что в разработке, вполне нормально иметь на сервере разграничение прав. В том числе иметь сервисы, которые могут останавливать/запускать только отдельные группы пользователей. Это могут быть разные отделы разработки на тестовом стенде, или например отдел поддержки конкретного продукта в продакшене, не суть. Когда есть «все админы» которые могут делать всё - это или маленький проект, или шарагоподход.

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

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

А я спрашивал какую мою проблему podman может решить здесь и сейчас

Ну я вот переехал ( с матом, багрепортами и прочим горем ) на подман для девелопмента. Надоели пляски с sudo и прочими костылями.

Кое-как проблему для rootless билдов решает. Хотя, конечно, fuse-overlayfs и slirp4netns это те еще косые костыли.

vasily_pupkin ★★★★★ ()

Как на десяточке работает? Можно подсунуть в Docker Desktop?

paramon ()

больше вендорлоков богу вендорлоков

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

Вопрос: какую мою проблему подман решает лучше докера?

Ответ: ну он там внутри себя более лучше устроен.

Вот и поговорили.

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

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

В большинстве дистров «добавить пользователя в группу docker» – это по сути дать ему root.

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

Я соотношу данную информацию со своим опытом, технологии применяются в рамках определённых сценариев использования. Если программа помогает решить проблему в реалистичном сценарии — это замечательно. Если программа помогает решить проблему секса стоя в гамаке на лыжах — … По-моему, нормальный подход.

Если вы согласны, идём дальше. По возрастанию сложности мы можем выделить ситуации:

  1. (локальная) песочница — нет нужды в разграничении прав.

  2. Мелкий прод — все админы могут всё и это правильно.

  3. Крупнее — админы могут всё, служба поддержки может запускать строго определённый (sudo) список команд, включая докерные.

  4. По-взрослому — никто не может ничего, всё запрещено, даже логина нет, оркестрация через k8s, логи через ELK, мониторинг через графану и т.д.

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

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

Кое-как проблему для rootless билдов решает.

Допустим, у меня есть Jenkins, который динамически запускает slave-узлы в AWS. В чём проблема, что на данном узле jenkins-agent может творить любую фигню?

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

В таком кейсе (короткоживущий инстанс под один таск) этой проблемы нет, вполне очевидно.

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

служба поддержки может запускать строго определённый (sudo) список команд, включая докерные

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

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

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

Сейчас очень популярно работать с «тонких» ноутбуков, и посему «мейнфреймы» (теперь называющиеся билд-сервера) снова в моде. Не настолько уж и редкий use-case.

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

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

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

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

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

хочу пример!

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

Смысл в твоем sudo если уже возможность выполнения докерных команд - повышение привелегий?

С помощью sudo можно разрешить конкретную команду, например docker logs -f mongodb можно, а docker run ... уже нет. Таким образом операционный инженер может посмотреть логи монго, но не украсть содержимое секретных файлов.

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

«мейнфреймы» (теперь называющиеся билд-сервера)

Но ведь это совершенно разные модели использования. На мэйнфрейм одновременно заходят и работают сотни людей и без должной изоляции тут никуда. А на сборочной ферме, CI slave и т.д. людям вообще делать нечего. Есть строго один пользователь под которым работает jenkins-agent (например). И тот — дань традиции, в модели одна задача — один сервер можно вообще под рутом работать, это ни на что не повлияет.

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

Придётся постараться. А можете и не. Это всё равно.

ugoday ★★★★★ ()

Мне уже плохо от всех этих систем контейниризации и слоёв на слоё. Пипец, как это всё работает и почему?

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

и слоёв на слоё.

Да нету никаких «слоёв на слое». Есть несколько пространств имён в которых можно запускать процесс и пара утилит для упрощения этого дела. Просто запустите один и тот же процесс в докере/подмане и без них и сравните производительность.

ugoday ★★★★★ ()

Ненужно! Учите сразу куберетис, даже если это тупо локалхост. Благо микро-дистрибутивов кубера хватает.

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

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

KISS-подход

хейтером systemd

KISS

systemd

Тебе самой не смешно эти слова в одном предложении использовать?

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

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

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

Может быть вы поделитесь вашим богатым опытом, приведёте пример когда наличие выделенного демона привело к возникновению инцидента?

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

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

Баш портянки рулят.

с systemd эти портянки дополняются ещё и лапшой зависимостей и глюками/костылями самого systemd.

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

большинство представителей пресловутого одного процента

Some outlaw motorcycle clubs can be distinguished by a «1%» patch worn on the colors. This is said to refer to a comment by the American Motorcyclist Association (AMA) that 99% of motorcyclists were law-abiding citizens, implying the last one percent were outlaws

Зачем байкерам докер?

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

контейнеры уплыли в неизвестность.

По идее же должны работать как работали. Вплоть до перезапуска демона докера.

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

Еще и на Go вместо Rust. Кому это нужно?

Докер на Go – так копи-пастить проще.

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

У докера обнаружили фатальный недостаток?

У него один фатальный недостаток – очень долго всё это вот. Временные контейнеры в большинстве случаев не нужны вовсе. Из 50-ти команд нужны они раза 4. Т.е. формат докерфала таков, что он там всё сам делает, вместо того, чтобы делегировать пользователю как раз управление его временными/промежуточными контейнерами и прочим.

Podman его не решает.

(И ещё один – память он не использует толком, даже если её запас. Что долго).

kostyarin_ ★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.