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

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

★★★★★

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

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

А как бы вы это сделали?

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

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

Пруф или GTFO.

intelfx ★★★★★ ()

Годно, нужно. Разобраться наконец в синтаксисе podman, что ли.

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

Флаг –restart-policy для команд podman run и podman create теперь поддерживает политику unless-stopped.

А как, кстати, это работает без центрального демона? podman под капотом создаёт systemd-юниты?

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

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

https://www.redhat.com/en/blog/red-hat-openshift-container-platform-4-now-defaults-cri-o-underlying-container-engine

With OpenShift 4, the default container engine is moving from Docker to CRI-O, providing a lean, stable, simple and boring container runtime that moves in lock step with Kubernetes.

А как, кстати, это работает без центрального демона? podman под капотом создаёт systemd-юниты?

Я так поняла что --restart – это в рамках одного процесса podman. То есть если процесс внутри контейнера завершится, то podman-обертка его снова запустит. Но если сам podman завершится - то всё, перезапускать будет некому.

А systemd-юниты он умеет генерить, но это не под капотом, а явно, через вызов podman generate systemd.

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

А как бы вы это сделали?

Делегировал бы пользователю и всё – типа ставишь чекпоинты по местам разным в докерфайле. Зачем мне intermediate container на каждый чих и команды составленные в виде x && y && z && a в 50 стопок, просто чтобы он не создавал их. Это назвается поместить себя в рамки, чтобы костылями их решать. Да он ещё для них хэш считает. Это ппц.

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

Временные контейнеры в большинстве случаев не нужны вовсе. Из 50-ти команд нужны они раза 4.

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

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

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

Прямо сейчас через gcloud container ты можешь запуститься с cos_containerd или ubuntu_containerd без докера.

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

Собираю докерфайлом, начальство на ковер не вызывало =D

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

buildah уже научился использовать кеш?

Если нет, то я лучше продолжу использовать kaniko.

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

троллинг тупостью, это не троллинг

земля те пухом

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

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

Доки по сборке Го-приложений это вообще нечто. Пайк пыхтел писал быстрый компилятор, чтобы всё это просто было перечёркнуто в Докерке до нуля. Аутентичный пример

COPY go.mod .
COPY go.sum .
RUN go mod download

# ^^^ трудно представить, но это нужно для ускорения сборки в контейнере

COPY . .

RUN go build -o main .

Собственно давече go.sum ещё обновлялся на каждый чих. А go mod download тащит все зависимости по сети, Карл.

Sic transit gloria mundi.

@alpha, @ugoday, ну и собственно выгодней было бы кэшировать как раз последствия чертовски долгой go mod downalod, для которой нужны go.mod и go.sum (каждый раз обновлённые с некоторой вероятностью); причём кэшировать на неделю или на какой-то предельный размер, например, чтобы не таскать по сети каждый раз всё это.

P.S.: ну и чё buildah могёт так?

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

Делегировал бы пользователю и всё

Я не понимаю что это значит. Приведите пример что ли «правильного» Dockerfile.

команды составленные в виде x && y && z && a в 50 стопок,

А как тогда объяснять когда слои создавать, а когда — нет?

Да он ещё для них хэш считает. Это ппц.

Почему ппц и как надо?

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

Прямо сейчас занимаемся миграцией части кластеров с 6 на 7. Ни у кого из команды не возникло таких бредовых мыслей, как у тебя, относительно systemd. Так как все - профессионалы своего дела, то просто разбираемся, как решать наши задачи с помощью этого инструмента. И да, возраст от 30 до 50.

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

Меряться пенисами — давняя и славная забава, но чтоб чужими …

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

Меряться пенисами — давняя и славная забава, но чтоб чужими …

Тебе виднее, чем ты там меряешься. Я бы на твоем месте задумался на тем, что не так с твоей способностью к обучению, если такая очевидная в плане эволюции вещь, как systemd, вызывает у тебя резкое неприятие.

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

Непонятно что ты вообще хотел этим примером сказать.

Ты для сборки скачиваешь исходники внутрь контейнера по сети а виноват в этом контейнер?

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

Ты для сборки скачиваешь исходники внутрь контейнера по сети а виноват в этом контейнер?

Нет проблемы качать их по сети. Есть проблема невозможности оставить их там, в контейнере, не смотря на будущие изменения go.mod и go.sum. Ну и так далее…

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

Я не понимаю что это значит. Приведите пример что ли «правильного» Dockerfile.

Явно делать промежуточные контейнеры. Что тут может быть не понятно?

А как тогда объяснять когда слои создавать, а когда — нет?

А что если первые 15 команд мне нужна только изоляция, а не слои? Как тогда Докер должен это понять?

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

Есть проблема невозможности оставить их там, в контейнере

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

Тогда как раз кеш у тебя будет доступен сразу и качать его заново не понадобится.

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

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

То есть на хостах где отличная от systemd система инициализации podman вообще не будет работать ? Так как часть функционала docker, podman использует из systemd ?

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

Ты просто слепил сборку софта со сборкой контейнера и жалуешься. Софт надо отдельно собирать, контейнер - отдельно. Потому что последнее это для рантайма. Потому что это разные задачи и кешируются они по разному.

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

А какие есть production quality дистры без systemd?

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

Ты просто слепил сборку софта со сборкой контейнера и жалуешься. Софт надо отдельно собирать, контейнер - отдельно. Потому что последнее это для рантайма. Потому что это разные задачи и кешируются они по разному.

Я не могу вылезти из контейнера потому что сборка софтины идёт на основе другого контейнера с какими-то там специальными либами, используемыми при сборке (софтины).

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

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

А чем не устраивает ? docker pull example.com/test-image

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

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

Только это будет отдельная штука, которую ты можешь ставить, а можешь и не ставить.

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

Явно делать промежуточные контейнеры.

Образы наверное. Что вам сейчас мешает явно сделать промежуточный образ, а потом FROM my-base-image:0.1.3?

А что если первые 15 команд мне нужна только изоляция, а не слои?

RUN очень && длинная && строка && с командами.

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

Если тебе нужны какие-то системные библиотеки м утилиты, ты же их через yum/apt/whatever ставишь, а не gentoo style из исходников. Также и с основным аппом должно быть: собирается на билд сервере в артефакт, потом просто скачивается и разворачивается в контейнер при сборке.

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

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

Если сервер свой, можно подумать про кеш через volume mount.

Или, как предложила !alpha, запечь в контейнер (но это должен быть чисто сборочный контейнер, и не надо заменять нормальный ci скрипт докерфайлом).

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

Путь до registry зависит от инфраструктуры. Из-за того что для докера приходится его прописывать в явном виде, у тебя скрипты деплоя должны знать куда именно деплоят. Носить эту информацию через всю инфру очень дорого.

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

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

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

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

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

Это замечательно, но перспективы сэкономить 0.5% системных ресурсов не достаточно, чтобы менять базовые инструменты. По крайней мере в моём случае.

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

Нам твой случай очень интересен и важен. Продолжай писать о нем побольше.

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

То есть на хостах где отличная от systemd система инициализации podman вообще не будет работать ? Так как часть функционала docker, podman использует из systemd ?

Не так.

podman - это стандартный процесс. Без скрытых запросов к сторонним сервисам и т.п. Он не использует systemd для запуска контейнера, но, как любой простой процесс легко встраивается в любую стандартную систему управления процессами. То есть благодаря тому что podman не лезет в оркестрацию, повышение привилегий и т.п., а просто запускает контейнер, он совместим с любой готовой оркестрацией, хоть от systemd, хоть от openrc, хоть от openmpi.

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

Путь до registry зависит от инфраструктуры.

Дал Господь частный реестр образов, даст и VPN до него. Безотносительно деталей реализации на машине, где вы делаете pull image должна быть сетевая связность с реестром. Собственно, вы либо явно задаёте имя как registry/image, либо используете неявный реестр по умолчанию, который всё равно должен быть как-то прописан на хосте. Что, в принципе не так уж и плохо, но на «Путь до registry» никак не влияет.

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

Да я уже поняла что ты любитель богом данных костылей.

Разумеется это проблему можно решить, разными способами. Я её тоже решила в своё время. Но это никак не меняет того факта что хардкод докер-хаба в коде и отказ от приёма патча, который это чинит - это чисто маркетинговое решение компании Docker, позорное с технической зрения.

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

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

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

Давайте не будем про маркетинг. Мне это не интересно, да и вам наверное то же. Я говорю о простой вещи: мы можем задавать частный реестр в имени образа, а можем иметь параметр в конфиге с именем реестра по умолчанию. Второй способ выглядит несколько красивее, но с точки зрения сетевой инфраструктуры они абсолютно одинаковы.

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

Половина осталась работать. Половина просто зафризилась и потеряла сеть.

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

с точки зрения сетевой инфраструктуры они абсолютно одинаковы

Нет. Для того чтобы они стали одинаковы с точки зрения инфраструктуры, инфраструктура должна быть соответствующим образом настроена. То есть мы уже ломаем separation of concerns и требуем перенастройки базовой инфры (сетевой) для работы деплой-скриптов приложения (которые от железа и топологии сети должны давно быть абстрагированы).

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

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

До появления podman в Fedora, CentOS и RHEL этот патч накладывали на docker при сборке rpm-ки. Потому что в отличие от тебя, «суровый энтерпрайз» не любит костылить обходные пути в настройках сети без реальной необходимости.

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

Ага, и оно еле-еле вышло из беты (или ещё не вышло)?

Ну и containerd это всё равно кусок докера.

intelfx ★★★★★ ()

А что есть почитать про Podman?

Как я понимаю, в RHEL 8 и CentOS 8 для того что получить, например, GCC или Clang/LLVM новой версии, лучше использовать именно Podman, а не сторонние (хоть и официальные) репозитории вроде SCL, EPEL и пр. Так ли это?

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

Людям там может быть удобно работать. Не любой рабочий процесс можно запихнуть в jenkins.

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

Для того чтобы они стали одинаковы с точки зрения инфраструктуры, инфраструктура должна быть соответствующим образом настроена

Не понимаю. Есть два варианта:

  1. docker pull example.com/image:tag — после чего нам нужно разрешить example.com в ip адрес, найти маршрут до того адреса, установить соединение и т.д.

  2. podman pull image:tag — после чего нужно взять из конфига имя реестра example.com, разрешить example.com в ip адрес, найти маршрут до того адреса, установить соединение и т.д.

Я не вижу тут больших различий с точки зрения инфраструктуры.

в Fedora, CentOS и RHEL этот патч накладывали на docker при сборке rpm-ки.

NIH синдром красношляпы меня абсолютно не удивляет.

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

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

Не любой рабочий процесс можно запихнуть в jenkins.

Опишите мне ваш рабочий процесс. Интересно же.

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

можно подумать про кеш через volume mount.

Хм, наверное это оно.

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

Есть два варианта:

apt install kernel

apt install www.debian.org/kernel (надеюсь, аналогия понятна).

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