Наконец-то вышла Fedora 22!

Конечно, некоторые наши коллеги уже переехали на Fedora 23, но, тем не менее, новость для конечных пользователей прекрасная. Коллеги-аналитики уже обсуждают новость на OpenNET.ru, ну а мы пойдем обновлять продакшен-сервера до 22й версии.

Ну и одновременно с Fedora 22 для основных архитектур, вышла сборка Fedora 22 для AArch64.

Наш коллега, Hans de Goede, объявил о своем присоединении к разработке открытого драйвера для видеокарт NVIDIA, Nouveau. Теперь у Red Hat есть два разработчика, которые на благо всего коммьюнити работают над проектом.

Наш коллега, Christian Hergert, радостно сообщает о новом релизе GNOME Builder - 3.16.3.
Среди новинок:

Окно приветствия было полностью переписано. Язык программирования теперь извлекается из .doap файла. Правда, заработает это только, когда будет правильный tracker-miner.

Добавлена мини-карта по исходным кодам.

Добавлено недостающее и убрано лишнее из настроек.

Добавлено автодополнение через использование ctags.
Другой наш коллега, Dimitris Zenios, патчил несколько недель и допатчился добавил подсветку парных элементов XML.

Пример использования автодополнения через ctags и clang.

Наверняка все знают, но если кто еще нет, то вот - уже послезавтра состоится Red Hat Forum: Moscow 2015. Регистрируйтесь, кто не зарегистрировался.

Анонсирована очередная встреча Moscow Python User Group, которую планировали провести еще с осени 2014.



28-го мая (четверг) в 19:00 пройдёт вторая встреча нашего сообщества на тему: "Async: why and when?". Программа и гости ожидаются невероятно крутые.

  • Обзор положения дел в asyncio
    Андрей Светлов, LevelUp, Python Core Developer
  • Async: why and when? Cравнительный анализ данных фреймворков: asyncio, gevent, twisted, tornado
    Алексей Гречишкин, Rambler&Co, Тимлид
    Злата Обуховская, Rambler&Co, Тимлид "Рамблер-Новости"
  • Мертв ли R? Или статистический анализ данных с помощью Python
    Павел Клеменков, Rambler&Co, Руководитель отдела машинного обучения
  • Let it crash: what Python can learn from Erlang
    Benoit Chesneau, Enki Multimedia, Web Craftsman

Мероприятие пройдёт в офисе компании Rambler&Co (для входа потребуется паспорт). Обязательная регистрация на Timepad.

И, до встречи, друзья.)

P.S. Отдельное спасибо компании Rambler&Co за помощь в организации. Саше Шорину ( доклад на первой встрече ) и Александру Зеленяку за то, что они всё-всё сделали, чтобы это мероприятие состоялось.



Приходите!

Вчера была анонсирована крайне опасная уязвимость в коде KVM/Qemu - Venom (CVE-2015-3456). Вкратце, дыра в коде виртуального флоппи-диска позволяет вырваться за пределы гостевой системы, в процесс Qemu. Очень опасная уязвимость, и обновления уже вышли - рекомендуем сначала обновиться, а потом читать дальше.

Но есть и хорошие новости! Если у вас работает SELinux, то вырваться дальше, в хостовую систему, не получится, сообщает нам в своей ленте Google+ наш коллега, Daniel P. Berrangé. Дело в том, что в KVM/Qemu уже давно штатно включена технология sVirt, разрабатываемая с 2008 года, и использующая SELinux или AppArmour. Наш коллега, Dan Walsh, как раз презентовал технологию в 2009 году. Эту ошибку sVirt + SELinux не исправляет, но ущерб радикально ограничивает - зловред не выпрыгнет за пределы ресурсов, выделенных отравленному процессу.

Разумеется, если вы наслушались анонимных аналитиков, которые рекомендуют отключить SELinux (например, ноль, раз, два, три, четыре и т.п.), т.к. "мешает работать", "ненужно" и т.п., и правда отключили его, то вы сами виноваты. Интересно, что некоторые из коллег-аналитиков регулярно задают нам вопросы типа "приведите хоть один пример, когда SELinux помог?". Как говорится, "никогда такого не было, и вот опять".

Dan Walsh объявил об успешном включении еще одной опции для журналирования в Docker - ведение журнала напрямую в Journal. Ранее были доступны опции syslog, json (по умолчанию), или "без журнала".

Gergely Nagy, инженер Balabit (создатели syslog-ng) и участник Debian, попытался объяснить, почему бинарные логи, это хорошо, а текстовые плохо. Чуда не случилось - анонимные коллеги-аналитики привычно обвинили его в поццерингофилии, в том, что он некомпетентен, не умеет регекспы, и т.п.

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

Одной из слабых сторон Docker является просто все. Среди этого недлинного списка особо хочется отметить управление сетью. Когда нужно запустить три разных версии руби (например для сборочных тестов в разных дистрибутивах), все хорошо - отработало, и отвалилось. В более сложных случаях (миграция, например), нужно что-то делать с адресами и портами.

Осознание этой необходимости породило ряд решений по управлению сетевым трафиком внутри гипервизора или между ними. Некоторые проектировались именно с прицелом на Docker, и с пониманием того, что целевая система отстает от Red Hat на несколько лет, а в ряде ключевых моментов, принципиально не поддерживает ряд т.н. "ненужных" фич (например, как в случае упорного игнорирования systemd, мол "ненужно"). Тем не менее, система, повторимся, оказалась популярна, и это давление снизу заставляет проектировать решения в т.ч. и на ее основе. А это накладывает отпечаток на используемые технологии, разрешая полагаться лишь на доступный функционал.

Когда представитель Docker выступал в столице, на YaC 2014, он предложил новый класс компонентов, "Ambassador". Это прокси-сервер (прокси-серверы), принимающий соединения, и обладающий информацией об актуальной топологии распределенной системы, обновляющейся с помощью одного из существующих механизмов service discovery. Если контейнер мигрируется или перезапускается на другой машине, то Ambassador перевосстановит связь согласно изменившейся топологии. Ни клиент, ни контейнер, предоставляющий сервис, изменений не увидят, и соединение не пострадает. Одно скажем сразу - благодаря этому архитектурному элементу, ряд анонимных коллег-экспертов получил шанс понять, что средства service discovery, даже тот же Avahi, это не "ненужно", а очень даже нужная вещь.

Помимо концепции Ambassador, появились и другие варианты организации сети. Ambassador плох хотя бы тем, что если мы нарисуем схему того, как по нему идут пакеты данных, то увидим несколько нырков из ядра в юзерспейс и обратно. Хорош же он тем, что следуя концепции "лучше сделать быстро, чем хорошо" он прост и в реализации, и в использовании. Сложность там в основном идет на решение задачи о поддержании актуальной информации о топологии, ну и как то надо решать задачу связности системы (А видит B, B видит С, А и C не соединены напрямую - как передать данные от A к C?).

Надо отдельно упомянуть грустную, но вполне обычную картину слабости горизонтальных связей в больших компаниях. Под укреплением внутрикорпоративных связей девушками, на которых обычно и взваливается непонятная им задача повышения внутрикорпоративного духа, чаще всего понимается некая оффлайновая добровольно-приказная активность (хорошо если с алкоголем, а то порой и без него - нам рассказывали как-то печальную историю корпоративного мероприятия в США, в вегетарианском ресторане), где народ быстро разбивается по привычным кучкам, не изменяя конфигурацию кластера. Чего тут говорить, если на мероприятии Google I/O 2013, разработчики AudioFlinger, аналога Pulseaudio для Android, рассказалли, как они с удивлением ознакомились с подсистемой cgroups, разработанной несколько лет назад их же коллегами, буквально за соседней дверью? Если уж в настолько новаторской компании есть такой неосвоенный ресурс для улучшения ситуации, то что говорить о других? Так вот, в ряде организаций есть нездоровый недостаток общения между программистами / девопсами и бухгалтерией и инженерами NOC. Это выливается в то, что там, где можно стукнуть парой команд на Cisco-свитче, программист, не зная о том, что (и не зная как) задачу решили лет 30 назад, упорно долбится с отбойным молотком Golang. Результат скорее всего будет далек от оптимального.

Вариант poor-man's SDN Weave, от одноименной команды из разработчиков RabbitMQ, выглядит интереснее, т.к. помимо всего прочего они обещают решить задачу сложной, многозвенной топологии. Но какой ценой? Как выяснилось, ценой падения пропускной способности до 6% номинальной, и повышения latency в 4 раза. До 6 процентов от номинала, и в 4 раза, Карл!

Можно ли лучше? Можно! Тут то как раз и стоило бы обратиться к опыту коллег из NOC. Инкапсуляция трафика, отказоустойчивость точек его приема и обновление таблиц маршрутизации, это даже на слух не очень современная задача, и в ядре уже давно включены протоколы и механизмы, позволяющие делать это оптимальнее, чем поднимать из ядра в юзерспейс, принимать решение, заталкивать обратно в ядро, передавая дальше, по цепочке. Как раз flannel, о котором мы периодически упоминаем, и который уже включен в Fedora, может работать в т.ч. и на уровне ядра. Каковы же его показатели в сравнении с Weave и нативной сетью?

Name TCP BW (MB/s) TCP Lat (µs) BW % Lat %
Native 116 91.8 100.00 100.00
Weave 6.91 372 5.96 405.23
Flannel UDP 23 164 19.83 178.65
Flannel VXLan 112 129 96.55 140.52


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

Особо отметим, что тема SDN потеряла тэг "дивная зверушка", и переходит в раздел "надо попробовать". Мы некоторое время назад видели, как один из первых энтузиастов SDN в России был поставлен в тупик вопросом "кому это надо?" на одном из столичных мероприятий. Теперь, что уже понятно, такого не будет. Как мы видим, даже управляя трафиком из userspace можно получить приличную производительность, и некоторое падение показателей выглядит вполне допустимым, учитывая то, какие возможности открываются.

Основным открытым вариантом SDN пока является OpenDaylight. Недавно про него хорошую обзорную статью написали в Mirantis. Проект уже довольно серьезный, что немного пугает проприетарных вендоров, некоторые из них (VMware и Juniper - опять VMware, да что это с ними такое?) снижают степень вовлеченности в проект. Зря, кстати.

Проблема с открытыми SDN-системами ровно одна - законченных продуктов не было. До сих пор не было. Первого апреля был интересный анонс - CloudRouter, специализированный Linux-дистрибутив для создания роутеров для облачных систем. Среди участников есть дружественная нам Cloudius Systems, уже известные вам разработчики OSv и Seastar, и компания нашего соотечественника Игоря Сысоева, Nginx. Проект базируется на Fedora. Учитывая, что параллельно вовсю разрабатывается открытое аппаратное решение для роутеров уровня дата-центра, не стоило бы проприетарным вендорам отворачиваться от OpenDaylight. А ведь открытые SDN уже рассматриваются, как кандидаты для модернизации беспроводных сетей.

Docker, упорно пытающийся вылезти за пределы "запустить три версии руби одновременно", возможно переживает сильнейший удар. Три больших игрока объединились против него. На недавно прошедшем CoreOS Fest Google, Red Hat, и VMware официально поддержали стандарт App Container в своих продуктах. Этот стандарт уже поддерживается в собственном продукте CoreOS, Rocket, а теперь будет поддерживаться и другими компаниями и коммьюнити.

Архитектурно, повторимся, Docker ничем похвалиться не может - это еще один из продуктов, чья популярность возникла впопреки. Это вас не должно удивлять - дело в том, что зачастую делать правильно сложнее, чем неправильно. Да, если делаешь не по инструкции, то результат может быть плохой. А что если он будет хороший? О плохих историях почти никто не рассказывает (что рассказывать-то? сам дурак, сделал неправильно), да и вообще, плохое возникает реже, чем хорошее. Вот по блогам и форумам кочуют прекраснодушные рассказчики с их "отключил SELinux, и ничего!", "поставил венду, и не ослеп", "не учил математику, и не дурее других".

И до Docker были контейнеры (LXC, Parallels, и т.п.), но его разработчики сделали одно простое, но умное решение - ставка на начинающих, и поддержка популярного у них дистрибутива, одновременно предложив рабочее решение, обходящее все его недостатки. Тем не менее, остались открытыми вопросы безопасности, управления сетью (хотя в последнее время управление сетью в Docker начало улучшаться, как благодаря работе независимых разработчиков, так и благодаря усилиям их команды), зависимостей между процессами (а зависимости никуда не делись, как ни радуйся тому, что можно "запустить три версии руби одновременно"), управление хранилищем, декомпозиция толстого бинарника на работающие независимо компоненты (как это было сделано в systemd). Разумеется, со временем, у Docker будет решение всех этих и прочих проблем, но нашими друзьями из CoreOS, как нам кажется, было предложено архитектурно гораздо более правильное решение. Которое, теперь, еще и будет стандартизировано.

Стандартизация App Container, и управление оргвопросами коммьюнити будет осуществляться на демократической модели, с помощью выбираемых по совокупности заслуг участниками (как это делается почти везде в успешных OpenSource-проектах). Пока проектом управляют пятеро человек - Charles Aylward из Twitter, Vincent Batts из Red Hat, Tim Hockin из Google, и Brandon Philips и Jonathan Boulle из CoreOS.

Интересно, что стандарт уже поддерживается и на FreeBSD, в продукте Jetpack.


Может уже пора сбегать?

Страницы