Добавить в корзинуПозвонить
Найти в Дзене
Цифровая Переплавка

Подман вместо Докера: почему стоит пересмотреть привычку

Когда-то Docker казался чудом: контейнеры упростили жизнь разработчикам, позволили запускать код одинаково на ноутбуке и в продакшене. Но со временем «магия» обернулась головной болью: постоянный демон dockerd, работающий с root-правами, стал не только прожорливым, но и уязвимым. Именно поэтому всё больше инженеров, включая автора статьи Доминика Шиманского, переходят на Podman. Главное отличие Podman от Docker: Docker же за последние годы отметился уязвимостями вроде CVE-2019-5736 (escape через runC) или «Dirty Pipe». В случае Podman архитектура сама минимизирует такие риски. Podman «чувствует» себя в Linux как родной: Меня особенно впечатляет, что переход на Podman не требует переписывания проектов: Для тех, кто жил в docker-compose, есть альтернатива: podman-compose или генерация манифестов под Kubernetes (podman generate kube). Я считаю, что Podman — это не «замена ради замены», а следующий логичный шаг. Docker показал миру контейнеры, но застрял в архитектурных компромиссах. Podma
Оглавление

Когда-то Docker казался чудом: контейнеры упростили жизнь разработчикам, позволили запускать код одинаково на ноутбуке и в продакшене. Но со временем «магия» обернулась головной болью: постоянный демон dockerd, работающий с root-правами, стал не только прожорливым, но и уязвимым. Именно поэтому всё больше инженеров, включая автора статьи Доминика Шиманского, переходят на Podman.

🔒 Безопасность как архитектурное решение

Главное отличие Podman от Docker:

  • 🚫 Нет постоянного демона. Контейнер запускается как дочерний процесс текущего пользователя.
  • 🧑‍💻 Rootless-режим по умолчанию — даже если злоумышленник получит root в контейнере, на хосте он останется обычным пользователем.
  • 🛡️ Меньше точек отказа: сбой одного контейнера не обрушивает всю систему.

Docker же за последние годы отметился уязвимостями вроде CVE-2019-5736 (escape через runC) или «Dirty Pipe». В случае Podman архитектура сама минимизирует такие риски.

⚙️ Интеграция с Linux

Podman «чувствует» себя в Linux как родной:

  • 📜 systemd — генерация unit-файлов одной командой podman generate systemd. Контейнеры становятся полноценными сервисами.
  • 📦 Pods — родная поддержка групп контейнеров с общими ресурсами. Идеально для разработки под Kubernetes.
  • 🔧 Unix-философия — вместо монолита есть связка инструментов:
    🏗️
    Buildah для сборки образов,
    🔍
    Skopeo для копирования и анализа.

🚀 Миграция без боли

Меня особенно впечатляет, что переход на Podman не требует переписывания проектов:

  • 🪄 Достаточно прописать алиас alias docker=podman.
  • 📜 Dockerfile остаются рабочими, т.к. оба используют OCI-формат.
  • 🧩 Различия касаются в основном привилегированных портов (теперь лучше использовать reverse proxy) и прав доступа к томам.

Для тех, кто жил в docker-compose, есть альтернатива: podman-compose или генерация манифестов под Kubernetes (podman generate kube).

🌍 Личное мнение

Я считаю, что Podman — это не «замена ради замены», а следующий логичный шаг. Docker показал миру контейнеры, но застрял в архитектурных компромиссах. Podman же органично вписывается в современный стек DevOps, где Kubernetes и systemd — повседневность.

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

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

🔗 Источники: