Подман против Докера

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

В этом посте мы рассмотрим различия между Docker и Podman и постараемся найти тот, который подойдет вам лучше всего!

Докер

Docker — это технология контейнеризации, которая упрощает управление зависимостями внутри проекта на всех уровнях (разработка и развертывание).

Механизм Docker, доступный в Linux, Windows и Mac OS, сосредоточен на контейнерах и их оркестрации, и в этом контейнеризация отличается от виртуализации.

Docker состоит из двух основных строительных блоков: Docker CLI и Docker Daemon.

Докер Демон:

Это постоянный фоновый процесс, который помогает управлять образами Docker, контейнерами, сетями и томами хранения. Docker использует свой REST API Docker Engine для взаимодействия с демоном Docker, доступ к которому осуществляется через протокол HTTP.

Докер-интерфейс командной строки:

Это клиент командной строки Docker для взаимодействия с демоном Docker. Это то, что вы используете при запуске любой команды Docker.

Работа Docker основана на ядре Linux и функциях этого ядра, таких как контрольные группы и пространства имен. Эти функции разделяют процессы, чтобы они могли работать независимо, поскольку цель контейнеров — запускать несколько процессов и приложений по отдельности.

Именно это позволяет оптимизировать использование инфраструктуры без снижения уровня безопасности по сравнению с отдельными системами.

Все контейнерные инструменты, такие как Docker, поставляются с моделью развертывания на основе образа. Эта модель упрощает совместное использование приложения или набора служб в нескольких средах.

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

Подман

Podman (POD MANager) создает, запускает и управляет контейнерами OCI и образами контейнеров. Он был разработан Red Hat и изначально предназначался для корпоративного Linux 8. Он используется для управления контейнерами и является официальным преемником Docker.

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

Он управляет всей экосистемой контейнеров с помощью библиотеки libpod. Поскольку Podman работает только на платформах Linux, в настоящее время разрабатываются REST API и клиенты, позволяющие системам Mac и Windows вызывать службу.

Однако в настоящее время существует удаленный клиент на базе Varlink, который работает на платформах Mac или Windows и позволяет удаленно связываться с сервером Podman на базе Linux. Библиотека libpod поддерживает несколько методов безопасной загрузки изображений, включая проверку доверия и изображений.

Он также поддерживает модули для совместного управления группами контейнеров и несколько форматов изображений, включая форматы изображений OCI и Docker.

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

Амбициозные пользователи контейнеров уже могут выйти на новый уровень с модулями. Построение и эксплуатация кластера Kubernetes больше не нужны. В простейшем случае вновь разработанные модули можно тестировать и улучшать в ходе отдельных операций. Возможен даже последующий перенос в Kubernetes.

Команда podmangenerate kube предоставляет соответствующие файлы конфигурации. Затем они служат входными данными для инструмента Kubernetes kubectl.

Текущие версии Podman даже могут создавать файлы конфигурации для systemd — удовольствие для всех, кто использует вездесущий преемник init для оркестровки контейнеров.

Подман против Докера: различия

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

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

Это позволяет процессам, запущенным в контейнерах, получать доступ к ядру с привилегиями root и, таким образом, атаковать хост-систему.

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

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

В то время как Docker следует модели клиент-сервер, где клиент Docker взаимодействует с демоном Docker через API, Podman следует модели fork-exec. Каждый контейнер запускается как дочерний процесс Podman.

Пространство имен пользователя создается при первом использовании, когда Podman запускается с обычными правами пользователя. В пространстве имен пользователя Podman запускается с правами root и имеет права на монтирование файловых систем и создание контейнеров.

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

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

Хост может использовать команду mount/unmount для монтирования файловой системы контейнера, например, для доступа или изменения файлов, а затем снова их размонтировать.

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

Кроме того, Podman предоставляет команду podmangeneratesystemd, которая генерирует соответствующий сервис systemd для соответствующего контейнера и, таким образом, освобождает пользователя от создания сервисов systemd, а это означает, что доступна интеграция в хост-системе.

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

Подман Докер
Архитектура Демон Демон меньше
Управление услугами Системад Докер-движок
Совместимость с брандмауэром Перезаписывает правила брандмауэра Соблюдает правила брандмауэра
Платформа Встроенная поддержка Linux Linux, Windows и Mac

Когда следует переходить с Docker на Podman

Если вы развертываете контейнеры в среде на основе RHEL, в этом случае у вас не так много вариантов, кроме использования Podman, поскольку он является родным для RHEL. Вы также можете перейти на Podman или выбрать Podman вместо Docker, если у вас небольшие развертывания с небольшим количеством контейнеров.

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

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

Миграция с Podman на Docker

Если вы находитесь в командной строке, переключиться с Docker Engine на Podman довольно легко. Проще говоря, большую часть времени работает команда $ alias docker=podman.

Конечно, это предполагает, что в системе установлено соответствующее программное обеспечение. В случае с Linux это тоже не проблема; готовые пакеты программного обеспечения доступны для коммерческих дистрибутивов.

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

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

Переключиться немного сложнее, когда используются графические инструменты, такие как Docker Desktop. Особенно это должно коснуться тех разработчиков, которые работают с Windows или macOS.

Пользователям Docker Desktop придется привыкнуть к командной строке, и то же самое относится и к созданию Docker. Однако есть проект podman-compose. Программное обеспечение, написанное на Python, служит заменой Docker Compose.

Заключительные слова

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

Реальным преимуществом является отсутствие отдельного процесса-демона и привилегий root, не говоря уже о естественном использовании групп контейнеров. Однако стоит отметить, что Docker остается основной технологией в отношении контейнеров, но, скорее всего, в долгосрочной перспективе ситуация изменится.

Источник