Comments 92
UFO landed and left these words here
Нет, не планируется, просто потому что мы его нигде не используем. Но платформа открыта для расширения, все, что нужно — просто написать соответствующий фреймворк.
У нас тут кафе с «таким же» названием прикрыли, а Яндексу не страшно?
Это же не «к****н», это сокращение (Configurable Omnipotent Custom Applications Integrated Network Engine). А что оно так совпало — никто не виноват, да-да.
А потом поступит предложение от гос-чего-то-там-контроля переименоваться, чтобы стало понятнее, в какой-нибудь «Configurable Omnipotent Integrated Network Engine for Custom Applications». Прямо так и скажут, мол, «Coineca» звучит как-то лучше для русского уха, чем чуждый нам (согласно статье УК) «Сo**in»!
А если бы название было что-то вроде: "хранилище уникальное информационно-технического анализа" — то же бы сокращение юзали? Яндекс.*сами_знаете_что*?

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

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

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

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

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


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

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

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

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

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

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

Отсюда и вопрос — ждать аналогичного в Cocaine и как именно это дело деплоится в продакшен? Было бы интересно получить хотя бы абстрактный ответ, дабы не конфликтовать с NDA.
Пора варить?

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

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

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

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

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

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

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

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

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

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

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

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

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

Чувствую у вас там большой запас презентаций)
А где я говорил про полную виртуализацию? IaaS не обязательно подразумевает полную виртуализацию.

А так Google — один из ведущих разработчиков подсситемы cgroups из ядра Linux, так что то, что они им пользуются (точнее — все мы) вполне логично.
Давайте я расскажу =) 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. Совершенно несложно сделать всё так, чтобы ничего не нужно было переписывать, просто из-за этого не выйдет заимплементить некоторые другие штуки.
Спасибо за расшифровку, очень интересно, как это устроено внутри, ждем следующих статей!

Попробую найти время, чтобы это дело развернуть в тестовой среде. Реально ли по документации с Git проекта собрать это дело или лучше подождать Ваших (кстати, как раз именного этого бы и хотелось — как можно больше техники!) статей на Хабре?
Документация к последней версии (v0.11) обновилась совсем недавно, так что она самая актуальная и по ней вполне реально самостоятельно развернуть облачко.
Ну и конечно, всегда можно написать нам на рассылку, мы с радостью ответим.
Скажу вам по секрету, kobolog — автор Cocaine :) А в рассылочку пишите, или ногами приходите, если будете проездом в Москве. Возможно, в этом году будут какие нибудь субботники с докладами про чудо-технологию в Питере.
Автора видно издалека, я догадался :) А давайте сначала в Питере? По-моему, основной интерес к фиче будет все же среди хостеров, а их, как сложилось, в Питере как минимум не меньше, чем в Москве, если не больше :)
Я ответил на Ваш ответ 5 минут назад в сообщении :) Контейнеры там есть, но они вовсе не готовы для продакшена, в RHEL 6 — это developer preview, то есть — только тесты.
Очень круто. От продуманности решения до описания и картинок. :) Будем использовать.
Вы бы в приложении сделали поворот карты по вектору движения и ночной режим для векторных карт, ага!
В статье есть про это небольшой раздел:
Где Яндекс использует Cocaine

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

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

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

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

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

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

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

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

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

В целом же arch — достаточно красноглазый дистрибутив, вероятность появления сборки от поклонников арча далеко не нулевая.
Only those users with full accounts are able to leave comments. Log in, please.
Information
Founded

September 23, 1997

Location

Россия

Employees

свыше 10000 человек

Registered

9 August 2008