Программа консул что это

Содержание

Magic Cookies

«Есть люди, которым труднее других. И на них обязанность быть лучше. Другим сходит с рук, а им нет… Это вроде бы каждый обязан. Но если человек решился жить по мечте, то он обязан вдвойне. Потому что большинство по мечте жить трусит… Или благоразумие мешает. А те, кто живет по мечте, — они вроде примера. Или укора».

Олег Куваев.

Страницы

среда, 3 марта 2021 г.

Consul: Service Discovery это просто, или прощаемся с конфиг-файлами

Обзорная статья о Consul ( http://consul.io ) — системе для поддержания обнаружения сервисов и распределенного хранилища ключ-значение. Кроме самого Consul, рассмотрим Consul-Template — средство для управления конфигурациями сервисов автоматически отражающее изменения в топологии. Статья будет интересна DevOps инженерам, системным архитекторам, тим-лидам проектов и прочим интересующимся микросервисными архитектурами.

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

Service Discovery в распределенных системах на примере Consul. Александр Сигачев (Inventos)

Consul: «что за птица — с чем едят?»

Лирическое отступление, но по теме.
В текущем мире огромных объемов данных, где распределенные системы их обработки становятся не чем-то из мира недостижимой фантастики но обыденными вещами, вопросы их правильного проектирования и реализации становятся очень важным моментом в последующем развитии этих систем. Каждый, кто хотя бы раз принимал участие в разработке архитектур автоматически масштабируемых, распределенных систем, знает что этот процесс очень трудоемкий и требующий достаточно серьезного стека знаний систем из которых можно строить подобные архитектурные решения. С учетом бурного развития облачных вычислений и появления IaaS платформ — разворачивание масштабируемых систем стало достаточно простым делом. Однако взаимодействие компонентов таких систем (интеграция новых компонентов, удаление неиспользуемых частей и т.д.) всегда вызывает головную боль у архитекторов, devops инженеров и программистов. Для этих целей можно придумывать свой велосипед (шаблоны конфигурационных файлов, поддержка саморегистрации со стороны приложения и т.д.), можно использовать локальные или распределенные системы хранения данных «ключ-значение» (redis, zookeeper, etcd и др.) а можно использовать системы обнаружения сервисов (Service Discovery).

Часто термин Service Discovery (в дальнейшем я буду использовать сокращение — SD) относится к системам сетевого обнаружения (протокол SDP , к примеру) но в последнее время SD используется и в программной части архитектур для взаимного обнаружения связанных компонентов систем. Особенно это касается микросервисного подхода к разработке программных комплексов. MSA (Micro Services Architecture), одними из первопроходцев и популяризаторов которой является Netflix, все чаще становится стандартом для разработки распределенных, авто-масштабируемых, высоко нагруженных систем. И Consul уже много где используется для обеспечения SD в подобного рода системах. К примеру Cisco использует его в своем движке для MSA — Cisco MI .

КОНСУЛ — что это такое? значение и описание

Собственно, Consul и есть удачное объединение K/V хранилища и SD функционала. Ну а теперь подробнее.

Consul: Чем он лучше?

Достаточно резонный вопрос «Зачем нам Consul, если у нас есть Zookeeper и он прекрасно справляется с задачей SD?». Ответ на поверхности — Zookeeper, и подобные системы (etcd, doozerd, redis, etc) не предоставляют функционала SD — их задача всего-лишь хранить данные в том или ином формате и гарантировать их доступность и консистентность в каждый отдельный момент времени (при условии правильной настройки и использования, конечно). Естественно такой модели будет вполне достаточно для обеспечения SD, но вот удобство использования (настройки, обслуживания, и т.д.) частенько оставляет желать лучшего.

К примеру, Zookeeper: это постоянная возня с его кластером, — начиная с первичной настройки (автоматизированная установка zk кластера средствами Ansible или SaltStack может доставить немало хлопот даже продвинутому специалисту), заканчивая передачами софту, использующему Zookeeper, ссылок на кластер вида zk://10.10.1.2:2181,10.10.1.3:2181,10.10.1.5:2181/app (необходимо предварительно знать где расположен кластер, все его ноды). Мало того, — если кластер Zookeeper по какой-то причине «переедет» на другие адреса (очень актуально в облачных средах, MSA архитектурах), придется перезапускать все использующие этот кластер приложения и сервисы.
С Consul все проще: ребята из HashiCorp сделали «все для людей». Consul распространяется как 1 бинарный файл (нет надобности следить за зависимостями, использовать пакетные менеджеры) и любой софт использующий Consul всегда делает запросы к нему на localhost (нет надобности хранить ссылку на кластер или master ноду сервиса), — Consul все берет на себя.

Использование Gossip в качестве протокола обмена данными делает Consul быстрым, отказоустойчивым и не требующим выделенного мастера для нормального функционирования. На самом деле мастер как таковой формально имеется (даже кворум мастеров) но это необходимо по большей части для того, чтобы пережить полную остановку всех нод кластера (мастера обеспечивают периодическое сохранение оперативных данных на диск тем самым гарантируя персистентность данных). В итоге, для приложения (микросервиса) использующего Consul вся работа с SD сводится к общению с localhost:8500 — куда бы не переехало приложение — там всегда будет агент Consul. Мало того, для работы с Consul не нужно иметь каких-либо клиентских библиотек (как в случае с Zookeeper) — для этого используется простой и понятный HTTP REST API (простые данные, не более 20 разных API функций), либо DNS сервисы с SRV записями (да, — одна из функций Consul — предоставление DNS интерфейса к зарегистрированным сервисам).
Более подробно можно почитать тут .

Consul: Как поставить, и начать работу?

Сразу скажу, что останавливаться подробно на установке и настройке мы не будем — для читающих статью, думаю, это будет достаточно простым упражнением. Лишь одна проблема достойная внимания, — не прозрачность в поиске документации по установке на сайте, потому вот ссылки: начальная установка (как домашнее задание — разработка start/stop скриптов для своего любимого init.d/upstart/systemd — ненужное — вычеркнуть), запуск агентов и инициализация кластера .

Пара замечаний по поводу выбора топологии кластера. Не лишним будет отметить, что Consul не имеет обособленного мастера, который единолично принимал и распространял бы конфигурации сервисов и данные между нодами, — абсолютно любой агент может быть использован для регистрации сервисов и данных. Вообще-то говоря, мастер (точнее кворум мастов) как таковой имеется, и его основная роль — обеспечение персистентности данных при рестартах кластера.

Consul: Регистрируем сервис, используем запросы

Итак, имея готовый кластер (или одну ноду для тестов) начнем регистрировать сервисы. Для начала сгенерируем гипотетический сценарий на базе которого будем дальше разбираться с работой Consul: предположим у нас есть классическое web приложение состоящее из нескольких frontend сервисов, нескольких backend сервисов и хранилища данных — пусть будет mongodb. Оговорим сразу же, что инфраструктура тестовая и вопросы наподобие: почему MongoDB не кластеризован?, почему HAProxy, а не Nginx? и т.д. оставляю пытливому читателю в качестве домашнего задания.
При работе с Consul мы будем различать 2 вида сервисов — активные (использующие http rest api для собственной регистрации и внедрения проверок доступности) и пассивные (требующие предварительно приготовленных конфигурационных файлов для Consul). К первым будем относить сервисы разрабатываемые локально (продукт компании и его компоненты), ко вторым: сторонние приложения (необязательно поддерживающие работу с Consul, или не поддерживающих ее вообще, — к примеру MongoDB).

Итак, введем регистрацию для MongoDB сервиса — создадим файл /etc/consul.d/mongodb.json :

< «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» > ] > >

Самое важное тут:
1. address/port — собственно именно эти данные будут получать клиенты Consul в ответ на запрос информации о сервисе «mongo-db». Публикуемый адрес должен быть доступен.
2. Секция «checks» — список проверок позволяющих идентифицировать жив ли сервис. Это может быть любой скрипт (возвращающий 0 в случае нормального функционирования сервиса; 1 в случае warning статуса сервиса и любое другое значение в случае недоступности сервиса), http проверка (запрашивается некий URL и на основании ответа генерируется состояние сервиса — HTTP/2XX — сервис жив, HTTP/4XX, HTTP/5XX — сервис недоступен).

Последующий рестарт агента (с указанием /etc/consul.d/ как каталога с конфигурациями) примет этот файл и зарегистрирует MongoDB как сервис доступный для SD. Скрипт указанный в секции checks делает подключение к 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>]

Или с помощью встроенного в Consul DNS сервера:

Использование того или иного способа получения данных из Consul зависит от архитектуры запрашивающего компонента (для скриптов удобнее использовать DNS интерфейс, для компонентов написанных на ЯП высокого уровня — REST запросы или специализированные библиотеки).

Все сервисы, которые могут поддерживать саморегистрацию должны использовать библиотеки для необходимых ЯП: python , java , go , ruby , php . Необходимо не забывать помимо, собственно регистрации сервисов, грамотно разрабатывать скрипты проверки доступности того или иного сервиса чтобы не получить систему с зарегистрированными но не работающими сервисами.

Consul: Прощайте конфигурационные файлы.

Собственно добрались до самой сути, — дочитавшим посвящается… Итак в какой-то определенный момент времени мы получили среду в которой зарегистрированы сервисы (mongodb, backend, — к примеру) какую же выгоду можно получить?
В традиционных распределенных системах (без внедренного SD) используются в основном такая техника для добавления нового компонента в систему (скажем при росте нагрузки необходимо создать еще один backend):
1. Создается инстанс backend сервиса (зачастую при помощи систем оркестровки типа SaltStack/Puppet/Ansible/Hand-Made scripts/etc)
2. Система оркестровки по шаблонам генерирует новые конфигурационные файлы для сервисов использующих backend (load balancers, frontends, etc)
3. Та же система оркестровки генерирует конфиг файл для этого нового backend сервиса, указывая в нем контактную информацию о mongodb и прочих зависимых компонентах
4. Все зависимые сервисы перечитывают конфигурацию (или рестартуют) пересоздавая соединения между собой
5. Система дожидается конвергенции и переходит в рабочее состояние.

Подобный подход очень затратен — необходимо сделать генерации конфиг файлов, их распространение, перезапуски сервисов и т.д. Ко всему — в процесс вовлечена система оркестровки (сторонний по отношению к рабочей системе компонент) за доступностью которой тоже нужно следить.

Как заключение.

В целом, из-за того, что Consul находится в фазе активной разработки возможны некоторые проблемы (из замеченного мной — проблемы с развалом кластера при рестарте всех нод с Consul), но базовый функционал SD работает нормально и каких-либо нареканий незамечено. Напомню еще о поддержке Consul’ом множества дата-центров для обеспечения распределенности.

Источник: www.bulygin.su

КОНСУЛ

Построение произвольных сечений и расчет их геометрических характеристик на основе теории сплошных стержней

Программа Консул предназначена для формирования сечений, а также расчета их геометрических характеристик, исходя из теории сплошных стержней.

Графические интерактивные средства обеспечивают формирование сложных сечений произвольной формы с отверстиями и включают функции сглаживания углов, корректировки контура сечения и координат вершин, переноса группы выбранных вершин и др. В программе предусмотрен импорт сечений из файлов форматов DXF и DWG, а также работа с параметрическими сечениями, заданными пользователем.

В результате расчета могут быть получены следующие характеристики: площадь поперечного сечения, значения моментов инерции, радиусы инерции, моменты сопротивления, крутильные и секториальные характеристики, координата центра изгиба.

Программа позволяет получить поля нормальных напряжений, если заданы внутренние усилия в сечении.

Вычисленные геометрические характеристики могут быть использованы в комплексе SCAD при задании жесткостных характеристик элементов.

Интерфейс

Консул работает в операционной среде Windows. Организация пользовательского диалога и элементы управления полностью соответствуют этой среде.

Help (Справочная информация)

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

Источник: scadsoft.com

Установка агента Consul и примеры регистрации сервисов

Обновлено

Обновлено: 22.06.2022 Опубликовано: 10.09.2021

Установленный агент Consul позволяет обмениваться информацией с кластером, отправляя состояние работы сервисов, которые запущены на узле. Мы рассмотрим процесс установки агента на компьютер под управлением Linux на базе Deb (Ubuntu, Debian) или RPM (Rocky Linux, CentOS). Также мы приведем примеры регистрации и настройки проверки сервисов.

Подготовка системы

Предварительно, необходимо настроить брандмауэр. Открываем порты 8300,8301,8302,8500. В зависимости от системы управления netfilter, команды будут отличаться. а) iptables (как правило для систем на базе deb):

iptables -I INPUT -p tcp —match multiport —dports 8300,8301,8302,8500 -j ACCEPT
iptables -I INPUT -p udp —match multiport —dports 8301,8302 -j ACCEPT

Для сохранения правил используем один из методов, предложенных в данной инструкции. б) firewalld (чаще для RPM-based):

firewall-cmd —permanent —add-port=<8300,8500>/tcp
firewall-cmd —permanent —add-port=/
firewall-cmd —reload

Установка агента

wget — утилита для загрузки файлов.
unzip — пакет для распаковки архивов zip.

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

apt install wget unzip

yum install wget unzip

Теперь можно приступать к установке консула.

На странице со списком релизов необходимо посмотреть на все версии и выбрать необходимую. Также мы можем посмотреть версию consul на сервере:

. и установить такую же.

Так или иначе, создаем переменную с номером версии:

И скачиваем архив с бинарным файлом:

Распаковываем его в каталог /usr/bin:

unzip consul_$_linux_amd64.zip -d /usr/bin

Проверяем, что команды консул выполняются:

Мы должны увидеть версию программы:

Настройка и запуск агента

Настроим запуск агента в качестве сервиса. Для этого мы создадим юнит в systemd.

Создаем учетную запись, от которой будет работать агент:

useradd -r -c ‘Consul Agent’ consul

* в данном примере мы создадим системную (-r) учетную запись consul. Для удобства восприятия мы также добавим комментарий (-c).

Создаем каталоги для приложения консул:

mkdir -p /var/lib/consul /etc/consul.d

И выставим на них соответствующие права:

chown consul:consul /var/lib/consul /etc/consul.d

chmod 775 /var/lib/consul /etc/consul.d

* в данном примере мы указали, что владельцем данных каталогов будет созданная учетная запись consul. Права будут полные у владельца, остальные смогут читать данные.

Создаем конфигурационный файл:

«server»: false,
«datacenter»: «dc1»,
«node_name»: «agent01»,
«data_dir»: «/var/lib/consul»,
«bind_addr»: «192.168.0.100»,
«client_addr»: «127.0.0.1»,
«retry_join»: [«192.168.0.15», «192.168.0.20», «192.168.0.25»],
«encrypt»: «zpjf5a4reDbJFpT6FeaF0LGxD0zBRPSRbIoUkLBt0ps=»,
«log_level»: «warn»,
«enable_syslog»: true,
«telemetry»: «disable_compat_1.9»: true
>
>

server — указывает на использование серверного режима. При значении false используется режим клиента.
datacenter — датацентр, к которому будет присоединяться участник кластера. dc1 — датацентр по умолчанию.
node_name — имя, которым будет представлен узел в кластере.
data_dir — каталог на компьютере, который будет использоваться консулом для хранения своей информации.
bind_addr — IP-адрес, на котором будет слушать сервис.
client_addr — адрес, к которому будут привязаны клиентские интерфейсы. На практике, были проблемы при указании нескольких адресов. Проблема не наблюдается при использовании 127.0.0.1 для client_addr и внешнего сетевого адреса для bind_addr.
retry_join — список серверов консула, к которым должен присоединиться агент.
encrypt — ключ, который был сформирован для серверов консул и используется в качестве значения параметра encrypt (его можно посмотреть в конфигурационном файле на сервере consul).
log_level — уровень логирования. Возможны варианты trace, debug, info, warn, err. По умолчанию используется info.
enable_syslog — вести ли системный лог.
disable_compat_1.9 — запрещает все метрики, которые объявлены устаревшими, начиная с версии 1.9.

Проверяем корректность настройки:

consul validate /etc/consul.d/

Мы должны увидеть:

Configuration is valid!

Продолжаем. Создаем юнит в systemd:

[Unit]
Description=Consul client agent
Requires=network-online.target
After=network-online.target

[Service]
User=consul
Group=consul
PIDFile=/var/run/consul/consul.pid
RuntimeDirectory=consul
ExecStart=/usr/bin/consul agent
-config-dir=/etc/consul.d
-pid-file=/var/run/consul/consul.pid
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
KillSignal=SIGTERM
Restart=on-failure
RestartSec=42s

Перечитываем конфигурацию systemd:

Разрешаем автозапуск сервиса, стартуем его и проверяем статус:

systemctl enable consul

systemctl start consul

systemctl status consul

На любом из узлов кластера выполним:

Среди членов кластера мы должны увидеть свой компьютер, например:

.
agent01 192.168.0.100:8301 alive client 1.10.2 2 dc1

С агентом завершили.

Использование ACL

Выше мы рассмотрели базовый способ присоединения агента к кластеру. Однако, если мы включили проверку подлинности на стороне сервера, необходимо создать политику для агентов и сделать соответствующие настройки на клиентских нодах.

На сервере переходим в каталог с конфигурациями консула и создаем файл с политикой:

node_prefix «» policy = «write»
>
node «» policy = «write»
>
service_prefix «» policy = «write»
>
service «» policy = «write»
>

* это пример политики, которой слишком много позволено. Для увеличения безопасности, мы можем ограничиться перечислением конкретных значений. Например, service «web» для возможности регистрировать сервисы, названия которых начинаются на web.

Создаем политику agent на основе файла agent-policy.txt:

И после, создаем токен на основе политики agent:

consul acl token create -description «Token for Agent» -policy-name agent

Мы получим что-то на подобие:

AccessorID: ddcf169e-237b-836c-47cf-537c12a3818f
SecretID: 37570fdb-798c-24e5-c8c3-612e86031345
Description: Token for Agent
Local: false
Create Time: 2021-09-09 16:36:57.216491588 +0300 MSK
Policies:
b3f3a892-c792-726c-8136-9744fd7e0f7b — agent

Нам нужно значение поля SecretID — это токен, который мы будем использовать на агенте.

Переходим на клиентскую ноду и открываем наш конфигурационный файл:

— это сформированный на сервере токен.

Перезагружаем консул на агенте:

systemctl restart consul

Регистрация сервисов

Рассмотрим общий принцип регистрации сервиса в консуле.

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

Добавить настройку в консул.
Проверить конфигурацию и перезапустить сервис consul.
Проверить регистрацию.
Настроить проверку состояния.

Синтаксис для конфигурации при регистрации сервиса следующий:

Чтобы настройка применилась, перезагружаем консул.

Проверить, что сервис зарегистрировался можно в веб-панели. Также мы можем опросить сервис в DNS:

* в боевой среде стоит настроить перенаправление запросов для домена консула (по умолчанию, consul) на серверы консула. Также для корректной работы многих приложений необходимо сделать так, чтобы консул отвечал на DNS-запросы по порту 53 — для этого можно использовать dnsmasq.

Более конкретно, мы рассмотрим настройки в примерах.

Для проверки состояния нашего сервиса используется конфигурация следующего вида:

* это всего лишь пример. Конфигурация для выполнения проверок может использовать разные подходы. Подробнее, можно почитать в инструкции Consul. Health-check на сайте influunt.ru или Checks на официальном сайте консула.

Чтобы настроить проверку сервиса, мы добавляем опцию check и передаем в качестве аргументов опции проверки.

Но чтобы это работало, в конфигурационном файле консула нужно добавить две строки:

.
«enable_local_script_checks»: true,
«enable_script_checks»: true
.

Перейдем к конкретике.

Примеры регистрации сервисов

По мере необходимости, я буду добавлять новые примеры.

0. Включение возможности делать проверку

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

.
«enable_local_script_checks»: true,
«enable_script_checks»: true

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

Проверяем конфигурационный файл и перезапускаем консул:

consul validate /etc/consul.d/

systemctl restart consul

Источник: www.dmosk.ru

Consul: Service Discovery это просто, или прощаемся с конфиг-файлами

Обзорная статья о Consul (http://consul.io) — системе для поддержания обнаружения сервисов и распределенного хранилища ключ-значение. Кроме самого Consul, рассмотрим Consul-Template — средство для управления конфигурациями сервисов автоматически отражающее изменения в топологии. Статья будет интересна DevOps инженерам, системным архитекторам, тим-лидам проектов и прочим интересующимся микросервисными архитектурами.