centos7, mysql

Установка и настройка кластера Consul Hashicorp

Thank you for reading this post, don't forget to subscribe!

В дан­ной инструк­ции мы рас­смот­рим уста­нов­ку и настрой­ку кла­сте­ра систе­мы обна­ру­же­ния сер­ви­сов Consul. Дан­ный кла­стер будет состо­ять из трех нод.

Подготовка сервера

Выпол­ним пред­ва­ри­тель­ные опе­ра­ции по настрой­ке наших серверов.

1. Уста­нов­ка допол­ни­тель­ных пакетов

Выпол­ня­ем команду:

yum install unzip wget

* где:

  • unzip — необ­хо­дим для рас­па­ков­ки архивов.
  • wget — ути­ли­та для загруз­ки фай­лов по сети.

2. Настра­и­ва­ем время

Зада­ем часо­вой пояс:

timedatectl set-timezone Europe/Moscow

* в дан­ном при­ме­ре мы зада­ем мос­ков­ское вре­мя. Пол­ный пере­чень воз­мож­ных вари­ан­тов мож­но полу­чить коман­дой: timedatectl list-timezones.

Уста­нав­ли­ва­ем ути­ли­ту для син­хро­ни­за­ции времени:

yum install chrony

Запус­ка­ем ее в каче­стве сервиса:

systemctl enable chronyd --now

3. Настрой­ка име­ни серверов

Для сер­ве­ра кон­сул важ­но, что­бы сер­ве­ры были доступ­ны по име­нам. Для нача­ла настро­им последние:

hostnamectl set-hostname consul01.test.local

hostnamectl set-hostname consul02.test.local

hostnamectl set-hostname consul03.test.local

* пред­по­ла­га­ет­ся, что нашим трем сер­ве­рам будут зада­ны име­на consul01, consul02 и consul03. Они будут в домене test.local.

Что­бы сер­ве­ры мог­ли обра­щать­ся друг к дру­гу по име­нам, мы долж­ны либо заре­ги­стри­ро­вать их в локаль­ной систе­ме DNS, либо доба­вить на каж­дом сер­ве­ре запи­си в файл hosts:

vi /etc/hosts

192.168.0.15 consul01.test.local
192.168.0.20 consul02.test.local
192.168.0.25 consul03.test.local

4. Настрой­ка безопасности

Откры­ва­ем пор­ты в брандмауэре:

firewall-cmd --add-port={8300,8301,8302,8500,8600}/tcp --permanent

firewall-cmd --add-port={8301,8302,8600}/udp --permanent

firewall-cmd --reload

Установка и запуск Consul

Consul  -

при­ло­же­ние для обна­ру­же­ния сер­ви­сов (service discovery) на осно­ве DNS и про­вер­ки их доступ­но­сти. Оно исполь­зу­ет­ся для обес­пе­че­ния свя­зи меж­ду ком­по­нен­та­ми мик­ро­сер­вис­ной инфра­струк­ту­ры, поз­во­ляя созда­вать отка­зо­устой­чи­вую и мас­шта­би­ру­е­мую систе­му с воз­мож­но­стью балан­си­ров­ки нагруз­ки. Consul раз­ра­бо­тан ком­па­ни­ей HashiCorp, кото­рой так­же при­над­ле­жат дру­гие попу­ляр­ные про­дук­ты, напри­мер, Vagrant, TerraForm, Atlas, Vault.

Реги­стра­ция сер­ви­сов в кон­су­ле про­из­во­дит­ся с помо­щью функ­ции Consul Connect. Так­же реги­стри­ру­ют­ся поли­ти­ки вза­и­мо­дей­ствия, напри­мер, мы можем ука­зать, что сер­вис 1 может вза­и­мо­дей­ство­вать с сер­ви­сом 2, но не может вза­и­мо­дей­ство­вать с сер­ви­сом 3. Так­же для реги­стра­ции сво­е­го при­ло­же­ния доступ­на HTTP API или кон­фи­гу­ра­ци­он­ные фай­лы само­го кон­су­ла (при нали­чии под­держ­ки со сто­ро­ны приложения).

При­ло­же­ние может быть уста­нов­ле­но на сер­ве­ры под управ­ле­ни­ем всех попу­ляр­ных систем: Linux, Windows, MacOS, BSD. Под­дер­жи­ва­ют­ся сле­ду­ю­щие спо­со­бы установки:

  1. Копи­ро­ва­ние в систе­му бинар­но­го файла.
  2. Сбор­ка при­ло­же­ния из исходников.
  3. Уста­нов­ка в Kubernetes.
  4. В виде кон­тей­не­ра Docker.

При­ло­же­ние рабо­та­ет на сле­ду­ю­щих портах:

Порт Про­то­кол Опи­са­ние
8600 TCP and UDP Сер­вер DNS
8500 TCP Consul UI + API
8301 TCP and UDP Порт LAN
8302 TCP and UDP Порт WAN
8300 TCP Сер­вис RPC
21000 - 21255 Диа­па­зон пор­тов для реги­стра­ции сервисов
8501 TCP Защи­щен­ный Consul UI + API. По умол­ча­нию, не настро­ен и зада­ет­ся любой. Дан­ный номер реко­мен­до­ван в офи­ци­аль­ной документации.
8502 gRPC API. По умол­ча­нию, не настро­ен и зада­ет­ся любой. Дан­ный номер реко­мен­до­ван в офи­ци­аль­ной документации.

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

Установка

Уста­нов­ка будет выпол­не­на путем копи­ро­ва­ния бинар­но­го фай­ла. Для нача­ла перей­дем на стра­ни­цу загруз­ки про­грамм­но­го про­дук­та и посмот­рим его послед­нюю версию.

После под­ста­вим нуж­ную вер­сию в переменную:

export VER="1.9.5"

* в моем при­ме­ре будет уста­нав­ли­вать­ся вер­сия 1.9.5.

После загру­жа­ем архив с бинарником:

wget https://releases.hashicorp.com/consul/${VER}/consul_${VER}_linux_amd64.zip

И рас­па­ко­вы­ва­ем его:

unzip consul_${VER}_linux_amd64.zip

Копи­ру­ем полу­чен­ных бинар­ник в ката­лог /usr/bin:

mv consul /usr/bin/

Про­ве­ря­ем, что при­ло­же­ние может запус­кать­ся в наших системах:

consul -v

Мы долж­ны уви­деть что-то на подобие:

Consul v1.9.5
Revision 3c1c22679
Protocol 2 spoken by default, understands 2 to 3 (agent will automatically use protocol >2 when speaking to compatible agents)

Мож­но пере­хо­дить к настройке.

Настройка

Созда­ем учет­ную запись, от кото­рой будет рабо­тать консул:

useradd -r -c 'Consul DCS service' consul

* в дан­ном при­ме­ре мы созда­дим учет­ную запись consul, кото­рая будет систем­ной. Так­же мы доба­вим неболь­шой комментарий.

Созда­ем ката­ло­ги для при­ло­же­ния консул:

mkdir -p /var/lib/consul /etc/consul.d

И выста­вим на него нуж­ные права:

chown consul:consul /var/lib/consul /etc/consul.d

chmod 775 /var/lib/consul /etc/consul.d

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

Сге­не­ри­ру­ем ключ для кон­су­ла на любой из нод кластера:

consul keygen

zpjf5a4reDbJFpT6FeaF0LGxD0zBRPSRbIoUkLBt0ps=

Полу­чен­ный ключ сохра­ня­ем. Его мы будем исполь­зо­вать при настрой­ке всех узлов кластера.

Созда­ем кон­фи­гу­ра­ци­он­ный файл для консула:

vi /etc/consul.d/config.json

* где:

  • bind_addr — адрес, на кото­ром будет слу­шать наш сер­вер кон­сул. Это может быть IP любо­го из наших сете­вых интер­фей­сов или, как в дан­ном при­ме­ре, все.
  • bootstrap_expect — ожи­да­е­мое коли­че­ство сер­ве­ров в кластере.
  • client_addr — адрес, к кото­ро­му будут при­вя­за­ны кли­ент­ские интерфейсы.
  • datacenter — при­вяз­ка сер­ве­ра к кон­крет­но­му дата­цен­тру. Нужен для логи­че­ско­го раз­де­ле­ния. Сер­ве­ры с оди­на­ко­вым дата­цен­тром долж­ны нахо­дить­ся в одной локаль­ной сети.
  • data_dir — ката­лог для хра­не­ния данных.
  • domain — домен, в кото­ром будет заре­ги­стри­ро­ван сервис.
  • enable_script_checks — раз­ре­ша­ет на аген­те про­вер­ку работоспособности.
  • dns_config — пара­мет­ры для настрой­ки DNS.
  • enable_syslog — раз­ре­ше­ние на веде­ние лога.
  • encrypt — ключ для шиф­ро­ва­ния сете­во­го тра­фи­ка. В каче­стве зна­че­ния исполь­зу­ем сге­не­ри­ро­ван­ный ранее.
  • leave_on_terminate — при полу­че­нии сиг­на­ла на оста­нов­ку про­цес­са кон­су­ла, кор­рект­но отклю­чать ноду от кластера.
  • log_level — мини­маль­ный уро­вень собы­тия для отоб­ра­же­ния в логе. Воз­мож­ны вари­ан­ты "trace", "debug", "info", "warn", and "err".
  • rejoin_after_leave — по умол­ча­нию, нода поки­да­ю­щая кла­стер не при­со­еди­ня­ет­ся к нему авто­ма­ти­че­ски. Дан­ная опция поз­во­ля­ет управ­лять дан­ным поведением.
  • retry_join — пере­чис­ля­ем узлы, к кото­рым мож­но при­со­еди­нять кла­стер. Про­цесс будет повто­рять­ся, пока не завер­шить­ся успешно.
  • server — режим рабо­ты сервера.
  • start_join — спи­сок узлов кла­сте­ра, к кото­рым про­бу­ем при­со­еди­нить­ся при загруз­ке сервера.
  • ui_config — кон­фи­гу­ра­ция для гра­фи­че­ско­го веб-интерфейса.

Про­ве­ря­ем кор­рект­ность кон­фи­гу­ра­ци­он­но­го файла:

consul validate /etc/consul.d/config.json

Мы долж­ны увидеть:

…
Configuration is valid!

В завер­ше­ние настрой­ки созда­дим юнит в systemd для воз­мож­но­сти авто­ма­ти­че­ско­го запус­ка сервиса:

vi /etc/systemd/system/consul.service

Обра­ти­те вни­ма­ние, что в дан­ном при­ме­ре ука­зан сер­вер consul01.test.local. Мы долж­ны заме­нить это зна­че­ние для каж­до­го из настра­и­ва­е­мых сер­ве­ров. Таким обра­зом, у нас будет три фай­ла с раз­ны­ми зна­че­ни­я­ми для опции node.

Пере­чи­ты­ва­ем кон­фи­гу­ра­цию systemd:

systemctl daemon-reload

Систе­ма уста­нов­ле­на, настро­е­на и гото­ва к запуску.

Запуск и проверка

Стар­ту­ем наш сервис:

systemctl start consul

Так­же раз­ре­ша­ем авто­ма­ти­че­ский старт при запус­ке сервера:

systemctl enable consul

Смот­рим теку­щее состо­я­ние рабо­ты сервиса:

systemctl status consul

Мы долж­ны уви­деть состояние:

…
Active: active (running) since …
…

Состо­я­ние нод кла­сте­ра мы можем посмот­реть командой:

consul members

А дан­ной коман­дой мож­но уви­деть допол­ни­тель­ную информацию:

consul members -detailed

Так­же у нас дол­жен быть досту­пен веб-интер­фейс по адресу:
http://<IP-адрес любо­го сер­ве­ра консул>:8500. Перей­дя по нему, мы долж­ны уви­деть стра­ни­цу со ста­ту­сом наше­го кластера.