Podman проти Docker: який вибрати?

| | 0 Comments| 9:25 AM
Categories:

Якщо ви любите світ віртуалізації та контейнеризації, ви, ймовірно, стикалися з Podman і Docker, і вам могло бути цікаво, чим вони відрізняються один від одного.

У цьому дописі ми дослідимо відмінності між Docker і Podman і спробуємо знайти правильний вибір для вас!

Докер

Docker — це технологія контейнеризації, яка полегшує керування залежностями в межах проекту на всіх рівнях (розробка та розгортання).

Механізм Docker, доступний для Linux, Windows і Mac OS, зосереджується навколо контейнерів та їх оркестровки, і саме цим контейнеризація відрізняється від віртуалізації.

Docker складається з двох основних будівельних блоків: Docker CLI і Docker Daemon.

Докер Демон:

Це постійний фоновий процес, який допомагає керувати образами Docker, контейнерами, мережами та обсягами зберігання. Docker використовує свій REST API Docker Engine для взаємодії з демоном Docker, доступ до якого здійснюється через протокол HTTP.

Docker CLI:

Автор зображення: Redhat

Це клієнт командного рядка Docker для взаємодії з демоном Docker. Це те, що ви використовуєте, коли запускаєте будь-яку команду Docker.

Робота Docker базується на ядрі Linux і функціях цього ядра, таких як контрольні групи та простори імен. Ці функції відокремлюють процеси, щоб вони могли працювати незалежно, оскільки мета контейнерів полягає в тому, щоб запускати кілька процесів і програм окремо.

Саме це дає можливість оптимізувати використання інфраструктури без зниження рівня безпеки порівняно з окремими системами.

Усі контейнерні інструменти, такі як Docker, мають модель розгортання на основі зображень. Ця модель спрощує спільне використання програми або набору служб у кількох середовищах.

Крім того, Docker допомагає автоматизувати розгортання програм у середовищі контейнера. За допомогою цих різноманітних інструментів користувачі отримують повний доступ до програм і можуть прискорити розгортання, контролювати версії та призначати їх.

Підман

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

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

  Як увімкнути двофакторну аутентифікацію для LinkedIn

Він керує всією екосистемою контейнерів за допомогою бібліотеки libpod. Оскільки Podman працює лише на платформах Linux, REST API та клієнти зараз розробляються, щоб дозволити системам Mac і Windows викликати службу.

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

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

У дуже маленьких і керованих середовищах Podman може навіть служити попередником Kubernetes. Він усуває розрив між унікальним керуванням окремими екземплярами з перших років реклами контейнерів і сучасною оркестровкою з Kubernetes.

Амбіційні користувачі контейнерів вже можуть насолоджуватися наступним рівнем з контейнерами. Створення та робота кластера Kubernetes більше не потрібні. У найпростішому випадку новосконструйовані контейнери можна перевірити та вдосконалити в окремих операціях. Можливий навіть подальший перехід на Kubernetes.

Команда podman generate kube надає відповідні файли конфігурації. Потім вони один до одного служать вхідними для інструмента Kubernetes kubectl.

Поточні версії Podman можуть навіть створювати конфігураційні файли для systemd – це радість для всіх, хто використовує всюдисущий наступник init для оркестровки контейнера.

Podman проти Docker: відмінності

Docker швидко зарекомендував себе як коник для керування контейнерами. Проте Docker має багато переваг і, перш за все, швидко зростаючий репертуар зображень, а також недоліки та можливі ризики для безпеки. Крім того, Docker більше не підтримується як контейнер для Kubernetes.

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

Це дозволяє процесам, запущеним у контейнерах, отримувати доступ до ядра з привілеями root і таким чином атакувати хост-систему.

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

  Вичерпний посібник із NFT CryptoPunks

З точки зору безпеки це добре, тому що Podman менш вразливий до атак, якщо демону не потрібно працювати 24/7 з правами суперкористувача. Podman не вимагає фонового процесу через архітектуру, яка принципово відрізняється від Docker.

Тоді як Docker дотримується моделі клієнт-сервер, де клієнт Docker спілкується з демоном Docker через API, Podman дотримується моделі fork-exec. Кожен контейнер працює як дочірній процес Podman.

Простір імен користувача створюється під час першого використання, коли Podman запускається зі звичайними привілеями користувача. У просторі імен користувача Podman працює з привілеями root і має права монтувати файлові системи та створювати контейнери.

Відповідно, контейнер Podman має лише ті права, які має виконуючий користувач. Використання просторів імен користувачів означає, що кожен користувач може створювати власні контейнери та керувати ними, але вони не видимі для інших користувачів і суперкористувача.

Оскільки Podman працює незалежно від Docker, розробники мають багато свободи дій і можуть реагувати на побажання спільноти. Цікаві доповнення до Podman включають команду mount/unmount та інтеграцію systemd.

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

Хоча моніторинг контейнерів за допомогою systemd не працює через демон у Docker with Podman, контейнери можна запускати, контролювати та навіть перезапускати за допомогою systemd.

Крім того, Podman надає команду podman generate systemd, яка генерує відповідну службу systemd для відповідного контейнера і, таким чином, звільняє користувача від створення служб systemd, що означає, що інтеграція в головну систему доступна.

Ще одна суттєва відмінність між Podman і Docker полягає в тому, що останній не змінює правил брандмауера чи поточної інсталяції dnsmasq через його здатність створювати внутрішню мережу. Навпаки, Docker має перезаписати правила брандмауера, щоб увімкнути зв’язок між контейнерами.

PodmanDockerArchitecture DaemonDaemon lessServices Management SystemdDocker EngineFirewall Compatibility Перезаписує правила брандмауера Дотримується правил брандмауера ПлатформаВнутрішня підтримка linuxLinux, Windows і Mac

Коли вам слід перейти з Docker на Podman

Якщо ви розгортаєте контейнери в середовищі на основі RHEL, у цьому випадку у вас не буде багато варіантів, окрім використання Podman, оскільки він є рідним для RHEL. Ви також можете перейти на або вибрати Podman замість Docker, якщо у вас невеликі розгортання з невеликою кількістю контейнерів.

  25 найкращих безкоштовних інструментів веб-сканера

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

Подібним чином, якщо ви тільки починаєте входити у світ контейнерів, у цьому випадку Docker є кращим вибором, оскільки він стабільний, добре налагоджений з належною документацією та має неглибоку криву навчання порівняно з Podman, якому все ще бракує стабільності та не має чітко визначеної документації.

Міграція з Podman на Docker

Якщо ви перебуваєте в командному рядку, досить легко переключитися з Docker Engine на Podman. У найпростішому вигляді псевдонім $ виконує команду docker=podman більшу частину часу.

Звичайно, це передбачає, що в системі встановлено відповідне програмне забезпечення. У випадку з Linux це теж не проблема; готові програмні пакети доступні для комерційних дистрибутивів.

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

Але є й винятки, оскільки деякі команди Docker не мають відповідників у світі Podman. Подібним чином деякі команди поводяться інакше в Docker, ніж у всесвіті Podman. На даний момент це впливає лише на обробку томів, які вже налаштовано.

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

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

Заключні слова

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

Справжньою перевагою є відсутність окремого процесу демона та привілеїв root, не кажучи вже про природне використання груп контейнерів. Однак варто зазначити, що Docker залишається основною технологією щодо контейнерів, але це, швидше за все, зміниться в довгостроковій перспективі.

Ви також можете дослідити деякі команди Docker для керування контейнерами.