Контейнерная виртуализация в 2020: Podman vs Docker

Рхел 8 для нас все еще недостаточно стабилен :) Поэтому докер под 7й шапкой. При миграции на 8 будем смотреть; вероятно, будет OCI со своей обвязкой/containerd

Я юзаю podman, потому что docker не может многократно ресторнуть единожды чекпойнтнутый контейнер, а красношляпые не заметили, что докер это не осилил, и как-то взяли и запилили. Но я не облачное существо.

Рхел 8 для нас все еще недостаточно стабилен :)

А сколько надо в пойнтрелизах, и для чего?

Да шутка это была. Мы стали заложниками своего папета. Очень много version-specific вещей, включая фиксацию конкретных версий библиотек (тут еще быдлокода немного и заброшенные проекты, которые тем не менее должны работать). Короче, где-то в марте-апреле мы наконец-то избавились от 5 в продакшене. А шестой вообще не появилось. Потиху идет миграция в контейнеры, но это возможно далеко не на всех проектах (тут и требования к ресурсам, и архитектура, и, главное, за их переписывание никто не хочет платить).

Какие преимущества/грабли/синяя изолента возникают при переходе на OCI (podman)?

Плюсы: rootless-режим для локальной разработки и интеграция с systemd при желании раздеплоить контейнеризованный сервис не заморачиваясь с облаками.

Минусы: если рабочий процесс был выстроен вокруг docker swarm, то исправлять это сложно. Но вообще всё равно нужно, потому что будущего у docker swarm нет в том числе и в самом докере.

Выбор между Podman без демона и Docker с демоном. Мне идеологически больше нравится Podman, конечно, но куда девать какой-нибудь Traefik в конфигурации, работающий через сокет Docker? Мои велосипеды ещё Watchtower автоматически пуллит и перезапускает, опять же, через сокет Docker. Бекапилка тоже вызывает pre-hook для Restic с помощью сокета Docker.

Мне идеологически больше нравится Podman, конечно, но куда девать какой-нибудь Traefik в конфигурации, работающий через сокет Docker? Мои велосипеды ещё Watchtower автоматически пуллит и перезапускает, опять же, через сокет Docker. Бекапилка тоже вызывает pre-hook для Restic с помощью сокета Docker.

++

Поставил podman-docker и все взлетело

многократно ресторнуть единожды чекпойнтнутый контейнер

Ты юзаешь CRIU?

Да.

А, в целом, что с производительностью? ЕМНИП Вы писали о просадках из-за слоев?

у подмана вроде поддержку сокетов тоже завезли.

Но на самом деле идеологически правильные решения тем и хороши что они прямее, и делать из них копию костыльных неправильных решений неинтересно.

Не, это была не я. Я никаких просадок не замечаю, но я их и не ищу.

Там кажется речь была про формат файловой системы для контейнера. overlayfs и т.п. Но он уже с тех пор по-моему дважды поменялся, так надо заново холиварить.

Но на самом деле идеологически правильные решения тем и хороши что они прямее, и делать из них копию костыльных неправильных решений неинтересно.

Идеологическая правильность — это, конечно, хорошо, но что делать с реальными конкретными задачами, в которых изнутри контейнера или из непривилегированной программы нужно взаимодействовать с контейнерным движком?

Там кажется речь была про формат файловой системы для контейнера. overlayfs и т.п. Но он уже с тех пор по-моему дважды поменялся, так надо заново холиварить.

Это не формат файловой системы. Overlayfs — это виртуальная файловая система, позволяющая накладывать друг на друга несколько каталогов; наследник AUFS. Она используется всеми докероподобными, чтобы хранить слои на диске в виде пофайловых дельт и реконструировать итоговую ФС непосредственно при запуске контейнера.

Я так понимаю, речь идёт о том, что из rootless-режима нельзя использовать overlayfs, потому что это обычная ядерная ФС. В Podman для этого написали костыль — FUSE-вариант overlayfs, но поскольку это FUSE, оно существенно тормозит.

С сетью там примерно то же самое: поскольку без рута нельзя настраивать виртуальные интерфейсы, iptables и ещё много чего, написали костыль под названием slirp4netns, который представляет собой тупо сетевой стек в юзерспейсе поверх TUN/TAP. Проблемы те же — тормоз.

В результате rootless контейнер больше не является zero-cost абстракцией.

Читать http://docs.podman.io/en/latest/_static/api.html

Ну то есть там и говорится о том, что у подмана есть эмуляция docker.sock. А я тебя спрашиваю, как решить такую задачу идеологически правильными решениями?

Надо смотреть на уровень выше, откуда пришла задача.

С чего бы спрашивается приложению из контейнера требовалось управлять контейнерным движком.

А который из них дохрена дискового пространства не жрёт? Мы мимо докера из-за этого ходим уже который год. При том, что он в коммерческой разработке уже изо всех щелей торчит, по ходу.

А мониторинг Docker-демона, веб-панели управления всякие? cAdvisor-ы там, я не знаю что ещё?

Или они не так работают?

Контейнеры используются одни и те же, что в Podman, что в Docker.

Дисковое пространство прямо зависит от собранного контейнера. Может пару килобайт с помощью scratch (то есть без дистрибутива), может целая CentOS/Debian на пару гигабайт завёрнутая.

Или они не так работают?

Я не знаю подробностей, но в целом это задача не podman, а cri-o.

https://www.openshift.com/blog/crictl-vs-podman

Podman - это собиралка и запускалка контейнеров, а не система оркестрации, поэтому «идеологически правильно» не использовать его для построения систем, где это необходимо.

В случае с контейнерами запущенными через podman, это обычные пользовательские процессы, и мониторинг и оркестрацию идеологически правильно делать стандартными системными средствами типа ansible и systemd, а не костылить на скриптах свой аналог kubernetes.

Ну главная проблема в том, что приходится это на одном разделе держать, и менеджится оно автоматически.

Я не знаю подробностей, но в целом это задача не podman, а cri-o.

CRI-O — это адаптер между двумя слоями абстракции. CRI — это такой зверь, который существует только внутри Kubernetes и снаружи Kubernetes он никому особо не нужен.

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

Podman - это собиралка и запускалка контейнеров, а не система оркестрации, поэтому «идеологически правильно» не использовать его для построения систем, где это необходимо.

Да, только уж так получилось, что Docker-подобные контейнеры имеют свою внутреннюю сеть (или несколько), свой файрволл, свои дисковые тома, свой DNS и своё внутреннее всё. Поэтому говорить «ну это всего лишь запускалка, а не оркестрация, оркестрируйтесь как-нибудь сами» — не очень правдиво.

В случае с контейнерами запущенными через podman, это обычные пользовательские процессы, и мониторинг и оркестрацию идеологически правильно делать стандартными системными средствами типа ansible и systemd

Не понятно, при чём тут оркестрация, и как связаны названные тобой инструменты с мониторингом. :)

Я задал два конкретных вопроса: как в этом новом мире нужно извлекать метрики, которые раньше извлекались из Docker-демона, и как в этом новом мире нужно писать софт, который бы предоставлял UI к контейнерному движку?

а не костылить на скриптах свой аналог kubernetes.

То есть позиция состоит в том, что ничего кроме Kubernetes в мире не существует? А зачем тогда нужен отдельный podman, если он как бы есть, но как бы и такой немного ущербный и second-class citizen? Остановились бы на libpod и CRI-O.

То есть я это к чему: Docker, конечно, весь из себя не такой, но как это водится у коммерчески успешных стартапов, они отлично видят пользовательский юзкейс: контейнеры плюс легковесная автономная оркестрация для случаев, когда Kubernetes — это оверкилл. А вся эта движуха вокруг Podman — она отдаёт академичностью в худшем смысле этого слова: мы сделаем идеологически идеальную систему, ну а то что она неюзабельна и не решает половины пользовательских задач, это нас уже не волнует, покупайте опеншифт.

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

Мониторинг и оркестрация контейнеров - не пользовательская задача.

То есть позиция состоит в том, что ничего кроме Kubernetes в мире не существует? А зачем тогда нужен отдельный podman, если он как бы есть, но как бы и такой немного ущербный и second-class citizen?

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

То есть я это к чему: Docker, конечно, весь из себя не такой, но как это водится у коммерчески успешных стартапов, они отлично видят пользовательский юзкейс: контейнеры плюс легковесная автономная оркестрация для случаев, когда Kubernetes — это оверкилл. А вся эта движуха вокруг Podman — она отдаёт академичностью в худшем смысле этого слова: мы сделаем идеологически идеальную систему, ну а то что она неюзабельна и не решает половины пользовательских задач, это нас уже не волнует, покупайте опеншифт.

Во-первых ты в корне неверно представляешь себе ситуацию с докером.

Docker - не является успешным коммерческим стартапом. Он является стартапом набравшим множество инвестиций и пробившим некоторый путь для других, но при этом так и не сумевшим найти способ собственной монетизации. Одна из причин - собственно плохой дизайн решений.

Поэтому Docker Swarm - это не конкурирующая технология, это уже мертвая технология. Компания Docker уже прикрыла проекты с ним связанные и продала эту часть бизнеса Мирантису.

То, что кто-то продолжает использовать swarm - это инерция, которая разумеется продлится ещё не один год, но для построения новых решений использовать swarm сейчас в принципе нелогично.

А во-вторых, ты банально передергиваешь.

Вопрос изначально был задан в рамках «идеологически правильных» подходов. Поэтому да, внезапно, ответы на такие вопросы отдают «академичностью».

Мониторинг и оркестрация контейнеров - не пользовательская задача.

Ну это уже шлангование. Очевидно, бывают разные уровни «пользовательскости». Пользователь контейнерного движка — это продуктовый разработчик, админ или опс. Ни одного из них внутренняя кухня куба не интересует, поэтому CRI-O в принципе не может быть релевантно в контексте этого разговора.

Во-первых ты в корне неверно представляешь себе ситуацию с докером.

Я достаточно хорошо себе её представляю. Возможно, я неточно выразился по поводу «коммерческой успешности». Давай скажем «очень популярный, практически захвативший индустрию продукт».

<…> но при этом так и не сумевшим найти способ собственной монетизации. Одна из причин - собственно плохой дизайн решений.

Вот тут на самом деле можно очень зло пошутить. Плохой дизайн решений: они слишком хорошо работают искаропки и не требуют покупки коммерческой поддержки на каждый чих, поэтому и не монетизируются ;)

Поэтому Docker Swarm - это не конкурирующая технология, это уже мертвая технология. Компания Docker уже прикрыла проекты с ним связанные и продала эту часть бизнеса Мирантису.

Про Swarm вообще речи не было. Я могу подробнее рассказать, о каком сорте юзкейсов я говорю (но для этого нужно, чтобы собеседник вообще имел желание слушать).

Вопрос изначально был задан в рамках «идеологически правильных» подходов. Поэтому да, внезапно, ответы на такие вопросы отдают «академичностью».

Обычно предполагается, что идеологически правильное решение сложнее, но всё равно применимо в реальном мире. А названное тобой не просто отдаёт академичностью, а насквозь академично: пригодно только для того, чтобы повесить его на стенку и любоваться, а работу всё равно делать через сраный докер.

Очевидно, бывают разные уровни «пользовательскости». Пользователь контейнерного движка — это продуктовый разработчик, админ или опс. Ни одного из них внутренняя кухня куба не интересует, поэтому CRI-O в принципе не может быть релевантно в контексте этого разговора.

Сформулируй use-case, когда их должен интересовать долгоживущий мониторинг контейнеров на локальном контейнерном движке.

Я могу подробнее рассказать, о каком сорте юзкейсов я говорю (но для этого нужно, чтобы собеседник вообще имел желание слушать).

Ещё желательно хамить перестать, и тогда может быть получится интересно побеседовать.

А названное тобой не просто отдаёт академичностью, а насквозь академично: пригодно только для того, чтобы повесить его на стенку и любоваться, а работу всё равно делать через сраный докер.

А то я не переводила разработку на использование контейнеров и не знаю как оно может работать.

Фишка в том что изначально docker пошёл по пути - мы выполним все пожелания разработчика, а что потом с этим делать на проде - это головная боль админов. Понятно что разработчикам такой подход очень понравился и они внедрили его везде куда дотянулись. Отсюда полный маркетинговый успех.

И отсюда получились эти девелоперские окружения на swarm, в которых кроме собственно приложения ещё пятьсот тысяч оберток и системных сервисов по типу «всё своё ношу с собой». Раньше такое делали на make и bash, а теперь вот докер ухудшил эту ситуацию в разы.

А потом пришёл реальный мир, и выяснилось что разработчики вообще-то во-первых не умеют работать с системными сервисами и все их встроенные в окружения штуки работают не так как должны работать прод-сервера, а во-вторых, что у прода есть ещё критерии кроме удобства разработчика и они не менее важны. Поэтому вместо того чтобы взять «готовое» ops-ам и devops приходится это готовое распутывать обратно, убирать захардкоженные DNS и прочие костыли, и внедрять в продакшен-окружение чистые приложения без оберток.

Повторюсь, это проблема не контейнеров как таковых а культуры разработки. Контейнеры её просто усугубили.

Сейчас есть надежда что этот маятник двинулся немножко в другую сторону, где до многих вдруг дошло что инфру разработки должен диктовать прод, а не разработчик. Поэтому во многих проектах, где прод использует k8s, сейчас например dev-окружение разработчика - это такой же деплой в тот же k8s с теми же опциями и под тем же load balancer.

Возможны ли другие варианты прода? Да, возможны. Например, как я описала выше, статичные systemd-сервисы с выкаткой через ansible и обзором хоть через тот же cockpit.

Бывает ли что-то среднее? В принципе наверное можно написать морду к cri «попроще» чем k8s. Но ни podman ни docker тут большой роли не играют. Там надо смотреть на уровень ниже.