задний план
Поскольку текущий реестр использования основного продукта компанииconsul,consulДля обеспечения высокой доступности требуется кластеризация.Традиционный метод (Nginx/HAProxy) будет иметь проблему с единой точкой отказа.Чтобы решить эту проблему, я начал изучать, как полагаться только наconsulСпособ сделать регистрацию кластера, после дня метания, наконец-то проверил, что может пройтиКластерная версия ConsulClientПри регистрации кластера я также столкнулся с некоторыми проблемами в процессе развертывания и внедрения.Настоящим я записываю и делюсь этим, надеясь помочь нуждающимся студентам.
Сравнение кластера кластеров версии хоста и докера
Развертывание кластера в режиме переадресации клиент+сервер включает два варианта: первый — прямое развертывание в режиме хоста, второй — два.client+3server, каждыйconsulИнстанс развертывает хост (подходит для местных тиранов).Преимущества этого режима - простое насилие и относительно простая эксплуатация и обслуживание. Схема развертывания архитектуры этого режима выглядит следующим образом:
Выбираем другой экономичный режим,dockerПреимущество в экономии ресурсов, а недостаток в управлении многимиdockerЗеркало, до внедрения платформ управления контейнерами, таких как k8s, последующая деятельностьdockerЭксплуатация и обслуживание этого режима будет более хлопотным.Схема развертывания архитектуры этого режима выглядит следующим образом:
Из архитектурных диаграмм двух вышеупомянутых режимов мы можем ясно понять, что режим развертывания хоста является наиболее простым и прямым, иdockerХотя модель экономит ресурсы, она увеличивает сложность и усложняет эксплуатацию и техническое обслуживание. Однако этот режим должен быть хорошим выбором в текущей контейнерной среде. Причина очень проста. Поскольку ресурсы используются полностью, эксплуатация и обслуживание контейнера могут быть выполнены платформой эксплуатации и обслуживания контейнера, такой как k8s. Давайте попрактикуемся в контейнеризацииconsulРазвертывание кластера.
Подготовка окружающей среды
Здесь подготовлены два виртуальных хоста, поскольку они виртуальные хосты, внешний IP-адрес одинаковый, поэтому мы различаем их по порту.
主机A:192.168.23.222:10385 内网ip:192.168.236.3
主机B:192.168.23.222:10585 内网ip:192.168.236.5
Конфигурация развертывания
Шаг 1. Установите среду Docker на хост(Возьмите Centos в качестве примера)
yum install docker
Шаг 2. Извлеките образ Consul для развертывания.
docker pull consul
Шаг 3. Назначьте IP-сегмент хосту Docker, чтобы предотвратить дублирование нескольких IP-адресов хоста.
- Изменить на хосте А
dockerиз/etc/docker/daemon.jsonфайл, добавьте следующее
"bip": "172.17.1.252/24"
- Редактировать на хосте B
dockerиз/etc/docker/daemon.jsonфайл, добавьте следующее
"bip": "172.17.2.252/24"
Конфигурация здесь для хостаdockerЭкземпляр назначает IP, потому что последующиеdockerБудет выполнена межхостовая регистрация, если она зарегистрирована по умолчанию,dockerЭто внутренняя сеть используемого хоста, которая вызывает повторение IP-адреса, поэтому здесь выполняется ручное распределение IP-адресов.Конечно, вы можете настроить приведенную выше конфигурацию IP-адресов.
Шаг 4: Разверните Consul на хосте A
Node1:
docker run -d --name=node_31 --restart=always \
-e 'CONSUL_LOCAL_CONFIG={"skip_leave_on_interrupt": true}' \
-p 11300:8300 \
-p 11301:8301 \
-p 11301:8301/udp \
-p 11302:8302/udp \
-p 11302:8302 \
-p 11400:8400 \
-p 11500:8500 \
-p 11600:8600 \
consul agent -server -join=172.17.1.1 -bootstrap-expect=3 -node=node31 \
-data-dir=/consul/data/ -client 0.0.0.0 -ui
Здесь выделены несколько параметров:
--name:ДаdockerИмя контейнера, которое отличается для каждого экземпляра контейнера.
-node:ДаconsulНазвание узла, которое отличается для каждого узла
-bootstrap-expect: количество узлов, которые должны запустить кластер, здесь значение равно 3.
-data-dir:ДаconsulКаталог центра обработки данных должен быть указан сconsulРазрешения на чтение и запись, иначе запуск сообщит об ошибке.
После успешного запуска выполните команду для просмотраconsulузел.
docker exec -t node_31 consul members
Результат выглядит следующим образом:
Node Address Status Type Build Protocol DC Segment
node31 172.17.1.1:8301 alive server 1.6.2 2 dc1 <all>
Это указывает на то, что первый узел запускается нормально, а затем остальные узлы хоста A запускаются нормально.
Node2:
docker run -d --name=node_32 --restart=always \
-e 'CONSUL_LOCAL_CONFIG={"skip_leave_on_interrupt": true}' \
-p 9300:8300 \
-p 9301:8301 \
-p 9301:8301/udp \
-p 9302:8302/udp \
-p 9302:8302 \
-p 9400:8400 \
-p 9500:8500 \
-p 9600:8600 \
consul agent -server -join=172.17.1.1 -bootstrap-expect=3 -node=node32 \
-data-dir=/consul/data/ -client 0.0.0.0 -ui
Node3:
docker run -d --name=node_33 --restart=always \
-e 'CONSUL_LOCAL_CONFIG={"skip_leave_on_interrupt": true}' \
-p 10300:8300 \
-p 10301:8301 \
-p 10301:8301/udp \
-p 10302:8302/udp \
-p 10302:8302 \
-p 10400:8400 \
-p 10500:8500 \
-p 10600:8600 \
consul agent -server -join=172.17.1.1 -bootstrap-expect=3 -node=node33 \
-data-dir=/consul/data/ -client 0.0.0.0 -ui
После запуска трех узлов выполните команду для проверки состояния узлов:
docker exec -t node_31 consul operator raft list-peers
Результат выглядит следующим образом:
Node ID Address State Voter RaftProtocol
node32 ee186aef-5f8a-976b-2a33-b20bf79e7da9 172.17.1.2:8300 follower true 3
node33 d86b6b92-19e6-bb00-9437-f988b6dac4b2 172.17.1.3:8300 follower true 3
node31 0ab60093-bed5-be77-f551-6051da7fe790 172.17.1.1:8300 leader true 3
Здесь показано, что триserverузлов завершили развертывание кластера и выбралиnode_31в качестве главного узла. Наконец, разверните клиент в хост-кластере, и все готово.
Node4 (клиентский узел)
docker run -d --name=node_34 --restart=always \
-e 'CONSUL_LOCAL_CONFIG={"leave_on_terminate": true}' \
-p 8300:8300 \
-p 8301:8301 \
-p 8301:8301/udp \
-p 8302:8302/udp \
-p 8302:8302 \
-p 8400:8400 \
-p 8500:8500 \
-p 8600:8600 \
consul agent -retry-join=172.17.1.1 \
-node-id=$(uuidgen | awk '{print tolower($0)}') \
-node=node34 -client 0.0.0.0 -ui
воплощать в жизньdocker exec -t node_31 consul membersкоманда, результат следующий:
Node Address Status Type Build Protocol DC Segment
node31 172.17.1.1:8301 alive server 1.6.2 2 dc1 <all>
node32 172.17.1.2:8301 alive server 1.6.2 2 dc1 <all>
node33 172.17.1.3:8301 alive server 1.6.2 2 dc1 <all>
node34 172.17.1.4:8301 alive client 1.6.2 2 dc1 <default>
Здесь хост АconsulВсе узлы запущены, развертывание кластера завершено, можно сказать, что это однохостовая версия.consulкластер, то следующее, что нам нужно сделать, это поместить хост BconsulЕго можно добавить в кластер хоста А.
Шаг 5: Разверните консуль на хосте B
Node5
docker run -d --name=node_51 --restart=always \
-e 'CONSUL_LOCAL_CONFIG={"skip_leave_on_interrupt": true}' \
-p 11300:8300 \
-p 11301:8301 \
-p 11301:8301/udp \
-p 11302:8302/udp \
-p 11302:8302 \
-p 11400:8400 \
-p 11500:8500 \
-p 11600:8600 \
consul agent -server -join=172.17.1.1 -bootstrap-expect=3 -node=node_51 \
-data-dir=/consul/data/ -client 0.0.0.0 -ui
Node6
docker run -d --name=node_52 --restart=always \
-e 'CONSUL_LOCAL_CONFIG={"skip_leave_on_interrupt": true}' \
-p 9300:8300 \
-p 9301:8301 \
-p 9301:8301/udp \
-p 9302:8302/udp \
-p 9302:8302 \
-p 9400:8400 \
-p 9500:8500 \
-p 9600:8600 \
consul agent -server -join=172.17.1.1 -bootstrap-expect=3 -node=node_52 \
-data-dir=/consul/data/ -client 0.0.0.0 -ui
Node7
docker run -d --name=node_53 --restart=always \
-e 'CONSUL_LOCAL_CONFIG={"skip_leave_on_interrupt": true}' \
-p 10300:8300 \
-p 10301:8301 \
-p 10301:8301/udp \
-p 10302:8302/udp \
-p 10302:8302 \
-p 10400:8400 \
-p 10500:8500 \
-p 10600:8600 \
consul agent -server -join=172.17.1.1 -bootstrap-expect=3 -node=node_53 \
-data-dir=/consul/data/ -client 0.0.0.0 -ui
После развертывания трех серверных узлов хоста B выполняем командуdocker exec -t node_51 consul membersПроверьте состояние узла кластера
Node Address Status Type Build Protocol DC Segment
node_51 172.17.2.1:8301 alive server 1.6.2 2 dc1 <all>
почему толькоnode_51А как насчет этого единственного узла? Проблема в узле? Мы запрашиваем тот же запрос на хосте B, и результаты следующие:
node31 172.17.1.1:8301 alive server 1.6.2 2 dc1 <all>
node32 172.17.1.2:8301 alive server 1.6.2 2 dc1 <all>
node33 172.17.1.3:8301 alive server 1.6.2 2 dc1 <all>
node34 172.17.1.4:8301 alive client 1.6.2 2 dc1 <default>
Узлы хоста А имеют только узлы своих машин, а все узлы хоста Б не зарегистрированы.Почему так? Причина в том,consulСвязанный IP-адрес — это IP-адрес интрасети контейнера, внутренняя связь хоста возможна, но связь между хостами не может передаваться через адрес интрасети, так как мы это делаем? Мы можем перенаправить его с помощью правил маршрутизации и перенаправить адрес внутренней сети запроса хоста A в контейнер хоста B на хост B. Здесь мы начинаем назначать ip контейнеру.
Выполняем следующую команду на хосте A:
route add -net 172.17.2.0 netmask 255.255.255.0 gw 192.168.236.5
Эта команда означает, добавить правило маршрутизации172.17.2.1~172.17.2.254Диапазон IP-запросов, все перенаправлены на192.168.236.5По адресу это наш хост Б.
Точно так же хост B также выполняет следующие команды:
route add -net 172.17.1.0 netmask 255.255.255.0 gw 192.168.236.3
После завершения добавления выполнитеdocker exec -t node_53 consul membersЗаказ:
Node Address Status Type Build Protocol DC Segment
node31 172.17.1.1:8301 alive server 1.6.2 2 dc1 <all>
node32 172.17.1.2:8301 alive server 1.6.2 2 dc1 <all>
node33 172.17.1.3:8301 alive server 1.6.2 2 dc1 <all>
node_51 172.17.2.1:8301 alive server 1.6.2 2 dc1 <all>
node_52 172.17.2.2:8301 alive server 1.6.2 2 dc1 <all>
node_53 172.17.2.3:8301 alive server 1.6.2 2 dc1 <all>
node34 172.17.1.4:8301 alive client 1.6.2 2 dc1 <default>
Присоединение к кластеру выполнено успешно, что завершает объединение контейнера Docker между хостами.
Наконец, разверните один на хосте B.client
Node8 (клиентский узел)
docker run -d --name=node_54 --restart=always \
-e 'CONSUL_LOCAL_CONFIG={"leave_on_terminate": true}' \
-p 8300:8300 \
-p 8301:8301 \
-p 8301:8301/udp \
-p 8302:8302/udp \
-p 8302:8302 \
-p 8400:8400 \
-p 8500:8500 \
-p 8600:8600 \
consul agent -retry-join=172.17.1.1 \
-node-id=$(uuidgen | awk '{print tolower($0)}') \
-node=node54 -client 0.0.0.0 -ui
Все последние узлы кластера успешно добавлены, и результаты следующие:
node31 172.17.1.1:8301 alive server 1.6.2 2 dc1 <all>
node32 172.17.1.2:8301 alive server 1.6.2 2 dc1 <all>
node33 172.17.1.3:8301 alive server 1.6.2 2 dc1 <all>
node_51 172.17.2.1:8301 alive server 1.6.2 2 dc1 <all>
node_52 172.17.2.2:8301 alive server 1.6.2 2 dc1 <all>
node_53 172.17.2.3:8301 alive server 1.6.2 2 dc1 <all>
node34 172.17.1.4:8301 alive client 1.6.2 2 dc1 <default>
node54 172.17.2.4:8301 alive client 1.6.2 2 dc1 <default>
Выполнить команду состояния узлаdocker exec -t node_31 consul operator raft list-peers:
node32 ee186aef-5f8a-976b-2a33-b20bf79e7da9 172.17.1.2:8300 follower true 3
node33 d86b6b92-19e6-bb00-9437-f988b6dac4b2 172.17.1.3:8300 follower true 3
node31 0ab60093-bed5-be77-f551-6051da7fe790 172.17.1.1:8300 leader true 3
node_51 cfac3b67-fb47-8726-fa31-158516467792 172.17.2.1:8300 follower true 3
node_53 31679abe-923f-0eb7-9709-1ed09980ca9d 172.17.2.3:8300 follower true 3
node_52 207eeb6d-57f2-c65f-0be6-079c402f6afe 172.17.2.2:8300 follower true 3
Такой содержит 6server+2clientизconsulКонтейнерный кластер развернут, давайте проверимconsulизwebПанель выглядит следующим образом:
Интеграция приложений
версия кластераconsulМы готовы к развертыванию, так как же нам интегрироваться с приложением? Нам нужно только интегрировать кластерную версиюconsulПросто зарегистрируйте клиент.
Сначала добавьте зависимости
<dependency>
<groupId>com.github.penggle</groupId>
<artifactId>spring-cloud-starter-consul-cluster</artifactId>
<version>2.1.0.RELEASE</version>
</dependency>
Второй шагbootstrap.yml|propertiesуказано вspring.cloud.consul.hostдля нескольких узлов следующим образом:
spring.cloud.consul.host=192.168.23.222:10385,192.168.23.222:10585
Если вы хотите вывести соответствующие журналы регистрации, вы также можете добавить конфигурацию журнала в logback.
<logger name="org.springframework.cloud.consul" level="TRACE"/>
Таким образом, после завершения настройки и успешного запуска мы видим, что регистрация нашего приложения прошла успешно.На следующем рисунке показан результат успешной регистрации, которую я протестировал:
Здесь показано, что мои узлы приложений зарегистрированы на 2 кластера соответственно.clientвыше, черезclientПрокси перенаправляет запрос работоспособномуserver, тем самым понимаяconsulвысокая доступность.
Суммировать
В этой статье не изучается какая-либо техническая галантерея, это чисто обмен опытом работы, в основном оconsulСпособ развертывания кластера, традиционный режим может бытьHAProxyДля завершения развёртывания кластера, но недостатки этого способа очевидны, виртуальный ip всё равно может указывать на неисправную ноду, поэтому используемconsulизclient+serverрежим развертывания кластера черезdockerОн полностью использует ресурсы компьютера, и для обеспечения высокой доступности кластера требуется всего 2 компьютера.