Podman — один из множества инструментов для контейнеризации. Но в отличие от Docker, используется он не часто, даже в тестировании или хотя бы pet-проектах. 

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

Но Podman, будучи на 4 года младше Docker, а также, в теории, фундаментально безопаснее, подобного приёма не получил. Быть может, он его всё-таки заслуживает?
Возможно, к ужасу ваших DevOps и SRE-инженеров, вам стоит уже сейчас бежать и громить выстроенные пайплайны оркестрации кластеров Docker-контейнеров, чтобы менять всё на Podman?!

Не повторяйте в домашних условиях

Привет Хабр, с вами снова Матвей Мочалов из cdnnow!, и, как можно догадаться из лида, я бы хотел продолжить тему контейнеризации, начавшейся со статьи — Docker — не то, чем кажется. 

Маленький дисклеймер к лиду:

Возможно, к ужасу ваших DevOps и SRE-инженеров, вам стоит уже сейчас бежать громить выстроенные пайплайны оркестрации кластеров Docker-контейнеров?

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

На этом дисклеймер закончен.

Podman, the voyage to the corner of the globe

…Is a real trip. Пожалуй, идеальное звуковое сопровождение для тематики контейнеров, так привязавшейся к морской стилистике.

Как мы уже выяснили, за множеством «магических» слов про контейнеризацию и Docker (где полёт фантазии доходит до того, что контейнеры — это как виртуальные машины и даже круче) — кроется суровая реальность в виде базового функционала UNIX-подобных систем, появившегося ещё аж в конце 70-х.

А что же у нас такое Podman? Первый коммит в репозитории проекта был сделан ещё 1 ноября 2017 года, а версия 1.0 только 16 января 2019 года (Docker к тому моменту отметил шестилетие). Наверное, в этом новом, свежем инструменте для контейнеризации какой-то другой рантайм вместо runс, возможно, написан на Rust, он сам себя деплоит на сервер, заваривает кофе, переписывает за вас .yaml конфиги и вместо вас выходит на созвоны с коллегами? 

В рантайме под капотом Podman использует runc. Потом, в 2020 добавился crun (да, очень оригинально) вместо Go, написанный Ред Хатовцами на C. Но в целом же, основа осталась на Go, никаким Rust тут и не пахнет. На созвоны его тоже, увы, не пошлёшь.

Ну и зачем же он тогда нужен?

Как и у любой внезапно появившейся разработки от крупной корпорации, в этом случае Red Hat, ответ на реальную первопричину начала проекта и вопрос {Зачем?} — всегда один:

Если кто-то думает, что я преувеличиваю, то почитайте самих же  Red Hat, у которых основная аргументация — потому что можем и хотим. Гугл V8 сделала зачем-то, значит и мы можем контейнерами командовать. Чтобы все знали, где контейнеры — там это лицо с красной федорой.

Если же переходить от первопричин к тому, чем конкретно оправдывали жизнеспособность этой затеи — это в первую очередь легковесность и простота проекта. Docker относительно Podman представляет из себя махину размером с кита не только на логотипе, но и по сути. Ведь он несёт в себе целую экосистему, необходимую не только для создания и запуска контейнеров, но и для их оркестрации — Docker Swarm, который некоторые зачем-то используют вместо Kubernetes и OpenShift.
Podman же изначально разрабатывался так, что он будет использоваться в комбинации с  k8s и OpenShift. 

Правда, по иронии, остальная индустрия окромя Red Hat про это оказалась не в курсе и по сей день продолжила использовать Docker в связке с k8s и OpenShift. Это при том, что в RHEL 8, вышедшей ещё в 2019, Podman сменил Docker, а в k8s от поддержки Docker отказались ещё в 2020.

Стоп, отказались от Docker?

Но… каким же образом тогда все продолжают его и дальше использовать с k8s и OpenShift?
Во-первых, Podman, который должен был прийти на замену Docker в деле создания и тестирования контейнеров, которые уже дальше скармливаются инструментам их оркестрирования — почти полностью совместим с Docker, начиная от синтаксиса консольных команд и заканчивая непосредственно контейнерами, которые зачастую из коробки запускаются без дополнительных изменений в них.

Во-вторых, прекращение поддержки коснулось только рантайма — модуля, который непосредственно запускает контейнеры в работу, в его роли выступает CRI-O. И нет, он не заменил рантаймы runc и crun. Опустим лингвистические злоключения термина рантайм с его применением, но runc и его собрат crun — это более низкоуровневые рантаймы, которые используются рантаймами и контейнерными движками по типу CRI-O и ему подобными.

Но отчего же всё-таки то одно, то другое называют то tool, то runtime, то engine, как на картинке ниже? Потому что. Просто, потому что.

Почему Docker победил?

Для начала, не смотря на любовь мира IT сломя голову бежать использовать всё новое, а также по чистой случайности накачивать стоимость акций новинки (точно-точно не по стратегии pump- and-dump, не привлекая внимания санитаров регулирующих органов) рынок — есть рынок. IT или не IT, а преимущество первопроходца (FMA) есть везде.
COBOL, до сих пор живущий в фундаменте мировой банковской системы ещё с начала 60х годов прошлого века — передаёт привет в напоминание об этом.

Да, концептуально Docker не был первым решением, но он был первым инструментом, что объединил в себе целую экосистему для контейнеризации под одной оберткой. Удобной, как для отдельно взятого разработчика, так и для интернациональной мегакорпорации зла добра, у которой один дата-центр может потреблять электричества и воды, как небольшое африканское государство. И вот, с появления Docker в 2013 до первого релиза Podman v0.3.5, прошло уже 5 лет, а к 1.0 в 2019, аж 6.

И в который раз сделаю акцент на том, что Docker — это экосистема. Экосистема сервисов построенных вокруг него, экосистема сборки и деплоя, экосистема множества образов на все случаи жизни, которые пусть в большинстве своём и будут совместимы с Podman, но зачем заморачиваться, если и так работает? Да, кодовая база у него побольше из-за того, что к проекту привинчен Docker Swarm для оркестрации контейнерами, но это проблема по большей части разработчиков Docker, а не их конечных пользователей. Которые под Windows, MacOS и FreeBSD готовы мириться даже с тем, что он запускается в виртуалке. А как мы выяснили в прошлом посте, в MacOS на ARM устройствах до недавнего времени запускался в виртуалке внутри виртуалки.

К тому же, Podman, банально не предлагает ничего радикально нового относительно Docker.. Чем-то “модным”, как тот же Rust, или выходящие из его тени Zig c Nim, он тоже не щеголяет. Разве что с FreeBSD отношения у него получше, только вот у сообщества Фряхи, со всем, что называется контейнеры, а не «jail» - отношения не очень.

Эээксперименты

Попробуем запустить для примера Docker-контейнер с помощью Podman, для этого нам потребуется совершение следующих, чрезвычайно сложных и опасных для жизни действий:

```bash
podman pull docker.io/library/hello-world
podman run --rm docker.io/library/hello-world
```

Как можно заметить на практике, синтаксис Docker и Podman практически идентичен.

И да, зачастую больше ничего не требуется, чтобы запустить Docker-образ в Podman. Просто скачать и никаких дополнительных телодвижений. И да, я знаю, что за пределами «Hello World», в крупном проекте может и возникнет множество проблем и «сюрпризов», но они неизбежны и в рамках использования Docker-контейнеров с самим же Docker.

И кажется что-то мы упускаем, ах да, безопасность! Podman позиционируется как более безопасный, потому что у него нет собственного демона для его запуска и поддержания работы. А ещё по умолчанию ему не требуются рут-права. Но как же тогда он запускается, сам себе демон, что-ли? Нет, просто, в отличие от Docker, Podman использует не демона, а ДЕМОНЮГУ, на миллион+ строк кода, имя которому Сот… SystemD.

И который имеет рут-права по умолчанию, ещё и как PID1 процесс, но зато это тоже разработка Red Hat! А поэтому, мы будем это решение гордо называть rootless!

Кроме того, отсутствие необходимости в рут-правах обусловлено использованием пространств имён. За этим мистическим шаманским словосочетанием из мира Линуксоидов кроется такая же простая концепция, как у chroot и pivot-root. Но вместо того, чтобы сделать абстракцию и внутри файловой системы хоста создать ещё одну, изолированную корневую папку, пространства имён заходят ещё дальше. Они создают также своё древо процессов, позволяют отдельно регулировать выделяемую для запускаемых из-под них процессов память, нагрузку на процессор, сеть и т.д.
В общем, чтобы запустить контейнер, Podman для начала сам запускается в контейнере пространств имён, который если говорить ещё проще, представляет из себя создание временной папки, только в рамках которой у него есть свои собственные рут-права.

Правда, фишка эта уже давно не уникальна, и в 2020 с версии 20.10 Docker также получил возможность запускаться в rootless режиме. И да, точно так же через использование пространств имён.

Из хорошего можно отметить, что Podman, на удивление, неплохо себя чувствует под FreeBSD, в то время как Docker для FreeBSD в нативном-виде скорее мёртв, чем жив. Подтверждением этому являются безуспешные попытки несчастных экспериментаторов запустить на нём что-то актуальное, а также рассылка внутри проекта Фряхи где, как оказывается, на 2023 год команды двух проектов даже не контактировали друг с другом.

Выводы

Docker, несмотря на все старания Red Hat как был, так и остаётся предпочтением большинства пользователей инструментов контейнеризации. Куда чаще можно встретить любителей поедать кактус Docker Swarm, чем тех, кто хотя бы в домашних условиях использует Podman. 
Мы, в cdnnow! — не исключение из этого правила, работа с контейнерами у нас ведётся с помощью привычного всем Docker, а дальше они уже бороздят просторы интернета под управлением k8s. Да и честно говоря, из всего моего опыта общения с коллегами, я ещё не встречал тех, кто бы использовал Podman, хотя я старался и спрашивал напрямую при первой же возможности.
Если такие есть — отзовитесь, пожалуйста, в комментариях. Дайте знак, что вы реальны. А также вопрос к тем, кто использует Docker Swarm вместо k8s и OpenShift — зачем?