Обнаружение службы с помощью Docker и Consul: часть 1

За последний год я стал большим поклонником использования Consul для всего, что связано с обнаружением сервисов. Если вы пользуетесь микросервисами, вы, вероятно, столкнулись с проблемой, заключающейся в том, что с увеличением количества создаваемых вами услуг становится все сложнее управлять связью между всеми этими службами. Консул обеспечивает идеальное решение этой проблемы. Он предоставляет простой в использовании, открытый (основанный на стандартах) подход к обнаружению услуг (и, кроме того, предоставляет большой набор других функций). Недавно я выступил с докладом о том, как выполнить обнаружение служб в архитектуре микросервисов с помощью Consul , и получил несколько запросов, чтобы объяснить немного больше об этом. Итак, в этой статье и нескольких последующих действиях я расскажу немного больше о том, как вы можете использовать Консул. Я не просто остановлюсь только на части обнаружения услуг, предоставляемой консулом, но также покажу вам пару других функций, предоставляемых консулом или одним из инструментов, его окружающих. Обратите внимание, что все примеры, файлы Docker и т. Д. Можно найти в следующем репозитории: https://github.com/josdirksen/next-build-consul . Поэтому вместо «копирования и вставки» из этой статьи просто клонируйте репозиторий.

Начиная

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

Чтобы выполнить все это, нам сначала нужно предпринять следующие шаги для настройки среды, в которой мы можем запускать сервисы:

Примечание: я использую docker-machine на моем Mac, чтобы сделать все это. Если вы используете Windows или Linux, команды могут немного отличаться. Будем надеяться, что Docker для Mac (и Windows) быстро выйдет из бета-версии ( https://blog.docker.com/2016/03/docker-for-mac-windows-beta/) , поэтому нам это больше не нужно …

1. Создайте четыре док-машины: одну, на которой мы запустим сервер Consul, и три, на которых мы запустим наши отдельные сервисы и агента Consul.
2. Запустите главный консул-сервер: мы будем использовать один сервер Consul (и несколько агентов Consul, подробнее об этом позже), чтобы отслеживать работающие службы и некоторые связанные с докером вещи.
3. Настройка Docker Swarm : чтобы избежать необходимости развертывания наших служб по отдельности, мы будем использовать Docker Swarm для управления тремя узлами, на которых мы будем запускать наши службы. В оставшейся части этой статьи мы будем использовать docker-compose для запуска и остановки отдельных сервисов.
4. Настройка оверлейной сети Docker: если мы хотим, чтобы наши сервисы общались друг с другом простым способом, мы создадим оверлейную сеть. Это позволит компонентам, которые мы развертываем в Docker, легко общаться друг с другом (так как они будут использовать одну подсеть)
5. Запустите агентов Консула: у каждого узла будет свой собственный агент консула, который будет следить за состоянием служб на этом узле и связываться с сервером консула.

Создание докер-машин

Итак, первое, что мы сделаем, это создадим несколько докеров. Сначала мы создадим докер-машину, которая будет содержать наш консул-сервер. Причина, по которой мы запускаем этот первый, заключается в том, что мы можем указать другим докер-машинам консультироваться с запущенным внутри этого контейнера и использовать его для управления docker-swarm и оверлейной сетью, которую мы хотим использовать.

Прежде чем мы запустим сервер Consul, давайте кратко рассмотрим архитектуру, лежащую в основе Consul.

На этом изображении вы можете увидеть два режима, в которых может работать Консул. Он может работать в режиме сервера или в режиме агента. Все Серверы общаются друг с другом и решают, кто является лидером. Агент просто общается с одним из серверов и обычно работает на узле, на котором также запущены службы. Обратите внимание, что состояние между всеми серверами и агентами в кластере является общим. Поэтому, когда служба регистрируется у одного из агентов, эта информация становится доступной для всех серверов и агентов, которые связаны друг с другом.

Для этого набора статей мы не будем устанавливать кластер серверов, а просто будем его использовать. Теперь, когда у нас работает докер, мы можем запустить консул-сервер. Прежде чем мы начнем, позвольте мне сначала показать вам простой скрипт, который облегчает переключение между различными докер-машинами и псевдонимом, который мы используем, чтобы избежать ввода «docker-machine».

Таким образом, с этими псевдонимами, сначала мы делаем «dm-env nb-consul», чтобы выбрать правильный докер.

Запустить главный консул машины

Затем мы получаем IP-адрес этого сервера, а затем мы можем запустить наш сервер Consul следующим образом.

На данный момент у нас работает консольный сервер Docker. Теперь давайте создадим три других сервера, на которых мы будем запускать наши сервисы.

Настройка Docker Swarm

Как вы можете видеть в следующих командах, мы также одновременно создаем рой-кластер Docker, и узел «nb1» является мастером роя.

На данный момент у нас есть четыре док-машины и работают. Один из них работает мастером-консулом, а другие пока мало что делают.

Прежде чем мы продолжим настройку ведомых устройств, есть еще один полезный скрипт, который может пригодиться:

Этот скрипт добавляет IP-адреса докер-машин в ваш локальный файл «hosts». Это означает, что мы можем просто получить доступ к узлам докера, просто перейдя, например, по адресу « http: //nb-consul.local: 8500 ».

Настройте сеть докеров

В нашем сценарии мы хотим, чтобы все наши сервисы могли общаться друг с другом. У нас есть несколько хостов докеров, поэтому нам нужно найти простой способ, чтобы службы работали в узле «nb1», чтобы иметь возможность общаться с «nb2». Самый простой способ сделать это — создать единую сеть, которая будет использоваться всеми службами, работающими в док-контейнерах. Для этого мы создаем простую «оверлейную» сеть, например:

И поскольку мы создали это на нашем мастере роя, эта сеть будет доступна всем членам нашего роя. Когда мы создадим наши сервисы позже, мы подключим их к этой сети, чтобы они все находились в одной подсети.

Начать консул агентов

Чтобы запустить консулов, мы собираемся использовать docker-compose. Файл docker-compose очень прост и является простым способом избежать ввода всех команд запуска (особенно когда вы делаете живые демонстрации)

Ничего особенного в этом файле. Единственное, что вы можете заметить, это то, что мы используем явные IP-адреса в командах для запуска агентов Консула. Мы могли бы просто использовать для этого переменную окружения, которая устанавливается простым скриптом bash. Но для этой статьи мы просто указываем IP-адреса соответствующих докер-машин. Убедитесь, что ваш «DOCKER_HOST» указывает на мастера роя докеров и запускайте агентов следующим образом:

На данный момент у нас есть сервер Consul, работающий в док-машине «nb-consul», и на наших узлах работают три агента. Чтобы проверить нашу настройку, давайте откроем интерфейс сервера Consul: http: //nb-consul.local: 8500

И, как вы видите, у нас работает 1 сервер (наш сервер Consul) и три агента. Итак, с этого момента мы можем начать добавлять наши сервисы, чтобы перейти к этой архитектуре:

Добавление услуг

Сервисы в этом случае — просто простые приложения golang. Я создал простое приложение, которое может работать в веб-интерфейсе или в бэкэнд-режиме. В режиме внешнего интерфейса он предоставляет минимальный пользовательский интерфейс с кнопкой для вызова бэкэнд-службы, а в режиме внутреннего интерфейса он предоставляет простой API, который возвращает некоторую информацию вызывающей стороне, и предоставляет простой интерфейс, показывающий некоторую статистику. Для удобства я перенес это изображение в концентратор докеров ( https://hub.docker.com/r/josdirksen/demo-service/ ), чтобы вы могли легко использовать его без необходимости сборки из исходного репозитория github.

Как вы можете видеть из предыдущего обзора архитектуры, мы хотим запустить интерфейс и бэкэнд-сервис на каждом из узлов. Мы могли бы сделать это вручную, но, поскольку у нас есть docker-swarm, мы можем легко сделать это через один файл docker-compose. Если вы хотите посмотреть, как этот файл выглядит, вы можете проверить источники здесь ( https://github.com/josdirksen/next-build-consul) .

Давайте сначала запустим сервисы, а затем посмотрим, как они регистрируются в Консуле:

Как вы можете видеть в последнем выводе «docker ps», у нас работают три интерфейса, три сервера и три агента консула. Это в значительной степени та архитектура, к которой мы стремимся. Мы также можем увидеть это, когда откроем Консул:

Как видите, у нас есть три внешних сервиса и три внутренних сервиса, зарегистрированных в Консуле. Если мы откроем один из бэкэндов, мы увидим некоторую общую информацию:

И мы можем использовать интерфейс внешнего интерфейса, чтобы вызвать один из наших бэкэндов:

Однако есть пара вопросов, на которые мы должны ответить:

1. Регистрация сервиса : когда мы запускаем бэкэнд или фронтенд сервис, мы видим его в Консуле. как нам это сделать?
2. Обнаружение службы : и когда мы нажимаем кнопку на веб-службе, вызывается одна из внутренних служб. Как веб-интерфейс узнает, какую службу позвонить?

В следующих разделах мы рассмотрим эти вопросы поближе.

Служба регистрации

Во-первых, регистрация сервиса. Чтобы зарегистрировать услугу в Консуле, мы должны сделать очень простой вызов REST нашему местному консулу-агенту, который выглядит примерно так:

Как видите, мы указываем имя, адрес и порт, где находится служба, и добавляем дополнительную проверку работоспособности. Когда healtcheck возвращает что-то в диапазоне 200, служба помечается как исправная и может быть обнаружена другими службами. Так, как мы делаем это для наших услуг. Если вы посмотрите на источники для этого примера, вы можете найти файл «script / entrypoint.sh», который выглядит следующим образом:

Что делает этот скрипт, так это то, что он создает JSON для отправки на консул-агент, и перед запуском основного приложения он использует «curl» для его отправки. Поэтому, когда служба запускается, она автоматически регистрируется в локальном агенте консула (обратите внимание, что вы также можете сделать это более автоматически, например, с помощью Consul Registrator . Это работает, поскольку мы можем просто ссылаться на локального агента по его имени, поскольку он находится в тот же самый контроллер. Если вы посмотрите внимательно, вы можете увидеть, что здесь мы используем пару переменных окружения. Они передаются через файл docker-compose, который мы используем:

Интересная часть здесь — записи DNS. Как вы помните, 192.168.99.106 — это адрес нашего консул-сервера. Это означает, что мы проводим поиск DNS против Консула (мы могли бы также указать на агента консула).

Обнаружение услуг

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

Круто верно? Мы можем обнаружить сервис, просто используя DNS. Это также означает, что интегрировать это в наши существующие приложения очень просто, поскольку мы можем просто полагаться на базовое разрешение DNS. Например, в веб-сервисе мы вызываем бэкэнд, используя этот код:

Это вызывает одну из внутренних служб, использующих DNS. Теперь у нас также есть простое переключение при сбое, так как временное время DNS Consul установлено в 0. Приложения могут все еще выполнять некоторое кэширование, но это означает, что у нас уже есть некоторое базовое переключение:

Что, конечно, также работает для нашего приложения frontend / golang:

В продолжении этой статьи мы также покажем более продвинутую отработку отказа, представив HAProxy в качестве промежуточного звена для более продвинутых методов отработки отказа.

Выводы

Это в значительной степени завершает эту первую статью. Итак, в заключение, что мы сделали:

1. Мы настроили простую архитектуру, используя 4 док-узла. 1 для сервера консула и три для наших услуг.
2. Службы регистрируются в Консуле при запуске службы.
3. Нам не нужно явно что-то делать, чтобы включить обнаружение службы. Мы можем использовать стандартный DNS для поиска службы.
4. Consul использует TTL 0 для DNS и возвращает доступные сервисы, используя roundrobin. Как вы уже видели, вы уже можете использовать это для базового переключения при сбое, когда поиск DNS не удается.

Следите за новостями в ближайшие недели.