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

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

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

Podman — инструмент, который стоит освоить, если вы регулярно работаете в Linux. Ниже — путь от установки до уверенной повседневной работы: без предположений, что всё уже настроено само.

Зачем нужен Podman

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

Установка

В 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

Пошаговая настройка

После установки переходите к базовому сценарию. Команды ниже выполняйте от пользователя с достаточными правами, но не запускайте всё под root без необходимости.

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

5. Включите lingering

Без lingering пользовательские службы останавливаются при выходе из сессии. Для сервера без постоянного входа это критично.

loginctl enable-linger $(whoami)
loginctl show-user $(whoami) | grep Linger

6. Проверьте обновление и логи

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

podman pull docker.io/library/nginx:alpine
systemctl --user restart container-app.service
journalctl --user -u container-app.service -n 30 --no-pager

Базовая конфигурация

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

# ~/.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 — проверяйте сложные файлы.

Совет 5. Для Kubernetes-совместимых сценариев используйте podman kube generate

Для Kubernetes-совместимых сценариев используйте podman kube generate и kube play.

Практический сценарий

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

Дальше действуйте короткими шагами: установка, минимальная конфигурация, проверка, затем расширение. После каждого шага фиксируйте, что именно изменилось и как это проверить. Такой журнал экономит время, когда через месяц понадобится повторить настройку на другом сервере или объяснить её коллеге.

Порядок работ для этого сценария выглядит так:

  1. Проверьте установку и режим
  2. Настройте подчинённые UID
  3. Запустите первый сервис
  4. Настройте автозапуск через systemd
  5. Включите lingering
  6. Проверьте обновление и логи

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

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

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

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

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

2. Порт занят

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

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

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

Что проверить перед вводом в работу

Перед тем как считать настройку завершённой, пройдитесь по короткому списку. Он не заменяет полноценный аудит, но отсекает большинство очевидных проблем.

Чек-лист

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

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

Итог

Podman — это не «поставил и забыл». Рабочая конфигурация складывается из понимания задачи, аккуратной установки и проверки результата. Начните с базового сценария, затем добавляйте только те возможности, которые действительно используете.

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

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

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

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

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