По виртуализации прорывных новостей пока нет. Не то, чтобы тема потеряла актуальность, просто сейчас гораздо интересней тематика контейнеров и объединения виртуальных систем и контейнеров в облака, зачастую гибридные до крайней степени причудливости. Вот поэтому лишь такие новости и поступают.

Сейчас использование контейнеров активно расширяется на все возможные области задач, тестируя тем самым реалистичные границы применения. Например, проект GNOME предлагает запускать в контейнерах графические приложения. Это потребует полного перехода на Wayland, systemd и kdbus, но это совсем другая история. Коллеги-аналитики уже обсуждают на OpenNET.ru.


Анонимные аналитики негативно оценивают грядущие улучшения в systemd/Linux платформе

В облачных системах есть две важные темы среди всех прочих - связность систем (виртуализация сети с помощью SDN, распределенные хранилища данных и шины данных), и репликация (как систем, так и данных). Эти темы связаны настолько, что решение различных задач в этой предметной области часто производится одним и тем же инструментарием. Например, для виртуализации сети сейчас можно использовать т.н. сетевые контроллеры, например flannel, о котором мы вскользь упоминали или Weave, о котором мы тоже упоминали. В ходу, конечно, и более сложные решения SDN. Из этих двух, проекту flannel пока везет больше, и он уже включен в Fedora - можете пробовать, если не боитесь ряда детских болезней. Если же не боитесь, то наш коллега, Scott Collier, написал короткую хаутушку, как быстро развернуть сетку для Docker на базе flannel на нескольких машинках. К сожалению, дефолтная конфигурация flannel пока неоптимальная даже для Docker-систем, не говоря уж о нестандартных решениях, и для реальных решений вам придется ее поменять. Мы работаем над более общим и менее завязанным на какие-то специфические случаи решением, и просим вас сообщать про ошибки и пожелания в нашу багзиллу. Устоявшихся сценариев использования пока мало, и даже инженеры CoreOS и Red Hat пока не владеют достаточным объемом информации про возможные варианты использования.

Вышеупомянутый flannel использует etcd для хранения и репликации настроек, который готовится к выходу версии 2.0. Мы планируем обновить его до последней альфа-версии, и это возможно вызовет регрессии, т.к. в этой версии изменены некоторые умолчальные параметры и изменено то, как бутстрапится кластер etcd. Опять же, тема очень новая, и просто нет достаточного количества "use case", чтоб все проверить - без вас тут никак.

Возможности etcd гораздо выше, чем репликация настроек. Будучи просто системой хранения структурированных данных он годится в т.ч. и для задачи service discovery. Тут напомним про часто отключаемый неосведомленными пользователями Avahi, который можно также использовать в облаках, если уметь его готовить. Мы уже обращали ваше внимание на далеко не полный список облачных средств для service discovery, но вариантов решения с тех пор еще прибавилось. Например, недавно появился еще один проект от Mesosphere, известных вам по участию в проекте Kubernetes, вместе с Google, Red Hat, CoreOS и т.п. Они предложили облачный сервис DNS - mesos-dns, само собой написанный на Golang. Предлагается запустить его как основной DNS-сервер, который предоставит доменную зону .mesos (можно настроить). В этой зоне появятся доменные имена, соответствующие запущенным в кластере сервисам. Решение довольно интересное, т.к. он прячет от приложений изнанку системы, и позволяет обходиться без работы с API систем service discovery. API для DNS, это базовый функционал любого языка программирования, и это сильно упростит вещи (ценой усложнения настройки самой системы в целом, конечно).

Если по service discovery вариантов полно, то по шинам данных, которые и обеспечивают управление системой, пока довольно скучное однообразие. Либо строятся облачные системы без общей шины данных, как это делается в проекте CoreOS, либо, как в случае OpenStack, используется вариант AMQP. Конечно, сейчас в рамках очередного уровня абстракций OpenStack Oslo производится работа по реализации ZeroMQ-бэкенда, но по умолчанию используется RabbitMQ, написанный на Erlang нашими друзьями из одноименной компании. James Page, техлид Canonical, сообщил результаты тестирования бэкенда RabbitMQ против ZeroMQ - результаты пока не в пользу ZeroMQ. Тут, кстати, у Red Hat серьезный просчет. Дело в том, что у них был свой AMQP-вариант - Qpid, и они планировали использовать именно его, а не RabbitMQ. Хоть Qpid и быстрее на ряде синтетических тестов, но коммьюнити выбрало RabbitMQ, и им приходится нагонять. У них в штате нет специалистов по нему, а мультиинструменталист Rich WM Jones занят другими делами. К счастью в Red Hat был принят ряд решений, и тут ситуация, по агентурным данным, скоро переменится - новости скоро будут!

Сложность облачных систем в целом продолжает повышаться. Разработчики громоздят все большие уровни абстракций, виртуализируя все больше и больше подсистем. Это не только упрощает создание сервисов, но и, к сожалению, повышает хрупкость и понижает "поддерживаемость" облачных систем в целом. Первоначальный энтузиазм, вызванный продолжающимся упрощением развертывания и управления облаков благодаря появлению проектов типа Fuel от Mirantis и Juju от Canonical, сменился осознанием того, что сложность в основном просто перетекла с уровня отдельного изолированного сервиса на уровень всей облачной системы. Скорость разработки приводит к тому, что бэкенды к разным уровням абстракций сильно расползаются по уровню качества - это, разумеется, не проблема, если под рукой есть коллектив разработчиков Red Hat, HP или Mirantis. А вот маленькие коллективы начали чувствовать свою беспомощность перед нависающей тучей подсистем в OpenStack, и отказываться от OpenStack в пользу нестандартных решений, например на базе инструментария CoreOS. Вероятно, мы услышим еще о подобных историях в ближайшее время.

Одним из таких инструментов от проекта CoreOS является fleet, супервизор задач для кластера, разработанный на базе etcd и systemd. Вы уже могли о нем слышать. К сожалению, пока его в репозитории Fedora нет, но мы работаем над этим. Написан fleet, разумеется, на Golang.

Вообще, Golang, при всех его недостатках, становится стандартом. Просто те альтернативы, которые ему есть, не очень удобны. Не, ну а как? Rust, как оказалось, даже и собрать сложно, не то, что писать на нем (там вообще есть хоть какая то система CI?). Haskell настолько непрост, что до сих пор на нем написали лишь компилятор Нaskell и утилиты для разработки компилятора Haskell. На судьбе Ocaml трагическим образом сказалась чудовищная близорукость основного архитектора системы, который всерьез считал, что многопроцессорные системы не будут популярны. Ну а про остальные варианты даже упоминать не стоит. Поэтому, чтоб произвести впечатление на первокурсниц, изучайте Haskell. Чтоб попасть в Mozilla Foundation, попробуйте собрать Rust и начать на нем писать (и переписывать каждую неделю). Чтоб поговорить по душам с Rich WM Jones начните писать на Ocaml. А чтоб упросить себе жизнь DevOps, то ваш выбор - Golang. Для московских пользователей этого языка у нас есть две новости - хорошая и не очень. Хорошая это то, что в ближайшее время выйдет анонс очередного Moscow Golang User Meetup. Плохая - это будет мемориальной встречей, посвященной эвакуации офиса разработки Google из России.

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