Компания
697,47
рейтинг
27 февраля 2014 в 17:03

Разработка → Свой Cocaine. Облачная платформа Яндекса

Мы уже рассказывали на Хабре про облачную инфраструктуру Яндекса. Сегодня пришёл черёд от слов перейти к делу — мы хотим по шагам показать, как можно развернуть собственное облако на Elliptics и Cocaine.



Схема


Давайте рассмотрим установку небольшого облачка, в котором можно запустить тестовое приложение использующее flask.

Это облачко состоит из следующих элементов:
  • cocaine-runtime, запускающий приложения в Docker;
  • Docker-registry для хранения образов приложений;
  • Elliptics в качестве распределенного хранилища приложений, а также конфигурации облака;
  • агрегирующая нода cocaine-runtime — единая точка входа в облако для клиентского кокаинового кода;
  • HTTP-frontend как альтернативный способ для доступа к приложениям.


На каждом этапе будем проводить проверки, тестирующие успешность выполнения этапа.



Как видно, нам понадобится 5 (можно виртуальных) машинок с ядром не ниже 3.8 для поддержки Docker. Необходимые пакеты можно найти в репозитории.

Как добавить репозиторий
Создадим /etc/apt/sources.list.d/reverbrain.list следующего содержания:
deb http://repo.reverbrain.com/precise/ current/amd64/
deb http://repo.reverbrain.com/precise/ current/all/

Подтянем ключ:
curl -O http://repo.reverbrain.com/REVERBRAIN.GPG
sudo apt-key add REVERBRAIN.GPG

Посмотрим, какие пакеты, относящиеся к кокаину, стали доступны:
apt-get update
apt-cache search cocaine


5 минут на Elliptics


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

В паре команд это выглядит так:
sudo apt-get install elliptics=2.24.14.31 elliptics-client=2.24.14.31
mkdir /tmp/history/ && mkdir /tmp/root
cp /usr/share/doc/elliptics/examples/ioserv.conf  ./tst_ioserv.conf


Далее в tst_ioserv.conf нам придется изменить буквально 3 строки. Итак:
group = 1
addr = localhost:1025:2-0 192.168.50.201:1025:2-1 // здесь подставьте свой IP
indexes_shard_count = 16


После этого запускаем:
dnet_ioserv -c tst_ioserv.conf



Настройка cocaine-runtime + Docker

Приступим к реализации нашего мини-облака с конфигурации машин, непосредственно запускающих код нашего приложения. Ядром инсталляции будет безусловно cocaine-runtime. Также необходимо установить сам Docker и cocaine-plugin для работы с Docker.

Уточню, что хотя наша цель — запустить приложение в docker-контейнере, мы также запустим приложение как обычный процесс.

Контейнеризация — есть благо. Она решает проблемы с окружением для приложения:
  • зависимости всегда с нами;
  • нет конфликтов между зависимостями двух приложений;
  • неизменность окружения в dev, test, prod-средах.

Запуск без контейнера применим и удобен, когда нет зависимостей (например, приложение на go) или технической возможности использовать контейнеры (например, ядро ниже требуемой версии и обновить его нельзя).

После подключения репозитория установим необходимые пакеты:
sudo apt-get install cocaine-runtime libcocaine-core2 libcocaine-plugin-docker2 libcocaine-plugin-elliptics=2.24.14.31 elliptics-client=2.24.14.31



Для управления приложениями нам необходима утилита cocaine-tool. Проще всего ее установить из PyPI — стандартного репозитория Python пакетов.

Необходимо установить биндинг в Python для msgpack.
sudo apt-get install msgpack-python


А затем cocaine-tools.
sudo pip install cocaine-tools


А почему msgpack-python не из PyPI?
Msgpack-python имеет две реализации. Одна «pure-Python», вторая — на Cython. При установке из PyPI делается попытка скомпилировать бинарную версию, а в случае неудачи ставится чистая реализация. Плохо то, что эти реализации несовместимы между собой. Мы брали за эталон Cython версию. Чаще всего какая-то из необходимых зависимостей отсутствует и устанавливается чистая реализация, что — в зависимости от версии — приводит к непонятным ошибкам. Так было не всегда, и возможно ситуация исправится в будущем.


Docker устанавливаем по описанию в официальной документации любым удобным способом. Использован следующий путь:
curl -s https://get.docker.io/ubuntu/ | sudo sh



После успешной инсталяции пакетов cocaine-runtime стартует с дефолтной конфигурацией, которую нам необходимо изменить.
Останавливаем cocaine-runtime и переходим к модификации конфигурации.
sudo service cocaine-runtime stop



Дефолтный файл конфигурации расположен в /etc/cocaine/cocaine-default.conf и выглядит так:
{
    "version": 2,
    "paths": {
        "plugins": "/usr/lib/cocaine",
        "runtime": "/var/run/cocaine"
    },
    "services": {
        "logging": {
            "type": "logging"
        },
        "storage": {
            "type": "storage",
            "args": {
                "backend": "core"
            }
        },
        "node": {
            "type": "node",
            "args": {
                "runlist": "default"
            }
        }
    },
    "storages": {
        "core": {
            "type": "files",
            "args": {
                "path": "/var/lib/cocaine"
            }
        },
        "cache": {
            "type": "files",
            "args": {
                "path": "/var/cache/cocaine"
            }
        }
    },
    "loggers": {
        "core": {
            "type": "syslog",
            "args": {
                "identity": "cocaine",
                "verbosity": "info"
            }
        }
    }
}


Сделаем конфигурацию облачной. Для этого необходимо настроить 2 сущности:
  1. Сконфигурить работу с распределенным стораджем (в нашем примере — Elliptics). Все дело в том, что cocaine-runtime вычитывает из storage список запускаемых приложений, профили запуска приложений, манифесты приложений. Если использовать присутствующий «из коробки» файловый storage, то придется поддерживать консистентность этих данных на каждой ноде, что крайне неудобно. В случае распределенного стораджа этот вопрос решается сам собой.
  2. Заставить runtime сообщать информацию о себе агрегирующим нодам облака.

Для экспериментов удобно модифицировать копию предоставляемого конфига «по умолчанию» (например, /etc/cocaine/cocaine-cloud.conf).

Заставить cocaine-runtime сообщать агрегирующим нодам о запущенных на нем приложениях и сервисах можно, добавив секцию network в конфигурацию на одном уровне вложенности с services.

  "network" : {
        "group": "224.168.2.9"
   },
  "services": {
  ...
  }


Единственный параметр group описывает адрес multicast-группы, в которую будет производиться рассылка оповещений.
Конфигурация storage выполняется модификацией секций services/storage и storages/core:

"storage": {
            "type": "elliptics"
        },
"storages" : {        
"core": {
            "type": "elliptics",
            "args": {
                "nodes" : {
			"192.168.50.201" : 1025
		},
		"io-thread-num" : 8,
		"wait-timeout" : 30,
		"check-timeout" : 60,
		"net-thread-num" : 8,
		"groups" : [1],
		"verbosity" : 2
            }
        }
}


Реализации storage на технологии Elliptics обеспечивается соответствующим плагином. К слову, все плагины из наших пакетов ставятся в /usr/lib/cocaine, где их по умолчанию ищет cocaine-runtime.

Теперь заставим стартовать кокаин с этим конфигом по дефолту. Создаем
/etc/default/cocaine-runtime:
CONFIG_PATH="/etc/cocaine/cocaine-cloud.conf"

Запустим cocaine-runtime с новым конфигом, убедимся в том, что процесс работает.


После запуска на порту 10053 сервис-локатор этой ноды будет ожидать запросов о доступности приложения. Это своего рода DNS для облачных приложений и сервисов, то есть по имени сервиса или приложения вы узнаете куда надо отправлять запросы, чтобы они были обработаны.

Запросить информацию о приложениях на этой ноде можно при помощи команды cocaine-tool info. Вывод этой команды пока не потрясает воображение, но запомните его — совсем скоро он изменится.

Напомним, что помимо cocaine-runtime и плагинов, мы установили Docker. Проверим, что он так же успешно запустился:


Предполагаем, что на второй машине будет проделаны аналогичные действия. Итого мы имеем 2 машинки с запущенным cocaine-runtime, которые смотрят в общий storage — это прекрасно!

В этой точке уже вполне можно запускать приложения. Это, конечно, пока совсем не облако, но все же. Засучив рукава, приступим.

В первую очередь нам необходимо доставить код приложения в кокаиновый storage. Эта задача решается с легкостью при помощи cocaine-tool.

Склонируем репозиторий с примером и перейдем внутрь каталога.
git clone git@github.com:cocaine/cocaine-framework-python.git -b v0.11
cd cocaine-framework-python/examples/flask/



Можно заметить, что помимо кода приложения, здесь расположен manifest.json:
{
  "slave": "main.py"
}


Основная задача этого файла указать платформе, что запускать. Также можно передать environment.

Для загрузки кода приложения, которое хотим запустить как процесс, в облако необходимо выполнить следующую команду:
cocaine-tool app upload --name example

cocaine-tool запакует Ваше приложение в архив и загрузить в облачное хранилище. А потом мы посмотрим список загруженных приложений.



Вот оно, наше приложение! Главное, не забыть установить flask, который требует наше приложение. Вот этот недостаток запуска без контейнера.
sudo apt-get install python-flask


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

Простейший профиль — пустой JSON {}. В этом случае используются параметры по умолчанию.

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

Назовем наш профиль default и загрузим его в облачное хранилище. Проверим, что он загрузился правильно.


Наконец-то настал момент, когда можно дернуть рубильник и приложение запустится:
cocaine-tool app start --name example --profile default



Теперь-то вывод команды cocaine-tool info изменился. В нем показано, какие приложения запущены на данной ноде и статистика о приложениях.

Попробуем послать сообщение в наше приложение. Для этой цели достаточно вот такого небольшого скрипта на питоне:
#!/usr/bin/env python

from cocaine.services import Service
app = Service("example")
print(app.enqueue("write", "DATA").get())
print(app.enqueue("read", "DATA").get())


Приложение все еще запущено только на одной ноде, но можно сходить на вторую и запустить его и там. Теперь можно продолжить строить инфраструктуру для приложений в Docker.

Docker-registry


Docker-registry — это ваше приватное хранилище образов (контейнеров) приложений. Более подробно о нем можно почитать в официальной документации docker.

Docker-registry поддерживает множество бекендов для хранения образов. Ассортимент начинается с записи образов на локальную файловую систему и простирается до хранения образов в Elliptics.

Самый простой способ запустить Docker-registry — это использовать Docker. Для этого нам нужно поставить Docker (смотри выше) и дать команду запусти нужный образ.
sudo docker run -p 5000:5000 registry


Образ registry в первый раз загрузится из репозитория, закэшируется и в следующий раз будет запускаться быстро.

После запуска Docker-registry будет слушать порт 5000. Пингуем его:
curl "http://192.168.50.4:5000/_ping"


На этом настройка завершена.

Сборка и деплой приложения в контейнере


Деплой приложения в случае контейнера будет мало отличаться от «неконтейнерного». Самое главное отличие в том, что для сборки образа необходим Dockerfile. По сути он состоит из набора shell-команд, которые необходимо выполнить для формирования внутреннего состояния образа. После этого образ заливается в Docker-registry.

Далее любой Docker, который хочет запустить контейнер, может загрузить себе образ из registry. Синтаксис Dockerfile, доступные команды можно найти здесь. Вместо Dockerfile вы можете предоставить Chef-рецепт или Puppet-манифест, которые будут выполнены внутри контейнера при сборке.

В профиле для этого приложения необходимо указать тип изоляции Docker. Для этого создадим новый профиль.
{
    "queue-limit": 1000,
    "pool-limit": 10,
    "isolate": {
        "type": "docker",
        "args": {
            "memory_limit": 1000000000,
            "endpoint": "unix:///var/run/docker.sock",
            "registry": "registry.cloud.net:5000",
            "cpu_shares": 0
        }
 
    },
    "concurrency": 200
}

Профиль мы разместили в файле именем docker-profile.json, загрузим его с именем docker-profile
cocaine-tool profile upload --name docker-profile --profile=docker-profile.json


В этом примере мы имеем готовый Dockerfile, и загрузка приложение в облако производиться так:
sudo cocaine-tool app upload --docker=unix:///var/run/docker.sock --registry=registry.cloud.net:5000 --manifest manifest-docker.json --name example-docker --timeout 20000

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


Упущен из виду один момент — о том, какие приложения cocaine-runtime запускает при старте и как узнаёт об этом. Для этого есть runlist. По сути своей этот ассоциативный массив из приложений и их профилей, который cocane-runtime читает при старте. Он располагается, как и профили, в storage. Так как наборы запускаемых приложений на разных нодах облака могут отличаться, то и ранлисты на них могут быть разные. Имя ранлиста указывается в конфиге cocaine-runtime в параметре runlist сервиса node.

Конфигурирование агрегирующей ноды


По сути своей эта часть конфигурации очень похожа на пункт «Настройка cocaine-runtime». Это закономерно, так как в роли агрегирующей ноды выступает cocaine-runtime. Всю работу по балансировке в нем выполняет gateway plugin.

У нас есть две реализации данного плагина. Первая называется adhoc. Она доступна «из коробки» и не требует установки дополнительных пакетов. Вторая реализация, используемая нами в боевых условиях, называется ipvs. Как видно из названия, она использует одноименную технологию. Adhoc разумно применять в случае, когда нет возможности использовать ipvs. И безусловно, можно написать свою реализацию данного плагина, чтобы использовать для балансировки понравившуюся вам технологию.

От слов к делу. Устанавливаем пакеты:
sudo apt-get install cocaine-runtime libcocaine-core2 libcocaine-plugin-ipvs2 libcocaine-plugin-elliptics=2.24.14.31 elliptics-client=2.24.14.31



Если нет возможности использовать ipvs, то последний из приведенных пакетов ставить нет необходимости. Различия в базовой конфигурации будут незначительны и будут указаны отдельно.

Сделать runtime агрегирующей нодой позволит добаление секции network с подсекцией gateway. Предполагаем, что как и прежде, правим копию конфига «по умолчанию». Сервис storage конфигурируем аналогично предыдущему пункту — он скоро понадобится.
    "network": {
        "group": "224.168.2.9",
        "gateway": {
             "type": "ipvs" // adhoc
        }
    },
    "services"...


После перезапуска sudo service cocane-runtime restart должен стартовать процесс:
cocaine /usr/bin/cocaine-runtime --daemonize --configuration /etc/cocaine/cocaine-gateway.conf --pidfile /var/run/cocaine/runtime.pid


На самом деле gateway принимает еще ряд параметров (о них можно прочитать в документации).

Давайте откроем лог (по умолчанию он пишется в syslog). Можно заметить, что было зарегистрировано подключение двух нод, а потом одна из них выключилась. Вы можете проделать аналогичные операции с вашими бекендами и убедиться, что discovery работает.


Cocaine-native-proxy


Cocaine-native-proxy позволяет ходить в облачные приложения по HTTP. Установка и настройка её предельно просты.
apt-get install cocaine-native-proxy


Затем нам необходимо указать список агрегирующих нод в секции locators. В нашем случае такая нода одна. Строго говоря, там можно указать адреса локаторов и нод не работающих в режиме агрегации. Это плохо по той причине, что такая нода ничего не знает о сервисах и приложениях на других нодах, а значит, вы не будете иметь к ним доступ. Более подробное описание параметров можно найти на github.com/cocaine/cocaine-native-proxy/blob/master/README.md
{
    "endpoints": [
        "0.0.0.0:8080"
    ],
    "backlog": 2048,
    "threads": 2,
    "application": {
        "locators": ["192.168.50.103:10053"],
        "service_pool": 5,
        "reconnect_timeout": 180,
        "request_timeout": 5
    }
}


Точка входа в облако в нашей инсталяции — машина с агрегируещей нодой. Несмотря на то, что HTTP интерфейс вынесен наружу через cocaine-native-proxy, на самом деле эта прокси тоже использует агрегирующую ноду. Мы её указывали в конфиге в секции locators. Давайте же попробуем позвать наши приложения двумя способами. HTTP клиент будет использовать обработчик события http, а из клиентского кода на Python обработаем события write и read.

В клиентском коде теперь указывается адрес точки входа в облако. В моем случае — 192.168.50.103.

#!/usr/bin/env python

from cocaine.services import Service
app = Service("example", host="192.168.50.103")
print(app.enqueue("write", "DATA").get())
print(app.enqueue("read", "DATA").get())


В качестве обработчика события http вызывается приложение на flask. Сейчас в HTTP-proxy поддерживается два способа определения того, в какое приложение какое событие послать. Первый способ предполагает, что переданный URL построен по шаблону: ///tail?arg=1&args=2. Соответственно URL обрезается в начале. В приложение он поступит в виде /tail?arg=1&args=2. Это очень простой и примитивный способ.

При втором способе решение принимается на основе специальных заголовков X-Cocaine-Service, X-Cocaine-Event. Их можно проставлять при помощи nginx.

Таким образом, следующие два запроса попадают в одинаковые обработчики:
curl "http://localhost:8080/read" -H "X-Cocaine-Service: example" -H "X-Cocaine-Event: http"
curl "http://localhost:8080/example/http/read"


Балансировка между версиями приложения



Наше облако позволяет запускать одновременно несколько версий одного приложения и производить балансировки нагрузки между ними. Идея заключается в том, что мы объединяем несколько приложений в группу и назначаем им веса в рамках этой группы. Таким образом доступ к приложениям будет осуществляться не по имени приложения, а по имени группы. А в рамках группы выбор будет сделан исходя из веса. Это очень полезная возможность. Располагая ей, можно вводить новые версии приложений в облако, подавая на них лишь часть нагрузки (скажем, 5%). А затем увеличивая эту долю. При этом можно не удалять предыдущую версию приложения. Ведь в случае обнаружения бага в новой версии, можно так же легко вернуть нагрузку обратно, выполнив при этом лишь небольшое число команд.

Попробуем воспроизвести этот процесс. Для этого создадим группу для приложения example, скажем exampleGroup. Добавим в неё приложение example с весом 1000. И попросим ноду обновить списки групп. В логах это видно будет по записи
service/locator: adding group 'exampleGroup'



После этого то же самое приложение будет доступно по имени exampleGroup. Для того чтобы проверить, предлагаю изменить тестовое приложение, заменив в app.py приветствие в ручке hello:

@app.route('/')
def hello(name=None):
    return "HELLO! I'm version #2"


Затем зальём это приложение и запустим его и отредактируем роутинг группу, добавив приложение example2.


Если подергать приложение
curl "http://localhost:8080/exampleGroup/http/"


То можно заметить, что ответы от разных версий чередуются. Если выставить вес example2 равным 0, то нагрузка на него через HTTP-proxy перестанет идти через некоторое время. Оно характеризуется периодом, через который HTTP-proxy обновляет соединения до приложений. Используя клиентский код, изменения заметите сразу.

Вместо заключения


Вот так легко и быстро, как опытный повар готовит спагетти, мы приготовили кокаиновое облако. Теперь при наличии инфраструктуры хочется рассказать о том, как писать приложения для Cocaine на различных языках, как писать свои cервисы, как сделать фреймворк. Но об этом в другой раз.
Автор: @noxiouz
Яндекс
рейтинг 697,47

Комментарии (65)

  • 0
    А сервис не попадает на учет Роскомадзора? За распространие Cocaine то?
    • 0
      Вот да, Мизулина уже взялась за Яндекс.Браузер, а как узнает что в нем еще и Cocaine есть — ух, что начнется!
    • +6
      Замечу, что Cocaine не сервис, а технология.
      • +2
        Воистину. Вы правы, просто на языке крутилось выражение «Облачный сервис».
  • 0
    Ну теперь-то хабр точно закроют.
  • +2
    Уже представляю, как принесу бухгалтеру счет на оплату кокаина.
    • +3
      этот кокаин бесплатный.
      • +11
        Почти чувствую себя рок-звездой!
  • +15
    — Как работает ваш сервис?
    — Ну знаете, это как-бы облако и оно сделано из кокаина…
    • –2
      Хорошо хоть это облако не повторяет форму Украины.
  • +11
    Передайте от меня огромный респект Вашему графическому редактору!
    • +1
      Наверное у меня проблема с восприятием, но я долго тупил в картинку, да она наверное красивая, но понимания не добавила совсем.
      Но ясно показала кашу в голове этого самого дизайнера, или наличие веществ…
      Что-то куда-то подключается замешивается на кокаине, переключается и соединяется, иии вот результат.
      • +1
        Я про графический контент во всей серии статей в совокупности.
  • +22
    Я уже жалею что Яндекс обозвал это все кокаином. Не потому, что наркотики и все дела, а потому что горе-шутники хабра под каждым постом начинают извергать из себя шутки в стиле «хаха, кокаин, роскомнадзор, вы что курили?»
    • –1
      Уверен что Яндекс знал на что шел, когда так называл свою технологию.
      • 0
        Возможно это запланированный тролинг
    • +2
      это хороший повод посмотреть, кто адекватен, а кто нет :)
      • +1
        То есть сначала дать технологии название на грани фола, а потом негодовать почему так много внимания уделяется названию — адекватность?
        • +5
          Ну если отвечать лично за себя — да, это хороший индикатор тех, кто адекватный. если человек не может/не хочет понимать суть, но озабочен высказыванием своего мнение и думает, что это кому-то важно, это да, индикатив :)
    • +9
      Вы же тоже знали, на что шли, выбирая никнейм на Хабре :)
      • –1
        Конечно знал, это уже не первый мой никнейм с отвратительным смыслом и юзерпиком :) Так проще получить бейджик «Тролль».
  • 0
    Вот как я буду представлять эту облачную технологию своим коллегам/боссам — «Let's switch to cocaine!»?
    • +5
      Вы так говорите, как будто в этом есть что-то плохое.
  • +4
    Наконец-то! Давно ждал эту статью. Несколько раз уже пытался собрать кокаин. Все никак не получалось. То части зависимостей не достает, то компилятор с ошибками валится. (собирал на разных версиях убунты под докером)
    • +4
      Мы всегда стараемся ответить на вопросы. Так что спрашивайте, если что.
      • +1
        Спасибо.
        Сразу вопрос номер раз:
        Описанное в статье реально развернуть на пяти контейнерах в докере?
        Или лучше отдельные виртуалки в virtualbox заводить?
        Кстати, совсем круто было бы, если бы вы опубликовали линки на уже настроенные образы (*.ovf) виртуалок.
        • +3
          Я разворачивал это на пяти вируталках с помощью Vagrant. Это были голые виртуалки, чтобы описывать реальный процесс установки и ничего не забыть. Box для Vagrant с precise и нужным ядром можно взять отсюда repo.reverbrain.com/vagrant-base/. Главное, чтобы multicast бегал между виртуалками и ядро было подходящее. А насчет запустить каждый элемент внутри контейнера — можно попробовать, получится здорово. Главное иметь ввиду неизменяемость контейнеров и пробрасывать внешние директории внутрь. Например, чтобы каталог, где Elliptics хранит данные, был проброшен с реальной машины, иначе после рестарта данных не будет.
          • 0
            Ну для тестов это и хорошо, что данных не останется.
  • +3
    А почему на первой картинке между программистом и облаком есть кот, а на второй его уже нету. С ним всё хорошо?
    • +1
      Безусловно да! За спиной программиста есть диванчик и котик пошел полежать.
    • +11
      Человек и кошка плачут у окошка
      Серый дождик каплет прямо на стекло.
      К человеку с кошкой едет неотложка,
      Человеку бедному мозг больной свело…
      • +4
        Yandex едет, едет сквозь снежную равнину,
        Cocaine целебный людям он везёт.
      • +1
        Мне из творчества этого автора больше нравится песня про индейца =) Без подтекста
    • +5
      На первой картинке и с перспективой косяк: облако висит над подоконником, а дождь идёт на улицу. Значит ли это, что данные будут сливаться наружу?
    • +1
      Заметьте, что человек успел переодеться за время смены картинки. Кроме того, на первом рисунке у него на столе какие-то банки, и у человека руки на клаве. На второй картинке банок уже нет и человек держится за стол.

      Что с ним случилось?
  • +1
    Взрыв мозга.
  • +2
    Планируется ли cocaine-сервис? Возможно независимо от яндекса? Может хотя бы в демо-режиме?
  • 0
    Субъективно, все-таки сложновато это поднять, много шагов.
    Немного смущают 2 вещи.
    1) Я, наверное, запутался, но для деплоя надо каждый раз грузить новый контейнер целиком на сервер или он там как-то diff делает? Просто контейнер с ubuntu неплохо так весит — порядка 700 мегов.
    Почему просто не используете git push, как на Heroku?
    2) Все это заведется без Elliptics? С еще одним key-value store не тянет разбираться, хватает уже существующих. Было бы круто посмотреть, как это будет работать с чем-то более обыденным в отдельном контейнере, например, с Redis.
    А в целом, отличное начинание.
    • +1
      1) Docker собирает контейнеры слоями. Например, базовый слой — ubuntu, второй слой python, третий слой конфиги, четвертый слой статика и тд. Подтягиваются только слои, начиная с измененного. Если ничего не изменили в первом и втором слое, то будут отдельно загружены только слои 3 и 4.
      Что касается git push, то мы работаем на этим. Однако, чтобы получить полностью желаемый контейнер, желательно сделать Dockerfile (или Chef/Pupper). Безусловно Heroku, определив язык вашего приложения, попытается выполнить установку зависимостей. Но при этом поставить бинарные зависимости для python не может.
      2) У нас нет плагина, чтобы обеспечить поддержку Redis. Но его можно сделать.
  • +2
    Ребята спасибо за пост и за то что делаете вообще.
    Очень хочется прочитать про dev окружение и отладку в нем:
    Как это все поднимать на dev тачке?
    как оперативно и без геммороя отлаживать?
    • 0
      Быстро поднять dev себе на ноутбуке можно используя vagrant github.com/cocaine/cocaine-vagrant/tree/v0.11. Самый быстрый способо получить dev.
      Можно про второй вопрос чуть шире? Потому как подходы к отладке они разные в зависимости от кода. Кому-то нужен DTrace для Nodejs, а так и gdb внутри койнера запускали в аттачились к запущенному воркеру.

      Из стандартных средств: всегда есть логи, корки. Насколько мне известно, в некоторых очень крупных облаках, набор тот же.
      • 0
        Да вот к примеру я хочу написать приложение для кокаина которое работает с eliptics с postgresql и еще с парачку сервисами из cocaine вот как это все дело отлаживать в dev окружении.
        Понятно что писать код, пушить его в «dev» инфраструктуру и отлаживать там не очень удобно.
        • 0
          Учитывая то, что eliptics вы будете дергать через тот же cocaine клиент, а postgresql через родной драйвер. То не важно где и как выполняется ваш код. Можно отладить максимально большую часть без загрузки его в облако. И только потом уже начинать тестирование там. Ведь по сути своей это все обычные приложения, некоторые моменты можно заменить заглушками. А там уже логирование.
          • 0
            Это все понятно, но если приложение сложное и надо прогнать всю связку, тут придется попотеть.
            Вот к примеру у django+celery можно поднимать командой инфраструктуру у себя на машине, вот если-бы такая возможность была, было бы гораздо проще.
            • 0
              Да, но по мне так тут будет оправдан Unix-like подход, законченные небольшие приложения, выполняющие одну задачу, а не сложные GodApp. И стартуют быстрее, и точек отказа меньше. Но это все вопрос архитектуры.
              • 0
                Согласен, это true-way, но к сожалению есть legacy код, либо рефакторить-разносить, либо как-то подружить.
                Вариант с подружить гораздо интереснее :)
  • 0
    Вот вы пишете про балансировку между версиями приложения. Просто разбрасывая по весам. Но это какой-то выраженный случай.
    Умеет ли ваш балансер запоминать пользователя? Что бы дальше его уже на определенную ноду кидать.
    • 0
      Кидать на определенную ноду нет смысл, так как воркеры это сущности без состояния.

      Но можно сделать больше. Можно написать приложение-балансировщик. Так как из одного приложения, легко звать другое, то реализуемо следующее. Вы можете анализитровать приходящий запрос как угодно, использовать любую информацию из него, принимать решение на основе любой логики, которую сами напишите. Например, анализируя содержимое хедеров (если речь, про HTTP). Это достаточно гибко.
  • 0
    1) Docker собирает контейнеры слоями. Например, базовый слой — ubuntu, второй слой python, третий слой конфиги, четвертый слой статика и тд. Подтягиваются только слои, начиная с измененного. Если ничего не изменили в первом и втором слое, то будут отдельно загружены только слои 3 и 4.
    Что касается git push, то мы работаем на этим. Однако, чтобы получить полностью желаемый контейнер, желательно сделать Dockerfile (или Chef/Pupper). Безусловно Heroku, определив язык вашего приложения, попытается выполнить установку зависимостей. Но при этом поставить бинарные зависимости для python не может.
    2) У нас нет плагина, чтобы обеспечить поддержку Redis. Но его можно сделать.
  • 0
    Какие проблемы с изоляцией контейнеров существуют по сравнению с полностью изолированными виртуальными машинами?
    • 0
      а что понимается под полностью изолированными виртуалками? KVM?
  • +1
    Будет ли репозиторий под Debian?
    • +1
      Скорее всего нет, потому как мы его не используем. Но если запросов будет много, то постараемся что-нибудь придумать.
      • 0
        На 14.04 после ее выхода пакеты в какое-то обозримое время появятся или года через два? :)

        Я почему спрашиваю — для 13.10 собираю пакеты самостоятельно, в принципе, это не трудно, но вот с grape, например, проблемы, а без него не заводится historydb… Пичаль-пичаль.
        • 0
          мне не удалось обнаружить зависимость от grape в historydb. Можно больше подробностей?
          • +1
            В исходниках то может и нет.

            github.com/reverbrain/historydb

            Firstly, __complete__ elliptics tutorial. It is __neccessary__ to start work with elliptics.


            Идём туда…

            Build from source

            Eblob
            Elliptics
            Cocaine Core
            Cocaine Framework Python
            Cocaine Framework Native
            Swarm
            Grape


            Дисциплинированный читатель, привыкший к тому, что документацию надо читать, а не проглядывать по диагонали, поймет это именно так, а не иначе.

            Да и какая разница, по большому счету, нужен ли Grape именно для HistoryDB или сам по себе. Все равно ведь ломается (это для cocaine-core достаточно просто CMakeLists.txt подправить). Я сейчас даже не уверен, что по пути к концу tutorial'a ломается именно Grape, а не Swarm. Завтра прогоню билд и напишу точнее.
          • 0
            В общем да, память подвела, grape там не нужен.

            Нужны

            1. swarm (который собирался тоже не без приключений)
            2. fastcgi-daemon2 — исходники которого надо еще гуглить. Cлава богу, хоть находятся в странном месте github.com/golubtsov/Fastcgi-Daemon

              В этом ваша в Яндексе главная беда, все поразбросали по разным местам, половина вон на github.com/reverbrain/, другая половина на github.com/cocaine/, документация то там, то здесь, то еще вон там, частенько друг другу противоречит, пока разберешься, где свежее, где старье, на которое давно забили, а удалить руки не дошли… Ради бога, сложите всё на reverbrain, раз уж завелось специальное место и более менее живое. Остальное удалите нафиг, чтобы не гуглилось и не запутывало людей.


            3. В общем, historydb не собирается даже на precise… gist.github.com/cadmi/5e037df4c8e23bce552a
            • 0
              ответственные лица говорят, что зачинили. Попробуйте, пожалуйста!
  • 0
    А как дела обстоят с websocket в cocaine?
    Т.к. это постоянные соединения, то наверное должна быть какая-то прокся которая грамотно могла бы разруливать соединения с end-point-ами, или как-то еще.
    • 0
      На данный момент никак, тк не было необходимости. Можно написать проксю, которая с клиентской стороны слушает ws, и заворачивает сообщения в приложения. По сути это та же HTTP прокси, что есть сейчас -только снаружи способ взаимодействия другой. Если есть C++ библиотека для работы с ws, то можно добавить эту возможность в native-proxy github.com/cocaine/cocaine-native-proxy или написать свою на другом языке. Будем рады пул-реквесту! =) Готовы обсуждать.
  • 0
    А постоянные соединения поддерживаются в github.com/cocaine/cocaine-native-proxy?
    Я про HTTP/1.1? Тогда можно было-бы через постоянные соединения поднять сервис с wsgi интерфейсом и через него гонять websocket
    Или как-то возможно пробрасывать HTTP/1.1 через, к примеру, nginx?
  • 0
    Спустя время решил таки попробовать собрать окружение для теста, но все никак не получается завести вариант с Docker, выдает ошибку:
    cocaine-tool app start --name example-docker --profile default-docker
    {
        "example-docker": "1:086d9b704ba9...a16f0408ea8c: Failed to process READ command: No such file or directory: -2"
    }
    


    При этом заливка приложения происходит корректно (никаких ошибок не выдает).
    • 0
      А можно мне вывод следующих команд, пожалуйста:
      cocaine-tool app list
      cocaine-tool app view --name example-docker
      cocaine-tool profile list
      cocaine-tool profile view --name default-profile

      Можно в личку)

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

Самое читаемое Разработка