Red Hat запартнерилась с Black Duck Software (это те, кто сейчас владеет OpenHUB.net), чтобы улучшить безопасность контейнеров.

Как вы знаете, контейнер, это просто обычный процесс (или совокупность процессов), к которым присоединено некоторое количество меток (namespaces, cgroups, capabilities, SELinux, и прочие возможные метки), по которым операционная система определяет то, что из ресурсов доступно процессу. Понятно, что безопасность такой вещи гораздо ниже, чем у виртуалки, и наши коллеги, например, Dan Walsh, об это регулярно рассказывают. К сожалению, из-за начальной ориентации контейнеров, как "замена виртуалки, только быстрее", народ не обращает внимание на это. Вторая проблема, это то, что контейнеры рекламируются, как "средство от зависимостей". Мы уже обладаем неким аппаратом проверки того, что в пакетах, и того, как их распространять, а вот с контейнерами все гораздо хуже. Т.к. контейнеры постепенно реализовывают функционал пакетных менеджеров, то теперь возникла потребность в проверке содержимого. Вот ради этого Red Hat и объединяет усилия с Black Duck. Напомним наше предсказание - скоро в контейнеры добавят зависимости.

Откуда вообще в Docker такое количество архитектурных проблем? Ну, мы уже отвечали - из-за того, что его разрабатывали для недалеких и нетребовательных пользователей Ubuntu, где и пакетный менеджер малофункциональный, и с безопасностью плохо. Недавно наш коллега, инженер Rackspace, Major Hayden, которого вы можете уже знать, как человека с самым прекрасным в мире резюме, решил разобраться, а как в Ubuntu с промышленно принятыми стандартами безопасности? Ну, понятно, что SELinux там нет, т.е. дистрибутив отстает лет на 10 от нас, а что с остальным? Оказалось, что все очень плохо, и с т.з. безопасности лучше даже Arch. Вероятно именно поэтому, из-за отсутствия хоть какого то бы ни было соответствия промышленным стандартам, те большие разработчики OpenStack, базирующиеся на Ubuntu (или даже Debian), проигрывают контракт за контрактом в пользу решений на базе RHEL. Ну что сказать, свою голову не приставишь - подолбятся еще в стену и начнут задумываться. К счастью, HP уже взял под свою опеку Debian, и вполне вероятно, что мы увидим улучшения в нем, связанные с безопасностью. А оттуда они перейдут в Ubuntu, где вообще уже ничего своего не делается.

Matthew Garrett, благополучно эвакуировавшийся из закрывшейся Nebula в CoreOS, продолжает работать над безопасностью (в свободное от радикального феминизма время). В CoreOS делают все правильно, и там за основной компонент безопасности взяли SELinux и функционал ядра. Конечно, народ осознает, что есть большой массив задач безопасности, который просто не решить с SELinux, и там предлагают уже известное и применяющееся в том же Google решение - контейнеры запускать в виртуалках. Это отчасти работает, конечно, но хочется-то на baremetal-машинах.

Напомню, что у нас есть видение того, какие есть проблемы с безопасностью в контейнерах, и то, как их надо решать. Это не значит, конечно, что решения у нас уже есть, а лишь то, что мы понимаем проблематику. Интересно, что постепенно разными организациями и компаниями поднимается одна важная проблема - управление пользователями (и трансляцией пользовательских числовых идентификаторов) в контейнерах. Т.к. UID 1001 в контейнере далеко не обязательно будет тождественнен UID 1001 на хостовой машине, или в другом контейнере, а еще он на хостовой машине выглядеть будет, как какой-нибудь UID 49512, то нужен пропатченный OpenLDAP необходима новая система для трансляции. Тут нужен старый-добрый OpenLDAP с парой патчей совершенно новый, современный механизм AAA. VMware разработала и открыла новый фреймворк - Lightwave, а вот ребята из CoreOS похоже не до конца поняли, какое сокровище у них в руках, когда анонсировали dex, OpenID провайдер. Представляете, как может быть инновационно - контейнеры с авторизацией в Twitter, Facebook, и Google+.

Ну, как бы, опа. Угадайте, на какие продукты?

Сообщают, что от VMware отказывается еще один известный заказчик - Apple. В пользу KVM, конечно. Нельзя не порадоваться за коллег, работающих над KVM - они создали первоклассный продукт, который запросто бьет коммерческие предложения. Напомним, недавно VMware уже тряхануло, когда PayPal официально подтвердил, что выкидывает их на мороз. Говорят, что Apple еще и к OpenStack присматривается.

Пытливый айтишник спросит, а зачем вообще всерьез базироваться на проприетарных, дорогих, и неудобных продуктах от престарелых динозавров (IBM, EMC, Cisco, VMware, Oracle и прочих)? Ну как зачем, а как же откат? На самом деле, есть интересный социальный момент. Если среди программистов выше всех котируются те, что сделали заметный вклад в разработку известных открытых продуктов, то, как считается, среди менеджеров круче те, которые управляли большим (в смысле затраченных денег) проектом. Проприетарные решения от умирающих динозавров ультрадорогие, поэтому они выгоднее для повышения крутизны управленца. За покупку в IBM еще никого не уволили, ведь так? Ну, народ похоже не только начал считать деньги, но и сравнивать возможности. Если дом большой (Apple, PayPal и т.п.), то на первое место выходит даже не фичастость, а расширяемость и масштабируемость (т.е. "клауд, клауд, клауд"). Тут старичкам показать тупо нечего. Все открытые решения лучше, и расширяемее.

Самое смешное знаете в чем? Они всерьез стали винить Сноудена. Нет уж! "Надо отвечать за свои поступки, ...а не сваливать вину на какого-то Карлсона с крыши".



Вообще, хорошая новость к недавнему выходу Qemu 2.4. Несмотря на очевидную и близкую победу, народ останавливаться не собирается, и работает дальше. Например, помните печальную историю патчсета RT-Linux? Ну там все закончилось хорошо, и у Томаса теперь есть стабильное финансирование. А вот теперь его работа стала основой для проекта Realtime KVM, о котором есть хорошая статья на LWN. Обязательно почитайте, над чем ведутся работы.

Компания, которую основали наши бывшие коллеги, становится частью Red Hat! Скоро будет официальный анонс.

Red Hat стал платиновым корпоративным спонсором коммьюнити Node.js, присоединившись к хорошему коллективу из Microsoft, IBM, PayPal и прочих. Теперь под контроль наших коллег попадает и одна из самых популярных JS-платформ. Для стандартизации, это лишь в плюс. Ну, наверное, это связано с покупкой FeedHenry.

Вообще, насчет Microsoft как-то неудобно получается. Недавно наши коллеги запустили процесс удаления предложенных Microsoft расширений для стандарта C11 (об этом уже писали на OpenNET.ru), а тут придется с ними сотрудничать. Но, кстати, удалять собрались уже четвертый неправильный способ работы со строками, так что его никому особо жалко не будет.

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

Продолжается эпопея с поддержкой архитектуры POWER8 в Ocaml. В апстриме был бэкенд для 32-битного PowerPC, а вот для 64-битных процессоров всегда была какая-то проблема (ну с этой архитектурой из-за снобизма их вендоров по-другому и быть не могло). Наш коллега, David Woodhouse давным давно написал бэкенд для ppc64, который, к сожалению, выкинули, т.к. железо от Apple медленно умирало (в смысле физически), затем Sony залочило Playstation 3, а другого доступного железа в продаже и не было никогда (см. "снобизм вендоров"). В прошлом году появился новый (третий) бэкенд для ppc64le от IBM, но тоже в формате out-of-tree патчей. И вот, наконец-то, базируясь на разработках Red Hat и IBM в апстриме написали свой, четвертый бэкенд для архитектур ppc / ppc64 / ppc64le. Понятно, что унифицированный бэкенд гораздо лучше, чем разномастные сторонние патчи, поэтому наш коллега, Rich WM Jones, объявил, что Ocaml-пакеты в Fedora теперь будут собираться с помощью upstream-бэкенда.

Кстати, насчет доступных и надежных дистрибутивов для альтернативных платформ - CentOS уже появился для i686, и скоро появится для ppc64 / ppc64le. Работа по сборке CentOS под armv7hl также почти закончена.

Сформирована программа первого systemd.conf 2015. Подтянулись и спонсоры, так что будет интересно.

Интересно, что еще продолжают биться об стену создатели альтернативных init-систем. Совсем недавно появилась еще пара - beginning и govisor (про него даже написали на OpenNET.ru). Одно время программисты писали десятки если не сотни window-менеджеров, потом медиаплейеры, а вот теперь стали писать init-системы. Ну что сказать, уровень растет!

С ростом интереса к базовым компонентам, появился спрос на исторические материалы. Мы неоднократно говорили, что SysVinit был признан устаревшим 10-15 лет назад, вот, например, обратите внимание на инициативу GNOME-разработчика Seth Nickell (опять эти гномеры!). В этой связи интересно посмотреть на хронологию событий, приведших к появлению нынешнего лидера.

Вышедший не так давно systemd 226 (новость на OpenNET.ru) интересен тем, что он не очень интересен. Кроме изменений в systemd-networkd там унифицирована работа демона D-Bus и современного kdbus. Требуется самый последний dbus 1.10, которого нет даже в Fedora 22, и мы видим четкий эволюционный путь - через работу с dbus 1.10 к kdbus в следующем релизе (получается, что уже 24).

К самому D-Bus стали присматриваться пристальнее. Как раз, когда решили менять - вот вовремя то! Ну, конечно, лучше поздно, чем никогда. Так или иначе, народ уже увидел, что в dbus содержится пересекающаяся функциональность с init-системой, и это плохо. Где же вы раньше были?

К сожалению, вновь появившиеся тесты производительности dbus vs. sd-bus vs. kdbus + sd-bus противоречат результатам синтетических тестов чистого kdbus полуторагодичной давности. Впечатление такое, что Poettering и его команда что-то такое в sd-bus наворотили, и там теперь серьезный затык. Пока переходить на kdbus пожалуй не стоит. Будем надеяться, что это, все-таки, проблема в sd-bus, и инженеры Google не столкнутся с такими проблемами, прежде чем начнут перевод Android на kdbus.

И из других новостей - вышел PulseAudio 7.0. Теперь с socket activation по TCP!

Наши друзья из OSv представили еще один проект в букете своих технологий - ScyllaDB. Это реализация Cassandra на языке C++, что традиционно для OSv. Как говорят авторы, получилось в 10 раз быстрее, и им удалось добиться миллиона транзакций в секунду на одной ноде.

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


По нашему мнению, различий от оригинальной Cassandra не так и много

Известный хулиган и матершинник, Linus Torvalds, одобрил включение в ядро пары патчей, благодаря которым для сборки ядра с цифровыми подписями модулей теперь потребуется openssl-devel. Т.к. Linus использует Fedora, то он проверял лишь с openssl-devel, а в Debian и Ubuntu надо использовать libssl-dev или что-то типа того. Конечно, туда современные ядра добавят с традиционной задержкой, так что волноваться не о чем.

Наше дружное сообщество поздравляет учащихся с началом учебного года! Помните, что ученье - свет, а неученье - чуть свет, на работу.

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

Если честно, немного страшновато - откроешь какой-нибудь ZDNet или TheRegister, и там в каждой статье контейнер на контейнере, и экcперты, прославляющие этот величайший технологический прорыв Человечества со времен электричества. Мы-то знаем, что "контейнер", это обычный процесс, к которому в таблице процессов добавлены метки "namespace" и "control groups", которые учитываются при его работе, но люди, принимающие решения, похоже этого не знают, и всерьез сравнивают с виртуализацией и кластерами "дооблачных" времен. Есть растущее ощущение, что ушедший в ультразвук энтузиазм по поводу контейнеров обернется ужасающим разочарованием. Но пока этого не произошло, давайте наслаждаться открывшимися возможностями.

Так вот, VMware теперь рекламирует не виртуализацию, а контейнеры. Нам это нравится, т.к. это благоприятно сказывается на блудном сыне VMware, компании Pivotal, которая и помогает VMware создавать новую платформу (благо у них уже есть открытая платформа - Cloud Foundry). Для нас Pivotal, конечно, это прежде всего люди, разрабатывающие нашу любимую шину сообщений - RabbitMQ. На базе нее построен обмен сообщениями в OpenStack, и хотя есть попытки использовать конкурирующие AMQP-решения (Qpid), RabbitMQ с места просто так не сдвинуть. Он написан на Erlang, что заведомо повышает качество кода и надежность системы. Нужно отметить, что рядом лиц затрачиваются огромные усилия по включению варианта на базе ZeroMQ, но есть основания предполагать, что это не взлетит никогда. Если кто не в курсе, то у ZeroMQ помимо ряда социально-организационных проблем, есть серьезные недостатки и ограничения, которые следует учитывать. Наши друзья и коллеги, в т.ч. и участники Moscow Erlang User Group, как-то скинулись и переписали ряд особо гадких особенностей ZeroMQ. Получилось внушительно.


Коллеги узнали, что ты решил использовать ZeroMQ


Конечно, с RabbitMQ есть нюансы использования, все-таки CAP-теорему так просто не объехать, но все ведущие компании-разработчики OpenStack сейчас нанимают Erlang-разработчиков, и можно ожидать, что в ближайшее время ситуация улучшится. Сейчас RabbitMQ рассматривается ими как загадочная шкатулка с музыкой, и даже в Red Hat проблемы с ним решаются извне, не трогая код продукта, а привычно перенастраивая окружение от ядра до Glibc.

Интересно, что VMware, похоже понимает, что главное в "контейнерах", это не сами "контейнеры", а их обвязка - средства управления, живой миграции, failover, развертывание, сетевые возможности (SDN) и многое другое. Недаром она привлекает других именно этими возможностями своих проприетарных продуктов. Тем не менее, не только они тут играются. Mirantis в последнее время дружит со всеми - Mirantis и CoreOS, Mirantis и Intel, и даже Mirantis и Goldman Sachs (Голдманы, как и все финансисты, очень любят открытое, даже оборудование). Некоторые даже всерьез используют термин OpenStack Wars (как Unix Wars, только про OpenStack), но в мире OSS воевать непросто да и бессмысленно - лучше сотрудничать.

Страницы