Перейти к основному содержимому
Принцип работы Podman

Основные сущности⁠

Контейнер⁠

Контейнер (Container) — это изолированная среда исполнения приложений с их зависимостями. Для работы контейнеры используют ядро Linux и его встроенные возможности: namespaces и cgroups.

Используемая изоляция для контейнеров

Для контейнеров используются следующие виды изоляции:

  • IPC — изоляция ресурсов межпроцессного взаимодействия;
  • Network — изоляция сетевого стека;
  • Mount — изоляция точек монтирования;
  • PID — изоляция идентификаторов процессов;
  • User — изоляция идентификаторов пользователей и групп;
  • UTS — изоляция имени хоста и доменного имени.

Образ контейнера⁠

Образ контейнера (Container Image) — это неизменяемый шаблон, содержащий файловую систему, зависимости и настройки, необходимые для запуска приложения. Он служит основой для создания контейнера и зависит от архитектуры процессора.

Образ хранится в единственном экземпляре в системе и используется множеством контейнеров. Образ не копируется при создании контейнеров: это экономит дисковое пространство и ускоряет запуск экземпляров. Контейнер является запущенным экземпляром образа, а все изменения, сделанные во время его работы (например, запись файлов или модификация данных), сохраняются в новом слое, не затрагивая исходный образ.

Многослойная структура образа позволяет создавать кастомные образы на основе внесенных изменений.

Например, можно собрать образ Nginx на основе контейнерного образа SELECTOS.

Реестр образов⁠

Реестр образов (Registry) — это централизованное хранилище для распределения и управления контейнерными образами.

Реестры бывают:

  • публичные — для обмена открытыми образами и использования готовых решений (например, Docker Hub, Quay.io);
  • приватные — для хранения собственных, часто коммерческих или чувствительных к безопасности и стандартам образов.

Podman поддерживает работу как с публичными, так и с приватными реестрами образов, совместимыми с OCI-форматами.

В SELECTOS 2.0 Hele поставляется Podman 5.4.x. По умолчанию Podman настроен на использование реестра cr.selectos.selectel-lab.ru.

Можно подключать дополнительные реестры, в том числе локальные приватные реестры (например, развернутые через registry:2 или Harbor), облачные managed-сервисы (AWS ECR, Google Container Registry, Azure Container Registry), корпоративные решения.

Конфигурационный файл /etc/containers/registries.conf определяет порядок поиска образов, политики безопасности и параметры аутентификации.

Под⁠

Под (pod) — это группа контейнеров, объединенных некоторыми общими ресурами. Пример использования пода: запуск веб-сервера, состоящего из http-сервера и базы данных.

Концепция пода заимствована из Kubernetes и поддерживается Podman нативно. Каждый под имеет инфра-контейнер, который обеспечивает постоянную работу пода. Podman поддерживает управление как подами, так и отдельными контейнерами.

Используемая изоляция для подов

Виды изоляции (namespace), разделяемые контейнерами внутри пода:

  • Network — общение через localhost благодаря общему сетевому пространству;
  • PID (Process ID) — контейнеры видят процессы друг друга, могут отправлять сигналы между процессами;
  • IPC (Inter-Process Communication) — контейнеры могут использовать общие механизмы межпроцессного взаимодействия (очереди сообщений, разделяемая память, семафоры);

Инфра-контейнер⁠

Инфра-контейнер (Infra-container) — это основной контейнер, который всегда входит в под, и поддерживает его жизненный цикл.

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

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

Tом⁠

Том (volume) — это механизм сохранения данных независимо от жизненного цикла контейнера. Томы нужны для передачи объемных файлов в контейнер и сохранения созданных во время его работы данных. Они позволяют монтировать существующую на системе директорию внутрь контейнера или создавать отдельное хранилище, которое потом будет доступно на хосте.

Принцип работы Podman⁠

Ниже описан принцип работы Podman на примере выполнения команды запуска postgres-контейнера.

1. Запуск контейнера командой podman run⁠

podman run -d --name my-container -p 8080:80 docker.io/library/nginx:latest

Эта команда запускает контейнер для образа в фоновом режиме (-d, --detached) и присваивает ему имя my-container. Podman CLI обращается к библиотеке libpod, выполняющей роль бэкенда для Podman.

2. Получение образа⁠

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

3. Подготовка файловой системы⁠

Библиотека libpod создает «верхний» записываемый слой поверх неизменяемых слоев образа Postgres. Все изменения в контейнере будут записываться в этот новый слой.

4. Формирование конфигурации контейнера⁠

Библиотека libpod создает конфигурационный файл config.json в стандартном OCI-формате. Среда запуска контейнеров использует данный файл для получения настроек контейнера: параметров запуска, монтирования томов, переменных окружения, cкриптов или команд, которые выполняются до/после запуска, пользовательских настроек и пр.

5. Настройка сети⁠

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

6. Запуск контейнера⁠

Podman запускает вспомогательный процесс conmon (Container Monitor) для мониторинга контейнерного процесса, сбора его логов и обработки сигналов. Процесс conmon вызывает среду запуска контейнера OCI runtime, которая с помощью системных вызовов ядра Linux формирует изолированную среду и запускает основной процесс контейнера.

7. Мониторинг⁠

Процесс conmon остается запущенным и отслеживает состояние контейнера. Если указан флаг -d, Podman завершит работу по окончании основного процесса. Дополнительные флаги -it (–-interactive, — tty) указывают, чтобы создать псевдотерминал для контейнера и интерактивной работы в нем.

8. Завершение⁠

После завершения работы контейнера conmon тоже прекращает свою работу.