LINUX.ORG.RU

Test Days для Podman 6.0

 , ,


0

2

Проект Fedora объявил о проведении серии Test Days для Podman 6.0 — следующего крупного релиза контейнерного движка, развиваемого как альтернатива Docker без центрального демона. Тестирование новой ветки проходит с 11 по 15 мая и ориентировано как на разработчиков, так и на обычных пользователей Fedora.

Podman 6.0 станет одним из крупнейших обновлений проекта за последнее время. Разработчики готовят заметную переработку сетевой подсистемы, обновления механизмов взаимодействия контейнеров и внутренние изменения в архитектуре runtime-компонентов. Часть нововведений направлена на улучшение совместимости с Kubernetes и OCI-инструментами.

В Fedora отмечают, что основной задачей Test Days является проверка обратной совместимости и выявление проблем в реальных сценариях эксплуатации. Пользователям предлагается протестировать:

  • запуск rootless-контейнеров;
  • работу compose-совместимых конфигураций;
  • сетевые режимы;
  • взаимодействие с systemd;
  • миграцию существующих окружений с Podman 5.x.

Особое внимание уделяется изменениям в контейнерных сетях. Разработчики продолжают постепенную модернизацию сетевого стека, включая улучшения интеграции с Netavark и Aardvark DNS — компонентами, пришедшими на смену старым CNI-механизмам.

Podman давно стал одним из ключевых компонентов экосистемы Fedora и Red Hat. Проект активно используется в серверных Linux-дистрибутивах, CI/CD-инфраструктуре и средах разработки благодаря поддержке rootless-режима и совместимости с OCI-контейнерами без необходимости постоянно работающего daemon-процесса.

Релиз Podman 6.0 ожидается после завершения тестирования и исправления найденных ошибок. Разработчики Fedora подчёркивают, что участие сообщества в Test Days напрямую влияет на стабильность будущего выпуска.

>>> Источник

★★★

Проверено: hobbit ()
Последнее исправление: hobbit (всего исправлений: 1)

Я только одного не понимаю, чего они так педалируют отсутствие демона? Что в этом хорошего?

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

Что у них за фобия с демоном?

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

Скорее Н - неработоспособность.

Зачем тогда демон файрволд сделали? Он ещё меньше нужен.

Имхо это маркетинг отчаянья.

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

Я только одного не понимаю, чего они так педалируют отсутствие демона? Что в этом хорошего?

Что у них за фобия с демоном?

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

Подман с демоном - это просто докер.

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

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

xgatron
()
Ответ на: комментарий от r--r--r--

Единственное важное отличие - поддержка системд в контейнерах.

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

Еще одно важное отличие - реализация совместных ресурсов через поды и синтаксис в ямл в стиле кубернетис в противовес композа с ямлом в докере.

И то и другое имхо не взлетело. Сам не разбирался, но есть подозрение, что вместо podman сделали systemd nspawn. Понятно, что оно от докера оно ушло заметно дальше, но сама реализация куда как логичней для запуска систем, а не приложений.

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

Еще одно важное отличие - реализация совместных ресурсов через поды и синтаксис в ямл в стиле кубернетис в противовес композа с ямлом в докере.

Они буквально докеркомпоз втащили себе чуть ли не раньше, чем сам докер.

Сам не разбирался, но есть подозрение, что вместо podman сделали systemd nspawn.

Есть подозрение, что ты пишешь какую-то пургу. Podman с systemd вообще никак не связан, они оба два совершенно независимы друг от друга.

r--r--r--
()
Ответ на: комментарий от xgatron

Как минимум минус одна точка отказа между контейнером и системд.

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

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

The command flag –user (or shorthand -u) in Docker is used to specify which user and/or group a container should run as.

Чтобы образ собрать демон тоже не особо нужен.

по минимуму да, но может и потребоваться. Демон позволяет гибко автоматизировать процессы. Не случайно везде уже всунули докер в автосборку и мало кто (?) использует подман.

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

Не совсем понятно, что значит «держать»? Демон запускается сам по обращению к сокету. Сейчас посмотрел, демон rss 92мб и процессор ноль. Даже на сервере с 4 гигами это просто ни о чем. Греп жрет больше. Докеры прекрасно работают на тв приставках с 2 гигами.

Хозяйственный же ты парень… ;)

usermod
()
Ответ на: комментарий от r--r--r--

Есть подозрение, что ты пишешь какую-то пургу. Podman с systemd вообще никак не связан, они оба два совершенно независимы друг от друга.

ясно понятно. вопросов больше нет.

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

Единственное важное отличие - поддержка системд в контейнерах.

Что ты несёшь? Он и в обычном докере работает без проблем. Другое дело что я давненько уже не видел прод систем которые до сих пор на podman не переехали.

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

The command flag –user

Это не имеет отношения к rootless.

Мне этот флаг не нужен, я сразу без свистоперделок внутри root без sudo и прочего.

galanthus
()
Ответ на: комментарий от r--r--r--

Подман с демоном - это просто докер.

Это подман. У него есть режим демона. Специально для совместимости с докером.

galanthus
()
Ответ на: комментарий от r--r--r--

Это буквально единственное важное отличие от докера.

Что-то там говорили, что docker не совсем свободный, потому есть podman — свободная замена не совсем свободному докеру.

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

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

А у подмана делаешь podman machine start - и все, можно пользоваться.

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

Это буквально единственное важное отличие от докера

Нет.

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

А что там - демон или не демон - вообще плевать, это какие-то мелкие детали реализации, которые ни на что не влияют на практике.

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

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

извините, но я умею мониторить нужные мне параметры и без докера

управление через универсальный rest

есть podman.socket, он вам на чуть-чуть запустит демона с универсальным рест

любые хуки и колбеки.

их нужность зависит от задачи. Как и мониторинга с рестом

The command flag –user (or shorthand -u) in Docker is used to specify which user and/or group a container should run as.

это про пользователя в контейнере, а я про пользователя, который будет «владельцем» контейнера — от этого пользователя будут работать вспомогательные процессы и на него будет отображаться (idmap) рут в контейнере. В случае докера «владельцем» контейнера будет пользователь от которого запущен демон.

по минимуму да, но может и потребоваться. Демон позволяет гибко автоматизировать процессы. Не случайно везде уже всунули докер в автосборку и мало кто (?) использует подман.

как минимум докер был первым, потому его всунули везде, где можно.
Задачи у всех разные — кто-то прокидывает сокет или использует dind чтобы гибко автоматизировать процессы, кто-то использует билдах, канико и пр.

Не совсем понятно, что значит «держать»? Демон запускается сам по обращению к сокету. Сейчас посмотрел, демон rss 92мб и процессор ноль. Даже на сервере с 4 гигами это просто ни о чем. Греп жрет больше. Докеры прекрасно работают на тв приставках с 2 гигами.

Не совсем понятно, почему вы распоряжаетесь оперативной памятью других людей :) То, что у меня может быть 128ГБ оперативки не значит, что я хочу запускать все программы сразу.
Насчет 92мб верю, но есть проблема в том, что я видел процессы докера по 30+ГБ — вот он наелся и спит.
И висящие намертво тоже видел — главное live-restore включить до обнаружения таких, иногда бывает необходимость не убивать контейнеры

xgatron
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.