Расскажи про свой опыт работы с Podman

Мой опыт работы с Podman

Как DevOps-инженер с более чем 10-летним опытом, я активно использую Podman в production-средах примерно с 2019 года, когда он начал набирать популярность как безопасная и архитектурно более корректная альтернатива Docker. Мой опыт охватывает миграцию с Docker на Podman, интеграцию в CI/CD-пайплайны, оркестрацию через Podman Compose и systemd, а также решение сложных проблем, связанных с сетевыми моделями и безопасностью.

Ключевые преимущества и особенности Podman в моей практике

1. Архитектура без демона (daemonless):

    *   Это главное преимущество с точки зрения безопасности и стабильности. Каждый контейнер запускается как отдельный процесс пользователя, что устраняет единую точку отказа и снижает поверхность для атак.
    *   На практике это означает большую надежность. Падение **containerd** (или демона Docker) не приводит к остановке всех контейнеров. Я наблюдал это в продакшене: при обновлении ядра или сбое системы контейнеры, запущенные через Podman, часто восстанавливались корректнее.

1. Работа с rootless-контейнерами:

    *   Возможность запуска контейнеров от имени непривилегированного пользователя — это game-changer для безопасности. Я внедрил эту практику для всех внутренних и тестовых сервисов.
    *   Пример команды для запуска rootless-контейнера:

    ```bash
    podman run -d --name my-app -p 8080:8080 localhost/my-app:latest
    ```

    *   Это потребовало настройки подсистем Linux (`/etc/subuid`, `/etc/subgid`) и часто — увеличения `user.max_user_namespaces` через `sysctl`. Решение этих нюансов — часть моего опыта.

1. Интеграция с systemd для управления жизненным циклом:

    *   Podman идеально вписывается в экосистему Linux. Я создаю **systemd-юниты** для управления контейнерами как обычными службами, что дает автоматический запуск при загрузке, мониторинг и перезапуск.
    *   Пример unit-файла (`/etc/systemd/system/myapp.service`):

    ```ini
    [Unit]
    Description=My Application Container
    After=network.target

    [Service]
    Type=exec
    ExecStart=/usr/bin/podman run --name myapp --rm -p 8080:8080 myapp:latest
    ExecStop=/usr/bin/podman stop myapp
    Restart=always
    User=myuser
    Group=myuser

    [Install]
    WantedBy=multi-user.target
    ```

    *   Генерация таких юнитов часто автоматизируется через `podman generate systemd --new --files --name myapp`.

Реальные сценарии использования и решения проблем

• CI/CD пайплайны (GitLab CI, Jenkins):

    *   Я настраивал runner'ы для использования Podman-in-Podman (используя `podman run --privileged` или `--security-opt label=disable` в особых случаях) для сборки образов. Ключевым было решение проблем с **user namespace mapping** внутри контейнеров.
    *   Пример этапа сборки в `.gitlab-ci.yml`:

    ```yaml
    build:
      stage: build
      script:
        - podman build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA .
        - podman push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
      only:
        - main
    ```

• Orchestration с Podman Compose:

    *   Для локальной разработки и развертывания небольших стеков (например, приложение + PostgreSQL + Redis) я использую **Podman Compose**. Он обеспечивает полную совместимость с файлами `docker-compose.yml`, но работает в rootless-режиме.
    *   Пример команды для работы со стеком:

    ```bash
    podman-compose -f docker-compose.prod.yml up -d
    ```

• Сетевые модели и тюнинг:

    *   По умолчанию Podman использует **CNI** для сетей, что дает большую гибкость, чем драйвер Docker. Я настраивал изолированные сети, статический IP-адреса для контейнеров и проброс IPv6.
    *   Создание пользовательской сети:

    ```bash
    podman network create --subnet 10.89.0.0/24 my-custom-net
    podman run --network my-custom-net --ip 10.89.0.42 nginx
    ```

• Работа с образами и реестрами:

    *   Podman полностью совместим с OCI-образами и реестрами (Docker Hub, Quay,私有ные реестры). Я активно использовал **skopeo** (часть экосистемы Podman) для копирования образов между реестрами без их полной загрузки.
    *   Пример копирования образа:

    ```bash
    skopeo copy docker://docker.io/library/nginx:alpine docker://my-registry.local/nginx:alpine
    ```

Сравнение с Docker и выбор инструмента

В моей практике Podman стал основным инструментом для:

• Production-серверов, где критична безопасность (благодаря rootless).
• Сред, где недопустима зависимость от единого демона.
• Систем, тесно интегрированных со systemd и современными дистрибутивами (RHEL 8+, Fedora).

Однако Docker (или скорее его runtime, containerd) остается в арсенале для:

• Разработки на macOS/Windows (где Podman Desktop все еще развивается).
• Некоторых legacy-пайплайнов или инструментов, жестко завязанных на Docker Socket API.

Вывод

Мой опыт с Podman — это путь от экспериментов до полного внедрения в высоконагруженных проектах. Его философия "просто инструмент, а не платформа" резонирует с UNIX-подходом. Сложности, связанные с миграцией (например, тонкости настройки сетей или прав), окупаются повышенной безопасностью, стабильностью и прозрачностью работы. Podman — это не просто "замена Docker", а эволюционный шаг в управлении контейнерами, который я настоятельно рекомендую для современных Linux-сред.