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-контейнеров».
Комментарии (97)
isden
30.10.2018 10:56+1А вот кто проголосовал за «Реальное использование (в production или близко)» — подскажите плз, чем оно лучше докера и стоит ли начать думать об экспериментах с миграцией?
beduin01
30.10.2018 11:03-7Все эти Docker'ы нужны только для кривого софта способного работать только на побитовых копиях ОС разработчиков. Как следствие вместо повышения качества софта создается целая экосистема костылей. В начале был Docker сейчас podman, через года два еще что-то увидим.
Сами по себе эти технологии пустые и затраты на внедрение\обслуживание не окупаются просто потому, что гораздо выгоднее софт научиться нормально писать, чем нанять целый отдел DevOps'ов который будет весь этот ужас обслуживать.
И да, Docker популярен только там где люди пишут только на скриптовых языках. В нормальных компилируемых потребность в нем отсутствует. Нет можно конечно упороться и запихнуть в него софт, но зачем?
>Это все очень круто и здорово пока у вас части приложения не требуют разных версий библиотек ставящихся через пакетный менеджер, который ставит только одну
Значит это или плохо написанное приложение или хреновый пакетный менеджер если в нем такие проблемы есть. Другого не дано.
Да и новые версии библиотек не просто так выпускают. Часто в них дыры и ошибки находят. Согласно логике фанатов Докера предлагается вместо решения задачи обновления версий библиотек просто засунуть все в контейнер и надеяться, что оно как-то обойдется. Великолепная логика!
Пока дураки жмут штангу фанаты Docker катают ее по полу и смеются.Fedcomp
30.10.2018 11:08+3Это все очень круто и здорово пока у вас части приложения не требуют разных версий библиотек ставящихся через пакетный менеджер, который ставит только одну. Не говоря уже о том что раздельные окружения менее зависимы друг от друга и ими проще управлять. Я уже молчу что разбив на все это на детальки, можно масштабировать одни части и не трогать другие.
Вы поймете все неудобства когда вам придется компилировать два приложения требующих разные версии библиотек. И нет, даже компилируему приложению может понадобиться бд/редис/что то еще что может быть неудобно ставить/настраивать в том же окружении.
Не понимаю вашего скепсиса.
Затраты на обслуживание/внедрение окупаются когда у вас 10 кодеров вместо одного дорогого системщика и сервис надо масштабировать на большое количество людей.Gemorroj
30.10.2018 11:20-2а что мне помешает использовать старую какую-нибудь старую 100 лет известную виртуализацию (kvm/openvz и тд) вместо докера?
FeNUMe
30.10.2018 11:42+1Мешают значительно большие накладные расходы на эту «старую» виртуализацию.
Ipeacocks
30.10.2018 23:47+1OpenVZ — это те же контейнеры. Только с хранением состояния, т.е. аналоги виртуальных машин, только они легковснее и + в принципе все плюсы и минусы контейнеров.
Т.е. если вернуться к теме вопроса
> а что мне помешает использовать старую какую-нибудь старую 100 лет известную виртуализацию (kvm/openvz и тд) вместо докера?
Ну с виртуалками будет просто долго, потому как они большие и производительность, как вы сказали будет ниже через дополнительные слои абстракий. С openvz — потому что он не мейнстрим, а с Docker все получится, потому что он чертовски популярен.
Barafu_Albino_Cheetah
30.10.2018 17:58+5Docker контейнер потребляет столько памяти, сколько ему сейчас нужно. Может занимать и освобождать память. KVM виртуалка требует отвести память заранее. Её можно увеличивать путём удваивания (но это небыстро), а освобождать вообще нельзя.
Docker стартует моментально, виртуалка грузится.
Docker имеет ядро одно на всех, виртуалки каждая — своё, и они поддерживают кучу внутренних состояний, которые в виртуалке нафиг не нужны.
Docker использует системное IO, виртуалка даже с virtio вынуждена что-то трансформировать и переорганизовывать.
Docker умеет централизованно обновляться из репы, виртуалки каждая по-своему.
Docker compose и swarm умеют такое, под что на виртуалках отдельный человек необходим.
Так можно продолжать очень долго. Эпоха кручения серверов в виртуалках ушла*. Учите Docker.
* кроме некоторых особых случаев безопасности. И Windows.BaLaMuTt
31.10.2018 13:35Эпоха кручения серверов в виртуалках ушла
бред. Все облака почему-то на виртуализации основаны, а не на голом железе + никто вам не мешает ворочать контейнеры докером внутри виртуальной машины.creker
31.10.2018 22:47Одно другому никак не противоречит. Облака на виртуалках, потому что альтернатив у них нет — изоляция нужная же какая-то. Но вот все, кто повыше сидят, с виртуалок слезли на контейнера и эпоха действительно прошла. Очень забавно в этом всем видеть таких как vmware, которые всеми ногами и руками впихывают в свою архитектуру контейнеры где-то сбоку криво и косо, лишь бы вписалось как-то в существующий стек.
erlyvideo
01.11.2018 03:57> Docker использует системное IO, виртуалка даже с virtio вынуждена что-то трансформировать и переорганизовывать.
нет. Докер дает оверхед на сеть и делает безумно сложным многие сетевые штуки, которые кое как возможно сделать на виртуалках.
imanushin
30.10.2018 18:13+2100 лет известную
Вы переборщили.
kvm/openvz и тд
Докер использует изоляцию в ОС, то есть:
- Всех обслуживает одна ОС, то есть:
- В память грузится одно ядро ОС (и лицензируется тоже одно ядро)
- Файловая система может быть одна на всех, с дедупликацией и т.д.
- Эта ОС полностью контролирует всё железо, а не определенную его часть.
- Каждое приложение запускается в отдельной cgroups (или Job Objects в Windows), то есть:
- Процессы из одной группы не видят таковых из другой
- Нельзя прыгнуть в память чужого cgroups (ну т.е. изоляция)
- Можно ограничить объем ресурсов для cgroups, то есть процессорное время, объем памяти, нагрузку на IO и пр.
- Любое приложение для мониторинга может следить сразу за всеми (т.е. в отличии от виртуализации — не надо запускать по одному инстансу на каждом хосте)
Еще раз, это важно: в случае контейнеров у вас одна ОС, которая распределяет ресурсы. А не много разных ОС. У вас прямой доступ к файловой системе, никто не пишет в ФС виртуальной машины, чтобы потом хост перенаправил блок к ФС уже реального хоста. За счет этого получается практически идеальная кооперация между компонентами, т.к. в памяти нет ничего лишнего, кроме ядра ОС и процессов внутри контейнеров. Тот же докер ничего дополнительного не проксирует (кроме запуска/остановки контейнеров).
Аналоги подобной штуки:
- В iOS каждое приложение запускается от отдельного пользователя, что автоматом дает изоляцию ресурсов (тех же файлов)
- В Windows вы можете залогиниться разными пользователями в разные сессии и не мешать друг другу. Причем все это не уберет фишек дедупликации данных на диске.
В виртуализации вы сразу:
- Лишаетесь дедупликации (и схожего переиспользования ресурсов) на файловой системе хоста
- Заставляете под каждую виртуальную машину поднимать отдельное ядро системы (кстати, заодно и за лицензии заплатите, ведь на одной машине у вас будет несколько запущенных серверов), которое будет добавлять задержки к куче операций, таких как работа с внешними устройствами (с той же сетью), работа с ring-0 (эта часть интерпретируется) и т.д.
- И получаете бонус — можете запускать Linux & Windows на одном хосте.
Резюме: если у вас очень много контейнеров/образов, которые могут быть запущены на одной и той же ОС — контейнеры помогут вам сэкономить ресурсы.
- Всех обслуживает одна ОС, то есть:
force
30.10.2018 13:29Соглашусь с beduin01 эта проблема, что вы описали как раз и вылезает из-за того, что существующая система версионирования обычно весьма корявая, и лезет проблема dll hell, которую и решили таким «элегантным» образом. Как бы я не любил в ноде ужас с папкой node_modules, из-за того что все зависимости и лежат в этой папке, вы можете на сервере держать кучу абсолютно разных приложений на ноде, и не знать проблем. В dotnetcore тоже очень хорошо сделали версионирование и докер вроде бы не нужен.
При этом, когда я сталкиваюсь с каким-нить ruby, я понимаю, что тут Docker был просто спасением.
Так что всё зависит от средств разработки и их возможностей. Где-то нафиг не нужен докер, где-то без него не обойтись. И мне больше нравится первый вариант, тогда докер всего-лишь приятное дополнение и удобство деплоя и оркестрации. Но, можно и без него.bugagazavr
31.10.2018 05:09При этом, когда я сталкиваюсь с каким-нить ruby, я понимаю, что тут Docker был просто спасением.
Спасением от bundler install --help и bundler exec --help?
force
31.10.2018 10:09В теории да, но когда требуются разные версии ruby или разные версии bundler'а — нифига не помогает.
Честно скажу, я плохо знаю руби, но проблемы с версионированием там какие-то уж очень жестокие на мой взгляд.
mobilesfinks
31.10.2018 11:03Докер это не только решение «dll hell», это ещё унифицированный интерфейс и снэпшот кода приложения. Независимо от рантайм окружения вы получаете одно и тоже приложение что на Ubuntu, что на CentOS, что в любом другом линукс дистрибутиве (с виндой дел не имел, не скажу).
beduin01 просто не понимает всех возможностей докера и тех задач которые он решает. Я думаю он просто не умеет им пользоваться или не сталкивался с задачами в которых придётся костыли подпирать костылями если нет докера.
Если бы всё было так красиво как он описал про компиллируемые языки, то докера бы не было и все бы писали и компиллировали, а скриптовые языки были бы малоразвиты.
Докер популярен именно потому, что он решает требуемые задачи с минимальным оверхедом и со стороны ресурсов и со стороны администрирования.
greendog
30.10.2018 12:27+4Какая-то каша у вас в голове. Если вы и впрямь считаете, что докер нужен для того, чтобы не учиться писать нормально софт, то это значит, что вы вообще не в теме и размышляете о том, в чём не разбираетесь.
Даже не знаю, как можно комментировать фразу «как следствие вместо повышения качества софта создается целая экосистема костылей» — так можно о всём техническом прогрессе сказать, что автомобили созданы для того, чтобы не ходить «нормально» пешком.amarao
30.10.2018 18:23+2Именно! А компьютеры созданы ленивыми людьми, которые так и не освоили двоичный счёт.
khim
30.10.2018 19:48Двоичный счёт тут причём? Первые компьютеры десятичными были. И где-то до 80х использовались двоично-десятичные числа (даже в x86 они есть, хотя мало какие программы их используют)
amarao
31.10.2018 12:49Компьютеры первой-второй волны работали только двоичных на float'ах, потому что считать надо, а битов было мало. Средний размер слова был 36-38 бит. Двоично-десятичное — это позднее изобретение, чтобы не делать постоянную конвертацию при выводе.
beduin01
30.10.2018 20:08-7>это значит, что вы вообще не в теме и размышляете о том, в чём не разбираетесь.
Дружище, каша в голове не у меня, а у тебя. Не я, а ты освоил разные говно языки и поимел с ними изрядный баттхерт. То что ты не умеешь собирать переносимый софт это лично твои проблемы. Я имел богатый опыт работы с дебилами, которые пытались решить через Docker проблемы своих кривых арихитектур. Ни у кого ничего путного из этого не вышло. Я не думаю что ты чем-то от них отличаешься.
greendog
30.10.2018 21:10Чувак, судя по твоему стилю изложения, место тебе где-нибудь среди трактористов :)
Сдаётся мне, скоро ты получишь почётный значок тролля, кем на самом деле ты и являешься. Продолжай в том же духе — один ты достойный Лорд, а остальные все дебилы.
YemSalat
31.10.2018 05:00Ага, и когда новый проект на своей машине запускаешь — тоже все себе в систему ставишь, да?
geisha
30.10.2018 23:52Какая-то каша у вас в голове.
Справедливости ради из этих ваших докеров тоже изрядная каша. Во-первых, их тут оказалось разновидностей вагон и маленькая тележка. Во-вторых, есть полу-виртуализация lxc, openvz и, наверное, ещё. В третьих, есть такая хрень, как виртуализация в рамках интерпретатора (virtualenv для питона). В четвёртых, есть module для линуксов. И это только примеры известные мне.
Это не костыли, это просто откладывание сегодняшних проблем с совместимостью на неопределённый срок. Что потом? Потом будут нанимать людей для поддержки сайтика на старой джанге на python2 с кучей хлама в venv, которое вертится в (к тому времени) морально устаревшем докере в виртуальной машине с федорой 7, который нужно перенести на выделенный сервер из-за того, что амазон отказался поддерживать старый образ. Примерно в этот момент и начинается настоящее веселье, о котором, почему-то, не сообщают на презентациях.greendog
31.10.2018 00:02+1Да-да, всё так. Именно поэтому забросим контейнеры, облака, фреймворки, паттерны, ide и прочие демонические базы и вернёмся к ibm-286 и написанию сайтегов в блокноте. И всё потому, что современные технологии для определённых личностей сложны в силу их консервативности, если не лени.
Вы занимаетесь демагогией. Если вы зарабатываете сайтиками на джанге, то это не значит, что людям, которые работают над софтом для миллионов запросов в секунду не нужны все эти докеры. А то бы так и писали сайтеги на джанге в блокноте.geisha
31.10.2018 02:49У вас такая же полярная точка зрения как и у того чувака. Эти технологии сложны не потому что, по вашему мнению, кто-то что-то не понимает. Они сложны потому что их сложно заставить работать вместе и сложно использовать за рамками примеров из документации. Рано или поздно, во всем это замечательном нагромождении из докеров и софта, делающего миллион запросов в секунду, неизбежно появляется маленький скриптик, меняющий LD_LIBRARY_PATH (это пример). Хотя, казалось бы, ничего особенного не произошло, примерно с этого момента никто из уважаемых людей, пишуших софт, делающий миллион запросов в секунду, не знает, как вся эта каша работает на самом деле. А потом решают обновить докер и, в результате, ваш хвалёный софт делает 0 (ноль) запросов секунду. А ещё оказывается, что вместо новой модной технологии в данном конкретном случае можно было статически слинковать httpd и бед не знать.
Но это не значит, что эти технологии не надо использовать. Во-первых, разработка может зависеть от бизнес-факторов и, во-вторых, может просто не быть альтернативы.mobilesfinks
31.10.2018 11:07Они сложны потому что их сложно заставить работать вместе и сложно использовать за рамками примеров из документации.
Правда? Ужас то какой. Как же я это всё запускаю то?
Документация бывает конечно ужасной и зачастую приходится либо искать хаутушки (тоже кривые зачастую) или сидеть и самому глубоко вникать. Обычно эти проблемы только в начальных релизах, если софт становится популярным, то эти проблемы зачастую уходят сами, в процессе развития.
willyd
31.10.2018 03:14Вы описали обычные проблемы обслуживания.
Да, были lxc, openvz и т.д. И они использовались. Но с ними была одна большая проблема — практически в каждом проекте реализация была разной, тесты и деплой были разными. Докер просто перенес все это в массы, с более менее стабильными интерфейсами. С одной стороны программисты получили легкий способ поставки своего кода в стабильном окружении, с другой стороны администраторы получили инструмент для более эффективного управления приложениями и окружениями. При этом им не нужно при переходе с одного проекта на другой что-либо изучать. Работодатели за счет этого получают сокращение расходов. Тут вин со всех сторон.
Но, как раньше, так и сейчас, нужны все-таки люди, которые понимают то, с чем работают, а то будет либо как у Аэрофлота — вываленный наружу интерфейс докера, либо как вы описали — говнокод с адом в зависимостях.geisha
31.10.2018 04:44Но с ними была одна большая проблема — практически в каждом проекте реализация была разной, тесты и деплой были разными.
Это завление прямо противоположно моим представлениям о виртуализации и докерах. Наверное, я чего-то не понимаю. Я думал я прямо сейчас могу снять lxc инстанс за десятку и вообще не знать, на чём он вертится кроме версии ядра.
С одной стороны программисты получили легкий способ поставки своего кода в стабильном окружении
Пакеты в ОС, eggs/wheels в питонах — везде есть свой способ (и надежный!) поставлять код с зависимостями на неизвестную систему невзирая на окружение.
Вы описали обычные проблемы обслуживания.
Ну да, кто-то раньше наговнокодил и теперь это надо обслуживать. Что это если не откладывание проблем?willyd
31.10.2018 04:57+1Что это если не откладывание проблем?
Их никто и не откладывает. Вы мешаете теплое с мягким. Это не проблемы докера, если у коддера руки из жопы и в голове каша — это будет и в докере, и в lxc.
Но, как ни крути, для тех, кто активно использует контейнеры, они заметно упрощают цикл разработки/поставки. И те, кто сидел на lxc, постепенно начинают переходить на докеры, кубернеты, и прочее…geisha
31.10.2018 06:59Это не проблемы докера, если у коддера руки из жопы и в голове каша — это будет и в докере, и в lxc.
Ой вот только не надо этого: хорошие кодеры первыми набегают на хабр и рассказывают, что им, к сожалению, не платят за хороший код и именно поэтому приложение, показывающее карты на моём телефоне занимает 107 мегабайт и в два раза больше места в оперативке. Проблемы докера меня лично, как пользователя, не касаются, но я уверен, что это одна из тех технологий, которые стимулируют говнокодить даже очень хороших программистов. Без докера пришлось бы последовательно обновлять весь стек приложения до самых новых зависимостей, попутно устранять баги, оптимизировать. Но зачем? Можно ж докер, иметь двадцать старых дырявых версий одной и той же libpng и, при необходимости, добавить двадцать первую в один и тот же контейнер. Докер ведь именно для этого и существует: для ваших старых дырявых зависимостей, которые лень разгребать.mobilesfinks
31.10.2018 11:15Без докера пришлось бы последовательно обновлять весь стек приложения до самых новых зависимостей, попутно устранять баги, оптимизировать. Но зачем?
Любой разработчик работает не на себя, а на бизнес. Даже если этот бизнес свой это всё равно бизнес. И разработчику необходимо либо быстро сделать и выкатить, чтобы получать уже деньги, либо сидеть месяуами и полировать код, но не получать ни копейки.
Думаю тут выбор очевиден.
Дальше, есть рефакторинг. Это позволяет отполировать/переписать уже имеющийся код. Тут тоже чуществует такой же баланс НАДО и ХОЧУ.
И вся бизнес структура на всё этом балансе строится.
А вы транслируете только одну точку зрения «ХОЧУ» в то время как бизнесу требуется «НАДО».geisha
01.11.2018 01:06Я так и написал:
кодеры первыми набегают на хабр и рассказывают, что им, к сожалению, не платят за хороший код
И нет, в отличии от вас, я ноль раз написал, чего я хочу.
amarao
31.10.2018 12:50В этом месте не имеет значения, используется там «устаревший питон», или оно написано на вечномолодом pascal. Со временем кодовая база устаревает вне зависимости от используемых технологий.
geisha
01.11.2018 02:42Не знаю, к чему вы это написали, но да, не имеет. Речь идёт о том, использовать что-то или обойтись без чего-то. Если вы отказались от питона или паскаля — уже не имеет значения, когда они устареют. Поэтому, скорость устаревания кодовой базы прямо пропорциональна количеству технологий, от которых эта кодовая база зависит.
Fedcomp
30.10.2018 12:31+2Часто в них дыры и ошибки находят
После чего вы обновляете версию библиотеки в Dockerfile и пересобираете контейнер. Не сильно отличается от обычной системы.Cenzo
31.10.2018 05:28С точки зрения security, замечу, что всё-таки отличается не в лучшую сторону. Добавляется новый шаг — найти все контейнеры с уязвимыми библиотеками и пересобрать их _все_. И тут как раз начинается то, о чём предпочитают не упоминать — зоопарк контейнеров, часть контейнеров притянуто извне и неизвестно кем поддерживается, часть контейнеров, скажем, на CentOS 6, потому что их боятся трогать чтобы ничего из работающего не сломать, часть забыли кто и как собирал и так далее.
С этой точки зрения гораздо легче иметь поддерживаемую систему с разделяемыми библиотеками, где обновление одной либы гарантированно исправляет ошибку. Так что у медали всегда две стороны и не стОит закрывать глаза на проблемы тоже.amarao
31.10.2018 12:52Вот, самое здравое тут — «притянуто извне и неизвестно кем поддерживается». Ближайшим аналогом этого будет make install для прокси сервера. Что оно там инсталл, куда, никто не знает, но лучше не трогать, ибо работает.
Cenzo
01.11.2018 00:09Не могу не согласиться и к сожалению контейнеры поощряют такое поведение — нет видимых проблем, никто не обновляет контейнер. Про сторонние, скачанные со всяких хабов вообще молчу, еще и внешняя зависимость.
amarao
01.11.2018 01:26Любые формы вендоринга требуют внимания. Статически слинкованные библиотеки (C, Rust, Go), питоновые venv'ы.… Даже динамическая линковка не решает проблемы (С/С++), потому что баг может быть, например, в макросе в хидере библиотеки и только перекомпиляция с обновлённым хидером исправит проблему.
Любые баги компиляторов или транспиляторов тоже фиксятся только перекомпиляцией. А транспиляторов больше, чем кажется — yacc/flex, всякие протобуферы, ORM'ы, которые генерируют классы, etc.
Т.е. в этой ситуации гнать на докер со словами «он скрывает вендоринг» — глупо. Да, вендоринг. Да, большего масштаба чем было. Так оно ради масштаба и делалось.Cenzo
01.11.2018 01:59Со сказанным согласен, речь лишь о том, что умноженные проблемы с безопасностью тоже придётся как то учитывать, о чём часто молчат.
Easter
30.10.2018 13:10+1Похоже вы не разобрались зачем это вообще нужно. Например хостинги, оптимальное использование мультипроцессорности. А уж легкость и простота сборки и развертывания своих же приложений в изолированных контейнерах, никак не могут быть связаны с кривизной ПО.
avengerweb
30.10.2018 14:55+2Интересный отзыв о скриптовых языках, а где вы компилируете ваш «компилируемый» софт? А что если shared библиотеки, которые вы используете не установлена в другой ОС или имеют расхождения по версиям, но это еще просто.
А представьте что вы для кеша используете Redis, для поиска ElasticSearch, nginx как реверс прокси, будете конфигурировать их каждый раз? Особенно когда вам нужно будет быстро поднять тестовый сервер или к вам в команду пришел новый стажер-программист, как вы долго ему будете объяснять что и как ему нужно установить прежде чем писать код?
А теперь представьте что у вас распределенный high-load проект с хотя-бы 3-4 нодами, и вот вы решили что вам нужно поменять версию БиблиотекиX везде и вместо того чтобы обновить образ в докере вы шлете сис-админа чтобы тот аккуратно не помешав работе вашего сервиса все обновил. И вот, долгожданный релиз, а БиблиотекиX в новой версии обзавелась мемликом и теперь вам нужно все снова откатывать.
Таких ситуаций полно, к сожалению, и дело не в том что софт «херовый», а в том что он сложный использует тысячи библиотек, зависимостей, сторонних сервисов и аппликаций.Pariah
30.10.2018 15:57Почему же админ должен это делать руками? Разве DSC системы с этим не помогут? В каком-нибудь стейте «соли» прописать новую библиотеку и запустить раскатку стейтов на ноды, сложностей вроде не больше, чем обновлять докер образы и так же их деплоить.
amarao
30.10.2018 18:26+3Я не видел ни одной роли для salt'а или ansible'а, которая бы делала blue-green deployment. А в k8s — оно из коробки и офигенно работает.
Blue-green-deployment — это когда при апгрейде софта мы поднимаем новые реплики на новой версии, потом перекидываем нагрузку с одной из старых реплик на новую, и выводим старую реплику из эксплуатации. Потом ещё раз и ещё — пока кластер целиком не переползёт на новую версию.
Чтобы «поднять ещё одну реплику» нужно иметь систему, которая может быстро поднять "-цать копий серверов". Динамически, с мониторингом живости и прибитием лишнего. Вручную такое на chef/ansible/puppet написать можно — они все тьюринг-полные. Но k8s уже написан и протестирован, так что зачем писать своё?boblenin
30.10.2018 19:06Ну как альтернатива для B/G deployment может быть PaaS, но с ним идет vendor lock.
tagirb
31.10.2018 14:38Коллега как раз сваял на днях blue-green для AWS (ALB + blue ASG / green ASG) на Terraform. То же можно было бы сделать и на Ansible.Так что варианты есть.
amarao
31.10.2018 15:01+1Конечно, вариант «написать своё» всегда есть. Стоит взять тьюринг-полное нечто (а ансибл тьюринг-полный, плюс позволяет цеплять свои модули на питоне, который не только тьюринг-полный, но ещё и язык программирования), как сразу же можно написать что угодно. Хоть операционную систему, хоть систему оркестрации.
Проблема в том, что ансибл (и т.д.) — это системы управления конфигурациями. И только. У них в workflow нет понятия «реакции на несвязный факап». А у систем оркестрации оно должно быть в центре внимания.
Ансибл может в любой момент времени проверить, что у нас есть N рабочих реплик. Но он не может это проверять в каждый момент времени. Например, ансибл убедился, что у нас N+1 рабочих реплик и пошёл сносить реплику N+1. В это время реплика 2 сдохла.
Оркестрация в такой ситуации снесёт N+1'ую реплику, и тут же запустит N'ую (потому что рабочих реплик стало N-1). А ансибл радостно зарепортит «всё сделано».
Можно завернуть ansible в цикл. Но это начинает подозрительно напоминать написание супервизора. На ансибле. Смешно.
0xd34df00d
31.10.2018 03:03Интересный отзыв о скриптовых языках, а где вы компилируете ваш «компилируемый» софт? А что если shared библиотеки, которые вы используете не установлена в другой ОС или имеют расхождения по версиям, но это еще просто.
Например, пользуюсь stack'ом. Получаю reproducible build'ы, возможность иметь разные версии одной и той же библиотеки для разных проектов, и так далее. И библиотеки сами ставятся, да.
Sabubu
30.10.2018 15:54+1Ну вот я пытался запустить старый Firefox, например 3.5 или около того, на современном Дебиане. Не работает. Более новая библиотека GTK, казалось бы, должна быть обратно совместима, но по факту — нет (видимо, в старой версии не было какой-то проверки и код работал, а в новой проверки ужесточены). Как мне запускать этот старый фаерфокс на новой системе?
Контейнеры тут могли бы быть удобным решением, правда надо еще найти, как в контейнер запихнуть древнюю версию библиотеки и древнии версии ее зависимостей.
То есть проблема в убогости пакетных менеджеров, которые не способны поддерживать установку нескольких версий одной библиотеки, а умеют лишь ставить самое новое.khim
30.10.2018 17:08-2То есть проблема в убогости пакетных менеджеров, которые не способны поддерживать установку нескольких версий одной библиотеки, а умеют лишь ставить самое новое.
Нет, конечно. Пакетные менеджеры прекрасно ставят множество версий одной библиотеки — если они объявлены несовместимыми. Скажем GTK+1.2 и GTK+2.0 отлично уживаются.
А вот если разработчики на совместимость «забивают» и порождают две версии библиотек, которые, вроде как бы, должны быть совместимыми, но де-факто совместимыми не являются… тогда у вас беда.
То есть да — docker, podman и прочие решают именно проблему криво написанных программ… но других-то у нас нет…amarao
31.10.2018 12:54Если все будут писать софт без багов — половину современного ИТ можно выкидывать за ненадобностью.
Если же мы имеем ситуацию с несовместимостью между ABI версий библиотек, то это обычная проблема, ничем не лучше и не хуже любой другой.
И добротное IT должно уметь продолжать жить даже с таким багом, а не закрываться со словами segmentation fault… Пардон, incompatible call bla-bla-bla.
Sabubu
31.10.2018 14:16Извините, но мой опыт, в т.ч. с Фаерфоксом, показывает что декларируемая ситуация часто отличается от реальности. В теории библиотеки совместимы — а по факту нет (пример: новая версия более тщательно проверяет входные параметры, а программа передает в них некорректные значения, что работало со старой версией). Да, может быть старый Фаерфокс неправильно работает с библиотекой и содержит ошибку, однако мне нужны не объяснения, а работающий браузер.
Cenzo
01.11.2018 00:07Учтите только, что в контейнерах библиотеки тоже надо постоянно обновлять, чтобы не нарваться на серьезные проблемы с безопасностью. И точно такая же проблема с проверкой параметров в API может вылезти после обновления. А по факту часто имеем «работает — не трожь» и сопутствующие дыры, которые эксплуатируются. Не теоретически, а вполне на основе опытных данных.
Hardcoin
30.10.2018 18:08гораздо выгоднее софт научиться нормально писать
Можно ли увидеть какие-либо расчеты в подтверждение вашей позиции? Или это ваше личное мнение, которое не обязано быть правильным?
tendium
31.10.2018 12:24Докер (и контейнеризация вообще) позволяет гарантировать одинаковые условия исполнения кода. Это в свою очередь снижает (хотя и не отменяет полностью) ситуации а-ля «а у меня локально всё в порядке».
Плюс, рядовой ситуацией является несколько одновременно поддерживаемых релизов одного и того же софта. Иногда новый релиз ведет к частичному нарушению обратной совместимости (например, за счет изменения дефолтов). Кроме того, только что вышедший релиз используемого стороннего ПО может иметь изъяны, т.к. он не проверен временем на продакшне. Поэтому переход с одного релиза на другой может быть достаточно рисковым, и делать его только лишь потому, что так хочется вам лично, не стоит.
При этом достаточно просто и легко опробовать новый релиз, даже если для вашей любимой серверной ОС он не был выпущен. И тут (при вашем отношении к докеру) либо компилировать самому (что может стать увлекательным приключением), либо рисковать, подключая сторонние репозитории.
Всех этих проблем вы можете избежать, используя контейнеризацию. И да, к вопросу о скриптовых языках, надеюсь, это была неудачная шутка. Погуглите, сколько сервисов с миллионными и даже миллиардными доходами, написано с использованием Python. В общем, вспоминается старая поговорка про корреляцию ума и богатства.
stratosmi
01.11.2018 10:28затраты на внедрение\обслуживание не окупаются
Программист приносит больше реальной пользы, когда сосредоточен на создании/поддержании собственно прикладной ценности создаваемого им продукта, а вовсе не технологической обвязки (обвязка — это в том числе поддержка совместимости с различными внешними средами).
MIKEk8
30.10.2018 13:39Спасибо. Очень «полезная» статья. Напился вдоволь.
Извиняюсь за токсичность, но очень обидна когда тема не раскрыта.shurup Автор
30.10.2018 13:42+1К сожалению, комментарий не раскрывает тему того, что не раскрыто.
MIKEk8
30.10.2018 14:40+9По конкретики:
Куча ненужной информации, от историй названий, до упоминания версий и таблице сравнения команд где только 2 отличаются.
Но при этом не раскрыты преимущества. Есть техническое описание что оно может, но непонятно зачем это может пригодится.
Упоминается какое то их виденье, но в чём оно заключается не сказано, или плохо уловимо.
Можно было перечислить какие инструменты у них есть, и какую роль во всём этом играет libpod.
Конечно есть ссылки, но это не сильно спасает.
Напримет:Среди зависимых компонентов для работы Podman — такие утилиты для Linux-контейнеров, как runc и conmon, а также сетевые плагины CNI.
Для тех кому эти названия ни о чём не говорят, это выглядит как рандомный факт. Да есть ссылки, но мало у кого после прочтения README появляется понимание хорошо это или плохо. А если это и не хорошо и не плохо, то на что влияет?
Итог: У вас получилась не популярная статья, а сухая глава из учебника, причём с одним лишь примером вне контекста. Понять может только тот кто и так знает. А как вы писали в заголовке «чтобы познакомиться с ним, узнать о его истоках и подумать о перспективах», но такая манера повествования ясности не вносит.shurup Автор
30.10.2018 15:17+1> непонятно зачем это может пригодится
Об этом написано здесь:
В целом же основная задумка Podman заключается в том, чтобы предоставить пользователям Kubernetes, выбравшим CRI-O в качестве исполняемой среды для контейнеров, аналог консольного интерфейса Docker CLI
Далее — почему же тогда не Docker CLI, сказано здесь:
принципиальная разница в архитектуре: если Docker CLI для выполнения команд общается с демоном Docker, то Podman — самостоятельная утилита, не требующая никаких демонов для своей работы
> Для тех кому эти названия ни о чём не говорят, это выглядит как рандомный факт.
Признаюсь, эта статья ориентирована не на тех, для кого такие названия, как runc и CNI, ни о чём не говорят. Чтобы таким людям было проще, есть многократные ссылки на обзор CRI-O, где эта тема раскрыта. Дублировать её в данной статье не посчитал уместным, а к этому, как я вижу, и сводится всё основное непонимание и видимый недостаток раскрытия темы…
P.S. К вопросу о преимуществах и сравнениях: Podman по сути своего предназначения интереснее сравнивать с упомянутым в начале статьи cri-containerd от Docker Inc. И есть на эту тему взгляд со стороны Red Hat.MIKEk8
30.10.2018 16:31Спасибо за пояснения. Прочитав «обзор CRI-O» стало намного понятней. Правда всё равно не понятно чем их не устраивает демон в докере, но я думая что в комментарии ниже есть ответ.
Как я сейчас понял HR делают свою «оболочку» частично на основе уже стандартизованных элементов докера и в соответствии с «Проект следует идеологии UNIX-команд, где каждая утилита делает лишь одну вещь, но хорошо.».
А изначально из статьи складывалось впечатление (как выше писали NIH), делаем свой велосипед потому что свой. Пара мелких фишек которые непонятно зачем нужны — не в счёт.shurup Автор
30.10.2018 16:42Спасибо и вам за комментарии. Добавил в материал абзац с ссылкой на сравнение Podman с containerd/crictl и соответствующим комментарием.
P.S. Несмотря на всё, грань с NIH в таких случаях всё же довольно тонкая, поэтому иметь её в виду тоже стоит.
grey_kristy
30.10.2018 14:47+2А зачем? Чем Docker не устраивает?
Develar
30.10.2018 15:16+2Вот этот тикет может пролить свет — https://github.com/containerd/containerd/issues/2288
amarao
30.10.2018 18:28+4Меня — тем, что он очень opionated. Тот же lxc для жизни лучше, но pod'ов не хватает. Очень надеюсь, что эта штука взлетит.
Ключевая проблема состоит в том, что RH хочет из управлялки контейнеров сделать простую тупую ясную утилиту. А Docker (компания) хочет быть business value, чтобы все на неё обращали внимание и думали docker way.
Утилита лучше, чем чужое business value, потому что утилита полезнее.
Gizmich
30.10.2018 15:33+1В целом же основная задумка Podman заключается в том, чтобы предоставить пользователям Kubernetes, выбравшим CRI-O в качестве исполняемой среды для контейнеров, аналог консольного интерфейса Docker CLI (для взаимодействия с контейнерами и образами, запущенными в кластерах):
«Podman реализует 38 из 40 команд Docker CLI, определённых в Docker 1.13 (на момент анонса в феврале — прим. перев.), но некоторые из них мы специально не повторяли.
Это я так понимаю когда мы хотим Докер, но что бы это был не Докер. Из статьи я чесно говоря не понял принципиальной разницы. Или должно быть какое-то сравнение производительности или чего-то еще.shurup Автор
30.10.2018 16:39Есть ссылка на сравнение производительности runc в разных реализациях (в т.ч. CRI-O и containerd, с которым уместнее сравнивать, чем просто Docker*), приводившееся в этой статье. Вот оно:
(его источник)
* Если сравнивать ещё с самим Docker, то налицо как минимум значимое архитектурное отличие (не нужен демон), поэтому корректнее всё же рассматривать Podman vs. containerd/crictl. Здесь есть функциональные отличия — информацию об этом добавил в текст статьи, спасибо!
sergeyns
30.10.2018 15:38+1Щас IBM развернется на ниве проприетарного софта… Чувствую что через пару лет весь софт от IBM будет идти в виде докер контейнеров с «модифированным» RH внутри, а внутри него — уже свой podman, и уже внутри этой матрешки — микросервисы ))).
elcamlost
30.10.2018 17:48+1Правильно ли я понимаю, что если я просто пользуюсь докером без k8s (для развертывания локальной dev среды через compose), то никаких преимуществ от podman не получу?
shurup Автор
30.10.2018 18:21Технически это сделать можно (вот, кстати, онлайн-сценарий от Katacoda для такого знакомства — добавил его заодно и в статью), но практический смысл… Разве что вам почему-то надоел запущенный в системе демон Docker или хочется интегрировать запуск контейнеров с системными сервисами (через systemd). Глобально же это скорее интересно тем, кто собирается запускать контейнеры в «таком же виде» в Kubernetes — тогда всё будет унифицировано.
tagirb
30.10.2018 20:23Коллега как раз сваял на днях blue-green для AWS (ALB + blue ASG / green ASG) на Terraform. То же можно было бы сделать и на Ansible.Так что варианты есть.
scruff
31.10.2018 11:25Можете хотя бы тезисно рассказать, как это делается через Ansible, кусочками из play-book? Спасибо.
tagirb
31.10.2018 14:43В смысле, blue-green? Извините, я тут просто случайно «не в ту ветку» написал, вот ссылка в «ту ветку»: habr.com/company/flant/blog/426141/#comment_19307065.
Sovetnikov
30.10.2018 20:40+1А я вот тоже не понял, чем оно отличается от docker для пользователей? Какие плюсы?
Только очень много раз прочёл «стандарт».Ipeacocks
30.10.2018 21:02+1Дело не в этом, docker многих не устраивал: они делали новые версии без оглядки на продукты, которые им пользуются и не очень заботились об обратной совместимости. Более того Docker — это оверхед для продуктов типа Kubernetes.
Envek
31.10.2018 00:54+1Для пользователей, которые разработчики прикладного софта и оборачивают результат своей работы в контейнеры — разницы почти никакой
А вот для админов, которые это всё добро запускают — разница большая. Докер тяжёлый, тащит много своего ненужного стека, который в продакшене хочется заменить на что-нибудь другое (та же работа с сетью), докер-демон иногда зависает (не запускает новые контейнеры и не останавливает старые).
Основной запрос на переход Docker > CRI-O исходит как раз от админов.
Более того, благодаря всем этим усилиям и инициативам OCI по стандартизации этого добра, разработчики в принципе могут собирать образы Docker'ом, а админы — запускать их CRI-O
creker
31.10.2018 03:00К слову, инициатива это исходит от докера, т.к. он передал многие свои компоненты в OCI, стандартизировал форматы и прочее. Собственно, они и были в числе основателей OCI.
creker
31.10.2018 02:58+1Тем, что все эти начинания с cri-o делаются для совсем других целей — сделать легковесный рантайм для кубернетиса и ему подобных. Никто убийцу докера писать не собирался и не пишет. Докер остается в своей нише, а в нише маленького компонента кубернетиса он выглядит слишком большим и сложным, поэтому его заменяют на крио. Хотя докер все еще остается доминирующим и дефолтным вариантов. Все таки устоявшийся взрослый продукт. Подман тут видится разве что для совсем узкий кейсов — потестить, поиграться. Смысла запускать у себя машине это все никакого. Докер тут нужнее, а смысла ворочать руками контейнеры, когда у тебя кубернетис, тем более не видно.
Ipeacocks
30.10.2018 20:58Docker RIP?
creker
31.10.2018 02:53Он никуда не денется, т.к. является основой цикла разработки. Локальное тестирование, простые кейсы, где нужно просто запустить что-то в контейнере. Смысла линять с докера в этих случаях никакого. Да и альтернатив нет — для мака вот есть шикарное интегрированное докер решение, будто у меня контейнеры прям в макоси. Все эти крио даже не суются сюда и не собираются докер вытеснять, это не их ниша.
viras777
31.10.2018 21:16-2Как убого выглядит мир линукса с контейнерами и насколько всё красиво во FreeBSD :)
isden
01.11.2018 09:54> красиво во FreeBSD
А не могли бы вы раскрыть мысль? Мне правда интересно. Когда я последний раз трогал FreeBSD, там были простые Jails. Простые — в смысле что-то больше похожее на lxd.
Но это было довольно давно, может быть сейчас уже завезли что-то более интересное?viras777
01.11.2018 10:14Я скорее имел ввиду идеологию подхода в разных ОС, например, захотели 2-й питон, зашли в те же порты, поставили, захотели 3-й питон, зашли и поставили. Что замечательно, так это то, что они сосуществуют вместе со всеми своими либами и зависимостями в одной ОС и без контейнеров (да, jail есть и это рабочий инструмент для продакшена). Аналогично и с другими проектами. В линуксе, что не день, то сюрприз. Опять же пример, вечером уходил — всё работало, утром запустил компьютер и нет модуля управления рабочими столами, обновил ОС (centos), пропала менюха.
Как я вижу, во FreeBSD ОС — это комплект ядра, окружения, и даже пакетов. В Линуксе, больше выбор, но приходится платить за это кровью админов)))isden
01.11.2018 11:07Ну справедливости ради, 2 и 3 питон одновременно держать в системе не проблема.
Неудобства начинаются когда надо одновременно, ну возьмем для примера php — 5.2,5.3,5.6,7.0,7.2 (не спрашивайте зачем). Можно конечно все это развернуть на одной системе, но это получится адский ад. Гораздо удобнее запихать разные версии в разные контейнеры и наслаждаться чистотой и порядком в системе.
А еще докер — это не только изоляция приложений.
MMik
Спасибо за статью. Всё ещё временами путаю CRI-O с CRIU (Checkpoint/Restore In Userspace).