Коротко о главном

Podman запускает контейнеры без постоянного демона и умеет работать от обычного пользователя. Команды похожи на docker, поэтому переход занимает минуты, но архитектура другая: контейнеры — это процессы, которыми управляет systemd, а не клиенты одного привилегированного сервиса. Для домашнего сервера это заметно снижает риски.

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

Большинство проблем с Podman сводится к нескольким повторяющимся ошибкам. Ниже — что проверить в первую очередь и как не усугубить ситуацию.

Почему это происходит

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

Типичные ошибки

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

1. Permission denied при запуске rootless

Проверьте подчинённые UID/GID, настройки новых пользовательских пространств имён и версию ядра. После изменения subuid перезайдите в сессию.

2. Порт занят

Посмотрите, кто слушает порт, и смените публикацию. Конфликт часто возникает между системным сервисом и контейнером.

3. Служба не стартует после выхода из системы

Включите lingering и проверьте путь к юниту: системные и пользовательские юниты лежат в разных каталогах.

Как настроить правильно

Правильная последовательность проста: проверить версию и зависимости, сделать резервную копию конфигурации, внести минимальное изменение, проверить логи и только потом двигаться дальше.

Установка

В Debian, Ubuntu и Linux Mint используется пакетный менеджер APT:

sudo apt install podman podman-compose

В Fedora и RHEL-совместимых системах пакет ставится через DNF:

sudo dnf install podman podman-compose

В Arch Linux и производных пакет доступен в официальных репозиториях:

sudo pacman -S podman podman-compose

1. Проверьте установку и режим

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

podman --version
podman info --format '{{.Host.Security.Rootless}}'
podman run --rm alpine echo ok

2. Настройте подчинённые UID

Для rootless-контейнеров нужен диапазон подчинённых идентификаторов. Проверьте, что он выделен пользователю.

grep "^$(whoami):" /etc/subuid /etc/subgid
podman unshare cat /proc/self/uid_map

3. Запустите первый сервис

Создайте том и запустите контейнер с публикацией порта только на localhost. Так сервис не окажется в сети до настройки прокси.

podman volume create appdata
podman run -d --name app -p 127.0.0.1:8080:80 -v appdata:/data docker.io/library/nginx:alpine
curl -I http://127.0.0.1:8080

4. Настройте автозапуск через systemd

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

podman generate systemd --new --name app > ~/.config/systemd/user/container-app.service
systemctl --user daemon-reload
systemctl --user enable --now container-app.service

Рабочий конфиг

Начните с минимального рабочего варианта. Не копируйте большой конфиг целиком: добавляйте параметры по одному и проверяйте результат после каждого изменения.

# ~/.config/containers/registries.conf
unqualified-search-registries = ["docker.io"]

# ~/.config/containers/storage.conf
[storage]
driver = "overlay"

Практические советы

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

Совет 1. Не запускайте rootless-контейнеры с —privileged: это сводит защиту на

Не запускайте rootless-контейнеры с —privileged: это сводит защиту на нет.

Совет 2. Для портов ниже 1024 используйте обратный прокси, а не повышение прав.

Для портов ниже 1024 используйте обратный прокси, а не повышение прав.

Совет 3. Храните данные в именованных томах или явных каталогах, а не внутри ко

Храните данные в именованных томах или явных каталогах, а не внутри контейнера.

Совет 4. podman-compose удобен, но не покрывает все возможности docker compose

podman-compose удобен, но не покрывает все возможности docker compose — проверяйте сложные файлы.

Профилактика

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

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

Чек-лист

  • Версия пакета и конфигурация зафиксированы и доступны для сравнения.
  • Есть автоматическая проверка синтаксиса перед перезапуском службы.
  • Журналы ротуются, а диск не заполняется ими за неделю.
  • Изменения проходят через тестовый стенд, а не сразу на рабочий сервер.

Итог

Большинство ошибок с Podman лечится не переустановкой, а проверкой конфигурации, логов и прав доступа. Действуйте по одному изменению за раз — и причина быстро найдётся.

Насколько публикация полезна?

Нажмите на звезду, чтобы оценить!

Средняя оценка 0 / 5. Количество оценок: 0

Оценок пока нет. Поставьте оценку первым.

Поделиться: Telegram ВКонтакте