Понятно, что в настоящий момент страсти вокруг Red Hat имеют совсем другой и весьма глобальный фокус, но мы всё же о своём — локальном и прикладном из мира контейнеров. С начала этого года в Red Hat активно трудятся над заменой для Docker под названием Podman (или libpod). Об этом проекте ещё почему-то не писали на хабре, а ведь сейчас весьма подходящее время для того, чтобы познакомиться с ним, узнать о его истоках и подумать о перспективах. Поехали!
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.
Шапки с логотипом 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».
Фрагмент таблицы сравнения команд Docker и Podman: большинство из них совпадают, но встречаются и отличия
Однако за этой видимой идентичностью в интерфейсе кроется принципиальная разница в архитектуре: если Docker CLI для выполнения команд общается с демоном Docker, то Podman — самостоятельная утилита, не требующая никаких демонов для своей работы.
С релизом Fedora 28 Atomic Host (май этого года) Podman стал инструментом этого Linux-дистрибутива по умолчанию для управления контейнерами. И только совсем недавно, в сентябре, на Linux-конференции All Systems Go! в Берлине Dan Walsh, руководитель команды Red Hat Container Engineering, представил Podman ещё более широкой публике — запись выступления можно увидеть здесь (а только презентацию — здесь).
Презентация 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
Отдельного упоминания достоин проект 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:
Мы уже писали практически обо всех этих проектах (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-контейнеров».
Автор: shurup
