Наконец-то, после 25й (!) итерации, OverlayFS включили в дерево vfs.git. Еще пара-тройка шагов, и его включат в официальный Git-репозиторий Торвальдса.

OverlayFS, это результат более чем четырехлетней разработки Miklos Szeredi, разработчика FUSE. Целью проекта является создание "многослойной" файловой системы, объединяющей другие файловые системы в одну, и предоставляющей возможность "форка" полученной системы. Одним из приложений этой функциональности были LiveCD, которые таким образом планировали предоставлять возможность прозрачного доступа к системе на чтение-запись. Еще вариантом использования была функциональность "factory reset" в embedded-системах (телефоны, роутеры, медиаплейеры), когда основная система никогда не изменялась, а настройки велись в union-fs. С развитием облачных технологий появилось еще одно применение - большая часть облачных систем идентична, и хочется эту общую часть разделять между сотнями и тысячами контейнеров в хостовой системе одновременно позволяя всем контейнеризированным приложениям ее изменять, если нужно.

Существовало несколько реализаций Union-FS в разных системах (хороший обзор был сделан Valerie Aurora на LWN.net - первая часть и вторая часть), но в Linux ни одна из реализаций не добралась до ванильного ядра. Причин тому много - архитектурная усложненность, низкое качество кода, высокий уровень ненависти в рассылке ядра социально-личностные проблемы. Ближе всех к ядру подобралась было AuFS, и ее даже поспешно включили в ряд Debian-based дистрибутивов. Но быстро выяснилось, что это было ошибкой, т.к. система оказалась чрезвычайно сложной, хрупкой, и бесперспективной для включения в ядро. Но ущерб поспешными действиями мэйнтейнеров был нанесен - разработчики Docker, по наивности полагаясь на возможности, присутствовавшие в самом популярном Linux-дистрибутиве, решили базироваться на aufs. Непонятно, почему они не проконсультировались с нашими коллегами, которые бы наверняка подсказали более рациональное решение. Так или иначе, когда у Red Hat появился интерес к Docker, то наши коллеги протянули руку помощи зашедшему в архитектурный тупик проекту, переведя его на Device Mapper.

История OverlayFS началась давно, и по сравнению с другими вариантами, система выглядела очень простой. Мэйнтейнеры ядра, придерживаясь их неповторимого стиля общения в списке рассылки ядра, отозвались о патчсете окрыляюще для начинающих - Andrew Morton сказал, что ему проще не принимать его, а на последовавшее предложение перенести функционал в FUSE-модуль в userspace, Linus Torvalds, в присутствии разработчика userspace-файловых систем, высказался, что люди, разрабатывающие файловые системы в userspace просто заблуждаются. Получив свою дозу мотиваторов, Miklos за три года совершил еще две дюжины попыток, и наконец-то пробился!

Одним из первых пользователей OverlayFS были разработчики OpenWRT, и недаром - factory reset и откат при аварии обновления для них является обязательной фичей. Как вы знаете, атомарное, консистентное, изолированное и надежное обновление системы в рамках старой Linux-архитектуры сейчас в общем случае невозможно. Особенно сложно добиться хотя бы частичного удовлетворения ACID, если использовать не RPM, а один из нестандартных самодельных пакетных менеджеров (некоторые из них довольно популярны, и их примитивность и малофункциональность порой видится их наивными пользователями как преимущество перед сложным RPM). Наши коллеги работают над надежными апдейтами довольно давно - offline-апдейты, перенос всего в /usr, использование btrfs, контейнеризация и изоляция приложений, инициатива Fedora Atomic, и многое другое. До чего-то работающего еще пока, к сожалению, довольно далеко.

После визита в гости к известному хулигану и матершиннику, давнишнему пользователю Fedora, Linus Torvalds, и после посиделок у другого нашего коллеги, Jes Sorensen, Linux Foundation навестили еще одного нашего коллегу. Встречайте, Linux Foundation в гостях у John Linville!



Мы уже рассказывали о печальной судьбе патчсета -RT. Вкратце повторим - его тянет на себе единственный доброволец, Thomas Gleixner. Несмотря на то, что на его труде строятся коммерческие продукты ряда компаний, от них ему ничего не перепадало. Из компаний его спонсировала в основном Red Hat, которая и так оплачивает разработку почти всего опенсорса, но та больше не спонсирует, т.к. проект непрофильный. Профильной его работа является для компаний, разрабатывающих embedded-продукты, но они вообще ему никак не помогали. Вообще, если Томас надеялся на чувство справедливости у любителей придержать исходники до публичного скандала, а потом кинуть в толпу форкнутый U-Boot трехлетней давности и пропатченное ядро Linux 2.6.14 без истории изменений, в одном большом ZIP-файле с бинарными модулями без исходников, которые и собрать-то не всегда получается, то он жестоко просчитался.

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

...[Томас] получил письма от примерно двух дюжин компаний, которые спрашивали его о расписании выхода Linux 3.16-rt, потому что это требуется для планирования выхода их коммерческих продуктов. Он отвечал им, что у него нет бюджета, чтобы планировать, и спрашивал их не могут ли они помочь? Некоторые компании не ответили вообще, что Томас назвал "честным подходом". Другие ответили, что денег нет. Создавать продукт на основе технологии, и не иметь бюджета, чтоб работать над ней, это "безумие", по словам Томаса. А вот третьи сказали, что раз так, то они будут разрабатывать продукт на основе ядра 3.12-rt.
Удивительно, но денег на проект не оказалось даже у US Navy. Ну если и натовская военщина не хочет помочь, то Томас сказал, что раз так, то разрабатывать RTLinux на постоянной основе он прекращает, и будет относиться к нему, как к хобби.


Thomas Gleixner после общения с M***a V***a и натовцами

Выложили видеозаписи всех выступлений с ежегодного мероприятия Gstreamer Conference, которое проводится с 2010 года. Enjoy!

Приближается еще одно мероприятие - OpenStack Summit November 2014 Paris. Оно состоится в Париже, с 3го по 5е ноября (2го начинается регистрация, а 6го и 7го тусовочные дни). Расписание очень плотное, и наших коллег там будет прилично. Ожидается заезд наших соотечественников из компании Mirantis, от которой будет представительная программа, как и положено одному из лидеров разработки OpenStack.

Присоединяйтесь!

Только что анонсировали очередной митап DevOps Moscow коммьюнити:

После летнего перерыва возвращаемся к DevOps митапам. В этот раз эксперимент - будем проводить митап в будний день. К нам приедет Jérôme Petazzoni из компании Docker и расскажет нам о Docker из первых рук. Программа мероприятия будет позже. Ждите обновлений.


Мероприятие состоится 29 октября, с 18.00 по 22.00 в офисе Badoo, БЦ "Легенды Цветного", сразу напротив метро Трубная. Цветной бульвар, 2, стр. 1 Зарегистрируйтесь, чтобы получать обновления.

Вслед за списком пожеланий от разработчиков systemd, у разработчиков GNOME появился свой GNOME Kernel Wishlist.

Появилось дополнение к новости о выходе версии 1.2 утилиты для сборки RPM, mock. Michael Šimáček решил поподробнее рассказать о нововведениях в этой версии. которых больше, чем было анонсировано. И действительно, список новинок довольно значителен:

  • Уже упомянутый плугин для LVM. Это изменения для больших билд-ферм, которое будет использовать фичи LVM по созданию снапшотов. Общая пакетная база, из которой собираются rootfs для сборки, как правило, довольно значительна. Поэтому LVM должен сильно экономить время на перегенерацию roots при его использовании. Раньше мы использовали тарболы, которые распаковывались в chroot.
  • Улучшение производительности с помощью nosync при перегенерации Yum DB при сборке rootfs. В случае создания rootfs особая надежность на случай аварии не нужна, поэтому нет нужды вызывать большое количество раз fsync (man 2 fsync), что ускорит сборку пакетов.
  • Поддержка dnf. Мы уже используем dnf в быту - работает надежно, хотя порой иначе, чем yum, что замечали и наши коллеги. Пока фича считается экпериментальной.
  • Улучшенный режим журналирования. Теперь mock печатает в консоли и вывод Yum/DNF и rpmbuild.
  • Меньшее количество блокирующих операций. Некоторые операции над rootfs теперь поддерживают множественный доступ, например shell-доступ к ней, прямо в процессе сборки.
  • Теперь mock может выполнять дополнительные команды Yum/DNF, например mock --pm-cmd clean metadata-expire.
  • В процессе сборки rootfs можно выполнять команды --enablerepo и --disablerepo пакетного менеджера.
  • Долгожданная команда short-circuit, позволяющая проходить заново обвалившиеся стадии без запуска с самого начала.
  • Возможность передачи дополнительных аргументов в rpmbuild. Например для выбора алгоритма сжатия в финальном пакете.
  • Теперь можно задавать свои пути к утилитам rpm, rpmbuild, yum, yum-builddep, dnf. Таким образом можно легко подменять их своими версиями, без необходимости изменять system-wide копии.
  • Автоматическая инициализация и улучшенная очистка после завершения.
  • Поддержка Python 3.
  • Малоизвестная фича --unique-ext. Она позволяет запускать в параллель несколько сборок одного и того же пакета, с тем же названием. Напрямую это сделать нельзя, т.к. сборки будут использовать одну и ту же директорию для chroot, а благодаря этому ключу к названию добавится указанный суффикс, и конфликта не будет.


Конечно, пока наша инфраструктура неидеальна, но судя по таким новостям, мы потихоньку движемся в верном направлении!

Мы всегда говорим, что киборги-админы локалхоста, читающие логи "глазами" (например, раз, два, три), и проклинающие "бинарные логи", просто не знакомы с задачами, которые возникают, когда надо не только читать /var/log/messages, но и осмысливать прочитанное. И вот, в новых вакансиях Яндекса, мы с интересом увидели практические примеры задач на анализ логов:

Эксперт по нагрузочному тестированию
...
Продемонстрируйте свои знания
...
Вопрос 4

Перед вами пример части access-лога web-сервера, на котором работает сервис Яндекс.Погода.

[10/Jul/2010:00:13:18 +0400] pogoda.yandex.ru 2.2.2.2 "GET /chernigov HTTP/1.1" 200 "http://www.yandex.ua/" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0)" 113
[10/Jul/2010:00:13:19 +0400] pogoda.yandex.ru 3.3.3.3 "GET /russia HTTP/1.1" 200 "http://pogoda.yandex.ru/27612/choose/" "Opera/9.52 (Windows NT 6.0; U; MRA 5.5 (build 02842); ru)" 119
[10/Jul/2010:00:13:20 +0400] pogoda.yandex.ru 5.5.5.6 "GET / HTTP/1.1" 302 "http://www.yandex.ru/" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; InfoPath.2)" 203


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

1) топ-3 рефереров, с которых перешли на главную страницу сервиса (/) или на страницу с прогнозом погоды в Москве (/moscow), и число таких переходов;
2) в какое время уложилось 95% запросов (время ответа в мс указано в последнем столбце каждой строки) для страниц с прогнозом погоды в Киеве (/kiev).

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


и еще одна вакансия:

Стажёр-тестировщик
...
Продемонстрируйте свои знания
...
Вопрос 11

Перед вами часть access-лога веб-сервера, на котором работает Яндекс.Погода.

[10/Oct/2012:00:15:32 +0400] pogoda.yandex.by 178.122.164.78 "GET / HTTP/1.1" 302 "-" "Opera/9.80 (Windows NT 5.1; U; Edition Yx 01; ru) Presto/2.10.229 Version/11.60" "-" 0.008 - 1170
[10/Oct/2012:00:15:35 +0400] pogoda.yandex.ru 212.193.232.183 "GET / HTTP/1.0" 302 "-" "-" "-" 0.011 - 1237
[10/Oct/2012:00:15:37 +0400] pogoda.yandex.ru 78.46.121.182 "GET /kemerovo/details HTTP/1.1" 200 "http://pogoda.yandex.ru" "Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)" "-" 0.314 - 93275
[10/Oct/2012:00:15:38 +0400] pogoda.yandex.ru 93.158.129.212 "GET /astrahan/ HTTP/1.1" 200 "-" "Python-urllib/2.5" "-" 0.183 - 37160


Любым удобным для вас способом определите для полного лога из нескольких миллионов строк:

1) количество запросов для каждой секунды суток;
2) число 5хх HTTP-кодов ответа.

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


Те наши читатели, которые хоть немного знакомы с SQL, уже могли заметить, что вопросы довольно характерные. Мы бы хотели задать дополнительные вопросы соискателям:

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

Страницы