Consul入门04 - Consul集群

Part 1:转载自:https://segmentfault.com/a/1190000005040904

咱们已经启动了咱们的第一个代理而且在这个代理上注册和查询了服务。这些显示了使用Consul是多么的容易可是并无展现Consul的可扩展性以及可用于产品级别的服务发现的基础设施。在本篇向导中,咱们将创建咱们第一个多成员的真实的集群。html

当一个Consul代理启动后,它对任何其余的节点都一无所知:它是个单独的隔离集群。为了让它感知其余的集群成员,代理必须加入一个现有的集群中去。为了加入一个现有的集群,它只须要知道一个单个的现有成员。它加入后,代理将广播该成员,而且快速发现集群中的其它成员。一个Consul代理可以加入任何其它的代理,不只仅是那些运行在服务模式下的代理。node

启动代理

为了模拟一个相对真实的集群,咱们将经过Vagrant启动两个节点的集群。接下来使用的Vagrantfile能够在Consul仓库demo中找到。git

咱们首先启动两个节点:github

$ vagrant up

一旦该系统可用了,咱们就能经过ssh登陆到该系统,并开始配置咱们的集群。咱们开始登陆到第一个节点:web

$ vagrant ssh n1

在咱们之前的例子里,咱们使用 *-dev 标志来快速地设置一个开发服务器。不管如何它并不能用于一个集群的环境下。咱们将移除 -dev* 标志,而是替换成指定的用于集群的标志,下面就回涉及该标志。json

每一个集群节点都必须有一个惟一的名称。默认下Consul使用计算机的主机名,不过咱们可使用 -node 命令行选项手动地覆盖它。bootstrap

咱们也能够指定 绑定地址:Consul将在该地址侦听,而且改地址能够被集群中全部其它的节点访问到。虽然一个 绑定 的地址不是一个严格须要的(Consul将默认侦听在系统中第一个私有的IP),不过最好提供一个。一个生产环境下的服务一般有多个网络接口,因此指定一个 绑定 地址将保证你不会把Consul绑定到错误的网络接口上。segmentfault

第一个节点如今将做为咱们集群中的惟一服务器,咱们指定它运行在server模式下。bash

-bootstrap-expect 标志暗示Consul服务器咱们会有其它的服务节点将会加入。这个标志的目的是延迟复制日志的引导直到预期的服务节点成功加入。你能够在引导教程里查阅到更多的信息。服务器

最后,咱们增长 config-dir,指定将在哪里能够找到服务以及检查定义。

全部的标志都指定后,将这些设置加入 consul ageng 命令行:

vagrant@n1:~$ consul agent -server -bootstrap-expect 1 \
    -data-dir /tmp/consul -node=agent-one -bind=172.20.20.10 \
    -config-dir /etc/consul.d
...

如今,在另外一终端里,咱们链接到第二个节点:

$ vagrant ssh n2

此次,咱们设置 绑定地址 是第二个节点的IP地址。由于该节点将不会是一个Consul的服务器,因此咱们不指定它启动为服务器模式。

全部的标志都指定后,将这些设置加入 consul ageng 命令行:

vagrant@n2:~$ consul agent -data-dir /tmp/consul -node=agent-two \
    -bind=172.20.20.11 -config-dir /etc/consul.d
...

这时,咱们已经有了两个Consul代理在运行:一个服务器和一个客户端。这两个Consul代理如今还对彼此没有任何感知,它们都为两个单节点的集群。你能够运行 consul members 来验证它们,每一个集群都仅包含一个成员。

加入集群

如今,咱们将告知第一个代理加入第二个代理,在一个新的终端中运行下列命令:

$ vagrant ssh n1
...
vagrant@n1:~$ consul join 172.20.20.11
Successfully joined cluster by contacting 1 nodes.

你应该能够在各自的代理日志中看到一些日志的输出。若是你仔细的查看,你将会看到有节点加入的日志信息。若是你再次运行consul members,你会看到两个代理都已经感知到了另外一个节点的存在。

vagrant@n2:~$ consul members
Node       Address            Status  Type    Build  Protocol
agent-two  172.20.20.11:8301  alive   client  0.5.0  2
agent-one  172.20.20.10:8301  alive   server  0.5.0  2

记住:为了加入一个集群,一个Consul代理只须要知道一个现有的成员。在加入指定的集群后,各个代理会互相传播完整的成员信息。

启动时自动加入一个集群

理想状况下,不管何时一个新的节点加入了你的数据中心中,它应该自动地加入Consul集群而无需手动操做。为了达到这个目的,你可使用Atlas by HashiCorp而且指定 -atlas-join 标志。下面就是一个配置例子:

$ consul agent -atlas-join \
  -atlas=ATLAS_USERNAME/infrastructure \
  -atlas-token="YOUR_ATLAS_TOKEN"

这须要一个Atlas的用户名和token,在这里建立账号,而后在你的Consul配置中使用你认证信息的替换各自的值。如今,不管什么时候一个经过Consul代理启动的节点加入,它将自动加入你的Consul集群而无需硬编码任何的配置信息。

另外一个能够选择的是,你能够在启动的时候使用 -join 标志或者 start_join 指定一个已知Consul代理的地址来加入一个集群。

查询节点

就像查询服务同样,Consul有一个API用户查询节点信息。你能够经过DNS或者HTTP API来查询。

对于DNS API,名称结构是 NAME.node.consul 或者 NAME.node.DATACENTER.consul。 若是数据中心被移除,Consul将仅仅查询本地数据中心。

例如,从“agent-one”,咱们能够查询节点"agent-two"的地址:

vagrant@n1:~$ dig @127.0.0.1 -p 8600 agent-two.node.consul
...

;; QUESTION SECTION:
;agent-two.node.consul. IN  A

;; ANSWER SECTION:
agent-two.node.consul.  0 IN    A   172.20.20.11

这种查找节点的能力对于系统管理任务而言是很是有用的。例如知道了节点的地址,咱们可使用ssh登陆到该节点而且能够很是容易地使得该节点成为Consul集群中的一部分而且查询它。

离开集群

为了离开指定的集群,你能够优雅地退出一个代理(使用 Ctrl-C)或者强制杀死代理进程。优雅地离开可使得节点转换成离开状态;其它状况下,其它的节点检测这个节点将失败。其不一样的地方在这里有详细的描述。

下一步

如今有了一个多节点的Consul集群已经启动而且运行着。让咱们经过[健康检测]()使咱们的服务具备更强的鲁棒性。

Part 2:根据Part一、Windows安装Linux虚拟机(CentOS7)及Consul入门01-03,咱们使用虚拟机来实现集群(三台:三台机器才能知足基础的集群,当有一台主服务退出时,另外两台从新选举新的主服务)。

1、启动三台虚拟机,为了方便演示,我这边使用PUTTY来分别链接这三台机器,并统一使用root登陆。


2、为了方便演示,咱们分别将三台机器上的web.json中的serviceName从新命名为web、web一、web2(能够一开始的时候就这么命名或者使用vi编辑器),并分别在三台机器上运行consul
咱们先将consul定义为server(服务器模式):
consul agent -server -bootstrap-expect 1 -data-dir /tmp/consul/ -node=web -bind=192.168.240.129 -config-dir /etc/consul.d/
另外两台机器使用以下命令启动(不将他们定义为服务器模式):
consul agent -data-dir /tmp/consul/ -node=web1 -bind=192.168.240.130 -config-dir /etc/consul.d/
consul agent -data-dir /tmp/consul/ -node=web2 -bind=192.168.240.131 -config-dir /etc/consul.d/

启动好以后,咱们会发现,非server的两台机器web1和web2会时不时的在控制台输出信息,这是由于尚未加入到web的server中,没有找到集群的主服务,不用担忧,咱们继续看:



3、再打开三个putty客户端(上下匹配:左上1是web的consul server,左下1是新开的web putty客户端),并分别在里面运行consul members查看集群内成员,此时只能分别查看到本机的信息,type分别为server和client:


4、加入集群:
一个consul agent就是一个独立的程序。一个长时间运行的守护进程,运行在concul集群中的每一个节点上。
启动一个consul agent ,只是启动一个孤立的node,若是想知道集群中的其余节点,应该将consul agent加入到集群中去 cluster。
agent有两种模式:server与client。server模式包含了一致性的工做:保证一致性和可用性(在部分失败的状况下),响应RPC,同步数据到其余节点代理。
client 模式用于与server进行通讯,转发RPC到服务的代理agent,它仅保存自身的少许一些状态,是很是轻量化的东西。自己是相对无状态的。
agent除去设置server/client模式、数据路径以外,还最好设置node的名称和ip。

在web1和web2的client机器上,使用consul join IP加入consul server,我这里是这样的:
consul join 192.168.240.129


5、加入集群后,再次使用consul members 咱们发现,集群中的机器已经能够互相发现了。一个server,其它是client:




Part 3:Server之间的leader自动选举功能:此次咱们须要4台机器,其中web、web一、web2都定义为server,一台client。(虚拟机安装及基本配置请看:Windows安装Linux虚拟机(CentOS7)及Consul入门01-03


一开始学习consul, 咱们须要让consul 运行起来。consul server推荐至少在3~5个之间,推荐的方法是一开始启动其中一台server,而且配置到bootstrap的模式,该模式node能够指定本身做为leader,而不用进行选举。而后再依次启动其余server,配置为非bootstrap的模式。最后把第一个serverbootstrap模式中止,从新以非bootstrap模式启动,这样server之间就能够自动选举leader。

web:

consul agent -server -bootstrap -data-dir /tmp/consul -node=web


web一、web2:用如下命令启动consul,不须要带bootstrap 选项:

consul agent -server -data-dir /tmp/consul -node=web1
	consul agent -server -data-dir /tmp/consul -node=web2

PS:三台server都启动以后,会发现web1和web2在控制台也会有消息更新,提示NO cluster leader,说明没法选举leader,分别查看各自的集群信息时,也是没法互相查看的。



web一、web2须要加入到web的集群中:consul join 192.168.240.129:



当三台server都加入到集群,咱们须要配置这三台机子为同等的server,而且让它们本身选择leader,这时能够中止第一台(web)的consul,而后运行以下命令:

consul agent -server -data-dir /tmp/consul -node=web
consul join 192.168.240.130



PS:此时,咱们在每台机子上输入 consul info,咱们会发现此时的leader是web2;咱们并无指定,是集群本身选择的:




这时,咱们模拟异常或者服务器退出,将web2关闭,这时咱们再次输入consul info会发现,web和web1自动选举了web做为leader:



最后,将client机器连入集群,就是一个小型的完整集群了。

参考文章:http://www.cnblogs.com/yatingyang/p/4495098.html

Part 4:已经组建过的集群服务器,在退出集群以后,将没法加入以前的cluster中,而是依旧如第一次启动那样,看不到peers。

参考地址:http://tonybai.com/2015/07/06/implement-distributed-services-registery-and-discovery-by-consul/?utm_source=tuicool&utm_medium=referral

问题描述:我这边由于电脑重启了,因此集群就都退出了,可是按照上面的步骤,没法从新组建集群,没法选出leader,经过info命令看,两个节点都变成了Follower,集群仍然处于无leader状态。

问题解释:这个问题在consul的github repository issues中被对人次说起,但做者彷佛不将此做为bug。产生这个问题的缘由是当server退出时,consul会将/tmp/consul/raft/peers.json的内容由["192.168.240.129:8300","192.168.240.130:8300","192.168.240.131:8300"]=====改成=====》》》》null.当server重启后,该文件并未改变,依旧为null,因此没法从新弄自动join到cluster中,也就没法选取leader了。

问题解决:打开对应的serve中/tmp/consul/raft/peers.json文件,将内容统一修改成["192.168.240.129:8300","192.168.240.130:8300","192.168.240.131:8300"],而后重启,使用-rejoin命令加入集群或者重复Part3中的步骤便可。