estet

28 марта 2016, Worldwide

# Понедельник 69 твитов

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

9:58

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

9:59

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

10:03

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

10:08

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

10:21

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

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

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

10:45

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

10:53

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

11:19

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

11:27

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

11:28

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

11:29

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

11:31

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

11:35

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

11:37

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

11:38

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

11:40

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

11:41

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

11:42

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

11:52

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

11:55

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

11:58

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

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

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

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

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

12:05

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

12:07

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

12:13

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

12:14

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

12:17

Всё, он ушёл.

12:20

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

12:24

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

12:26

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

12:29

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

12:33

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

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

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

12:38

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

12:39

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

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

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

12:42

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

12:43

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

12:45

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

12:48

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

12:50

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

12:55

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

12:56

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

12:57

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

12:58

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

12:59
@backendsecret кстати, а почему в Ubuntu нет OpenVZ?
13:01

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

13:01

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

13:07

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

13:08

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

13:10

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

13:17

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

13:20

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

13:31

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

13:34

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

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

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

14:02

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

14:03
@backendsecret прокрастинирую

Тоже хорошо. twitter.com/melnikov_p/sta…

14:03
@backendsecret пишу тесты =)

Какое-то ПО станет чуточку лучше :) twitter.com/PZabolotniy/st…

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

# Вторник 42 твита

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

8:45

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

8:55

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

9:03

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

9:20

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

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

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

9:22

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

9:23

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

9:23

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

9:25

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

9:28

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

9:28

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

9:29

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

9:30

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

9:41

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

9:41

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

9:54

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

9:55

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

9:58

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

10:01

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

10:05

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

10:07

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

10:16

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

10:18

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

10:19

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

10:21

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

10:25

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

10:27

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

10:30

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

10:33

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

10:35

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

10:36

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

10:42

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

10:58

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

11:59

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

12:17

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

12:23

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

12:24

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

12:32

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

13:01

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

13:13
@backendsecret github.com/akumuli/Akumuli

Time-series database, 6 контрибьюторов. Неплохо :) twitter.com/Lazin/status/7…

13:19

# Среда 82 твита

@backendsecret недавно стартанули github.com/WorldBrain/Web…

Можно присоединиться :)

Кому интересно - присоединяйтесь! :) twitter.com/mr_mig_by/stat…

8:04

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

9:24

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

9:24

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

11:45

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

11:47

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

11:50

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

11:54

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

12:06

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

12:06

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

12:17

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

12:18

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

12:59

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

13:02

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

13:16

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

13:24
@backendsecret Тестируете каждый билд? как делаете деплой на железки?

Об этом дальше :) twitter.com/Dronmdf/status…

13:27

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

13:28

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

13:30

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

13:32

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

13:34

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

13:39

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

13:41

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

13:43

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

13:46

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

13:47

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

13:52

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

13:53

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

13:56

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

13:58

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

13:59

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

14:04

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

14:06

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

14:09

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

14:12

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

14:13

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

14:14

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

14:17

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

14:23

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

14:25

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

14:27

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

14:31

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

14:32

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

14:35

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

14:39
Builds now running on OpenVZ - We moved our entire build infrastructure to an OpenVZ based virtualization... tmblr.co/Zy8qosg4nUU5

Инженеры в @travisci вполне довольны стабильностью OpenVZ twitter.com/travisci/statu…

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

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

14:43

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

14:44

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

14:45

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

14:50

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

14:50

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

14:53

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

14:55

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

14:56

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

14:57

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

14:59

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

15:00

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

15:01

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

15:02

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

15:04

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

15:05

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

15:05

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

15:09

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

15:14

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

15:15

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

15:16

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

15:16

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

15:17

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

15:19

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

15:21

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

15:22

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

15:24

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

15:25

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

15:29

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

15:30

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

15:30

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

15:31

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

15:34

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

15:36
@backendsecret Впечатляет... Так что насчет деплоя на железо? Как вы это делаете?

WinPE/PXE twitter.com/Dronmdf/status…

15:45

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

15:51

# Четверг 49 твитов

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

10:19

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

10:21

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

10:21

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

10:24

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

10:25

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

10:28

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

10:30

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

10:31

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

10:34

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

10:36

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

10:38

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

10:40

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

10:42

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

10:44

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

10:45

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

10:46

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

10:49

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

10:49

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

11:14
@backendsecret у меня в гостях в SDCast'е был Андрей Вагин, рассказывал про CRIU: sdcast.ksdaemon.ru/2014/12/sdcast… Для тех, кто не слышал.

Сам слушал, было интересно :) twitter.com/KSDaemon/statu…

11:15

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

11:16

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

11:17

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

11:18

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

11:22

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

11:23

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

11:37

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

11:38

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

11:42

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

11:43

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

11:52

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

11:53

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

11:56

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

11:59

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

12:01

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

12:02

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

12:03

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

12:06

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

12:08

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

12:09

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

12:10

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

12:14

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

13:07

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

13:08

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

13:10

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

13:11
@backendsecret какой у вас % в ядре?

В 2009 году вошли в 10-ку компаний linuxfoundation.org/sites/main/fil… twitter.com/dcromster/stat…

13:14

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

13:15

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

13:17

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

13:18

# Пятница 70 твитов

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

9:09

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

9:17
@backendsecret есть вопрос - какой версии тут РНР? habrastorage.org/getpro/habr/co…

Версия определённо включает круглое число, но какая именно - не разобрать. twitter.com/tkachenko/stat…

9:27

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

9:33

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

9:35

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

9:37

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

9:40

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

9:42

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

9:47

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

9:50

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

9:50

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

9:52

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

9:54

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

9:55

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

9:56

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

9:57

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

9:59

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

10:00

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

10:02

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

10:04

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

10:06

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

10:07

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

10:10

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

10:11

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

10:13

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

10:14

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

10:19

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

10:20

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

10:22

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

10:23

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

10:24

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

10:28

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

10:29

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

10:30

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

11:02

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

11:03

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

11:05

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

11:07
@backendsecret а как почувствовали себя после появления нескольких источников задач? Неудобно ведь.

Как раз остался один источник - внутренняя джира, в которой появляются дефекты из публичной джиры. twitter.com/strizhechenko/…

11:08

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

11:10

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

11:10

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

11:11

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

11:13

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

11:14

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

11:15

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

11:17

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

11:18

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

11:18

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

11:21

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

11:25

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

11:27

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

11:28

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

11:28

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

11:32

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

11:33

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

11:34

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

11:35

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

11:37

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

11:38

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

11:40

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

11:42

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

11:43

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

11:44

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

11:54

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

11:55

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

11:55

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

11:58

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

11:59

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

12:00

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

12:02

# Суббота 57 твитов

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

9:57

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

9:57

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

10:00

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

10:57

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

11:02

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

11:02

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

11:03

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

11:07

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

11:09

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

11:15

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

11:22

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

11:25

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

11:32

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

11:44

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

11:44

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

11:45

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

11:50

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

11:52

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

11:54

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

11:55

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

11:59

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

12:00

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

12:02

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

12:08

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

12:08

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

12:10

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

12:13

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

12:23

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

12:38

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

12:39

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

12:40

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

12:42

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

12:42

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

12:46

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

12:47

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

12:47

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

12:48

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

12:50

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

12:50

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

12:51

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

12:52

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

12:53

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

12:53

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

12:54

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

12:54

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

12:55

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

12:56

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

12:59

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

13:00

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

13:01

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

13:02

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

13:03

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

13:06

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

13:11

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

13:12

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

13:13

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

13:14

openvz.org

www.youtube.com

github.com

habrahabr.ru

criu.org

www.opennet.ru

lists.openvz.org

other