Service Discovery та KV-сховище на Consul: налаштування з ACL

Коли сервіси розосереджені між Kubernetes, bare metal та legacy-системами, ручне налаштування DNS і конфігурацій призводить до простоїв та витоків даних. Ми налаштовуємо HashiCorp Consul для автоматичного виявлення сервісів і централізованого KV-сховища, реалізуючи проєкт під ключ — від кластера до ACL. Наша команда забезпечує стабільну роботу та подальшу підтримку, щоб ваша інфраструктура масштабувалася без збоїв.
Часті запитання

Як налаштувати 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% доступність.

Процес впровадження та типові помилки

  1. Аудит інфраструктури: виявляємо сервіси, вразливості в discovery, вимоги до KV.
  2. Проектування: схема кластера, політики ACL, сценарії бекапу.
  3. Розгортання: Terraform або Ansible для server nodes, агентів, налаштування gossip-шифрування.
  4. Інтеграція: реєстрація сервісів, підключення health checks, міграція конфігів.
  5. Тестування: chaos-тести (відмова ноди, мережеві затримки), перевірка failover.
  6. Деплой у 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 місяць.

Наші компетенції:

Останні роботи

  • Розробка сайту компанії B2B ADVANCE
    Розробка сайту компанії B2B ADVANCE
    1542
  • Розробка веб-додатків для компанії FEEDME
    Розробка веб-додатків для компанії FEEDME
    1394
  • Розробка веб-сайту для компанії БЕЛФІНГРУП
    Розробка веб-сайту для компанії БЕЛФІНГРУП
    1081
  • Розробка інтернет магазину для компанії FURNORO
    Розробка інтернет магазину для компанії FURNORO
    1369
  • Розробка логотипу компанії B2B Advance
    Розробка логотипу компанії B2B Advance
    816
  • Розробка веб-додатків для компанії Enviok
    Розробка веб-додатків для компанії Enviok
    1142