Comments 92
UFO just landed and posted this here
А планируется ли поддержка .net (F#, C#)?
У нас тут кафе с «таким же» названием прикрыли, а Яндексу не страшно?
Это же не «к****н», это сокращение (Configurable Omnipotent Custom Applications Integrated Network Engine). А что оно так совпало — никто не виноват, да-да.
А потом поступит предложение от гос-чего-то-там-контроля переименоваться, чтобы стало понятнее, в какой-нибудь «Configurable Omnipotent Integrated Network Engine for Custom Applications». Прямо так и скажут, мол, «Coineca» звучит как-то лучше для русского уха, чем чуждый нам (согласно статье УК) «Сo**in»!
А если бы название было что-то вроде: "хранилище уникальное информационно-технического анализа" — то же бы сокращение юзали? Яндекс.*сами_знаете_что*?
Мы в России живём. Как Вы тут будете называть этот сервис? Все помнят как у нас величают ОПераторов СОтовой Связи?
Тут товарищ звёздочками прикрывает название — это ещё ничего. А если он позвонит в тех поддержду и вспосмнит, о СОРМе, который анализирует тысячи телефонных звонков на присутсвие определённых слов? Они с саппортом в словарные ассоциации будут играть?
— Ало, у меня тут проблема с Вашим сервисом
— С каким?
— На «К» на чинается, на «н» заканчивается
— Вы забыли как он называется?
— Нет, помню. Но не произношу имени сервиса всуе
В общем, удачи техподдержке Яндекса
Мы в России живём. Как Вы тут будете называть этот сервис? Все помнят как у нас величают ОПераторов СОтовой Связи?
Тут товарищ звёздочками прикрывает название — это ещё ничего. А если он позвонит в тех поддержду и вспосмнит, о СОРМе, который анализирует тысячи телефонных звонков на присутсвие определённых слов? Они с саппортом в словарные ассоциации будут играть?
— Ало, у меня тут проблема с Вашим сервисом
— С каким?
— На «К» на чинается, на «н» заканчивается
— Вы забыли как он называется?
— Нет, помню. Но не произношу имени сервиса всуе
В общем, удачи техподдержке Яндекса
Почему вы так боитесь сказать слово КОКАИН? Ах да, законы. Все же Хабр наглядно показывает, что правительство людей будет нагибать и нагибать, раз уже слово КОКАИН бояться написать. Дожили.
А как будет звучать от довольного архитектора «я подсел на Cocaine»…
Сразу вопрос, а почему под Ваши задачи не подошел CoreOS? Там ведь и обнаружение сервисов и управление конфигурацией через raft и многое-многое другое да еще в комплекте с контейнерами и очень никзйо стоимостью поддержки.
Ваша не правда :) CoreOS упомянутый выше как раз изначально поддерживает Docker
Сильной поддержкой изоляции приложений — технологию Docker, кроме нас, официально поддерживает только OpenShift
Ваша не правда :) CoreOS упомянутый выше как раз изначально поддерживает Docker
CoreOS это совсем не то, о чём мы тут рассказываем. CoreOS это просто ещё один linux flavor в комплекте с etcd и dockerd. Это значит, что:
— некая несуществующая подсистема всё равно должна терминировать траффик пользователей, маршрутизировать его в выбранный по какому-то алгоритму контейнер и возвращать ответ;
— некая другая несуществующая подсистема должна собирать статистику, метрики и контролировать жизненный цикл контейнеров, управляя текущим количеством запущенных экземпляров приложения;
— ещё одна несуществующая подсистема должна управлять образами, генерировать их из коммитов и тегов, запускать автотесты и, возможно, пушить прошедшие тестирование образы в репозиторий, который тоже нужно как-то менеджить;
— и много чего другого.
В общем, CoreOS выглядит неплохой базовой системой для запуска Cocaine, но никак не заменой =)
Задачи Cocaine — управление ресурсами, предоставление общей шины для связи компонент и маршутизация запросов — CoreOS не решает.
— некая несуществующая подсистема всё равно должна терминировать траффик пользователей, маршрутизировать его в выбранный по какому-то алгоритму контейнер и возвращать ответ;
— некая другая несуществующая подсистема должна собирать статистику, метрики и контролировать жизненный цикл контейнеров, управляя текущим количеством запущенных экземпляров приложения;
— ещё одна несуществующая подсистема должна управлять образами, генерировать их из коммитов и тегов, запускать автотесты и, возможно, пушить прошедшие тестирование образы в репозиторий, который тоже нужно как-то менеджить;
— и много чего другого.
В общем, CoreOS выглядит неплохой базовой системой для запуска Cocaine, но никак не заменой =)
Задачи Cocaine — управление ресурсами, предоставление общей шины для связи компонент и маршутизация запросов — CoreOS не решает.
Не, что Cocaine — это несколько больше, чем CoreOS довольно ясно и понятно. Вопрос был именно в том, почему он не был заложен в основу платформы.
CoreOS не подошел объективно или не хотите принимать NIH решения?
CoreOS не подошел объективно или не хотите принимать NIH решения?
CoreOS был анонсирован через полтора года после начала разработки Cocaine, так что мы никак не могли взять его за основу =) А сейчас у нас и так есть поддержка Docker и уже тестируется репликация конфигурации на основе Raft.
О, даты, спасибо за инфу :) Становится понятнее.
CoreOS все же чуточку больше чем ядро+raft+docker, там используется крайне грамотный подход к обновлениям ОС через read-only root раздел, что почти до нуля снижает стоимость обслуживания железа на ноде и убирает в общем-то нафиг не нужный на машине CentOS/Debian/Ubuntu/Ваш-любимый_дистрибутив.
Отсюда и вопрос — ждать аналогичного в Cocaine и как именно это дело деплоится в продакшен? Было бы интересно получить хотя бы абстрактный ответ, дабы не конфликтовать с NDA.
CoreOS все же чуточку больше чем ядро+raft+docker, там используется крайне грамотный подход к обновлениям ОС через read-only root раздел, что почти до нуля снижает стоимость обслуживания железа на ноде и убирает в общем-то нафиг не нужный на машине CentOS/Debian/Ubuntu/Ваш-любимый_дистрибутив.
Отсюда и вопрос — ждать аналогичного в Cocaine и как именно это дело деплоится в продакшен? Было бы интересно получить хотя бы абстрактный ответ, дабы не конфликтовать с NDA.
Пора варить?
А если ближе к теме, то откуда такое название то взялось?
А если ближе к теме, то откуда такое название то взялось?
Нейминг реально смущяет.
— Ты под чем работаешь?
— Под хироку.
— А мне под Cocain'ом лучше =)
— Ты под чем работаешь?
— Под хироку.
— А мне под Cocain'ом лучше =)
Если верить подкасту Радио-Т, то оно как-то само так вышло. Впрочем, могу и перепутать, это было несколько выпусков назад и лишь вскользь
А в свете последних законов об ужесточениях всяких не попадает ли выбор такого названия под пропаганду наркотиков в сети Интернет?
Проснитесь уже. Если правительство захочет бодаться — оно найдет к чему придраться. В России нельзя не нарушить закон. Просто Яндекс, это тебе не какой-то строптивый журналюга-блогер или популярный сайтик. Яндекс может и копытом в чело отвесить какому-нибудь депутату. И будут волнения, и будет брожение. Кому это надо?
Еще вопрос — «На данный момент Cocaine может быть развернут из пакетов на следующих линуксовых дистрибутивах: Ubuntu 12.04 (Precise Pangolin) и старше и RHEL 6 и производных.»
Но оба эти дистрибутива используют 2.6.32 версию ядра, а Вы для работы docker просите аж 3.8 ядро. Как обеспечить работу Cocaine на RHEL6, но при этом не занимаясь сборкой ядер самостоятельно и без жертв продакшену?
Но оба эти дистрибутива используют 2.6.32 версию ядра, а Вы для работы docker просите аж 3.8 ядро. Как обеспечить работу Cocaine на RHEL6, но при этом не занимаясь сборкой ядер самостоятельно и без жертв продакшену?
у меня на Ubuntu 12.04 сейчас ядро 3.8.0-35-generic. Адпдейты были только из репозитория
Да, спасибо, я совершенно забыл обновления базового ядра в Ubuntu.
Но все равно остается вопрос по части RHEL 6.
Но все равно остается вопрос по части RHEL 6.
Поддержка Docker'а обеспечивается плагином. Без него Cocaine вполне себе может работать, просто изоляция процессов будет на уровне fork'а и ограничений при помощи механизма cgroups.
Соответственно, 3.8 ядро необходимо лишь в тех случаях, когда используется Docker.
Соответственно, 3.8 ядро необходимо лишь в тех случаях, когда используется Docker.
Дело тут не в Docker самом по себе, они используют функции Linux ядра для повышения изоляции одних приложений от других, это не просто запросы Docker.
Проблема несколько шире — меня крайне удивляет, что авторы утверждают, что Docker не обязален и списывают потребность в новом ядре на него (вообще, если быть точными, то ядро лучше 3/13, так как только там была добавленна полноценная поддержка user namespace), но раз управление изоляцией обеспечено именно через него, то что тогда получается?
А получается облачная система без изоляции. То есть мы получаем сервер с 1000-2000 приложений, которые никак друг от друга не отделены кроме как силами POSIX системы прав. Работать такое если и будет, то настолько ужасно, насколько может работать сервер «а весь софт мы поставим на железо» :)
А получается облачная система без изоляции. То есть мы получаем сервер с 1000-2000 приложений, которые никак друг от друга не отделены кроме как силами POSIX системы прав. Работать такое если и будет, то настолько ужасно, насколько может работать сервер «а весь софт мы поставим на железо» :)
Далеко не всегда изоляция на уровне контейнеров необходима, это от приложений зависит. Кому-то cgroups будет достаточно, а кому-то и на уровне разных процессов. Вы, наверное, сразу прикладываете подобные системы к продаже услуг хостинга частникам, да?
К сожалению, для применения в хостинге любым контейнерам очень далеко.
Поэтому ответ — нет, я сужу со стороны отдаленной от хостинга. Просто без изоляции гибкость и вообще смысл использования таких сложных систем — теряется. Потому что если стоит задача запустить 1 приложение на 1000 серверов, то это проще сделать обычным способом — через какую-либо систему управления конфигурациями.
Поэтому ответ — нет, я сужу со стороны отдаленной от хостинга. Просто без изоляции гибкость и вообще смысл использования таких сложных систем — теряется. Потому что если стоит задача запустить 1 приложение на 1000 серверов, то это проще сделать обычным способом — через какую-либо систему управления конфигурациями.
А потом навесить сверху балансировку нагрузки, управление пулом воркеров, сбор логов, вотчдоги, а в качестве отдельного бонуса — деплоймент свежей версии.
На самом деле, если надо запустить даже десяток приложений на паре десятков серверов — то всякие PaaS уже нанесут ощутимую пользу, уже даже за счёт унификации инфраструктуры. Если же приложения взаимодействуют друг с другом — то без какой-то платформы будет совсем печально.
На самом деле, если надо запустить даже десяток приложений на паре десятков серверов — то всякие PaaS уже нанесут ощутимую пользу, уже даже за счёт унификации инфраструктуры. Если же приложения взаимодействуют друг с другом — то без какой-то платформы будет совсем печально.
Вы забываете тот момент, что для работы на базе PaaS приложение должно быть переписано с нуля с учетом особенностей платформы. Поэтому не получится унифицировать имеющееся — переписывать с нуля! :) И тут-то встает вопрос «а зачем».
Google ушел от Google Apps Engine к Google Compute Engine, и это — неспроста.
Я не хочу, сказать, что Cocaine — плохо (это наоборот — круто!), я хочу сказать, что такой паттер подходит к от силы десятку-другому компаний в Ру сегменте.
А крупняк — Google, FB и прочие давно живут на контейнерных IaaS с аналогичной системой, правда, они не открытые.
Google ушел от Google Apps Engine к Google Compute Engine, и это — неспроста.
Я не хочу, сказать, что Cocaine — плохо (это наоборот — круто!), я хочу сказать, что такой паттер подходит к от силы десятку-другому компаний в Ру сегменте.
А крупняк — Google, FB и прочие давно живут на контейнерных IaaS с аналогичной системой, правда, они не открытые.
Я же как раз и написал, «зачем». Чтобы не думать об инфраструктуре в каждом из приложений, а сделать её один раз. Вы попробуйте, всё не так страшно, переписывать всё с нуля не надо :) Ну или можно начинать новое писать под PaaS, а старое постепенно вывести из эксплуатации.
А откуда у вас такие знания про гугл и фб? Мне вот от сотрудников гугла доходили сведения, что у них очень даже PaaS под названием borg. А их новая система, про которую в интернете побольше ссылок есть, называется omega.
А откуда у вас такие знания про гугл и фб? Мне вот от сотрудников гугла доходили сведения, что у них очень даже PaaS под названием borg. А их новая система, про которую в интернете побольше ссылок есть, называется omega.
«Чтобы не думать об инфраструктуре», какое-то время назад краем глаза зацепил пост «20 жалоб сотрудников Google». Так вот одна была «дайте мне обычный VPS с MySQL и Linux для прототипа проекта, достал меня Ваш GAE и BigTable!». Честно говоря, не уверен, в 100% правдивости отзыва, но по-моему — показательно.
Про Google и FB все довольно сложно по причине скудности публичной информации, но с другой стороны в сети есть достоверная информация, что они «используют контейнеризацию в основе своих облаков», а вот что там внутри — не известно, по крайне мере я не видел такой информации.
То есть ситация такова, что там IaaS точно есть, а вот наличие PaaS — под вопросом.
Про Google и FB все довольно сложно по причине скудности публичной информации, но с другой стороны в сети есть достоверная информация, что они «используют контейнеризацию в основе своих облаков», а вот что там внутри — не известно, по крайне мере я не видел такой информации.
То есть ситация такова, что там IaaS точно есть, а вот наличие PaaS — под вопросом.
А как вы сделали вывод о том, что IaaS есть из фразы о том, что контейнеризацию используют? В Cocaine вон тоже контейнеры, а никаких виртуалок нету.
www.usenix.org/cluster-management-google
www.youtube.com/watch?v=WbE3wAJCm3I
www.usenix.org/cluster-management-google
www.youtube.com/watch?v=WbE3wAJCm3I
Давайте я расскажу =) 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. Совершенно несложно сделать всё так, чтобы ничего не нужно было переписывать, просто из-за этого не выйдет заимплементить некоторые другие штуки.
Совершенно не важно какими буквами это называть, главное — чтобы разработчики не думали о том, где и как их приложения будут запущены, а просто писали код, используя те инструменты, которые им подходят, а админы не думали о том, как разрешить очередной конфликт из трёх сотен зависимостей. Та же 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 проекта собрать это дело или лучше подождать Ваших (кстати, как раз именного этого бы и хотелось — как можно больше техники!) статей на Хабре?
Попробую найти время, чтобы это дело развернуть в тестовой среде. Реально ли по документации с Git проекта собрать это дело или лучше подождать Ваших (кстати, как раз именного этого бы и хотелось — как можно больше техники!) статей на Хабре?
Документация к последней версии (v0.11) обновилась совсем недавно, так что она самая актуальная и по ней вполне реально самостоятельно развернуть облачко.
Ну и конечно, всегда можно написать нам на рассылку, мы с радостью ответим.
Ну и конечно, всегда можно написать нам на рассылку, мы с радостью ответим.
Ого, поддержка от самого Яндекса :) Спасибо!
Скажу вам по секрету, kobolog — автор Cocaine :) А в рассылочку пишите, или ногами приходите, если будете проездом в Москве. Возможно, в этом году будут какие нибудь субботники с докладами про чудо-технологию в Питере.
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
Ну и докер не обязательно использовать, тогда особо без разницы, какое ядро.
Очень круто. От продуманности решения до описания и картинок. :) Будем использовать.
Для каких задач планируете использовать?
Повышение живучести пользовательских сервисов. Начнем с простого шаринга пользовательских гео-данных, а там посмотрим.
Риквестуем поддержку PHP! Да и можем в коде поучаствовать в принципе… )
Где Яндекс использует Cocaine
В статье есть про это небольшой раздел:
Где Яндекс использует Cocaine
Яндекс.Браузер — весь браузерный бэкэнд работает через Cocaine. Например, “Умная строка”, “Быстрые ссылки”, “Любимые сайты”. Внутренняя инфраструктура Яндекса.
А какой порядок (10/100/1000?) размера кластера на Cocaine?
Яндекс, вы просто боги маркетинга. :)
load balancer всё так же в выпиленном состоянии?
Что употребляли, так и назвали? :)
Спасибо за поддержку языка Go ;)
High End Russian Online Integrated Network Engine
Business Linear Object Java Oriented Builder
Windows HTML-Optimised Resourses
Без этих сервисов трудно представить жизнь в современном IT сообществе. Спасибо Яндексу за идею.
Business Linear Object Java Oriented Builder
Windows HTML-Optimised Resourses
Без этих сервисов трудно представить жизнь в современном IT сообществе. Спасибо Яндексу за идею.
А мне одному показалось странным наличие агрегирующей ноды? Если она падает, то падает все приложение? Или я чего-то не так понял?
RedHat Openshift, поддерживает JavaEE. В Cocaine можно будет развернуть JavaEE приложение?
Где посмотреть пример реализации nodejs-приложения?
На главной странице node.js фреймворка (здесь) есть подробное описание, плюс в каталоге sample есть еще несколько примеров.
В заключение мы рассмотрим более подробно Cocaine’овый протокол и как можно добавить поддержку другого языка, то есть написать собственный фреймворк.
А вот это хотелось бы по-подробнее. Ну или хотя бы линком киньте на ман/примеры откуда можно было бы начать.
А PKGBUILD для арча будет?
А за что минус-то? Я хочу потестить cocaine. Быстрого варианта поставить его у меня нет, кроме как ждать пакет. Ну или ставить под виртуалкой убунту и в ней уже поднимать cocaine. А это время.
А кто отменял
Чтобы сделать PKGBUILD для арча надо сначана изучить, как его делать, а потом сделать билд-ферму под него, чтобы регулярно тестировать сборку. Если у вас есть на это время — you are welcome! Опен сорс же так работает. Перед разработчиками Cocaine не стоит задачи охвата максимального количества разных дистрибутивов.
cmake. && make && sudo make install?
Чтобы сделать PKGBUILD для арча надо сначана изучить, как его делать, а потом сделать билд-ферму под него, чтобы регулярно тестировать сборку. Если у вас есть на это время — you are welcome! Опен сорс же так работает. Перед разработчиками Cocaine не стоит задачи охвата максимального количества разных дистрибутивов.
Я прекрасно понимаю, почему его не делают на текущий момент.
А на ваш
И вопрос могу переформулировать, адресуя его разработчикам. Поддержка ArchLinux в качестве целевой платформы планируется?
А на ваш
make install могу сказать только одно.Если у вас есть на это время — you are welcome! Опен сорс же так работает.
И вопрос могу переформулировать, адресуя его разработчикам. Поддержка ArchLinux в качестве целевой платформы планируется?
И времени, к сожалению, на все не хватает, а так — с удовольствием занялся бы поддержкой для арча.
На счёт make install — cmake_install_prefix поможет, или вагрантовская виртуалка для опытов. Впрочем, тут каждый сам решает, делать ему make install, или не делать, а если делать — то где.
В ближайшее время из новых систем планируется только поддержка новой LTS убунты, которая в апреле выйдет. Основные силы разработчиков направлены на написание новых фич и починку багов. Если у нас получится собрать сборочные стенды с самыми разными популярными линуксами — то их поддержка может появиться, но вряд ли это будет раньше, чем через год, если вообще будет.
В целом же arch — достаточно красноглазый дистрибутив, вероятность появления сборки от поклонников арча далеко не нулевая.
В ближайшее время из новых систем планируется только поддержка новой LTS убунты, которая в апреле выйдет. Основные силы разработчиков направлены на написание новых фич и починку багов. Если у нас получится собрать сборочные стенды с самыми разными популярными линуксами — то их поддержка может появиться, но вряд ли это будет раньше, чем через год, если вообще будет.
В целом же arch — достаточно красноглазый дистрибутив, вероятность появления сборки от поклонников арча далеко не нулевая.
а если в общих чертах сравнить с App Scale , то как пересекается функциональность этих продуктов?
«спавниться»
Поправьте пожалуйста очепятку.
Поправьте пожалуйста очепятку.
Sign up to leave a comment.
Облачная платформа Яндекса. Cocaine