Comments 28
Начал читать и подумал — а идея правильная, SD сейчас актуален в больших сервисах, интересно как они это предлагают…
Но по ходу чтения статьи совершенно не понял в чем преимущество перед системами оркестрации. Нам нужно поменять некоторые параметры в конфигах для 20 серверов, скажем. Причем, не все сразу, а по-очереди, сначала на базах, а потом на веб-серверах. Как нам тут поможет Consul и почему в нем это будет проще?
Представим, что у нас есть сервис с 2000 серверов и уже настроен, скажем, Zabbix с локальными агентами, которые проверяют состояник сервисов. Нам теперь еще надо для каждого сервиса написать конфиг для Consul, который будет делать то же самое?
На мой взгляд такие системы были бы удобнее не как отдельный сервис, а как библиотека, встраиваемая непосредственно в код — особенно для самописных сервисов.
Но по ходу чтения статьи совершенно не понял в чем преимущество перед системами оркестрации. Нам нужно поменять некоторые параметры в конфигах для 20 серверов, скажем. Причем, не все сразу, а по-очереди, сначала на базах, а потом на веб-серверах. Как нам тут поможет Consul и почему в нем это будет проще?
Представим, что у нас есть сервис с 2000 серверов и уже настроен, скажем, Zabbix с локальными агентами, которые проверяют состояник сервисов. Нам теперь еще надо для каждого сервиса написать конфиг для Consul, который будет делать то же самое?
На мой взгляд такие системы были бы удобнее не как отдельный сервис, а как библиотека, встраиваемая непосредственно в код — особенно для самописных сервисов.
Ну, во первых Consul — это не замена для систем оркестровки — это разные вещи. Определенно одна из причин Вашего недовольства очень проста: это попытка натянуть на текущую спроектированную и отлаженную систему Consul и попытаться его как-то использовать. Да — это ни к чему хорошему не приведет, скорее даже наоборот — добавит массу неудобств и «костылей» чтобы все это запустить.
Внедрение Consul и SD больше подходит для систем которые находятся в состоянии начального проектирования, либо для таких, архитектура которых себя исчерпала и требуется рефакторинг (читай перепроектировать систему и переделать ее компоненты).
В примере с Zabbix-ом — тоже разночтение: Consul использует health-check проверки для того, чтобы дерегистрировать сервис, который более не может выполнять свои функции и не может быть больше использован другими компонентами системы. Consul ни в коем случае не заменит мониторинговую систему.
Внедрение Consul и SD больше подходит для систем которые находятся в состоянии начального проектирования, либо для таких, архитектура которых себя исчерпала и требуется рефакторинг (читай перепроектировать систему и переделать ее компоненты).
В примере с Zabbix-ом — тоже разночтение: Consul использует health-check проверки для того, чтобы дерегистрировать сервис, который более не может выполнять свои функции и не может быть больше использован другими компонентами системы. Consul ни в коем случае не заменит мониторинговую систему.
Consul: Прощайте конфигурационные файлы.
SD позволяет существенно упростить этот процесс (как именно, пытливый читатель уже думаю догадался)
Вот на этом месте и возникли вопросы. Не могли бы вы подробнее рассказать, чтобы не было недопониманий?
Если это разные вещи, то зачем вы их сравнивали?
Если вы имели в виду отказ от конфигов с помощью авторегистрации в коде — то да, в своем коде мы можем это сделать и это было бы очень удобно. Но что там про mongodb и кластер?
Не хотелось бы превращать обзорную статью в полноценный гайд по использованию SD. Но можно попробовать кратенько. Итак методология простенького сценария такова:
1. запускаем MongoDB и регистрируем ее в Consul
2. запускаем микросервис(ы) который использует MongoDB как хранилище. Сервис вместо того, чтобы лезть в свой конфиг-файл (где указано системой оркестровки адрес MongoDB сервера и его порт), делает запрос в Consul (по ссылке localhost:8500/v1/catalog/service/mongo-db) и получает данные о том, куда ему подключаться.
3. проходит некоторое время и MongoDB сервер меняет хост (достаточно частый случай для облачных сред, Mesos кластеров и прочих IaaS сервисов; и удержимся от описания того, как данные будут мигрировать)
4. В обычных случаях (без SD), начинаем: zabbix рапортует о том, что монга умерла, запускаем оркестратор — генерим новую монгу, генерим куче сервисов новый конфиг файл с атрибутами коннекта к новой монге, перезапускаем их. В случае с SD, приложение получает connection drop с сервером MongoDB и переходит в состояние некое состояние standby во время которого периодически опрашивает Consul на предмет регистрации нового инстанса MongoDB. Получив данные о регистрации — переподключается.
Очевидная выгода в том, что не используются сторонние по отношению к системе компоненты (системы мониторинга и оркестровки, — но я не призываю не использовать их вообще), сервисы не рестартуют продолжая выполнять какие-то запросы не зависящие от наличия подключения к MongoDB, и таки — отсутствие конфигурационных файлов (не в общем как таковых, но в данном конкретном случае можно без них).
В любом случае — интеграция Consul это не просто «поставил-настроил-работает», — это серьезный архитектурный шаг и не факт, что он подойдет в любом случае.
1. запускаем MongoDB и регистрируем ее в Consul
2. запускаем микросервис(ы) который использует MongoDB как хранилище. Сервис вместо того, чтобы лезть в свой конфиг-файл (где указано системой оркестровки адрес MongoDB сервера и его порт), делает запрос в Consul (по ссылке localhost:8500/v1/catalog/service/mongo-db) и получает данные о том, куда ему подключаться.
3. проходит некоторое время и MongoDB сервер меняет хост (достаточно частый случай для облачных сред, Mesos кластеров и прочих IaaS сервисов; и удержимся от описания того, как данные будут мигрировать)
4. В обычных случаях (без SD), начинаем: zabbix рапортует о том, что монга умерла, запускаем оркестратор — генерим новую монгу, генерим куче сервисов новый конфиг файл с атрибутами коннекта к новой монге, перезапускаем их. В случае с SD, приложение получает connection drop с сервером MongoDB и переходит в состояние некое состояние standby во время которого периодически опрашивает Consul на предмет регистрации нового инстанса MongoDB. Получив данные о регистрации — переподключается.
Очевидная выгода в том, что не используются сторонние по отношению к системе компоненты (системы мониторинга и оркестровки, — но я не призываю не использовать их вообще), сервисы не рестартуют продолжая выполнять какие-то запросы не зависящие от наличия подключения к MongoDB, и таки — отсутствие конфигурационных файлов (не в общем как таковых, но в данном конкретном случае можно без них).
В любом случае — интеграция Consul это не просто «поставил-настроил-работает», — это серьезный архитектурный шаг и не факт, что он подойдет в любом случае.
localhost:8500/v1/catalog/service/mongo-db
Этот запрос же только сервис вернёт, без состояния. Я бы порекомендовал отправлять запрос сюда: localhost:8500/v1/health/service/mongo-db?passing
Вернёт список всех инстансов mongo-db, которые прошли хелс чек.
Отличное замечание. Можно и так, однако мне кажется, что предпочтительнее принудительно дерегистрировать сервис не прошедший health check, во избежание накопления мусора в Consul.
Зависит от ситуации. У нас часть сервисов сами о своём состоянии сообщают консулу, используя /v1/agent/check/fail/, /v1/agent/check/warn/ и /v1/agent/check/pass/. Когда сервис слишком нагружен, он меняет свой стейт на fail или warn, тогда к нему временно не будут приходить новые запросы. Позже он опять обновит стейт на pass.
>Не хотелось бы превращать обзорную статью в полноценный гайд по использованию SD. Но можно попробовать кратенько. Итак методология простенького сценария такова:
Я бы хотел лично увидеть и гайд нормальный и примеры под которые консул будет хорошо использовать. Да и примеры где его не надо использовать.
Я бы хотел лично увидеть и гайд нормальный и примеры под которые консул будет хорошо использовать. Да и примеры где его не надо использовать.
Дело в том, что Вы не найдете гайдов по Consul — весь гайд это описание API и пара несложных примеров его использования. Да и не может быть гайдов в принципе (равно как и условий в которых можно использовать только Consul) и причина этого очень проста: Consul это не самостоятельный программный продукт, а один из строительных кирпичиков MSA (при чем не обязательно незаменимый). Consul достаточно трудно натянуть на уже работающую систему без структурных изменений ее архитектуры, мало того — многим системам совершенно и не нужны микросервисы, SD и все, что с этим связано. Но, если Вы системный архитектор и в данный момент проектируете систему которая должна легко масштабироваться, быстро разрабатываться и меняться под новые потребности, — без подходов заложенных в MSA Вам вряд ли обойтись. И вот тут уже приходит на помощь Consul — как часть микросервисной архитектуры отвечающая за SD компонентов.
Как таковым гайдом/примером использования может служить полное описание распределенной системы использующей Consul, но подобное описание вряд ли разрешат предоставить владельцы таких систем.
Как таковым гайдом/примером использования может служить полное описание распределенной системы использующей Consul, но подобное описание вряд ли разрешат предоставить владельцы таких систем.
Судя по описанию, у меня сложилось впечатление, что это замена DNS / DynDNS
1. запускаем с DynDNS агентом, создаём ДНС запись.
2. в конфиг файле указываем доменное имя, и делая ДНС запрос получаем адрес.
3. при миграции доменное имя тоже меняется.
4. всё тоже самое, только меняем консул на ДНС.
Вы, наверное, про что-то забыли сказать.
1. запускаем с DynDNS агентом, создаём ДНС запись.
2. в конфиг файле указываем доменное имя, и делая ДНС запрос получаем адрес.
3. при миграции доменное имя тоже меняется.
4. всё тоже самое, только меняем консул на ДНС.
Вы, наверное, про что-то забыли сказать.
Используем Consul для сервис дискавери на своих серверах. Пока никаких проблем не было. Три мастера + клиент на каждой машине. Хелс чеки можно как и со стороны консула сделать, так и из самих приложений. Если делать на стороне самого консула, то можно кастомные скрипты использовать. В придачу можно настроить DNS Interface. В общем, очень полезная вещь.
Объясните пожалуйста, не понимаю. Ну вот мы перестали писать в конфигах
Теперь пишем в конфиг
получается поменяли шило на мыло??
а если нужно будет не один mongo-db а несколько (тестовый, промышленный)
а если еще нужно будет чтобы какой mongo-db выбирать зависело от какого нибудь значения??? Saas Multi-tenancy например…
address:port (а еще может нужно знать какая db, какая collection) MongoDB. Теперь пишем в конфиг
discoveryUrl = http://localhost:8500/v1/catalog/service/mongo-dbполучается поменяли шило на мыло??
а если нужно будет не один mongo-db а несколько (тестовый, промышленный)
а если еще нужно будет чтобы какой mongo-db выбирать зависело от какого нибудь значения??? Saas Multi-tenancy например…
Теперь пишем в конфиг discoveryUrl = localhost:8500/v1/catalog/service/mongo-db
Фишка в том, что discoveryUrl фиксирован (он на всегда localhost и формат запроса стабилизирован) и описывать в конфиг-файле сервиса его не имеет смысла. Единственное что нужно — соглашение об именовании сервисов.
а если нужно будет не один mongo-db а несколько (тестовый, промышленный)
И тут не проблема — просто нужно зарегистрировать разные версии с разными именами или использовать механизм тегирования при объявлении сервиса.
По поводу того какая база или коллекция должна быть использована — Consul KV может быть использован для прозрачной передачи каких-либо настроек. Подробнее в документации.
Не затруднит ли вас пояснить, как использовать подключение к сервисам через Consul в php-проектах? Если host:port не нужен, то как, например, подключить Symfony или ZF к базе данных через Consul? Через Consul DNS?
Сразу оговорюсь, что опыта использования php библиотеки для Consul у меня лично нету. В Вашем конкретном случае в связи с тем, что ни Symphony ни Zend Framework (насколько мне известно) не поддерживают напрямую обращение к Consul, Вам придется написать что-то вроде плагина для указанных платформ который бы запрашивал необходимую информацию в Consul и передавал ее непосредственно ядру фреймворка.
Насколько я понимаю, это возможно через DNS:
instead of making HTTP API requests to Consul, a host can use the DNS server directly via name lookups like «redis.service.east-aws.consul». This query automatically translates to a lookup of nodes that provide the redis service, are located in the «east-aws» datacenter, and have no failing health checks. It's that simple!
Все верно — DNS работать будет но, только в том случае, если запрашиваемые сервисы будут использовать стандартные порты. К примеру, MySQL прописанный в Consul на таком-то хосте и использующий стандартный порт 3306, можно будет указать в виде `mysql.service.consul` (если Вы зарегистрировали сервис базы используя mysql в качестве имени сервиса) как хост для подключения к базе. Однако нюанс №1 — не забываете, что DNS резолвер Consul не используется по умолчанию в системе (обратите внимание на вызовы типа: dig 127.0.0.1 -p 8600 ...); нюанс №2 если Вы используете ресурс менеджеры (к примеру Mesos) для поднятия баз данных, то порт для сервиса базы не будет соответствовать стандартному и Вам придется делать SRV запрос к Consul для получения порта.
Получается, что «упрощающая» система, как всегда, усложняет жизнь. PHP-скрипт, который дёргает HTTP-api для резолва каждого внешнего ресурса при каждом обращении к сайту, это как-то странно. И это если ещё не думать про разное окружение, когда у разработчиков consul не настроен в принципе и код обрастает новыми if-else.
Ну, не все так печально, если вспомнить, что REST запросы идут к localhost (думаю Вы добавите 1-2 мс к времени генерации страницы и да, — DNS резолвинг занимает значительно больше времени), а памятуя, что указанные Вами фреймворки достаточно тяжелы сами по себе, влияние задержек на запросы к Consul будет минимальным. На худой конец Вы можете воспользоваться кешем и делать запросы к Consul, скажем, каждый 100-й запрос к странице (в любом случае если база по указанному адресу станет недоступной Вам придется обрабатывать исключение и запрашивать данные из Consul заново).
Насколько я понимаю документацию по Consul, там нет особых проблем с указанием портов для сервисов. Возможно (я ещё не протестировал всю планируемую архитектуру), будут нюансы если на двух хостах запустить одинаковые сервисы на разных портах. Но я проверю это.
Предполагаю, что если не слишком усложнять (например, я не использую Mesos), то всё должно работать. А с consul template так и вовсе становится интересно.
Предполагаю, что если не слишком усложнять (например, я не использую Mesos), то всё должно работать. А с consul template так и вовсе становится интересно.
Consul-Template хорошая вещь, но не забывайте, что её мониторинг и поддержание в рабочем состоянии не такая уже и простая задача, если учесть, что поддержка High Availability в нем не реализована. В любом случае мы используем его в связке с HAProxy для реализации прозрачного изменения к-ва бэкендов. В связи с тем, что Mesos и подобные ему платформы (Nomad, к примеру) будут набирать обороты и все чаще появляться в качестве опций для деплоймента приложений, рекомендую тратить время на разработку архитектуры с учетом возможного использования этих средств — здорово сэкономите себе время/затраты впоследствии.
Дело в том, что разрабатывать архитектуру, зная лишь название сервиса, довольно экстремально. :) Думаю вы представляете, сколько красивых лендингов я уже видел за последнее время. Все эти кубики, упакованные в другие кубики. Devops сейчас на пике и количество разных решений зашкаливает. Но мне нужно выбрать что-то хотя бы сколько-нибудь стабильное, вот я и пытаюсь собрать минимальную архитектуру (сервис не highload, но хочется заложить основы будущего масштабирования и сделать переезд в облака в будущем не слишком сложной задачей).
Добавлю Nomad и Mesos себе в TODO на изучение.
Добавлю Nomad и Mesos себе в TODO на изучение.
Mesos — это ещё один контейнеризатор с дополнительными утилитами? Я пока выбрал LXD (или LXC, если будут проблемы с LXD) для этих целей.
Нет, — Mesos это в двух словах это кластерная операционка. Cisco (и Mesosphere в качестве их партнеров) используют для обозначения DCOS (DataCenter OperationSystem) для обозначения Mesos и его окружения (Marathon, Aurora, Cronos, Consul, etc). Почитайте обязательно — очень внушительный шаг в сторону упрощения деплоймента и эксплуатации кластерных систем.
Судя по назначению и даже по названию, это для проектов несколько иного масштаба. Там, где я сейчас внедряю devops, до реальных кластеров ещё очень неблизко.
Спасибо за ссылки, изучать это всё мне в любом случае интересно, вот только хватит ли времени всё на себе испытать — пока не уверен.
Спасибо за ссылки, изучать это всё мне в любом случае интересно, вот только хватит ли времени всё на себе испытать — пока не уверен.
Я бы не назвал Mesos простым в плане деплоя. Проще, чем Kubernetes, да, но и своих подводных камней хватает (в плане эксплуатации).
Как раз деплоить Mesos очень просто — для большинства популярных операционных Linux систем уже если репозиторий от Mesosphere — простая установка пакета + указание ZooKeeper ссылки на Mesos мастер — всего-то делов.
Другой вопрос именно в функционировании: его нельзя использовать как средство для решения проблем текущей инфраструктуры, — под использование Mesos необходимо переделывать много всего. Плюс пока не решенные проблемы с persistent storage (точнее в 0.25 — уже должны анонсировать таковое для отдельного фреймворка) оставляют использование Mesos для энтузиастов. Однако, я считаю, что за подобными системами будущее.
Другой вопрос именно в функционировании: его нельзя использовать как средство для решения проблем текущей инфраструктуры, — под использование Mesos необходимо переделывать много всего. Плюс пока не решенные проблемы с persistent storage (точнее в 0.25 — уже должны анонсировать таковое для отдельного фреймворка) оставляют использование Mesos для энтузиастов. Однако, я считаю, что за подобными системами будущее.
Sign up to leave a comment.
Consul: Service Discovery это просто, или прощаемся с конфиг-файлами