Локальное развитие мезосферы

В настоящее время я изучаю использование Mesosphere в производстве для запуска нескольких микросервисов в качестве контейнеров Docker.

Я выполнил развертывание DCOS и смог успешно запустить одну из служб. Однако, прежде чем продолжить этот подход, мне также необходимо охватить сторону разработки (не самого Mesos или Mesosphere, а развитие микросервисов).

Существуют ли какие-либо передовые методы запуска локального развертывания Mesosphere в Vagrantbox или что-то подобное, что позволило бы нашим разработчикам запускать все сервисы, которые есть в нашей экосистеме, из существующих образов докеров и запускать один сервис, над которым вы сейчас работаете? из локальной папки кода?

Я уже знаю, как связать папку кода разработчиков с машиной Vagrant, а также должен запустить часть Docker, но я все еще немного потерял всю часть интеграции Mesosphere.

Есть ли кто-нибудь, кто мог бы перенаправить меня на какой-нибудь ресурс в Интернете, описывающий возможное решение этой проблемы? Кто-нибудь из вас делал что-то подобное и хотел бы поделиться некоторыми мыслями по этому поводу?


docker vagrant mesos mesosphere dcos
person Tim Specht    schedule 19.02.2016    source источник

Ответы (2)


arrow_upward
4
arrow_downward

Сник Пик

Mesosphere активно работает над улучшением взаимодействия разработчиков с DCOS. Часть этих усилий включает работу над локальным кластером разработки, чтобы помочь разработчикам приложений, служб и пакетов DCOS. Однако решение еще не совсем готово для прайм-тайма. Тем не менее, мы начали предоставлять ранний доступ избранным клиентам DCOS Enterprise Edition. Если вы хотите узнать об этом больше, обратитесь к своему торговому представителю или свяжитесь с отделом продаж через наш веб-сайт: https://mesosphere.com/contact/

Общедоступные инструменты

Тем не менее, уже существует множество различных инструментов, которые могут помочь при разработке фреймворков Mesos или приложений Marathon.

Многозначность

Обновление 2017-08-03

Два рекомендуемых в настоящее время варианта локальной разработки для DC/OS:

person KarlKFI    schedule 20.02.2016

arrow_upward
1
arrow_downward

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

Моя компания, например, использует не DCOS, а обычный кластер Mesos с кластерными планировщиками Marathon и Chronos. У нас есть три среды, каждая из которых работает под управлением CoreOS и Mesos/Marathon (в разных версиях, чтобы иметь возможность протестировать обновление версии и т. д.):

  • Локальные кластеры Vagrant для наших разработчиков для локальной разработки/тестирования (можно настроить для использования разных версий CoreOS/Mesos/Marathon на основе файлов user_data)
  • Тестовый кластер (виртуализированный, последняя бета-версия CoreOS, последняя версия Mesos/Marathon/Chronos)
  • Рабочий кластер (голое железо, последняя стабильная версия CoreOS, в настоящее время Mesos 0.25.0 и Marathon 0.14.1)

В нашем цикле сборки используется сервер сборки (в нашем случае TeamCity, Jenkins и т. д. также должны работать нормально), который создает образы Docker и отправляет их в наш частный репозиторий Docker. В этом процессе изображения помечаются автоматически.

У нас также должна быть возможность автоматически запускать их через вызовы Marathon API к кластеру, определенному в самой сборке, или они могут быть развернуты разработчиками вручную. Таким образом, обновленные образы Docker извлекаются из нашего частного репозитория Docker (обязательно используйте "forcePullImage": true, чтобы получить последнюю версию, если вы не используете определенные теги изображений).

Видеть

person Tobi    schedule 20.02.2016
comment
Большое спасибо за информацию, Тоби! Еще один вопрос: как вы справляетесь с одним разработчиком, активно работающим над одним микросервисом, в зависимости от других в среде? Это потребует от разработчика внедрить свой рабочий код в марафонское задание, работающее внутри mesos, верно? - person Tim Specht; 22.02.2016
comment
Не уверен, правильно ли я вас понял... Вы имеете в виду, что разработчик работает над одним сервисом, который зависит от других/является частью приложения? - person Tobi; 22.02.2016
comment
Да, именно так! Таким образом, локальный кластер mesos будет запускать несколько сервисов из образов контейнеров, созданных CI, и разработчик будет активно работать над другим сервисом непосредственно со своей машины, которая использует эти контейнеры, созданные CI. - person Tim Specht; 22.02.2016
comment
Что ж, если вы запускаете это через Marathon, это означает, что вам сначала нужно собрать Docker-образ соответствующего сервиса, а затем просто запустить (уничтожить старую версию приложения Marathon и создать новую версию через API) новую версию приложение. - person Tobi; 22.02.2016
comment
Я знаю, и это сильно снизит скорость разработки. Поэтому я подумал, что можно напрямую запустить марафонский сервис из кода без предварительного создания образа. Как вы это делаете? - person Tim Specht; 22.02.2016
comment
Я думаю, вам нужно будет собрать образ Docker, потому что необходимо распространять артефакт. Есть (по крайней мере) два способа: Для локальных сборок Docker с использованием сценариев bash: 1) Локальная сборка образа Docker 2) Отправка в частное репо 3) (Повторный) запуск приложения Marathon с помощью вызова curl. Для сборки CI: 1) Отправить в репозиторий Git/SVN 2) Сервер CI создает и отправляет образ Docker в частный репозиторий Docker 3) Ручной перезапуск приложения Marathon - person Tobi; 22.02.2016