LINUX.ORG.RU
решено ФорумAdmin

podman/buildah vs docker

 ,


2

4

Я правильно понимаю, что buildah+podman можно использовать как эквивалентную (drop-in) замену последнему докеру, работающую с cgroups v2?

Несколько вопросов:

  • buildah умеет полноценно интерпретировать Dockerfile?
  • podman умеет в лимиты (ну, то есть, пользоваться цгруппами по назначению)?
  • оно всё вместе умеет работать (push+pull) с обычными докеровскими реестрами (в т. ч. с аутентификацией)?
  • есть ли какой-то эквивалент docker-compose для локальной отладки, или всем в куб?

sudo cast @alpha

★★★★★

buildah умеет полноценно интерпретировать Dockerfile?

Да, умеет multistage, но не умеет многие фишки из BuildKit

podman умеет в лимиты (ну, то есть, пользоваться цгруппами по назначению)?

Да, но не в rootless режиме - нужно ждать полноценной поддержки cgroupsv2

оно всё вместе умеет работать (push+pull) с обычными докеровскими реестрами (в т. ч. с аутентификацией)?

Да

есть ли какой-то эквивалент docker-compose для локальной отладки, или всем в куб?

https://developers.redhat.com/blog/2019/01/29/podman-kubernetes-yaml/

vrutkovs ★★ ()

есть ли какой-то эквивалент docker-compose для локальной отладки, или всем в куб?

Думаю вот это ещё в тему:

https://developers.redhat.com/blog/2019/01/15/podman-managing-containers-pods/

То есть podman умеет работать не только с отдельными контейнерами, но и с группой контейнеров объединённых общей сетью и т.п. Такой локальный вариант pod-а из kubernetes.

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

не умеет многие фишки из BuildKit

Ну я в BuildKit ещё и не тыкал толком. В любом случае, когда ждать?

нужно ждать полноценной поддержки cgroupsv2

А хоть какая-то поддержка cgroups v2 там есть?

https://developers.redhat.com/blog/2019/01/29/podman-kubernetes-yaml/

Понятно. Всем в куб. :)

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

intelfx ★★★★★ ()

Есть некий podman-compose, там скрипт парсит композ фаил и создает поды или группу подов в зависимости от флагов. Лично мне нравится подман но в рутлесс режиме он дико грузит диск, если бы не это то просто сказка.

Novell-ch ★★★★★ ()
Ответ на: комментарий от WitcherGeralt

У нас билдеры контейнеров когда я их перевел на подман стали показывать максимальный LA, они юзают glustefs как свой волюм. Да и локально у себя на ssd подман рутовый быстрее докера но рутлесс на 40-50% дольше собирает образ чем докер. Если судить по тому что тут написано, но это или из-за vfs или из-за fuse-overlayfs. https://opensource.com/article/19/2/how-does-rootless-podman-work

И еще образы а рутлесс просто нереально много занимают на диске.

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

И еще образы а рутлесс просто нереально много занимают на диске.

Ну это совсем из области фантастики. Явно root или не root тут ни при чем. Надо смотреть в чём реальная разница.

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

В любом случае, когда ждать?

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

А хоть какая-то поддержка cgroups v2 там есть?

Есть, и даже лимиты в rootless - только сейчас в Fedora 31 оно всё основательно поломано, так что пока толком не могу проверить что поддерживается

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

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

Например?

Сейчас везде докер. Ценность podman (по крайней мере я так это вижу) как раз в том, что его можно использовать как более-менее эквивалентную замену докеру — с существующими докерфайлами, репозиториями, скриптами, подходами и т. п.

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

Есть, и даже лимиты в rootless

Кстати, про rootless. Что там с драйверами хранения? Я так понимаю, что оверлей не-руту нельзя — а как тогда вообще этим пользоваться? У меня-то btrfs и я просто включил соответствующий драйвер на субволюмах (кстати, удивлён, что его вообще портанули из докера, учитывая нелюбовь RH к btrfs), а в общем случае как с этим жить?

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

@Novell-ch

@WitcherGeralt

И еще образы а рутлесс просто нереально много занимают на диске.

Ну это совсем из области фантастики. Явно root или не root тут ни при чем. Надо смотреть в чём реальная разница.

Нет, он прав. Там для rootless по дефолту используется «тупой» драйвер хранения vfs, который на каждый слой делает полную копию. Собственно это меня и беспокоит, а пользоваться-то этим как?

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

Там для rootless по дефолту используется «тупой» драйвер хранения vfs

Где именно - там?

$ cat ~/.config/containers/storage.conf 
[storage]
  driver = "overlay"
  runroot = "/run/user/1000"
  [storage.options]
    size = ""
    remap-uids = ""
    remap-gids = ""
    ignore_chown_errors = ""
    remap-user = ""
    remap-group = ""
    ostree_repo = ""
    skip_mount_home = ""
    mount_program = "/usr/bin/fuse-overlayfs"
    mountopt = ""
    [storage.options.thinpool]
      autoextend_percent = ""
      autoextend_threshold = ""
      basesize = ""
      blocksize = ""
      directlvm_device = ""
      directlvm_device_force = ""
      fs = ""
      log_level = ""
      min_free_space = ""
      mkfsarg = ""
      mountopt = ""
      use_deferred_deletion = ""
      use_deferred_removal = ""
      xfs_nospace_max_retries = ""

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

Где именно - там?

Тут. :)

$ rm -rf ~/.config/containers ~/.local/share/containers

$ podman pull busybox
Trying to pull docker.io/library/busybox...
Getting image source signatures
Copying blob 7c9d20b9b6cd done
Copying config 19485c79a9 done
Writing manifest to image destination
Storing signatures
19485c79a9bbdca205fce4f791efeaa2a103e23431434696cc54fdd939e9198d

$ cat ~/.config/containers/storage.conf
[storage]
  driver = "vfs"
  runroot = "/run/user/1000"
  graphroot = "/home/intelfx/.local/share/containers/storage"
  [storage.options]
    size = ""
    remap-uids = ""
    remap-gids = ""
    ignore_chown_errors = ""
    remap-user = ""
    remap-group = ""
    ostree_repo = ""
    skip_mount_home = ""
    mount_program = ""
    mountopt = ""
    [storage.options.thinpool]
      autoextend_percent = ""
      autoextend_threshold = ""
      basesize = ""
      blocksize = ""
      directlvm_device = ""
      directlvm_device_force = ""
      fs = ""
      log_level = ""
      min_free_space = ""
      mkfsarg = ""
      mountopt = ""
      use_deferred_deletion = ""
      use_deferred_removal = ""
      xfs_nospace_max_retries = ""

А у тебя оверлей работает от пользователя? Как?

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

Ну вот о том и речь, что надо сравнивать не root vs rootless, а конкретные настройки в конфиге storage.

У меня Fedora 30, podman-1.5.1-3.fc30.x86_64 и по умолчанию под пользователем overlay. Ровно так же как и в /etc/containers/storage.conf

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

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

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

Ну вот о том и речь, что надо сравнивать не root vs rootless, а конкретные настройки в конфиге storage.

Я говорил о том, что при rootless плохой дефолт и мне не очень понятно, как его можно улучшить. Из вариантов хранилища для rootless я вижу только «тупой» vfs и ФС-специфичный btrfs. Драйвер overlay у меня от пользователя не работает, ну оно и понятно — overlayfs смонтировать от пользователя нельзя.

А вот как у тебя он работает от пользователя (да ещё и дефолтом), я вообще нифига не понимаю.

я все равно не поняла связь между драйверами fs и размером образов

Так речь-то не о размере образа как такового (в виде тарболла), а о размере на диске после распаковки.

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

Драйвер overlay у меня от пользователя не работает, ну оно и понятно — overlayfs смонтировать от пользователя нельзя.

Там какая-то магия с user namespace

И если мы говорим о сборке образа из докер-файла или о запуске контейнеров то всё работает. А если речь о buildah mount, то нужно дополнительно использовать buildah unshare

https://github.com/containers/buildah/blob/master/docs/buildah-unshare.md

Так речь-то не о размере образа, а о размере на диске после распаковки.

Ну может это у тебя речь об этом, а Novell-ch писал про размер образов. Что и показалось мне странным

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

Там какая-то магия с user namespace

И если мы говорим о сборке образа из докер-файла или о запуске контейнеров то всё работает

Блин, а можно подробнее? Чёт у меня совсем не работает и не гуглится. Нагуглился только костыль fuse-overlay.

а Novell-ch писал про размер образов

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

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

Блин, а можно подробнее? Чёт у меня совсем не работает и не гуглится. Нагуглился только костыль fuse-overlay.

Ну как бы

Overlayfs is not supported in rootless mode UNLESS fuse-overlay is configured as the mount-program.

https://github.com/containers/buildah/issues/1304#issuecomment-458507340

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

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

Можно клепать имаджи, которые запустит докер, без самого докера и докерфайлов - я про это небольшую [статью](https://vrutkovs.eu/posts/source2image/) делал

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

я про это небольшую статью делал

Многие могут показаться черезчур усложненными (а некоторые - черезчур упрощенными), но фактически Dockerfiles до сих пор остаются неформализированным стандартом

Блин, я тебе о том и говорю, что ценность докера (так себе ценность, конечно, но всё же) не в том, что он докер, а в сложившейся вокруг него экосистеме целиком, включая и образы, и реестры, и докерфайлы и всё такое. И мой вопрос был именно о том, как с podman/buildah влезть в существующую экосистему.

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

И мой вопрос был именно о том, как с podman/buildah влезть в существующую экосистему.

Оно создано, чтобы _вылезти_ из экосистемы Docker и влезть в экосистему RedHat, ну.

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

Да, но не в rootless режиме - нужно ждать полноценной поддержки cgroupsv2

Тем временем с удивлением обнаружил, что из коробки оно вообще в rootless + cgroups2 не умеет. А всё потому что podman podman’ом, понты и всё такое, а ядро у него по умолчанию всё равно от докера: runc. Надо поменять runc на crun O_o. Кто вообще эти названия придумывает?

https://github.com/opencontainers/runc
vs
https://github.com/containers/crun

Найдите десять отличий.

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

С удивлением обнаружил также, что

FYI systemd-nspawn actually implements the OCI spec since the latest release

(src), но при этом не является эквивалентной заменой для runc или crun, печаль-беда. Зато

Fedora 31 is switching to cgroupv2 entirely (and will start using crun as a result – because it supports cgroupv2). I guess now it’s do or die (work is being done in #2114).

(src), наконец-то они зашевелились, слава федоре, редхату слава.

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

Найдите десять отличий.

golang vs. c (как результат стало быстрее запускаться)

сообщество с требованием поддержки старых дистров и k8s vs. домашний проект Джузеппе

После десятка фиксов всего стека умвр в F31. Правда, старые runc контейнеры, понятно, crun запускать не умеет, заодно и перебилдил их

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