Comments 116
Спасибо за статью. Всё ещё временами путаю CRI-O с CRIU (Checkpoint/Restore In Userspace).
А вот кто проголосовал за «Реальное использование (в production или близко)» — подскажите плз, чем оно лучше докера и стоит ли начать думать об экспериментах с миграцией?
Все эти Docker'ы нужны только для кривого софта способного работать только на побитовых копиях ОС разработчиков. Как следствие вместо повышения качества софта создается целая экосистема костылей. В начале был Docker сейчас podman, через года два еще что-то увидим.
Сами по себе эти технологии пустые и затраты на внедрение\обслуживание не окупаются просто потому, что гораздо выгоднее софт научиться нормально писать, чем нанять целый отдел DevOps'ов который будет весь этот ужас обслуживать.
И да, Docker популярен только там где люди пишут только на скриптовых языках. В нормальных компилируемых потребность в нем отсутствует. Нет можно конечно упороться и запихнуть в него софт, но зачем?
>Это все очень круто и здорово пока у вас части приложения не требуют разных версий библиотек ставящихся через пакетный менеджер, который ставит только одну
Значит это или плохо написанное приложение или хреновый пакетный менеджер если в нем такие проблемы есть. Другого не дано.
Да и новые версии библиотек не просто так выпускают. Часто в них дыры и ошибки находят. Согласно логике фанатов Докера предлагается вместо решения задачи обновления версий библиотек просто засунуть все в контейнер и надеяться, что оно как-то обойдется. Великолепная логика!
Пока дураки жмут штангу фанаты Docker катают ее по полу и смеются.
Сами по себе эти технологии пустые и затраты на внедрение\обслуживание не окупаются просто потому, что гораздо выгоднее софт научиться нормально писать, чем нанять целый отдел DevOps'ов который будет весь этот ужас обслуживать.
И да, Docker популярен только там где люди пишут только на скриптовых языках. В нормальных компилируемых потребность в нем отсутствует. Нет можно конечно упороться и запихнуть в него софт, но зачем?
>Это все очень круто и здорово пока у вас части приложения не требуют разных версий библиотек ставящихся через пакетный менеджер, который ставит только одну
Значит это или плохо написанное приложение или хреновый пакетный менеджер если в нем такие проблемы есть. Другого не дано.
Да и новые версии библиотек не просто так выпускают. Часто в них дыры и ошибки находят. Согласно логике фанатов Докера предлагается вместо решения задачи обновления версий библиотек просто засунуть все в контейнер и надеяться, что оно как-то обойдется. Великолепная логика!
Пока дураки жмут штангу фанаты Docker катают ее по полу и смеются.
Это все очень круто и здорово пока у вас части приложения не требуют разных версий библиотек ставящихся через пакетный менеджер, который ставит только одну. Не говоря уже о том что раздельные окружения менее зависимы друг от друга и ими проще управлять. Я уже молчу что разбив на все это на детальки, можно масштабировать одни части и не трогать другие.
Вы поймете все неудобства когда вам придется компилировать два приложения требующих разные версии библиотек. И нет, даже компилируему приложению может понадобиться бд/редис/что то еще что может быть неудобно ставить/настраивать в том же окружении.
Не понимаю вашего скепсиса.
Затраты на обслуживание/внедрение окупаются когда у вас 10 кодеров вместо одного дорогого системщика и сервис надо масштабировать на большое количество людей.
Вы поймете все неудобства когда вам придется компилировать два приложения требующих разные версии библиотек. И нет, даже компилируему приложению может понадобиться бд/редис/что то еще что может быть неудобно ставить/настраивать в том же окружении.
Не понимаю вашего скепсиса.
Затраты на обслуживание/внедрение окупаются когда у вас 10 кодеров вместо одного дорогого системщика и сервис надо масштабировать на большое количество людей.
а что мне помешает использовать старую какую-нибудь старую 100 лет известную виртуализацию (kvm/openvz и тд) вместо докера?
Мешают значительно большие накладные расходы на эту «старую» виртуализацию.
OpenVZ — это те же контейнеры. Только с хранением состояния, т.е. аналоги виртуальных машин, только они легковснее и + в принципе все плюсы и минусы контейнеров.
Т.е. если вернуться к теме вопроса
> а что мне помешает использовать старую какую-нибудь старую 100 лет известную виртуализацию (kvm/openvz и тд) вместо докера?
Ну с виртуалками будет просто долго, потому как они большие и производительность, как вы сказали будет ниже через дополнительные слои абстракий. С openvz — потому что он не мейнстрим, а с Docker все получится, потому что он чертовски популярен.
Т.е. если вернуться к теме вопроса
> а что мне помешает использовать старую какую-нибудь старую 100 лет известную виртуализацию (kvm/openvz и тд) вместо докера?
Ну с виртуалками будет просто долго, потому как они большие и производительность, как вы сказали будет ниже через дополнительные слои абстракий. С openvz — потому что он не мейнстрим, а с Docker все получится, потому что он чертовски популярен.
Docker контейнер потребляет столько памяти, сколько ему сейчас нужно. Может занимать и освобождать память. KVM виртуалка требует отвести память заранее. Её можно увеличивать путём удваивания (но это небыстро), а освобождать вообще нельзя.
Docker стартует моментально, виртуалка грузится.
Docker имеет ядро одно на всех, виртуалки каждая — своё, и они поддерживают кучу внутренних состояний, которые в виртуалке нафиг не нужны.
Docker использует системное IO, виртуалка даже с virtio вынуждена что-то трансформировать и переорганизовывать.
Docker умеет централизованно обновляться из репы, виртуалки каждая по-своему.
Docker compose и swarm умеют такое, под что на виртуалках отдельный человек необходим.
Так можно продолжать очень долго. Эпоха кручения серверов в виртуалках ушла*. Учите Docker.
* кроме некоторых особых случаев безопасности. И Windows.
Docker стартует моментально, виртуалка грузится.
Docker имеет ядро одно на всех, виртуалки каждая — своё, и они поддерживают кучу внутренних состояний, которые в виртуалке нафиг не нужны.
Docker использует системное IO, виртуалка даже с virtio вынуждена что-то трансформировать и переорганизовывать.
Docker умеет централизованно обновляться из репы, виртуалки каждая по-своему.
Docker compose и swarm умеют такое, под что на виртуалках отдельный человек необходим.
Так можно продолжать очень долго. Эпоха кручения серверов в виртуалках ушла*. Учите Docker.
* кроме некоторых особых случаев безопасности. И Windows.
И в windows есть контейнера и не только Hyper-V, так что можно вычеркивать)
Эпоха кручения серверов в виртуалках ушлабред. Все облака почему-то на виртуализации основаны, а не на голом железе + никто вам не мешает ворочать контейнеры докером внутри виртуальной машины.
Одно другому никак не противоречит. Облака на виртуалках, потому что альтернатив у них нет — изоляция нужная же какая-то. Но вот все, кто повыше сидят, с виртуалок слезли на контейнера и эпоха действительно прошла. Очень забавно в этом всем видеть таких как vmware, которые всеми ногами и руками впихывают в свою архитектуру контейнеры где-то сбоку криво и косо, лишь бы вписалось как-то в существующий стек.
gke в gce который в borg))
контейнеры, которые ранятся в виртуалках, которые, в свою очередь, ранятся в контейнерах
контейнеры, которые ранятся в виртуалках, которые, в свою очередь, ранятся в контейнерах
> Docker использует системное IO, виртуалка даже с virtio вынуждена что-то трансформировать и переорганизовывать.
нет. Докер дает оверхед на сеть и делает безумно сложным многие сетевые штуки, которые кое как возможно сделать на виртуалках.
нет. Докер дает оверхед на сеть и делает безумно сложным многие сетевые штуки, которые кое как возможно сделать на виртуалках.
100 лет известную
Вы переборщили.
kvm/openvz и тд
Докер использует изоляцию в ОС, то есть:
- Всех обслуживает одна ОС, то есть:
- В память грузится одно ядро ОС (и лицензируется тоже одно ядро)
- Файловая система может быть одна на всех, с дедупликацией и т.д.
- Эта ОС полностью контролирует всё железо, а не определенную его часть.
- Каждое приложение запускается в отдельной cgroups (или Job Objects в Windows), то есть:
- Процессы из одной группы не видят таковых из другой
- Нельзя прыгнуть в память чужого cgroups (ну т.е. изоляция)
- Можно ограничить объем ресурсов для cgroups, то есть процессорное время, объем памяти, нагрузку на IO и пр.
- Любое приложение для мониторинга может следить сразу за всеми (т.е. в отличии от виртуализации — не надо запускать по одному инстансу на каждом хосте)
Еще раз, это важно: в случае контейнеров у вас одна ОС, которая распределяет ресурсы. А не много разных ОС. У вас прямой доступ к файловой системе, никто не пишет в ФС виртуальной машины, чтобы потом хост перенаправил блок к ФС уже реального хоста. За счет этого получается практически идеальная кооперация между компонентами, т.к. в памяти нет ничего лишнего, кроме ядра ОС и процессов внутри контейнеров. Тот же докер ничего дополнительного не проксирует (кроме запуска/остановки контейнеров).
Аналоги подобной штуки:
- В iOS каждое приложение запускается от отдельного пользователя, что автоматом дает изоляцию ресурсов (тех же файлов)
- В Windows вы можете залогиниться разными пользователями в разные сессии и не мешать друг другу. Причем все это не уберет фишек дедупликации данных на диске.
В виртуализации вы сразу:
- Лишаетесь дедупликации (и схожего переиспользования ресурсов) на файловой системе хоста
- Заставляете под каждую виртуальную машину поднимать отдельное ядро системы (кстати, заодно и за лицензии заплатите, ведь на одной машине у вас будет несколько запущенных серверов), которое будет добавлять задержки к куче операций, таких как работа с внешними устройствами (с той же сетью), работа с ring-0 (эта часть интерпретируется) и т.д.
- И получаете бонус — можете запускать Linux & Windows на одном хосте.
Резюме: если у вас очень много контейнеров/образов, которые могут быть запущены на одной и той же ОС — контейнеры помогут вам сэкономить ресурсы.
> Лишаетесь дедупликации
Не то чтобы лишаетесь… При активном использовании клонирования дедупликация работает неплохо. А еще можно подключать диски например по iSCSI с хранилки, и тогда будет полноценная дедупликация вообще. Далее, пустое место дедуплицируется хорошо, если не используется thin provision.
Но эффективность будет ниже, это да.
Не то чтобы лишаетесь… При активном использовании клонирования дедупликация работает неплохо. А еще можно подключать диски например по iSCSI с хранилки, и тогда будет полноценная дедупликация вообще. Далее, пустое место дедуплицируется хорошо, если не используется thin provision.
Но эффективность будет ниже, это да.
Соглашусь с beduin01 эта проблема, что вы описали как раз и вылезает из-за того, что существующая система версионирования обычно весьма корявая, и лезет проблема dll hell, которую и решили таким «элегантным» образом. Как бы я не любил в ноде ужас с папкой node_modules, из-за того что все зависимости и лежат в этой папке, вы можете на сервере держать кучу абсолютно разных приложений на ноде, и не знать проблем. В dotnetcore тоже очень хорошо сделали версионирование и докер вроде бы не нужен.
При этом, когда я сталкиваюсь с каким-нить ruby, я понимаю, что тут Docker был просто спасением.
Так что всё зависит от средств разработки и их возможностей. Где-то нафиг не нужен докер, где-то без него не обойтись. И мне больше нравится первый вариант, тогда докер всего-лишь приятное дополнение и удобство деплоя и оркестрации. Но, можно и без него.
При этом, когда я сталкиваюсь с каким-нить ruby, я понимаю, что тут Docker был просто спасением.
Так что всё зависит от средств разработки и их возможностей. Где-то нафиг не нужен докер, где-то без него не обойтись. И мне больше нравится первый вариант, тогда докер всего-лишь приятное дополнение и удобство деплоя и оркестрации. Но, можно и без него.
При этом, когда я сталкиваюсь с каким-нить ruby, я понимаю, что тут Docker был просто спасением.
Спасением от bundler install --help и bundler exec --help?
Докер это не только решение «dll hell», это ещё унифицированный интерфейс и снэпшот кода приложения. Независимо от рантайм окружения вы получаете одно и тоже приложение что на Ubuntu, что на CentOS, что в любом другом линукс дистрибутиве (с виндой дел не имел, не скажу).
beduin01 просто не понимает всех возможностей докера и тех задач которые он решает. Я думаю он просто не умеет им пользоваться или не сталкивался с задачами в которых придётся костыли подпирать костылями если нет докера.
Если бы всё было так красиво как он описал про компиллируемые языки, то докера бы не было и все бы писали и компиллировали, а скриптовые языки были бы малоразвиты.
Докер популярен именно потому, что он решает требуемые задачи с минимальным оверхедом и со стороны ресурсов и со стороны администрирования.
beduin01 просто не понимает всех возможностей докера и тех задач которые он решает. Я думаю он просто не умеет им пользоваться или не сталкивался с задачами в которых придётся костыли подпирать костылями если нет докера.
Если бы всё было так красиво как он описал про компиллируемые языки, то докера бы не было и все бы писали и компиллировали, а скриптовые языки были бы малоразвиты.
Докер популярен именно потому, что он решает требуемые задачи с минимальным оверхедом и со стороны ресурсов и со стороны администрирования.
Если не сторонитесь экзотики, то NixOS
>который ставит только одну.
К слову, gentoo умел слоты и это решалось. Так же, есть всякие python virtualenv именно для этого. Руби вообще штатно позволяет ставить несколько версий (правда, в работе «есть нюансы»).
Но это не «докер не нужен», это к тому что некоторые частные задачи имеют возможность решения и без него.
А для сборки приложения/софта/пакетов вообще правильно держать отдельный сервер/виртуалку и деплоить уже собранное.
К слову, gentoo умел слоты и это решалось. Так же, есть всякие python virtualenv именно для этого. Руби вообще штатно позволяет ставить несколько версий (правда, в работе «есть нюансы»).
Но это не «докер не нужен», это к тому что некоторые частные задачи имеют возможность решения и без него.
А для сборки приложения/софта/пакетов вообще правильно держать отдельный сервер/виртуалку и деплоить уже собранное.
Какая-то каша у вас в голове. Если вы и впрямь считаете, что докер нужен для того, чтобы не учиться писать нормально софт, то это значит, что вы вообще не в теме и размышляете о том, в чём не разбираетесь.
Даже не знаю, как можно комментировать фразу «как следствие вместо повышения качества софта создается целая экосистема костылей» — так можно о всём техническом прогрессе сказать, что автомобили созданы для того, чтобы не ходить «нормально» пешком.
Даже не знаю, как можно комментировать фразу «как следствие вместо повышения качества софта создается целая экосистема костылей» — так можно о всём техническом прогрессе сказать, что автомобили созданы для того, чтобы не ходить «нормально» пешком.
Именно! А компьютеры созданы ленивыми людьми, которые так и не освоили двоичный счёт.
Двоичный счёт тут причём? Первые компьютеры десятичными были. И где-то до 80х использовались двоично-десятичные числа (даже в x86 они есть, хотя мало какие программы их используют)
Компьютеры первой-второй волны работали только двоичных на float'ах, потому что считать надо, а битов было мало. Средний размер слова был 36-38 бит. Двоично-десятичное — это позднее изобретение, чтобы не делать постоянную конвертацию при выводе.
Забавно иногда обнаружить ошибочный некропост — да ещё и заплюсованный. Правда ошиблись мы оба, стоит признать. ENIAC работал только с десятичными числами, двоичных там не было…
>это значит, что вы вообще не в теме и размышляете о том, в чём не разбираетесь.
Дружище, каша в голове не у меня, а у тебя. Не я, а ты освоил разные говно языки и поимел с ними изрядный баттхерт. То что ты не умеешь собирать переносимый софт это лично твои проблемы. Я имел богатый опыт работы с дебилами, которые пытались решить через Docker проблемы своих кривых арихитектур. Ни у кого ничего путного из этого не вышло. Я не думаю что ты чем-то от них отличаешься.
Дружище, каша в голове не у меня, а у тебя. Не я, а ты освоил разные говно языки и поимел с ними изрядный баттхерт. То что ты не умеешь собирать переносимый софт это лично твои проблемы. Я имел богатый опыт работы с дебилами, которые пытались решить через Docker проблемы своих кривых арихитектур. Ни у кого ничего путного из этого не вышло. Я не думаю что ты чем-то от них отличаешься.
Чувак, судя по твоему стилю изложения, место тебе где-нибудь среди трактористов :)
Сдаётся мне, скоро ты получишь почётный значок тролля, кем на самом деле ты и являешься. Продолжай в том же духе — один ты достойный Лорд, а остальные все дебилы.
Сдаётся мне, скоро ты получишь почётный значок тролля, кем на самом деле ты и являешься. Продолжай в том же духе — один ты достойный Лорд, а остальные все дебилы.
Ага, и когда новый проект на своей машине запускаешь — тоже все себе в систему ставишь, да?
Дружище, расскажи как ты такой умный и гениальный со своим качественно написаным переносимым софтом будешь реализовывать масштабирование сервиса в 1 клик? :) А заодно расскажи как ты будешь это все решать когда используется софт не только твоей гениальной разработки? :)
Какая-то каша у вас в голове.Справедливости ради из этих ваших докеров тоже изрядная каша. Во-первых, их тут оказалось разновидностей вагон и маленькая тележка. Во-вторых, есть полу-виртуализация lxc, openvz и, наверное, ещё. В третьих, есть такая хрень, как виртуализация в рамках интерпретатора (virtualenv для питона). В четвёртых, есть module для линуксов. И это только примеры известные мне.
Это не костыли, это просто откладывание сегодняшних проблем с совместимостью на неопределённый срок. Что потом? Потом будут нанимать людей для поддержки сайтика на старой джанге на python2 с кучей хлама в venv, которое вертится в (к тому времени) морально устаревшем докере в виртуальной машине с федорой 7, который нужно перенести на выделенный сервер из-за того, что амазон отказался поддерживать старый образ. Примерно в этот момент и начинается настоящее веселье, о котором, почему-то, не сообщают на презентациях.
Да-да, всё так. Именно поэтому забросим контейнеры, облака, фреймворки, паттерны, ide и прочие демонические базы и вернёмся к ibm-286 и написанию сайтегов в блокноте. И всё потому, что современные технологии для определённых личностей сложны в силу их консервативности, если не лени.
Вы занимаетесь демагогией. Если вы зарабатываете сайтиками на джанге, то это не значит, что людям, которые работают над софтом для миллионов запросов в секунду не нужны все эти докеры. А то бы так и писали сайтеги на джанге в блокноте.
Вы занимаетесь демагогией. Если вы зарабатываете сайтиками на джанге, то это не значит, что людям, которые работают над софтом для миллионов запросов в секунду не нужны все эти докеры. А то бы так и писали сайтеги на джанге в блокноте.
У вас такая же полярная точка зрения как и у того чувака. Эти технологии сложны не потому что, по вашему мнению, кто-то что-то не понимает. Они сложны потому что их сложно заставить работать вместе и сложно использовать за рамками примеров из документации. Рано или поздно, во всем это замечательном нагромождении из докеров и софта, делающего миллион запросов в секунду, неизбежно появляется маленький скриптик, меняющий LD_LIBRARY_PATH (это пример). Хотя, казалось бы, ничего особенного не произошло, примерно с этого момента никто из уважаемых людей, пишуших софт, делающий миллион запросов в секунду, не знает, как вся эта каша работает на самом деле. А потом решают обновить докер и, в результате, ваш хвалёный софт делает 0 (ноль) запросов секунду. А ещё оказывается, что вместо новой модной технологии в данном конкретном случае можно было статически слинковать httpd и бед не знать.
Но это не значит, что эти технологии не надо использовать. Во-первых, разработка может зависеть от бизнес-факторов и, во-вторых, может просто не быть альтернативы.
Но это не значит, что эти технологии не надо использовать. Во-первых, разработка может зависеть от бизнес-факторов и, во-вторых, может просто не быть альтернативы.
Они сложны потому что их сложно заставить работать вместе и сложно использовать за рамками примеров из документации.
Правда? Ужас то какой. Как же я это всё запускаю то?
Документация бывает конечно ужасной и зачастую приходится либо искать хаутушки (тоже кривые зачастую) или сидеть и самому глубоко вникать. Обычно эти проблемы только в начальных релизах, если софт становится популярным, то эти проблемы зачастую уходят сами, в процессе развития.
Вы описали обычные проблемы обслуживания.
Да, были lxc, openvz и т.д. И они использовались. Но с ними была одна большая проблема — практически в каждом проекте реализация была разной, тесты и деплой были разными. Докер просто перенес все это в массы, с более менее стабильными интерфейсами. С одной стороны программисты получили легкий способ поставки своего кода в стабильном окружении, с другой стороны администраторы получили инструмент для более эффективного управления приложениями и окружениями. При этом им не нужно при переходе с одного проекта на другой что-либо изучать. Работодатели за счет этого получают сокращение расходов. Тут вин со всех сторон.
Но, как раньше, так и сейчас, нужны все-таки люди, которые понимают то, с чем работают, а то будет либо как у Аэрофлота — вываленный наружу интерфейс докера, либо как вы описали — говнокод с адом в зависимостях.
Да, были lxc, openvz и т.д. И они использовались. Но с ними была одна большая проблема — практически в каждом проекте реализация была разной, тесты и деплой были разными. Докер просто перенес все это в массы, с более менее стабильными интерфейсами. С одной стороны программисты получили легкий способ поставки своего кода в стабильном окружении, с другой стороны администраторы получили инструмент для более эффективного управления приложениями и окружениями. При этом им не нужно при переходе с одного проекта на другой что-либо изучать. Работодатели за счет этого получают сокращение расходов. Тут вин со всех сторон.
Но, как раньше, так и сейчас, нужны все-таки люди, которые понимают то, с чем работают, а то будет либо как у Аэрофлота — вываленный наружу интерфейс докера, либо как вы описали — говнокод с адом в зависимостях.
Но с ними была одна большая проблема — практически в каждом проекте реализация была разной, тесты и деплой были разными.Это завление прямо противоположно моим представлениям о виртуализации и докерах. Наверное, я чего-то не понимаю. Я думал я прямо сейчас могу снять lxc инстанс за десятку и вообще не знать, на чём он вертится кроме версии ядра.
С одной стороны программисты получили легкий способ поставки своего кода в стабильном окруженииПакеты в ОС, eggs/wheels в питонах — везде есть свой способ (и надежный!) поставлять код с зависимостями на неизвестную систему невзирая на окружение.
Вы описали обычные проблемы обслуживания.Ну да, кто-то раньше наговнокодил и теперь это надо обслуживать. Что это если не откладывание проблем?
Что это если не откладывание проблем?Их никто и не откладывает. Вы мешаете теплое с мягким. Это не проблемы докера, если у коддера руки из жопы и в голове каша — это будет и в докере, и в lxc.
Но, как ни крути, для тех, кто активно использует контейнеры, они заметно упрощают цикл разработки/поставки. И те, кто сидел на lxc, постепенно начинают переходить на докеры, кубернеты, и прочее…
Это не проблемы докера, если у коддера руки из жопы и в голове каша — это будет и в докере, и в lxc.Ой вот только не надо этого: хорошие кодеры первыми набегают на хабр и рассказывают, что им, к сожалению, не платят за хороший код и именно поэтому приложение, показывающее карты на моём телефоне занимает 107 мегабайт и в два раза больше места в оперативке. Проблемы докера меня лично, как пользователя, не касаются, но я уверен, что это одна из тех технологий, которые стимулируют говнокодить даже очень хороших программистов. Без докера пришлось бы последовательно обновлять весь стек приложения до самых новых зависимостей, попутно устранять баги, оптимизировать. Но зачем? Можно ж докер, иметь двадцать старых дырявых версий одной и той же libpng и, при необходимости, добавить двадцать первую в один и тот же контейнер. Докер ведь именно для этого и существует: для ваших старых дырявых зависимостей, которые лень разгребать.
Без докера пришлось бы последовательно обновлять весь стек приложения до самых новых зависимостей, попутно устранять баги, оптимизировать. Но зачем?
Любой разработчик работает не на себя, а на бизнес. Даже если этот бизнес свой это всё равно бизнес. И разработчику необходимо либо быстро сделать и выкатить, чтобы получать уже деньги, либо сидеть месяуами и полировать код, но не получать ни копейки.
Думаю тут выбор очевиден.
Дальше, есть рефакторинг. Это позволяет отполировать/переписать уже имеющийся код. Тут тоже чуществует такой же баланс НАДО и ХОЧУ.
И вся бизнес структура на всё этом балансе строится.
А вы транслируете только одну точку зрения «ХОЧУ» в то время как бизнесу требуется «НАДО».
Пакеты в ОС, eggs/wheels в питонах — везде есть свой способ (и надежный!) поставлять код с зависимостями на неизвестную систему невзирая на окружение.
Да ладно, вот вам практический пример — небольшой проект на Java, крутится на Tomcat. Года 4 ему. Один заказчик. Один хостер. Один программист. Казалось бы, какие проблемы? Но время идёт — хочется и Java поновее и Tomcat обновить. Вот только геморройно всё это — надо заказчику объяснить, зачем это нужно, он должен хостеру заявку написать, сервис на время уйдет в даун. Мне перед всем этим надо убедиться, что существующий код будет работать с новой Java (и Tomcat), а если нет, то все притормозить :) В общем и проект простой и заказчик один — а хлопот и согласований на месяц работы.
Так что я теперь докер изучаю. С ним я могу всю работу по обновлению окружения сделать сам — ничего, ни с кем, не согласовывая и никого не тормозя в случае факапа.
В этом месте не имеет значения, используется там «устаревший питон», или оно написано на вечномолодом pascal. Со временем кодовая база устаревает вне зависимости от используемых технологий.
Не знаю, к чему вы это написали, но да, не имеет. Речь идёт о том, использовать что-то или обойтись без чего-то. Если вы отказались от питона или паскаля — уже не имеет значения, когда они устареют. Поэтому, скорость устаревания кодовой базы прямо пропорциональна количеству технологий, от которых эта кодовая база зависит.
Часто в них дыры и ошибки находят
После чего вы обновляете версию библиотеки в Dockerfile и пересобираете контейнер. Не сильно отличается от обычной системы.
С точки зрения security, замечу, что всё-таки отличается не в лучшую сторону. Добавляется новый шаг — найти все контейнеры с уязвимыми библиотеками и пересобрать их _все_. И тут как раз начинается то, о чём предпочитают не упоминать — зоопарк контейнеров, часть контейнеров притянуто извне и неизвестно кем поддерживается, часть контейнеров, скажем, на CentOS 6, потому что их боятся трогать чтобы ничего из работающего не сломать, часть забыли кто и как собирал и так далее.
С этой точки зрения гораздо легче иметь поддерживаемую систему с разделяемыми библиотеками, где обновление одной либы гарантированно исправляет ошибку. Так что у медали всегда две стороны и не стОит закрывать глаза на проблемы тоже.
С этой точки зрения гораздо легче иметь поддерживаемую систему с разделяемыми библиотеками, где обновление одной либы гарантированно исправляет ошибку. Так что у медали всегда две стороны и не стОит закрывать глаза на проблемы тоже.
Вот, самое здравое тут — «притянуто извне и неизвестно кем поддерживается». Ближайшим аналогом этого будет make install для прокси сервера. Что оно там инсталл, куда, никто не знает, но лучше не трогать, ибо работает.
Не могу не согласиться и к сожалению контейнеры поощряют такое поведение — нет видимых проблем, никто не обновляет контейнер. Про сторонние, скачанные со всяких хабов вообще молчу, еще и внешняя зависимость.
Любые формы вендоринга требуют внимания. Статически слинкованные библиотеки (C, Rust, Go), питоновые venv'ы.… Даже динамическая линковка не решает проблемы (С/С++), потому что баг может быть, например, в макросе в хидере библиотеки и только перекомпиляция с обновлённым хидером исправит проблему.
Любые баги компиляторов или транспиляторов тоже фиксятся только перекомпиляцией. А транспиляторов больше, чем кажется — yacc/flex, всякие протобуферы, ORM'ы, которые генерируют классы, etc.
Т.е. в этой ситуации гнать на докер со словами «он скрывает вендоринг» — глупо. Да, вендоринг. Да, большего масштаба чем было. Так оно ради масштаба и делалось.
Любые баги компиляторов или транспиляторов тоже фиксятся только перекомпиляцией. А транспиляторов больше, чем кажется — yacc/flex, всякие протобуферы, ORM'ы, которые генерируют классы, etc.
Т.е. в этой ситуации гнать на докер со словами «он скрывает вендоринг» — глупо. Да, вендоринг. Да, большего масштаба чем было. Так оно ради масштаба и делалось.
Ага, вот только в таких монолитных системах есть тоже свои проблемы. Да, обновление либы исправит уязвимость в 10 продуктах её использующих. Вот только, что вы будете делать если один из продуктов с новой версией либы не работает. А он для бизнеса ой как важен. В 99% админы просто откатят либу на старую версию. Результат 10 дырок.
Дружище, не пугай меня…
Похоже вы не разобрались зачем это вообще нужно. Например хостинги, оптимальное использование мультипроцессорности. А уж легкость и простота сборки и развертывания своих же приложений в изолированных контейнерах, никак не могут быть связаны с кривизной ПО.
Интересный отзыв о скриптовых языках, а где вы компилируете ваш «компилируемый» софт? А что если shared библиотеки, которые вы используете не установлена в другой ОС или имеют расхождения по версиям, но это еще просто.
А представьте что вы для кеша используете Redis, для поиска ElasticSearch, nginx как реверс прокси, будете конфигурировать их каждый раз? Особенно когда вам нужно будет быстро поднять тестовый сервер или к вам в команду пришел новый стажер-программист, как вы долго ему будете объяснять что и как ему нужно установить прежде чем писать код?
А теперь представьте что у вас распределенный high-load проект с хотя-бы 3-4 нодами, и вот вы решили что вам нужно поменять версию БиблиотекиX везде и вместо того чтобы обновить образ в докере вы шлете сис-админа чтобы тот аккуратно не помешав работе вашего сервиса все обновил. И вот, долгожданный релиз, а БиблиотекиX в новой версии обзавелась мемликом и теперь вам нужно все снова откатывать.
Таких ситуаций полно, к сожалению, и дело не в том что софт «херовый», а в том что он сложный использует тысячи библиотек, зависимостей, сторонних сервисов и аппликаций.
А представьте что вы для кеша используете Redis, для поиска ElasticSearch, nginx как реверс прокси, будете конфигурировать их каждый раз? Особенно когда вам нужно будет быстро поднять тестовый сервер или к вам в команду пришел новый стажер-программист, как вы долго ему будете объяснять что и как ему нужно установить прежде чем писать код?
А теперь представьте что у вас распределенный high-load проект с хотя-бы 3-4 нодами, и вот вы решили что вам нужно поменять версию БиблиотекиX везде и вместо того чтобы обновить образ в докере вы шлете сис-админа чтобы тот аккуратно не помешав работе вашего сервиса все обновил. И вот, долгожданный релиз, а БиблиотекиX в новой версии обзавелась мемликом и теперь вам нужно все снова откатывать.
Таких ситуаций полно, к сожалению, и дело не в том что софт «херовый», а в том что он сложный использует тысячи библиотек, зависимостей, сторонних сервисов и аппликаций.
Почему же админ должен это делать руками? Разве DSC системы с этим не помогут? В каком-нибудь стейте «соли» прописать новую библиотеку и запустить раскатку стейтов на ноды, сложностей вроде не больше, чем обновлять докер образы и так же их деплоить.
Я не видел ни одной роли для salt'а или ansible'а, которая бы делала blue-green deployment. А в k8s — оно из коробки и офигенно работает.
Blue-green-deployment — это когда при апгрейде софта мы поднимаем новые реплики на новой версии, потом перекидываем нагрузку с одной из старых реплик на новую, и выводим старую реплику из эксплуатации. Потом ещё раз и ещё — пока кластер целиком не переползёт на новую версию.
Чтобы «поднять ещё одну реплику» нужно иметь систему, которая может быстро поднять "-цать копий серверов". Динамически, с мониторингом живости и прибитием лишнего. Вручную такое на chef/ansible/puppet написать можно — они все тьюринг-полные. Но 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 в цикл. Но это начинает подозрительно напоминать написание супервизора. На ансибле. Смешно.
Проблема в том, что ансибл (и т.д.) — это системы управления конфигурациями. И только. У них в workflow нет понятия «реакции на несвязный факап». А у систем оркестрации оно должно быть в центре внимания.
Ансибл может в любой момент времени проверить, что у нас есть N рабочих реплик. Но он не может это проверять в каждый момент времени. Например, ансибл убедился, что у нас N+1 рабочих реплик и пошёл сносить реплику N+1. В это время реплика 2 сдохла.
Оркестрация в такой ситуации снесёт N+1'ую реплику, и тут же запустит N'ую (потому что рабочих реплик стало N-1). А ансибл радостно зарепортит «всё сделано».
Можно завернуть ansible в цикл. Но это начинает подозрительно напоминать написание супервизора. На ансибле. Смешно.
UFO just landed and posted this here
Ну вот я пытался запустить старый Firefox, например 3.5 или около того, на современном Дебиане. Не работает. Более новая библиотека GTK, казалось бы, должна быть обратно совместима, но по факту — нет (видимо, в старой версии не было какой-то проверки и код работал, а в новой проверки ужесточены). Как мне запускать этот старый фаерфокс на новой системе?
Контейнеры тут могли бы быть удобным решением, правда надо еще найти, как в контейнер запихнуть древнюю версию библиотеки и древнии версии ее зависимостей.
То есть проблема в убогости пакетных менеджеров, которые не способны поддерживать установку нескольких версий одной библиотеки, а умеют лишь ставить самое новое.
Контейнеры тут могли бы быть удобным решением, правда надо еще найти, как в контейнер запихнуть древнюю версию библиотеки и древнии версии ее зависимостей.
То есть проблема в убогости пакетных менеджеров, которые не способны поддерживать установку нескольких версий одной библиотеки, а умеют лишь ставить самое новое.
То есть проблема в убогости пакетных менеджеров, которые не способны поддерживать установку нескольких версий одной библиотеки, а умеют лишь ставить самое новое.Нет, конечно. Пакетные менеджеры прекрасно ставят множество версий одной библиотеки — если они объявлены несовместимыми. Скажем GTK+1.2 и GTK+2.0 отлично уживаются.
А вот если разработчики на совместимость «забивают» и порождают две версии библиотек, которые, вроде как бы, должны быть совместимыми, но де-факто совместимыми не являются… тогда у вас беда.
То есть да — docker, podman и прочие решают именно проблему криво написанных программ… но других-то у нас нет…
Если все будут писать софт без багов — половину современного ИТ можно выкидывать за ненадобностью.
Если же мы имеем ситуацию с несовместимостью между ABI версий библиотек, то это обычная проблема, ничем не лучше и не хуже любой другой.
И добротное IT должно уметь продолжать жить даже с таким багом, а не закрываться со словами segmentation fault… Пардон, incompatible call bla-bla-bla.
Если же мы имеем ситуацию с несовместимостью между ABI версий библиотек, то это обычная проблема, ничем не лучше и не хуже любой другой.
И добротное IT должно уметь продолжать жить даже с таким багом, а не закрываться со словами segmentation fault… Пардон, incompatible call bla-bla-bla.
Извините, но мой опыт, в т.ч. с Фаерфоксом, показывает что декларируемая ситуация часто отличается от реальности. В теории библиотеки совместимы — а по факту нет (пример: новая версия более тщательно проверяет входные параметры, а программа передает в них некорректные значения, что работало со старой версией). Да, может быть старый Фаерфокс неправильно работает с библиотекой и содержит ошибку, однако мне нужны не объяснения, а работающий браузер.
Учтите только, что в контейнерах библиотеки тоже надо постоянно обновлять, чтобы не нарваться на серьезные проблемы с безопасностью. И точно такая же проблема с проверкой параметров в API может вылезти после обновления. А по факту часто имеем «работает — не трожь» и сопутствующие дыры, которые эксплуатируются. Не теоретически, а вполне на основе опытных данных.
гораздо выгоднее софт научиться нормально писать
Можно ли увидеть какие-либо расчеты в подтверждение вашей позиции? Или это ваше личное мнение, которое не обязано быть правильным?
Докер (и контейнеризация вообще) позволяет гарантировать одинаковые условия исполнения кода. Это в свою очередь снижает (хотя и не отменяет полностью) ситуации а-ля «а у меня локально всё в порядке».
Плюс, рядовой ситуацией является несколько одновременно поддерживаемых релизов одного и того же софта. Иногда новый релиз ведет к частичному нарушению обратной совместимости (например, за счет изменения дефолтов). Кроме того, только что вышедший релиз используемого стороннего ПО может иметь изъяны, т.к. он не проверен временем на продакшне. Поэтому переход с одного релиза на другой может быть достаточно рисковым, и делать его только лишь потому, что так хочется вам лично, не стоит.
При этом достаточно просто и легко опробовать новый релиз, даже если для вашей любимой серверной ОС он не был выпущен. И тут (при вашем отношении к докеру) либо компилировать самому (что может стать увлекательным приключением), либо рисковать, подключая сторонние репозитории.
Всех этих проблем вы можете избежать, используя контейнеризацию. И да, к вопросу о скриптовых языках, надеюсь, это была неудачная шутка. Погуглите, сколько сервисов с миллионными и даже миллиардными доходами, написано с использованием Python. В общем, вспоминается старая поговорка про корреляцию ума и богатства.
Плюс, рядовой ситуацией является несколько одновременно поддерживаемых релизов одного и того же софта. Иногда новый релиз ведет к частичному нарушению обратной совместимости (например, за счет изменения дефолтов). Кроме того, только что вышедший релиз используемого стороннего ПО может иметь изъяны, т.к. он не проверен временем на продакшне. Поэтому переход с одного релиза на другой может быть достаточно рисковым, и делать его только лишь потому, что так хочется вам лично, не стоит.
При этом достаточно просто и легко опробовать новый релиз, даже если для вашей любимой серверной ОС он не был выпущен. И тут (при вашем отношении к докеру) либо компилировать самому (что может стать увлекательным приключением), либо рисковать, подключая сторонние репозитории.
Всех этих проблем вы можете избежать, используя контейнеризацию. И да, к вопросу о скриптовых языках, надеюсь, это была неудачная шутка. Погуглите, сколько сервисов с миллионными и даже миллиардными доходами, написано с использованием Python. В общем, вспоминается старая поговорка про корреляцию ума и богатства.
даа, вкатали вам минусов. Но вы держитесь
затраты на внедрение\обслуживание не окупаются
Программист приносит больше реальной пользы, когда сосредоточен на создании/поддержании собственно прикладной ценности создаваемого им продукта, а вовсе не технологической обвязки (обвязка — это в том числе поддержка совместимости с различными внешними средами).
Я так и не понял какую проблему они решал создавая свой стэк.
NIH?
Тут много политики. Docker Inc в свое время захотели весь рынок под себя поджать, а Google, RH и прочие — не захотели им этого позволить.
Плюс неожидано всплыл факт: можно и лучше писать софт, поскольку качество у Docker довольно низкое. Много раз ломали API, регистри так вообще сущий ад по началу был.
Если конкретно об этой статье, то радует отсутствие демона. Это решение давно напрашивалось, поскольку сейчас, если я правильно понимаю, Docker в памяти находится только как орбитр и точка входа для удаленных управляющих сигналов, а в k8s это уже лишняя сущность.
Вот тут написано:
developers.redhat.com/blog/2019/02/21/podman-and-buildah-for-docker-users
Типа у докера всё зависит от одного процесса (а это плохо), если он умирает, то все контейнеры остаются без родителя. Для управления докером нужен рут, и типа у докера есть потенциальные проблемы безопасности.
Хотя по мне слабоватые аргументы…
developers.redhat.com/blog/2019/02/21/podman-and-buildah-for-docker-users
Типа у докера всё зависит от одного процесса (а это плохо), если он умирает, то все контейнеры остаются без родителя. Для управления докером нужен рут, и типа у докера есть потенциальные проблемы безопасности.
Хотя по мне слабоватые аргументы…
del
Спасибо. Очень «полезная» статья. Напился вдоволь.
Извиняюсь за токсичность, но очень обидна когда тема не раскрыта.
Извиняюсь за токсичность, но очень обидна когда тема не раскрыта.
К сожалению, комментарий не раскрывает тему того, что не раскрыто.
По конкретики:
Куча ненужной информации, от историй названий, до упоминания версий и таблице сравнения команд где только 2 отличаются.
Но при этом не раскрыты преимущества. Есть техническое описание что оно может, но непонятно зачем это может пригодится.
Упоминается какое то их виденье, но в чём оно заключается не сказано, или плохо уловимо.
Можно было перечислить какие инструменты у них есть, и какую роль во всём этом играет libpod.
Конечно есть ссылки, но это не сильно спасает.
Напримет:
Итог: У вас получилась не популярная статья, а сухая глава из учебника, причём с одним лишь примером вне контекста. Понять может только тот кто и так знает. А как вы писали в заголовке «чтобы познакомиться с ним, узнать о его истоках и подумать о перспективах», но такая манера повествования ясности не вносит.
Куча ненужной информации, от историй названий, до упоминания версий и таблице сравнения команд где только 2 отличаются.
Но при этом не раскрыты преимущества. Есть техническое описание что оно может, но непонятно зачем это может пригодится.
Упоминается какое то их виденье, но в чём оно заключается не сказано, или плохо уловимо.
Можно было перечислить какие инструменты у них есть, и какую роль во всём этом играет libpod.
Конечно есть ссылки, но это не сильно спасает.
Напримет:
Среди зависимых компонентов для работы Podman — такие утилиты для Linux-контейнеров, как runc и conmon, а также сетевые плагины CNI.Для тех кому эти названия ни о чём не говорят, это выглядит как рандомный факт. Да есть ссылки, но мало у кого после прочтения README появляется понимание хорошо это или плохо. А если это и не хорошо и не плохо, то на что влияет?
Итог: У вас получилась не популярная статья, а сухая глава из учебника, причём с одним лишь примером вне контекста. Понять может только тот кто и так знает. А как вы писали в заголовке «чтобы познакомиться с ним, узнать о его истоках и подумать о перспективах», но такая манера повествования ясности не вносит.
> непонятно зачем это может пригодится
Об этом написано здесь:
Далее — почему же тогда не Docker CLI, сказано здесь:
> Для тех кому эти названия ни о чём не говорят, это выглядит как рандомный факт.
Признаюсь, эта статья ориентирована не на тех, для кого такие названия, как runc и CNI, ни о чём не говорят. Чтобы таким людям было проще, есть многократные ссылки на обзор CRI-O, где эта тема раскрыта. Дублировать её в данной статье не посчитал уместным, а к этому, как я вижу, и сводится всё основное непонимание и видимый недостаток раскрытия темы…
P.S. К вопросу о преимуществах и сравнениях: Podman по сути своего предназначения интереснее сравнивать с упомянутым в начале статьи cri-containerd от Docker Inc. И есть на эту тему взгляд со стороны Red Hat.
Об этом написано здесь:
В целом же основная задумка 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.
Спасибо за пояснения. Прочитав «обзор CRI-O» стало намного понятней. Правда всё равно не понятно чем их не устраивает демон в докере, но я думая что в комментарии ниже есть ответ.
Как я сейчас понял HR делают свою «оболочку» частично на основе уже стандартизованных элементов докера и в соответствии с «Проект следует идеологии UNIX-команд, где каждая утилита делает лишь одну вещь, но хорошо.».
А изначально из статьи складывалось впечатление (как выше писали NIH), делаем свой велосипед потому что свой. Пара мелких фишек которые непонятно зачем нужны — не в счёт.
Как я сейчас понял HR делают свою «оболочку» частично на основе уже стандартизованных элементов докера и в соответствии с «Проект следует идеологии UNIX-команд, где каждая утилита делает лишь одну вещь, но хорошо.».
А изначально из статьи складывалось впечатление (как выше писали NIH), делаем свой велосипед потому что свой. Пара мелких фишек которые непонятно зачем нужны — не в счёт.
А зачем? Чем Docker не устраивает?
Вот этот тикет может пролить свет — https://github.com/containerd/containerd/issues/2288
Меня — тем, что он очень opionated. Тот же lxc для жизни лучше, но pod'ов не хватает. Очень надеюсь, что эта штука взлетит.
Ключевая проблема состоит в том, что RH хочет из управлялки контейнеров сделать простую тупую ясную утилиту. А Docker (компания) хочет быть business value, чтобы все на неё обращали внимание и думали docker way.
Утилита лучше, чем чужое business value, потому что утилита полезнее.
Ключевая проблема состоит в том, что RH хочет из управлялки контейнеров сделать простую тупую ясную утилиту. А Docker (компания) хочет быть business value, чтобы все на неё обращали внимание и думали docker way.
Утилита лучше, чем чужое business value, потому что утилита полезнее.
В целом же основная задумка Podman заключается в том, чтобы предоставить пользователям Kubernetes, выбравшим CRI-O в качестве исполняемой среды для контейнеров, аналог консольного интерфейса Docker CLI (для взаимодействия с контейнерами и образами, запущенными в кластерах):
«Podman реализует 38 из 40 команд Docker CLI, определённых в Docker 1.13 (на момент анонса в феврале — прим. перев.), но некоторые из них мы специально не повторяли.
Это я так понимаю когда мы хотим Докер, но что бы это был не Докер. Из статьи я чесно говоря не понял принципиальной разницы. Или должно быть какое-то сравнение производительности или чего-то еще.
Есть ссылка на сравнение производительности runc в разных реализациях (в т.ч. CRI-O и containerd, с которым уместнее сравнивать, чем просто Docker*), приводившееся в этой статье. Вот оно:
(его источник)
* Если сравнивать ещё с самим Docker, то налицо как минимум значимое архитектурное отличие (не нужен демон), поэтому корректнее всё же рассматривать Podman vs. containerd/crictl. Здесь есть функциональные отличия — информацию об этом добавил в текст статьи, спасибо!
(его источник)
* Если сравнивать ещё с самим 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
Тем, что все эти начинания с cri-o делаются для совсем других целей — сделать легковесный рантайм для кубернетиса и ему подобных. Никто убийцу докера писать не собирался и не пишет. Докер остается в своей нише, а в нише маленького компонента кубернетиса он выглядит слишком большим и сложным, поэтому его заменяют на крио. Хотя докер все еще остается доминирующим и дефолтным вариантов. Все таки устоявшийся взрослый продукт. Подман тут видится разве что для совсем узкий кейсов — потестить, поиграться. Смысла запускать у себя машине это все никакого. Докер тут нужнее, а смысла ворочать руками контейнеры, когда у тебя кубернетис, тем более не видно.
Docker RIP?
Он никуда не денется, т.к. является основой цикла разработки. Локальное тестирование, простые кейсы, где нужно просто запустить что-то в контейнере. Смысла линять с докера в этих случаях никакого. Да и альтернатив нет — для мака вот есть шикарное интегрированное докер решение, будто у меня контейнеры прям в макоси. Все эти крио даже не суются сюда и не собираются докер вытеснять, это не их ниша.
Docker is the best
Как убого выглядит мир линукса с контейнерами и насколько всё красиво во FreeBSD :)
> красиво во FreeBSD
А не могли бы вы раскрыть мысль? Мне правда интересно. Когда я последний раз трогал FreeBSD, там были простые Jails. Простые — в смысле что-то больше похожее на lxd.
Но это было довольно давно, может быть сейчас уже завезли что-то более интересное?
А не могли бы вы раскрыть мысль? Мне правда интересно. Когда я последний раз трогал FreeBSD, там были простые Jails. Простые — в смысле что-то больше похожее на lxd.
Но это было довольно давно, может быть сейчас уже завезли что-то более интересное?
Я скорее имел ввиду идеологию подхода в разных ОС, например, захотели 2-й питон, зашли в те же порты, поставили, захотели 3-й питон, зашли и поставили. Что замечательно, так это то, что они сосуществуют вместе со всеми своими либами и зависимостями в одной ОС и без контейнеров (да, jail есть и это рабочий инструмент для продакшена). Аналогично и с другими проектами. В линуксе, что не день, то сюрприз. Опять же пример, вечером уходил — всё работало, утром запустил компьютер и нет модуля управления рабочими столами, обновил ОС (centos), пропала менюха.
Как я вижу, во FreeBSD ОС — это комплект ядра, окружения, и даже пакетов. В Линуксе, больше выбор, но приходится платить за это кровью админов)))
Как я вижу, во FreeBSD ОС — это комплект ядра, окружения, и даже пакетов. В Линуксе, больше выбор, но приходится платить за это кровью админов)))
Ну справедливости ради, 2 и 3 питон одновременно держать в системе не проблема.
Неудобства начинаются когда надо одновременно, ну возьмем для примера php — 5.2,5.3,5.6,7.0,7.2 (не спрашивайте зачем). Можно конечно все это развернуть на одной системе, но это получится адский ад. Гораздо удобнее запихать разные версии в разные контейнеры и наслаждаться чистотой и порядком в системе.
А еще докер — это не только изоляция приложений.
Неудобства начинаются когда надо одновременно, ну возьмем для примера php — 5.2,5.3,5.6,7.0,7.2 (не спрашивайте зачем). Можно конечно все это развернуть на одной системе, но это получится адский ад. Гораздо удобнее запихать разные версии в разные контейнеры и наслаждаться чистотой и порядком в системе.
А еще докер — это не только изоляция приложений.
Ну вообще php5 (тут конечно версии не очень хорошо разделяются) и 7.x вполне себе могут жить на одной машине. Более того, 7 ветка изначально разделена на 0,1,2,etc. Со своими конфигами, со своими модулями и вот это все.
А я и не говорю что тут неразрешимые проблемы. Просто разводится срач в системе и поддержка всего этого зоопарка начинает занимать время.
На самом деле в случае php я вообще не могу представить ситуацию, когда есть что-то, для чего надо несколько версий на одной машине для разработчика, который пишет свой продукт.
Ситуации со всякими древними CMS/etc не рассматриваем. Ибо нормально написанный продукт заводится на любой версии
Ситуации со всякими древними CMS/etc не рассматриваем. Ибо нормально написанный продукт заводится на любой версии
Например, клиентский сервер. Какой-то софт умеет только в <=5.2, какой-то 5.3-5.6, и какой-то только в 5.6-7 (но очень лучше 7.1-7.2). Миграция на новые версии/платформы всего этого дела стоит от несколько тысяч $$, и клиент не готов за это платить.
> Ибо нормально написанный продукт заводится на любой версии
Особенно когда он был написан лет так 10-15 назад (и с тех пор не обновлялся) и даже на 5.3 без танцев с бубном полноценно не работает.
> Ибо нормально написанный продукт заводится на любой версии
Особенно когда он был написан лет так 10-15 назад (и с тех пор не обновлялся) и даже на 5.3 без танцев с бубном полноценно не работает.
Я же специально акцентировал «Ситуации со всякими древними CMS/etc не рассматриваем».
Вот, к примеру, я только что перенес спагетти-код 10-летней давности с сервера на 5.3 на 7.0. Там хоть и «ужоснах», но завелось. Надо бы, конечно, переписать-отрефакторить, но это не критичное, так что как время будет.
Вот, к примеру, я только что перенес спагетти-код 10-летней давности с сервера на 5.3 на 7.0. Там хоть и «ужоснах», но завелось. Надо бы, конечно, переписать-отрефакторить, но это не критичное, так что как время будет.
> Я же специально акцентировал «Ситуации со всякими древними CMS/etc не рассматриваем».
Ну они от этого никуда не исчезают же :(
Да и суть то не только в этом. С докером можно очень просто взять и развернуть у себя точно такое же окружение как на проде например. Или быстренько поднять сервис на nodejs на посмотреть. И еще 100500 применений в рамках только изоляции приложений. А там же еще есть и кластеризация/оркестрация и прочие swarm'ы.
> с сервера на 5.3 на 7.0. Там хоть и «ужоснах», но завелось.
Ну это вам очень повезло с кодом. Ну или код не сильно наворочен был, что удаленные в 7 фичи почти не использовались.
Ну они от этого никуда не исчезают же :(
Да и суть то не только в этом. С докером можно очень просто взять и развернуть у себя точно такое же окружение как на проде например. Или быстренько поднять сервис на nodejs на посмотреть. И еще 100500 применений в рамках только изоляции приложений. А там же еще есть и кластеризация/оркестрация и прочие swarm'ы.
> с сервера на 5.3 на 7.0. Там хоть и «ужоснах», но завелось.
Ну это вам очень повезло с кодом. Ну или код не сильно наворочен был, что удаленные в 7 фичи почти не использовались.
«Ибо нормально написанный продукт заводится на любой версии». Серьезно? Читайте список: php.net/manual/en/migration70.incompatible.php
Появился podman-compose для использования docker-compose.yml с podman.
Sign up to leave a comment.
Red Hat заменяет Docker на Podman