Установка Podman  Компоненты Podman  Как Podman запускает контейнеры  Docker Compose  Podman REST API  Перемещение образов между машинами  Генерируем исходный код проекта Spring Boot  Добавляем логику  Dockerfile  Build  Push  Test  Scan  Archive  Шифрование  В этой статье мы не будем подробно разбирать базовые функции Podman и отличия этого проекта от Docker. Такой информации хватает в интернете. Вместо этого, мы на конкретном примере (простое Java приложение) разберем как можно заменить Docker на Podman в конвейере CI/CD, и какие это может принести дивиденды. Podman – это инструмент с открытым исходным кодом для работы с образами контейнеров. Является утилитой командной строки с аналогичными docker командами, однако не требует дополнительный сервис для работы и может работать без привилегий root. В этой статье речь пойдет об использовании Podman в контексте CI/CD, но перед этим стоит перечислить несколько отличий Podman о Docker: Podman позволяет конфигурировать короткие имена для реестров. В Docker используется docker.io когда вы выбираете короткое имя. Podman может запускать контейнеры и поды и использованием YAML Кубернетес. А также он может генерировать YAML Кубернетес для запущенных контейнеров. Podman поддерживает поды как в Кубернтес и может запускать несколько контейнеров в одном поде. Podman работает как обычная CLI утилита, а Docker необходимо несколько демонов Linux с привилегиями root. Podman может запускать контейнеры в разных пользовательских пространствах имен в отличии от Docker. Podman поддерживает запуск systemd в контейнерах а также многие другие возможности systemd. Podman не нужен для работы контейнеров, а Doсker использует демон Linux, который должен быть запущен всегда. Все настройки по-умолчанию в Podman можно кастомизировать в отличии от Docker. В то время как Docker использует монолитное приложение для создания, запуска и загрузки образов контейнеров, разработчики Podman решили разделить функционал между тремя проектами: Podman, Buildah, и Skopeo. Podman на Windows и macOS уже доступен, а Buildah пока доступна только на Linux, с возможностью установки в WSL2 на Windows. docker container update Podman не поддерживает изменение запущенных контейнеров, рекомендуется пересоздавать их заново. docker plugin Podman не поддерживает плагины. docker swarm Podman не поддерживает Docker Swarm, вместо этого Podman, для оркестрации интегрируется с Кубернетес и использует CRI-O. docker trust Эта команда имплементрована как Podman image trust. podman container podman generate podman healthcheck podman image podman init podman machine podman mount podman network exists/prune/reload podman play podman pod podman system podman unmount podman unshare podman untag podman volume exists Пакеты Podman доступны для большинства дистрибутивов Linux и не требуют настройки дополнительных репозиториев: Сборка Podman из исходного кода гораздо проще, чем компиляция бинарных файлов Docker. Компонент Описание libpod Управление жизненным циклом контейнеров crun/runc Среда выполнения контейнеров containers/image Управление образами контейнеров containers/storage Управление томами, файловой системой и хранилищем данных для контейнеров и образов Buildah Сборка контейнеров Conmon Мониторинг среды выполнения контейнеров Container Network Interface (CNI) Управление сетями реализовано на основе спецификаций Кубернетес CNI Для того, чтобы получить список с реестрами контейнеров которые используются Podman: Compose нужен для оркестрации мультиконтейнерных приложений. Podman полностью совместим с Docker Compose, однако для это необходимо активировать сервис сокета в системе: docker-compose нужен docker.sock, поэтому Podman при установке создает символическую ссылку на этот файл: После активации сервиса сокета можно проверить REST API Podman с помощью curl: В данном случае вы должны получить список со всеми образами контейнеров в системе. Большинство функции Podman CLI доступны через REST API. Podman позволяет перемещать образы контейнеров между хостами, без использования реестров контейнеров. Сначала нужно добавить новое SSH соединение: Затем копируем образ с помощью команды podman image scp: В качестве примера будет использоваться тестовый проект на Java Spring Boot. Для сборки Java будет использоваться Gradle. Для оркестрации Jenkins. Spring Boot дает возможность с помощью встроенных средств создавать скелет проекта: директории и исходный код для сборных инструментов экосистемы Java – Maven и Gradle. Для этого можно использовать интерфейс командной строки, веб-форму, в данном случае вы будете использовать утилиту curl: После выполнения этой команды, в текущей директории должен появится каталог приложения под названием hello: Для того, чтобы вывести список с файлами в директории выполните команду ls hello. Планируемый результат: Нужно будет добавить код в директорию сгенерированного приложения, для того, чтобы скомпилировать проект. Ниже приведен пример кода, который нужно добавить в скелет проекта. HelloApplication.java: Добавите этот код в проект: Выполнить команду: ls hello/src/main/java/com/example/demo/ Планируемый результат: Для работы вы будете использовать следующий Dockerfile: Следующая стадия определяет контейнер который содержит только среду выполнения Java (Java runtime). Jar-файл из предыдущей стадии копируется в новый контейнер, а остальные инструкции нужны, чтобы запустить с нужными параметрами приложение Spring Boot, которое мы создали. Скопируйте Dockerfile в проект: Выполнить команду: ls hello/Dockerfile Планируемый результат: Jenkins с помощью вебхуков (webhook) можно интегрировать с GitLab или Gitea, таким образом можно организовать автоматический запуск CI конвейера после коммита в репозиторий Git. Для сборки образа будем использовать Buildah. Buildah это инструмент который работает в связке с Podman. Кодовая база Podman включает в себя пакеты Buildah. Buildah поддерживает формат Dockerfile, но его цель это низкоуровневый интерфейс для сборки образов контейнеров без Dockerfile. Buildah не нужен демон Linux, с помощью этого инструмента можно создавать образ контейнера внутри другого контейнера. Buildah не нужны привилегии root для сборки образов, что является несомненным плюсом с точки зрения безопасности. После запуска сборки в логах можно увидеть вывод Gradle:  Основные конфигурационные файлы, которые используются Buildah: /etc/containers/registries.conf - Реестры контейнеров. /usr/share/containers/policy.json - Верификация сигнатур. /usr/share/containers/mounts.conf - Директории и файлы которые автоматически монтируются в контейнерах. /usr/share/containers/seccomp.json - Системные вызовы которые разрешены для выполнения в контейнерах. Загрузка собранного образа в реестр ничем не отличается от Docker: Так же как и с Docker для аутентификации используется команда podman/buildah login Buildah так же как и Podman умеет работать c аутентификационными файлами: buildah push --authfile /auth.json registry.example.com Podman позволяет проверять состояние контейнера и приложения с помощью специальных проверок (healthchecks). Механизм проверок похож на то, что было реализовано в последних версиях Docker Compose. С помощью этой функции, можно встраивать в конвейер CI простые функциональные и интеграционные тесты. Для сканирования собранного образа на уязвимости можно использовать один из популярных инструментов для статического анализа уязвимостей (SAST): Результаты сканирования для каждой сборки будут сохранятся в Jenkins:  Skopeo используется для копирования и перемещения образов между реестрами контейнеров. В данном случае образ контейнера из публичного реестра с помощью skopeo сохраняется для архивации на диске: Skopeo можно использовать для реверс-инжиниринга образов, в случаях, когда не доступа к Dockerfile: В ситуациях когда необходимо использовать публичный реестр контейнеров для работы с закрытой кодовой базой, skopeo позволяет использовать шифрование: Загружаем образ с помощью skopeo: Инструктируем Jenkins сохранять сборочные артефакты и останавливать все запущенные контейнеры после прогона конвейера: Скачать docker-compose: Сделать файл исполняемым: Удостовериться, что docker-compose работает: Сохранить файл со следующим содержимым docker-compose.yaml: Запустите docker-compose: Планируемый результат: http://<< IP ADDRESS >>:8088 Сгенерированный автоматический пароль можно найти в логе:  Введите пароль:  Дождитесь завершения загрузки плагинов:  Выберите «new item» => pipeline:  В секции «pipeline» нужно будет добавить скрипт для тестового приложения:  Конвейер для тестового приложения: