Системное администрирование, IT-инфраструктура, DevOps, Блог компании Флант, Open source
Если окинуть взглядом современный мир 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 (название является сокращением от «pod manager») состоялся в феврале этого года:
По этой причине сам анонс был озаглавлен как «повторное представление» (reintroduction). А первый публичный релиз Podman — v0.2 — состоялся за 2 недели до этого анонса. Итак, в чём же суть Podman?
Цель Podman — предоставить консольный интерфейс для запуска контейнеров вне системы оркестровки. Примечательно, что запускаемые контейнеры могут быть объединены в специальные группы с общими пространствами имён, т.е. поды (pods) — эта концепция уже стала хорошо известной благодаря Kubernetes. Проект следует идеологии UNIX-команд, где каждая утилита делает лишь одну вещь, но хорошо. Другая важная деталь, которую неустанно подчёркивают разработчики, уже была процитирована выше в анонсе: Podman может использоваться как вместе с CRI-O, так и независимо от него.
В целом же основная задумка Podman заключается в том, чтобы предоставить пользователям Kubernetes, выбравшим CRI-O в качестве исполняемой среды для контейнеров, аналог консольного интерфейса Docker CLI (для взаимодействия с контейнерами и образами, запущенными в кластерах):
Фрагмент таблицы сравнения команд 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 ещё более широкой публике — запись выступления можно увидеть здесь (а только презентацию — здесь).
Презентация 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:
Мы уже писали практически обо всех этих проектах (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 до появления этой статьи. Спасибо за участие!
Читайте также в нашем блоге:
Red Hat заменяет Docker на Podman +64
97
26000
Понятно, что в настоящий момент страсти вокруг 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 — самостоятельная утилита, не требующая никаких демонов для своей работы.
Как минимум из-за этого архитектурного отличия будет более корректным сравнивать 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 ещё более широкой публике — запись выступления можно увидеть здесь (а только презентацию — здесь).
Презентация 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:
Мы уже писали практически обо всех этих проектах (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-контейнеров».
Вы можете помочь и перевести немного средств на развитие сайта
Спасибо за статью. Всё ещё временами путаю CRI-O с CRIU (Checkpoint/Restore In Userspace).
А вот кто проголосовал за «Реальное использование (в production или близко)» — подскажите плз, чем оно лучше докера и стоит ли начать думать об экспериментах с миграцией?
Все эти Docker'ы нужны только для кривого софта способного работать только на побитовых копиях ОС разработчиков. Как следствие вместо повышения качества софта создается целая экосистема костылей. В начале был Docker сейчас podman, через года два еще что-то увидим.
Сами по себе эти технологии пустые и затраты на внедрение\обслуживание не окупаются просто потому, что гораздо выгоднее софт научиться нормально писать, чем нанять целый отдел DevOps'ов который будет весь этот ужас обслуживать.
И да, Docker популярен только там где люди пишут только на скриптовых языках. В нормальных компилируемых потребность в нем отсутствует. Нет можно конечно упороться и запихнуть в него софт, но зачем?
>Это все очень круто и здорово пока у вас части приложения не требуют разных версий библиотек ставящихся через пакетный менеджер, который ставит только одну
Значит это или плохо написанное приложение или хреновый пакетный менеджер если в нем такие проблемы есть. Другого не дано.
Да и новые версии библиотек не просто так выпускают. Часто в них дыры и ошибки находят. Согласно логике фанатов Докера предлагается вместо решения задачи обновления версий библиотек просто засунуть все в контейнер и надеяться, что оно как-то обойдется. Великолепная логика!
Пока дураки жмут штангу фанаты Docker катают ее по полу и смеются.
Это все очень круто и здорово пока у вас части приложения не требуют разных версий библиотек ставящихся через пакетный менеджер, который ставит только одну. Не говоря уже о том что раздельные окружения менее зависимы друг от друга и ими проще управлять. Я уже молчу что разбив на все это на детальки, можно масштабировать одни части и не трогать другие.
Вы поймете все неудобства когда вам придется компилировать два приложения требующих разные версии библиотек. И нет, даже компилируему приложению может понадобиться бд/редис/что то еще что может быть неудобно ставить/настраивать в том же окружении.
Не понимаю вашего скепсиса.
Затраты на обслуживание/внедрение окупаются когда у вас 10 кодеров вместо одного дорогого системщика и сервис надо масштабировать на большое количество людей.
а что мне помешает использовать старую какую-нибудь старую 100 лет известную виртуализацию (kvm/openvz и тд) вместо докера?
Мешают значительно большие накладные расходы на эту «старую» виртуализацию.
OpenVZ — это те же контейнеры. Только с хранением состояния, т.е. аналоги виртуальных машин, только они легковснее и + в принципе все плюсы и минусы контейнеров.
Т.е. если вернуться к теме вопроса
> а что мне помешает использовать старую какую-нибудь старую 100 лет известную виртуализацию (kvm/openvz и тд) вместо докера?
Ну с виртуалками будет просто долго, потому как они большие и производительность, как вы сказали будет ниже через дополнительные слои абстракий. С openvz — потому что он не мейнстрим, а с Docker все получится, потому что он чертовски популярен.
Есть еще lxd, там тоже состояние сохраняется и можно разворачивать немодифицированный rootfs. По расходам — примерно +- тот же самый докер.
Да, суть почти та же. Но он не також популярный и скорее замена простым виртуалкам.
Docker контейнер потребляет столько памяти, сколько ему сейчас нужно. Может занимать и освобождать память. KVM виртуалка требует отвести память заранее. Её можно увеличивать путём удваивания (но это небыстро), а освобождать вообще нельзя.
Docker стартует моментально, виртуалка грузится.
Docker имеет ядро одно на всех, виртуалки каждая — своё, и они поддерживают кучу внутренних состояний, которые в виртуалке нафиг не нужны.
Docker использует системное IO, виртуалка даже с virtio вынуждена что-то трансформировать и переорганизовывать.
Docker умеет централизованно обновляться из репы, виртуалки каждая по-своему.
Docker compose и swarm умеют такое, под что на виртуалках отдельный человек необходим.
Так можно продолжать очень долго. Эпоха кручения серверов в виртуалках ушла*. Учите Docker.
* кроме некоторых особых случаев безопасности. И Windows.
И в windows есть контейнера и не только Hyper-V, так что можно вычеркивать)
Одно другому никак не противоречит. Облака на виртуалках, потому что альтернатив у них нет — изоляция нужная же какая-то. Но вот все, кто повыше сидят, с виртуалок слезли на контейнера и эпоха действительно прошла. Очень забавно в этом всем видеть таких как vmware, которые всеми ногами и руками впихывают в свою архитектуру контейнеры где-то сбоку криво и косо, лишь бы вписалось как-то в существующий стек.
> Docker использует системное IO, виртуалка даже с virtio вынуждена что-то трансформировать и переорганизовывать.
нет. Докер дает оверхед на сеть и делает безумно сложным многие сетевые штуки, которые кое как возможно сделать на виртуалках.
Вы переборщили.
Докер использует изоляцию в ОС, то есть:
Еще раз, это важно: в случае контейнеров у вас одна ОС, которая распределяет ресурсы. А не много разных ОС. У вас прямой доступ к файловой системе, никто не пишет в ФС виртуальной машины, чтобы потом хост перенаправил блок к ФС уже реального хоста. За счет этого получается практически идеальная кооперация между компонентами, т.к. в памяти нет ничего лишнего, кроме ядра ОС и процессов внутри контейнеров. Тот же докер ничего дополнительного не проксирует (кроме запуска/остановки контейнеров).
Аналоги подобной штуки:
В виртуализации вы сразу:
Резюме: если у вас очень много контейнеров/образов, которые могут быть запущены на одной и той же ОС — контейнеры помогут вам сэкономить ресурсы.
Соглашусь с beduin01 эта проблема, что вы описали как раз и вылезает из-за того, что существующая система версионирования обычно весьма корявая, и лезет проблема dll hell, которую и решили таким «элегантным» образом. Как бы я не любил в ноде ужас с папкой node_modules, из-за того что все зависимости и лежат в этой папке, вы можете на сервере держать кучу абсолютно разных приложений на ноде, и не знать проблем. В dotnetcore тоже очень хорошо сделали версионирование и докер вроде бы не нужен.
При этом, когда я сталкиваюсь с каким-нить ruby, я понимаю, что тут Docker был просто спасением.
Так что всё зависит от средств разработки и их возможностей. Где-то нафиг не нужен докер, где-то без него не обойтись. И мне больше нравится первый вариант, тогда докер всего-лишь приятное дополнение и удобство деплоя и оркестрации. Но, можно и без него.
Спасением от bundler install --help и bundler exec --help?
В теории да, но когда требуются разные версии ruby или разные версии bundler'а — нифига не помогает.
Честно скажу, я плохо знаю руби, но проблемы с версионированием там какие-то уж очень жестокие на мой взгляд.
Докер это не только решение «dll hell», это ещё унифицированный интерфейс и снэпшот кода приложения. Независимо от рантайм окружения вы получаете одно и тоже приложение что на Ubuntu, что на CentOS, что в любом другом линукс дистрибутиве (с виндой дел не имел, не скажу).
beduin01 просто не понимает всех возможностей докера и тех задач которые он решает. Я думаю он просто не умеет им пользоваться или не сталкивался с задачами в которых придётся костыли подпирать костылями если нет докера.
Если бы всё было так красиво как он описал про компиллируемые языки, то докера бы не было и все бы писали и компиллировали, а скриптовые языки были бы малоразвиты.
Докер популярен именно потому, что он решает требуемые задачи с минимальным оверхедом и со стороны ресурсов и со стороны администрирования.
Если не сторонитесь экзотики, то NixOS
Какая-то каша у вас в голове. Если вы и впрямь считаете, что докер нужен для того, чтобы не учиться писать нормально софт, то это значит, что вы вообще не в теме и размышляете о том, в чём не разбираетесь.
Даже не знаю, как можно комментировать фразу «как следствие вместо повышения качества софта создается целая экосистема костылей» — так можно о всём техническом прогрессе сказать, что автомобили созданы для того, чтобы не ходить «нормально» пешком.
Именно! А компьютеры созданы ленивыми людьми, которые так и не освоили двоичный счёт.
Двоичный счёт тут причём? Первые компьютеры десятичными были. И где-то до 80х использовались двоично-десятичные числа (даже в x86 они есть, хотя мало какие программы их используют)
Компьютеры первой-второй волны работали только двоичных на float'ах, потому что считать надо, а битов было мало. Средний размер слова был 36-38 бит. Двоично-десятичное — это позднее изобретение, чтобы не делать постоянную конвертацию при выводе.
>это значит, что вы вообще не в теме и размышляете о том, в чём не разбираетесь.
Дружище, каша в голове не у меня, а у тебя. Не я, а ты освоил разные говно языки и поимел с ними изрядный баттхерт. То что ты не умеешь собирать переносимый софт это лично твои проблемы. Я имел богатый опыт работы с дебилами, которые пытались решить через Docker проблемы своих кривых арихитектур. Ни у кого ничего путного из этого не вышло. Я не думаю что ты чем-то от них отличаешься.
Чувак, судя по твоему стилю изложения, место тебе где-нибудь среди трактористов :)
Сдаётся мне, скоро ты получишь почётный значок тролля, кем на самом деле ты и являешься. Продолжай в том же духе — один ты достойный Лорд, а остальные все дебилы.
Ага, и когда новый проект на своей машине запускаешь — тоже все себе в систему ставишь, да?
Это не костыли, это просто откладывание сегодняшних проблем с совместимостью на неопределённый срок. Что потом? Потом будут нанимать людей для поддержки сайтика на старой джанге на python2 с кучей хлама в venv, которое вертится в (к тому времени) морально устаревшем докере в виртуальной машине с федорой 7, который нужно перенести на выделенный сервер из-за того, что амазон отказался поддерживать старый образ. Примерно в этот момент и начинается настоящее веселье, о котором, почему-то, не сообщают на презентациях.
Да-да, всё так. Именно поэтому забросим контейнеры, облака, фреймворки, паттерны, ide и прочие демонические базы и вернёмся к ibm-286 и написанию сайтегов в блокноте. И всё потому, что современные технологии для определённых личностей сложны в силу их консервативности, если не лени.
Вы занимаетесь демагогией. Если вы зарабатываете сайтиками на джанге, то это не значит, что людям, которые работают над софтом для миллионов запросов в секунду не нужны все эти докеры. А то бы так и писали сайтеги на джанге в блокноте.
У вас такая же полярная точка зрения как и у того чувака. Эти технологии сложны не потому что, по вашему мнению, кто-то что-то не понимает. Они сложны потому что их сложно заставить работать вместе и сложно использовать за рамками примеров из документации. Рано или поздно, во всем это замечательном нагромождении из докеров и софта, делающего миллион запросов в секунду, неизбежно появляется маленький скриптик, меняющий LD_LIBRARY_PATH (это пример). Хотя, казалось бы, ничего особенного не произошло, примерно с этого момента никто из уважаемых людей, пишуших софт, делающий миллион запросов в секунду, не знает, как вся эта каша работает на самом деле. А потом решают обновить докер и, в результате, ваш хвалёный софт делает 0 (ноль) запросов секунду. А ещё оказывается, что вместо новой модной технологии в данном конкретном случае можно было статически слинковать httpd и бед не знать.
Но это не значит, что эти технологии не надо использовать. Во-первых, разработка может зависеть от бизнес-факторов и, во-вторых, может просто не быть альтернативы.
Правда? Ужас то какой. Как же я это всё запускаю то?
Документация бывает конечно ужасной и зачастую приходится либо искать хаутушки (тоже кривые зачастую) или сидеть и самому глубоко вникать. Обычно эти проблемы только в начальных релизах, если софт становится популярным, то эти проблемы зачастую уходят сами, в процессе развития.
Вы описали обычные проблемы обслуживания.
Да, были lxc, openvz и т.д. И они использовались. Но с ними была одна большая проблема — практически в каждом проекте реализация была разной, тесты и деплой были разными. Докер просто перенес все это в массы, с более менее стабильными интерфейсами. С одной стороны программисты получили легкий способ поставки своего кода в стабильном окружении, с другой стороны администраторы получили инструмент для более эффективного управления приложениями и окружениями. При этом им не нужно при переходе с одного проекта на другой что-либо изучать. Работодатели за счет этого получают сокращение расходов. Тут вин со всех сторон.
Но, как раньше, так и сейчас, нужны все-таки люди, которые понимают то, с чем работают, а то будет либо как у Аэрофлота — вываленный наружу интерфейс докера, либо как вы описали — говнокод с адом в зависимостях.
Пакеты в ОС, eggs/wheels в питонах — везде есть свой способ (и надежный!) поставлять код с зависимостями на неизвестную систему невзирая на окружение.
Ну да, кто-то раньше наговнокодил и теперь это надо обслуживать. Что это если не откладывание проблем?
Но, как ни крути, для тех, кто активно использует контейнеры, они заметно упрощают цикл разработки/поставки. И те, кто сидел на lxc, постепенно начинают переходить на докеры, кубернеты, и прочее…
Любой разработчик работает не на себя, а на бизнес. Даже если этот бизнес свой это всё равно бизнес. И разработчику необходимо либо быстро сделать и выкатить, чтобы получать уже деньги, либо сидеть месяуами и полировать код, но не получать ни копейки.
Думаю тут выбор очевиден.
Дальше, есть рефакторинг. Это позволяет отполировать/переписать уже имеющийся код. Тут тоже чуществует такой же баланс НАДО и ХОЧУ.
И вся бизнес структура на всё этом балансе строится.
А вы транслируете только одну точку зрения «ХОЧУ» в то время как бизнесу требуется «НАДО».
Я так и написал:
И нет, в отличии от вас, я ноль раз написал, чего я хочу.В этом месте не имеет значения, используется там «устаревший питон», или оно написано на вечномолодом pascal. Со временем кодовая база устаревает вне зависимости от используемых технологий.
Не знаю, к чему вы это написали, но да, не имеет. Речь идёт о том, использовать что-то или обойтись без чего-то. Если вы отказались от питона или паскаля — уже не имеет значения, когда они устареют. Поэтому, скорость устаревания кодовой базы прямо пропорциональна количеству технологий, от которых эта кодовая база зависит.
После чего вы обновляете версию библиотеки в Dockerfile и пересобираете контейнер. Не сильно отличается от обычной системы.
С точки зрения security, замечу, что всё-таки отличается не в лучшую сторону. Добавляется новый шаг — найти все контейнеры с уязвимыми библиотеками и пересобрать их _все_. И тут как раз начинается то, о чём предпочитают не упоминать — зоопарк контейнеров, часть контейнеров притянуто извне и неизвестно кем поддерживается, часть контейнеров, скажем, на CentOS 6, потому что их боятся трогать чтобы ничего из работающего не сломать, часть забыли кто и как собирал и так далее.
С этой точки зрения гораздо легче иметь поддерживаемую систему с разделяемыми библиотеками, где обновление одной либы гарантированно исправляет ошибку. Так что у медали всегда две стороны и не стОит закрывать глаза на проблемы тоже.
Вот, самое здравое тут — «притянуто извне и неизвестно кем поддерживается». Ближайшим аналогом этого будет make install для прокси сервера. Что оно там инсталл, куда, никто не знает, но лучше не трогать, ибо работает.
Не могу не согласиться и к сожалению контейнеры поощряют такое поведение — нет видимых проблем, никто не обновляет контейнер. Про сторонние, скачанные со всяких хабов вообще молчу, еще и внешняя зависимость.
Любые формы вендоринга требуют внимания. Статически слинкованные библиотеки (C, Rust, Go), питоновые venv'ы.… Даже динамическая линковка не решает проблемы (С/С++), потому что баг может быть, например, в макросе в хидере библиотеки и только перекомпиляция с обновлённым хидером исправит проблему.
Любые баги компиляторов или транспиляторов тоже фиксятся только перекомпиляцией. А транспиляторов больше, чем кажется — yacc/flex, всякие протобуферы, ORM'ы, которые генерируют классы, etc.
Т.е. в этой ситуации гнать на докер со словами «он скрывает вендоринг» — глупо. Да, вендоринг. Да, большего масштаба чем было. Так оно ради масштаба и делалось.
Со сказанным согласен, речь лишь о том, что умноженные проблемы с безопасностью тоже придётся как то учитывать, о чём часто молчат.
Дружище, не пугай меня…
Похоже вы не разобрались зачем это вообще нужно. Например хостинги, оптимальное использование мультипроцессорности. А уж легкость и простота сборки и развертывания своих же приложений в изолированных контейнерах, никак не могут быть связаны с кривизной ПО.
Интересный отзыв о скриптовых языках, а где вы компилируете ваш «компилируемый» софт? А что если shared библиотеки, которые вы используете не установлена в другой ОС или имеют расхождения по версиям, но это еще просто.
А представьте что вы для кеша используете Redis, для поиска ElasticSearch, nginx как реверс прокси, будете конфигурировать их каждый раз? Особенно когда вам нужно будет быстро поднять тестовый сервер или к вам в команду пришел новый стажер-программист, как вы долго ему будете объяснять что и как ему нужно установить прежде чем писать код?
А теперь представьте что у вас распределенный high-load проект с хотя-бы 3-4 нодами, и вот вы решили что вам нужно поменять версию БиблиотекиX везде и вместо того чтобы обновить образ в докере вы шлете сис-админа чтобы тот аккуратно не помешав работе вашего сервиса все обновил. И вот, долгожданный релиз, а БиблиотекиX в новой версии обзавелась мемликом и теперь вам нужно все снова откатывать.
Таких ситуаций полно, к сожалению, и дело не в том что софт «херовый», а в том что он сложный использует тысячи библиотек, зависимостей, сторонних сервисов и аппликаций.
Почему же админ должен это делать руками? Разве DSC системы с этим не помогут? В каком-нибудь стейте «соли» прописать новую библиотеку и запустить раскатку стейтов на ноды, сложностей вроде не больше, чем обновлять докер образы и так же их деплоить.
Я не видел ни одной роли для salt'а или ansible'а, которая бы делала blue-green deployment. А в k8s — оно из коробки и офигенно работает.
Blue-green-deployment — это когда при апгрейде софта мы поднимаем новые реплики на новой версии, потом перекидываем нагрузку с одной из старых реплик на новую, и выводим старую реплику из эксплуатации. Потом ещё раз и ещё — пока кластер целиком не переползёт на новую версию.
Чтобы «поднять ещё одну реплику» нужно иметь систему, которая может быстро поднять "-цать копий серверов". Динамически, с мониторингом живости и прибитием лишнего. Вручную такое на chef/ansible/puppet написать можно — они все тьюринг-полные. Но k8s уже написан и протестирован, так что зачем писать своё?
Ну как альтернатива для B/G deployment может быть PaaS, но с ним идет vendor lock.
Коллега как раз сваял на днях blue-green для AWS (ALB + blue ASG / green ASG) на Terraform. То же можно было бы сделать и на Ansible.Так что варианты есть.
Конечно, вариант «написать своё» всегда есть. Стоит взять тьюринг-полное нечто (а ансибл тьюринг-полный, плюс позволяет цеплять свои модули на питоне, который не только тьюринг-полный, но ещё и язык программирования), как сразу же можно написать что угодно. Хоть операционную систему, хоть систему оркестрации.
Проблема в том, что ансибл (и т.д.) — это системы управления конфигурациями. И только. У них в workflow нет понятия «реакции на несвязный факап». А у систем оркестрации оно должно быть в центре внимания.
Ансибл может в любой момент времени проверить, что у нас есть N рабочих реплик. Но он не может это проверять в каждый момент времени. Например, ансибл убедился, что у нас N+1 рабочих реплик и пошёл сносить реплику N+1. В это время реплика 2 сдохла.
Оркестрация в такой ситуации снесёт N+1'ую реплику, и тут же запустит N'ую (потому что рабочих реплик стало N-1). А ансибл радостно зарепортит «всё сделано».
Можно завернуть ansible в цикл. Но это начинает подозрительно напоминать написание супервизора. На ансибле. Смешно.
Например, пользуюсь stack'ом. Получаю reproducible build'ы, возможность иметь разные версии одной и той же библиотеки для разных проектов, и так далее. И библиотеки сами ставятся, да.
Ну вот я пытался запустить старый Firefox, например 3.5 или около того, на современном Дебиане. Не работает. Более новая библиотека GTK, казалось бы, должна быть обратно совместима, но по факту — нет (видимо, в старой версии не было какой-то проверки и код работал, а в новой проверки ужесточены). Как мне запускать этот старый фаерфокс на новой системе?
Контейнеры тут могли бы быть удобным решением, правда надо еще найти, как в контейнер запихнуть древнюю версию библиотеки и древнии версии ее зависимостей.
То есть проблема в убогости пакетных менеджеров, которые не способны поддерживать установку нескольких версий одной библиотеки, а умеют лишь ставить самое новое.
А вот если разработчики на совместимость «забивают» и порождают две версии библиотек, которые, вроде как бы, должны быть совместимыми, но де-факто совместимыми не являются… тогда у вас беда.
То есть да — docker, podman и прочие решают именно проблему криво написанных программ… но других-то у нас нет…
Если все будут писать софт без багов — половину современного ИТ можно выкидывать за ненадобностью.
Если же мы имеем ситуацию с несовместимостью между ABI версий библиотек, то это обычная проблема, ничем не лучше и не хуже любой другой.
И добротное IT должно уметь продолжать жить даже с таким багом, а не закрываться со словами segmentation fault… Пардон, incompatible call bla-bla-bla.
Извините, но мой опыт, в т.ч. с Фаерфоксом, показывает что декларируемая ситуация часто отличается от реальности. В теории библиотеки совместимы — а по факту нет (пример: новая версия более тщательно проверяет входные параметры, а программа передает в них некорректные значения, что работало со старой версией). Да, может быть старый Фаерфокс неправильно работает с библиотекой и содержит ошибку, однако мне нужны не объяснения, а работающий браузер.
Учтите только, что в контейнерах библиотеки тоже надо постоянно обновлять, чтобы не нарваться на серьезные проблемы с безопасностью. И точно такая же проблема с проверкой параметров в API может вылезти после обновления. А по факту часто имеем «работает — не трожь» и сопутствующие дыры, которые эксплуатируются. Не теоретически, а вполне на основе опытных данных.
Можно ли увидеть какие-либо расчеты в подтверждение вашей позиции? Или это ваше личное мнение, которое не обязано быть правильным?
Докер (и контейнеризация вообще) позволяет гарантировать одинаковые условия исполнения кода. Это в свою очередь снижает (хотя и не отменяет полностью) ситуации а-ля «а у меня локально всё в порядке».
Плюс, рядовой ситуацией является несколько одновременно поддерживаемых релизов одного и того же софта. Иногда новый релиз ведет к частичному нарушению обратной совместимости (например, за счет изменения дефолтов). Кроме того, только что вышедший релиз используемого стороннего ПО может иметь изъяны, т.к. он не проверен временем на продакшне. Поэтому переход с одного релиза на другой может быть достаточно рисковым, и делать его только лишь потому, что так хочется вам лично, не стоит.
При этом достаточно просто и легко опробовать новый релиз, даже если для вашей любимой серверной ОС он не был выпущен. И тут (при вашем отношении к докеру) либо компилировать самому (что может стать увлекательным приключением), либо рисковать, подключая сторонние репозитории.
Всех этих проблем вы можете избежать, используя контейнеризацию. И да, к вопросу о скриптовых языках, надеюсь, это была неудачная шутка. Погуглите, сколько сервисов с миллионными и даже миллиардными доходами, написано с использованием Python. В общем, вспоминается старая поговорка про корреляцию ума и богатства.
даа, вкатали вам минусов. Но вы держитесь
Программист приносит больше реальной пользы, когда сосредоточен на создании/поддержании собственно прикладной ценности создаваемого им продукта, а вовсе не технологической обвязки (обвязка — это в том числе поддержка совместимости с различными внешними средами).
Я так и не понял какую проблему они решал создавая свой стэк.
NIH?
del
Спасибо. Очень «полезная» статья. Напился вдоволь.
Извиняюсь за токсичность, но очень обидна когда тема не раскрыта.
К сожалению, комментарий не раскрывает тему того, что не раскрыто.
По конкретики:
Для тех кому эти названия ни о чём не говорят, это выглядит как рандомный факт. Да есть ссылки, но мало у кого после прочтения README появляется понимание хорошо это или плохо. А если это и не хорошо и не плохо, то на что влияет?Куча ненужной информации, от историй названий, до упоминания версий и таблице сравнения команд где только 2 отличаются.
Но при этом не раскрыты преимущества. Есть техническое описание что оно может, но непонятно зачем это может пригодится.
Упоминается какое то их виденье, но в чём оно заключается не сказано, или плохо уловимо.
Можно было перечислить какие инструменты у них есть, и какую роль во всём этом играет libpod.
Конечно есть ссылки, но это не сильно спасает.
Напримет:
Итог: У вас получилась не популярная статья, а сухая глава из учебника, причём с одним лишь примером вне контекста. Понять может только тот кто и так знает. А как вы писали в заголовке «чтобы познакомиться с ним, узнать о его истоках и подумать о перспективах», но такая манера повествования ясности не вносит.
> непонятно зачем это может пригодится
Об этом написано здесь:
Далее — почему же тогда не Docker CLI, сказано здесь:
> Для тех кому эти названия ни о чём не говорят, это выглядит как рандомный факт.
Признаюсь, эта статья ориентирована не на тех, для кого такие названия, как runc и CNI, ни о чём не говорят. Чтобы таким людям было проще, есть многократные ссылки на обзор CRI-O, где эта тема раскрыта. Дублировать её в данной статье не посчитал уместным, а к этому, как я вижу, и сводится всё основное непонимание и видимый недостаток раскрытия темы…
P.S. К вопросу о преимуществах и сравнениях: Podman по сути своего предназначения интереснее сравнивать с упомянутым в начале статьи cri-containerd от Docker Inc. И есть на эту тему взгляд со стороны Red Hat.
Спасибо за пояснения. Прочитав «обзор CRI-O» стало намного понятней. Правда всё равно не понятно чем их не устраивает демон в докере, но я думая что в комментарии ниже есть ответ.
Как я сейчас понял HR делают свою «оболочку» частично на основе уже стандартизованных элементов докера и в соответствии с «Проект следует идеологии UNIX-команд, где каждая утилита делает лишь одну вещь, но хорошо.».
А изначально из статьи складывалось впечатление (как выше писали NIH), делаем свой велосипед потому что свой. Пара мелких фишек которые непонятно зачем нужны — не в счёт.
Спасибо и вам за комментарии. Добавил в материал абзац с ссылкой на сравнение Podman с containerd/crictl и соответствующим комментарием.
P.S. Несмотря на всё, грань с NIH в таких случаях всё же довольно тонкая, поэтому иметь её в виду тоже стоит.
А зачем? Чем Docker не устраивает?
Вот этот тикет может пролить свет — https://github.com/containerd/containerd/issues/2288
Меня — тем, что он очень opionated. Тот же lxc для жизни лучше, но pod'ов не хватает. Очень надеюсь, что эта штука взлетит.
Ключевая проблема состоит в том, что RH хочет из управлялки контейнеров сделать простую тупую ясную утилиту. А Docker (компания) хочет быть business value, чтобы все на неё обращали внимание и думали docker way.
Утилита лучше, чем чужое business value, потому что утилита полезнее.
Это я так понимаю когда мы хотим Докер, но что бы это был не Докер. Из статьи я чесно говоря не понял принципиальной разницы. Или должно быть какое-то сравнение производительности или чего-то еще.
Есть ссылка на сравнение производительности runc в разных реализациях (в т.ч. CRI-O и containerd, с которым уместнее сравнивать, чем просто Docker*), приводившееся в этой статье. Вот оно:
(его источник)
* Если сравнивать ещё с самим Docker, то налицо как минимум значимое архитектурное отличие (не нужен демон), поэтому корректнее всё же рассматривать Podman vs. containerd/crictl. Здесь есть функциональные отличия — информацию об этом добавил в текст статьи, спасибо!
Щас IBM развернется на ниве проприетарного софта… Чувствую что через пару лет весь софт от IBM будет идти в виде докер контейнеров с «модифированным» RH внутри, а внутри него — уже свой podman, и уже внутри этой матрешки — микросервисы ))).
Правильно ли я понимаю, что если я просто пользуюсь докером без k8s (для развертывания локальной dev среды через compose), то никаких преимуществ от podman не получу?
Технически это сделать можно (вот, кстати, онлайн-сценарий от Katacoda для такого знакомства — добавил его заодно и в статью), но практический смысл… Разве что вам почему-то надоел запущенный в системе демон Docker или хочется интегрировать запуск контейнеров с системными сервисами (через systemd). Глобально же это скорее интересно тем, кто собирается запускать контейнеры в «таком же виде» в Kubernetes — тогда всё будет унифицировано.
Коллега как раз сваял на днях blue-green для AWS (ALB + blue ASG / green ASG) на Terraform. То же можно было бы сделать и на Ansible.Так что варианты есть.
Можете хотя бы тезисно рассказать, как это делается через Ansible, кусочками из play-book? Спасибо.
В смысле, blue-green? Извините, я тут просто случайно «не в ту ветку» написал, вот ссылка в «ту ветку»: habr.com/company/flant/blog/426141/#comment_19307065.
А я вот тоже не понял, чем оно отличается от docker для пользователей? Какие плюсы?
Только очень много раз прочёл «стандарт».
Дело не в этом, docker многих не устраивал: они делали новые версии без оглядки на продукты, которые им пользуются и не очень заботились об обратной совместимости. Более того Docker — это оверхед для продуктов типа Kubernetes.
Так и в чём плюсы?
Ну я же вроде как написал.
Для пользователей, которые разработчики прикладного софта и оборачивают результат своей работы в контейнеры — разницы почти никакой
А вот для админов, которые это всё добро запускают — разница большая. Докер тяжёлый, тащит много своего ненужного стека, который в продакшене хочется заменить на что-нибудь другое (та же работа с сетью), докер-демон иногда зависает (не запускает новые контейнеры и не останавливает старые).
Основной запрос на переход Docker > CRI-O исходит как раз от админов.
Более того, благодаря всем этим усилиям и инициативам OCI по стандартизации этого добра, разработчики в принципе могут собирать образы Docker'ом, а админы — запускать их CRI-O
К слову, инициатива это исходит от докера, т.к. он передал многие свои компоненты в OCI, стандартизировал форматы и прочее. Собственно, они и были в числе основателей OCI.
Тем, что все эти начинания с cri-o делаются для совсем других целей — сделать легковесный рантайм для кубернетиса и ему подобных. Никто убийцу докера писать не собирался и не пишет. Докер остается в своей нише, а в нише маленького компонента кубернетиса он выглядит слишком большим и сложным, поэтому его заменяют на крио. Хотя докер все еще остается доминирующим и дефолтным вариантов. Все таки устоявшийся взрослый продукт. Подман тут видится разве что для совсем узкий кейсов — потестить, поиграться. Смысла запускать у себя машине это все никакого. Докер тут нужнее, а смысла ворочать руками контейнеры, когда у тебя кубернетис, тем более не видно.
Docker RIP?
Он никуда не денется, т.к. является основой цикла разработки. Локальное тестирование, простые кейсы, где нужно просто запустить что-то в контейнере. Смысла линять с докера в этих случаях никакого. Да и альтернатив нет — для мака вот есть шикарное интегрированное докер решение, будто у меня контейнеры прям в макоси. Все эти крио даже не суются сюда и не собираются докер вытеснять, это не их ниша.
Docker is the best
Как убого выглядит мир линукса с контейнерами и насколько всё красиво во FreeBSD :)
> красиво во FreeBSD
А не могли бы вы раскрыть мысль? Мне правда интересно. Когда я последний раз трогал FreeBSD, там были простые Jails. Простые — в смысле что-то больше похожее на lxd.
Но это было довольно давно, может быть сейчас уже завезли что-то более интересное?
Я скорее имел ввиду идеологию подхода в разных ОС, например, захотели 2-й питон, зашли в те же порты, поставили, захотели 3-й питон, зашли и поставили. Что замечательно, так это то, что они сосуществуют вместе со всеми своими либами и зависимостями в одной ОС и без контейнеров (да, jail есть и это рабочий инструмент для продакшена). Аналогично и с другими проектами. В линуксе, что не день, то сюрприз. Опять же пример, вечером уходил — всё работало, утром запустил компьютер и нет модуля управления рабочими столами, обновил ОС (centos), пропала менюха.
Как я вижу, во FreeBSD ОС — это комплект ядра, окружения, и даже пакетов. В Линуксе, больше выбор, но приходится платить за это кровью админов)))
Ну справедливости ради, 2 и 3 питон одновременно держать в системе не проблема.
Неудобства начинаются когда надо одновременно, ну возьмем для примера php — 5.2,5.3,5.6,7.0,7.2 (не спрашивайте зачем). Можно конечно все это развернуть на одной системе, но это получится адский ад. Гораздо удобнее запихать разные версии в разные контейнеры и наслаждаться чистотой и порядком в системе.
А еще докер — это не только изоляция приложений.