Consul — это инструмент для сервис-дискавери, конфигурации и сегментации сети, разработанный HashiCorp. Чтобы разобраться в его компонентах постепенно, начнём с основ и перейдём к более сложным частям.

Составные части

1. Агенты (Agents)

Что это: Фоновые процессы, работающие на каждом сервере в кластере Consul. Зачем:

  • Общаются с другими агентами.
  • Проверяют здоровье сервисов (health checks).
  • Сообщают о статусе ноды (сервера) в кластере.

Типы агентов:

  • Client Agent – только перенаправляет запросы серверам (не хранит состояние кластера).
  • Server Agent – участвует в принятии решений, хранит данные (stateful).

Совет: Начните с запуска одного агента в режиме dev (consul agent -dev), чтобы посмотреть, как он работает.

2. Сервисы (Services)

Что это: Любое приложение (веб-сервер, БД, микросервис), которое зарегистрировано в Consul. Зачем:

  • Автоматическое обнаружение сервисов (Service Discovery).
  • Мониторинг их состояния (Health Checks).

Как регистрируются:

  • Через конфигурационный файл (например, web-service.json).
  • Через API (consul services register).

Пример:

{
  "service": {
    "name": "web",
    "port": 8080,
    "check": {
      "http": "http://localhost:8080/health",
      "interval": "10s"
    }
  }
}

3. Health Checks (Проверки здоровья)

Что это: Механизм проверки, жив ли сервис. Типы проверок:

  • HTTP – запрос к эндпоинту (например, /health).
  • TCP – проверяет, доступен ли порт.
  • Script – запускает команду (например, ping).

Где используются:

  • Сервис не будет маршрутизироваться, если он “нездоров”.
  • Интеграция с балансировщиками (например, NGINX, Envoy).

4. Ключ-значение хранилище (KV Store)

Что это: Простое хранилище данных (как etcd или Redis, но встроенное в Consul). Зачем:

  • Хранение конфигов.
  • Координация между сервисами (например, блокировки).

Пример:

consul kv put app/config/db_url "postgres://user:pass@db:5432"
consul kv get app/config/db_url

5. DNS-интерфейс

Что это: Consul предоставляет DNS-сервер для обнаружения сервисов. Зачем:

  • Упрощение интеграции (можно использовать стандартный DNS).

Пример:

dig web.service.consul  # Вернёт IP и порт сервиса "web"

6. RPC (Remote Procedure Calls) и Gossip Protocol

Что это: Механизмы общения между агентами.

  • Gossip – для быстрого распространения информации (например, о новых сервисах).
  • RPC – для запросов к серверам (например, список сервисов).

Gossip в Consul: что это и зачем нужно?

Gossip (протокол gossip) — это механизм децентрализованного обмена информацией между нодами Consul, работающий по принципу “слухов” (когда каждая нода периодически обменивается данными со случайными соседями).

Для чего нужен gossip?

  1. Обнаружение сервисов и нод (Service Discovery)
    • Ноды Consul автоматически обнаруживают друг друга без жесткой привязки к центральному серверу.
  2. Распространение информации о состоянии кластера (Membership)
    • Если нода падает, остальные быстро узнают об этом через gossip.
  3. Распространение событий (Event Broadcasting)
    • Например, при развертывании новой версии сервиса можно отправить событие через gossip.
  4. Поддержка работы Multi-Datacenter
    • Gossip помогает синхронизировать данные между разными дата-центрами.

Почему gossip нужно шифровать?

Gossip-трафик по умолчанию передается в открытом виде, что может быть небезопасно. Шифрование gossip нужно, чтобы:

  1. Предотвратить подмену нод (MITM-атаки)
    • Без шифрования злоумышленник может добавить фальшивую ноду в кластер.
  2. Защитить конфиденциальные данные
    • В gossip передаются метаданные о сервисах, IP-адресах и состоянии нод.
  3. Соответствовать требованиям безопасности (PCI DSS, HIPAA и др.)
    • Некоторые стандарты требуют шифрования всего сетевого трафика.

7. ACL (Access Control Lists)

Что это: Система безопасности (управление доступом). Зачем:

  • Ограничение доступа к API/KV.
  • Защита от несанкционированных изменений.

8. Multi-Datacenter Replication

Что это: Consul может работать в нескольких дата-центрах. Зачем:

  • Глобальная синхронизация сервисов.
  • Отказоустойчивость.

Порядок изучения

  1. Запустите consul agent -dev и изучите UI (http://localhost:8500).
  2. Зарегистрируйте сервис + health check.
  3. Поэкспериментируйте с KV-хранилищем.
  4. Попробуйте DNS-запросы.
  5. Разверните кластер из 3 серверов + 1 клиента.
  6. Настройте ACL.
  7. Почитайте про multi-DC.

Настройка на Debian 12

datacenter = "dc1"
data_dir = "/opt/consul"
server = true
bootstrap_expect = 3
client_addr = "0.0.0.0"
bind_addr = "192.168.251.21"
retry_join = ["192.168.251.22", "192.168.251.23"]
ui = tru

bind_addr - адрес ноды retry_join - список адресов других код кластера консул

ui будет доступен по адресу http://192.168.251.21:8500

Настройка TLS

Для настройки HTTPS-соединений между нодами Consul вам нужно выполнить несколько шагов по конфигурации TLS. Вот как это можно сделать:

1. Генерация TLS-сертификатов

Сначала вам нужно создать:

  • Корневой CA сертификат
  • Сертификаты для каждого сервера Consul
# Генерация CA
openssl genrsa -out ca.key 2048
openssl req -new -x509 -days 365 -key ca.key -out ca.crt

# Генерация сертификата для сервера
openssl genrsa -out server.key 2048
openssl req -new -key server.key -out server.csr
openssl x509 -req -days 365 -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out server.crt

2. Настройка Consul конфига

Добавьте в ваш конфиг следующие параметры:

datacenter = "dc1"
data_dir = "/opt/consul"
server = true
bootstrap_expect = 3
client_addr = "0.0.0.0"
bind_addr = "192.168.251.21"
retry_join = ["192.168.251.22", "192.168.251.23"]
ui = true

# TLS конфигурация
verify_incoming = true
verify_outgoing = true
verify_server_hostname = true
ca_file = "/path/to/ca.crt"
cert_file = "/path/to/server.crt"
key_file = "/path/to/server.key"

# Для RPC шифрования
ports {
  https = 8501
}

# Если нужно шифровать gossip трафик
encrypt = "your-encryption-key"

3. Генерация ключа для gossip

consul keygen

Добавьте полученный ключ в параметр encrypt в конфиге.

4. Развертывание

  1. Скопируйте сертификаты (ca.crt, server.crt, server.key) на все сервера Consul
  2. Убедитесь, что права доступа к файлам правильные (обычно consul:consul и 600)
  3. Перезапустите Consul на всех нодах

5. Проверка

consul members -ca-file=/path/to/ca.crt

Важные замечания

  1. Все ноды должны использовать один и тот же CA сертификат
  2. Для production лучше использовать сертификаты от доверенного CA или HashiCorp Vault
  3. Убедитесь, что hostname в сертификатах соответствует именам нод
  4. Можно настроить разные уровни проверки (например, только verify_outgoing для начала)

После настройки весь трафик между нодами (RPC, gossip) будет шифроваться.