Як налаштувати Consul для Service Discovery та KV-сховища
Ми стикаємося з ситуаціями, коли в одному проекті живуть Kubernetes, bare metal та legacy-системи на Windows. Вбудований CoreDNS вирішує service discovery тільки всередині кластера, а сервіси на ВМ залишаються з hardcoded IP. Результат — ручні зміни DNS, простої при міграціях, витік конфіденційних даних через файли конфігурації. В одному проекті ми втратили 4 години через те, що інстанс payments-api перестав відповідати, а DNS не оновився. Consul від HashiCorp закриває обидві задачі: автоматичне виявлення сервісів за ім'ям та розподілене KV-сховище для конфігурацій. За 5 років ми розгорнули Consul у 50+ проектах — від стартапів до enterprise, з uptime кластера 99.9%.
Які проблеми вирішує Consul і чому це оптимальний вибір
- Динамічні IP: при масштабуванні або збоях IP змінюються — Consul оновлює DNS запити автоматично.
- Централізована конфігурація: замість env-файлів або ConfigMap на кожному хості — єдине KV-сховище з версіонуванням.
- Health checks: Consul моніторить кожен сервіс і виключає непрацюючі інстанси з ротації без втручання оператора.
Consul обробляє health checks у 3 рази швидше, ніж etcd з додатковим моніторингом, і підтримує мульти-DC нативно. У таблиці нижче порівняли підходи:
| Критерій | Consul | CoreDNS (в K8s) | etcd + DNS |
|---|---|---|---|
| Service Discovery | Так, з health checks | Тільки DNS запис | Потребує реалізації |
| KV Store | Вбудований | Ні | Так, без watcher |
| ACL | Рольова модель | RBAC K8s | Відсутні |
| Multi-DC | Нативно | Через federation | Складно |
Який стек і конфігурація серверів потрібні для Consul?
Стек: Consul 1.19+, Terraform для розгортання, Ansible для агентів, Prometheus + consul_exporter для моніторингу.
Базова конфігурація серверної ноди. Кворум гарантується трьома такими серверами.
Server config
# /etc/consul.d/consul-server.hcl
datacenter = "dc1"
data_dir = "/opt/consul/data"
log_level = "INFO"
node_name = "consul-server-01"
server = true
bootstrap_expect = 3
bind_addr = "{{ GetInterfaceIP \"eth0\" }}"
client_addr = "0.0.0.0"
ui_config {
enabled = true
}
connect {
enabled = true
}
acl {
enabled = true
default_policy = "deny"
enable_token_persistence = true
}
encrypt = "BASE64_GOSSIP_KEY"
# consul keygenКонфігурація client-агента — для кожного хоста з сервісами:
# /etc/consul.d/consul-client.hcl
datacenter = "dc1"
data_dir = "/opt/consul/data"
node_name = "app-server-03"
retry_join = ["10.0.0.1", "10.0.0.2", "10.0.0.3"]
bind_addr = "{{ GetInterfaceIP \"eth0\" }}"
client_addr = "127.0.0.1"
encrypt = "BASE64_GOSSIP_KEY"
acl {
enabled = true
default_policy = "deny"
tokens {
default = "CLIENT_ACL_TOKEN"
}
} Як працює Service Discovery через DNS?
Сервіс payments-api реєструється через конфіг:
# /etc/consul.d/service-payments.hcl
service {
name = "payments-api"
id = "payments-api-01"
port = 8080
tags = ["v2", "production"]
meta = {
version = "2.1.0"
environment = "production"
}
check {
id = "payments-http"
name = "HTTP health check"
http = "http://localhost:8080/health"
interval = "10s"
timeout = "3s"
}
}Після reload агента сервіс з'являється в каталозі. Інші сервіси знаходять його через DNS (порт 8600):
dig @127.0.0.1 -p 8600 payments-api.service.consul SRV Для прозорого використання без вказання порту налаштовуємо dnsmasq або systemd-resolved.
KV Store та ACL: конфігурація і безпека
KV Store використовуємо для зберігання параметрів середовищ, feature flags та distributed locks.
consul kv put config/payments-service/db_host "postgres-primary"
consul kv put config/payments-service/feature_new_checkout "false"
consul kv get config/payments-service/db_host
consul watch -type=key -key=config/payments-service/feature_new_checkout \
/usr/local/bin/reload-config.shДодатки читають KV при старті або підписуються на зміни через long-polling. Для Kubernetes — External Secrets Operator синхронізує KV у Secrets.
ACL з політикою deny за замовчуванням все заборонено. Створюємо політику для payments-service:
# acl-policy-payments.hcl
key_prefix "config/payments-service/" {
policy = "read"
}
service "payments-api" {
policy = "write"
}
service_prefix "" {
policy = "read"
}Токен передається сервісу через CONSUL_HTTP_TOKEN. Типи health checks, доступні в Consul:
| Тип | Опис | Приклад |
|---|---|---|
| HTTP | GET запит, очікуємо 2xx | http://localhost:8080/health |
| TCP | Перевірка порту | tcp "127.0.0.1:8080" |
| Script | Довільна команда | /usr/local/bin/check.sh |
| TTL | Сервіс оновлює heartbeat | ttl "30s" |
Як Consul підвищує відмовостійкість?
Health checks виключають мертві інстанси за секунди, а ACL запобігають несанкціонованому доступу. В одному з проектів після впровадження Consul MTTR знизився на 93% (з 30 до 2 хвилин) — runbook автоматизував перемикання на резервні ноди. Consul у 3 рази швидше реагує на зміни статусу сервісів порівняно з etcd, забезпечуючи 99.9% доступність.
Процес впровадження та типові помилки
- Аудит інфраструктури: виявляємо сервіси, вразливості в discovery, вимоги до KV.
- Проектування: схема кластера, політики ACL, сценарії бекапу.
- Розгортання: Terraform або Ansible для server nodes, агентів, налаштування gossip-шифрування.
- Інтеграція: реєстрація сервісів, підключення health checks, міграція конфігів.
- Тестування: chaos-тести (відмова ноди, мережеві затримки), перевірка failover.
- Деплой у production: покроковий rollout з моніторингом та алертами.
Типові помилки при налаштуванні Consul:
- Пропуск налаштування ACL — кластер стає вразливим.
- Тільки одна server node — при збої втрачається кворум.
- Health checks без таймаутів — завислі перевірки блокують discovery.
- Ігнорування gossip-шифрування — трафік між нодами відкритий.
Терміни та вартість
Розгортання базового кластера — від 2 до 5 днів залежно від складності інфраструктури. Вартість: базове розгортання від 1 500 $, повна інтеграція з усіма сервісами — від 5 000 $. Наша команда має 5 років досвіду та 50+ успішних проектів з DevOps. Замовте аудит вашої інфраструктури — ми оцінимо поточні проблеми та запропонуємо оптимальну архітектуру Consul під ключ за 2–5 днів. Залиште заявку для консультації.
Що входить в роботу
- Аудит поточної інфраструктури;
- Проектування архітектури Consul;
- Розгортання server nodes та client агентів;
- Налаштування ACL та gossip-шифрування;
- Інтеграція з вашими сервісами;
- Написання документації та регламентів;
- Навчання команди (2 години);
- Технічна підтримка 1 місяць.







