Некоторое время назад мы подробно обсудили
об одной из базовых облачных технологий Яндекса — Elliptics. Сегодня пришло время поговорить о другом — том, под которым работают «эльфы» и который делает мечту об их облаке немного ближе к реальности.
Мы поговорим о кокаине.
Cocaine (Configurable Omnipotent Custom Applications Integrated Network Engine) — это система PaaS (платформа как услуга) с открытым исходным кодом, которая по сути представляет собой движок приложений и позволяет создавать собственные приложения облачного хостинга, такие как Google AppEngine, OpenShift, CloudFoundry или Heroku.
Кокаин" alt="Облачная платформа Яндекс.
Всем известно, что облака способны решить все инфраструктурные проблемы, превратить затраты в прибыль и навсегда наполнить вашу жизнь бесконечной радостью и счастьем.
Единственным препятствием на пути к этим целям являются, по сути, облака.
,
,
? Что угодно как услуга? Какой загадочный набор букв нужно выбрать, чтобы все наконец стало хорошо?
Мы потратили много времени на изучение этих вопросов, отбирая лучшие, на наш взгляд, идеи и концепции, чтобы построить ту облачную платформу, которую хотелось бы сразу установить, настроить и успешно использовать.
История
История рождения этой технологии тесно связана с Heroku. Давным-давно, когда облачные технологии не были так популярны, но уже существовал Heroku, им заинтересовался основатель нашего проекта Андрей Сибирев.
Кокаин" alt="Облачная платформа Яндекс.
Кокаин">
Heroku в то время представлял собой движок приложений, поддерживавший только Ruby, но сама идея была революционной.
Подумайте только: вы могли бы написать собственное железнодорожное приложение, загрузить его в облако и вообще не думать о проблемах инфраструктуры.
Нужна база данных? Нет проблем – есть дополнения! Вытаскивать логи? Никаких проблем снова! Проблемы с балансировкой нагрузки также были волшебным образом решены.
Сайт молодой и развивающийся? Хорошо, у него есть ресурсы.
Сайт уже популярен? Ну а облако поможет ему «набухнуть» под нагрузкой и выжить.
Кроме того, быстрое развертывание с помощью git научило меня ценить красоту с самого раннего возраста.
Звучит круто.
По крайней мере, так позиционировала себя Heroku. В действительности все было, конечно, темнее.
У них была отличная идея, была реализация, но почти нигде не было описано, как это вообще работает. Как известно, если хочешь понять что-то неизведанное, новое, поставь себя на место разработчика.
Как бы вы написали, учитывая увиденные вами плюсы и минусы? Так был запущен проект движка облачных приложений с открытым исходным кодом.
Забегая вперед, скажу, что, судя по всему, зарубежные разработчики руководствовались той же логикой, что дало толчок развитию еще нескольких подобных продуктов: OpenShift и CloudFoundry. О них мы поговорим чуть позже.
Изначально Cocaine был гаражным проектом просто для развлечения, но все изменилось, когда у Яндекса возникла потребность в какой-то раздутой платформе приложений, способной выдерживать нагрузку в «может 10, а может и 100 000 RPS» для внутренних целей.
Тем временем на подходе был Ya.Browser с такими же потребностями, и стало понятно, что проекту пора выбираться из гаража.
Оставим на время эту историю в стороне и окунемся в мир сухой статистики и неоспоримых утверждений.
Где Яндекс использует кокаин
Яндекс.Браузер — весь бэкенд браузера работает через Кокаин.
Например, «Умная линия», «Быстрые ссылки», «Любимые сайты».
Внутренняя инфраструктура Яндекса.
Поддерживаемые платформы
На данный момент Cocaine можно развернуть из пакетов в следующих дистрибутивах Linux:- Ubuntu 12.04 (Precision Pangolin) и старше
- RHEL 6 и производные.
Из исходного кода Cocaine можно скомпилировать практически на любой *nix-системе, имеющей Boost 1.46+ и компиляторе с
Стандарт уровня GCC 4.4 (то есть практически нет).
В качестве бонуса Cocaine успешно собирается из исходного кода на Mac OS X. Для поддержки технологии Docker (обсуждается позже) требуется ядро Linux версии не ниже 3.8.
Почему так кокаин?
Давайте подробнее рассмотрим, чем «Кокаин» отличается от своих основных конкурентов.Начнем с Хероку.
Прежде всего, Heroku не является технологией с открытым исходным кодом и собственной ценовой политикой, что может отпугнуть некоторых клиентов.
Но за счет явной монетизации Heroku имеет более развитую поддержку и имеет (теперь) хорошую документацию с картинками.
Удобнейшая система развертывания приложений, основанная на git, заставляет с самого начала наводить порядок в коде и дает возможность отката в случае факапа.
Множество дополнений позволяют легко удовлетворить потребности вашего приложения в различных базах данных, кэшировании, организации очередей, синхронизации, ведении журналов и многом другом.
Сами приложения при запуске полностью изолируются друг от друга в процессах, называемых dynos, которые распределяются по специальной dyno-сетке, состоящей из нескольких серверов.
Dynos запускаются по мере необходимости в зависимости от нагрузки и убиваются при отсутствии нагрузки — так Heroku балансирует нагрузку и обеспечивает отказоустойчивость.
Несмотря на то, что изначально Heroku поддерживал только Ruby, теперь Heroku предоставляет возможность писать приложения на таких языках, как Java, Closure, Node.js, Scala, Python и (внезапно) PHP.
Разработка CloudFoundry и OpenShift началась почти одновременно с Cocaine. Оба являются проектами с открытым исходным кодом и имеют мощную поддержку со стороны крупных компаний — VMware и RedHat соответственно.
CloudFoundry уже пережил одно возрождение.
Однако языковая поддержка ограничена Java, Scala, Groovy, Ruby и JavaScript. OpenShift с этим справляется лучше — он поддерживает дополнительно Python и Perl, а поддержку нужных языков можно создать самостоятельно.
К сожалению, приложения могут общаться друг с другом только через http, что несколько ограничивает возможности Облака.
При этом Кокаин выгодно отличается от них:
- наличие адаптеров для различных языков (фреймворков), что значительно упрощает работу с Облаком;
- возможность приложений общаться друг с другом не только через http, что, например, дает возможность построить собственную платформу облачных вычислений;
- сильная поддержка изоляции приложений — технологию Docker, кроме нас, официально поддерживает только OpenShift.
Краткий принцип работы
Теперь давайте посмотрим, как на самом деле работает наше облако, попутно обсудив причины, повлиявшие на выбор того или иного решения.Сформулируем следующее неоспоримое утверждение: облака созданы для решения инфраструктурных задач.
Одной из таких задач является обеспечение отказоустойчивости.
Вряд ли кого-то сильно впечатлит облачная платформа, работающая только на одной машине.
В этом случае облако погибает вместе с машиной.
Облако Cocaine состоит из одной или нескольких независимых машин, на которых установлен сервер «cocaine-runtime».
По сути, это все, что нужно для минимального функционирования платформы.
Кокаин" alt="Облачная платформа Яндекс.
Кокаин">
Мы решили не идти по пути CloudFoundry и создать отдельную программу для каждой логической части облака.
Так, например, то, что в других облаках называется HealthManager — мониторинг жизни запущенных приложений, — мы объединили в одну сущность.
Такое решение, с одной стороны, упрощает администрирование узла и уменьшает количество точек отказа, но с другой стороны, если кокаин-рантайм «отказывает», то весь узел на некоторое время удаляется из списка.
Но проверка временем и нагрузками показала, что выбор такого решения оказался удачным.
Представьте, что у вас есть дюжина машин, каждая из которых работает в режиме кокаина.
Но эти машины ничего не знают друг о друге.
При рассмотрении вариантов выбора схемы построения топологии облака рассматривались два варианта: все обо всех знают и немногие знают обо всех.
В первом случае идентичность всех узлов будет гарантирована: если какой-то узел умрет, ничего существенного не изменится.
Но при этом происходит путаница логики, ведь здесь по сути задействованы две сущности: первая — агрегация узлов и управление ими; второй — управление вашим узлом.
Во втором случае логика узлов агрегации кокаин-рантайма полностью отделена от остальных, но этот узел нужно будет настроить особым образом.
В конечном итоге был выбран второй вариант. Пользователи ничего не знают о местонахождении сервисов или приложений, к которым они обращаются — известен только адрес узла агрегации и название приложения.
Узел сам выбирает оптимальную машину для запроса, на которой он выполняется.
Механизм облачных приложений не назывался бы так, если бы он не мог запускать приложения.
На самом деле, время выполнения кокаина не заботится о том, что оно запускает. Единственное требование — файл должен быть исполняемым.
Другое дело, что это приложение будет убито практически сразу, потому что.
не сможет ответить на простое сообщение о рукопожатии и в принципе нет общих средств мониторинга приложения извне.
Если работает, то это не значит, что он не завис, например.
И тут мы вплотную подходим к теме мониторинга жизни приложений (или воркеров).
Запущенное приложение нужно как-то контролировать.
Фактически требуется минимум: приложение должно время от времени уведомлять сервер о том, что оно активно, с помощью команд пульса и корректно завершать работу с помощью команды завершения.
Если приложение слишком долго не отвечает, то оно считается мертвым и ему отправляется сигнал SIGKILL для его завершения.
Другими словами, работник должен реализовать особую, простую
.
Для удобства разработки приложений сделаны адаптеры для различных языков, которые мы называем рамки .
Пять минут истории
Фреймворки — это специальный API, который реализует наиболее удобный для конкретного языка способ взаимодействия с облаком.Например, под фреймворком скрыта реализация внутреннего протокола, что позволяет очень легко вызывать облачный сервис и работать с ним.
Также были реализованы инструменты для упрощения работы с асинхронными вызовами.
На данный момент уже реализована поддержка:
- С++
- Джава
- Питон
- Рубин
- Node.js
- Идти
интерфейс и через
.
Их реализация во многом очень похожа на аналогичные инструменты от Heroku или CloudFoundry — приложения можно разворачивать, запускать, останавливать, управлять и настраивать, а также собирать статистику и просматривать логи.
Здесь действительно сложно придумать что-то новое, хотя инструменты Amazon EC2 по-прежнему являются для нас примером в плане простоты и удобства, мы стремимся к этому.
Архитектура
Давайте сделаем шаг назад и посмотрим на облачную инфраструктуру сверху.Что такое облако? Обычно существует несколько машин, которые предоставляют ресурсы.
Эти машины каким-то образом связаны в единое целое каким-то элементом управления.
Предоставляемые общие ресурсы используются для организации различных сервисов и пользовательских приложений.
Вам ничего не напоминает? Существует категория программного обеспечения, к которой относятся программы, управляющие инфраструктурой одного (обычно) компьютера и предоставляющие его ресурсы пользователю.
У них есть четкое разделение на модули, есть сущность управления и есть пользовательское пространство.
Речь идет, конечно, о операционные системы .
Мы подумали, а почему бы не сделать нечто подобное, но в случае с облачной инфраструктурой? Именно так устроен кокаин.
В центре всего находится ядро, включающее в себя основные иерархии.
услуги , водители И API .
Сервис — это, по сути, библиотека, написанная на C++, подключенная к ядру, которая предоставляет Облаку определенный сервис.
Сервисы запускаются одновременно с кокаин-рантаймом и живут в отдельном потоке в единственном экземпляре на протяжении всего времени его работы.
Кокаин" alt="Облачная платформа Яндекс.
Кокаин">
Основной услугой является обслуживание Узел , позволяющий контролировать запуск, остановку и работу Приложения .
Изначально запущенное приложение не имеет воркеров — экземпляров этого приложения — они начнут спавниться при увеличении нагрузки на приложение.
Каждое приложение имеет Двигатель , который отвечает за распределение очереди сообщений между работниками и клиентами, управление и балансировку их количества.
рабочие .
Услуга Локатор позволяет объединять независимые узлы в единый кластер, а также осуществлять поиск запрошенного клиентом приложения или услуги в Облаке.
Например, если какое-то приложение запрашивает сервис Logger, то именно Locator решает, какую конечную точку ему предоставить.
Наряду с конечной точкой также указывается таблица отправки методы обслуживания.
Кстати говоря: в отличие от механизма RPC
или
, мы решили избавиться от обязательного
(IDL) сервисы (и приложения).
Вместо этого мы загружаем таблицу методов с каждым разрешением, а затем фреймворки реализуют собственный способ работы с ней для каждого языка.
Все что для этого нужно – это всего лишь название запрашиваемого сервиса и, возможно, версия.
Получили ли мы от этого пользу? Определенно да! Устранив необходимость определения IDL для каждого приложения, мы значительно упростили их разработку для динамических языков, таких как Ruby или Python.
Если изменился API приложения, нет необходимости переписывать заглушки для всех фреймворков — в случае с динамически типизированными языками методы обычно создаются динамически.
Продолжим об услугах
Вряд ли найдется хоть одно облако без инструментов логирования — реализуем как сервис Регистратор , который представляет собой единую точку для транспортировки логов со всего узла.Наконец, сервис Хранилище — это абстрактный интерфейс для хранения чего угодно — например, самих приложений, манифестов, профилей и другой необходимой информации, включая сами приложения.
Архитектура службы открыта для расширения и аналогична модулям ядра Linux. Вы можете писать свои собственные сервисы, а также расширять существующую иерархию.
Кокаин" alt="Облачная платформа Яндекс.
Кокаин">
Они стоят особняком водители , целью которого является генерация событий, обрабатываемых облаком.
Например, таким событием может быть изменение файла или каталога, истечение времени ожидания или другое событие.
Можно (как вариант) написать драйвер для АЦП, который будет сбрасывать сигналы для обработки по мере их поступления.
В отличие от многих аналогичных PaaS, в которых приложения и сервисы могут взаимодействовать друг с другом только через HTTP, в Cocaine связь происходит через механизм RPC по бинарному протоколу, подобному HTTP/2.0. Это дает нам возможность, например, напрямую взаимодействовать между различными приложениями, используя возможности, предоставляемые фреймворками.
Вы можете прочитать об этом больше
.
Разумеется, сам HTTP-интерфейс никуда не делся.
Каждая платформа предоставляет собственные инструменты, которые упрощают разработку HTTP-приложений.
Например, в случае с Python существуют декораторы, похожие на колбы.
Извне к приложениям также можно получить доступ не только через HTTP-интерфейс (хотя такая возможность предусмотрена), но, например, через ZeroMQ или собственные расширения.
Масштабирование и изоляция
Давайте подробнее рассмотрим, как на самом деле реализовано распределение Облака и как оно пытается жить под нагрузкой.При запуске кластера отдельные узлы (машины, на которых работает среда выполнения кокаина) узнают друг о друге с помощью внутреннего сервиса.
Локатор , который регистрирует каждую машину в многоадресной группе, тем самым организуя связь между всеми узлами и отдельным узлом, настроенным для Металокатор , который является точкой входа в облако и выполняет базовую балансировку нагрузки.
Если на конкретной машине появится новое приложение или размножится существующее, металлокатор сразу узнает об этом и направит нагрузку на него.
Облако, используя вышеуказанное Двигатель также отслеживает очередь сообщений и контролирует загрузку.
При увеличении нагрузки на приложения платформа автоматически запустит необходимое количество экземпляров этого приложения, руководствуясь своими внутренними представлениями о нагрузке на узлы и наличии слотов на различных машинах.
В данной ситуации слоты означают некий единый ресурс машины.
Система создания и изоляции приложений вынесена в отдельную сущность, называемую Изолировать .
В стандартной конфигурации облако будет запускать новые экземпляры приложений с использованием обычных процессов.
Если поддержка Docker установлена в виде плагина, облако будет запускать новые приложения в отдельном изолированном контейнере.
Изоляция? Легко!
Docker — это технология с открытым исходным кодом, которая обеспечивает простой и эффективный способ создания легких, портативных и автономных контейнеров для любого приложения.После создания такой контейнер будет одинаково хорошо работать практически в любой среде: от ноутбуков разработчиков и тестировщиков до кластеров из тысяч серверов.
Это, например, позволяет изолировать приложения вместе с их бинарными зависимостями и больше не думать о том, что ваше приложение начнет вести себя в облаке по-разному из-за разных версий библиотек или вообще не будет работать.
Технология Docker основана на обычных контейнерах Linux (LXC), которые обеспечивают возможность запуска приложения в изолированной среде за счет использования пространств имен и cgroups.
В отличие от полностью виртуализированных сред, таких как Xen или KVM, контейнеры используют общее ядро и не предоставляют возможности эмуляции устройств, но они не несут дополнительных затрат и запускаются практически мгновенно.
Помимо самой контейнеризации, Docker предоставляет инструменты, упрощающие настройку сети, распространение и развертывание образов приложений.
Одним из таких инструментов является создание образов приложений из нескольких независимых слоев.
При разработке приложений Cocaine с двоичными зависимостями (например, приложений C++ или Python) Docker может быть очень полезен для изоляции этих двоичных зависимостей.
Устойчивость к эрозии
Представьте, что вы создали приложение, загрузили его на сервер, настроили и предоставили самому себе.Через неделю вы решаете проверить, как оно работает, и с грустью обнаруживаете, что приложение давным-давно вылетело совсем по другим причинам:
- спонтанные обновления операционной системы или зависимых библиотек;
- диск, полный журналов;
- зависание или сбой самого приложения;
- проблемы с самим серверным оборудованием.
Кокаин"> Эрозия программного обеспечения
”.
Кокаин представляет собой устойчивую к эрозии технологию.
Система изоляции убережет ваше приложение от спонтанных обновлений библиотек и ОС.
Если приложение выйдет из строя или зависнет, оно будет автоматически перезапущено самим облаком, а точнее системой, называемой в других облачных платформах как менеджер по здравоохранению .
Проблемы с самим железом смягчаются самой облачностью.
Плагины и сервисы
Плагины и сервисы уже кратко обсуждались ранее в контексте ядра платформы.Плагины — это модули расширения архитектуры.
Например, поддержка Docker обеспечивается с помощью плагина.
Они делятся на:
- Изолировать - система изоляции приложений
- Водитель — система генерации внешних событий для приложений
- Хранилище - система хранения.
- Ведение журнала — система журналирования.
- шлюз — система балансировки
- Услуги — другие пользовательские сервисы
Хотите ли вы заменить системы журналирования на Системный журнал на
? Отлично, меняем три строчки в конфиге, код остаётся без изменений.
Может быть, вас не устраивает система балансировки по умолчанию и вы хотите IPVS? Легко! Ну а что, если у вас недостаточно предустановленных плагинов и вы хотите реализовать что-то новое? Что ж, написать их совсем не сложно, и мы будем очень рады пул-реквестам.
Самый последний пункт в плагинах — это сервисы.
Строго говоря, сервисы — это абстрактные интерфейсы для различных частей инфраструктуры.
Например, сервис URLFetch позволяет приложениям делать http-запросы и организовывать контроль над этими запросами, поскольку в целом приложениям не разрешается покидать контейнер из соображений безопасности.
Использование плагина Логсташ можно настроить агрегацию логов со всего кластера, их унифицированную обработку, индексацию и хранение в одном
с последующим удобным отображением в
(что мы и делаем в Яндексе).
Использование плагина
Всю информацию вы можете хранить в нашей одноименной системе.
В качестве альтернативы реализован плагин MongoDB и сервис Elasticsearch, которые позволяют использовать эти технологии в качестве системы хранения информации.
Заключение
Эта вводная статья начинает серию статей об облачной платформе Cocaine. В дальнейшем архитектура платформы, ее преимущества и недостатки будут рассмотрены более подробно (где бы мы были без них?).Мы покажем вам, как развернуть собственное облако из исходников или пакетов и как его настроить.
Далее последует описание фреймворков с примерами реальных приложений, написанных с их помощью.
Далее последует описание уже написанных плагинов и сервисов и будет рассмотрен пример написания собственного плагина или сервиса (а может и того и другого).
В заключение мы более подробно рассмотрим протокол Cocaine и то, как можно добавить поддержку другого языка, то есть написать свой собственный фреймворк.
Мы разрабатываем на github.
Кокаин"> Вся актуальная информация доступна здесь
.
В разделе Wiki есть документация как быстро собрать Cocaine из исходников, есть описание внутренних деталей.
Если вас заинтересовала платформа, вы можете опробовать ее через готовый вариант.
изображение.
Если у вас есть вопросы, задавайте.
Теги: #облака #paas #открытый исходный код #OpenSource #кокаин
-
Менеджер Аккаунта Google
19 Dec, 24 -
Актант
19 Dec, 24 -
Правила Личной Эффективности От Ed
19 Dec, 24 -
Планирование Бизнеса
19 Dec, 24 -
Поговорим О Логировании
19 Dec, 24
