====== Docker или Podman: что лучше подойдет для вашего проекта ======

==== Зачем нужны контейнеры ====

Контейнеры – это автономные программные пакеты, которые включают в себя код и все зависимости, необходимые для его работы: библиотеки, инструменты, настройки и среду выполнения. Контейнеры быстро стали стандартом, поскольку они:

  * Занимают меньше места и требуют меньше ресурсов, чем традиционные виртуальные машины.
  * Обеспечивают изолированное пространство, где приложение работает автономно, не влияя на другие программы и системы.
  * Позволяют быстро развертывать и масштабировать приложения.

==== Что такое Docker ====

**Docker **– де-факто стандарт контейнеризации: для большинства разработчиков «контейнер» ассоциируется исключительно с Docker. Docker быстро стал эдаким «швейцарским ножом» в нише создания и оркестровки контейнеров – обзавелся всеобъемлющей функциональностью еще до того, как на горизонте появились альтернативные решения. Сейчас экосистема Docker предлагает набор мощных инструментов, способных решать большинство задач, связанных с управлением контейнерами, например:

  * **Docker Compose**  – для определения и запуска многоконтейнерных приложений.
  * **Docker Swarm**  – для кластеризации и оркестрации контейнеров.
  * **Docker Network **– для создания и управления сетями контейнеров.
Однако недостатки у Docker тоже есть:

  * Без дополнительных манипуляций и системных настроек не обеспечивает должный уровень безопасности.
  * Не все приложения эффективно работают в Docker-контейнерах.
  * Накладные расходы **снижают производительность**. Если вы проходили курсы на платформе **Stepik**, то наверняка заметили, насколько долго там выполняется проверка решений – это потому, что при каждом запуске кода поднимается Docker-контейнер.
  * Интеграция других инструментов с Docker может быть сложной, особенно для начинающих разработчиков.
  * Возможностей Docker все-таки не хватает для оркестрации и мониторинга **масштабных ** приложений.

==== Что такое Podman ====

**Podman**  – инструмент для создания, запуска и управления контейнерами и подами (группами контейнеров). Принцип его работы очень похож на **Kubernetes ** (Podman разрабатывался с учетом всех особенностей K8s): этот факт и привлекает к нему внимание разработчиков, которым по каким-то причинам нужна надежная альтернатива **Docker**  (и более простой способ оркестрации контейнеров – с** **K8s или без).

Podman разработан компанией **Red Hat**  в соответствии со стандартами [[https://opencontainers.org/|Open Container Initiative (OCI)]], отличается дружелюбностью по отношению к начинающим пользователям, и входит в комплексный набор инструментов, который можно использовать, как модульную структуру:

  * **Podman**  – менеджер образов и подов контейнеров.
  * **Buildah**  – сборщик контейнеров.
  * **Skopeo**  – менеджер для проверки образов контейнеров.
  * **runc**  – обеспечивает базовую функциональность по созданию, запуску и управлению контейнерами для Podman и Buildah.
  * **crun **– опциональная среда выполнения, которая обеспечивает большую гибкость, контроль и безопасность для контейнеров без root-доступа (с ограниченными привилегиями).
Все эти инструменты могут работать с любым другим OCI-совместимым движком, включая Docker: это сильно упрощает переход с Docker на Podman или их совместное использование. И, разумеется, контейнеры Podman можно использовать с Kubernetes – фактически, между этими платформами много общего: как видно из названия, Podman может создавать группы (поды) контейнеров, которые работают вместе точно так же, как поды в Kubernetes.

**Главное преимущество **Podman в том, что он дает возможность использовать разные контейнеры для одного приложения внутри пода: один, например, для фронтенда, другой для бэкенда и базы данных. Эти контейнеры автоматически совместно планируются, совместно размещаются и совместно используют ресурсы (сеть, хранилище и т.п.) Кроме того, определения подов из Podman можно экспортировать в YAML-файл для быстрого разворачивания приложения в кластере Kubernetes.

Еще одна **отличительная черта Podman**  – это отсутствие демона (программы, работающей в фоновом режиме для обработки сервисов, процессов и запросов без пользовательского интерфейса). Это уникальный подход для контейнерного движка: Podman запускает контейнеры и поды как дочерние процессы.

Эти и другие преимуществ, которые мы рассмотрим ниже, делают Podman жизнеспособной и интересной альтернативой Docker в соответствующем контексте. Или мощным дополнением для совместной работы – как уже упоминалось, Podman поддерживает CLI-интерфейс, совместимый с Docker.

==== Podman vs Docker: основные различия ====

Поскольку Podman и Docker предназначены для решения одних и тех же задач, между ними много общего. Но есть и несколько принципиальных различий. Это не делает один из них лучше другого, но может повлиять на выбор наиболее подходящего инструмента для конкретного проекта.

==== Архитектура ====

Docker использует клиент-серверную логику и демон (постоянно работающую фоновую программу) для создания образов и запуска контейнеров. В архитектуре Podman демон не используется, поэтому он может запускать контейнеры от имени пользователя. Для управления сервисами и поддержки запуска контейнеров Podman в фоновом режиме применяет [[https://ru.wikipedia.org/wiki/Systemd|systemd]], который создает контрольные юниты для существующих контейнеров или для генерации новых. Systemd также можно интегрировать с Podman, позволяя ему запускать контейнеры с systemd, включенным по умолчанию, без каких-либо модификаций.

{{https://media.proglib.io/posts/2024/06/20/2907d92e17bb5016f6b7c07197d1bed1.png?nolink&}}

Различия в архитектуре Podman и Docker
==== Привилегии root ====

Так как у Podman нет демона для управления активностью, он не предоставляет root-права для своих контейнеров по умолчанию. Docker недавно добавил режим rootless в конфигурацию демона, но Podman использовал этот подход первым и продвигал его как фундаментальную особенность. Эта особенность тесно связана со следующим пунктом.

==== Безопасность ====

Цель контейнеров – безопасно изолировать приложения от хост-системы, минимизируя проблемы совместимости и повышая безопасность. Одна из основных проблем безопасности – риск выхода из контейнера (container breakout), когда злоумышленник может скомпрометировать хост-систему. Для снижения таких рисков жизненно важно запускать контейнеры с минимальными привилегиями.

Podman по умолчанию предоставляет более строгие настройки безопасности по сравнению с Docker. Такие функции, как контейнеры без root привилегий, пользовательские пространства имен и профили seccomp, доступны в Docker, но не включены по умолчанию и часто требуют дополнительной настройки.

Настройки Podman по умолчанию включают запуск контейнеров без root привилегий в изолированных пользовательских пространствах имен, что ограничивает последствия потенциального выхода из контейнера. В противоположность этому, настройки Docker по умолчанию запускают процессы контейнера от имени пользователя root, что представляет более высокий риск в случае выхода из контейнера.

Кроме того, контейнеры Podman, привязанные к сеансам пользователей, позволяют системам аудита отслеживать вредоносную активность до конкретных пользователей, в отличие от Docker, где отслеживание до пользователя затруднено из-за системного демона.

Podman и Docker используют возможности ядра Linux и **профили seccomp ** для контроля разрешений процессов. По умолчанию Podman запускает контейнеры с более узким набором из 11 возможностей по сравнению с более рискованной настройкой Docker по умолчанию из 14 возможностей.

Хотя Docker тоже можно настроить для обеспечения максимальной безопасности, Podman обычно требует меньше усилий для достижения безопасной конфигурации.

==== Создание образов ====

Docker – самодостаточный инструмент: сам создает образы контейнеров. Podman специализируется на управлении контейнерами, а для создания образов использует уже упомянутый инструмент Buildah.

==== Docker Swarm и Docker Compose ====

**Docker Swarm**  позволяет создавать кластеры из нескольких хостов для развертывания и управления контейнеризированными приложениями. Swarm использует файлы **Docker Compose**  для определения и развертывания многоконтейнерных приложений в кластере. Изначально Podman не работал с Docker Swarm, однако недавно в него добавили поддержку Docker Compose, что позволило преодолеть это ограничение и сделало его совместимым со Swarm.

==== «Все в одном» против модульного подхода ====

Пожалуй, именно в этом заключается основное различие между двумя инструментами: Docker — это **монолитная**, мощная и независимая технология (со всеми сопутствующими преимуществами и недостатками), которая выполняет **все**  задачи контейнеризации на протяжении всего цикла. Podman использует **модульный**  подход, полагаясь на специализированные инструменты для конкретных задач.

==== Производительность ====

=== Использование ресурсов и время запуска контейнеров ===

Архитектура Podman дает ему небольшое преимущество в плане использования ресурсов: поскольку Podman не требует центрального демона, контейнеры Podman могут запускаться и останавливаться быстрее по сравнению с Docker. В тестах производительности, проведенных Red Hat, Podman демонстрировал более низкое потребление ЦП и оперативной памяти по сравнению с Docker для эквивалентных рабочих нагрузок. Время запуска также зависит от набора зависимостей в конкретном образе — некоторые контейнеры Podman запускает на 50% быстрее, чем Docker.

{{https://media.proglib.io/posts/2024/06/20/2353a7d417ed22b83a48b3d5e1f38759.png?nolink&}}

Red Hat Performance Benchmarks
=== Сетевая производительность ===

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

=== Обработка операций ввода-вывода ===

В тестах ввода-вывода, проведенных Red Hat, Podman показал лучшие результаты по скорости чтения и записи файлов внутри контейнеров по сравнению с Docker.

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

==== Экосистема ====

Развитая экосистема и сильная поддержка сообщества — критически важные факторы при выборе главного инструмента развертывания и масштабирования. Вот что могут предложить экосистемы Docker и Podman.

=== Docker ===

Экосистема Docker опережает Podman по масштабу и зрелости:

  * **Docker Hub ** служит стандартом для предварительно собранных образов контейнеров. В нем огромное количество репозиториев с миллионами образов для различных приложений, библиотек и фреймворков. Эта обширная библиотека позволяет разработчикам использовать существующие образы, экономя время и усилия.
  * **Официальные репозитории. ** Помимо Docker Hub, существует множество официальных репозиториев, ориентированных на конкретных поставщиков и дистрибутивы, предлагающих дополнительные образы.
  * **Сторонние инструменты**. Docker имеет процветающую экосистему сторонних инструментов, таких как Docker Compose, которые бесшовно интегрируются с платформой. Эти инструменты охватывают все аспекты разработки и развертывания — CI/CD, сканирование безопасности контейнеров и управление реестрами.
=== Podman ===

Количество легкодоступных предварительно собранных образов для Podman в настоящее время меньше по сравнению с Docker Hub. Но, хотя экосистема Podman далеко не такая обширная, как у Docker, она постепенно развивается:

  * **Увеличивается количество сторонних инструментов**. Появился ряд суперполезных решений, например Podman Desktop и [[https://github.com/containers/podman-compose|Podman Compose]] для управления многоконтейнерными приложениями.
  * **Появляются официальные репозитории. ** Аналогично Docker, существуют официальные репозитории для конкретных дистрибутивов, предлагающие совместимые с Podman образы.
  * **Есть возможность использовать Docker образы. ** Благодаря поддержке стандарта OCI, Podman может использовать большинство образов, изначально созданных для Docker. Однако стоит отметить, что некоторые образы Docker могут использовать функции, специфичные для Docker, которые не поддерживаются в Podman. В таких случаях может потребоваться небольшая корректировка образа.
Преимущество Docker в экосистеме и поддержке сообщества пока что значительно, и этот факт ощутимо влияет на принятие решения о выборе инструмента, но у Podman есть отличные шансы догнать лидера.

==== Подведем итоги ====

==== Может ли Podman заменить Docker? ====

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

==== В чем заключаются основные отличия Podman от Docker? ====

Podman в отличие от Docker не требует отдельного демона для запуска контейнеров, что делает его более легким и безопасным. Также у него лучше реализована поддержка запуска контейнеров пользователями без прав root, что повышает уровень безопасности. Кроме того, Podman может запускать поды Kubernetes напрямую, без использования дополнительного инструмента вроде Docker Compose.

==== В каких случаях стоит использовать Docker? ====

Docker станет идеальным выбором в ситуациях, когда необходимо учитывать эти аспекты:

  * **Устоявшиеся рабочие процессы.**  Если команда полагается на конкретные инструменты и сервисы, которые бесшовно интегрируются с Docker, он станет наиболее безопасным выбором: обширная экосистема Docker и зрелые инструменты минимизируют неожиданные сюрпризы и обеспечивают плавный опыт разработки.
  * **Широкий выбор предварительно собранных образов. ** Если проект нуждается в легкодоступных предварительно собранных образах из Docker Hub, Docker безусловно лидирует. Его огромная библиотека позволяет вам использовать существующие, хорошо протестированные образы, ускоряя разработку и развертывание.
  * **Сложные развертывания. ** Для развертываний, включающих множество взаимодействующих контейнеров, отлично подходит Docker Swarm. Эта платформа позволяет управлять и масштабировать такие сложные развертывания на кластере машин.
В этих сценариях Docker предлагает весомые преимущества и обеспечивает более плавный опыт разработки и развертывания, позволяя использовать хорошо зарекомендовавшие себя рабочие процессы и инструменты.

==== В каких случаях лучше использовать Podman? ====

Podman оптимален для этих сценариев:

  * **Акцент на безопасность.**  Для сред с повышенными требованиями к безопасности возможность Podman запускать контейнеры от имени непривилегированных пользователей делает его предпочтительным вариантом. Этот ориентированный на безопасность подход снижает площадь атаки и укрепляет общий уровень безопасности системы.
  * **Умеренные требования к ресурсам.**  Если эффективность использования ресурсов имеет первостепенное значение, рационализированный дизайн Podman делает его привлекательным выбором: благодаря своей архитектуре он использует меньше ресурсов и лучше подходит для сред с соответствующими ограничениями.
  * **Интеграция с systemd. ** Для сред, основанных на systemd, Podman предлагает значительное преимущество благодаря бесшовной интеграции. Это упрощает задачи управления контейнерами.
  * **Бесшовная интеграция с Kubernetes.**  Podman заимствовал некоторые ключевые концепции из Kubernetes (поды и пространства имен). Благодаря этому Podman может более естественным образом интегрироваться с Kubernetes. Например, можно запускать поды напрямую на узлах Kubernetes, не используя сам Kubernetes для оркестрации.
Выбор между Docker и Podman зависит от ваших конкретных требований и предпочтений. Docker предлагает надежную платформу с богатой экосистемой и широким распространением, что делает его отличным выбором для многих проектов. С другой стороны, Podman представляет собой легковесную альтернативу без демона, которая может быть более подходящей для определенных сценариев использования, особенно в средах Kubernetes.