Всем привет! С вами Сергей Бронников, эту неделю развлекать вас здесь буду я. Может кто-то уже подписан на мой аккаунт @estet.

Последние 11 лет я связан с виртуализацией. Сначала тестирование (Virtuozzo, Parallels Desktop for Mac), теперь занимаюсь проектом OpenVZ.

Пару недель назад аккаунт вела Аня Воробьёва и твитила про терминологию: вирт. машины, контейнеры etc. Поэтому я дублировать ее не буду.

Предлагаю на неделе обсудить контейнерные технологии, opensource, разработку ядра, конференции, сообщества. Если не против, тогда начнём.

Есть у нас такой проект OpenVZ (которому уже 10 лет), который позволяет использовать OS контейнеры. А вы за App или OS контейнеры?

Основные пользователи OpenVZ это хостеры openvz.org/Hosting_provid… Так как здесь нет ни одного хостера, то интересно узнать ваше предпочтение.

@backendsecret Мне нравится docker, это удобно. Я разработчик и с контейнерами у меня не такие серьезные отношения. :)

Что-то я сходу начал с OpenVZ, а может тут никто про проект не знает или не интересно. Давайте активнее или все обедать ушли?

Кто-нибудь планирует делать доклад на @HighLoad_Conf Junior? Осталась последняя неделя подачи заявок.

Давайте я вам расскажу как весело (я не утрирую) разрабатывать продукт в opensource.

Технологии контейнеров реализованы в Linux ядре. Базовые вещи: пространства имён (PID, NET, USER, UTS) и cgroups.

Пространства имён нужны для изоляции объектов контейнера в ядре от хоста и других контейнеров.

cgroups нужны для управления ресурсами на всём сервере. Процессам контейнера 1 столько памяти, процессам контейнера 2 столько то CPU и т.д.

Когда мы начинали делать продукт Virtuozzo, то в ванильном ядре не было никаких пространств имён. Поэтому часть из них появилась в ядре Vz.

Если вы разрабатываете продукт на основе opensource, то нужно работать с апстримом и отдавать туда максимум изменений.

Советую посмотреть слайды разработчика из RedHat @nearyd. Он объясняет почему нужно работать с апстримом slideshare.net/nearyd/swimmin…

Так вот по мере того, как разные вещи для контейнеров появлялись в Linux kernel мы их портировали в ванильное ядро.

Например тред c патчами PID NS от @xemulp marc.info/?t=11837091360… Как видно, PID NS был интересен не только нам, IBM тоже это хотел.

Если вы ещё не заснули, то я продолжу свои речи.

Вообщем всё закончилось хорошо и наши патчи приняли git.kernel.org/cgit/linux/ker… PID NS появился в ванильном ядре.

Потом был черёд NETNS и первые патчи были от Даниэля Лезкано из IBM marc.info/?l=linux-kerne… Потом подключились Э. Бидерман и Д. Лунёв (OVZ).

Так с миру по нитке в ядре появились остальные пространства имён. Всем хорошо: вы не тащите с собой кучу патчей, сообщество получает фичи.

Но тут есть нюанс: не все изменения сообщество готово принимать. Иногда приходится долго убеждать людей, переделывать патчи.

Часто работа с апстримом превращается в самую настоящую политику. Тут важно работать с сообществом: ездить на конференции, работать с людьми

@backendsecret с чем связана переделка? Кодестайл не тот?

. @dcromster это все мелочи. Не всегда люди могут договориться о реализации. Или, например то, что вы хотите принести мало кому интересно.

@backendsecret а почему до контейнеров не додумались ещё во времена 2.2 2.4 ? :)

. @dcromster Гм, ну Москва тоже не сразу строилась. :) Понемногу компании делали компоненты из которых появилась технология контейнеров.

"Не пиара ради, а пользы для". Мой доклад на @lveecon youtube.com/watch?v=IIC427…, я там рассказывал про разработку OpenVZ.

Сейчас контейнеры в тренде и мне понравилась раскраска, которую сотрудники RedHat раздавали на конференции. pic.twitter.com/hYvwaJryPB

Там на примере дома для трёх поросят очень доступно объясняют что такое контейнеры :) Вот ссылка для печати github.com/fedoradesign/c…

Так, тут пришел мой руководитель и хочет, чтобы я не в твиттер писал, а начал работать.

Всё, он ушёл.

Вот так понемногу мы отдавали свои изменения ванильное ядро. Это 2k+ коммитов от разработчиков OpenVZ за всё время. pic.twitter.com/K5QfE9CLLC

Недавно Стас Кинсбурский закончил с патчами для виртуализации NFS (это не гоночки, а сетевая ФС) marc.info/?l=linux-nfs&m…

Худо бедно с пространствами имён разобрались (хотя вот UserNS только недавно появились, а Time NS вроде ещё не сделали).

В 2004 году в ядре 2.6.12 появляются cpusets man7.org/linux/man-page…

В 2006 году Поль Менаж из Гугла kernel.org/doc/ols/2007/o… переделывает cpusets и их переименовывают в control groups.

@backendsecret А что в то время представлял из себя openvz? Мне вот интересно, как давно форкнутые проекты смерживают обратно.

. @Dronmdf OpenVZ всегда был рабочим решением, просто может функциональности меньше было.

. @Dronmdf Опыт показывает, что чем раньше отсылать патчи, тем проще.

. @Dronmdf Гугл насколько помню до сих пор не может отдать свои изменения для Android в основную ветку Linux ядра.

@backendsecret Но вам приходилось покапле вливать его в ядро... Какую каплю влить первой? вот что мне интересно. :)

. @Dronmdf весь патчсет разделяется на более-менее независимые части и каждую часть пытаются отдать сообществу.

. @Dronmdf кстати тут более уместно слово "продать", чем "отдать". Нужно объяснить людям, что это стоит взять :)

Возвращаясь к теме про cgroups - недавно их переработали и выпустили в cgroups 2.0 linux.org.ru/news/kernel/12…

В OpenVZ было несколько поколений memory management: UBC, SLM, vSwap и в Virtuozzo 7 будет 4-е поколение - VCMMD goo.gl/NLDxa9

Это такой пример итеративного развития технологии управления памятью для контейнеров и пример технологии, которую в ядро не принимали.

Мы активно участвовали в разработке memory cgroups и в RHEL7, на котором мы базируемся, наши изменения появились... 1/2

...и мы смогли выкинуть предыдущие реализации MM и использовать MM из ванильного ядра. Появился vcmmd github.com/OpenVZ/vcmmd 2/2

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

У нас есть разработчик, который занимается MM. Он очень стеснительный, но мы его вытащили с докладом на митап в Яндексе.

Если интересно больше узнать про управление памятью для контейнеров, то посмотрите запись доклада youtube.com/watch?v=Mo5A-z… Очень доступно.

@backendsecret кстати, а почему в Ubuntu нет OpenVZ?

. @dcromster из-за неготовности поддерживать второй дистрибутив. Мы поддерживаем только RPM-based.

Я примерно описал сложности разработки в opensource. Но у нас есть другой продукт - контейнеры Windows. Тоже для хостеров.

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

Недавно тимлид команды по разработке Virtuozzo for Windows писал статью на Хабре habrahabr.ru/company/parall… Почитайте.

Все наши усилия по работе с сообществом не прошли даром и мы снизили общий размер патча vzkernel в 4 раза! pic.twitter.com/pwhM2JTWA1

Завтра расскажу про другие примеры компонентов, которые мы пытались "продать" в основную ветку Linux ядра.

Тут часто ведущие задают вопрос про то, кто какую музыку слушает. Я в офисе почти всё время слушаю музыку, для меня лучше Pandora ничего нет

Вообще-то этот сервис не работает в России, но pianobar вкупе с tor и polipo позволяют слушать их и в России.

Что вы делаете прямо сейчас? Только честно. Я ядро пересобираю на RPi, чтобы там можно было тесты запускать.

@backendsecret разворачиваю OpenVZ’шку с последним Squid потестить как он вообще нынче работает :)

. @strizhechenko имеет смысл пробовать Virtuozzo 7, у которой скоро будет финальный релиз. Тот же opensource, бесплатно, но фич больше.

. @strizhechenko вот сравнение с Vz7, OpenVZ, LXC openvz.org/Comparison а там сами смотрите.

@backendsecret переношу ряд mind maps в coggle, чтобы делиться ими и встраивать в бложик.

И снова здравствуйте. Прекрасный день, чтобы рассказать про наш опыт реализации "живой" миграции контейнеров в ванильном ядре.

Как я вчера рассказывал, все фичи, которые появляются в vzkernel, мы пытаемся добавить в основную ветку Linux ядра.

Задача "живой" миграции процессов и групп процессов одна из самых интересных и сложных в разработке контейнеров. Сегодня поговорим про нее.

“Живая” миграция это миграция контейнера с низким временем недоступности (downtime). Это 1-2 секунды.

Такая задержка в обслуживании, которая не повлечёт за собой разрыв открытых сетевых соединений.

Это интересная задача, но зачем нужно мигрировать state? Может, проще писать stateless системы? twitter.com/backendsecret/…

. @rubyunderhood спасибо за вопрос. Это просто два разных подхода.

. @rubyunderhood Для инфраструктуры, которую вы полностью контролируете подходит вариант stateless.

. @rubyunderhood В хостинге контейнерами управляет клиент и его окружение не всегда воспроизводимо, чтобы убить контейнер и поднять заново.

. @rubyunderhood поэтому хостеру нужно перенести контейнеры на другой сервер, чтобы выполнить обслуживание сервера

Помимо этих двух подходов есть ещё балансировка сетевого трафика (High Availability). То есть у нас два инстанса, выполняющих обслуживание.

Один инстанс выключаем и выполняем обслуживание. Качество сервиса не страдает. Потом включаем обратно.

Итого есть: "живая" миграция, stateless контейнеры (микросервисы), High Availability. А ещё есть вариант обслуживания "crash-driven".

"crash-driven" это когда вы обслуживаете сервер, когда у вас всё упало.

Миграция это: “заморозка” процессов и сохранение состояния в файлы на диске 1/2

перенос этих файлов на удалённый сервер, восстановление состояния из файлов и “разморозка” процессов. 2/2

Изначально технология "заморозки"/"разморозки" (Checkpoint/Restore (C/R)) была реализована только в ядре vzkernel в виде системного вызова.

Технология была протестирована и отлично работала, но был существенный недостаток - патчи для C/R не принимали в основную ветку Linux ядра.

К слову, были и другие проекты по реализации C/R в ядре (DMTCP, BLCR) и их реализации тоже не принимали criu.org/Comparison_to_…

Поэтому мы взялись за амбициозный проект - реализовать C/R в пространстве пользователя, а в ядро добавить небольшие необходимые изменения.

Так в 2011 году родился проект CRIU (Checkpoint and Restore In Userspace). Идея была описана и сообщество ее приняло lwn.net/Articles/45191…

Хотя и отнеслись к идее CRIU довольно скептично, но первый коммит был принят в ядро git.kernel.org/cgit/linux/ker… pic.twitter.com/9z6GfZ8qDT

За прошедшие 5 лет проект CRIU достиг версии 2.0 и готов полностью заменить предыдущую реализацию "живой" миграции. opennet.ru/opennews/art.s…

В ядро понадобилось добавить "всего" лишь сто с лишним небольших патчей criu.org/Upstream_kerne…

В основном эти патчи добавляют интерфейсы для получения необходимой информации о процессах в Linux.

На сегодняшний день "живая" миграция в LXC, Docker и Virtuozzo 7 работает с помощью CRIU. criu.org/Integration

В проекте CRIU участвуют более 40 разработчиков, в том числе из @Canonical , IBM, @google, @ru_Parallels github.com/xemul/criu/gra…

В результате мы получили возможность не "таскать" на каждое новое ядро патчсет для C/R. Сообщество получило рабочую реализацию C/R.

Лучше один раз увидеть, чем сто раз услышать :) Как работает C/R в CRIU -youtube.com/watch?v=2AjdZS…

На логотипе проекта жар-птица, русский аналог птицы феникс, восстающей из пепла. Как визуализация процесса C/R. pic.twitter.com/ddd8Xgabrc

Кстати возвращаясь к теме про stateless. Как известно, Docker это stateless. Но были желающие, которым нужна была "живая" миграция в Docker.

Это только подтверждает право на жизнь обоих подходов.

Применение CRIU не ограничивается живой миграцией. Например CRIU используется в проекте Tonic blog.tonicdev.com/2015/09/10/tim…

Если интересно больше узнать про миграцию контейнеров, то посмотрите запись доклада youtube.com/watch?v=qZoEL4…

Вот ещё демо миграции с помощью CRIU youtube.com/watch?v=mL9AFk… и описание blog.kubernetes.io/2015/07/how-di… Мигрировали Quake внутри Docker контейнера.

Интересное применение CRIU нашли в @CloudLinuxOS - они делают C/R процесса php для ускорения запуска youtube.com/watch?v=KMbwPp…

CRIU это только "заморозка" и "разморозка" процессов. Но нужен компонент который будет вызывать CRIU для C/R, переносить файлы.

Для этого есть другой проект - P.Haul (Process hauler). Мы его между собой называем “пихль”. criu.org/P.Haul

P.Haul @ProcessHauler выполняет всю черновую работу для миграции контейнера на другой сервер.

А вы участвуете в открытых проектах? Может у вас свой успешный проект? Поделитесь опытом.

Недавно публиковал статью, где объяснял, что не обязательно быть программистом, чтобы участвовать в открытом проекте habrahabr.ru/company/parall…

Привет, пупсики. А давайте поговорим про конференции. Кто какие митапы и конференции посещает.

Ездите в Европу/Штаты чтобы с народом пообщаться и поделиться опытом?

Вы или не ходите на конференции вообще или не хотите делиться.

На мой взгляд даже в Москве не так много хороших конференций о разработке в opensource. Если хочется пообщаться, надо ехать в US или Европу.

У нас к сожалению нет аналогов @fosdem, @devconf_cz, @fossasia, @lfnw, @linuxplumbers

Я обычно мониторю даты проведения конференций и у меня есть список twitter.com/estet/lists/fo… Может найдёте там что-то для себя.

Кстати кто-нибудь знает как удобно мониторить начало подачи докладов и даты конференций. Я себе сделал RSS ленту bronevichok.ru/ose/

Но лента генерируется из файла, который приходится руками обновлять. Может кто знает способ проще :)

У меня есть две темы, в которых я могу раскрыть наш уникальный опыт.

1. как мы тестируем Virtuozzo (вот уж не халява) 2. нюансы открытия исходного кода коммерческого закрытого продукта. Какую первой хотите?

Итак. Начнём с тестирования Virtuozzo, а следующей темой будет наш опыт открытия исходного кода продукта.

98% продукта Virtuozzo тестируется автоматическими тестами. Ручное тестирование в основном там, где нужно воспроизвести уникальный баг.

Для каждого релиза составляем тестплан и запускаем тесты из этого тестплана на физических серверах. pic.twitter.com/V9MWDUkHMb

Физ. серверами управляем с помощью сервиса, который обеспечивает жизненный цикл сервера: установка ОС, настройка окружения, запуск теста.

Плюс контроль состояния серверов, с помощью которого можно понять чем занимались сервера за какой-то период времени. pic.twitter.com/HgBJBWPFA9

Много серверов в QA - значит не успевают разбирать упавшие тесты, много серверов в Dev - не успевают исправлять. График выявляет проблемы.

Скриншот страницы с описанием сервера и страница запуска теста. pic.twitter.com/Lg0aY6nwfH

Каждый сервер имеет разные параметры: CPU, память, наличие SSD, скорость сетевой карты, размер HDD и шедулер тестов выбирает по этим парам.

Самописный шедулер мониторит новые билды и запускает тесты из тестплана, если найдет подходящие сервера для этих тестов.

Мы связали баги в Jira и сервис по обслуживанию серверов, чтобы было видно какой баг занимает сервер. Очень удобно. pic.twitter.com/0aHbNyIuLm

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

Virtuozzo это целостный продукт, который состоит из множества сложных компонентов: Linux ядро, гипервизор, утилиты и т.д.

Для каждой сборки Virtuozzo делаем удобные чейнджлоги, чтобы менеджер мог понять на чём акцентировать тестирование. pic.twitter.com/5Ol2jQA9tn

Все сборки Virtuozzo проходят Basic Validation Test, если тест не пройден, то билд не попадает в тестирование. Баг от BVT всегда bloker.

Если сборка прошла BVT, то на ней независимо от изменений запускаются порядка 100 тестов. Это базовые тесты, которые выявят деградации.

Если говорить о тестах, то они самые разные: юнит тестов не очень много, в основном функциональные, тесты на произв. и стресс тесты.

Функциональные тесты покрывают всякие сценарии пользователей: установить гостевую ОС, сделать бэкап, миграцию, но все это в жёстких условиях

Юнит-тесты есть мало где. Но, например, для диспетчера они есть github.com/OpenVZ/prl-dis…

Про тесты производительности Virtuozzo уже Аня Воробьёва @AnnaMelekhova написала backendsecret.ru/AnnaMelekhova/, не буду повторяться.

Особой популярностью пользуется тест start-stop, который в заданном окружении запускает и останавливает контейнеры или виртуальные машины.

Несмотря на кажущуюся простоту тест start-stop поймал нам не одну сотню багов и очень полюбился разработчикам.

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

Чем больше инстансов, тем эффективнее можно использовать каждый физический сервер. Такой тест ещё и выявляет утечки памяти.

Инстансы должны не только запуститься, но и выполнять обслуживание внешних запросов. Так мы узнаём плотность размещения на сервере.

Ядра vzkernel мы гоняем и в хвост и в гриву. Часто своими тестами находим баги, которые присутствуют в ванильном ядре или в ядрах RedHat.

Любопытный факт: мы релизы ядра раньше называли фамилиями русских художников и писателей: Феоктистов, Репин, Гоголь openvz.org/Download/kerne…

Что связывает Достоевского и Гоголя? У Достоевского было четыре с небольшим багфикса. openvz.org/Download/kerne… pic.twitter.com/sMjPsY75P4

У Репина конфиг такой же как и у Левитана #OpenVZ openvz.org/Download/kerne… pic.twitter.com/YmYJJqcLRP

Тесты для vzkernel используем как стандартные (типа LTP), так и самописные.

Ядра мы свои гоняем и в хвост и в гриву. Часто своими тестами находим баги, которые присутствуют в ванильном ядре или в ядрах RedHat.

Вот, например, Кир Колышкин @kolyshkin писал пост, где приводил примеры таких багов openvz.livejournal.com/23621.html #OpenVZ

Или вот так бывает lists.openvz.org/pipermail/deve… #OpenVZ pic.twitter.com/MpeumfyBRU

Или когда старый баг в netlink нашли patchwork.ozlabs.org/patch/83832/ #OpenVZ pic.twitter.com/vjDwt4NT4B

@peakscale we’re booting 120000 containers per day on OpenVZ, it’s okay I guess.

Так, я ушёл от темы. Продолжим про тестирование Virtuozzo.

Часто находим проблемы в безопасности Linux ядра, которые потом отправляем в RedHat. Вот примеры CVE opennet.ru/opennews/art.s…

Вообще это нормальная практика в разработке opensource - вы берёте чужой код и возвращаете туда фиксы для найденных багов.

Ещё используем два инструмента для контроля тестирования Virtuozzo: бёрндаун и график покрытия тестами. pic.twitter.com/T9Oi3HE3Ws

Графики помогают ответить на вопросы: "в каком состоянии тестирование и когда закончим".

Итого, что делает нашу тестовую лабораторию хорошей кузницей качества. И немаловажный важный фактор это конечно люди pic.twitter.com/yd4jzk0lPl

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

Доклад на тему разработки Virtuozzo speakerdeck.com/sergeyb/razrab… Там есть метрики о разработке и тестировании.

Доклад @vagin_andrey на #LinuxCon о тестировании Virtuozzo slideshare.net/andreywagin/pr…

Подробнее об автоматизации тестирования Virtuozzo я писал в статье habrahabr.ru/post/204292/

Основной акцент делаем на тестировании продукта, но некоторые компоненты тестируются отдельно. Например CRIU @__criu__.

Проект CRIU поддерживает несколько архитектур и на всех мы запускаем тесты с помощью Jenkins ci.openvz.org/view/CRIU/job/…

После релиза 2.0 мы разделили репозиторий на две ветки: master для проверенных изменений и criu-dev для новых патчей github.com/xemul/criu/tre…

Все новые патчи попадают в <s>рай</s> в ветку criu-dev и только если патч не вызвал никаких деградаций, то его комиттят в master.

Помимо тестов мы регулярно измеряем покрытие кода тестами. Сейчас покрытие составляет 64% ci.openvz.org/job/CRIU-x86_6… pic.twitter.com/W8v5Pe8DAH

Неплохо, но есть куда стремиться.

Основной тест CRIU это ZDTM (Zero Down Time Migration), которым уже успешно тестировали C/R в OpenVZ. criu.org/ZDTM_Test_Suite

Соотношение полезного и тестового кода в CRIU: 48 KLOC vs. 30 KLOC

Каждый тест из ZDTM запускается отдельно и проходит 3 стадии: подготовка окружения, «демонизация» и ожидание сигнала, проверка результата.

Тесты ZDTM условно разделены для две группы.

Первая группа — это статические тесты, которые подготавливают некое постоянное окружение или состояние и «засыпают» в ожидании сигнала.

Вторая группа — динамические тесты, которые постоянно меняют состояние и/или окружение (например пересылают данные через TCP соединение).

В первый релиз в CRIU было порядка 70 отдельных тестовых программ, а сейчас их количество увеличилось до 200 github.com/xemul/criu/tre…

Это что касается функционального тестирования. Но разработчики не брезгуют Fuzz тестированием и Fault injection lists.openvz.org/pipermail/criu…

Такие техники тестирования служат неплохим дополнением к обычным функциональным тестам.

Сложность тестирования заключается в нелинейном росте количества конфигураций. Базовое тестирование происходит на хосте и внутри контейнера.

Недавно в релиз Linux ядра вошла поддержка User namespaces и у нас добавилась ещё одна конфигурация.

Вдобавок к этому тесты запускаются в разных позах:
"сделать два раза CR и проверить что процесс работает (повторный CR)"...

"сделать CR и проверить что процесс не развалился (безресторный тест)"

"C/R нескольких процессов", "проверка обратной совместимости",
"снапшоты, в окружении неймспейсов", "C/R с правами обычного пользователя"

Длительность тестов небольшая 2-10 мин, но если учесть количество комбинаций всех сценариев и конфигураций, то получается внушительная цифра

Помимо тестирования пользуемся статическими анализаторами (clang-analyzer, Coverity) scan.coverity.com/projects/3365

Это всё, что я хотел бы рассказать о нашем тестировании. Есть вопросы - спрашивайте.

Завтра расскажу о нашем опыт открытия исходного кода коммерческого продукта.

У меня осталось два дня, а столько всего интересного ещё.

Я в предыдущие дни много писал про наш проект CRIU, но рассказал естественно не всё.

Павел Емельянов, который проект CRIU начал, согласился поделиться опытом, полученным за 4 года проекта.

История C/R глазами Павла. Вообще до нас много кто пытался сделать C/R в Linux. Все останавливались по схожим причинам.

Корень всех предыдущих провалов -- недостаток API в ядре для понимания состояния процессов. И для восстановления, но это другая история.

В восстановлении процессов основной проблемой является автоматическая генерация ядром разных идентификаторов.

Вот BLCR например, решил обойти эти проблемы написанием своего ядерного модуля. crd.lbl.gov/departments/co…

Эта идея не пошла, так как ядро развивается быстро и таскать свой код вне дерева со временем всё тяжелее.

DMTCP решали проблему добавив прокладку между ядром и программой -- свою собственную версию glibc. dmtcp.sourceforge.net

Это не заработало по той же причине -- ядро мчится вперёд быстрее, чем они успевают обновлять свою glibc.

CryoPID пытался решить проблему "в лоб", т.е. с использованием обычных Linux kernel интерфейсов. github.com/maaziz/cryopid

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

А у нас хватило! :)

По мере развития CRIU мы добавляли недостающую функциональность в ядро. На данный момент около 180 патчей criu.org/Upstream_kerne…

И то, что мы наделали в ядро пригодилось не только нам.

Например, sock_diag -- для детального изучения сокетов. На него "села" утилита ss, теперь про сокеты можно узнать гораздо больше.

Подробнее можно посмотреть в слайдах slideshare.net/openvz/speedin… и статье habrahabr.ru/post/275545/

Для unix сокетов -- с кем они соединены. Раньше такой возможности не было.

Между прочим, проблему "быстро двигающегося ядра" мы тоже не решили. Мы её оседлали :)

Вся новая функциональность ядра тоже требует соответствующей работы в CRIU.

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

Многие, кстати, при разработке своих штук в ядре уже думают "а что скажет команда CRIU, когда это увидит".

Между прочим, CRIU не заточено строго под OpenVZ, как это было у нас раньше (мы пытались делать как BLCR).

CRIU вообще готово работать не только с контейнерами.

Сообщество вокруг открытого проекта -- важная составляющая успеха.

Сообщество CRIU на сегодняшний день не такое большое, как у ядра, но и не такое крохотное как у OpenVZ kernel.

За всю историю проекта там поучаствовали кодом более 60 человек.

Их них около 10 сравнительно постоянных участников. Ну и команда Virtuozzo конечно.

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

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

Сейчас думаем как можно этот процесс автоматизировать. Дженкинс, конечно, помогает, но он не умеет забирать патчи из рассылки.

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

А ещё у нас в прошлом году была микро-конференция на @linuxplumbers, посвященная CRIU. plus.google.com/+CriuOrg/posts…

В этом мы тоже хотим её организовать, но пока докладчиков маловато. Хотя есть "гости" -- ребята из DMTCP и OpenMPI.

К слову CFP до сих пор открыт wiki.linuxplumbersconf.org/2016:checkpoin…

Интересно, что CRIU оказался отличным способом обучать студентов. И аспирантов.

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

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

Несколько человек уже дипломы защитили на CRIU тематику. И ещё несколько готовятся.

Ещё оказалось, что многие простые вещи, на самом деле сложные. Намример у нас на wiki есть статья про то, как открыть файл %)

Кстати, скоро в рамках CRIU мы поделимся с миром ещё несколькими интересными инструментами.

Именно инструментами, так как технологии уже есть, просто они намертво "вморожены" в сам CRIU.

Один из инструментов -- Сompel (компель). Программа и библиотека для внедрения паразитного кода в процессы. criu.org/Compel

Это безопасно, так как мы пользуемся обычными интерфейсами ядра, и делать ужасные вещи тому, кому это нельзя, не получится.

Это были изменения с PID, IPC и NET пространствами имён.

В разное время количество патчей в Linux ядро от Virtuozzo сильно варьировалось. pic.twitter.com/p3ZUBzkQfx

Твиттер опять испортил картинку, тут есть лучшего качества --openvz.org/File:Kernel_pa…

Осталась одна непокрытая тема - наш опыт перевода коммерческого продукта Virtuozzo в разряд открытых проектов.

Вообще-то сегодня 1-е апреля, но все последующие твиты прошу считать правдой. Всё будет серьёзно и без шуток.

Небольшой исторический экскурс: у нас был коммерческий продукт Virtuozzo c технологией контейнеров на базе ядра Linux.

На дворе был 1999 год, а ядро имело версию Linux kernel 2.2. Кстати и контейнеров никаких тогда не было, были "Virtual Environments".

В обиходе их называли "Вэ-ешки". Понятие "контейнеры" ввела компания Sun Microsystems в 2004 году.

Кстати сохранилась старая версия Virtuozzo от 2000 года - paul.sladen.org/vserver/aspcom… Там в описании ещё используется термин "VE".

В 2005 году компания SWsoft выпустила основные части Virtuozzo под лицензией GNU GPL в рамках проекта OpenVZ.

Со времени начала существования проекта OpenVZ код проекта и продукта Virtuozzo понемногу "разъезжался".

Основные пользователи OpenVZ - небольшие хостеры, у которых не было денег на Virtuozzo, но хотелось начать свой бизнес.

До сих пор этих хостеров тьма тьмущая - serverbear.com/compare?Sort=R…

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

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

Исходники выкладывали в виде архивов, но репозитория не было. Так делали чисто по техническим причинам.

Но это затрудняло участие в разработке OpenVZ - трудно было разобраться в изменениях в исходном коде.

Были хостеры, которые начинали с OpenVZ, но по мере роста хотели переехать на Virtuozzo. А такой переезд был нетривиален.

Virtuozzo и OpenVZ имели много общего, но развивались отдельно друг от друга.

По перечисленным ниже причинам мы решили объединить кодовые базы OpenVZ и Virtuozzo и сделать один продукт - Virtuozzo.

Что мы и сделали весной 2015 года - код 90% коммерческой Virtuozzo был открыт и доступен в публичном репозитории - github.com/OpenVZ

Остался один продукт Virtuozzo, который распространяется бесплатно и исходный код которого доступен.

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

В первую очередь выложили исходники RHEL7 ядра c нашими патчами opennet.ru/opennews/art.s…

По мере готовности публиковали исходный код утилит Virtuozzo opennet.ru/opennews/art.s…

Понятно, что исходного кода мало для того, чтобы использовать такой большой продукт как Virtuozzo.

Поэтому настроили автоматическую публикацию тестовых сборок Virtuozzo opennet.ru/opennews/art.s… Обновляешься и получаешь последние фичи.

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

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

Все патчи, которые нам присылали за прошедший год, были приняты. Вот например lists.openvz.org/pipermail/deve…

Для OpenVZ и Virtuozzo раздельными был не только исходный код, но и багтрекеры.

То есть команда разработки работает с одним багтрекером, а где-то сбоку репортят баги на тот же код...

Чтобы решить проблему сделали два инстанса Jira: публичный и внутренний. Множество багов в публичной джире - подмножество багов в приватной.

Летом 2015 настроили публичный инстанс джиры bugs.openvz.org и перенесли туда все существующие баги из багзиллы.

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

Выиграли все: команда разработки работает с одним багтрекером, сообщество может быть уверено, что их баги заметят.

После появления двух связанных трекеров появился соблазн открыть часть задач для команды разработки.

Если задача для новой Virtuozzo не критична для бизнеса, то нет смысла держать её только в приватной джире. Можно открыть эту информацию.

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

В разработке закрытого продукта всё просто - есть команда, все знают кто и за что отвечает. Внутренние списки рассылки, устное общение.

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

Естественно это касается только тех фич, которые в опенсорсе.

И вот тут проблема - нужно менять культуру внутри команд разработки. То, к чему люди привыкли за 15 лет.

У нас исторически есть два списка почтовой рассылки: devel@ и users@. Договорились с командой vzkernel вести всю разработку в devel@.

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

В целом изменения прошло безболезненно и сейчас вся разработка ядра идёт через devel@ lists.openvz.org/pipermail/deve…

В команде разработки утилит принят другой процесс - с помощью пулл реквестов в src.openvz.org.

Тут важно описать правила, по которым вы готовы принимать патчи от других людей openvz.org/How_to_submit_…

Это такой контракт между вами и внешними контрибьюторами. Процесс сразу становится прозрачен для внешних людей.

Культура общения с внешними людьми сама по себе не появится, поэтому нужно идти к этому постепенно. Вовлекать людей в почтовые рассылки, IRC

В общении с сообществом есть один нюанс. Бывает, что люди из сообщества пишут о проблемах использования на личную почту.

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

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

1. Воспользоваться помощью сообщества (список рассылки, IRC, форум) 2. Оплатить техническую поддержку.

Важное значение для проекта имеет информация о текущем статусе проекта.

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

В нашем опыте была ошибка: мы задержали переезд на ядро RHEL и не давали сообществу никакой информации о наших планах.

Это не очень благотворно сказалось на репутации проекта. Поэтому держите сообщество в курсе ваших планов насколько это возможно.

Учитывая этот опыт мы исправились и регулярно публикуем дайджесты изменений в проекте lists.openvz.org/pipermail/user…

Публикуем даты поддержки openvz.org/Releases и ближайшие планы openvz.org/Roadmap

Отдельно сообщаем о появлении в тестовых сборках новой функциональности lists.openvz.org/pipermail/user…

Общение с сообществом двунаправленное. Если нам нужен фидбек, но пользователи готовы его нам дать.

При переезде на RHEL7 был вопрос: оставить SimFS или нет. Все коммерческие клиенты уже использовали ploop и логично было SimFS выбросить.

Но простой вопрос "А кто-то использует SimFS?" вызвал широкое обсуждение simfs vs ploop lists.openvz.org/pipermail/user…

Если вы рассчитываете, что ваш проект может кого-то заинтересовать, то имеет смысл описать как поучаствовать openvz.org/Contribute

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

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

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

На мой взгляд сообщество с появлением Virtuozzo 7 только выиграло.

Для пользователей открытой версии доступна функциональность, которая раньше была только у коммерческих пользователей.

Плюс отсутствие vendor lock-in: c открытием исходного кода у пользователей появляется возможность вносить изменения в продукт самостоятельно

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

Это был забытый вчерашний твит. Был вчерашний, стал сегодняшний.

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

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

Потому что “свободных” рук всегда не хватает.

Это снаружи выглядит, что OpenVZ это проект большой коммерческой компании Parallels и там всё делают сотрудники компании.

А по факту проект долгое время лежал на плечах одного сотрудника (Кир Колышкин), который управлял им в одно лицо.

Это и работа с сообществом, и обновление документации, и присутствие на профильных конференциях, разработка и т.д.

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

Кто-то помогает на конференциях, кто-то отвечает на форуме и в списке рассылки менее опытным пользователям.

Вообще волонтёры это огромный плюс мира опенсорса.

Для всех мотивация может быть разной. Кто-то в свободную минуту поможет человеку на форуме, для кого-то по фану починить надоедливый баг.

Мы в свою очередь как можем поощряем волонтёров openvz.org/Membership

Я довольно часто на форумах слышал такой упрёк в нашу сторону: “Вы русские, а документация у вас только на английском."

Но английский это универсальный язык, тем более в сфере IT. Документация на двух языках это как минимум дублирование усилий.

И интересно наблюдать как люди проявляют инициативу в том, что им кажется неправильным.

Один пользователь взялся за написание руководство для Virtuozzo на русском языке github.com/Amet13/virtuoz…

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

Разработчики тоже интересуются нашими компонентами для контейнерной виртуализации. Но тут нужно понимать, что не у всех хватает компетенций.

А у кого хватает компетенций тот шлёт патчи :) В разработке vzctl за всё время существования OpenVZ поучаствовали порядка 200 человек.

Но по понятным причинам, наиболее активными разработчиками компонентов Virtuozzo/OpenVZ являются сотрудники компании.

Вклад в исходный код проекта сильно зависит от популярности и востребованности проекта, его зрелости и т.д.

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

Поговорим про будущее технологии виртуализации.

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

Недостатки виртуальных машин: низкая плотность. Плюсы: любая ОС и отличная изоляция.

Все Pro и Contra перечислять не буду, можно здесь посмотреть, если интересно - openvz.org/WP/Containers_…

Примерно год назад Intel анонсировала технологию Clear Containers clearlinux.org/features/clear…

Это такой Proof-of-Concept технологии на стыке виртуальных машин и контейнеров.

Это легковесные виртуальные машины на основе гипервизора KVM, которые могут иметь плотность размещения на уровне контейнеров и все плюсы ВМ.

Если говорить только о контейнерах, то следуя моде на микросервисы, все большие обороты набирает популярность app контейнеров (Docker, Rkt).

И конечно всему этому способствует доступность контейнеров буквально "из коробки".

Даже консервативная Microsoft двигается в сторону контейнеризации.
azure.microsoft.com/en-us/blog/new… Хотя у них пока "недоконтейнеры".

Хотите полноценные и с поддержкой - пользуйтесь Virtuozzo for Windows :)

Из-за всей этой шумихи появляется много игроков на рынке виртуализации, контейнерной в частности.

"Мы поддерживаем Docker" кричат все они :) В надежде обратить на себя внимание.

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

Мы в Virtuozzo считаем важным стандартизировать контейнеры в Linux. Чтобы не дублировать усилия и работать в одном направлении.

Вообще все существующие контейнерные проекты на рынке не только конкуренты друг другу. Мы стараемся совместно разрабатывать общие компоненты

Тот же Docker занимается запаковкой и запуском приложений, а мы виртуализацией — низкоуровневой технологией, которая используется в Docker.

Хороший пример — проект libcontainer, библиотека для управления ядерными компонентами, с помощью которых создаются контейнеры.

Docker изначально задумывался как проект по управлению шаблонами контейнеров и запускал их сначала с помощью vzctl.

Потом разработчики перешли на LXC, а еще позже задумали свою библиотеку — libcontainer.

Одновременно с этим мы решили «стандартизовать» околоядерную часть контейнеров и сделать низкоуровневую библиотеку.

Итого на тот момент получилось аж три «движка»: наш LibCT, LXC и libcontainer.

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

Поскольку цель у этих проектов была одинаковая, то мы решили объединить усилия.

В libcontainer у нас несколько интересов: 1. сейчас для того, чтобы работать с контейнерами, нужно сделать выбор между несколькими проектами

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

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

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

Сейчас libcontainer существует под именем runc и развивается консорциумом компаний-разработчиков runc.io

А вообще таких консорциумов два: Open Containers opencontainers.org и Cloud Native Computing Foundation cncf.io

Это всё, что я хотел бы вам рассказать :) Спасибо за внимание.

Надеюсь, что вам было интересно, несмотря на то, что тематика моих твитов не совсем соответствовала тематике @backendsecret.

Последний твит - просьба нашего HR менеджера. "Мы ищем таланты! virtuozzo.com/about/#careers".

Всем удачных выходных! А мне пора на тренировку :) Будут вопросы пишите @estet.