Consul для масштабирования и настройки Asterisk

Введение

     В прошлом году, выступая на этой сцене, я говорил, что уже больше 10 лет занимаюсь Asterisk. А тут ситуация у меня кардинально поменялась: я больше 10 месяцев к Asterisk вообще не прикасался — ни одного конфига не правил, в консоль не заходил. Только неделю назад появилась необходимость, но, тем не менее, я всё равно здесь и хочу вам рассказать о том, что такое Consul и как он может быть вам полезен.

     Классическим подходом к разработке приложений долгое время являлось создание единого сервиса, включающего в себя всю функциональность. Но современные тенденции идут к тому, чтобы разбивать монолитные приложения на отдельные микросервисы, то есть происходит переход к микросервисной или сервисно-ориентированной архитектуре. Это даёт множество преимуществ для разработчиков: можно сфокусироваться отдельной команде на одной части проекта, разные микросервисы могут быть написаны на разных языках, но всё равно вместе работать.

  Однако, помимо плюсов, возникают и проблемы, в основном для эксплуатации. Раньше отдельные части большого сервиса могли просто вызывать функции или методы внутри одного приложения. Когда же сервисы стали отдельными, возникает вопрос, как один сервис найдёт другой. Конечно, можно захардкодить адрес и порт, но в современных условиях это непрактично — ведь сервисы могут обновляться, масштабироваться, появляться новые экземпляры и так далее. Аналогично усложняется и настройка: если раньше был один конфиг, то теперь их много, и какие-то параметры общие, а какие-то индивидуальны. Помочь в этой проблеме может Consul — распределённое, высокодоступное решение, которое помогает сервисам находить друг друга и связываться между собой. Разрабатывается и поддерживается он компанией HashiCorp. Возможно, вы знакомы с другими их продуктами: Vagrant, Vault, Terraform и многими другими. Consul — зрелый, давно используемый продукт, имеющий open-source версию, а также Enterprise-редакцию с дополнительными функциями и облачным вариантом.

Ключевые возможности Consul:

1. Service Discovery — чтобы сервисы могли регистрироваться и находить друг друга.
2. Health Checking — проверка доступности и работоспособности сервисов.
3. K/V-хранилище — хранение настроек и других данных.
4. Защищённые коммуникации между сервисами (генерация TLS-сертификатов, создание безопасных туннелей).
5. Поддержка работы в нескольких дата-центрах «из коробки».

     Немного об архитектуре и терминологии. Основная единица Consul — это агент (Consul Agent), который запускается на каждом узле кластера и может работать в двух ролях: клиент или сервер.

• Consul-клиент (client) ничего в себе не хранит, лишь предоставляет интерфейсы для регистрации сервисов и запускает health-чек. Клиентов в кластере может быть тысячи.
• Consul-сервер (server) хранит полную информацию обо всех сервисах, ключах K/V и так далее. Обычное количество серверов в кластере — три или пять. Два сервера — плохой вариант из-за возможного «split brain» (каждый сервер останется в одиночестве, и непонятно, какой из них «прав»). Три и более серверов позволяют определить, где находится «большинство». Увеличение числа серверов выше пяти обычно не даёт большой пользы, но сильно увеличивает нагрузку и сетевой трафик.

     Серверы между собой выбирают лидера с помощью протокола Raft. Лидер владеет всей информацией, и когда он подтверждает какое-то изменение, оно считается согласованным и распространяется на остальные серверы. Если лидер выходит из строя, оставшиеся серверы выбирают нового.

     Установка Consul несложная. HashiCorp распространяет единый бинарный файл для разных платформ и архитектур, есть готовые пакеты для Debian и RPM-based систем, а при желании можно собрать из исходников (Consul написан на Go).

Service Discovery

     Service Discovery. Чтобы сервис был доступен через Consul, он должен зарегистрироваться. Это можно сделать двумя способами:

1. Описать сервис в конфигурационном файле (JSON/HCL).
2. Зарегистрировать его динамически через HTTP API.

     Простейшая конфигурация содержит имя сервиса (одно и то же имя для всех экземпляров), порт, а также описание health-чеков (TCP, HTTP-запрос, скрипт и т. д.). Если сервисы зарегистрированы в Consul, то другие сервисы могут их найти, обратившись к Consul по DNS или HTTP API.

• Через DNS: у каждого Consul-агента есть встроенный DNS-сервер. Сформировав специальный DNS-запрос (например, service_name.service.consul), можно получить список IP-адресов и портов всех экземпляров сервиса.
• Через HTTP: можно сделать запрос и получить актуальный список адресов, поддерживая при желании long polling, то есть оперативно узнавая об изменениях.

     Кроме того, Consul предоставляет K/V-хранилище, в котором можно хранить настройки. Доступ к нему возможен из CLI и по HTTP API. Структура ключей напоминает иерархию каталогов (похоже на etcd). Мы можем добавлять/удалять значения, хранить там общие настройки и тут же получать изменения в наших сервисах.

А где же тут Asterisk?

     А где же тут Asterisk? У меня давно была идея подружить Consul и Asterisk. Когда Сергей позвал меня на конференцию, я планировал сделать модуль для Asterisk, который бы напрямую взаимодействовал с Consul. Но оказалось, что подобный модуль уже давно существует! Его написал Сильвиан Бойли — так что он «красавчик», а я просто «говорящая голова». Модуль не слишком популярен, но всё же в 26 раз популярнее моего модуля для Kafka.

     Этот модуль для Consul в Asterisk работает через HTTP-запросы и требует только libcurl в качестве зависимости. Он легко собирается, есть даже «дебианизация» от автора. Загружается стандартным образом и настраивается в конфигурационном файле. В настройках можно указать:

• Идентификатор конкретного экземпляра сервиса (если не указать, он генерируется автоматически).
• Имя сервиса.
• Хост и порт, по которым доступен Consul, а также токен, если необходима авторизация.
• Дополнительные теги (для того, чтобы различать экземпляры Asterisk, например, по окружениям).
• Явный IP-адрес и порт, или их автоматическое определение по интерфейсу.

     Для health-check’а в модуле применена хитрость: проверять доступность SIP напрямую непросто, поэтому используется готовый HTTP-порт Asterisk (если он включён). Кроме того, у модуля есть консольный API, позволяющий переводить конкретный экземпляр сервиса в режим обслуживания (maintenance) и выводить из него. Это уже даёт пользу: можно находить все живые инстансы Asterisk элементарным DNS-запросом, а затем увести какой-то узел в обслуживание без обрыва звонков. В режиме maintenance он перестаёт выдаваться в списке доступных сервисов, новые звонки туда не пойдут, и мы можем спокойно перезагрузить или выключить этот узел.

     Но можно пойти дальше и использовать Consul Template. Оно следит за изменениями внутри Consul и на основе шаблонов (Go Template) генерирует конфигурационные файлы, а затем может выполнять команды для применения обновлённого конфига. Например, в Kamailio есть модуль dispatcher, который позволяет распределять звонки по списку узлов. Этот список можно хранить в конфигурационном файле и автоматически генерировать через Consul Template. Если в Consul появляется новый экземпляр Asterisk, он автоматически добавится в конфиг, а если узел пропадёт — строка будет удалена.

     Аналогично можно генерировать конфиги и для самого Asterisk. Например, в sip.conf подключать отдельный файл, который Consul Template обновляет при изменении списка сервисов. В шаблоне мы можем перебирать все экземпляры сервиса Asterisk, фильтровать их по тегам, исключать собственный узел и многое другое. Точно так же можно работать с данными из K/V-хранилища: получать значения по ключам, итерироваться по дереву ключей. Если кто-то использует Vault, то Consul Template умеет работать и с ним, подставляя секреты в конфиги динамически.