Поиск по сайту:

Как настроить Consul в производственной среде на Ubuntu 14.04

Введение

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

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

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

Предпосылки и цели

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

В документации консула рекомендуется иметь 3 или 5 серверов консула в каждом центре обработки данных, чтобы избежать потери данных в случае сбоя сервера. Серверы Consul — это компонент, который выполняет тяжелую работу. Они хранят информацию о службах и информацию о ключе/значении. Нечетное количество серверов необходимо, чтобы избежать тупиковых ситуаций во время выборов.

Помимо серверов консула, другие машины могут запускать агенты консула. Агенты-консулы очень легкие и просто пересылают запросы на серверы. Они обеспечивают метод изоляции ваших серверов и перекладывают ответственность за знание адресов серверов на самих агентов.

Чтобы мы могли реализовать некоторые механизмы безопасности в следующем руководстве, нам нужно назвать все наши машины в одном домене. Это сделано для того, чтобы мы могли выпустить подстановочный SSL-сертификат позже.

Детали наших машин здесь:

Hostname IP Address Role
server1.example.com 192.0.2.1 bootstrap consul server
server2.example.com 192.0.2.2 consul server
server3.example.com 192.0.2.3 consul server
agent1.example.com 192.0.2.50 consul client

Для этой демонстрации мы будем использовать 64-битные серверы Ubuntu 14.04, но любой современный сервер Linux должен работать одинаково хорошо. Когда конфигурация будет завершена, у вас должна быть готовая система, которая позволит вам легко добавлять сервисы, проверки и узлы.

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

Скачиваем и устанавливаем Консул

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

Прежде чем мы рассмотрим приложение консула, нам нужно получить unzip для извлечения исполняемого файла. Обновите кеш пакета локальной системы, а затем установите пакет с помощью apt:

apt-get update
apt-get install unzip

Теперь мы можем заняться получением программы консула. На странице проекта consul есть ссылки для скачивания бинарных пакетов для Windows, OS X и Linux.

Перейдите на страницу выше и щелкните правой кнопкой мыши операционную систему и архитектуру, которые представляют ваши серверы. В этом руководстве, поскольку мы используем 64-битные серверы, мы будем использовать ссылку «amd64» в разделе «linux». Выберите «копировать ссылку» или любую другую аналогичную опцию, которую предоставляет ваш браузер.

В вашем терминале перейдите в каталог /usr/local/bin, где мы будем хранить исполняемый файл. Введите wget и пробел, а затем вставьте URL-адрес, скопированный с сайта:

cd /usr/local/bin
wget https://dl.bintray.com/mitchellh/consul/0.3.0_linux_amd64.zip

Теперь мы можем извлечь бинарный пакет с помощью команды unzip, которую мы установили ранее. Затем мы можем удалить заархивированный файл:

unzip *.zip
rm *.zip

Теперь у вас должна быть доступна команда consul на всех ваших серверах.

Создайте необходимый каталог и структуру системы

Мы можем легко попробовать консул неструктурированным способом, используя команду consul. Это позволит вам протестировать некоторые функции. Мы сделали это в предыдущем руководстве, чтобы ознакомиться с программным обеспечением.

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

Первое, о чем мы должны позаботиться, это создать пользователя, специфичного для нашей задачи. Это стандартный случай разделения привилегий пользователей, поэтому мы будем запускать наши процессы консула с выделенным пользователем.

Создайте пользователя сейчас, набрав:

adduser consul

Вы можете пропустить все подсказки (возможно, вы захотите установить пароль. В противном случае он будет жаловаться), если хотите.

Далее мы создадим иерархию конфигурации, в которой будут храниться различные конфигурации, которые мы будем использовать в зависимости от того, как мы хотим запустить службу. Чтобы упростить эту задачу, мы создадим родительский каталог consul.d в структуре конфигурации /etc и поместим подкаталоги с именами bootstrap, server и client под этим в каждой системе:

mkdir -p /etc/consul.d/{bootstrap,server,client}

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

Нам также нужно создать место, где консул может хранить постоянные данные между перезагрузками. Для этой цели мы создадим каталог в /var/consul и предоставим его пользователю consul, чтобы он мог управлять данными:

mkdir /var/consul
chown consul:consul /var/consul

Имея эту структуру, мы сможем приступить к созданию файлов конфигурации.

Создание конфигурации начальной загрузки

Первая конфигурация, которую нам нужно создать, предназначена для начальной загрузки кластера. Это не очень распространенное событие, поскольку оно необходимо только для первоначального создания кластера. Однако мы собираемся создать файл конфигурации, чтобы мы могли быстро начать работу снова в случае полного выхода из строя кластера.

Вы можете поместить этот файл конфигурации только на один из ваших консул-серверов или на все из них, чтобы дать вам больше возможностей для начальной загрузки. Для этой демонстрации мы поместим его только на server1.

Файлы конфигурации хранятся в простом JSON, поэтому ими довольно легко управлять. Создайте первый файл в подкаталоге bootstrap:

nano /etc/consul.d/bootstrap/config.json

В этом файле мы можем начать с указания, что при использовании этой конфигурации консул должен запускаться как сервер в режиме начальной загрузки:

{
    "bootstrap": true,
    "server": true
}

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

Мы также можем передать каталог данных, который мы создали в /var/consul. Consul будет использовать это для хранения информации о состоянии кластера:

{
    "bootstrap": true,
    "server": true,
    "datacenter": "nyc2",
    "data_dir": "/var/consul"
}

Затем мы хотим внедрить шифрование в протокол шепота, который использует консул. Эта функциональность встроена в систему с общим секретом. Секрет должен быть 16-битной строкой в кодировке Base64. Чтобы получить значение, соответствующее этому значению, мы временно выйдем из файла.

В терминале мы можем использовать команду consul для генерации ключа нужной длины и кодировки. Тип:

consul keygen

X4SYOinf2pTAcAHRhpj7dA==

Скопируйте сгенерированное значение и снова откройте файл конфигурации:

nano /etc/consul.d/bootstrap/config.json

Используйте скопированную строку в качестве значения параметра encrypt:

{
    "bootstrap": true,
    "server": true,
    "datacenter": "nyc2",
    "data_dir": "/var/consul",
    "encrypt": "X4SYOinf2pTAcAHRhpj7dA=="
}

Наконец, мы добавим некоторую дополнительную информацию, чтобы указать уровень журнала и указать, что вы хотите использовать системный журнал для ведения журнала:

{
    "bootstrap": true,
    "server": true,
    "datacenter": "nyc2",
    "data_dir": "/var/consul",
    "encrypt": "X4SYOinf2pTAcAHRhpj7dA==",
    "log_level": "INFO",
    "enable_syslog": true
}

Сохраните и закройте файл, когда закончите.

Создание обычной конфигурации сервера

Теперь, когда наша загрузочная конфигурация завершена, мы можем использовать ее в качестве основы для нашей общей конфигурации сервера. Конфигурация сервера будет использоваться после загрузки кластера.

Начните с копирования файла начальной загрузки с server1 в подкаталог сервера на этом компьютере для редактирования:

cp /etc/consul.d/bootstrap/config.json /etc/consul.d/server

Откройте файл, чтобы внести необходимые изменения:

nano /etc/consul.d/server/config.json

Для начала нам нужно отключить флаг начальной загрузки, поскольку эта конфигурация предназначена для конфигураций без начальной загрузки.

Единственное, что нам нужно изменить для конфигурации сервера, — это указать IP-адреса другого сервера, к которым этот узел должен попытаться присоединиться при запуске. Это обеспечивает автоматическое присоединение, поэтому нам не нужно вручную присоединяться к кластеру после запуска нашего сервера:

{
    "bootstrap": false,
    "server": true,
    "datacenter": "nyc2",
    "data_dir": "/var/consul",
    "encrypt": "X4SYOinf2pTAcAHRhpj7dA==",
    "log_level": "INFO",
    "enable_syslog": true,
    "start_join": ["192.0.2.2", "192.0.2.3"]
}

Параметр encrypt должен быть одинаковым для всех участников системы, поэтому копирование файла уже позаботилось об этом для нас. Учитывайте это при создании новых конфигураций.

Сохраните файл, когда закончите.

Вы должны скопировать содержимое этого файла конфигурации на другие машины, которые будут действовать как ваши серверы консула. Поместите их в файл по адресу /etc/consul.d/server/config.json так же, как вы делали это на первом хосте.

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

{
    "bootstrap": false,
    "server": true,
    "datacenter": "nyc2",
    "data_dir": "/var/consul",
    "encrypt": "X4SYOinf2pTAcAHRhpj7dA==",
    "log_level": "INFO",
    "enable_syslog": true,
    "start_join": ["192.0.2.1", "192.0.2.3"]
}

Сохраните и закройте созданные файлы, когда закончите.

Создание конфигурации клиента

Теперь все настройки нашего сервера завершены. Мы можем сосредоточиться на том, чтобы наша клиентская машина работала с правильной конфигурацией.

Откройте файл конфигурации в подкаталоге клиента на клиентском компьютере:

nano /etc/consul.d/client/config.json

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

Мы начнем с удаления любых упоминаний о параметре bootstrap, так как это применимо только к конфигурациям сервера, и изменим параметр server на false.

Далее мы добавим параметр, указывающий расположение каталога веб-интерфейса. Через некоторое время мы получим необходимые для этого файлы. Место, где они будут находиться, — /home/consul/dist.

Наконец, мы хотим настроить параметр start_join, чтобы вывести список всех наших серверов:

{
    "server": false,
    "datacenter": "nyc2",
    "data_dir": "/var/consul",
    "ui_dir": "/home/consul/dist",
    "encrypt": "X4SYOinf2pTAcAHRhpj7dA==",
    "log_level": "INFO",
    "enable_syslog": true,
    "start_join": ["192.0.2.1", "192.0.2.2", "192.0.2.3"]
}

Сохраните и закройте файл, когда закончите.

Загрузка файлов веб-интерфейса

Теперь, когда мы настроили клиент для обслуживания веб-интерфейса, нам нужно получить фактические файлы, которые позволят нам это сделать.

На веб-сайте консула щелкните правой кнопкой мыши ссылку на веб-интерфейс консула и выберите «копировать местоположение ссылки» или любой другой аналогичный вариант, который у вас есть.

На клиенте используйте su, чтобы стать пользователем consul. Мы собираемся настроить веб-каталог в домашнем каталоге пользователя consul.

su consul
cd ~

Теперь введите wget, затем пробел и вставьте ссылку, которую вы скопировали для загрузки веб-интерфейса. На момент написания статьи это будет выглядеть так:

wget https://dl.bintray.com/mitchellh/consul/0.3.0_web_ui.zip

Разархивируйте загруженный файл и удалите zip-файл:

unzip *.zip
rm *.zip

Это создаст каталог с именем dist в вашем домашнем каталоге. Это каталог, на который мы указали параметр веб-интерфейса в файле конфигурации.

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

exit

Создайте сценарий Upstart

Теперь у нас есть файлы конфигурации. Затем мы можем сосредоточиться на создании скрипта upstart, чтобы наши экземпляры консула автоматически запускались при загрузке и перезапускались в случае возникновения каких-либо проблем.

Поскольку начальная загрузка кластера — это не то, что нам придется делать часто (большую часть времени сам кластер будет сохраняться, и может потребоваться перезапуск одного узла и повторное присоединение к кластеру), мы не будем учитывать начальную загрузку в сценарии upstart. Вскоре мы покажем вам, как выполнить этот процесс вручную.

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

nano /etc/init/consul.conf

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

description "Consul server process"

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

Мы также хотим указать, когда процесс должен остановиться. Используя стандартные уровни запуска Linux, мы можем указать ему останавливать процесс всякий раз, когда он не находится в одном из обычных режимов работы (останавливать процесс при остановке или перезагрузке сервера):

description "Consul server process"

start on (local-filesystems and net-device-up IFACE=eth0)
stop on runlevel [!12345]

Мы можем сказать системе инициализации перезапустить процесс, если он когда-либо неожиданно завершится. Мы также хотим указать пользователя и группу, под которыми должен запускаться процесс. Помните, мы создали пользователя и группу consul, чтобы изолировать процесс:

description "Consul server process"

start on (local-filesystems and net-device-up IFACE=eth0)
stop on runlevel [!12345]

respawn

setuid consul
setgid consul

Наконец, нам нужно предоставить фактическую команду, которую мы хотим запустить. Это будет просто команда consul, запущенная в режиме агента. Мы передадим каталог, содержащий спецификации конфигурации нашего сервера, в качестве аргумента команды:

description "Consul server process"

start on (local-filesystems and net-device-up IFACE=eth0)
stop on runlevel [!12345]

respawn

setuid consul
setgid consul

exec consul agent -config-dir /etc/consul.d/server

Сохраните файл, когда закончите.

Скопируйте содержимое этого файла в файл с именем /etc/init/consul.conf на каждом из ваших серверов, а также на клиенте.

На клиенте нам нужно немного изменить файл. Мы должны изменить описание, чтобы указать на то, что это клиентская машина. Нам также нужно изменить каталог конфигурации, который передается в фактическую команду consul.

Конечный файл должен выглядеть примерно так:

description "Consul client process"

start on (local-filesystems and net-device-up IFACE=eth0)
stop on runlevel [!12345]

respawn

setuid consul
setgid consul

exec consul agent -config-dir /etc/consul.d/client

Сохраните и закройте файл, когда закончите.

Запуск кластера

Теперь у нас есть все необходимое для быстрого запуска кластера консула. Процесс относительно прост.

На сервере, который содержит файл конфигурации начальной загрузки (в нашем случае server1), используйте su, чтобы ненадолго перейти к пользователю consul. Затем мы можем вызвать consul и передать каталог начальной загрузки в качестве аргумента:

su consul
consul agent -config-dir /etc/consul.d/bootstrap

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

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

start consul

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

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

Для этого нажмите CTRL-C в терминале загруженного сервера:

CTRL-C

Теперь вернитесь в свой корневой сеанс и запустите службу консула, как вы это делали с остальными серверами:

exit
start consul

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

Теперь, когда кластер полностью работоспособен, клиентские машины могут подключаться. На клиентской машине выполните ту же процедуру, что и root:

start consul

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

consul members

Node     Address             Status  Type    Build  Protocol
server3  192.0.2.3:8301  alive   server  0.3.0  2
server2  192.0.2.2:8301  alive   server  0.3.0  2
server1  192.0.2.1:8301  alive   server  0.3.0  2
agent1   192.0.2.50:8301    alive   client  0.3.0  2

Подключение к веб-интерфейсу

Мы настроили нашу клиентскую машину для размещения веб-интерфейса кластера. Однако это обслуживается на локальном интерфейсе, а это означает, что оно недоступно для нас через общедоступный интерфейс машины.

Чтобы получить доступ к веб-интерфейсу, мы создадим туннель SSH к клиентскому компьютеру, который содержит файлы пользовательского интерфейса. Consul обслуживает HTTP-интерфейс на порту 8500. Мы туннелируем наш локальный порт 8500 на порт 8500 клиентской машины. На локальном компьютере введите:

ssh -N -f -L 8500:localhost:8500 root@192.0.2.50

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

Теперь в локальном веб-браузере вы можете получить доступ к веб-интерфейсу консула, набрав:

http://localhost:8500

Это даст вам страницу веб-интерфейса по умолчанию:

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

Когда вы закончите использовать веб-интерфейс, вы можете закрыть туннель SSH. Найдите номер pid процесса, используя команду ps и grep для поиска номера порта, который мы переадресовали:

ps aux | grep 8500

1001      5275  0.0  0.0  43900  1108 ?        Ss   12:03   0:00 ssh -N -f -L 8500:localhost:8500 root@192.241.170.60
1001      5309  0.0  0.0  13644   948 pts/7    S+   12:12   0:00 grep --colour=auto 8500

Выделенное число в приведенном выше выводе (в строке, содержащей использованную нами команду туннелирования) — это номер pid, который мы ищем. Затем мы можем передать это команде kill, чтобы закрыть туннель:

kill 5275

Заключение

Теперь у вас должен быть стабильный способ управления вашими членами-консулами. Кластер консул можно быстро и легко настроить и запустить. Дополнительные узлы можно быстро настроить, скопировав файлы конфигурации (consul config и скрипт upstart) существующих серверов.

Хотя теперь у нас есть среда консула, настроенная таким образом, чтобы мы могли легко управлять нашими услугами, мы еще не полностью обезопасили наши коммуникации. В следующем руководстве мы сосредоточимся на том, как настроить проверку SSL-сертификата для шифрования и проверки RPC-соединений наших участников.