Около двух лет назад на страницах OpenNet было опубликовано (http://www.opennet.me/opennews/art.shtml?num=35028) интервью с Павлом Емельяновым, руководителем группы разработчиков Parallels Server Virtualization, в котором Павел рассказывал о планах компании по включению кодов контейнерной виртуализации в ядро Linux и проект CRIU. Три года назад, когда проект еще был в начальной стадии, он вызвал волну интереса у пользователей Linux и скептический отзыв у Эндрю Мортона. Осенью 2013 года был анонсирован первый крупный релиз проекта – CRIU 1.0. А сегодня он де-факто стал стандартом реализации технологии checkpoint-restore в Linux.
Напомним, Павел Емельянов отвечает не только за проектирование многокомпонентных систем, основанных на серверной виртуализации, но и организует процесс взаимодействия ядерной команды Parallels с сообществом разработчиков ядра Linux. Один из его любимых проектов, который получился из такой совместной работы, – CRIU (http://criu.org/): приложение, которое умеет снимать состояние выполняющихся в Linux процессов и восстанавливать в другом месте или в другое время эти процессы из полученных данных. Его целью было заменить существующую реализацию технологии сохранения и восстановления состояния контейнеров, которая, в свою очередь, необходима как база для живой миграции контейнеров.
Сегодня мы публикуем некоторые итоги работы команды Павла и ждем вопросов от сообщества, на которые Павел согласился ответить. Вопросы можно отправлять в свободной форме в комментариях к новости. Ответы будут опубликованы в ближайшие недели. Для пояснения сути контейнеров и оценки целесообразности использования таких
систем, в качестве дополнения также приводится перевод статьи Джеймса Боттомли (James Bottomley), известного разработчика ядра Linux, входящего в координационный технический комитет Linux Foundation и занимающего должность технического директора по серверной виртуализации в компании Parallels.<h2>Обзор итогов за 2 года от Павла Емельянова</h2>
<blockquote>
Недавно в жизни проекта произошло знаменательное событие – Parallels стала сотрудничать с инженерами из компаний Google и Canonical. Последняя, как известно, поддерживает дистрибутив Ubuntu. Они уже влились в проект не только как пользователи, но и как участники - в последнем релизе 1.3-rc2 есть патчи, присланные с адресов @google.com и @canonical.com. Более того, разработчики из Google и Canonical принимают активное участие в обсуждении поддержки cgroup в CRIU и успешно используют CRIU с утилитами Docker и LXC.
Кстати, о Docker и LXC. Эти два проекта в своё время завоевали огромную популярность и потеснили с олимпа проект OpenVZ в мире Linux Containers. Долгое время три проекта сосуществовали параллельно, предлагая пользователям одинаковую по сути, но разную в реализации и деталях технологию.
Недавно Docker, Parallels, Canonical, Google и RedHat договорились о слиянии центральных частей своих контейнерных проектов в один - libcontainer - и совместном, согласованном его развитии
.Libcontainer - это системная библиотека, предоставляющая гибкий и достаточно абстрактный интерфейс к ядерным контейнерным компонентам.
Немного технических подробностей. В ядре не существует такого понятия как "контейнер". Говоря о контейнерах, разработчики ядра подразумевают несколько разных подсистем ядра, которые позволяют, при правильном использовании, изолировать приложения в виртуальных средах. Это, главным образом, cgroups и namespaces. Прямое использование ядерных интерфейсов возможно, но весьма нетривиально.Библиотека libcontainer призвана облегчить процедуру их использования, предоставив программистам интерфейс, в котором есть более "привычные" и "возвышенные" понятия, такие как "контейнер", "вычислительные ресурсы", "виртуальная сеть" и т.п.
Помимо развития контейнерной технологии, Parallels видит в Libcontainer ещё и способ получить эту технологию в проекте OpenStack. OpenStack - это набор программ, позволяющий разворачивать облачную инфраструктуру и управлять ею. До сих пор OpenStack работал только с виртуальными машинами, но в последнее время, с развитием контейнерной технологии, сообщество разработчиков OpenStack всё чаще и чаще вспоминает о том, что неплохо было бы создавать контейнеры и в облаках, управляемых OpenStack-ом.
Уже было предпринято несколько попыток достичь этого - RackSpace разработал расширение на основе контейнеров OpenVZ, но это решение не было принято сообществом. Docker предоставил расширение, основанное на своей технологии, но и оно не закрепилось в проекте.
В качестве дальнейшего развития разработчики Parallels, Docker, Canonical и, возможно, RackSpace попробуют привнести контейнеры в OpenStack через Libcontainer.
Почему все это сейчас так важно? Дело в том, что контейнерная технология становится ключевым компонентом в большинстве дистрибутивов Linux. Более того, мы все чаще замечаем, что она становится востребованной в корпоративной среде, хотя традиционно считалась уделом хостинг-сообщества.
Поскольку рынок постепенно переходит от простых хостинговых услуг к облачным, мы считаем важным, чтобы у заказчиков были все необходимые для этого инструменты, в том числе - OpenStack и Docker. Последний, в частности, пригодится для упаковки ваших приложений в контейнер. Причины, по которым Parallels поддерживает сразу оба проекта, одинаковые: получить технологии Open Source, на основе которых можно построить дифференцированное предложение, соответствующее конкретным нуждам заказчиков. С помощью OpenStack, компонентов открытой технологии для облачных инструментов и инструментов автоматизации, с помощью Linux Foundation (и Linux в целом) в компании уже работает такое решение, как Parallels Cloud Server.
Сегодня разработчики Parallels помогают создать новое поколение docker-программ, таких как контейнеризированные приложения, и за счет этого расширить количество сценариев использования для контейнеров в вычислительной индустрии. А libcontainer как технология open source для потребления контейнерной виртуализации на уровне детализации – это согласованная (между Docker, LXC, Google и Parallels) возможность сделать это.
</blockquote><h2>Джеймс Боттомли, статья "Почему сегодня так много говорят о контейнерной виртуализации?"</h2>
<blockquote>
Из всех разнообразных технологий виртуализации контейнеры еще недавно рассматривались либо как недорогой вариант создания инфраструктуры для хостинга, либо как редкая диковинка. Но сегодня, благодаря облачной революции и выходу на первый план таких свойств, как эластичность и вычислительная плотность, контейнеры стали предметом повышенного интереса. Прежде всего, потому, что они больше всего подходят для решения этих задач. Почему же о них раньше забывали, и почему вспомнили сегодня?
В общих чертах виртуализация – это искусство запуска одной операционной системы поверх другой. История ее развития довольно длинная и богатая. Задолго до гипервизоров и UNIX-систем она использовалась в мейнфреймах для разделения различных операционных систем. Широкого признания на рынках UNIX и Linux она добилась лишь где-то в 2001-ом. В этом году компания VMware выпустила серверный продукт для виртуализации на основе гипервизора, привлекший внимание корпоративного рынка. Практически в то же самое время компания Parallels выпустила Virtuozzo, решение для контейнерной виртуализации, получившее большую популярность на рынке хостинга.Этот барьер сохранялся почти 12 лет: гипервизорная виртуализация не могла отхватить сколько-нибудь значимый кусок хостингового рынка, а контейнеры не могли проникнуть на корпоративный. Такое положение дел продлилось, по крайней мере, до 2013 года – момента появления разработчика Docker и начала роста интереса бизнеса к контейнерной технологии.
Контейнеры против гипервизоров – все дело в плотности<center><img src="http://www.opennet.me/opennews/pics_base/0_1404373057.png" style="border-style: solid; border-color: #e9ead6;...
URL:
Новость: http://www.opennet.me/opennews/art.shtml?num=40126
Павел, у меня вопрос по вашей же OpenVZ, которая успешно применяется в таком решении, как Proxmox VE.
Сейчас они поддерживают два варианта виртуализации - KVM и контейнеры OpenVZ.
Используют ядро от чего-то редхатистого, ибо в мейнстриме нет штатной поддержки OpenVZ (во всяком случае, до определенного времени точно не было).Будет ли OpenVZ (пусть и через LXC/cgroups) присутствовать в ванильных ядрах Linux?
Есть ли какой-либо интерес у создателей Proxmox VE к Libcontainer и CRIU/Docker/LXC (вам такая кухня может быть известна)?Есть ли планы по выпуску своего готового решения под лицензией AGPL, вроде Proxmox VE, но умеющего CRIU/Docker/LXC/OpenVZ/Virtuozzo?
Какие решения для ядер BSD вы разрабатываете и будет ли возможность миграции приложений из одного типа контейнера в другое, с платформы на платформу?
Я не из Parallels, но тоже Павел и могу ответить :)> Павел, у меня вопрос по вашей же OpenVZ, которая успешно применяется в
> таком решении, как Proxmox VE.
> Сейчас они поддерживают два варианта виртуализации - KVM и контейнеры OpenVZ.
> Используют ядро от чего-то редхатистого, ибо в мейнстриме нет штатной поддержки OpenVZ
> (во всяком случае, до определенного времени точно не было).
> Будет ли OpenVZ (пусть и через LXC/cgroups) присутствовать в ванильных ядрах Linux?Оно есть, vzctl из пакета OpenVZ. Можете поставить на ядро 3.14 и все у Вас будет. Такие новые ядра, например, в Fedora.
> Есть ли какой-либо интерес у создателей Proxmox VE к Libcontainer и CRIU/Docker/LXC
> (вам такая кухня может быть известна)?Неизвестно. Пока libcontainer не умеет OpenVZ любым прикладникам оно по боку.
> Есть ли планы по выпуску своего готового решения под лицензией AGPL, вроде
> Proxmox VE, но умеющего CRIU/Docker/LXC/OpenVZ/Virtuozzo?Оно есть - Parallels Cloud Server.
Уточните, что именно Вы хотите от OpenVZ, чего нет в стандартной поставке?
> Какие решения для ядер BSD вы разрабатываете и будет ли возможность миграции
> приложений из одного типа контейнера в другое, с платформы на платформу?Боюсь, что никакие, я не знаю ПО от || виртуализирующего BSD. Но как клиента, разумеется, BSD можно запустить на PCS, Parallels bare Metal или даже Parallels Desktop.
> Оно есть, vzctl из пакета OpenVZ. Можете поставить на ядро 3.14 и
> все у Вас будет. Такие новые ядра, например, в Fedora.А в ubnutn LTS ядро 3.14 нормально для таких развлечений? Какие опции конфига для работы vzctl с ванилью требуются и насколько LTSная убунта нужное поддерживает "из коробки"? Есть какие-то быстрые средства проверки совместимости той или иной системы с vzctl?
> Используют ядро от чего-то редхатистого, ибо в мейнстриме нет штатной поддержки OpenVZ (во всяком случае, до определенного времени точно не было).FYI на самом деле уже нет. :) в Debian Squeeze было, а в Wheezy предложили использовать LXC. Ну или как Proxmox ядро от RH.
>> Используют ядро от чего-то редхатистого, ибо в мейнстриме нет штатной поддержки OpenVZ (во всяком случае, до определенного времени точно не было).
> FYI на самом деле уже нет. :) в Debian Squeeze было, а
> в Wheezy предложили использовать LXC. Ну или как Proxmox ядро от
> RH.В wheezy/squeeze можно использовать стандартное OpenVZ ядро 2.6.32, все пакеты и юзерспейс давно стабильны.
Хочется же какие-нибудь 3.15, или рядом.
Да еще и не из чужеродной федоры, а прям родное, дебиановское. :)
> В wheezy/squeeze можно использовать стандартное OpenVZ ядро 2.6.32,Вы знаете, необходимость использовать столь некрофильское ядро - жирный минус. В нем знаете ли есть куча багов разной степени серьезности и непонятной степени бэкпортированности, нет поддержки свежего оборудования, etc.
Именно RHEL и поддерживает все серверное оборудование :)
Проприетарные драйверы в rpm от всяких супермикр, хп, деллов есть всегда именно под RHEL и SLES.
Какое еще Вам железо нужно на сервере? Свежие ноутбучные вебкамеры )))?
> Именно RHEL и поддерживает все серверное оборудование :)Рхел вообще гoвняшка редкостная, не зря ее убунта выпирает с большинства хостов в интернете. Вот пусть этим и пользуется полтора энтерпрайза.
> Проприетарные драйверы в rpm от всяких супермикр, хп, деллов
Проприетарный драйвер - вообще заявка на залет в будущем. Я себе не враг - сами такое DEPЬMO используйте.
> Какое еще Вам железо нужно на сервере? Свежие ноутбучные вебкамеры )))?
А самое разное. В ядро коммитят туеву хучу поддержки всего и вся. От мобилочных SoC до infiniband.
> OpenVZHe's dead, Jim. Продержится по инерции ещё пару лет, а потом или кусками войдёт в ядро, либо помрёт ибо с lxc меньше гемора.
>> OpenVZ
> He's dead, Jim. Продержится по инерции ещё пару лет, а потом или
> кусками войдёт в ядро, либо помрёт ибо с lxc меньше гемора.Не хочу Вас расстраивать, но почти все LXC в ядре - это бывший OpenVZ. Так что умирать он если и будет, то лишь вместе с ядром линукса.
> Не хочу Вас расстраивать, но почти все LXC в ядре - это
> бывший OpenVZ.Вот было бы замечательно если бы OVZ и его управляторы начали работать с современными ядрами вместо окаменелых гoвен мамонта.
FreeBSD/jail — технологии провидцев.
Ага, как было 100 нет назад неюзабильное, так и осталось. OpenVZ намого раньше сделал честную и непробиваемую изоляцию по ресурсам, которую с горем пополам всунули в 9й/10й FreeBSD.
> Ага, как было 100 нет назад неюзабильное, так и осталось.Это мышкой счёлкать нельзя что ли, приходиться набивать настройки конфигурации с клавиатуры?
> OpenVZ намого раньше сделал честную и непробиваемую изоляцию по ресурсам
Так уже честную? А что делать с общим SWAP и протечкой памяти в одном из контейнеров?
>> Так уже честную? А что делать с общим SWAP и протечкой памяти в одном из контейнеров?Количество swap-а и памяти лимитируется для каждого контейнера в отдельности. Объясните детальнее проблему, о которой вы говорите.
В случае с виртуальным сервером, использовать SWAP смерти подобно. Дело в том, что жёсткий диск - самое медленное устройство на сервере и он делится между всеми VPS. А SWAP очень сильно нагружает диски, поэтому малейшая активность свопа у нескольких VPS приведет к тому, что все виртуальные сервера, размещенные на этом сервере, практически перестанут отвечать на запросы.
> В случае с виртуальным сервером, использовать SWAP смерти подобно. Дело в том,
> что жёсткий диск - самое медленное устройство на сервере и он
> делится между всеми VPS. А SWAP очень сильно нагружает диски, поэтому
> малейшая активность свопа у нескольких VPS приведет к тому, что все
> виртуальные сервера, размещенные на этом сервере, практически перестанут отвечать на запросы.В OpenVZ ранее вообще не было swap. И юзаться он мог лишь при лютейшем недостатке памяти на ноде. С версии 2.6.32 (то есть уже лет 5 как) используется схема vSwap, когда SWAP дается контейнеру, но не реальный, а виртулизированный - созданынй на базе замедленной оперативной памяти.
То есть, если на современном ядре контейнер уйдет в глубоий SWAP, то никакой нагрузки на SWAP ноды он не будет производить - все будет крутиться в озу.
Но, конечно, если памяти на машине нету под это дело, что все начнет тормозить. Но такое поведение будет и на FreeBSD и на KVM и на Linux и даже на Windows, что вполне ожидаемо.
Вот тут описан способ надувательства контейнерной виртуализации OpenVZ, в процессе которого память всё равно в итоге распределяется неэффективно: http://openhosting.ru/vps/xen-vs-openvz.jspПро эмуляцию SWAP в памяти с полосой пропускания на уровне механики — это из разряда запудрить мозги пользователю, авось обойдётся. Пусть почувствует, что его контейнер начал использовать жёсткий диск. :))
Вот ещё давнишняя проблема контейнерной виртуализации на Linux: http://www.stableit.ru/2010/03/openvz.html (см. недавние комментарии — проблема так и не решена)
> Вот тут описан способ надувательства контейнерной виртуализации OpenVZ, в процессе которого
> память всё равно в итоге распределяется неэффективно: http://openhosting.ru/vps/xen-vs-openvz.jsp
> Про эмуляцию SWAP в памяти с полосой пропускания на уровне механики —
> это из разряда запудрить мозги пользователю, авось обойдётся. Пусть почувствует, что
> его контейнер начал использовать жёсткий диск. :))
> Вот ещё давнишняя проблема контейнерной виртуализации на Linux: http://www.stableit.ru/2010/03/openvz.html
> (см. недавние комментарии — проблема так и не решена)Более бездарного обзора как Xen, так и OpenVZ не видел: http://openhosting.ru/vps/xen-vs-openvz.jsp Армяне лучше чем Грузины. Чем? Чем Грузины :)
Это не надувательство, клиент в итоге получает _быстрый_ swap на скорости намного большей, чем ему выдал бы даже SSD диск и ощущает лишь небольшой лаг. Обращаю внимание, что лаг испытывает лишь 1 клиент, а их может быть, скажем, 1000 на одной ноде. В случае реального SWAP начали бы тормозить ВСЕ контейнеры из-за _одного_ клиента.
>[оверквотинг удален]
>> его контейнер начал использовать жёсткий диск. :))
>> Вот ещё давнишняя проблема контейнерной виртуализации на Linux: http://www.stableit.ru/2010/03/openvz.html
>> (см. недавние комментарии — проблема так и не решена)
> Более бездарного обзора как Xen, так и OpenVZ не видел: http://openhosting.ru/vps/xen-vs-openvz.jsp
> Армяне лучше чем Грузины. Чем? Чем Грузины :)
> Это не надувательство, клиент в итоге получает _быстрый_ swap на скорости
> намного большей, чем ему выдал бы даже SSD диск и ощущает
> лишь небольшой лаг. Обращаю внимание, что лаг испытывает лишь 1 клиент,
> а их может быть, скажем, 1000 на одной ноде. В случае
> реального SWAP начали бы тормозить ВСЕ контейнеры из-за _одного_ клиента.А по поводу http://www.stableit.ru/2010/03/openvz.html - это мой блог, к слову и там даже в комментариях сказано, что проблема была, во-первых, года 4 назад, во-вторых, имела корни в перегрузке софта (конкретно - Plesk под DDoS попал) и не имела отношения к контейнеризации :)
Не тратьте на iZEN время - это фрибсдшный болванчик, который openvz не видел даже на картинках. Тратить на него время бесполезно - он будет вопить что фрибзда рулит в любом случае. То что в фрибзде ж...а с виртуализацией и контейнерами - его не смущает.
> http://openhosting.ru/vps/xen-vs-openvz.jspТы конечно извини, но сравнивать OpenVZ с Xen - то же самое что сравнивать Теслу с карьерным самосвалом, лишь на том основании что у обоих колеса крутят электромоторы.
Я бы на вашем месте сначала ознакомился с технологией. vSwap к реальному swap-у имеет маленькое отношение. Когда контейнер начинает юзать vSwap, то физический своп не используется, а все данные сохраняются в памяти, а скорость этой операции искусственно замедляется. В результате пользователь, вышедший за лимит памяти, не получается отказ в ресурсах, а получает их с меньше скоростью, т е все как на реальной машине.
> Я бы на вашем месте сначала ознакомился с технологией. vSwap к реальному
> swap-у имеет маленькое отношение. Когда контейнер начинает юзать vSwap, то физический
> своп не используется, а все данные сохраняются в памяти, а скорость
> этой операции искусственно замедляется. В результате пользователь, вышедший за лимит памяти,
> не получается отказ в ресурсах, а получает их с меньше скоростью,
> т е все как на реальной машине.Да это понятно, что мухлёж в памятью, которой выделяется чуть больше, чем пользователь реально оплатил. В итоге-то держать какой-то объём дорогой оперативной памяти в резерве для каждого контейнера, а при его использовании будет эмулироваться дисковая механика — очень забавно со стороны и смотрится, и чувствуется. Ж))
>[оверквотинг удален]
>> swap-у имеет маленькое отношение. Когда контейнер начинает юзать vSwap, то физический
>> своп не используется, а все данные сохраняются в памяти, а скорость
>> этой операции искусственно замедляется. В результате пользователь, вышедший за лимит памяти,
>> не получается отказ в ресурсах, а получает их с меньше скоростью,
>> т е все как на реальной машине.
> Да это понятно, что мухлёж в памятью, которой выделяется чуть больше, чем
> пользователь реально оплатил. В итоге-то держать какой-то объём дорогой оперативной памяти
> в резерве для каждого контейнера, а при его использовании будет эмулироваться
> дисковая механика — очень забавно со стороны и смотрится, и чувствуется.
> Ж))Предложите лучше, реализуйте лучше. Пришлите патчи на LWN. Мы прочтем и порадуемся прогрессу. Так или иначе - ничего лучше, ни у кого в данный момент не существует среди открытых решений.
>[оверквотинг удален]
>>> не получается отказ в ресурсах, а получает их с меньше скоростью,
>>> т е все как на реальной машине.
>> Да это понятно, что мухлёж в памятью, которой выделяется чуть больше, чем
>> пользователь реально оплатил. В итоге-то держать какой-то объём дорогой оперативной памяти
>> в резерве для каждого контейнера, а при его использовании будет эмулироваться
>> дисковая механика — очень забавно со стороны и смотрится, и чувствуется.
>> Ж))
> Предложите лучше, реализуйте лучше. Пришлите патчи на LWN. Мы прочтем и порадуемся
> прогрессу. Так или иначе - ничего лучше, ни у кого в
> данный момент не существует среди открытых решений.Zones?
А разве в зонах swap был не на обычных ZFS пулах? Насколько я вижу, можно было лишь задать его объем: https://blogs.oracle.com/observatory/entry/zone_swap_space но не изолировать.
> Zones?Желающих иметь с солярой дело нынче что-то весьма немного.
SWAP в OpenVZ изолированный лет 7 как. Также там есть виртульный vSWAP, который вообще в озу. И протечки памяти.... поверю лишь в случае багрепорта на bugzilla.openvz.org
> которую с горем пополам всунули в 9й/10й FreeBSD.Отчего же с "горем"? Вполне себе бесшовно и прозрачно.
>> которую с горем пополам всунули в 9й/10й FreeBSD.
> Отчего же с "горем"? Вполне себе бесшовно и прозрачно.С горем потому, что изолируется от силы половина вещей, которые нужно изолировать. Jails по уровню с трудом дотягивают до Linux Upstream Containers, которые в свою очередь где-то в годах 5 разработки от уровня изоляции в OpenVZ.
И vimage уже перестал ядро ронять? Ладно сказки-то травить.
> И vimage уже перестал ядро ронять? Ладно сказки-то травить.wiki.polymorf.fr/index.php/Howto:FreeBSD_jail_vnet
> FreeBSD/jail — технологии провидцев.Какие из
* Kernel namespaces (ipc, uts, mount, pid, network and user)
Ваши провидцы _реализовали _раньше? Реализовали вообще?
>> FreeBSD/jail — технологии провидцев.
> Какие из
> * Kernel namespaces (ipc, uts, mount, pid, network
> and user)
> Ваши провидцы _реализовали _раньше? Реализовали вообще?Потрясный список! Я бы еще добавил blkio cgroup и tc для шейпинга :)
>> Какие из
>> * Kernel namespaces (ipc, uts, mount, pid, network and user)
>> Ваши провидцы _реализовали _раньше? Реализовали вообще?2iZEN: Не утруждайтесь, на википедию сам сходил. И половины нет.
> Потрясный список! Я бы еще добавил blkio cgroup и tc для шейпинга
> :)Это ровно 1 строка из Features с linuxcontainers.org/.
И дополнить ещё обратным списком "FreeBSD jails are limited in the following ways:" с wikipedia.org/wiki/FreeBSD_jail.
> 2iZEN: Не утруждайтесь, на википедию сам сходил. И половины нет.Бесшовно работает - язык у изена без костей.
>> FreeBSD/jail — технологии провидцев.
> Какие из
> * Kernel namespaces (ipc, uts, mount, pid, network
> and user)
> Ваши провидцы _реализовали _раньше? Реализовали вообще?Что за странный список? К чему он?
Контенеры jail на площадках хостинг-провайдеров работали уже тогда, когда IBM ещё не выделила на развитие GNU/Linux своего первого миллиарда долларов. Когда в Linux не было никаких способов изоляции приложений кроме дырявого chroot.
>>> FreeBSD/jail — технологии провидцев.
>> Какие из
>> Ваши провидцы _реализовали _раньше? Реализовали вообще?
> Что за странный список? К чему он?Очевидно же, для демнстрации Вашей некомпетентности. Спасибо!
Концепция FreeBSD/jail доказала право на жизнь ещё тогда, когда Linux путался в пелёнках. Linux до сих пор не имеет 100% работающую собственную контейнерную изоляцию (LXC) — http://habrahabr.ru/post/208746/
>доказала право на жизньЯ же сказал, спасибо, достаточно.
> Концепция FreeBSD/jail доказала правоА теперь вот у хостеров фря пошла в пешее эротическое. Такая вот правда жизни.
> Контенеры jail на площадках хостинг-провайдеров работали уже тогда, когда IBM ещё не
> выделила на развитие GNU/Linux своего первого миллиарда долларов.А деревянные бипланы летали раньше Боингов и Эйрбасов. Но почему-то теперь летают в основном на них, а не на деревянных бипланах. Хоть они и раньше были, etc.
Основной вопрос/просьба - пожалуйста, не забивайте/забывайте про OpenVZ! criu, docker, libcontainer и прочие они про апстримные контейнеры, которым до продакшена еще лет 5-7 разработки. А на OpenVZ все забили, хотя он в не меньшей степени нуждается в доделках и улучшениях юзерспейса.
У вас взаимоисключающие параграфы.
> У вас взаимоисключающие параграфы.Почему они взаимо исключающие? Что мешает прикрутить Докер к OpenVZ? Да никто.
>> У вас взаимоисключающие параграфы.
> Почему они взаимо исключающие? Что мешает прикрутить Докер к OpenVZ? Да никто.OpenVZ — это просто куча патчей для определённой версии ядра. Докеры, скорее всего, не хотят привязываться к определённой проприетарной (хоть и открытой) технологии и версии, вот и всё.
>>> У вас взаимоисключающие параграфы.
>> Почему они взаимо исключающие? Что мешает прикрутить Докер к OpenVZ? Да никто.
> OpenVZ — это просто куча патчей для определённой версии ядра. Докеры, скорее
> всего, не хотят привязываться к определённой проприетарной (хоть и открытой) технологии
> и версии, вот и всё.Они вполне хотят - я им писал на GitHub - они с радостью примут патчи для OpenVZ.
5-7 это вечность для сегодняшнего мира software. Docker уже релиз, год или максимум два, и он будет повсеместно
В том и дело, что нужно начинать сейчас. Аналогов OpenVZ в любом случае не будет по меньшей мере года 3-4. Все это время будет использоваться стабильное ядро RHEL 6 2.6.32, о котором все забыли в общем-то.Если знаете C, присоединяйтесь к допилке libct для OpenVZ :)
> 5-7 это вечность для сегодняшнего мира software. Docker уже релиз, год или
> максимум два, и он будет повсеместноВ Bhyve тоже будет Докер? Как интересно. Ж))
>> 5-7 это вечность для сегодняшнего мира software. Docker уже релиз, год или
>> максимум два, и он будет повсеместно
> В Bhyve тоже будет Докер? Как интересно. Ж))FreeBSD в виртуализации места нету в текущем виде. Исправятся - тоже сделают Докер =) Хотя он гадость, да.
>>> 5-7 это вечность для сегодняшнего мира software. Docker уже релиз, год или
>>> максимум два, и он будет повсеместно
>> В Bhyve тоже будет Докер? Как интересно. Ж))
> FreeBSD в виртуализации места нету в текущем виде.ПОЧЕМУ?! Мышкой нельзя настроить что ли, в этом всё "нет места"?
> Исправятся - тоже сделают Докер =) Хотя он гадость, да.
Доделаете LXC до юзабельного состояния — сравнивайте с jail в продакшене. А пока исправляйтесь сами.
>>>> 5-7 это вечность для сегодняшнего мира software. Docker уже релиз, год или
>>>> максимум два, и он будет повсеместно
>>> В Bhyve тоже будет Докер? Как интересно. Ж))
>> FreeBSD в виртуализации места нету в текущем виде.
> ПОЧЕМУ?! Мышкой нельзя настроить что ли, в этом всё "нет места"?
>> Исправятся - тоже сделают Докер =) Хотя он гадость, да.
> Доделаете LXC до юзабельного состояния — сравнивайте с jail в продакшене. А
> пока исправляйтесь сами.Вы уже доказали свою квалификацию в познаниях OpenVZ, повторять про LXC тоже самое, честно, смысла не вижу.
> честно, смысла не вижу.У него везде такая квалификация, увы.
> присланные с адресов @google.com и @canonical.comС этих адресов кто угодно может написать. Причем тут разрабы Гугла и Каноникла?
>> присланные с адресов @google.com и @canonical.com
> С этих адресов кто угодно может написать. Причем тут разрабы Гугла и
> Каноникла?Адреса @google.com используются только сотрудниками, публичный - gmail.com.
Если мощности процов еще растут и сокращается время компиляции, то сборка пакета и/или дистрибутива может дойти до 1-3 минут. Соответственно любая система виртуализации может быть контейнером для пакета
Даже такое уже было в OpenVZ: https://openvz.org/Using_vzpkg_and_vzyum_on_x86_64Кратко - была возможность собрать контейнер целиком очень быстро из набора rpm пакетов. Во многом похоже на debootstrap, только быстрее и более унифицирвоанно.
надо научиться как минимум аккумулировать и "консервировать" вычисления, а не просто примитивный ccache
Да, тут работы еще ну очень много....
> Если мощности процов еще растут и сокращается время компиляции, то сборка пакета
> и/или дистрибутива может дойти до 1-3 минут. Соответственно любая система виртуализации
> может быть контейнером для пакетаМожно просто использовать JVM с AOT, писать приложения на обычной Java и других языках для JVM — скорость разработки (а также отладки, исправления ошибок, выпуска новых версий) увеличится в разы по сравнению с протекающим C/C++ крапом. НО ЗАЧЕМ?
iZEN, Вы правда хотите, чтобы Вас еще и в незнании С++/С/Java тыкнули и предметно распяли по полочкам - почему это неверно? =)
> iZEN, Вы правда хотите, чтобы Вас еще и в незнании С++/С/Java тыкнули
> и предметно распяли по полочкам - почему это неверно? =)Я этого не хочу — это моя ЕЖЕДНЕВНАЯ боль на FreeBSD, так как от малейшего "чиха" в одной из ключевых библиотек на С++ должны быть перекомпилированы все от неё зависимые библиотеки и приложения (а это ВРЕМЯ), а иначе будут глюки, видимые невооружённым глазом. Для Java я такого бедлама не встречал — новое работает со старыми JAR'ками, старое — с новыми JAR'ками. То есть программные "модули" из-за малейшего изменения минорной версии библиотеки в Java не отваливаются и не начинают жить своей жизнью.
Из недавнего:
20140611:
AFFECTS: users of devel/icu
AUTHOR: bapt@FreeBSD.orgicu has been updated to 53.1. Please rebuild all ports that depend on it
If you use portmaster:
portmaster -w -r icu
If you use portupgrade:
portupgrade -fr devel/icu
If you use pkgng with binary packages:
pkg install -fR devel/icu— стабильно раз в полгода надо делать.
А ещё есть libjpeg, libpng...
> должны быть перекомпилированы все от неё зависимые библиотеки и приложения (а
> это ВРЕМЯ), а иначе будут глюки, видимые невооружённым глазом.Теперь ты понимаешь почему фрибздя повылетела из продакшнов, подчистую проcpaв системам с пакетными менеджерами. Где это время конечно кем-то когда-то тратится, но ты его как правило не тратишь, кроме сильно эксклюзивных случаев.
> Для Java я такого бедлама не встречал
Я понял. Изе кто-то сказал что фрибзда - круто. Изя поставил. И обнаружил что управление софтом в фряхе - ужоснax. Поэтому он любит яву. Вот оно что!
> А ещё есть libjpeg, libpng...
А в линухе с пакетным манагером такая либа заменяется за 10 секунд, вкатыванием 1 пакета. Приколись? :)
>> А ещё есть libjpeg, libpng...
> А в линухе с пакетным манагером такая либа заменяется за 10 секунд, вкатыванием 1 пакета. Приколись? :)Это потому что ты не видишь дальше собственного носа и не знаешь, как всё работает изнутри. Есть такая возможность: оставлять в системе устаревшие версии библиотек, пока приложения не обновятся и не заработают с новыми версиями. Так вот, в линухах ключевые старые (бажные) версии библиотек, если от них зависят установленные приложения, которые ещё не обновились в репозиториях, резервируются (preserve), хотя с виду всё хорошо: основная библиотека обновилась пакетом с новой версией, да. Вот только она будет использована в новых минорных версиях приложений, а установленные приложения её заигнорят. Полностью обновлённый и исправленный "стек приложений" пользователь получит спустя некоторое время — когда в системе не останется устаревших версий приложений, зависимых от данной библиотеки.
>[оверквотинг удален]
> Это потому что ты не видишь дальше собственного носа и не знаешь,
> как всё работает изнутри. Есть такая возможность: оставлять в системе устаревшие
> версии библиотек, пока приложения не обновятся и не заработают с новыми
> версиями. Так вот, в линухах ключевые старые (бажные) версии библиотек, если
> от них зависят установленные приложения, которые ещё не обновились в репозиториях,
> резервируются (preserve), хотя с виду всё хорошо: основная библиотека обновилась пакетом
> с новой версией, да. Вот только она будет использована в новых
> минорных версиях приложений, а установленные приложения её заигнорят. Полностью обновлённый
> и исправленный "стек приложений" пользователь получит спустя некоторое время — когда
> в системе не останется устаревших версий приложений, зависимых от данной библиотеки.Изик, ты в какой-то другой вселенной живешь!
1. У библиотек есть API.
2. Библиотеки в дистрибутиве не меняют если изменился API, поэтому он и называется дистрибутив.
3. Исправления багов не должны затрагивать изменения API
4. Если в библиотеку добавили фичу, API от этого не меняется или расширяется.
5. Старая программа не знает о новой фиче, в силу отсутствия у программеров машины времени.
6. Дистрибутив Gentoo - это несвязанное предложение.
> Это потому что ты не видишь дальше собственного носа и не знаешь,
> как всё работает изнутри.Болван ты, изя. Я по природе своей - что-то типа системщика. И в отличие от тебя, жабиста, знаю поболее о работе систем.
> Есть такая возможность: оставлять в системе устаревшие
> версии библиотек, пока приложения не обновятся и не заработают с новыми версиями.В линуксах с пакетными манагерами подгон версий либ в 99.9% случаев - проблема майнтайнеров, меня это при ЭКСПЛУАТАЦИИ системы не парит. Корректное состояние репов подразумевает состыкованные зависимости и ответственность причастных за свой кусок работы, как то отсутствие дыр и фатальных багов в этих компонентах.
При РАЗРАБОТКЕ мне может быть придется что-то узнать о особенностях библ и их версий, но опять же - это в целом больше проблема майнтайнеров, а разработчикам видны только какие-то чaстные случаи, когда некую либу глобально перетрясают, так что разработчик должен знать что и почему поменяли. Неудачными решениями можно подгадить, как автор deadbeef, но обычно это нормально работает, если авторы софта и майнтайнеры готовы к неким компромиссам и немного подыгрывают друг другу (а некооперативный апстрим - это хepoво!).
> Так вот, в линухах ключевые старые (бажные) версии библиотек, если
> от них зависят установленные приложения, которые ещё не обновились в репозиториях,
> резервируются (preserve),В системе может стоять несколько версий библ. Майнтайнеры отвечают за запатченость *всех* которые есть в репах. Да, моюно использовать libusb 0.1 а можно 1.0 и апи на выбор. Майнтайнеры отвечают за отсутствие дыр и фатальных багов в обоих. А какое апи мне больше нравится - выбор за разработчиком. Лишь бы зависимости правильно указал. А в большинстве версий либ апи если и меняется то обратно совместимо, как минимум в minor версиях/фиксах. В целом все достаточно культурно и работоспособно, хотя отдельные нюансы конечно же бывают, как и везде. Я навскидку помню лишь пару либ где тотально разное апи (и подкинуты major версии, соответственно). Libsdl vs libsdl2 и libusb 0.1 vs lubusb 1.0. Это разработчики всяко заметят ибо это решения авторов либ перекроить APi "for teh greater good". Иногда - оправданно, иногда - не очень.
> хотя с виду всё хорошо: основная библиотека обновилась пакетом
> с новой версией, да. Вот только она будет использована в новых
> минорных версиях приложений, а установленные приложения её заигнорят.Ты что-то не то скушал, болтунишка. Использовать новую версию либы будут все кто от нее зависел. А если есть более старая версия либы с иным API - майнтайнеры этой либы должны следить и чтобы в ней крутых багов и дыр не было.
> Полностью обновлённый и исправленный "стек приложений" пользователь получит спустя некоторое время
И это хорошо, ибо жить на ядерном полигоне постоянно - утомительно. Понимаешь, мне еще и работающая система нужна, поэтому очень хорошо что моменты подтягивания версий софта по крупному вынесены в известные предсказуемые интервалы, между которыми все работает и можно апдейтнуть систему с целью фиксов без риска что все умрет жестокой смертью по причине нестыковки версий чего-то где-то или еще какой там ерунды.
> — когда в системе не останется устаревших версий приложений, зависимых от данной библиотеки.
В этом есть некий смысл - "устаревшая" программа могла иметь например иной формат конфига и совершенно не обязательно что апгрейд программы с версии 1.0 до 2.5 пройдет гладко. Вот майнтайнеры более-менее серьезных дистров это просекли и выступают некими вратарями между юзверями и авторами софта. Задерживая большинство невкусных шайб, летевших в ворота юзверя.
Изя ты дурак
не сокращается. Всякие Страуструпы и его последователи до..юы упорно гогнокодят на шаблонах и убивают весь этот прирост с запасом.
libvirt, libcontainer, Docker, LXC, cgroups & namespaces, ...
Прослойка на абстракции и библиотекой погоняет.
> libvirt, libcontainer, Docker, LXC, cgroups & namespaces, ...
> Прослойка на абстракции и библиотекой погоняет.Да, тут целый ворох сущностей. Но libvirt в стороне от этого, его работа с LXC/OpenVZ стремится к 0.
Эмм, да, до линукса все идеи доходят реально как до жирафа. FreeBSD получила "контейнерную виртуализацию" где-то на рубеже столетия. И да, jail от рождения (в четвертой ветке, подверсию не помню) был глюковат - но свои задачи выполнял. В отличие от ...За что собственно фряху и любили. В отличие от косого и кривого поделия RH 6.2. Про гиковский на всю голову Debian даже и вспоминать не хочется.
И никому в голову не приходило обозвать фактически улучшенный chroot - виртуализацией.
В 2001-2002 некоторые хостинг провайдеры предлагали то, что позже обзовут VPS - на базе именно механизма jail в FreeBSD. Собственно лично пользовался.
Виртуалки - это было только на мейнфреймах. Про 2001 год как год старта хайпа по виртуализации тоже прогон - реально буча началась позднее, к 2003, а то и 2004 году.
ЗЫ Линуксная фрагментированность до сих пор выбешивает - как по фичам, так и по дистрибутивам.
ЗЗЫ Нехитро иЗена травить, "сперва добейся", да? Так вот, идейной новизны в LXC - ноль. И да, у фряхи - как ни крути, а приоритет. Пусть и не вылившийся в стратегическое преимущество.
> И да, jail от
> рождения (в четвертой ветке, подверсию не помню) был глюковат - но
> свои задачи выполнял. В отличие от ...Собственно, 4.0, март 2000-го. В продакшен у нас пошла почти сразу по релизу - вместе с новым сервером и Cronyx Sigma на канал к аплинку :)
Тебя так послушать, так во всём "идейной новизны - ноль". сама бзд - это переизобретение коммерческих юниксов. Не самая удачная попытка, причём.
> - это переизобретение коммерческих юниксов. Не самая удачная попытка, причём.При том настолько не самая удачная что корпорасы пошли инвестировать в пингвин. Невзирая на то что он вылупился на 10 лет позже, да еще под GPL и (вы только подумайте!) - там делиться надо.
>> - это переизобретение коммерческих юниксов. Не самая удачная попытка, причём.
> При том настолько не самая удачная что корпорасы пошли инвестировать в пингвин.
> Невзирая на то что он вылупился на 10 лет позже,ФриБЗДя в 93 появилась, в виде студенческого зародыша. Slakware уже в 92 был.
>>> - это переизобретение коммерческих юниксов. Не самая удачная попытка, причём.
>> При том настолько не самая удачная что корпорасы пошли инвестировать в пингвин.
>> Невзирая на то что он вылупился на 10 лет позже,
> ФриБЗДя в 93 появилась, в виде студенческого зародыша.Ага — с взятым у Novell кодом AT&T Unix и оставленным по обоюдному соглашению.
"Первая официальная версия FreeBSD 1.0 вышла в декабре 1993 года.", — Wiki.
А до неё ничего не было.> Slakware уже в 92 был.
Врёшь и не краснеешь.
"Первая версия этого дистрибутива была выпущена Патриком Фолькердингом — также известным как Mr. Slackware и The Man — 17 июля 1993. Эта версия базировалась на дистрибутиве SLS и представляла собой копию 3,5" дискеты, которую можно было скачать по FTP.", — Wiki.
"
From: Patrick J. Volkerding (bf703@cleveland.Freenet.Edu)
Subject: ANNOUNCE: Slackware Linux 1.00
Newsgroups: comp.os.linux
Date: 1993-07-16 17:21:20 PST
"
— http://www.slackware.com/announce/1.0.php
> А до неё ничего не было.Ты это видел? Что там было у AT&T. Оно вообще работало?
> Subject: ANNOUNCE: Slackware Linux 1.00
> Newsgroups: comp.os.linux
> Date: 1993-07-16 17:21:20 PSTЭто называется вижу только то, что хочу увидеть.
---
В общем пох...й на прошлое.
В настоящем - BSD в жопе, из TOP500 выброшена как устаревшая.
Даже нищеброды в деревнях на свои роутеры уже не ставят!RIP и Аминь!
>> А до неё ничего не было.
> Ты это видел? Что там было у AT&T. Оно вообще работало?Не видел. Нам на первом курсе университета Паскаль преподавали и занимались мы на терминалах "СМ-4".
>> Subject: ANNOUNCE: Slackware Linux 1.00
>> Newsgroups: comp.os.linux
>> Date: 1993-07-16 17:21:20 PST
> Это называется вижу только то, что хочу увидеть.Факт в том, что в 1992 году никакой Slackware ещё не было. Во всяком случае о ней ничего не знали. Впрочем, о FreeBSD — тоже не знали, так как приставку "Free" к аббревиатуре "BSD" (обозначающей дистрибутив калифорнийского университета Беркли) она приобрела позднее.
> В общем пох...й на прошлое.
Что ж ты его так не любишь? Вон, в датах совсем запутался. :))
> В настоящем - BSD в жопе, из TOP500 выброшена как устаревшая.
> Даже нищеброды в деревнях на свои роутеры уже не ставят!И мухи продолжают не ошибаться!
> И мухи продолжают не ошибаться!На мух в этой схеме больше всего похожи кадры типа тебя.
> ФриБЗДя в 93 появилась, в виде студенческого зародыша.Только ее не с ноля писали. А на основе кода других бздей. А Торвальдс код ни у кого не копипастил.
> да еще под GPL и (вы только подумайте!) - там делиться надо.http://www.youtube.com/watch?v=9GmipSGx5r8
> а приоритет. Пусть и не вылившийся в стратегическое преимущество.Проcpaные полимеры - это не приоритет, это хреновое управление проектом, чувак.
virtuozzo и vserver появились тоже на рубеже столетия и предлагали более высокий уровень изоляции.
Linux-vserver - Октябрь 2001, если быть точным.