company_banner

Облачная платформа Яндекса. Cocaine

    Некоторое время назад мы довольно подробно начали рассказывать об одной из базовых облачных технологий Яндекса — Elliptics. Сегодня настала очередь поговорить о другой — той самой, под которой работают «эльфы» и которая делает мечту о своем облаке чуть ближе к реальности. Речь пойдет о Cocaine.

    Cocaine (Configurable Omnipotent Custom Applications Integrated Network Engine) — это PaaS-система (Platform-as-a-Service) с открытым исходным кодом, являющаяся по сути app engine и позволяющая создавать собственные облачные хостинги приложений — такие, как Google AppEngine, OpenShift, CloudFoundry или Heroku.



    Всем известно, что облака могут решить все инфраструктурные проблемы, превратить издержки в прибыль и насытить вашу жизнь бесконечной радостью и счастьем на веки веков. Единственным препятствием на пути к этим целям являются, собственно, облака. IaaS, PaaS, SaaS? Whatever-as-a-Service? Какой именно загадочный набор букв нужно выбрать, чтобы всё наконец стало хорошо?

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

    История

    История появления на свет данной технологии тесно связана именно с Heroku. Давным-давно, когда облачные технологии не были так популярны, но уже была Heroku, ею заинтересовался основатель нашего проекта Андрей Сибирёв.



    Heroku на тот момент представлял собой app engine, который поддерживал лишь Ruby, но сама идея была революционной. Подумать только: можно было написать свое рельсовое приложение, залить его в облако и совершенно не думать об инфраструктурных проблемах. Нужна база данных? Нет проблем — есть add-on’ы! Стянуть логи? Опять без проблем! Также магическим образом решались проблемы балансировки нагрузки. Сайт молод и развивается? Хорошо, у него есть ресурсы. Сайт уже популярен? Хорошо, облако поможет ему “раздуться” под нагрузкой и выжить. К тому же быстрый деплой через git уже с самых ранних пор приучал приобщаться к прекрасному.

    Звучит круто. Во всяком случае, так Heroku позиционировал себя. В реальности все было, конечно, мрачнее.

    У них была прекрасная идея, была реализация, но практически нигде не было описано, как она вообще работает. Как известно, если хочешь разобраться в чем-то неведомом, новом, поставь себя на место разработчика. Как бы ты написал с учетом увиденных плюшек и недостатков? Так был начат open-source проект облачного app engine’а. Забегая вперед, скажу, что, по всей видимости, такой же логикой руководствовались иностранные разработчики, что дало толчок к разработке еще нескольких аналогичных продуктов: OpenShift и CloudFoundry. О них будет рассказано чуть позднее.

    Cocaine изначально был гаражным just-for-fun проектом, но всё изменилось, когда в Яндексе возникла потребность в какой-нибудь раздуваемой платформе для приложений, которая могла бы справится с нагрузкой “может быть 10, а может быть и 100 000 RPS” для внутренних целей. Тем временем на подходе был Я.Браузер с такими же потребностями, и стало ясно, что проекту пора вылезать из гаража.

    На время оставим повествование в сторону и окунемся в мир сухой статистики и неоспоримых утверждений.

    Где Яндекс использует Cocaine

    Яндекс.Браузер — весь браузерный бэкэнд работает через Cocaine. Например, “Умная строка”, “Быстрые ссылки”, “Любимые сайты”. Внутренняя инфраструктура Яндекса.

    Поддерживаемые платформы

    На данный момент Cocaine может быть развернут из пакетов на следующих линуксовых дистрибутивах:
    • Ubuntu 12.04 (Precise Pangolin) и старше
    • RHEL 6 и производных.


    Поддержки Windows, к сожалению, нет, и не планируется, но это не значит, что пользователи, например, C# не смогут воспользоваться облачными сервисами, которые крутятся где-то в другом месте — достаточно написать подходящий фреймворк (что это такое будет рассказано далее).
    Из исходников Cocaine может быть собран практически на любой *nix системе, в которой есть boost 1.46+ и компилятор с поддержкой C++11 стандарта уровня GCC 4.4 (то есть, практически никакой).

    В качестве бонуса, Cocaine успешно собирается из исходников на Mac OS X. Поддержка технологии Docker (будет рассмотрен далее) требует линуксовое ядро не младше 3.8.

    Why so Cocainy?

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

    Heroku прежде всего не open-source технология со своей ценовой политикой, что может отпугнуть некоторых клиентов. Но за счет явной монетизации, у Heroku более развита поддержка, есть хорошая (теперь) документация с картинками. Удобнейшая система деплоинга приложений, основанная на git, с самого начала заставляет наводить порядок в коде и дает возможность сделать откат в случае факапа.
    Куча аддонов позволяет легко удовлетворить потребности ваших приложений в различных базах данных, кэшировании, очередях, синхронизации, логгировании и многом другом.

    Сами приложения при запуске полностью изолируются друг от друга в процессах, называемых dyno, которые распределены по специальной dyno grid, которая состоит из нескольких серверов. Dyno запускаются по мере необходимости в зависимости от нагрузки и убиваются при отсутствии таковой — таким образом в Heroku происходит балансировка нагрузки и обеспечение отказоустойчивости.
    Несмотря на изначальную поддержку одних лишь Ruby, сейчас Heroku предоставляет возможность писать приложения на таких языках как Java, Closure, Node.js, Scala, Python и (внезапно) PHP.

    Разработка CloudFoundry и OpenShift начиналась практически одновременно с Cocaine. Оба являются open-source проектами с сильной поддержкой больших компаний — VMware и RedHat соответственно. CloudFoundry на данный момент уже успел пережить одно перерождение. При этом поддержка языков ограничивается Java, Scala, Groovy, Ruby и JavaScript.
    У OpenShift с этим получше — поддерживается в дополнение Python, Perl и есть возможность самому сделать поддержку требуемых языков. К сожалению, приложения между собой могут общаться только через http, что несколько ограничивает сферу применения Облака.

    Cocaine при этом выгодно отличается от них:
    • присутствием адаптеров к различным языкам (фреймворков), что очень сильно упрощает работу с Облаком;
    • возможностью приложений общаться между собой не только через http, что, например, дает возможность построить свою платформу облачных вычислений;
    • сильной поддержкой изоляции приложений — технологию Docker, кроме нас, официально поддерживает только OpenShift.


    Краткий принцип работы

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

    Постулируем следующее неоспоримое утверждение: облака призваны решить инфраструктурные задачи.

    Одной из таких задач является обеспечение отказоустойчивости. Вряд ли бы кого-нибудь сильно впечатлила облачная платформа, работающая только на одной машине. В таком случае облако умирает вместе с машиной. Облако Cocaine’а состоит из одной и более независимых машин, на которых установлен сервер “cocaine-runtime”. На самом деле, это все, что необходимо для минимального функционирования платформы.



    Мы решили не идти путем CloudFoundry и заводить на каждую логическую деталь облака отдельную программу. Так, например, то, что в других облаках называется HealthManager — контроль жизни запущенных приложений — у нас объединено в единую сущность. Такое решение, с одной стороны, упрощает администрирование ноды и уменьшает количество точек отказа, но с другой, если “падает” cocaine-runtime, то целая нода выбывает из списка на некоторое время. Но испытание временем и нагрузками показали, что выбор такого решения был удачным.

    Представьте, у вас есть десяток машин, на каждой из которых работает cocaine-runtime. Но эти машины ничего не знают друг о друге. Когда рассматривались варианты выбора схемы построения топологии облака, было рассмотрено два варианта: все знают обо всех и несколько знают обо всех. В первом случае гарантировалась бы идентичность всех нод: если какая-то нода умрет, ничего существенного не изменится. Но одновременно с этим происходит смешение логики, т.к. тут по сути задействованы две сущности: первая — агрегация узлов и управление ими; вторая — управление своим узлом. Во втором случае полностью разделяется логика cocaine-runtime агрегирующих нод от остальных, но эту ноду нужно было бы сконфигурировать особым образом. В конечном итоге был выбран второй вариант.

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

    Облачный app engine не назывался бы так, если бы не умел запускать приложения. На самом деле cocaine-runtime’у все равно, что запускать. Единственное требование — чтобы файл был исполняемым. Другое дело, что это приложение будет практически сразу убито, т.к. не сможет ответить на простое handshake сообщение и, в принципе, нет никаких общих средств для того, чтобы контролировать приложение снаружи. Если оно работает, это еще не значит, что оно не зависло, к примеру. И тут мы вплотную подходим к теме контроля жизни приложений (или воркеров).

    Запущенное приложение нужно каким-то образом контролировать. На самом деле, необходим самый минимум: приложение должно время от времени оповещать сервер о том, что оно живо heartbeat командами и красиво умирать при terminate команде. Если приложение не отвечает слишком долго, то оно считается умершим и ему посылается SIGKILL, чтобы добить. Другими словами, воркер должен реализовывать специальный несложный протокол. Для удобства разработки приложений были сделаны адаптеры под различные языки, которые мы называем фреймворками.

    Пятиминутка истории

    Фреймворки представляют из себя специальное API, реализующее наиболее нативный для конкретного языка способ коммуникации с облаком. Например, под фреймворком скрыта реализация внутреннего протокола, позволяющая очень просто осуществить вызов облачного сервиса и работу с ним. Также реализованы средства для упрощения работы с асинхронными вызовами. На данный момент уже реализована поддержка:
    • C++
    • Java
    • Python
    • Ruby
    • Node.js
    • Go


    Есть средства для управления всем этим облачным богатством как через консольный интерфейс, так и через веб. Их реализация во многом очень похожа на аналогичные инструменты Heroku или CloudFoundry — приложения можно деплоить, запускать, останавливать, управлять и настраивать, а также собирать статистику и смотреть логи. Тут придумать что-то новое действительно сложно, хотя инструменты Amazon EC2 пока для нас являются примером в плане простоты и удобства, мы стремимся к ней.

    Архитектура

    Давайте сделаем шаг назад и посмотрим на облачную инфраструктуру свысока. Что из себя представляет облако? Обычно есть несколько машин, которые предоставляют ресурсы. Эти машины связываются каким-то образом в единую сущность каким-то управляющим элементом. Предоставляемые общие ресурсы используются для организации различных сервисов и пользовательских приложений. Ничего не напоминает?
    Существует категория программного обеспечения, в которую входят программы, занимающиеся управлением инфраструктуры одного (как правило) компьютера и предоставлением его ресурсов пользователю. В них есть четкое разделение на модули, есть управляющая сущность, есть пользовательское пространство. Речь идет, конечно, об операционных системах. Мы подумали, почему бы не сделать нечто похожее, но в случае с облачной инфраструктурой?

    Именно так построен Cocaine.

    В центре всего находится ядро, в которое входят основные иерархии сервисов, драйверы и API. Сервисом по сути является некая библиотека, написанная на C++, подключаемая к ядру, которая предоставляет Облаку некую службу. Сервисы запускаются одновременно с cocaine-runtime и живут в отдельном потоке в единственном экземпляре все время его работы.



    Основным сервисом является сервис Node, позволяющий управлять запуском, остановкой и работой приложений. Изначально запущенное приложение не имеет воркеров — экземпляров этого приложения — они начнут спавниться в момент подачи и увеличения нагрузки на приложение.

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

    Сервис Locator позволяет связывать независимые ноды в единый кластер, а также осуществлять поиск запрашиваемого клиентом приложения или сервиса в Облаке. Например, если какое-то приложение запрашивает сервис Logger, то именно Locator решает, какой именно endpoint отдавать ему. Вместе с endpoint также отдается таблица диспетчеризации методов сервиса. Кстати о ней: в отличие от RPC механизма CORBA или Thrift, мы решили избавиться от обязательного описания интерфейсов (IDL) сервисов (и приложений). Вместо этого, мы загружаем таблицу методов при каждом резолвинге, а далее фреймворки реализуют нативный для каждого языка способ работы с ней. Все, что нужно для этого — лишь имя запрашиваемого сервиса и, возможно, версия.

    Выиграли ли мы от этого? Определенно, да! Убрав необходимость определять IDL для каждого приложения мы серьезно облегчили их разработку под динамические языки, такие как Ruby или Python. Если у какого-то приложения изменилось API нет необходимости переписывать стабы под все фреймворки — в случае динамически типизированных языков методы вообще создаются динамически.

    Продолжаем о сервисах

    Вряд ли есть хоть одно облако без средств логгирования — у нас оно реализовано в виде сервиса Logger, представляющим собой единую точку транспорта логов со всей ноды.

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

    Архитектура сервисов открыта для расширения и аналогична модулям ядра linux. Можно написать собственные сервисы, а также расширить уже существующую иерархию.



    Особняком стоят драйверы, назначение которых состоит в генерации событий, обрабатываемых облаком. Например, таким событием может быть изменение какого-то файла или каталога, таймаут или иное событие. Можно (как вариант) написать драйвер к АЦП, которая будет сбрасывать сигналы на обработку по мере их поступления.

    В отличие от многих аналогичных PaaS, в которых приложения и сервисы могут общаться между собой только через HTTP, в Cocaine общение происходит через механизм RPC поверх бинарного HTTP/2.0-like протокола. Это дает нам возможность, например, взаимодействовать между различными приложениями напрямую, используя средства, предоставляемые фреймворками. Более подробно об этом можно прочитать здесь. Разумеется, сам HTTP интерфейс никуда не делся. Для каждого фреймворка предоставляются нативные средства, упрощающие разработку HTTP приложений. Например, в случае Python, есть flask-подобные декораторы.

    Снаружи до приложений можно достучаться также не только по HTTP интерфейсу (хотя такая возможность предоставляется), а например, через ZeroMQ или собственные расширения.

    Масштабирование и изоляция

    Давайте посмотрим более подробно, как же на самом деле реализована распределенность Облака и как оно пытается жить под нагрузкой.

    При запуске кластера отдельные ноды (машины с запущенным cocaine-runtime) узнают друг о друге при помощи внутреннего сервиса Locator, который регистрирует каждую машину в multicast группе, организуя тем самым коммуникацию между всеми нодами и отдельной нодой, сконфигурированной под Metalocator, являющийся входной точкой для облака и осуществляющий базовую балансировку нагрузки. Если на какой-то отдельной машине появится новое приложение или размножится уже существующее, металокатор об этом сразу узнает и направит на него нагрузку.

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

    Система спавнинга и изолирования приложений вынесена в отдельную сущность, называемой Isolate. В стандартной конфигурации облако будет запускать новые инстансы приложений используя обычные процессы. Если в качестве плагина установлена поддержка Docker’а, то облако будет запускать новые приложения в отдельном изолированном контейнере.

    Изоляция? Легко!

    Docker — это open-source технология, предоставляющая простой и эффективный способ для создания легковесных, переносимых и самодостаточных контейнеров из любых приложений. Однажды созданный, такой контейнер будет одинаково хорошо работать практически в любой среде, начиная от ноутбуков разработчика и тестировщика и заканчивая кластерами из тысяч серверов. Это, например, позволяет проводить изолирование приложений вместе с их бинарными зависимостями и больше не думать о том, что твое приложение начнет себя вести по-другому в облаке из-за других версий библиотек, либо вообще не встанет.

    В основе технологии Docker лежат обычные Linux Containers (LXC), которые предоставляют способность запустить приложение в изолированной среде благодаря использованию namespaces и cgroups. В отличие от сред с полной виртуализацией, таких как Xen или KVM, контейнеры используют общее ядро и не предоставляют возможности эмуляции устройств, но при этом их использование не влечёт дополнительных накладных расходов и запускаются они практически мгновенно. Помимо непосредственно контейнеризации, Docker предоставляет инструменты, упрощающие конфигурирование сети, распространение и развертывание образов приложений. Одним из таких инструментов является создание образов приложений из нескольких независимых слоев.
    При разработке приложений для Cocaine’а, тянущих за собой бинарные зависимости (например, приложения на C++ или Python), технология Docker может оказаться очень полезной для изоляции этих бинарных зависимостей.

    Erosion resistance

    Представьте себе, что вы создали приложение, залили его на сервер, настроили и оставили на произвол судьбы. Через неделю вы решаете проверить как оно работает и с горестью обнаруживаете, что приложение упало давным-давно по абсолютно различным причинам:
    • спонтанные обновления операционной системы или зависимых библиотек;
    • переполнение диска логами;
    • зависание или падение самого приложения;
    • проблемы с самими железом сервера.


    Эти эффекты известны под названием “Software erosion”.

    Cocaine является erosion-resistant технологией. От спонтанных обновлений библиотек и ОС ваши приложение спасает система изоляции. В случае падения или зависания приложения, оно будет автоматически перезапущено самим облаком, а точнее системой, называемой в других облачных платформах как health manager. Проблемы с самим железом нивелируются самой облачностью.

    Плагины и сервисы

    Про плагины и сервисы уже было кратко рассказано ранее в контексте ядра платформы. Плагины представляют собой модули расширения архитектуры. Например, поддержка Docker’а осуществлена как раз с помощью плагина. Они подразделяются на:
    • Isolate — система изоляции приложений
    • Driver — система генерации внешних событий для приложений
    • Storage — система хранения.
    • Logging — система логгирования.
    • Gateway — система балансировки
    • Services — остальные пользовательские сервисы


    С помощью плагинов можно менять реализацию вышеперечисленных частей системы, сделав лишь изменение в конфигурационном файле. Хотите заменить системы логгирования с Syslog на Logstash? Отлично, меняем три строчки в конфиге, код при этом остается неизменным. Может, не устраивает дефолтная система балансировки и вам хочется IPVS? Запросто! Ну а что если не хватает предустановленных плагинов и хочется реализовать что-то новое? Что ж, писать их совершенно несложно, а мы будем очень рады пул реквестам.

    Самым последним пунктом в плагинах стоят сервисы. Если строго, то сервисы представляют собой абстрактные фронтенды к различным частям инфраструктуры.

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

    С помощью плагина Logstash можно настроить агрегацию логов со всего кластера, их унифицированную обработку, индексацию и хранение в том же Elasticsearch с последующим удобным отображением в Kibana (что мы и делаем в Яндексе).

    С помощью плагина Elliptics можно осуществлять хранение всей информации в нашей одноименной системе. В качестве альтернативы реализованы MongoDB plugin и Elasticsearch сервис, которые позволяют использовать эти технологию в качестве системы хранения информации.

    Заключение

    Это вводная статья начинает цикл статей об облачной платформе Cocaine. В дальнейшем будет рассмотрена более детально архитектура платформы, ее достоинства и недостатки (куда уж без них?).

    Мы покажем вам, как развернуть собственное облако из исходников или пакетов и как его сконфигурировать. Затем последует описание фреймворков с примерами реальных приложений, написанных с их помощью. Далее последует описание уже написанных плагинов и сервисов и будет рассмотрен пример написание собственного плагина или сервиса (а может и оба). В заключение мы рассмотрим более подробно Cocaine’овый протокол и как можно добавить поддержку другого языка, то есть написать собственный фреймворк.

    Разработку мы ведем на github. Вся самая актуальная информация доступна именно здесь. В разделе Wiki есть документация о том, как быстренько собрать Cocaine из исходников, есть описание внутренних деталей. Если вас заинтересовала платформа, вы можете попробовать ее в деле через готовый vagrant образ. Если есть вопросы, задавайте.
    Яндекс
    450.30
    Как мы делаем Яндекс
    Share post

    Comments 92

    • UFO just landed and posted this here
        +3
        Именно как ПО, доступное любому.
        +1
        А планируется ли поддержка .net (F#, C#)?
          +6
          Нет, не планируется, просто потому что мы его нигде не используем. Но платформа открыта для расширения, все, что нужно — просто написать соответствующий фреймворк.
          +27
          У нас тут кафе с «таким же» названием прикрыли, а Яндексу не страшно?
            +10
            Это же не «к****н», это сокращение (Configurable Omnipotent Custom Applications Integrated Network Engine). А что оно так совпало — никто не виноват, да-да.
              +2
              А потом поступит предложение от гос-чего-то-там-контроля переименоваться, чтобы стало понятнее, в какой-нибудь «Configurable Omnipotent Integrated Network Engine for Custom Applications». Прямо так и скажут, мол, «Coineca» звучит как-то лучше для русского уха, чем чуждый нам (согласно статье УК) «Сo**in»!
                +2
                Отлично звучит! Созвучно с koi neko, как мило!
                  0
                  звучит как название для какого-нибудь bitcoin сервиса
                  +6
                  А если бы название было что-то вроде: "хранилище уникальное информационно-технического анализа" — то же бы сокращение юзали? Яндекс.*сами_знаете_что*?

                  Мы в России живём. Как Вы тут будете называть этот сервис? Все помнят как у нас величают ОПераторов СОтовой Связи?

                  Тут товарищ звёздочками прикрывает название — это ещё ничего. А если он позвонит в тех поддержду и вспосмнит, о СОРМе, который анализирует тысячи телефонных звонков на присутсвие определённых слов? Они с саппортом в словарные ассоциации будут играть?

                  — Ало, у меня тут проблема с Вашим сервисом
                  — С каким?
                  — На «К» на чинается, на «н» заканчивается
                  — Вы забыли как он называется?
                  — Нет, помню. Но не произношу имени сервиса всуе

                  В общем, удачи техподдержке Яндекса
                    +1
                    Cocaine — это технология, а не сервис, поэтому к технической поддержке никто по его поводу обращаться не будет :)
                    +9
                    Почему вы так боитесь сказать слово КОКАИН? Ах да, законы. Все же Хабр наглядно показывает, что правительство людей будет нагибать и нагибать, раз уже слово КОКАИН бояться написать. Дожили.
                      +1
                      кокейн, если хочется пококетничать, никого не смущать и самому не смущаться :)
                        –1
                        Кокаин.
                          0
                          Между прочим, студенты-стоматологи до сих пор изучают его как местный анестетиков. Очень весело тренироваться выписывать рецепты на него:
                          RP: Cocaini hydrohloridi 5.0
                          D.t.d. N10
                          Da. Signa.
                          +1
                          А как будет звучать от довольного архитектора «я подсел на Cocaine»…
                        0
                        Сразу вопрос, а почему под Ваши задачи не подошел CoreOS? Там ведь и обнаружение сервисов и управление конфигурацией через raft и многое-многое другое да еще в комплекте с контейнерами и очень никзйо стоимостью поддержки.

                        Сильной поддержкой изоляции приложений — технологию Docker, кроме нас, официально поддерживает только OpenShift


                        Ваша не правда :) CoreOS упомянутый выше как раз изначально поддерживает Docker
                          +3
                          CoreOS это совсем не то, о чём мы тут рассказываем. CoreOS это просто ещё один linux flavor в комплекте с etcd и dockerd. Это значит, что:

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

                          В общем, CoreOS выглядит неплохой базовой системой для запуска Cocaine, но никак не заменой =)

                          Задачи Cocaine — управление ресурсами, предоставление общей шины для связи компонент и маршутизация запросов — CoreOS не решает.
                            0
                            Не, что Cocaine — это несколько больше, чем CoreOS довольно ясно и понятно. Вопрос был именно в том, почему он не был заложен в основу платформы.

                            CoreOS не подошел объективно или не хотите принимать NIH решения?
                              +4
                              CoreOS был анонсирован через полтора года после начала разработки Cocaine, так что мы никак не могли взять его за основу =) А сейчас у нас и так есть поддержка Docker и уже тестируется репликация конфигурации на основе Raft.
                                +2
                                О, даты, спасибо за инфу :) Становится понятнее.

                                CoreOS все же чуточку больше чем ядро+raft+docker, там используется крайне грамотный подход к обновлениям ОС через read-only root раздел, что почти до нуля снижает стоимость обслуживания железа на ноде и убирает в общем-то нафиг не нужный на машине CentOS/Debian/Ubuntu/Ваш-любимый_дистрибутив.

                                Отсюда и вопрос — ждать аналогичного в Cocaine и как именно это дело деплоится в продакшен? Было бы интересно получить хотя бы абстрактный ответ, дабы не конфликтовать с NDA.
                                  +3
                                  Будет больше статьей, там расскажем!
                                    0
                                    Интригуете! С нетерпением ждем :)
                            0
                            Таким было черновое название этого поста.
                            +3
                            Пора варить?

                            А если ближе к теме, то откуда такое название то взялось?
                              +2
                              Нейминг реально смущяет.

                              — Ты под чем работаешь?
                              — Под хироку.
                              — А мне под Cocain'ом лучше =)
                                +18
                                Дак правда лучше же.
                                  +12
                                  Посмотрим, вызовет ли Cocaine зависимость у айтишников.
                                    +9
                                    — У тебя умный дом на чем?
                                    — Малины с Пидорой, обработка фич X и Y на Кокаине…
                                      +5
                                      Помню, в конце девяностых бабушки в автобусах от разговоров типа «у меня мама сдохла, поеду на рынок, новую поищу» шарахались.
                                      То теперь все бабушки у подъездов точно убедятся, что все айтишники «наркоманы»!
                                    +1
                                    Если верить подкасту Радио-Т, то оно как-то само так вышло. Впрочем, могу и перепутать, это было несколько выпусков назад и лишь вскользь
                                    +4
                                    А в свете последних законов об ужесточениях всяких не попадает ли выбор такого названия под пропаганду наркотиков в сети Интернет?
                                      +3
                                      Проснитесь уже. Если правительство захочет бодаться — оно найдет к чему придраться. В России нельзя не нарушить закон. Просто Яндекс, это тебе не какой-то строптивый журналюга-блогер или популярный сайтик. Яндекс может и копытом в чело отвесить какому-нибудь депутату. И будут волнения, и будет брожение. Кому это надо?
                                      0
                                      Еще вопрос — «На данный момент Cocaine может быть развернут из пакетов на следующих линуксовых дистрибутивах: Ubuntu 12.04 (Precise Pangolin) и старше и RHEL 6 и производных.»

                                      Но оба эти дистрибутива используют 2.6.32 версию ядра, а Вы для работы docker просите аж 3.8 ядро. Как обеспечить работу Cocaine на RHEL6, но при этом не занимаясь сборкой ядер самостоятельно и без жертв продакшену?
                                        +1
                                        у меня на Ubuntu 12.04 сейчас ядро 3.8.0-35-generic. Адпдейты были только из репозитория
                                          0
                                          Да, спасибо, я совершенно забыл обновления базового ядра в Ubuntu.

                                          Но все равно остается вопрос по части RHEL 6.
                                            +1
                                            Поддержка Docker'а обеспечивается плагином. Без него Cocaine вполне себе может работать, просто изоляция процессов будет на уровне fork'а и ограничений при помощи механизма cgroups.
                                            Соответственно, 3.8 ядро необходимо лишь в тех случаях, когда используется Docker.
                                              0
                                              Дело тут не в Docker самом по себе, они используют функции Linux ядра для повышения изоляции одних приложений от других, это не просто запросы Docker.
                                                0
                                                Проблема несколько шире — меня крайне удивляет, что авторы утверждают, что Docker не обязален и списывают потребность в новом ядре на него (вообще, если быть точными, то ядро лучше 3/13, так как только там была добавленна полноценная поддержка user namespace), но раз управление изоляцией обеспечено именно через него, то что тогда получается?

                                                А получается облачная система без изоляции. То есть мы получаем сервер с 1000-2000 приложений, которые никак друг от друга не отделены кроме как силами POSIX системы прав. Работать такое если и будет, то настолько ужасно, насколько может работать сервер «а весь софт мы поставим на железо» :)
                                                  0
                                                  Далеко не всегда изоляция на уровне контейнеров необходима, это от приложений зависит. Кому-то cgroups будет достаточно, а кому-то и на уровне разных процессов. Вы, наверное, сразу прикладываете подобные системы к продаже услуг хостинга частникам, да?
                                                    0
                                                    К сожалению, для применения в хостинге любым контейнерам очень далеко.

                                                    Поэтому ответ — нет, я сужу со стороны отдаленной от хостинга. Просто без изоляции гибкость и вообще смысл использования таких сложных систем — теряется. Потому что если стоит задача запустить 1 приложение на 1000 серверов, то это проще сделать обычным способом — через какую-либо систему управления конфигурациями.
                                                      0
                                                      А потом навесить сверху балансировку нагрузки, управление пулом воркеров, сбор логов, вотчдоги, а в качестве отдельного бонуса — деплоймент свежей версии.

                                                      На самом деле, если надо запустить даже десяток приложений на паре десятков серверов — то всякие PaaS уже нанесут ощутимую пользу, уже даже за счёт унификации инфраструктуры. Если же приложения взаимодействуют друг с другом — то без какой-то платформы будет совсем печально.
                                                        0
                                                        Вы забываете тот момент, что для работы на базе PaaS приложение должно быть переписано с нуля с учетом особенностей платформы. Поэтому не получится унифицировать имеющееся — переписывать с нуля! :) И тут-то встает вопрос «а зачем».

                                                        Google ушел от Google Apps Engine к Google Compute Engine, и это — неспроста.

                                                        Я не хочу, сказать, что Cocaine — плохо (это наоборот — круто!), я хочу сказать, что такой паттер подходит к от силы десятку-другому компаний в Ру сегменте.

                                                        А крупняк — Google, FB и прочие давно живут на контейнерных IaaS с аналогичной системой, правда, они не открытые.
                                                          0
                                                          Я же как раз и написал, «зачем». Чтобы не думать об инфраструктуре в каждом из приложений, а сделать её один раз. Вы попробуйте, всё не так страшно, переписывать всё с нуля не надо :) Ну или можно начинать новое писать под PaaS, а старое постепенно вывести из эксплуатации.

                                                          А откуда у вас такие знания про гугл и фб? Мне вот от сотрудников гугла доходили сведения, что у них очень даже PaaS под названием borg. А их новая система, про которую в интернете побольше ссылок есть, называется omega.
                                                            0
                                                            «Чтобы не думать об инфраструктуре», какое-то время назад краем глаза зацепил пост «20 жалоб сотрудников Google». Так вот одна была «дайте мне обычный VPS с MySQL и Linux для прототипа проекта, достал меня Ваш GAE и BigTable!». Честно говоря, не уверен, в 100% правдивости отзыва, но по-моему — показательно.

                                                            Про Google и FB все довольно сложно по причине скудности публичной информации, но с другой стороны в сети есть достоверная информация, что они «используют контейнеризацию в основе своих облаков», а вот что там внутри — не известно, по крайне мере я не видел такой информации.

                                                            То есть ситация такова, что там IaaS точно есть, а вот наличие PaaS — под вопросом.
                                                              +2
                                                                0
                                                                Спасибо, посмотрю, первый раз вижу эту презентацию.

                                                                Чувствую у вас там большой запас презентаций)
                                                                0
                                                                А как вы сделали вывод о том, что IaaS есть из фразы о том, что контейнеризацию используют? В Cocaine вон тоже контейнеры, а никаких виртуалок нету.

                                                                www.usenix.org/cluster-management-google
                                                                www.youtube.com/watch?v=WbE3wAJCm3I
                                                                  0
                                                                  А где я говорил про полную виртуализацию? IaaS не обязательно подразумевает полную виртуализацию.

                                                                  А так Google — один из ведущих разработчиков подсситемы cgroups из ядра Linux, так что то, что они им пользуются (точнее — все мы) вполне логично.
                                                                  +3
                                                                  Давайте я расскажу =) PaaS & IaaS это всё, очевидно, marketing bullshit, так что давайте сразу эти аббревиатуры забудем. То что мы (и другие компании типа Гугла или ФБ) делаем — это попытка унифицировать инфраструктуру.

                                                                  Совершенно не важно какими буквами это называть, главное — чтобы разработчики не думали о том, где и как их приложения будут запущены, а просто писали код, используя те инструменты, которые им подходят, а админы не думали о том, как разрешить очередной конфликт из трёх сотен зависимостей. Та же Borg/Omega от Гугла и наш Cocaine — это и не PaaS и не IaaS per se, это система управления инфраструктурными ресурсами, и как раз GAE и, я подозреваю, CE уже работают поверх неё.

                                                                  В это понятие входит и изоляция (kvm, xen, lxc, openvz, docker — не важно), и service discovery, и messaging (protobuf, thrift, json-rpc, cap'n proto — опять же, не важно что именно), и resource provisioning и машрутизация вместе с балансировкой нагрузки и ещё куча всякого инструментария вокруг.

                                                                  А нужно ли переписывать приложения или не нужно — это вопрос реализации и trade-offs. Совершенно несложно сделать всё так, чтобы ничего не нужно было переписывать, просто из-за этого не выйдет заимплементить некоторые другие штуки.
                                                                    0
                                                                    Спасибо за расшифровку, очень интересно, как это устроено внутри, ждем следующих статей!

                                                                    Попробую найти время, чтобы это дело развернуть в тестовой среде. Реально ли по документации с Git проекта собрать это дело или лучше подождать Ваших (кстати, как раз именного этого бы и хотелось — как можно больше техники!) статей на Хабре?
                                                                      +1
                                                                      Документация к последней версии (v0.11) обновилась совсем недавно, так что она самая актуальная и по ней вполне реально самостоятельно развернуть облачко.
                                                                      Ну и конечно, всегда можно написать нам на рассылку, мы с радостью ответим.
                                                                        0
                                                                        Ого, поддержка от самого Яндекса :) Спасибо!
                                                                          0
                                                                          Скажу вам по секрету, kobolog — автор Cocaine :) А в рассылочку пишите, или ногами приходите, если будете проездом в Москве. Возможно, в этом году будут какие нибудь субботники с докладами про чудо-технологию в Питере.
                                                                            0
                                                                            Автора видно издалека, я догадался :) А давайте сначала в Питере? По-моему, основной интерес к фиче будет все же среди хостеров, а их, как сложилось, в Питере как минимум не меньше, чем в Москве, если не больше :)
                                                  0
                                                  Red Hat Enterprise Linux 6.5 enables customers to deploy application images in containers created using Docker in their environment of choice: physical, virtual, or cloud.
                                                  © www.redhat.com/archives/rhelv6-announce/2013-November/msg00000.html

                                                  Ну и докер не обязательно использовать, тогда особо без разницы, какое ядро.
                                                    +1
                                                    Я ответил на Ваш ответ 5 минут назад в сообщении :) Контейнеры там есть, но они вовсе не готовы для продакшена, в RHEL 6 — это developer preview, то есть — только тесты.
                                              +2
                                              Очень круто. От продуманности решения до описания и картинок. :) Будем использовать.
                                                0
                                                Для каких задач планируете использовать?
                                                  0
                                                  Повышение живучести пользовательских сервисов. Начнем с простого шаринга пользовательских гео-данных, а там посмотрим.
                                                    0
                                                    Вы бы в приложении сделали поворот карты по вектору движения и ночной режим для векторных карт, ага!
                                                +5
                                                Риквестуем поддержку PHP! Да и можем в коде поучаствовать в принципе… )
                                                  0
                                                  Где Яндекс использует Cocaine
                                                    +2
                                                    В статье есть про это небольшой раздел:
                                                    Где Яндекс использует Cocaine

                                                    Яндекс.Браузер — весь браузерный бэкэнд работает через Cocaine. Например, “Умная строка”, “Быстрые ссылки”, “Любимые сайты”. Внутренняя инфраструктура Яндекса.
                                                      0
                                                      А какой порядок (10/100/1000?) размера кластера на Cocaine?
                                                        +1
                                                        Несколько тысяч ядер, несколько терабайт оперативной памяти.
                                                          0
                                                          Странный баланс памяти/процессоров, то есть на 1 ядро как максимум 1Gb памяти. Может быть сотни терабайт оперативной памяти все же?

                                                          Ибо несколько ТБ оперативной памяти — это 2 недорогих Dell PowerEDGE 720 с 768Gb на борту :)
                                                            +1
                                                            На одно ядро приходится по несколько гигабайт. Всё-таки обработка запросов пользователей это в большей мере вычислительная задача, поэтому памяти особо много не нужно.
                                                              +1
                                                              Понятно, спасибо!
                                                    +13
                                                    Яндекс, вы просто боги маркетинга. :)
                                                      +1
                                                      Бесплатного пиара много не бывает.
                                                      0
                                                      load balancer всё так же в выпиленном состоянии?
                                                        0
                                                        Уже нет. Балансировкой занимается Locator с помощью Gateway плагинов. Сейчас их два — простой adhoc gateway, который выбирает ноды рандомно, и IPVS gateway, который рулит локальным IPVS, создавая и удаляя в нём виртуальные сервисы, добавляя рилы и выставляя веса.
                                                        –9
                                                        Что употребляли, так и назвали? :)
                                                          +4
                                                          Спасибо за поддержку языка Go ;)
                                                            +4
                                                            High End Russian Online Integrated Network Engine
                                                            Business Linear Object Java Oriented Builder
                                                            Windows HTML-Optimised Resourses

                                                            Без этих сервисов трудно представить жизнь в современном IT сообществе. Спасибо Яндексу за идею.
                                                              0
                                                              А мне одному показалось странным наличие агрегирующей ноды? Если она падает, то падает все приложение? Или я чего-то не так понял?
                                                                +1
                                                                Их можно сколько угодно поднимать, а в клиентском фреймворке указывать список из агрегирующих нод. Между собой они ничего не шарят, так что пусть падают.
                                                                0
                                                                RedHat Openshift, поддерживает JavaEE. В Cocaine можно будет развернуть JavaEE приложение?
                                                                  0
                                                                  Где посмотреть пример реализации nodejs-приложения?
                                                                    0
                                                                    На главной странице node.js фреймворка (здесь) есть подробное описание, плюс в каталоге sample есть еще несколько примеров.
                                                                    0
                                                                    В заключение мы рассмотрим более подробно Cocaine’овый протокол и как можно добавить поддержку другого языка, то есть написать собственный фреймворк.

                                                                    А вот это хотелось бы по-подробнее. Ну или хотя бы линком киньте на ман/примеры откуда можно было бы начать.
                                                                      +1
                                                                      Подробнее будет, но в следующих статьях.

                                                                      На данный момент можете почитать здесь о протоколе, а саму реализацию можно глянуть на примерах уже существующих фреймворках здесь. На мой взгляд, проще всего для понимания глянуть во фреймворк Go или Ruby, но тут, конечно, субъективно.
                                                                      –2
                                                                      А PKGBUILD для арча будет?
                                                                        0
                                                                        А за что минус-то? Я хочу потестить cocaine. Быстрого варианта поставить его у меня нет, кроме как ждать пакет. Ну или ставить под виртуалкой убунту и в ней уже поднимать cocaine. А это время.
                                                                          +2
                                                                          А кто отменял
                                                                          cmake. && make && sudo make install
                                                                          ?

                                                                          Чтобы сделать PKGBUILD для арча надо сначана изучить, как его делать, а потом сделать билд-ферму под него, чтобы регулярно тестировать сборку. Если у вас есть на это время — you are welcome! Опен сорс же так работает. Перед разработчиками Cocaine не стоит задачи охвата максимального количества разных дистрибутивов.

                                                                            0
                                                                            Я прекрасно понимаю, почему его не делают на текущий момент.
                                                                            А на ваш make install могу сказать только одно.
                                                                            Если у вас есть на это время — you are welcome! Опен сорс же так работает.

                                                                            И вопрос могу переформулировать, адресуя его разработчикам. Поддержка ArchLinux в качестве целевой платформы планируется?
                                                                              0
                                                                              И времени, к сожалению, на все не хватает, а так — с удовольствием занялся бы поддержкой для арча.
                                                                                0
                                                                                На счёт make install — cmake_install_prefix поможет, или вагрантовская виртуалка для опытов. Впрочем, тут каждый сам решает, делать ему make install, или не делать, а если делать — то где.

                                                                                В ближайшее время из новых систем планируется только поддержка новой LTS убунты, которая в апреле выйдет. Основные силы разработчиков направлены на написание новых фич и починку багов. Если у нас получится собрать сборочные стенды с самыми разными популярными линуксами — то их поддержка может появиться, но вряд ли это будет раньше, чем через год, если вообще будет.

                                                                                В целом же arch — достаточно красноглазый дистрибутив, вероятность появления сборки от поклонников арча далеко не нулевая.
                                                                          0
                                                                          а если в общих чертах сравнить с App Scale , то как пересекается функциональность этих продуктов?
                                                                            0
                                                                            «спавниться»
                                                                            Поправьте пожалуйста очепятку.

                                                                            Only users with full accounts can post comments. Log in, please.