Red Hat заменяет Docker на Podman

Понятно, что в настоящий момент страсти вокруг Red Hat имеют совсем другой и весьма глобальный фокус ^[1], но мы всё же о своём — локальном и прикладном из мира контейнеров. С начала этого года в Red Hat активно трудятся над заменой для Docker под названием Podman ^[2] (или libpod ^[3]). Об этом проекте ещё почему-то не писали на хабре, а ведь сейчас весьма подходящее время для того, чтобы познакомиться с ним, узнать о его истоках и подумать о перспективах. Поехали!

CRI-O как предыстория

Если окинуть взглядом современный мир Linux-контейнеров, то легко увидеть, что тема сегодняшней статьи является лишь одним из этапов долгосрочной стратегии Red Hat. Ярким тому подтверждением является проект CRI-O ^[4], о котором мы писали ^[5] год назад. Если вкратце, то CRI-O — реализация интерфейса Kubernetes CRI (Container Runtime Interface) для запуска исполняемых сред контейнеров, совместимых со стандартом OCI (Open Container Initiative). Если ещё короче, то это замена Docker'у в качестве runtime для Kubernetes. (Схожая в техническом смысле инициатива для K8s со стороны компании Docker Inc — cri-containerd ^[6], о которой мы тоже писали ^[7]; в той же статье есть сравнение производительности этих двух решений.)

История появления CRI-O такова, что, пока в OCI готовили стандарты для контейнеров (Runtime Specification ^[8] и Image Specification ^[9]) [что, впрочем, тоже происходило при участии Red Hat], в RH создали и поместили в инкубатор Kubernetes новый проект под названием OCID (Open Container Initiative Daemon), который позже [по требованию OCI] переименовали в CRI-O. Его предназначение звучало как «реализация стандартного интерфейса для исполняемой среды для контейнеров в Kubernetes», а продвижением в «технические массы» занимались в рамках более масштабного проекта Red Hat по созданию операционной системы для контейнеров — Project Atomic ^[10].

Шапки ^[11] с логотипом CRI-O на KubeCon + CloudNativeCon North America 2017

За минувшее время CRI-O дозрел до версии 1.0 ^[12], получил ^[13] поддержку в Minikube, а его последним достижением можно считать принятие ^[14] в качестве интерфейса для исполняемой среды контейнеров по умолчанию в проекте Kubic ^[15], который, что особенно примечательно, развивается сообществом конкурентного (для Red Hat) Linux-дистрибутива — openSUSE.

Возвращаясь к теме статьи: Podman изначально был частью CRI-O.

Появление и суть Podman

Официальный анонс проекта Podman (название является сокращением от «pod manager») состоялся ^[16] в феврале этого года:

«Podman (ранее известный как kpod) существовал с прошлого лета. Изначально он являлся частью проекта CRI-O ^[17]. Мы выделили podman в отдельный проект — libpod ^[3]. Мы хотели, чтобы и Podman, и CRI-O развивались со своей скоростью. Оба отлично работают и по отдельности (как независимые утилиты), и вместе».

По этой причине сам анонс был озаглавлен как «повторное представление» (reintroduction). А первый публичный релиз Podman — v0.2 ^[18] — состоялся за 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 ^[19]».

Фрагмент таблицы сравнения команд Docker и Podman: большинство из них совпадают, но встречаются и отличия

Однако за этой видимой идентичностью в интерфейсе кроется принципиальная разница в архитектуре: если Docker CLI для выполнения команд общается с демоном Docker, то Podman — самостоятельная утилита, не требующая никаких демонов для своей работы.

С релизом ^[20] Fedora 28 Atomic Host (май этого года) Podman стал инструментом этого Linux-дистрибутива по умолчанию для управления контейнерами. И только совсем недавно, в сентябре, на Linux-конференции All Systems Go! в Берлине Dan Walsh, руководитель команды Red Hat Container Engineering, представил Podman ещё более широкой публике — запись выступления можно увидеть здесь ^[21] (а только презентацию — здесь ^[22]).

Презентация Podman на All Systems Go! 2018

Технические примечания

Последний релиз Podman — v0.10.1.3 ^[23] (от 18 октября), а последний с новыми фичами — v0.10.1 ^[24] (от 12 октября), что вобрал в себя несколько новых команд и дополнительных флагов.

Код Podman написан на языке Go и распространяется на условиях свободной лицензии Apache License 2.0. Готовые для установки пакеты доступны для Fedora версии 27 и выше (есть и инструкция ^[25] по установке в Ubuntu). Среди зависимых компонентов для работы Podman — такие утилиты для Linux-контейнеров, как runc ^[26] и conmon ^[27], а также сетевые плагины CNI ^[28].

И запуск контейнера с 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 ^[29], который находится в стадии активной разработки и предлагает написанный на Python интерфейс для удалённого исполнения команд Podman.

Не только Podman: libpod и экосистема

В статье уже не раз наряду с Podman встречалось упоминание проекта libpod. В чём разница?

Если говорить о «полном» проекте Red Hat, то он в действительности называется libpod и размещён на GitHub ^[3] именно под таким названием. На сегодняшний день libpod позиционируется как «библиотека для приложений, нуждающихся в работе с концепцией подов из контейнеров, популяризированной Kubernetes». А сам Podman — это утилита, входящая в состав библиотеки libpod.

Если же вернуться к более широкому взгляду на контейнеры, то у Red Hat есть своё видение, которое воплощается в жизнь целым набором утилит на все случаи жизни. Большая их часть сосредоточена в репозиториях с говорящим названием github.com/containers ^[30], и одно только это уже показывает очевидные амбиции компании (к слову, раньше некоторые из этих проектов располагались на github.com/projectatomic ^[31]).

Взгляды Red Hat на стандартизацию и развитие экосистемы контейнеров сформулированы ^[32] прямо в README проекта libpod:

Мы уже писали практически обо всех этих проектах (runc, containers/image, containers/storage, CNI, conmon) в обзоре CRI-O ^[5], однако немаловажным пополнением с тех пор стала утилита для сборки образов контейнеров под названием buildah ^[33]. Кроме того, у Red Hat уже есть готовые ответы и на некоторые другие потребности современного мира контейнеров, такие как udica ^[34] для генерации профилей безопасности SELinux и skopeo ^[35] для работы с удалёнными реестрами образов.

Резюмируя

Подобно тому, как Red Hat стоит не только за своей enterprise-платформой для контейнеров OpenShift, но и принимает активнейшее участие в жизни «нижележащего» Open Source-проекта Kubernetes, американская компания реализует свой взгляд на современную IT-инфраструктуру и на более фундаментальном уровне — самих контейнеров, оркестровкой которых так озабочены DevOps- и SRE-инженеры. Podman и libpod — важные компоненты целой экосистемы, формируемой Red Hat в мире контейнеров на базе открытых стандартов. Если так смотреть на происходящее, то упомянутая в самом начале статьи сделка с IBM, которую преподносят ^[36] как инициативу по формированию ведущего поставщика решений в области гибридных облаков, выглядит ещё интереснее в масштабах всей индустрии…

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

P.S.

Читайте также в нашем блоге:

• «CRI-O — альтернатива Docker для запуска контейнеров в Kubernetes ^[5]»;
• «Интеграция containerd с Kubernetes, заменяющая Docker, готова к production ^[7]»;
• «В чём суть проекта Moby и почему главным репозиторием Docker вдруг стал moby/moby? ^[37]»;
• «Linux-дистрибутив from scratch для сборки Docker-образов — наш опыт с dappdeps ^[38]»;
• «Самый маленький Docker-образ — меньше 1000 байт ^[39]»;
• «Container Networking Interface (CNI) — сетевой интерфейс и стандарт для Linux-контейнеров ^[40]».

Автор: shurup

Источник ^[41]