Consul от HashiCorp решает задачу, которая в небольшой инфраструктуре обычно закрыта руками — “какой адрес у сервиса X прямо сейчас” и “где лежит этот конфиг, пока он не доехал до всех нод”. Сам Consul — это распределённый каталог сервисов с health-check’ами плюс встроенное KV-хранилище, и оба механизма доступны уже в режиме для локального теста.
Поднять агента для знакомства, без кластера и без прав root:
consul agent -dev
Это единственный сервер-агент в своём собственном datacenter, годится только для теста — HTTP API слушает 127.0.0.1:8500, DNS-интерфейс — порт 8600.
Зарегистрировать сервис — описать его в файле и отдать агенту:
{
"service": {
"name": "web",
"port": 8080,
"check": { "http": "http://localhost:8080/health", "interval": "10s" }
}
}
consul services register web.json
consul catalog services # проверить, что сервис появился в каталоге
Health-check здесь не опция для галочки — именно по нему Consul решает, отдавать ли адрес сервиса остальным через DNS/API, упавшая проверка молча убирает инстанс из выдачи.
KV-хранилище — третий угол той же системы, рядом с discovery, а не отдельный продукт:
consul kv put config/web/timeout 30s
consul kv get config/web/timeout
На этом примере удобно понять, почему Consul часто всплывает рядом с Patroni как DCS — etcd и Consul решают одну и ту же задачу распределённого хранилища с консенсусом, просто с разным API поверх.
#linux #sysadmin #consul