LINUX.ORG.RU
Новости — Open Source  

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

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

★★★★★

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

 ← 1 2 3 4 →
Ответ на: комментарий от dexpl

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

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

А podman pull image будет работать одинаково вне зависимости от того запускаю ли я это на своём ноуте, на сервере в штатовском дц или на сервере в гонконге, который должен тащить образ с приватного зеркала registry развернутого там же, потому что с доступом в штаты там проблема

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

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

Выглядит логичным, жаль в docker такого нет.

Samamy ★★★
()
Ответ на: комментарий от Samamy
  1. наличие 24х7 техподдержки. Что если какой-то косяк влезает, его чинят. Начиная от драйверов железа и заканчивая багами в ядре.
  2. вытекает из 1 - ответственность. Если из-за косяков софта полетели данные клиентов, судить будут не тебя. Или иск можно перенаправить.
anonymous
()
Ответ на: комментарий от anonymous

вытекает из 1 - ответственность. Если из-за косяков софта полетели данные клиентов, судить будут не тебя. Или иск можно перенаправить.

Покажи хоть одного вендора, который забыл прописать отказ от ответственности за потерю любых данных.

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

Учение Поттеринга всесильно, потому что он верно!

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

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

это не удивительно, все же понимают, что такое rh и его творения.

возможно, k8s в ibm cloud использует podman :)

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

Допустим, у меня есть Jenkins, который динамически запускает slave-узлы в AWS

я всё думал, что же ты такой тупой, а ты, прости хоспаде, девопс, ну это всё проясняет

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

Формат образов и рецептов у подмана и докера совпадает, насколько я знаю.

Это хорошо или плохо?

Обычно под ЕЕЕ понимают, когда первое что делают, это меняют формат.

AVL2 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
 ← 1 2 3 4 →
Open Source