本文共 9697 字,大约阅读时间需要 32 分钟。
http://www.jianshu.com/p/b4aaf267f7ba
官网Document
一、介绍
Consul有很多组件,但总的来说,它主要用来发现和配置服务。
(1)服务发现:Consul的客户端可以“provide”一个service,例如api或mysql,其他客户端可以使用Consul来“discover”给定服务的providers。通过DNS或HTTP。
(2)健康检查:Consul客户端可以 检查webserver是否返回200 OK,或本地节点的内存使用率是否低于90%,等等。这些信息可以被用来监视集群的健康,也用于服务发现组件在路由时远离不健康的hosts。
(3)Key/Value存储:可以用于动态配置、leader election等等。使用简单的HTTP API使用。
(4)Multi Datacenter(多数据中心):这意味着Consul的使用者们不需要再创建额外的抽象层来扩展Consul了。
Consul是一个分布式的、高可用HA的系统。
每一个向Consul提供服务的节点都运行一个Consul agent。运行这个agent对于发现其他服务或get/set key/value数据不是必须的。这个agent负责健康检查service和node自身。
这个agent和一个或多个Consul server通话。Consul Servers存储着数据并replicated数据。Servers自己会选举一个leader。虽然一个server也可以工作,但是3到5是推荐的,以防止失败时导致数据丢失。
如果你的infrastructure(基础设施)的组件要发现其他服务或节点,可以向任何一个Consul server或任何一个Consul agent查询,agent会自动转发请求到servers。
每个Datacenter都运行着一个ConsulServer的集群。当一个跨集群的service discovery或configuration request来到时,本地的Consul servers会转发请求到远端的Datacenter并返回结果。
二、GettingStarted
1、下载zip包
2、安装:解压、拷贝consul文件到任何的PATH路径中以方便它可以直接被执行,例如 /usr//local/bin。
三、运行agent:
(1)启动consul:
consul agent -dev #以dev模式运行,这种模式启动一个单节点的Consul环境,它不适用于生产环境。因为不持久化任何state。
consul agent -server #以server模式启动,
consul agent #默认是以client模式运行,client非常轻量级,它注册服务、运行healthchecks、转发query到servers。agent必须运行于集群上的每一个节点。
consul agent -dev -config-dir /etc/consul.d #或-config-file。指定配置文件夹,Consul会加载其中的所有文件。配置文件是json格式,除了提供启动agent时的命令行选项外,还用来提供check和service定义。
kill -HUP ${consulPid} #重新载入配置文件。
consul reload #重新载入配置文件。
(2)关闭consul:
consul leave #关闭consul并离开集群。也可以使用Ctrl+C或kill -INT来gracefully停止agent,这种体面的离开方式让consule可以有机会通知集群其他成员自己的离开。如果你强制地结束了agent,其他member会检测到这个节点的failed。当成员离开时,它的services和checks都会从catalog中移除。当成员failed时,它的health只是简单的被标记为critical,并不会从catalog中移除。Consul会自动尝试重新连接failed节点,允许它从恶劣的网络环境中恢复,显然离开的nodes不会被重新连接。另外,如果这个节点是server,体面的离开对避免潜在的中断的可能很重要。
为了防止dead nodes的积累,consul会自动把dead nodes移除出catalog。这个过程被称为reaping(收割)。默认是72小时的间隔(不建议更改)
(3)consul集群:
consul agent -server -bootstrap-expect 1 -node=agent-one -bind=10.0.209.123 -data-dir /tmp/consul -config-dir /etc/consul.d
consul agent -node=agent-two -bind=10.0.209.122 -data-dir /tmp/consul -config-dir /etc/consul.d
consul members # 现在你有了两个运行中的agent,一个server,一个client。分别在两个节点上运行这个命令,可以看到现在他们还不知道彼此。
consul join 10.0.209.122 #加入集群:现在我们告诉第一个agent加入第二个agent
consul members # 现在看看集群中有2个节点了
consul agent ... -join 1.1.1.1 1.1.1.2 #或-retry-join
(4)查询节点:
consul members #查询集群成员
dig @127.0.0.1 -p 8600 agent-two.node.consul #查询节点
dig @127.0.0.1 -p 8600 agent-two.node.[DATACENTER].consul
curl #通过API的方式查询节点
curl
(5)服务声明和查询:
consul agent -dev -config-dir /etc/consul.d # -config-dir指定配置文件夹,Consul会加载其中的所有文件
#
echo '{"service": {"name": "web", "port": 80, "tags": ["rails"]}}' >/etc/consul.d/web.json #定义一个服务“web”
consul reload #重新载入配置文件
dig @127.0.0.1 -p 8600 web.service.consul #查询web服务 (如果没有dig命令,请yum install bind-utils)
dig @127.0.0.1 -p 8600 rails.web.service.consul #通过tags来过滤services
curl
curl #通过HTTP API方式查询web服务
curl ' #使用健康状态过滤服务
(6)健康检查:
echo '{"check": {"name": "ping","script": "ping -c1 google.com >/dev/null","interval": "30s"}}' >/etc/consul.d/ping.json
echo '{"service": {"name": "web", "tags": ["rails"], "port": 80,"check": {"script":"curl 127.0.0.1 >/dev/null 2>&1", "interval": "10s"}}}' >/etc/consul.d/web.json
第二个definition修改了web service,增加了一个check,每10秒运行一次,使用curl来验证web server是否可访问。如果脚本以非0值退出,那么这个service被标记为unhealthy。
consul reload #重新载入配置文件
curl #使用HTTP API来查询,这里是查询所有的failing checks。
dig @127.0.0.1 -p 8600 web.service.consul #结果查询不到unhealthy的service。
(7)KEY/VALUE存储:
curl -v #因为现在还没有值,所以不会返回任何内容,使用-v参数是为了让你看看返回的详细信息
curl -X PUT -d 'test' #增加键web/key1,值为test
curl -X PUT -d 'test' #增加键web/key2=test,同时指定flags=42,flags默认值是0,flags值可以是一个64位的整数值,flags对于Consul没有任何意义,但你可以将他作为有意义的metadata
curl #现在再查询可以看到返回结果中value为base64编码后的值,这是为了允许一些non-UTF8的字符。
curl #单个key的查询
curl -X DELETE #删除
curl -X PUT -d 'newval'
curl -X PUT -d 'newval'
curl "" #表示等待web/key2的ModifyIndex大于等于101,并且最多等5秒,然后返回当前的值
四、consul cli:
consul -v #查看consul版本
consul info #提供了各种debugging信息,这些信息对operator会有用的。
consul reload:触发重新加载配置文件。等于kill -1或kill -HUP
consul configtest -config-file 或 -config-dir #只验证配置文件,不真正启动agent。
consul join 10.0.209.123 10.0.209.124 #可以指定多个node
consul leave #优雅的离开并shutdown
consul force-leave #强制集群中某个member进入“left”状态。注意,如果member实际上还是alive,它会rejoin the cluster。这个方法的真正意图是强制移除那些“failed”的节点。
consul members:
consul monitor #用来连接一个运行中的consul agent,并follow它的logs。这个命令的强大之处在于你可以使用一个非常高的log level(例如warn)来追踪日志,
consul monitor -log-level trace/debug/info/warn/err
consul kv delete/export/get/import/put #kv操作
consul event #fire一个自定义的user event到整个Datacenter。它们可以用于自动化部署、重启services、或执行其他协同动作。events可以通过使用watch的方式被处理。 event通过gossip协议传播,不保证一定传播到。不像其他的大部分consul data(它们都通过consensus协议被replicated),event数据是通过gossip 一点一点传播的。这意味着它没有被持久化并且没有顺序(例如fire两个event,不代表后面fire的就一定后收到)。 同时event的payload也有限制,但是没有一个准确的值,一般应该小于100bytes。
consul exec #在集群中所有的节点上远程执行并返回命令回显。例如,可以运行uptime命令在所有提供web service的机制上。 远程执行通过在KV中存储一个job,然后通过event系统通知节点有新的job并执行。 注意命令的输出结果不要太多,输出结果也是存储在KV中,如果有一个大的集群,这可能会让集群不可达。
consul keygen
consul keyring
consul lock #提供了一种简单的分布式锁机制。锁或semaphore通过给定的前缀在KV里创建,并且只有持有时,子进程才调用。如果lock丢失了或通信破坏了,子进程就被终止了。
consul maint #提供了对service和node的maintenance mode的control。使用这个命令,可以 标记某个节点提供的一个service或者某个节点整体为“under maintenance” 。在这种模式下,service和node将不会出现在DNS查询结果里或API结果里。实际上这让service或node离开了available “healthy” nodes 池。 实际上,maintenance mode是在health check为critical status时激活,取消注册health check后去激活。
consul operator #提供集群级别的工具,例如与Raft subsystem交互。使用这个命令要特别特别小心。因为不适当的使用可能导致Consul中断甚至丢失数据。
consul rtt #估算两个节点之间网络往返时间。round trip time
consul watch #监控一个节点的data view(list of nodes,services members,key value等等)的变化,并且调用一个进程(使用data view的最新的数据)。如果没有指定process,当前值会被dumped到stdout。
五、HTTP API:
1、所有的API路径的前缀都是 /v1/ 。这个文档也只是介绍 v1 API。例如:
2、有些 endpoints 使用或需要 ACL token 来操作。虽然agent可以被配置为使用默认的token,但是token可以在每次请求时都指定,通过在请求的Header里加入 X-Consul-Token 的值 或 在请求url中加入 token 参数(优先级最高)。但是推荐使用请求头里加入Header的方式。
3、当启用了authentication(认证)时,就应该在请求中传递token。下面是一个例子:
curl --header "X-Consul-Token: abcd1234"
4、很多(但不是所有的)endpoints都支持阻塞查询特色。支持该特色的endpoints会在response的HTTP header里包含一个 X-Consul-Index 的key。这个key标识了请求资源的当前状态。 然后在接下来的查询里可以在请求头里加入这个 X-Consul-Index key,表示你想等待任何在这个key表示的index之后的更改后的资源值。
5、一致性模型(consistency modes):很多查询的endpoints都支持多个级别的一致性。模型有:
stale : 这个模式允许任意的server来服务读请求,而不管它是不是leader。这意味着read可以任意的stale(不新鲜)。然而一般来说result都会在50ms内被同步完成。
要想切换这些模式,应该在请求url中提供 stale 或 consistent 参数,如果同时提供会报错。
为了支持数据的staleness不新鲜程度,response的HTTP Header中会包含 X-Consul-LastContact(表示最近和leader node的通信时间毫秒数)、X-Consul-KnownLeader(表明是否有已知的leader) 字段。这些数据可以被client用来判断数据的不新鲜程度并作出相应的动作决策。
6、默认情况下,所有的response输出都是最小化的JSON格式的。如果请求url中传递了pretty参数,会返回格式化的JSON数据。
7、HTTP 方法:Consul的API目标是RESTful,虽然有一些例外。API响应标准的HTTP GET、PUT、DELETE方法。例子:
curl --request PUT --data 'hello world!'
8、有些库文件可以用来更方便的调用API。一些是官方的,一些是第三方提供的。
9、具体的API请自行查看。
10、一些常用的:
agent相关的API
curl
curl
curl --request PUT --data @payload.json
curl --request PUT
curl
curl
curl
curl
curl
curl --request PUT --data @payload.json
curl --request PUT
curl --request PUT
catalog相关的API
curl --request PUT --data @payload.json
curl --request PUT --data @payload.json
curl
curl
curl
curl
curl
KV相关的API
curl
curl --request PUT --data 'xxx'
curl --request DELETE
Health相关的API
curl
curl
curl
curl
六、consul agent 启动选项和配置文件:
七、使用的端口:
8300:TCP # Server RPC :agent server 使用的,用于处理其他agent发来的请求
8301:TCP and UDP # Serf LAN: 所有的agent都要使用这个端口,用于处理LAN中的gossip,
8302:TCP and UDP # Serf WAN:agent Server使用的,处理WAN中的与其他server的gossip
8400:TCP # 所有agent都要使用的端口,用于处理从CLI来的RPC。
8500:TCP # 所有agent都要使用的端口,用于处理HTTP API。
8600:TCP and UDP # 用于处理 DNS 查询。
转载地址:http://lblbi.baihongyu.com/