Комментарии 49
Поскольку Podman может запускаться без root-прав, ему требуется отдельное место для записи образов. Поэтому репозиторий Podman расположен в домашнем каталоге пользователя ~/.local/share/containers.
На 7.7 (Maipo) podman (podman-0.12.1.2-2.git9551f6b.el7.x86_64) не хочет менять GraphRoot для non root пользователя с ~.local/share/containers/storage на что-то другое, если менять storage.conf и libpod.conf. Это как-то лечится?
Podman предлагает целый ряд дополнительных – по сравнению с Docker – функций
А подробнее? Есть ли хоть одна веская причина сменить докер на подман? Я не увидел
Ну справедливости ради в первой статье тоже дурацкие причины.
"Увидеть альтернативы", "разобраться в контейнерах" и "подготовиться к будущему" это причины поковырять технологию в свободное время, а не переходить в продакшене.
Непонятно почему они не приводят как причину увеличение безопасности — контр-меру от выхода из контейнера и получение рута на хосте, т.к. демон под рутом.
Rootless режим. Полезен в hpc-кластерах, чтобы пользователи могли использовать контейнеры для воспроизведения результатов вычислительных экспериментов. Правда, чтобы добавить поддержку MPI пришлось написать скрипт https://github.com/alexbers/mpiexec-docker.
Думаю, RedHat в будущем будет вставлять палки в колёса Докеру ещё сильнее и будет насильно проталкивать podman.
А насколько обычно отстают они в плане синтаксиса Dockerfile? Поддерживается ли экспериментальный синтаксис типа проброса ssh и монтирования кэшей? Чем отличается их scratch от стандартного 'FROM scratch'?
Как будто вышеперечисленный синтаксис сильно необходим. Здорово, что докер шагает вперёд. Но в принципе — все необходимое для работы с образами уже есть. Не хватает только зрелого тулинга, чтобы собирать контейнеры без докера.
Ну, прокидывание ssh-тоннеля в билдер бывает очень для установки зависимостей из приватного репозитория пакетов или git репозитория. Кєширование каталогов менеджера пакетов (хоть системных типа atp, хоть платформенных типа composer или npm) может кардинально уменьшить время билда.
Есть ответ простой — собирай докеры так, чтобы это было ненужно. Тот же гит можно скачать СНАРУЖИ докера, положить в каталог контекста, да и тупо секурнее это.
В общем — пускай кэшированием занимается не докер, причем непонятно как, а внешняя система сборки.
Вот как раз от внешней системы сборки хочется избавиться, чтобы тупо сделать
git clone repo app
docker build -t app
docker run appи чтобы это было эффективно
Это утопия. Идеалистичные мысли. Очень вредные.
Как минимум тем, что у тебя лок на системе сборке как докер. А если тебе нужно собирать попросту apk/deb/rpm или нативные бинари?
С другой стороны, инкапсуляция сборочного конвейера в отдельные докер-контейнеры — очень мощный механизм, но работает это так:
docker run \
-e USER=$(id -u) -e GROUP=$(id -g)\
--rm -v $PWD:/in -v $PWD/out:/out \
my_super_puper_compilerи в в текущем каталоге в подкаталоге /out получаешь артефакты сборки.
Которые при необходимости можно передать в следующий докер для мутации.
Мы так голанг собирали. Самая малость — что нужно побороть проблемы с правами на файлы
Т.е. еще раз переформулирую — использовать сборочный конвейер в виде мультистейдж докерфайла на этапе docker build разработчик отрубает себе обе руки — и потому что окончательным артефактом может быть ТОЛЬКО докер-контейнер, и потому что он лишает себя кучи плюшек (типа кэширования файлов в самом каталоге проекта).
Ну почему утопия, если работает? Вот если объявят эксперимент неудачным надо будет думать.
И особо не страшен лок на докере как билдере, если билдим артефакты для докера.
Ну и проблемы с правами внутри контейнеров мне лично встречались или по невнимательности, или по неверным предположениям о том, как права настроены в базовом образе. Из последнего на этой неделе как раз официальный golang образ, который без плясок не хотел качать пакеты под непривилегированным пользователем. Предыдущий раз — зимой.
Ну и проблемы с правами внутри контейнеров мне лично встречались или по невнимательности, или по неверным предположениям о том, как права настроены в базовом образе. Из последнего на этой неделе как раз официальный golang образ, который без плясок не хотел качать пакеты под непривилегированным пользователем. Предыдущий раз — зимой.
Ага, конечно. Речь скорее не про права ВНУТРИ контейнеры, хотя этот фактор тоже имеет место, а скорее то, что докер при прокидывании с хоста каталогов ставит им владельца root с идущими от этого последствиями. Это все можно пофиксить с кровью, но придется все используемые образы перепиливать и оборачивать запуск контейнеров в шелл-скрипты, которые делают все "как надо"
Вы сейчас описали практически как vagga работает — только без демонов и командной строки из 5 опций на пустом месте ;)
В этой статье пишут, что его нет
А компоуз и не нужен. Используйте… Ансибл.
Одного для одного другое для другого.
Вы ансиблом супервайзите сервисы в продакшене?
Погодите — что значит ансибл супервайзит?
Почему Вы думаете, что компоуз супервайзит? Если компоуз всего лишь обертка к докер-апи (т.е. убирает необходимость самому вводить docker volume create, docker run и пр.).
Если мы рассматриваем именно вопрос ЗАПУСКА и доставки контейнеров, то ансибл на голову выше компоуза. Я неоднократно писал почему так, но если нужно — могу повториться.
Я уж не говорю, что зачастую в проде докер не нужен....
github.com/containers/podman-compose
С т.з. adoption хорошо что они совместимы с докером. С другой стороны, в той же vagga есть супер-полезные вещи, которых в мейнстрим-контейнерах нет и видимо ещё долго не будет:
- Авто-версионирование и очистка старых образов/контейнеров. Заниматься этой уборкой в докере абсолютно осточертело.
- Прокидывание прокси с хоста — зачем в докере эти пляски с такой тривиальной вещью, абсолютно непонятно.
- В vagga сборка идёт серьёзно быстрее за счёт некоторых трюков, например libeatmydata.
- Командно-ориентированный процесс вместо контейнеро-ориентированного. Контейнеры стартуют за миллисекунды. В конфиге описываются команды, а контейнеры под них поднимаются/опускаются автоматически.
Думаю, именно на podman, если собираетесь остаться на RHEL-производных дистрибутивах. Например, у меня не получилось просто довести docker нас свежем RHEL8 из-за проблем с зависимостями и необходимостью настройки вручную сети для работы контейнеров.
podman — именно с точки зрения того, что это как докер, но лучше?
Коллеги в процессе обсуждения накидали кучу вариантов вроде systemd-nspawn, lxc… но назвать их полноценной заменой не могу.
С релизом Fedora 28 Atomic Host (май этого года) Podman стал инструментом этого Linux-дистрибутива по умолчанию для управления контейнерами.
habr.com/ru/company/flant/blog/426141
Сам не проверял как там в Атомике, но у подмена есть пакет совместимости с командами докера (как я понял, там набор алиасов), возможно, в Атомике используется именно это
А какой ценой решены эти проблемы? Не только ведь алиас прописать? Навскидку принципаильно нет возможности работать с удаленной машиной без костылей типа выполнения команд по ssh?
Основная «цена» отказа от демона — нельзя сериализировать пуллы, потому что нет демона который бы приоритезировал их. Остальное решается грамотной расстановкой локов
podman build -v /path/to/cache:/buildtime/cache -f Dockerfile .Если понимаешь, зачем тебе это, и как не выстрелить себе в ногу, то очень полезная функция, о которой Docker-комьюнити умоляет уже 5й год. В Docker, кстати, с некоторыми ограничениями похожее можно сделать, использую в качестве бэкенда сборки Buildkit.
Что касается Compose, вот вполне себе официальный репозиторий
На MacOs все еще нужно запускать демон подмана, и рут все также нужен
github.com/containers/libpod/blob/master/docs/tutorials/mac_client.md
Это не демон, а включение socket activation — http://0pointer.de/blog/projects/socket-activation.html
Podman и Buildah для пользователей Docker