Что здесь интересного:
Обзорная статья о Консул ( http://consul.io ) - система поддержания обнаружение службы и распределенное хранилище ключей-значений.
Помимо самого Консула, рассмотрим Consul-Template — инструмент управления конфигурациями сервисов, автоматически отражающий изменения в топологии.
Статья будет интересна DevOps-инженерам, системным архитекторам, руководителям проектных групп и всем, кто интересуется микросервисными архитектурами.
Естественно, я не могу охватить все аспекты функционирования и использования Consul, но в статье будет описано достаточно, чтобы любознательный читатель заинтересовался и продолжил глубже изучать.
Консул: «С какой птицей они едятЭ»
Лирическое отступление, но по теме.В современном мире огромных объемов данных, где распределенные системы их обработки становятся не чем-то из мира недостижимой фантастики, а повседневными вещами, вопросы их правильного проектирования и реализации становятся очень важным моментом в последующем развитии этих технологий.
системы.
Любой, кто хотя бы раз принимал участие в разработке архитектур автоматически масштабируемых, распределенных систем, знает, что этот процесс очень трудоемкий и требует достаточно серьезного багажа знаний о системах, из которых могут быть построены подобные архитектурные решения.
Учитывая бурное развитие облачных вычислений и появление платформ IaaS, развертывание масштабируемых систем стало достаточно простым.
Однако взаимодействие компонентов таких систем (интеграция новых компонентов, удаление неиспользуемых частей и т. д.) всегда вызывает головную боль у архитекторов, devops-инженеров и программистов.
Для этих целей можно придумать свой велосипед (шаблоны конфигурационных файлов, поддержка саморегистрации на стороне приложения и т.п.
), можно использовать локальные или распределенные системы хранения ключей (redis, Zookeeper и т.п.
), и т. д.) или вы можете использовать системы обнаружения сервисов.
Часто термин Service Discovery (далее я буду использовать аббревиатуру SD) относится к системам сетевого обнаружения (протокол СДП , например), но в последнее время SD стали использовать и в программной части архитектур для взаимного обнаружения родственных компонентов системы.
Особенно это касается микросервисного подхода к разработке программных систем.
С.
А.
(Micro Services Architecture), одним из пионеров и популяризаторов которой является Netflix, все больше становится стандартом разработки распределенных, автомасштабируемых, высоконагруженных систем.
А Консул уже во многих местах используется для обеспечения СД в таких системах.
Например, Cisco использует его в своем движке MSA — Сиско МИ .
На самом деле Consul представляет собой удачное сочетание K/V-хранилища и функциональности SD. Ну а теперь более подробно.
Консул: Как лучше?
Вполне резонный вопрос: «Зачем нам Консул, если у нас есть Zookeeper и он отлично справляется с СДЭ» Ответ на поверхности — Zookeeper, и подобные системы (etcd, doozerd, redis и т.д.) не предоставляют функционала SD — их задача лишь хранить данные в том или ином формате и гарантировать их доступность и целостность в каждый отдельный момент времени.(при условии правильной настройки и использования, конечно).
Естественно, такой модели будет вполне достаточно для обеспечения СД, но простота использования (настройки, обслуживания и т.п.
) зачастую оставляет желать лучшего.
Например, Zookeeper: это постоянные возни со своим кластером, начиная с первоначальной настройки (автоматическая установка zk-кластера с помощью Ansible или SaltStack может доставить немало хлопот даже продвинутому специалисту), заканчивая переносом ссылок на кластер к программному обеспечению, использующему Zookeeper зк://10.10.1.2:2181,10.10.1.3:2181,10.10.1.5:2181/приложение (предварительно необходимо знать, где находится кластер и все его узлы).
Более того, если кластер Zookeeper по каким-то причинам «переедет» на другие адреса (очень важно в облачных средах, MSA-архитектурах), все приложения и сервисы, использующие этот кластер, придется перезапускать.
С Консулом все проще: ребята из ХашиКорп делал «все для народа».
Consul распространяется в виде 1 бинарного файла (нет необходимости следить за зависимостями или использовать пакетные менеджеры) и любое программное обеспечение, использующее Consul, всегда делает запросы к нему на локальном хосте (нет необходимости хранить ссылку на кластер или мастер-ноду сервиса ) - Консул обо всём позаботится.
Применение Слух В качестве протокола связи Consul является быстрым, отказоустойчивым и не требует выделенного ведущего устройства для правильной работы.
Фактически мастер как таковой формально существует (даже кворум мастеров), но это необходимо по большей части для того, чтобы пережить полную остановку всех узлов кластера (мастера обеспечивают периодическое сохранение оперативных данных на диск, тем самым гарантируя постоянство данных).
В результате для приложения (микросервиса), использующего Consul, вся работа с SD сводится к общению с localhost:8500 — куда бы приложение ни перемещалось, там всегда будет агент Consul. Более того, для работы с Consul вам не нужно иметь никаких клиентских библиотек (как в случае с Zookeeper) — для этого вы используете простой и понятный HTTP REST API (простые данные, не более 20 различных функций API), либо DNS сервисы с записями SRV (да, одна из функций Consul — предоставление DNS-интерфейса зарегистрированным сервисам).
Вы можете прочитать более подробную информацию здесь .
Консул: Как установить и начать работу?
Скажу сразу, что мы не будем подробно останавливаться на установке и настройке — для читающих статью, думаю, это будет достаточно простое упражнение.Есть только одна проблема, достойная внимания - отсутствие прозрачности поиска установочной документации на сайте, поэтому вот ссылки: первоначальная установка (в качестве домашнего задания - разработка скриптов запуска/остановки любимого init.d/upstart/systemd - удаляем ненужное), запускающие агенты И инициализация кластера .
Пара замечаний по поводу выбора топологии кластера.
Стоит отметить, что у Consul нет отдельного мастера, который бы единолично принимал и распределял конфигурации сервисов и данные между узлами — для регистрации сервисов и данных можно использовать абсолютно любой агент. Вообще говоря, мастер (точнее, кворум мастеров) как таковой существует, и его основная роль — обеспечение сохранности данных при перезапусках кластера.
Консул: Регистрируйте сервис, используйте запросы
Итак, имея готовый кластер (или одну ноду для тестирования), приступим к регистрации сервисов.Для начала сгенерируем гипотетический сценарий, на основе которого мы будем дальше понимать работу Consul: предположим, у нас есть классическое веб-приложение, состоящее из нескольких фронтенд-сервисов, нескольких бэкенд-сервисов и хранилища данных — пусть это будет mongodb. Скажем сразу, инфраструктура тестовая и вопросы типа: почему MongoDB не кластеризована?, почему HAProxy, а не Nginx? и т. д. Оставляю это как домашнее задание любознательному читателю.
При работе с Consul мы будем различать 2 типа сервисов — активные (использующие http rest api для собственной регистрации и реализации проверок доступности) и пассивные (требующие заранее подготовленных файлов конфигурации для Consul).
В первый войдут сервисы, разработанные локально (продукт компании и его компоненты), во второй: сторонние приложения (не обязательно поддерживающие работу с Consul, либо не поддерживающие ее вообще, например MongoDB).
Итак, введем регистрацию в сервисе MongoDB — создадим файл /etc/consul.d/mongodb.json :
Самое главное здесь: 1. адрес/порт — именно такие данные получат клиенты Consul в ответ на запрос информации о сервисе «mongo-db».{ "service": { "name": "mongo-db", "tags": ["mongo"], "address": "123.23.34.56", "port": 27017, "checks": [ { "name": "Checking MongoDB" "script": "/usr/bin/check_mongo.py --host 123.23.34.56 --port 27017", "interval": "5s" } ] } }
Опубликованный адрес должен быть доступен.
2. Раздел «Проверки» — список проверок, позволяющих определить, жив ли сервис.
Это может быть любой скрипт (возвращающий 0, если служба работает нормально; 1 в случае предупреждения о статусе службы и любое другое значение, если служба недоступна), проверка http (запрашивается определенный URL-адрес и на основе ответа определяется состояние службы).
генерируется — HTTP/2XX — сервис активен, HTTP/4XX, HTTP/5XX — сервис недоступен).
Более подробная информация на сайте: Описание услуг , описание чеков .
Последующий перезапуск агента (с указанием /etc/consul.d/ в качестве каталога конфигурации) примет этот файл и зарегистрирует MongoDB как сервис, доступный для SD. Скрипт, указанный в разделе проверок, осуществляет подключение к MongoDB на указанном хосте (проверка доступности сервиса) и, например, делает запрос к какой-либо коллекции для проверки доступности данных.
Впоследствии вы можете проверить регистрацию с помощью Curl: ~/WORK/consul-tests #curl -XGET http://localhost:8500/v1/catalog/service/mongo-db
[{"Node":"mpb.local","Address":"192.168.59.3","ServiceID":"mongo-db","ServiceName":"mongo-db","ServiceTags":["mongo"],"ServiceAddress":"123.23.34.56","ServicePort":27017}]
Или используя DNS-сервер, встроенный в Consul: ~/WORK/consul-tests #dig @127.0.0.1 -p 8600 mongo-db.service.consul SRV
; <<>> DiG 9.8.3-P1 <<>> @127.0.0.1 -p 8600 mongo-db.service.consul SRV
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50711
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;mongo-db.service.consul.
Теги: #saas #consul #msa #service Discovery #soa #discovery #масштабируемость #масштабируемость #kv хранилища #распределенные вычисления #Системный анализ и проектирование #SaaS / S+S
-
Ноутбук Ferrari-Fo200-313G25N От Acer
19 Oct, 24 -
Google Ищет Лоббистов В Европе
19 Oct, 24 -
Gearjuice Rescue: Если Села Батарея
19 Oct, 24 -
Несовместимый Компьютер
19 Oct, 24
