Типичная установка выглядит так.
На машинках, обозначенных Node, работает процесс cocaine-runtime, внутри которого работают сконфигурированные сервисы. Также на этих машинках поднят docker.
На LoadBalancer работает nginx, cocaine-http-proxy, cocaine-runtime с плагином IPVS-gateway.
Отдельный кластер с elliptics storage.
На DockerRepository поднят репозиторий докера с еллиптикс-бекендом для хранения образов.
На Dockerbuild сконфигурирован пользователь ape, куда происходит git push приложений. Здесь поднят докер, здесь происходит билд приложений, отсюда раздаются команды на запуск, отсюда контейнеры с готовыми приложениями push'атся в docker репозиторий.
В кластер ElasticSearch записываются логи приложений, сервисов, рантайма и всего.
На этой машинке запущен cocaine-runtime со сконфигурированными сервисами. Обязательные сервисы — node, logging, storage.
По команде app_start(app_name, profile_name) сервис node получает из
стореджа манифест приложения и профиль. В профиле описан тип изолята
приложения, сервис node делает isolate->spool(), который, в случае с
докером, делает docker pull образа приложения, после чего контейнер
приложения готов к запуску.
Создается invocation service для данного приложения, с именем, совпадающим с именем приложения, публикуется на назначенном порту, и locator отправляет данные о запущенном приложении всем, кто раньше вызвал по RPC метод locator synchronize. Таким образом металокатор получает оповещение о запущенных приложениях.
Когда в invocation service приходят enqueue сообщения для приложения, invocation service создает сообщения в очередь приложения на данной ноде кластера. Engine поднимает воркеры приложения, и передает в них через pipe месседжи. Полученные от приложения месседжи он проксирует обратно клиенту, приславшему enqueue.
Здесь запущен cocaine-runtime с металокатором. Металокатор слушает анонсы поднявшийся нод в сконфигурированной мультикаст-группе, при получении аннонса вызывает synchronize в локаторе поднявшейся ноды, и в ответном бесконечном стриме получает info запускающихся приложений на соответствующей ноде. При получении info нового приложения locator добавляет в IPVS виртуальный сервис с именем приложения, и добавляет real-маршрут в таблицу IPVS, который указывает на поднявшееся приложение.
Когда клиент спросит у металокатора адрес сервиса, например storage, металокатор отдаст адрес виртуального (IPVS) сервиса, и когда клиент законнектится по этому адресу, IPVS направит пакеты на один из real-сервисов, который был ранее добавлен в этот virtual service при помощи IPVS-плагина.
Cocaine-http-proxy, запущенный на LoadBalancer, принимает http-запросы, упаковывает http-запрос в enqueue-message, и, как cocaine-client, отправляет это сообщение в virtual-service соответствующий приложению.
Cocaine-http-proxy поддеривает несколько соединений к каждому virtual-сервису. Это позволяет работать балансировке между версиями приложения: перед открытием соединения в virtual-service прокси вызывает resolve имени сервиса в локаторе.
Ресолв имени в локаторе задействует механизм роутинг-групп, и каждый ресолв возвращает определенную версию приложения из роутинг-группы с учетом весов версий приложений.
Поэтому, чтобы изменение веса версии отражалось на распределении запросов по версиям, proxy должна поддерживать пул из сравнительно большого числа соединений к приложению (на практике это может быть 20-60 соединений), и периодически их обновлять, каждый раз делая ресолв через металокатор.
Хранит построенные контейнеры приложений. В качестве хранилища образов использует elliptics.
Машинка, на которой выполняется билд образов, и на которой находится управляющая консоль.
Обычный Elliptics сторедж. Здесь все просто.
Сюда складываются все логи, и отсюда же забираются. Taillog ходит в любую из нод кластера, и получает апдейты логов.