12/07/2020
Давно хотелось написать в своем блоге об одном из основных продуктов HashiCorp — Consul. Пожалуй, это один из ключевых программных продуктов для HashiCorp. Он обеспечивает регистрацию, дерегистрацию и хранение информации о работающих IT сервисах в сети организации. Также он представляет собой хранилище Key—Value данных. Такая своеобразная СУБД вкупе с доступом к ней через протокол HTTP делает Consul эффективным инструментом в современной IT инфраструктуре. Большинство остальных продуктов HashiCorp может использовать Consul в качестве бекэнда для хранения своей информации. Это касается и Terraform, и Vault, и Nomad. Получается своеобразная кооперация, дающая возможность организовать отказоустойчивость и распределенность продуктов HashiCorp. При этом аналогичная методика может быть применена и использована в сторонних программных продуктах для организации хранения информации.
Сразу же хотелось бы обозначить сферу применения Consul. Как бы он хорош не был — далеко не всем он будет нужен или принесет заметную пользу. Данный программный продукт будет наиболее интересен тем, кто использует в своей инфраструктуре микросервисную архитектуру, а также удобным, как писал выше, в сочетании с прочими продуктами HashiCorp. Функционал Service Discovery, который является основным в работе Consul, используется во многих IT компаниях, ориентированных на предоставление Highload сервисов. Если же Ваша организация занимается эксплуатацией стандартных покупных IT решений, либо IT сервисов, базирующихся на монолитной архитектуре, то скорее всего программное обеспечение Consul будет не актуальным для Вас.
Как запустить
Существует 2 версии HashiCorp Consul — Open Source и Enterprise. Если первая доступна бесплатно абсолютно всем, то вторая с добавочным функционалом уже стоит денег и требует покупки соответствующих лицензий. Я в этой статье делаю акцент на Open Source версию данного программного продукта, так как он более чем достаточен в большинстве случаев, а также может использоваться любым разбирающимся ITшником.
Согласно референсной архитектуры, нам необходимы 3 виртуальные машины на базе Linux, которые будут использоваться для создания кластера Consul. На них устанавливается бинарник Consul, который скачивается с сайта https://releases.hashicorp.com/consul. При этом нужно выбрать требуюмую версию софта и используемую архитектуру. К слову сказать, один и тот же бинарник используется как на серверах кластера Consul, так и на клиентских машинах, которые обращаются к данному кластеру через данный установленный агент. После того, как нужный бинарник закачан и помещен в директорию /usr/bin/ на серверах кластера, нам нужно создать файлы настроек Consul. К сожалению из коробки ничего кроме исполняемого файла от Hashicrop мы не получим. Приведу в качестве примера следующие конфигурации.
Файл /etc/consul.d/config.json, в котором описываются основные параметры работы Consul на сервере. В частности указывается ip адрес, к которому будет привязан сервис, а также ip адреса всех серверов Consul в кластере.
{
"bind_addr": "xx.xx.xx.xx",
"datacenter": "MYDC",
"data_dir": "/opt/consul",
"encrypt": "MSDFUsdfkluwer3lklcx+hkUW40U5CpdmMbqosSLDKFJEFCSD4lsdf=",
"log_level": "INFO",
"enable_syslog": true,
"enable_debug": true,
"node_name": "consulserver-xx",
"server": true,
"ui": true,
"leave_on_terminate": false,
"skip_leave_on_interrupt": true,
"rejoin_after_leave": true,
"retry_join": [
"xx.xx.xx.xx",
"yy.yy.yy.yy",
"zz.zz.zz.zz"
]
}
В файле /etc/systemd/system/consul.service прописываем параметры для запуска и управления работой сервиса Consul в системе.
[Unit]
Description="HashiCorp Consul - A service mesh solution"
Documentation=https://www.consul.io/
ConditionFileNotEmpty=/etc/consul.d/config.json
[Service]
Type=notify
User=consul
Group=consul
ExecStart=/usr/bin/consul agent -config-dir=/etc/consul.d/ -enable-local-script-checks
ExecReload=/usr/bin/consul reload
KillMode=process
Restart=on-failure
LimitNOFILE=65536
[Install]
WantedBy=multi-user.target
Создаем отдельного пользователя и групу для запуска Consul, также проводим необходимые манипуляции с разрешениями файлов. После этого по сути можно запускать кластер в работу.
Как использовать
Итак, когда сервера Consul работают, можно попробовать получить от них то, для чего они предназначены. Это прежде всего Service Discovery. Consul предоставляет несколько вариантов взаимодействия с кластером в этом процессе.
Во-первых, регистрация работы тех или иных сервисов с помощью специальных конфигурационных файлов на виртуалках, где установлен Consul агент. Так же с помощью обращения напрямую к агенту можно как узнавать о работоспособности сервисов в сети, так и регистрировать их в системе.
Ниже пример конфигурационного файла, который в ручном режиме регистрирует сервис в Consul.
{"service":
{"name": "test-service",
"id": "test01",
"tags": ["devops"],
"address": "xx.xx.xx.xx",
"port": yy,
"check": {
"args": ["curl", "xx.xx.xx.xx:yy"],
"interval": "10s"
}
}
}
В данной конфигурации указан сервис в привязке к ip адресу и порту, где он работает, а также способ проверки его жизнедеятельности с помощью утилиты curl. Если указанная в конфигурации проверка будет неуспешна, то сервис автоматически будет дерегистрирован.
Во-вторых, использование HTTP API интерфейса системы Consul. С помощью этого API также можно регистрировать, дерегистрировать сервисы, а также получать информацию об их статусе. С помощью HTTP API по сути любое приложение само в автоматическом режиме может уведомлять о своем статусе, позволяя эффективно масштабировать приложения с миллионами пользователей.
В-третьих, DNS интерфейс Consul, позволяет получать информацию из его базы данных с помощью обычных DNS запросов любому клиенту в сети. С помощью несложных манипуляций можно интегрировать Consul с внутренними DNS серверами организации. Это позволяет абсолютно прозрачно приложениям использовать Service Discovery без каких-либо изменений внутри кода.
Так, к примеру, чтобы узнать ip адрес сервиса test-service, который мы ранее зарегистрировали в нашей Service Discovery системе, можно воспользоваться запросом типа A к DNS системе в зоне service.consul. Вывод команды dig представлен ниже. Надо добавить, что по умолчанию сервисы регистрируются в DNS в подзоне service.consul. В случае необходимости наименование этой зоны можно перенастроить.
dig test-service.service.consul
; <<>> DiG 9.11.3-1ubuntu1.11-Ubuntu <<>> test-service.service.consul
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48624
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;test-service.service.consul. IN A
;; ANSWER SECTION:
test-service.service.consul. 0 IN A xx.xx.xx.xx
;; Query time: 6 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; MSG SIZE rcvd: 74
Резюме
Если Ваша IT инфраструктура нацелена на предоставление Highload сервисов, базирующихся на микро архитектуре, Consul один из тех программных продуктов, который надо рассматривать и использовать уже здесь и сейчас. Вкупе со своими братьями и сестрами такими, как Vault, Nomad, Terraform — это незаменимый инструмент для Администраторов, Программистов, Инженеров и Девопсов.
