Нужны ли моим образам docker собственные экземпляры consul client?

#docker #consul #service-discovery

#docker #консул #обнаружение службы

Вопрос:

У меня есть докеризованное приложение, разделенное на несколько контейнеров (несколько интерфейсных и серверных серверов, балансировщик нагрузки, mysql, elasticsearch и т.д.). Конфигурация балансировщика нагрузки должна знать, какие контейнеры запущены, и поэтому я регистрирую службы с помощью Consul service discovery.

Но я не совсем уверен, что это хорошая идея запускать агент consul в каждом контейнере docker вместо использования хоста docker для контроля всех запущенных контейнеров docker и регистрации их через HTTP-API Consul.

Есть ли какая-либо лучшая практика, которой я могу следовать?

Ответ №1:

Вам не нужно запускать агент consul в каждом контейнере docker, вы можете просто воспользоваться consul, предоставив его DNS для вашего локального. Следующее не из контейнера, но вы в любом случае получите представление о том, что я делаю.

ниже приведена команда, которую я использую для запуска моего агента

 consul agent -data-dir /var/lib/consul/ -config-dir /etc/consul.d/ -bind 10.X.X.X -dns-port 53 -join consul-master
  

Примечание: я добавил запись / etc /hosts для consul-master с ее IP-адресом, а также добавил сервер имен для 127.0.0.1 в файл /etc /resolv.conf.

В каталоге /etc/ consul.d/ хранится мой файл конфигурации для службы. Ниже приведен пример:

 {
  "service": {
    "name": "stackoverflow",
    "tags": [
      "example"
    ],
    "port": 5000
  }
}
  

Теперь, когда мой агент consul запущен, я могу проверить на любом хосте с помощью агента consul (сервер / клиент) для службы с помощью команды dig или запроса http api следующим образом:

 curl http://stackoverflow.service.consul:80/api/v1/ping
{"success":true,"message":"pong"}
  

Для DNS:

 dig @127.0.0.1 -p 53 stackoverflow.service.consul

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.62.rc1.55.amzn1 <<>> @127.0.0.1 -p 53 tracker.service.consul
; (1 server found)
;; global options:  cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57167
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;tracker.service.consul.        IN  A

;; ANSWER SECTION:
tracker.service.consul. 0   IN  A   X.X.X.X

;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Jul  7 11:29:01 2017
;; MSG SIZE  rcvd: 56
  

Надеюсь, это поможет и даст четкое представление об этом

Комментарии:

1. Это, безусловно, просто позволяет вам разрешать имена хостов, однако, похоже, это все еще не позволяет вам зарегистрировать ваш контейнер в службе Consul?

Ответ №2:

Я не уверен, есть ли лучшие практики, но я нашел это сообщение в блоге очень полезным Автоматическое объявление службы Docker с помощью Registrator. Он рассказывает о нескольких подходах к регистрации сервиса и их преимуществах и недостатках.

Более прямо отвечая на ваш вопрос, нет, вы не должны запускать агент consul внутри каждого контейнера.

Один из вариантов — запустить агент consul на каждом хосте. Затем вы можете использовать что-то вроде Registrator для отслеживания запуска и завершения работы новых контейнеров и автоматического обновления Consul. Главное преимущество заключается в том, что у вашего контейнера есть одна задача — запустить ваше приложение. У регистратора также есть одна задача — следить за событиями запуска / остановки контейнера и записывать их в Consul. Ваши контейнеры могут ничего не знать о consul и все еще участвовать в обнаружении службы.

Существует также шаблон автопилота, который предлагает пойти в другом направлении и сообщить вашему приложению Consul, чтобы оно могло сообщать о своем собственном состоянии и обнаруживать свои собственные зависимости. Большая часть информации, которую я видел по этому шаблону, приходит с радостью (например, этот пост в блоге). Это стоит прочитать, чтобы взглянуть на достижение масштабируемости и устойчивости приложений с другой точки зрения.