Platform as a Service (PaaS) — это не самая тривиальная вещь для создания, развертывания и поддержки: для начала, приходится проделать немалую работу для управления всеми сервисами изнутри, затем предстоит продумать и реализовать хороший интерфейс, и, в конце-концов, сервис нужно продать и умело его поддерживать. Не удивительно, что инвестиции для создания таких сервисов, могут позволить себе только несколько зажиточных игроков на IT-рынке.Поэтому было вдвойне интересно наблюдать, как VMware разворачивают сервис CloudFoundry, да еще и с открытым кодом (честно, вот github аккаунт)! Полноценная PaaS, которую они так же предлагают использовать как хостинг, доступна так же каждому, для запуска в собственной компании или датацентре — теперь вы можете запустить «мини Heroku», или «облако EngineYard» на собственных серверах! Но в сторону маркетинг, гораздо интереснее взглянуть под капот этого проекта, ведь он полностью организован на Ruby.
CloudFoundry: Rails, Sinatra, EventMachine
CloudFoundry предоставляет возможность для запуска нескольких платформ и фреймворков (Rails, Sinatra, Grails, node.js), а также поддерживает и столь необходимые вспомогательные сервисы (MySQL, Redis, RabbitMQ). Другими словами, система является модульной и очень легко масштабируемой. У сервиса есть целый канал на youtube, где можно подробно познакомится инфраструктурой.
Rails 3 (CloudController) дирижирует этим оркестром из модулей и хранит информацию обо всех пользователях, используемых сервисах и приложениях, а так же контролирует предоставляемые услуги. При запуске консоли (CLI — command line client) на локальной машине, вы действительно обращаетесь к CloudController. Интересно, что само rails-приложение является надстройкой над веб-сервером Thin, использует Ruby 1.9 и асинхронные драйвера БД — иными словами, используются асинхронные рельсы, которые решают многие проблемы в производительности.Помогает рельсам Health Manager — демон, который импортирует все ActiveRecord модели из CloudController'a и регулярно сравнивает состояние базы данных с тем, что имеют остальные демоны. Если обнаруживается расхождение, health manager уведомляет CloudController — простой и эффективный способ сохранить распределенную информацию в актуальном состоянии.
Остальная часть CloudFoundry работает по определенному шаблону: каждый сервис — это ruby демон, который посылает запросы CloudController'y при первой загрузке, во время отправки JSON отчета о состоянии своего статуса, а так же при некоторых других действиях. Не удивительно, что за всем этим стоит EventMachine и, следовательно, используется Thin и rack endpoints.
map '/healthz' do
run lambda { |env| [200, RACK_TEXT_HDR, Component.updated_healthz] }
end
Маршрутизатор отвечает за разбор входящих запросов и перенаправление трафика на одно из приложений (droplets). Чтобы осуществлять это, применяется карта зарегестрированных URL'ов и соответствующих им приложений. Когда создается новый сервер с приложением, карта маршрутизатора обновляется, и трафик перенаправляется в соответствии с обновленными маршрутами. Для небольшого количества приложений достаточно одного маршрутизатора. Если же их много, то трафик распределяется между несколькими роутерами.
DEA (Droplet Execution Agent) — управляющий процессом создания новых приложений. При получении соответствующей команды от CloudController'a, запускает необходимые скрипты и команды и запускает сам сервер.
Есть еще и служба, контролирующая доступ серверов к таким ресурсам, как MySQL, Redis, RabbitMQ, и т.д. Архитектура ее опять очень проста: демон-шлюз на ruby прослушивает входящие запросы и вызывает необходимые команды «старт»/«стоп» и добавление/удаление пользовательских команд. Добавить новый или кастомный сервис так же просто, как имплементировать класс Provisioner.
Соединение всех кусочков и NATS
Каждый ruby демон, описанный выше, следует определенному шаблону: при загрузке посылает запрос CloudController'у и сообщает информацию о своем состоянии и статусе, посредством HTTP endpoints. Но как они работают друг с другом? Естественно, с помощью еще одной службы на ruby. Через NATS — легковесную систему публикации и подписки на сообщения, объединяющую все воедино. Каждый ruby демон при первом запустке подключается к NATS и подписывается на необходимые для него сообщения, а так же начинает публиковать собственные уведомления. Эта архитектура позволяет CloudFoundry легко добавлять и удалять новые маршрутизаторы, DEA агенты, контроллеры служб и так далее. Ничто не мешает выполнению всех действий, описанных выше, на одной машине, или на кластере в собственном ЦОД.
Итак, распределенные системы на Ruby возможны?
Конечно, да! Строительство распределенной системы с таким количеством масштабируемых частиц, как CloudFoundry — это настоящий подвиг. Выбрав ruby, как основной язык, компания VMware выразила ему вотум доверия по части таких нетривиальных систем. Под капотом этой огромной махины можно найти и rails, и sinatra, и rack, и много кода EventMachine. Так что всем рубистам я определенно советую почитать исходники на досуге.
