Да. Не зря для примера приведён скриншот с реакцией одного из них. Но глобально, на мой вкус, речь скорее про достаточно небольшие проекты. Для больших актуальнее, конечно, решение issues, как уже отметили в первом комментарии.
Технически это сделать можно (вот, кстати, онлайн-сценарий от Katacoda для такого знакомства — добавил его заодно и в статью), но практический смысл… Разве что вам почему-то надоел запущенный в системе демон Docker или хочется интегрировать запуск контейнеров с системными сервисами (через systemd). Глобально же это скорее интересно тем, кто собирается запускать контейнеры в «таком же виде» в Kubernetes — тогда всё будет унифицировано.
Есть ссылка на сравнение производительности runc в разных реализациях (в т.ч. CRI-O и containerd, с которым уместнее сравнивать, чем просто Docker*), приводившееся в этой статье. Вот оно:
* Если сравнивать ещё с самим Docker, то налицо как минимум значимое архитектурное отличие (не нужен демон), поэтому корректнее всё же рассматривать Podman vs. containerd/crictl. Здесь есть функциональные отличия — информацию об этом добавил в текст статьи, спасибо!
В целом же основная задумка Podman заключается в том, чтобы предоставить пользователям Kubernetes, выбравшим CRI-O в качестве исполняемой среды для контейнеров, аналог консольного интерфейса Docker CLI
Далее — почему же тогда не Docker CLI, сказано здесь:
принципиальная разница в архитектуре: если Docker CLI для выполнения команд общается с демоном Docker, то Podman — самостоятельная утилита, не требующая никаких демонов для своей работы
> Для тех кому эти названия ни о чём не говорят, это выглядит как рандомный факт.
Признаюсь, эта статья ориентирована не на тех, для кого такие названия, как runc и CNI, ни о чём не говорят. Чтобы таким людям было проще, есть многократные ссылки на обзор CRI-O, где эта тема раскрыта. Дублировать её в данной статье не посчитал уместным, а к этому, как я вижу, и сводится всё основное непонимание и видимый недостаток раскрытия темы…
P.S. К вопросу о преимуществах и сравнениях: Podman по сути своего предназначения интереснее сравнивать с упомянутым в начале статьи cri-containerd от Docker Inc. И есть на эту тему взгляд со стороны Red Hat.
[..] this post will focus on how to ensure your business’s compliance and requirements are actually being adhered to and to ensure that we need to test our applied RBAC objects, to ensure they do what we intend them to do.
Основной ответ на этот вопрос на поверхности: сравните объём внимания к Linux и конкретно к RHEL… Потому что Kubernetes — это основа и как бы umbrella для всех появляющихся вендорских дистрибутивов. Поэтому всё общее внимание (включая мероприятия, статьи и т.п.) поддерживаются и Red Hat, и Google, и всеми другими вендорами (да ещё и сторонними энтузиастами-компаниями, которые за upstream). А вся движуха вокруг OpenShift может быть только от Red Hat (ну, и некоторых её партнёров — только не самых крупных, а таких, у которых ещё нет собственных дистрибутивов).
И дополнительный ответ уже больше с «личной» стороны: мы не любим vendor lock-in и клиентам такое предлагать по умолчанию не будем (хотя и можем взяться за обслуживание, если у них есть собственные основания делать именно и только так).
Во многом всё индивидуально, т.к. к нам регулярно приходят люди без опыта в Kubernetes, а уже внутри мы их «прокачиваем». Если мы ищем с каким-то конкретным навыком (например, Kubernetes), то реальный опыт важнее сертификатов. Но если такое требование не является обязательным, то и сертификат без опыта, конечно, тоже будет плюсом.
«Отсутствие технологий в моём продакшне» — да, это явный ключ. В нашем случае сдавали люди с реальным опытом работы с Kubernetes. Впрочем, и другой вариант у нас тоже приведен:
«В сети нам попался радикально другой пример специалиста, который купил курс подготовки к экзамену от The Linux Foundation и потратил на всё это около 4-5 недель».
P.S. Несмотря на всё, грань с NIH в таких случаях всё же довольно тонкая, поэтому иметь её в виду тоже стоит.
(его источник)
* Если сравнивать ещё с самим Docker, то налицо как минимум значимое архитектурное отличие (не нужен демон), поэтому корректнее всё же рассматривать Podman vs. containerd/crictl. Здесь есть функциональные отличия — информацию об этом добавил в текст статьи, спасибо!
Об этом написано здесь:
Далее — почему же тогда не Docker CLI, сказано здесь:
> Для тех кому эти названия ни о чём не говорят, это выглядит как рандомный факт.
Признаюсь, эта статья ориентирована не на тех, для кого такие названия, как runc и CNI, ни о чём не говорят. Чтобы таким людям было проще, есть многократные ссылки на обзор CRI-O, где эта тема раскрыта. Дублировать её в данной статье не посчитал уместным, а к этому, как я вижу, и сводится всё основное непонимание и видимый недостаток раскрытия темы…
P.S. К вопросу о преимуществах и сравнениях: Podman по сути своего предназначения интереснее сравнивать с упомянутым в начале статьи cri-containerd от Docker Inc. И есть на эту тему взгляд со стороны Red Hat.
Да просто опечатался же человек, продублировал саму команду и не заметил — нет смысла это копировать в переводе :)
(И в комментариях к той статье обозначенная проблема звучала, кстати.)
Так или иначе — вы уже поспособствовали, и у нас теперь есть ещё один повод. Спасибо, а вы там держитесь… хотя бы за соломинку! :-)
И дополнительный ответ уже больше с «личной» стороны: мы не любим vendor lock-in и клиентам такое предлагать по умолчанию не будем (хотя и можем взяться за обслуживание, если у них есть собственные основания делать именно и только так).