目录
[1. 安装Gliderlabs/Registrator](#1. 安装Gliderlabs/Registrator)
[1.1 主要功能和用途](#1.1 主要功能和用途)
[1.2 工作流程](#1.2 工作流程)
[2.1 安装Consul-Template](#2.1 安装Consul-Template)
[2.2 准备模板文件](#2.2 准备模板文件)
[2.3 安装nginx](#2.3 安装nginx)
[2.4 启动template服务](#2.4 启动template服务)
引言
在当今微服务架构盛行的时代，服务发现与配置管理成为了构建高可用、易扩展应用的关键技术之一。Docker作为容器化技术的代表，以其轻量、高效的特性成为部署微服务的首选。而Consul，作为一套服务网格解决方案，不仅提供了服务发现与配置管理的功能，还集成了健康检查、KV存储等特性，与Docker配合使用，可以轻松构建起一套动态、可靠的微服务生态系统。本文将探讨如何在Docker环境下利用Consul实现服务的自动发现与更新。
一、服务注册与发现
服务注册与发现是微服务架构中的两个关键概念，对于构建可扩展、高可用的分布式系统至关重要。下面我将详细介绍这两个概念及其工作流程
（一）服务注册
服务注册是指服务实例在启动时将其自身的信息（如IP地址、端口号、服务ID、健康检查URL等元数据）注册到一个集中式的服务注册中心的过程。这样做的目的是让其他服务能够发现并访问到它。服务注册中心可以是Eureka、Consul、Zookeeper、Etcd等。
（二）服务发现
服务发现则是指客户端或服务间通过查询服务注册中心来查找所需服务实例的信息，并基于这些信息建立连接进行通信的过程。服务发现通常包括两个方面：
- 服务列表获取：客户端或服务向注册中心请求服务列表，注册中心返回当前所有可用服务实例的地址信息。
- 动态更新：一旦服务实例的状态发生改变（如新增、下线、故障转移），注册中心会实时通知相关客户端或服务，使得它们能够及时调整，使用最新的服务实例信息
（三）工作流程示例
-
服务启动：当一个微服务启动时，它会将自己的网络位置信息（IP、端口等）以及其它元数据发送给服务注册中心进行注册。
-
注册中心记录：服务注册中心接收到服务实例的信息后，将其存储起来，维护一个所有服务实例的可用性列表。
-
服务发现：当另一个服务需要调用该服务时，它不是直接通过硬编码的地址去访问，而是先向服务注册中心查询所需服务的所有可用实例。
-
获取实例信息：服务注册中心返回包含所有可用服务实例地址的信息列表。
-
负载均衡与连接：客户端或服务根据一定的策略（如轮询、随机、最少连接数等）从返回的实例列表中选择一个服务实例进行连接。
-
健康检查与动态更新：服务注册中心持续监控各个服务实例的健康状态，如果某个服务实例宕机或不可用，注册中心会将其从列表中移除，并通知所有订阅该服务变化的应用，实现服务实例列表的动态更新。
二、Consul的概念
（一）概念与特性
Consul是一个分布式、高可用的系统，专为微服务架构设计，提供了以下几个核心功能：
服务发现：允许服务自动注册和发现其他服务，无需硬编码服务地址。
健康检查：定期检查服务的健康状态，确保服务的可用性。如果一个服务实例不健康，Consul 会将其标记为不可用，同时通知其他服务实例进行相应的调整，保证系统的稳定性
KV存储：提供键值对存储，用于动态配置管理。
多数据中心：天然支持多数据中心部署，保证服务的地理分布式高可用。
（二）consul的两种模式
Consul作为一种服务网格解决方案，支持两种主要的工作模式，分别是客户端（Client）模式 和服务器（Server）模式。这两种模式共同协作，为微服务架构提供了服务发现、配置管理和健康检查等功能。
1.客户端（Client）模式
作用：
- 客户端模式的Consul代理主要负责本机上运行服务的注册与健康检查信息上报给服务器模式的Consul节点。
- 它还提供本地服务发现能力，允许本地应用查询服务目录。
- 客户端模式的代理可以作为DNS或HTTP接口，使得本地服务可以查询注册到Consul的服务列表。
特点：
- 通常每个参与服务发现的服务节点都会运行一个Consul客户端代理。
- 客户端代理是无状态的，不参与Raft一致性协议投票，也不持久化数据。
- 客户端代理之间通过Gossip协议进行通信，保持集群成员和健康状态的信息同步。
2.服务器（Server）模式
作用：
- 服务器模式的Consul节点负责维护服务目录的状态和数据的一致性。
- 它们构成了Consul集群的心脏，参与Raft共识算法，确保服务注册信息的一致性和高可用性。
- 服务器模式存储所有的配置信息和健康检查状态，并且在集群中复制这些数据，确保数据的持久性和灾难恢复能力。
特点：
- 为了保证高可用性，推荐在每个数据中心至少部署3个或5个服务器节点。
- 服务器节点需要更多的计算资源和存储资源，因为它们承担了数据持久化和一致性协议的责任。
- 服务器节点之间通过Raft协议进行领导选举和日志复制，确保数据的一致性。
server-leader是所有server节点的老大，它和其它server节点不同的是，它需要负责同步注册的信息给其它的server节点，同时也要负责各个节点的健康监测。
3.模式的协作
在实际部署中，Consul集群由多个服务器节点和多个客户端节点组成。客户端节点负责与本地服务交互并将信息上报给服务器节点，而服务器节点则维护整个集群的状态，并确保信息的正确分发和持久化。这种设计既保证了服务发现的高效性，又确保了数据的一致性和系统的高可用性。
（三）架构对比
1.传统架构
在传统的架构当中，当有新的服务添加到后端时，需要在代理当中手动添加新服务的代理信息字段，例如nginx作为代理服务器时，需要在upstream模块中添加后端服务的IP地址加端口号，而后重新启动代理服务或重新加载配置文件，使其生效。这样的架构，有一定的局限性，如果有多个微服务需要加入，需要添加多个字段。而且，在生产环境中，重启服务，可能会影响用户体验。
2.consul架构
后端服务 A-N 可以把当前自己的网络位置注册到服务发现模块，服务发现就以 K-V (键-值)的方式记录下来，K 一般是服务名，V 就是 ip:port。服务发现模块定时的进行健康检查，轮询查看这些后端服务能不能访问的了。前端在调用后端服务 A-N 的时候，会先询问服务发现模块后端服务的网络位置，然后再调用它们的服务。
与传统架构相比，省略了手动配置的繁琐，以及避免重启服务可能会带来的影响。
三、consul搭建部署
（一）容器服务更新与发现拓扑图
（二）安装部署consul服务
|------------|--------|---------------|----------------------------------------|----------|
| 服务节点 | 主机名 | ip地址 | 安装运行服务 | docker版本 |
| consul 服务器 | consul | 192.168.83.40 | 运行consul服务、nginx服务、consul-template守护进程 | 26.1.0 |
1.安装服务
cs
[root@consul data]#ls
consul_0.9.2_linux_amd64.zip
[root@consul data]#unzip consul_0.9.2_linux_amd64.zip -d /usr/bin/
Archive: consul_0.9.2_linux_amd64.zip
inflating: /usr/bin/consul
[root@consul data]#consul --version
Consul v0.9.2
Protocol 2 spoken by default, understands 2 to 3 (agent will automatically use protocol >2 when speaking to compatible agents)
2.启动服务
后台启动服务，并查看监听端口
cs
consul agent #这是启动Consul代理的基本命令。
-server
表示以服务器模式启动Consul。在Consul集群中，服务器模式的节点负责数据的存储、复制
以及提供一致性保证。通常一个集群需要多个服务器节点以确保高可用性。
-bootstrap
指示该服务器节点作为引导节点启动，用于初始化集群。在生产环境中，通常只在集群的第一
次启动时设置一个节点为引导节点，之后应移除该标志以避免意外形成多个集群。
-ui
启用Consul的Web UI界面，允许用户通过浏览器访问Consul的管理界面（默认端口8500）。
-data-dir=/var/lib/consul-data
指定Consul存储数据的目录。所有持久化的数据，如服务目录、键值存储等，都将保存在这个目录下。
-bind=192.168.10.23
设置Consul与其他服务器节点通信的绑定地址。Consul会使用这个地址加入集群，并与其他
服务器节点建立Raft协议的通信。
-client=0.0.0.0
设置Consul客户端接口监听的地址。这里设置为0.0.0.0意味着Consul将监听所有网络接口，
客户端可以通过任意地址访问Consul的客户端API和服务发现功能。
-node=consul-server01
给这个Consul节点指定一个名称，便于在集群管理和监控时识别。
&> /var/log/consul.log #将Consul的输出重定向到/var/log/consul.log文件
& #使命令在后台运行，不影响当前的shell会话。监听端口信息
cs
8300
这是Consul的服务器间的Raft协议通信端口。
Consul集群中的服务器节点通过这个端口进行Raft日志的复制和一致性状态的同步，
是维持集群数据一致性的关键通道。
8301
用于Serf LAN（局域网）成员间的Gossip协议通信。
Gossip协议是一种去中心化的成员发现和状态传播协议，
Consul通过它来维护集群成员关系、检测成员状态变化（比如加入、离开、失败等）以及快速广播消息。
8302
用于Serf WAN（广域网）的Gossip协议通信，
主要用于多数据中心的Consul集群间的信息同步。
如果你的Consul配置涉及多数据中心，这个端口就尤为重要。
8500
这是Consul的HTTP API和UI界面端口。
可以通过访问http://192.168.83.40:8500来查看Consul的Web UI，
进行服务发现、配置管理和健康检查等操作
API也允许外部应用通过HTTP请求与Consul交互。
8600
这个端口用于DNS和DNS-TLS服务。
Consul提供服务发现的一个重要方式就是通过DNS，允许应用通过域名来发现服务实例。
例如，应用可以通过查询service.service.consul来获取某项服务的所有实例地址。使用浏览器访问consul服务的8500端口
3.查看集群信息
3.1 查看members(成员)状态
cs
[root@consul data]#consul members
Node Address Status Type Build Protocol DC
consul-server01 192.168.83.40:8301 alive server 0.9.2 2 dc1
cs
Node
表示集群中节点的名称节点名称对于标识和管理集群中的不同服务器非常重要。
Address
显示了该节点在集群中用于与其他成员通信的地址和端口
即该节点通过这个地址上的端口参与Raft协议的通信和其他Serf LAN（局域网）的Gossip协议通信。
Status
状态显示为alive，意味着这个节点当前是活跃的，能够正常参与集群的操作和通信。
Type
类型显示为server，表明这是Consul集群中的一个服务器节点
Build
版本号0.9.2指的是Consul服务的版本。
Protocol
协议版本2表示该节点支持的Consul通讯协议版本。
Consul的不同版本可能支持不同的协议版本，这影响着节点间通信的兼容性。
DC
数据中心（Datacenter）标识为dc1，表明该节点属于名为dc1的数据中心。
在多数据中心部署中，这个标签对于区分和管理不同地理位置的集群成员非常关键。3.2 查看集群状态
cs
[root@consul data]#consul operator raft list-peers
Node ID Address State Voter RaftProtocol
consul-server01 192.168.83.40:8300 192.168.83.40:8300 leader true 2
[root@consul data]#consul info | grep leader #通过过滤查看leafer信息
leader = true
leader_addr = 192.168.83.40:8300
cs
Node
显示了集群中参与Raft协议的节点名称
ID
每个Raft节点都有一个唯一的ID，用于在Raft协议中唯一标识该节点。
在实际的Raft协议中，节点ID通常是内部生成的一个唯一字符串，此处是简化显示或示例特例。
Address
指示了该Raft节点的通信地址，即192.168.83.40:8300。这是节点间进行Raft日志复制和选举通信的地址。
State
当前节点在Raft集群中的角色状态，这里是leader。
Raft集群中只有一个领导者（Leader），负责处理所有客户端的请求、协调日志复制
并且是唯一可以提交日志条目到Raft日志并应用状态机的节点。
Voter
标记该节点是否具有投票权。true表示该节点是Raft集群中的投票成员，能够参与选举新的领导者。
在多数派选举机制中，每个投票成员的决策对集群达成共识至关重要。
RaftProtocol
指的是该节点支持的Raft协议版本，这里是2。
确保集群中的所有节点使用相同的Raft协议版本是至关重要的，这样才能保证协议操作的一致性和兼容性。3.3 通过 http api 获取集群信息
cpp
[root@consul data]#curl 127.0.0.1:8500/v1/status/peers
["192.168.83.40:8300"]
#查看集群server成员
[root@consul data]#curl 127.0.0.1:8500/v1/status/leader
"192.168.83.40:8300"
#集群 server-leader
[root@consul data]#curl 127.0.0.1:8500/v1/catalog/services
{"consul":[]}
#注册的所有服务
[root@consul data]#curl 127.0.0.1:8500/v1/catalog/nginx
#查看nginx服务信息
[root@consul data]#curl 127.0.0.1:8500/v1/catalog/nodes
[{"ID":"580d959a-f1b9-866f-496d-df426d5395ec","Node":"consul-server01","Address":"192.168.83.40","Datacenter":"dc1","TaggedAddresses":{"lan":"192.168.83.40","wan":"192.168.83.40"},"Meta":{},"CreateIndex":5,"ModifyIndex":6}]
#集群节点详细信息（三）安装部署registrator服务
|-----------------|---------------|---------------------------|----------|
| 服务节点 | ip | 安装运行服务 | docker版本 |
| consul 服务器 | 192.168.83.40 | 运行consul服务 | 26.1.0 |
| registrator 服务器 | 192.168.83.30 | 运行registrator容器、运行nginx容器 | 20.10.18 |
1. 安装Gliderlabs/Registrator
Gliderlabs/Registrator 是一个曾经流行的开源项目，设计用于自动在服务发现系统中注册和注销Docker容器中的服务。它紧密集成Docker环境，能够在Docker容器启动或停止时，即时地将服务信息注册到像Consul、Etcd或Zookeeper这样的服务发现工具中，从而实现服务实例的动态管理与发现
由于Gliderlabs/Registrator 项目已经不再积极维护，在较新版本的docker服务中，已经不支持过去该服务的镜像，所以需要安装较旧的docker版本，如20.10.18
cpp
docker run -d
运行一个新的Docker容器并在后台执行（-d表示后台运行）。
--name=registrator
为容器指定一个名称registrator，便于后续管理和识别。
--net=host
设置容器使用主机网络模式，容器直接使用宿主机的网络
-v /var/run/docker.sock:/tmp/docker.sock
将宿主机上的Docker守护进程的UNIX套接字/var/run/docker.sock挂载到容器内的/tmp/docker.sock。
这个操作允许容器内的进程监听Docker事件，如容器的启动和停止，从而动态地在Consul中注册或注销服务。
--restart=always
配置容器在退出后总是自动重启，确保服务注册功能始终在线。
gliderlabs/registrator:latest
指定使用的镜像为gliderlabs/registrator的最新版本，
Registrator是一个用于服务注册的工具，能自动将Docker容器中的服务注册到服务发现系统中。
--ip=192.168.83.30
指定Registrator在注册服务时使用的IP地址，这里设置为192.168.83.30
consul://192.168.83.40:8500
指定Consul服务发现系统的地址。
这部分告诉Registrator使用Consul作为服务发现后端，
并通过HTTP(S)协议与位于192.168.83.40的Consul服务器的8500端口进行通信。2.新建容器
在registrator服务器上新建nginx容器于apache容器，并查看consul服务器，发现功能是否正常
cpp
[root@localhost ~]#docker run -itd -p 10080:80 --name nginx-01 -h nginx-server01 nginx
7221607d0fa9ccd5b34e1ad3cd8de4d794a90105d8cb6e83a50dd638da73064c
[root@localhost ~]#docker run -itd -p 10081:80 --name nginx-02 -h nginx-server02 nginx
d343afba57dc492f8dc34ed4d15f1009791561fb5588db1397aee83f0ecece0b
[root@localhost ~]#docker run -itd -p 10082:80 --name httpd-01 -h httpd-server01 httpd
a2ec56d05dfd0384e8cf88dc9df2f3aec75bc6e4e1b7e2af36b902e7c6ec4b85
3.访问consul服务器验证
cpp
[root@consul ~]#curl 127.0.0.1:8500/v1/catalog/services
{"consul":[],"httpd":[],"nginx":[]}关闭httpd服务
cpp
[root@localhost ~]#docker stop httpd-01
httpd-01
再次查看consul服务，就会发现httpd服务就会从自动发现中消失
（四）安装部署consul-template
|-----------------|-----------|---------------|--------------------------------------------|----------|
| 服务节点 | 主机名 | IP地址 | 安装运行服务 | docker版本 |
| consul 服务器 | consul | 192.168.83.40 | 运行consul服务、nginx服务（代理）、consul-template守护进程 | 26.1.0 |
| registrator 服务器 | localhost | 192.168.83.30 | 运行registrator容器、运行nginx容器 | 20.10.18 |
Consul-Template是一个强大的工具，用于实时地根据Consul中的键值存储（KV Store）或服务目录的变动来生成和管理配置文件、执行系统命令或重启服务等。它充当Consul和系统配置之间的桥梁，确保应用程序总能获取到最新的配置信息，特别适用于微服务架构和需要动态配置管理的场景
1.基本信息
1.1 主要功能和用途
动态配置生成：Consul-Template监控Consul中的数据变化，当检测到相关配置更改时，它会自动更新配置文件，如应用的配置文件、Nginx配置等，无需人工干预。
服务发现与配置：结合Consul的服务发现功能，Consul-Template可以自动配置负载均衡器、反向代理等组件的后端服务列表，实现服务实例的自动添加与移除。
自动化运维任务：除了生成配置文件，Consul-Template还可以执行系统命令或脚本，比如根据配置变更重启服务、发送通知等，进一步自动化运维流程。
模板引擎：它支持使用Go模板语言编写配置模板，使得配置文件的生成高度灵活，可以根据Consul中的数据动态生成复杂结构的配置。
1.2 工作流程
监控：Consul-Template开始运行后，会根据配置文件中指定的Consul路径进行监控。
检测变化：当Consul中的数据发生变化时，Consul-Template会立即感知到。
渲染模板：利用变化的数据和预先定义好的模板文件，Consul-Template生成新的配置文件。
执行动作：根据配置，Consul-Template可能直接写入文件系统，执行系统命令，或者重启服务等。
2.实际操作
2.1 安装Consul-Template
cpp
[root@consul opt]#ls
consul_0.9.2_linux_amd64.zip consul-template_0.19.3_linux_amd64.zip containerd rh
[root@consul opt]#unzip consul-template_0.19.3_linux_amd64.zip -d /usr/bin/
Archive: consul-template_0.19.3_linux_amd64.zip
inflating: /usr/bin/consul-template
[root@consul opt]#ls /usr/bin/consul-template
/usr/bin/consul-template2.2 准备模板文件
cpp
[root@consul opt]#mkdir -p /data/consul
[root@consul opt]#cd /data/consul/
[root@consul consul]#vim nginx.ctmpl #文件格式，以.ctmpl结尾
[root@consul consul]#cat nginx.ctmpl
upstream http_backend {
{{range service "nginx"}}
server {{.Address}}:{{.Port}};
{{end}}
}
server {
listen 8000;
server_name localhost 192.168.83.40;
access_log /var/log/nginx/nginx-tmp-access.log;
index index.html index.php;
location / {
proxy_set_header HOST $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header Client-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass http://web;
}
}
cpp
upstream web {
......
}
这里使用了Consul Template的语法（由{{ }}包围的部分），这意味着在实际部署时，
这部分内容会根据Consul中的服务发现动态生成。
upstream web
定义的上游服务器组的名字，这个名称在Nginx的location配置块中通过proxy_pass指令引用
{{range service "nginx"}} 和 {{end}} 之间的部分构成了一个循环结构，
用于遍历Consul中所有名为"nginx"的服务实例。
这意味着只要在Consul中注册了带有标签或服务名称为"nginx"的服务，
它们的地址和端口就会被自动添加到这个upstream配置中
Server指令：server {{.Address}}:{{.Port}};
表示每一个遍历到的服务实例都会被配置为一个后端服务器，
其中{{.Address}}和{{.Port}}是Consul中服务实例的地址和端口信息。
这行配置会根据Consul中的服务列表动态生成，确保Nginx知道如何将请求转发到正确的后端服务器
server {
......
}
server
定义了一个Nginx服务器块，这是Nginx配置的基本单元，用于设定一个虚拟服务器的各种属性和行为。
listen 8000;
指定了这个Nginx服务器监听的端口为8000
server_name localhost 192.168.83.40;
定义了服务器的名称或IP地址，Nginx会响应对localhost和192.168.83.40的请求。
这意味着，当客户端请求到达时，如果Host头部匹配这些名称或IP，就会使用此配置块处理请求。
access_log /var/log/nginx/nginx-tmp-access.log;
指定了访问日志的存放路径
index index.html index.php;
设定了默认的首页文件，当访问一个目录时，Nginx会首先尝试提供index.html，
如果不存在，则尝试提供index.php。
location / {...}
定义了一个匹配所有请求的定位块
proxy_set_header
这一系列指令设置了代理请求传递给后端服务器时，会在HTTP头中添加或覆盖一些信息。
$host
保留原始请求的主机名。
$remote_addr
记录发起请求的客户端真实IP地址，这里Client-IP和X-Real-IP都设置成了客户端的远程地址，
是为了兼容不同的后端应用识别客户端IP的方式。
$proxy_add_x_forwarded_for
追加客户端的真实IP到X-Forwarded-For头部，用于记录请求经过的代理服务器信息。
proxy_pass http://web;
指定了代理转发的目标地址，所有匹配到此location块的请求都将被转发到http://web。
这代表upstream代理到后端服务的地址，具体地址可能根据Consul服务发现的结果动态填充。2.3 安装nginx
cpp
[root@consul consul]#yum install epel-release.noarch -y
......
[root@consul consul]#yum install nginx -y
......在配置文件中添加默认加载的虚拟主机目录
cpp
[root@consul consul]#vim /etc/nginx/nginx.conf
[root@consul consul]#sed -n '30,32p' /etc/nginx/nginx.conf
include /etc/nginx/mime.types;
include /etc/nginx/vhost/*.conf;
default_type application/octet-stream;
[root@consul consul]#mkdir /etc/nginx/vhost
[root@consul consul]#systemctl start nginx.service
2.4 启动template服务
在前台运行template，启动服务后不需要进行终止
cpp
consul-template
命令本身，用于实时地根据Consul中的数据变化来生成配置文件或执行其他命令。
--consul-addr 192.168.83.40:8500
指定Consul服务器的地址和端口。这里Consul运行在IP地址为192.168.83.40的主机上，端口为8500。
--template "/data/consul/nginx.ctmpl:/etc/nginx/vhost/consul.conf:/usr/local/nginx/sbin/nginx -s reload":
第一部分/data/consul/nginx.ctmpl
是指定的模板文件路径，即之前提到的Nginx配置模板文件。
第二部分/etc/nginx/vhost/consul.conf
生成的配置文件保存路径，每当Consul中的数据变化触发模板重新渲染时，生成的新配置文件将被写到这里
第三部分/usr/local/nginx/sbin/nginx -s reload
是执行命令，一旦模板生成新的配置文件，将执行这个命令。
这里的意思是重新加载Nginx配置，使得新的配置生效，而无需完全重启Nginx服务
--log-level=info
设置日志级别为info打开另一个终端进行查看
此时这个文件，就相当于nginx的配置文件，从而达到反向代理的效果，并以默认的轮询方式做负载均衡
3.验证结果
在nginx容器中建立不同的访问目录
访问consul-template的8000端口
3.1 添加服务
在registrator服务中增加一个nginx容器，测试服务发现及配置更新功能
cpp
[root@localhost ~]#docker run -itd -p 10086:80 --name nginx-03 -h nginx-server03 nginx
8813e7ba272f15045416c196af81ffef6e3c3b9403883fb40fa76cfaa2783149
[root@localhost ~]#docker exec -it nginx-03 bash
root@nginx-server03:/# echo "this is nginx-03" >/usr/share/nginx/html/index.html
root@nginx-server03:/# 
3.2 查看配置文件内容
再次查看consul服务器 template 更新的配置文件内容
3.3 测试轮询结果
再次使用客户端进行访问
3.4 停用nginx-02测试轮询结果
在registrator服务器上停止nginx-02服务
cpp
[root@localhost ~]#docker stop nginx-02
nginx-02查看consul服务器 template 更新的配置文件内容
访问192.168.83.40:8000测试轮询结果
（五）consul多节点
|-----------------|-------------|---------------|--------------------------------------------|----------|
| 服务节点 | 主机名 | ip地址 | 安装运行服务 | docker版本 |
| consul服务器 | consul | 192.168.83.40 | 运行consul服务、nginx服务（代理）、consul-template守护进程 | 26.1.0 |
| registrator 服务器 | localhost | 192.168.83.30 | 运行registrator容器、运行nginx容器 | 20.10.18 |
| consul节点服务器 | consul-node | 192.168.83.70 | 运行consul服务 | 26.1.0 |
1.安装服务
在consul节点服务器上安装consul服务
cpp
[root@consul-node opt]#ls
consul_0.9.2_linux_amd64.zip containerd rh
[root@consul-node opt]#unzip consul_0.9.2_linux_amd64.zip -d /usr/sbin/
Archive: consul_0.9.2_linux_amd64.zip
inflating: /usr/sbin/consul
2.加入已有集群
添加一台已有docker环境的服务器加入已有的集群中
cpp
[root@consul-node opt]#consul agent \
> -server \
> -ui \
> -data-dir=/var/lib/consul-data \
> -bind=192.168.83.70 \
> -client=0.0.0.0 \
> -node=consul-server02 \
> -enable-script-checks=true \
> -datacenter=dc1 \
> -join 192.168.83.40 &> /var/log/consul.log &
[1] 5263
-enable-script-checks=true #设置检查服务为可用
-datacenter #数据中心名称
-join #加入到已有的集群中3.查看结果
cpp
#查看成员状态
[root@consul-node opt]#consul members
Node Address Status Type Build Protocol DC
consul-server01 192.168.83.40:8301 alive server 0.9.2 2 dc1
consul-server02 192.168.83.70:8301 alive server 0.9.2 2 dc1
#查看集群状态
[root@consul-node opt]#consul operator raft list-peers
Node ID Address State Voter RaftProtocol
consul-server01 192.168.83.40:8300 192.168.83.40:8300 leader true 2
consul-server02 192.168.83.70:8300 192.168.83.70:8300 follower true 2