Як налаштувати Consul для Service Discovery: DNS, Health Checks та Mesh

# /etc/consul.d/server.hcl
datacenter = "dc1"
data_dir = "/opt/consul"
log_level = "INFO"
server = true
bootstrap_expect = 3
# чекаємо 3 серверні ноди для старту кластера
bind_addr = "{{ GetPrivateIP }}"
client_addr = "0.0.0.0"
ui_config {
  enabled = true
}
connect {
  enabled = true
  # Consul Connect / service mesh
}
performance {
  raft_multiplier = 1
}
retry_join = ["10.0.0.11", "10.0.0.12", "10.0.0.13"]

Конфіг клієнтського агента (на кожній ноді з сервісами):

# /etc/consul.d/client.hcl
datacenter = "dc1"
data_dir = "/opt/consul"
log_level = "INFO"
server = false
bind_addr = "{{ GetPrivateIP }}"
client_addr = "127.0.0.1"
retry_join = ["10.0.0.11", "10.0.0.12", "10.0.0.13"]

Запускаємо Consul як systemd-сервіс. Без ACL-політик кластер небезпечний — налаштовуємо їх після bootstrap.

Швидке налаштування за 5 кроків:

1. Розгорніть 3 server-ноди з конфігурацією вище.
2. Встановіть клієнтський агент на кожну обчислювальну ноду.
3. Налаштуйте health checks для кожного сервісу (тип, інтервал, deregister_critical_service_after).
4. Інтегруйте DNS через systemd-resolved: додайте DNS=127.0.0.1:8600 та Domains=~consul.
5. Увімкніть Consul Connect та налаштуйте sidecar-проксі для mTLS.

Як налаштувати health check та DNS для сервісів?

Consul підтримує HTTP, TCP, gRPC та скриптові перевірки. Рекомендований інтервал — 10 секунд, таймаут — 3 секунди. Параметр deregister_critical_service_after критично важливий: без нього мертвий сервіс залишається в каталозі назавжди. Встановіть його в 30 секунд для автоматичного видалення. За результатами навантажувальних тестів, налаштування health checks з HTTP endpoint знижує час виявлення збоїв до 10 секунд проти 30 секунд для TCP-перевірок.

Consul відповідає на DNS-запити за адресою 127.0.0.1:8600. Формат: <service>.service.<datacenter>.consul.

# Знайти адресу сервісу через DNS
dig @127.0.0.1 -p 8600 payment-api.service.dc1.consul
dig @127.0.0.1 -p 8600 payment-api.service.dc1.consul SRV # з портом

Щоб застосунки на ноді використовували стандартний DNS, налаштовуємо systemd-resolved. Після цього curl http://payment-api.service.consul:8080/api працює без вказівки порту 8600.

Consul Connect та mTLS: захист трафіку

Consul Connect додає взаємну TLS-аутентифікацію через sidecar-проксі (Envoy). Трафік шифрується автоматично, доступ контролюється через Intentions. Наприклад, consul intention create checkout-service payment-api дозволяє запити від checkout.

Конфіг sidecar proxy:

{
  "service": {
    "name": "payment-api",
    "port": 8080,
    "connect": {
      "sidecar_service": {
        "proxy": {
          "upstreams": [
            {
              "destination_name": "database",
              "local_bind_port": 5432
            }
          ]
        }
      }
    }
  }
}

Застосунок конектиться до localhost:5432, проксі шифрує та маршрутизує трафік до бази даних через mTLS.

Які метрики моніторити та як забезпечити HA?

Для стабільної роботи кластера відстежуйте:

• Raft-метрики (leader, commit time, log size)
• Serf-метрики (memberlist, gossip)
• Відсоток успішних health checks (SLO > 99.9%)
• Кількість зареєстрованих сервісів
• Затримка DNS-відповідей (p99 < 10ms)

Ці метрики можна експортувати в Prometheus та візуалізувати в Grafana. Впровадження моніторингу скорочує MTTR на 30% за досвідом наших проєктів.

Забезпечення високої доступності:

• Мінімум 3 server-ноди в Raft-кластері.
• Розміщення в різних зонах доступності (multi-AZ).
• Резервне копіювання снапшотів стану кожні 2 години.
• ACL та TLS для захисту від несанкціонованого доступу.
• Налаштування резервного кластера в іншому датацентрі (WAN federation).

Що входить в роботу: deliverables

• Розгортання 3-нодового кластера з базовою конфігурацією
• Налаштування health checks для всіх сервісів
• Інтеграція DNS через systemd-resolved
• Налаштування ACL та TLS для агентів (безпека)
• Впровадження Consul Connect з Envoy sidecar (опціонально)
• Документація з експлуатації та архітектури
• Навчання команди — 2 сесії по 1 годині
• Підтримка протягом 30 днів після здачі

Наша команда має досвід впровадження Consul на більш ніж 15 проектах — від стартапів до enterprise. Гарантуємо стабільну роботу кластера навіть при пікових навантаженнях. Ми пропонуємо налаштування Consul під ключ. Залиште заявку — оцінимо ваш проект.

Порівняння Consul з альтернативами

Типові помилки та як їх уникнути

• Ігнорування ACL. Consul за замовчуванням працює без аутентифікації — будь-хто може прочитати або змінити конфігурацію. Завжди вмикайте ACL.
• Відсутність deregister_critical_service_after. Мертві сервіси залишаються в каталозі назавжди. Встановлюйте 30 секунд.
• Одина серверна нода в production. При її падінні кластер повністю втрачає працездатність. Мінімум 3 ноди.
• Неправильний інтервал health checks. Занадто часті (кожні 1 с) створюють зайве навантаження, занадто рідкі (30 с+) запізнюються з виявленням збоїв. Оптимум — 10 секунд.

Орієнтовні терміни та вартість

Вартість розраховується індивідуально в залежності від складності. При цьому економія на ліцензіях та обслуговуванні може досягати 40%. Наприклад, базове налаштування кластера коштує від 800$. Замовте налаштування Consul зараз — отримайте готову архітектуру за 2-3 дні.