Понятно, что в настоящий момент страсти вокруг Red Hat имеют совсем другой и весьма глобальный фокус, но мы всё же о своём — локальном и прикладном из мира контейнеров. С начала этого года в Red Hat активно трудятся над заменой для Docker под названием Podman (или libpod). Об этом проекте ещё почему-то не писали на хабре, а ведь сейчас весьма подходящее время для того, чтобы познакомиться с ним, узнать о его истоках и подумать о перспективах. Поехали!
![](https://habrastorage.org/r/w1560/webt/hd/wj/kz/hdwjkzhgebmi5nh0kqny89ujgoi.png)
Если окинуть взглядом современный мир Linux-контейнеров, то легко увидеть, что тема сегодняшней статьи является лишь одним из этапов долгосрочной стратегии Red Hat. Ярким тому подтверждением является проект CRI-O, о котором мы писали год назад. Если вкратце, то CRI-O — реализация интерфейса Kubernetes CRI (Container Runtime Interface) для запуска исполняемых сред контейнеров, совместимых со стандартом OCI (Open Container Initiative). Если ещё короче, то это замена Docker'у в качестве runtime для Kubernetes. (Схожая в техническом смысле инициатива для K8s со стороны компании Docker Inc — cri-containerd, о которой мы тоже писали; в той же статье есть сравнение производительности этих двух решений.)
История появления CRI-O такова, что, пока в OCI готовили стандарты для контейнеров (Runtime Specification и Image Specification) [что, впрочем, тоже происходило при участии Red Hat], в RH создали и поместили в инкубатор Kubernetes новый проект под названием OCID (Open Container Initiative Daemon), который позже [по требованию OCI] переименовали в CRI-O. Его предназначение звучало как «реализация стандартного интерфейса для исполняемой среды для контейнеров в Kubernetes», а продвижением в «технические массы» занимались в рамках более масштабного проекта Red Hat по созданию операционной системы для контейнеров — Project Atomic.
![](https://habrastorage.org/r/w780q1/webt/ev/lg/29/evlg29gpllaqx4dpakb6viu8wtc.jpeg)
Шапки с логотипом CRI-O на KubeCon + CloudNativeCon North America 2017
За минувшее время CRI-O дозрел до версии 1.0, получил поддержку в Minikube, а его последним достижением можно считать принятие в качестве интерфейса для исполняемой среды контейнеров по умолчанию в проекте Kubic, который, что особенно примечательно, развивается сообществом конкурентного (для Red Hat) Linux-дистрибутива — openSUSE.
Возвращаясь к теме статьи: Podman изначально был частью CRI-O.
Официальный анонс проекта Podman (название является сокращением от «pod manager») состоялся в феврале этого года:
По этой причине сам анонс был озаглавлен как «повторное представление» (reintroduction). А первый публичный релиз Podman — v0.2 — состоялся за 2 недели до этого анонса. Итак, в чём же суть Podman?
Цель Podman — предоставить консольный интерфейс для запуска контейнеров вне системы оркестровки. Примечательно, что запускаемые контейнеры могут быть объединены в специальные группы с общими пространствами имён, т.е. поды (pods) — эта концепция уже стала хорошо известной благодаря Kubernetes. Проект следует идеологии UNIX-команд, где каждая утилита делает лишь одну вещь, но хорошо. Другая важная деталь, которую неустанно подчёркивают разработчики, уже была процитирована выше в анонсе: Podman может использоваться как вместе с CRI-O, так и независимо от него.
В целом же основная задумка Podman заключается в том, чтобы предоставить пользователям Kubernetes, выбравшим CRI-O в качестве исполняемой среды для контейнеров, аналог консольного интерфейса Docker CLI (для взаимодействия с контейнерами и образами, запущенными в кластерах):
![](https://habrastorage.org/r/w1560/webt/a-/tm/uo/a-tmuolifndysjinywi1xj16wf8.png)
Фрагмент таблицы сравнения команд Docker и Podman: большинство из них совпадают, но встречаются и отличия
Однако за этой видимой идентичностью в интерфейсе кроется принципиальная разница в архитектуре: если Docker CLI для выполнения команд общается с демоном Docker, то Podman — самостоятельная утилита, не требующая никаких демонов для своей работы.
Как минимум из-за этого архитектурного отличия будет более корректным сравнивать Podman не с Docker как таковым, а с crictl — консольной утилитой из состава cri-tools (он используется, в частности, для интеграции containerd с Kubernetes). И здесь есть функциональные отличия: Podman может перезапускать остановленные контейнеры, а также обеспечивает управление образами контейнеров. (Более подробное сравнение см. в блоге OpenShift. )
С релизом Fedora 28 Atomic Host (май этого года) Podman стал инструментом этого Linux-дистрибутива по умолчанию для управления контейнерами. И только совсем недавно, в сентябре, на Linux-конференции All Systems Go! в Берлине Dan Walsh, руководитель команды Red Hat Container Engineering, представил Podman ещё более широкой публике — запись выступления можно увидеть здесь (а только презентацию — здесь).
![](https://habrastorage.org/r/w780q1/webt/33/tb/qx/33tbqxv_zc2u_rzyexnlimwf224.jpeg)
Презентация Podman на All Systems Go! 2018
Последний релиз Podman — v0.10.1.3 (от 18 октября), а последний с новыми фичами — v0.10.1 (от 12 октября), что вобрал в себя несколько новых команд и дополнительных флагов.
Код Podman написан на языке Go и распространяется на условиях свободной лицензии Apache License 2.0. Готовые для установки пакеты доступны для Fedora версии 27 и выше (есть и инструкция по установке в Ubuntu). Среди зависимых компонентов для работы Podman — такие утилиты для Linux-контейнеров, как runc и conmon, а также сетевые плагины CNI.
И запуск контейнера с Podman, и последующая работа с ним похожи на привычный сценарий использования
Для практического знакомства с Podman можно также воспользоваться соответствующим онлайн-сценарием на Katacoda: «Containers without Docker — Launching Containers using Podman and Libpod».
Наконец, отдельного упоминания достоин проект pypodman, который находится в стадии активной разработки и предлагает написанный на Python интерфейс для удалённого исполнения команд Podman.
В статье уже не раз наряду с Podman встречалось упоминание проекта libpod. В чём разница?
Если говорить о «полном» проекте Red Hat, то он в действительности называется libpod и размещён на GitHub именно под таким названием. На сегодняшний день libpod позиционируется как «библиотека для приложений, нуждающихся в работе с концепцией подов из контейнеров, популяризированной Kubernetes». А сам Podman — это утилита, входящая в состав библиотеки libpod.
Если же вернуться к более широкому взгляду на контейнеры, то у Red Hat есть своё видение, которое воплощается в жизнь целым набором утилит на все случаи жизни. Большая их часть сосредоточена в репозиториях с говорящим названием github.com/containers, и одно только это уже показывает очевидные амбиции компании (к слову, раньше некоторые из этих проектов располагались на github.com/projectatomic).
Взгляды Red Hat на стандартизацию и развитие экосистемы контейнеров сформулированы прямо в README проекта libpod:
![](https://habrastorage.org/r/w1560/webt/r7/hk/e_/r7hke_irtz2uodzez8z8e5e-yb4.png)
Мы уже писали практически обо всех этих проектах (runc, containers/image, containers/storage, CNI, conmon) в обзоре CRI-O, однако немаловажным пополнением с тех пор стала утилита для сборки образов контейнеров под названием buildah. Кроме того, у Red Hat уже есть готовые ответы и на некоторые другие потребности современного мира контейнеров, такие как udica для генерации профилей безопасности SELinux и skopeo для работы с удалёнными реестрами образов.
Подобно тому, как Red Hat стоит не только за своей enterprise-платформой для контейнеров OpenShift, но и принимает активнейшее участие в жизни «нижележащего» Open Source-проекта Kubernetes, американская компания реализует свой взгляд на современную IT-инфраструктуру и на более фундаментальном уровне — самих контейнеров, оркестровкой которых так озабочены DevOps- и SRE-инженеры. Podman и libpod — важные компоненты целой экосистемы, формируемой Red Hat в мире контейнеров на базе открытых стандартов. Если так смотреть на происходящее, то упомянутая в самом начале статьи сделка с IBM, которую преподносят как инициативу по формированию ведущего поставщика решений в области гибридных облаков, выглядит ещё интереснее в масштабах всей индустрии…
Напоследок, предлагаю небольшой опрос об информированности читателей хабры о проекте Podman до появления этой статьи. Спасибо за участие!
Читайте также в нашем блоге:
![](https://habrastorage.org/webt/hd/wj/kz/hdwjkzhgebmi5nh0kqny89ujgoi.png)
CRI-O как предыстория
Если окинуть взглядом современный мир Linux-контейнеров, то легко увидеть, что тема сегодняшней статьи является лишь одним из этапов долгосрочной стратегии Red Hat. Ярким тому подтверждением является проект CRI-O, о котором мы писали год назад. Если вкратце, то CRI-O — реализация интерфейса Kubernetes CRI (Container Runtime Interface) для запуска исполняемых сред контейнеров, совместимых со стандартом OCI (Open Container Initiative). Если ещё короче, то это замена Docker'у в качестве runtime для Kubernetes. (Схожая в техническом смысле инициатива для K8s со стороны компании Docker Inc — cri-containerd, о которой мы тоже писали; в той же статье есть сравнение производительности этих двух решений.)
История появления CRI-O такова, что, пока в OCI готовили стандарты для контейнеров (Runtime Specification и Image Specification) [что, впрочем, тоже происходило при участии Red Hat], в RH создали и поместили в инкубатор Kubernetes новый проект под названием OCID (Open Container Initiative Daemon), который позже [по требованию OCI] переименовали в CRI-O. Его предназначение звучало как «реализация стандартного интерфейса для исполняемой среды для контейнеров в Kubernetes», а продвижением в «технические массы» занимались в рамках более масштабного проекта Red Hat по созданию операционной системы для контейнеров — Project Atomic.
![](https://habrastorage.org/webt/ev/lg/29/evlg29gpllaqx4dpakb6viu8wtc.jpeg)
Шапки с логотипом CRI-O на KubeCon + CloudNativeCon North America 2017
За минувшее время CRI-O дозрел до версии 1.0, получил поддержку в Minikube, а его последним достижением можно считать принятие в качестве интерфейса для исполняемой среды контейнеров по умолчанию в проекте Kubic, который, что особенно примечательно, развивается сообществом конкурентного (для Red Hat) Linux-дистрибутива — openSUSE.
Возвращаясь к теме статьи: Podman изначально был частью CRI-O.
Появление и суть Podman
Официальный анонс проекта Podman (название является сокращением от «pod manager») состоялся в феврале этого года:
«Podman (ранее известный как kpod) существовал с прошлого лета. Изначально он являлся частью проекта CRI-O. Мы выделили podman в отдельный проект — libpod. Мы хотели, чтобы и Podman, и CRI-O развивались со своей скоростью. Оба отлично работают и по отдельности (как независимые утилиты), и вместе».
По этой причине сам анонс был озаглавлен как «повторное представление» (reintroduction). А первый публичный релиз Podman — v0.2 — состоялся за 2 недели до этого анонса. Итак, в чём же суть Podman?
Цель Podman — предоставить консольный интерфейс для запуска контейнеров вне системы оркестровки. Примечательно, что запускаемые контейнеры могут быть объединены в специальные группы с общими пространствами имён, т.е. поды (pods) — эта концепция уже стала хорошо известной благодаря Kubernetes. Проект следует идеологии UNIX-команд, где каждая утилита делает лишь одну вещь, но хорошо. Другая важная деталь, которую неустанно подчёркивают разработчики, уже была процитирована выше в анонсе: Podman может использоваться как вместе с CRI-O, так и независимо от него.
В целом же основная задумка Podman заключается в том, чтобы предоставить пользователям Kubernetes, выбравшим CRI-O в качестве исполняемой среды для контейнеров, аналог консольного интерфейса Docker CLI (для взаимодействия с контейнерами и образами, запущенными в кластерах):
«Podman реализует 38 из 40 команд Docker CLI, определённых в Docker 1.13 (на момент анонса в феврале — прим. перев.), но некоторые из них мы специально не повторяли. Например, связанные с Docker Swarm — вместо этого для подов/контейнеров, нуждающихся в оркестровке, мы предлагаем использовать Kubernetes. Также не были реализованы некоторые команды для Docker Plugins вроде плагинов томов и для сети. Полный список команд Podman и их эквивалентов в Docker можно найти на странице Podman Usage Transfer».
![](https://habrastorage.org/webt/a-/tm/uo/a-tmuolifndysjinywi1xj16wf8.png)
Фрагмент таблицы сравнения команд Docker и Podman: большинство из них совпадают, но встречаются и отличия
Однако за этой видимой идентичностью в интерфейсе кроется принципиальная разница в архитектуре: если Docker CLI для выполнения команд общается с демоном Docker, то Podman — самостоятельная утилита, не требующая никаких демонов для своей работы.
Как минимум из-за этого архитектурного отличия будет более корректным сравнивать Podman не с Docker как таковым, а с crictl — консольной утилитой из состава cri-tools (он используется, в частности, для интеграции containerd с Kubernetes). И здесь есть функциональные отличия: Podman может перезапускать остановленные контейнеры, а также обеспечивает управление образами контейнеров. (Более подробное сравнение см. в блоге OpenShift. )
С релизом Fedora 28 Atomic Host (май этого года) Podman стал инструментом этого Linux-дистрибутива по умолчанию для управления контейнерами. И только совсем недавно, в сентябре, на Linux-конференции All Systems Go! в Берлине Dan Walsh, руководитель команды Red Hat Container Engineering, представил Podman ещё более широкой публике — запись выступления можно увидеть здесь (а только презентацию — здесь).
![](https://habrastorage.org/webt/33/tb/qx/33tbqxv_zc2u_rzyexnlimwf224.jpeg)
Презентация Podman на All Systems Go! 2018
Технические примечания
Последний релиз Podman — v0.10.1.3 (от 18 октября), а последний с новыми фичами — v0.10.1 (от 12 октября), что вобрал в себя несколько новых команд и дополнительных флагов.
Код Podman написан на языке Go и распространяется на условиях свободной лицензии Apache License 2.0. Готовые для установки пакеты доступны для Fedora версии 27 и выше (есть и инструкция по установке в Ubuntu). Среди зависимых компонентов для работы Podman — такие утилиты для Linux-контейнеров, как runc и conmon, а также сетевые плагины CNI.
И запуск контейнера с Podman, и последующая работа с ним похожи на привычный сценарий использования
docker
:$ sudo podman run -dt -e HTTPD_VAR_RUN=/var/run/httpd -e HTTPD_MAIN_CONF_D_PATH=/etc/httpd/conf.d \
-e HTTPD_MAIN_CONF_PATH=/etc/httpd/conf \
-e HTTPD_CONTAINER_SCRIPTS_PATH=/usr/share/container-scripts/httpd/ \
registry.fedoraproject.org/f27/httpd /usr/bin/run-httpd
$ sudo podman ps
...
$ sudo podman inspect -l
...
$ sudo podman logs --latest
10.88.0.1 - - [07/Feb/2018:15:22:11 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.55.1" "-"
10.88.0.1 - - [07/Feb/2018:15:22:30 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.55.1" "-"
10.88.0.1 - - [07/Feb/2018:15:22:30 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.55.1" "-"
10.88.0.1 - - [07/Feb/2018:15:22:31 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.55.1" "-"
10.88.0.1 - - [07/Feb/2018:15:22:31 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.55.1" "-"
$ sudo podman top <container_id>
UID PID PPID C STIME TTY TIME CMD
0 31873 31863 0 09:21 ? 00:00:00 nginx: master process nginx -g daemon off;
101 31889 31873 0 09:21 ? 00:00:00 nginx: worker process
Для практического знакомства с Podman можно также воспользоваться соответствующим онлайн-сценарием на Katacoda: «Containers without Docker — Launching Containers using Podman and Libpod».
Наконец, отдельного упоминания достоин проект pypodman, который находится в стадии активной разработки и предлагает написанный на Python интерфейс для удалённого исполнения команд Podman.
Не только Podman: libpod и экосистема
В статье уже не раз наряду с Podman встречалось упоминание проекта libpod. В чём разница?
Если говорить о «полном» проекте Red Hat, то он в действительности называется libpod и размещён на GitHub именно под таким названием. На сегодняшний день libpod позиционируется как «библиотека для приложений, нуждающихся в работе с концепцией подов из контейнеров, популяризированной Kubernetes». А сам Podman — это утилита, входящая в состав библиотеки libpod.
Если же вернуться к более широкому взгляду на контейнеры, то у Red Hat есть своё видение, которое воплощается в жизнь целым набором утилит на все случаи жизни. Большая их часть сосредоточена в репозиториях с говорящим названием github.com/containers, и одно только это уже показывает очевидные амбиции компании (к слову, раньше некоторые из этих проектов располагались на github.com/projectatomic).
Взгляды Red Hat на стандартизацию и развитие экосистемы контейнеров сформулированы прямо в README проекта libpod:
![](https://habrastorage.org/webt/r7/hk/e_/r7hke_irtz2uodzez8z8e5e-yb4.png)
Мы уже писали практически обо всех этих проектах (runc, containers/image, containers/storage, CNI, conmon) в обзоре CRI-O, однако немаловажным пополнением с тех пор стала утилита для сборки образов контейнеров под названием buildah. Кроме того, у Red Hat уже есть готовые ответы и на некоторые другие потребности современного мира контейнеров, такие как udica для генерации профилей безопасности SELinux и skopeo для работы с удалёнными реестрами образов.
Резюмируя
Подобно тому, как Red Hat стоит не только за своей enterprise-платформой для контейнеров OpenShift, но и принимает активнейшее участие в жизни «нижележащего» Open Source-проекта Kubernetes, американская компания реализует свой взгляд на современную IT-инфраструктуру и на более фундаментальном уровне — самих контейнеров, оркестровкой которых так озабочены DevOps- и SRE-инженеры. Podman и libpod — важные компоненты целой экосистемы, формируемой Red Hat в мире контейнеров на базе открытых стандартов. Если так смотреть на происходящее, то упомянутая в самом начале статьи сделка с IBM, которую преподносят как инициативу по формированию ведущего поставщика решений в области гибридных облаков, выглядит ещё интереснее в масштабах всей индустрии…
Напоследок, предлагаю небольшой опрос об информированности читателей хабры о проекте Podman до появления этой статьи. Спасибо за участие!
P.S.
Читайте также в нашем блоге:
- «CRI-O — альтернатива Docker для запуска контейнеров в Kubernetes»;
- «Интеграция containerd с Kubernetes, заменяющая Docker, готова к production»;
- «В чём суть проекта Moby и почему главным репозиторием Docker вдруг стал moby/moby?»;
- «Linux-дистрибутив from scratch для сборки Docker-образов — наш опыт с dappdeps»;
- «Самый маленький Docker-образ — меньше 1000 байт»;
- «Container Networking Interface (CNI) — сетевой интерфейс и стандарт для Linux-контейнеров».
Only registered users can participate in poll. Log in, please.
Ваша информированность о Podman (до этой статьи):
92.32% Первый раз слышу613
6.93% Случайные упоминания без погружения46
0.15% Теоретическое знакомство1
0.45% Практические эксперименты3
0.15% Реальное использование (в production или близко)1
664 users voted. 66 users abstained.