Docker - довольно известный инструмент контейнеризации и управления, собственно, контейнерами. В своей нише ему альтернативу найти крайне сложно. В чём же его сильные стороны?
-- Это сложный, но вместе с тем довольно интересный бэкэнд-хранилище. Слоёная фс на основе overlayfs. Как альтернатива - можно использовать btrfs, но в виду особенностей btrfs этот бэкэнд не рекомендуют к продакшен-применению.
-- Централизованное хранение образов ОС на сервере-registry. Причём такой сервер может быть как приватный так и публичный, и даже входить в различные готовые решения как опция - такое есть в gitlab, bitbucket и многих других on-permise сервисах совместной разработки.
-- Создание своих образов поверх уже готовых.
-- Менеджер сетей для контейнеров.
-- Собственно, менеджер контейнеров.
-- Зачаток системы оркестрации - docker swarm. То есть системы управления группами контейнеров, которые из себя представляют инстанс некоего сервиса.
Если у нас в руках есть такой классный инструмент, то почему на сцене появились альтернативы? А всё очень просто - в мире нет ничего идеального и docker тоже обладает своими слабостями:
-- Неясная стратегия развития, в связи с чем изменения в api, ломающие совместимость.
-- Нестаблильная работа прошлых выпусков.
-- Текущие перспективы развития и монетизации проекта не внушают уверенности в долгом и счастливом будущем проекта, несмотря на его популярность.
По этим и некоторым другим причинам на свет появился Podman, который позиционируется как docker replacement, совместимый с ним по синтаксису команд. Разрабатывает Podman команда Red Hat. Вроде как серьёзный вендор.
Одной из особенностей реализации механизма управления контейнерами в docker является наличие основного демона управления - dockerd, у которого есть как локально доступный интерфейс, через Unix Domain Socket, так и сетевой интерфейс, который как правило работает по tcp на порту 2376.
В отличие от docker-а у podman-а такого механизма нет. И, пожалуй, это ключевой момент. Таким образом, если docker работает как сервис и локальные пользователи могут до него достучаться через специальный клиент либо по сети, либо через сокет, в последнем случае им надо входить в ту же группу, которая владеет этим самым сокетом, то podman работает исключительно от пользователя, либо от рута.
Из положительных моментов:
-- Podman обладает синтаксисом команд, почти полностью повторяющим таковые в docker-е.
-- Storage-бэкэнд, работающий с registry умеет то же, что и docker как на pull так и на push, docker-образа идеально работают с podman-ом.
Зато есть масса минусов - работа podman-а от пользователя затрудняет практически всё:
-- это умолчальное место хранение образов - ~/.local/share/containers/storage
-- это управление сетью - юзер не может создать классические интерфейсы - macvlan, veth, bridge и проч.
-- юзер не может добавлять, менять, удалять правила в файрволл
-- юзеру нужен маппинг его группы id-шников для использования в качестве внутриконтейнерных юзеров и групп
Можно, конечно, работать и от обычного root-а, но злые языки говорят, что это небезопасно, поэтому в современном it стараются этой практики избегать. Что, впрочем, не мешает dockerd работать от root-а.
Но это всё лирика. Хотелось бы знать, что у нас с практикой? А с практикой всё обстоит довольно плачевно.
Собственно, одной из целей podman-а было избавление от различных лишних (по их мнению) демонов - dockerd и containerd, который супервайзит котейнер и является чем-то вроде systemd для отдельно взятого контейнера - готовит для него namespace, сетевые устройства, складывает из слоёв roofs, настраивает environment variables, подключает тома и запускает runc.
Иными словами podman выполняет роль docker+containerd.
Собственно, что я сделал? Да просто Dockerfile с полной установкой всех пакетов для создания full-инсталляции slackware из образа vbatts/slackware:14.2 в результате из 93-мегабайтного минимального образа мы должны по идее получить 8.93Гб образ slackware linux 14.2. во всяком случае так говорит docker и образ у докера действительно занимает порядка 9 гигов.
Итак, запускаем podman build на этот dockerfile и в итоге получаем ~53Гб занятого места. На этом моменте я не поверил своим глазам, но факт есть факт - 53Гб слоёв. И это при условии запуска от root-а, когда у podman-а есть все возможности по работе с overlayfs.
Акей, какие ещё непрятные моменты я обнаружил? - podman в процессе построения образа использует каталог /var/tmp, но с этим жить кое-как можно, а вот для текущего слоя он уже использует директорию /run, которая, как правило, смонтирована как tmpfs и не подразумевает особо большого количества добра в ней. И такое поведение для меня оказалось внезапным.
Далее, userspace сеть работает в принципе приемлемо, для тачки разработчика, но, подозреваю, что для produсtion-приложений её может нехватить.
Как работают pod-ы я не проверял, так как в моём случае они не нужны.
Ну и конечно, когда перепахивается такое количество данных притормаживает даже nvme-ssd, повешенный на pci-express. Вобщем, меня такое положение вещей не впечатлило, а непомерный жор драгоценного места на диске так и вообще расстроил.
Подводя итоги всему вышесказанному, Podman пока рановато заявлять как полноценную замену docker-у. Эксплуатация podman-а, настройка окружения под него и его ресурсоёмкость как приложения пока что ставят его в более проигрышное положение относительно docker-а.
N.B. Эта заметка не претендует на истину в последней инстанции, так как оне оперирует точными данными и выражает мнение автора на момент написания статьи.