consul知识梳理与环境搭建
一、 什么是consul
consul的基本介紹
在分布式架構中，服務治理是一個重要的問題。在沒有服務治理的分布式集群中，各個服務之間通過手工或者配置的方式進行服務關系管理，遇到服務關系變化或者增加服務的時候，人肉配置極其麻煩且容易出錯。之前在一個C/C++項目中，采用ZooKeeper進行服務治理，可以很好的維護服務之間的關系，但是使用起來較為麻煩。現在越來越多新的項目采用consul進行服務治理，各方面的評價都優于ZooKeeper，經過幾天的研究，這里做一個總結。
zookeeper和consul比較
? 開發語言方面，zookeeper采用java開發，安裝的時候需要部署java環境；consul采用golang開發，所有依賴都編譯到了可執行程序中，即插即用。
? 部署方面，zookeeper一般部署奇數個節點方便做簡單多數的選舉機制。consul部署的時候分server節點和client節點（通過不同的啟動參數區分），server節點做leader選舉和數據一致性維護，client節點部署在服務機器上，作為服務程序訪問consul的接口。
? 一致性協議方面，zookeeper使用自定義的zab協議，consul的一致性協議采用更流行的Raft。
? zookeeper不支持多數據中心，consul可以跨機房支持多數據中心部署，有效避免了單數據中心故障不能訪問的情況。
? 鏈接方式上，zookeeper client api和服務器保持長連接，需要服務程序自行管理和維護鏈接有效性，服務程序注冊回調函數處理zookeeper事件，并自己維護在zookeeper上建立的目錄結構有效性（如臨時節點維護）；consul 采用DNS或者http獲取服務信息，沒有主動通知，需要自己輪訓獲取。
? 工具方面，zookeeper自帶一個cli_mt工具，可以通過命令行登錄zookeeper服務器，手動管理目錄結構。consul自帶一個Web UI管理系統， 可以通過參數啟動并在瀏覽器中直接查看信息。
Consul是一個用來實現分布式系統的服務發現與配置的開源工具。他主要由多個組成部分：
? 服務發現：客戶端通過Consul提供服務，類似于API,MySQL,或者其他客戶端可以使用Consul發現服務的提供者。使用類似DNS或者HTTP，應用程序和可以很輕松的發現他們依賴的服務。
? 檢查健康：Consul客戶端可以提供與給定服務相關的健康檢查（Web服務器返回200 ok）或者本地節點（“內存利用率低于90%”）。這些信息可以監控集群的運行情況，并且使訪問遠離不健康的主機組件。
? 鍵值對存儲：應用程序可以使用Cousul的層級鍵值對。
? 多數據中心：Consul有開箱及用的多數據中心。
Consul 的角色
client: 客戶端, 無狀態, 將 HTTP 和 DNS 接口請求轉發給局域網內的服務端集群.
server: 服務端, 保存配置信息, 高可用集群, 在局域網內與本地客戶端通訊, 通過廣域網與其他數據中心通訊. 每個數據中心的 server 數量推薦為 3 個或是 5 個.
agent
組成 consul 集群的每個成員上都要運行一個 agent，可以通過 consul agent 命令來啟動。agent 可以運行在 server 狀態或者 client 狀態。自然的，運行在 server 狀態的節點被稱為 server 節點；運行在 client 狀態的節點被稱為 client 節點。
client 節點
負責轉發所有的 RPC 到 server 節點。本身無狀態，且輕量級，因此，可以部署大量的 client 節點。
server 節點
負責組成 cluster 的復雜工作（選舉、狀態維護、轉發請求到 lead），以及 consul 提供的服務（響應 RCP 請求）。考慮到容錯和收斂，一般部署 3 ~ 5 個比較合適。
Consul內幕
術語
? 代理(agent)：代理是Consul集群上每個成員的守護進程，它是由consul agent開始運行。代理能夠以客戶端或服務器模式運行。由于所有節點都必須運行代理，所以將節點引用為客戶端或服務器更為簡單，但還有其他實例的代理。所有代理可以運行DNS或HTTP接口，并負責運行檢查和保持服務同步。
? 客戶端：客戶端可以將所有RPC請求轉發到服務器的代理。客戶端是相對無狀態的。客戶端執行的唯一后臺活動是LANgossip池。它消耗最小的資源開銷和少量的網絡帶寬。
? 服務器端：服務器端是具有擴展的功能的代理，它主要參與維護集群狀態，響應RPC查詢，與其他數據中心交換WAN gossip ，以及向上級或遠程數據中心轉發查詢。
? 數據中心：雖然數據中心的定義似乎很明顯，但仍有一些細微的細節必須考慮。我們將一個數據中心定義為一個私有、低延遲和高帶寬的網絡環境。這不包括通過公共互聯網的通信，但是為了我們的目的，單個EC2區域內的多個可用區域將被視為單個數據中心的一部分
? Gossip：consul是建立在serf之上的，它提供了一個完整的gossip協議，用在很多地方。Serf提供了成員，故障檢測和事件廣播。Gossip的節點到節點之間的通信使用了UDP協議。
? LAN Gossip：指在同一局域網或數據中心的節點上的LAN Gossip池。
? WAN Gossip：指包含服務器的WAN Gossip池，這些服務器在不同的數據中心，通過網絡進行通信。
? 一致性協議采用 Raft 算法,用來保證服務的高可用.
? 成員管理和消息廣播 采用GOSSIP協議，支持ACL訪問控制。
ACL技術在路由器中被廣泛采用，它是一種基于包過濾的流控制技術。控制列表通過把源地址、目的地址及端口號作為數據包檢查的基本元素，并可以規定符合條件的數據包是否允許通過。
gossip就是p2p協議。他主要要做的事情是，去中心化。
這個協議就是模擬人類中傳播謠言的行為而來。首先要傳播謠言就要有種子節點。種子節點每秒都會隨機向其他節點發送自己所擁有的節點列表，以及需要傳播的消息。任何新加入的節點，就在這種傳播方式下很快地被全網所知道。
什么是服務注冊？
一個服務將其位置信息在“中心注冊節點”注冊的過程。該服務一般會將它的主機IP地址以及端口號進行注冊，有時也會有服務訪問的認證信息，使用協議，版本號，以及關于環境的一些細節信息。
什么是服務發現？
服務發現可以讓一個應用或者組件發現其運行環境以及其它應用或組件的信息。用戶配置一個服務發現工具就可以將實際容器跟運行配置分離開。常見配置信息包括：ip、端口號、名稱等。
當一項服務存在于多個主機節點上時，client端如何決策獲取相應正確的IP和port。
在傳統情況下，當出現服務存在于多個主機節點上時，都會使用靜態配置的方法來實現服務信息的注冊。
而當在一個復雜的系統里，需要較強的可擴展性時，服務被頻繁替換時，為避免服務中斷，動態的服務注冊和發現就很重要。
圖中，客戶端的一個接口，需要調用服務A-N。客戶端必須要知道所有服務的網絡位置的，以往的做法是配置是配置文件中，或者有些配置在數據庫中。這里就帶出幾個問題：
? 需要配置N個服務的網絡位置，加大配置的復雜性
? 服務的網絡位置變化，都需要改變每個調用者的配置
? 集群的情況下，難以做負載（反向代理的方式除外）
總結起來一句話：服務多了，配置很麻煩，問題多多
既然有這些問題，那么服務發現就是解決這些問題的。話說，怎么解決呢？我們再看一張圖
與之前一張不同的是，加了個服務發現模塊。圖比較簡單，這邊文字描述下。服務A-N把當前自己的網絡位置注冊到服務發現模塊（這里注冊的意思就是告訴），服務發現就以K-V的方式記錄下，K一般是服務名，V就是IP:PORT。服務發現模塊定時的輪詢查看這些服務能不能訪問的了（這就是健康檢查）。客戶端在調用服務A-N的時候，就跑去服務發現模塊問下它們的網絡位置，然后再調用它們的服務。這樣的方式是不是就可以解決上面的問題了呢？客戶端完全不需要記錄這些服務網絡位置，客戶端和服務端完全解耦！
這個過程大體是這樣，當然服務發現模塊沒這么簡單。里面包含的東西還很多。這樣表述只是方便理解。
圖中的服務發現模塊基本上就是微服務架構中服務發現的作用了。
consul 簡介
做服務發現的框架常用的有
? zookeeper
? eureka
? etcd
? consul
這里就不比較哪個好哪個差了，需要的童鞋自己谷歌百度。
那么consul是啥？consul就是提供服務發現的工具。然后下面是簡單的介紹：
consul是分布式的、高可用、橫向擴展的。consul提供的一些關鍵特性：
? service discovery：consul通過DNS或者HTTP接口使服務注冊和服務發現變的很容易，一些外部服務，例如saas提供的也可以一樣注冊。
? health checking：健康檢測使consul可以快速的告警在集群中的操作。和服務發現的集成，可以防止服務轉發到故障的服務上面。
? key/value storage：一個用來存儲動態配置的系統。提供簡單的HTTP接口，可以在任何地方操作。
? multi-datacenter：無需復雜的配置，即可支持任意數量的區域。
我們這里會介紹服務發現，健康檢查，還有一些基本KV存儲。多數據中心有機會另一篇文章再說。
總結：只要知道它是解決我上一部分提出的問題就行，其它的東西慢慢理解
consul的幾個概念
上圖是我從consul官方文檔摳出來的。
我們只看數據中心1，可以看出consul的集群是由N個SERVER，加上M個CLIENT組成的。而不管是SERVER還是CLIENT，都是consul的一個節點，所有的服務都可以注冊到這些節點上，正是通過這些節點實現服務注冊信息的共享。除了這兩個，還有一些小細節，一一簡單介紹。
? CLIENT
CLIENT表示consul的client模式，就是客戶端模式。是consul節點的一種模式，這種模式下，所有注冊到當前節點的服務會被轉發到SERVER，本身是不持久化這些信息。
? SERVER
SERVER表示consul的server模式，表明這個consul是個server，這種模式下，功能和CLIENT都一樣，唯一不同的是，它會把所有的信息持久化的本地，這樣遇到故障，信息是可以被保留的。
? SERVER-LEADER
中間那個SERVER下面有LEADER的字眼，表明這個SERVER是它們的老大，它和其它SERVER不一樣的一點是，它需要負責同步注冊的信息給其它的SERVER，同時也要負責各個節點的健康監測。
? 其它信息
其它信息包括它們之間的通信方式，還有一些協議信息，算法。它們是用于保證節點之間的數據同步，實時性要求等等一系列集群問題的解決。這些有興趣的自己看看官方文檔。
相關開源項目：Zookeeper，Doozer，Etcd，強一致性的項目，這些項目主要用于服務間的協調，同時又可用于服務的注冊。
什么是強一致性協議？
按照某一順序串行執行存儲對象讀寫操作， 更新存儲對象之后， 后續訪問總是讀到最新值。 假如進程A先更新了存儲對象，存儲系統保證后續A,B,C進程的讀取操作都將返回最新值。強一致性模型有幾種常見實現方法， 主從同步復制， 以及quorum復制等。
http://blog.csdn.net/shlazww/article/details/38736511
4.與confd服務集成，動態生成nignx與haproxy配置文件
Raft大概將整個過程分為三個階段，leader election，log replication和commit(safety)。
每個server處于三個狀態：leader，follower，candidate。正常情況下，所有server中只有一個是leader，其它的都是follower。server之間通過RPC消息通信。follower不會主動發起RPC消息。leader和candidate(選主的時候)會主動發起RPC消息。
首先選擇一個leader全權負責管理日志復制，leader從客戶端接收log entries，將它們復制給集群中的其它機器，然后負責告訴其它機器什么時候將日志應用于它們的狀態機。舉個例子，leader可以在無需詢問其它server的情況下決定把新entries放在哪個位置，數據永遠是從leader流向其它機器。一個leader可以fail或者與其他機器失去連接，這種情形下會有新的leader被選舉出來。
http://www.jdon.com/artichect/raft.html
http://blog.csdn.net/cszhouwei/article/details/38374603
zookeeper等不支持多數據中心功能的支持
? 使用 Raft 算法來保證一致性, 比復雜的 Paxos 算法更直接. 相比較而言, zookeeper 采用的是 Paxos, 而 etcd 使用的則是 Raft.
? 支持多數據中心，內外網的服務采用不同的端口進行監聽。 多數據中心集群可以避免單數據中心的單點故障,而其部署則需要考慮網絡延遲, 分片等情況等. zookeeper 和 etcd 均不提供多數據中心功能的支持.
? 支持健康檢查. etcd 不提供此功能.
? 支持 http 和 dns 協議接口. zookeeper 的集成較為復雜, etcd 只支持 http 協議.
? 官方提供web管理界面, etcd 無此功能.
綜合比較, Consul 作為服務注冊和配置管理的新星, 比較值得關注和研究.
二、 Consul架構設計
只有一個數據中心的Consul的架構圖如下：
我們可以看到，有三個不同的服務器由Consul管理。整個架構通過使用Raft算法工作，這有助于我們從三個不同的服務器中選出一個領導者。然后根據諸如Follower和Leader之類的標簽標記這些服務器。顧名思義，Follower有責任遵循Leader的決定。這三個服務器之間進一步相互連接以進行通信。
每個服務器使用RPC與其自己的客戶端進行交互。客戶端之間的通信是使用Gossip協議。可以使用TCP或Gossip來提供與互聯網設施的通信。
Raft算法
Raft是提供一致性的算法。它依賴于CAP定理的原理，該定理指出，在存在網絡分區的情況下，必須在一致性和可用性之間進行選擇。并非CAP定理的所有三個基本原理：Consistency(一致性)、Availability(可用性)、Partition Tolerance(分區容錯性)，都可以在任何給定的時間點實現。人們必須在最好的情況下權衡其中任何兩個。
一個Raft集群包含多個服務器，通常是奇數的。例如，如果我們有五臺服務器，它將允許系統容忍兩個故障。在任何給定時間，每個服務器都處于以下三種狀態之一：Leader，Follower或Candidate。在正常操作中，只有一個領導者，所有其他服務器都是Follower。這些Follower處于被動狀態，即他們自己不發出請求，而只是響應Leader和Candidate的請求。
下圖描述了使用Raft算法工作的工作流模型
協議類型
Consul中有兩種類型的協議，稱為
? Consensus協議
? Gossip協議
現在讓我們詳細了解它們。
Consensus Protocol
Consul使用Consensus protocol來提供CAP定理所描述的一致性。該協議基于Raft算法，其中Raft節點始終處于三種狀態中的任何一種：Follower, Candidate or Leader。
? Leader，負責Client交互和log復制，同一時刻系統中最多存在1個
? Follower，被動響應請求RPC，從不主動發起請求RPC
? Candidate，由Follower向Leader轉換的中間狀態
初始時所有節點都是以Follower啟動。一個最小的 Raft 集群需要三個參與者，這樣才可能投出多數票。當發起選舉時，如果每方都投給了自己，結果沒有任何一方獲得多數票。之后每個參與方隨機休息一陣（Election Timeout）重新發起投票直到一方獲得多數票。這里的關鍵就是隨機 timeout，最先從timeout中恢復發起投票的一方向還在 timeout 中的另外兩方請求投票，這時它們就只能投給對方了，這樣很快就能達成一致。
Gossip Protocol
Gossip協議可用于管理成員資格，跨群集發送和接收消息。在Consul中，Gossip協議的使用以兩種方式發生，WAN（無線區域網絡）和LAN（局域網）。有三個已知的庫，可以實現Gossip算法來發現對等網絡中的節點 ：
? teknek-gossip - 它與UDP一起使用，用Java編寫。
? gossip-python - 它利用TCP堆棧，也可以通過構建的網絡共享數據。
? Smudge - 它是用Go編寫的，使用UDP來交換狀態信息。
Gossip協議也被用于實現和維護分布式數據庫一致性或與一致狀態的其他類型數據，計算未知大小的網絡中的節點數量，穩健地傳播消息，組織節點等。
Remote Procedure Calls
RPC可以表示為遠程過程調用的簡寫形式。它是一個程序用于從另一個程序請求服務的協議。此協議可以位于網絡上的另一臺計算機中，而無需確認網絡詳細信息。
在Consul中使用RPC的真正用處在于，它可以幫助我們避免大多數發現服務工具在一段時間之前所遇到的延遲問題。在RPC之前，Consul過去只使用基于TCP和UDP的連接，這對大多數系統都很好，但對于分布式系統則不行。RPC通過減少從一個地方到另一個地方的分組信息傳輸的時間段來解決這些問題。
三、 Consul系列之服務部署、搭建、使用
主要以linux來講解其他操作平臺見官網Download Consul
下載 wget https://releases.hashicorp.com/consul/1.4.0/consul_1.4.0_linux_amd64.zip
解壓 unzip consul_1.4.0_linux_amd64.zip 得到目錄consul
復制 consul到你的系統的任何一個地方如果你想使用命令行直接訪問確保復制的目錄在你的PATH里 cp consul /usr/local/bin/
驗證consul是否安裝成功出現以下窗口則安裝成功
[root@iZbp1isjfk2rw8fpnxx8wgZ ~]# consul
Usage: consul [–version] [–help] []
Available commands are:
acl Interact with Consul’s ACLs
agent Runs a Consul agent
catalog Interact with the catalog
connect Interact with Consul Connect
debug Records a debugging archive for operators
event Fire a new event
exec Executes a command on Consul nodes
force-leave Forces a member of the cluster to enter the “left” state
info Provides debugging information for operators.
intention Interact with Connect service intentions
join Tell Consul agent to join cluster
keygen Generates a new encryption key
keyring Manages gossip layer encryption keys
kv Interact with the key-value store
leave Gracefully leaves the Consul cluster and shuts down
lock Execute a command holding a lock
maint Controls node or service maintenance mode
members Lists the members of a Consul cluster
monitor Stream logs from a Consul agent
operator Provides cluster-level tools for Consul operators
reload Triggers the agent to reload configuration files
rtt Estimates network round trip time between nodes
services Interact with services
snapshot Saves, restores and inspects snapshots of Consul server state
validate Validate config files/directories
version Prints the Consul version
watch Watch for changes in Consul
Consul Agent
執行consul agent -dev啟動開發模式這個模式會快速啟動一個單節點的Consul。注意這個模式不能數據持久化因此不能用于生產環境
啟動命令簡介
? -server定義agent運行在server模式每個數據中心的Server建議在35個避免失敗情況下數據的丟失
? -client定義agent運行在client模式
? -bootstrap-expect在一個datacenter中期望提供的server節點數目當該值提供的時候consul一直等到達到指定sever數目的時候才會引導整個集群
? -bind節點的ip地址一般是0.0.0.0或云服務內網地址用于被集群中的其他節點所訪問
? -node指定節點在集群中的唯一名稱默認為機器的hostname
? -config-dir配置文件目錄里面所有以.json結尾的文件都會被加載
? 更多可選參數參考Consul Command-line Options
Start Agent
[root@iZbp1isjfk2rw8fpnxx8wgZ ~]# consul agent -dev
==> Starting Consul agent…
==> Consul agent running!
Version: ‘v1.4.0’
Node ID: ‘9e05f4d6-56c1-e57c-c726-15d9ab1c0dd5’
Node name: ‘iZbp1isjfk2rw8fpnxx8wgZ’
Datacenter: ‘dc1’ (Segment: ‘’)
Server: true (Bootstrap: false)
Client Addr: [127.0.0.1] (HTTP: 8500, HTTPS: -1, gRPC: 8502, DNS: 8600)
Cluster Addr: 127.0.0.1 (LAN: 8301, WAN: 8302)
Encrypt: Gossip: false, TLS-Outgoing: false, TLS-Incoming: false
==> Log data will now stream in as it occurs:
看下 consul agent 輸出的幾個重要信息
? Node name代理的唯一名稱默認是機器的hostname可以通過-node標志自定義例如consul agent -dev -node myNode
? Datacenter數據中心Consul支持多個數據中心為了有效的工作每個節點必須被配置且上報到數據中心-datacenter標志用來設置數據中心對于單一的DC配置這個代理默認為dc1
? Server表示代理是以服務器還是客戶端的模式來運行。
? Client Addr用于代理的客戶端接口地址。
? Cluster Addr用于集群中的Consul代理之間通信的地址和端口集改地址必須可供其它節點訪問。
查看集群成員
打開一個新終端執行consul members可以看到集群的成員。
? Node節點名稱
? Address節點地址
? Statusalive表示節點為健康狀態
? Type節點的運行模式Server
Stop Agent
Agent兩種停止方式gracefully或forcefully
gracefully方式停止則是發送中斷信號到Agent進程兩種方法Ctrl+C、kill -INT consul_pid
服務注冊
Consul服務搭建好之后通過提供服務定義或HTTP API注冊一個服務通用的模式是通過提供服務定義的方式下文還會介紹怎么應用Consul進行健康檢查
提供服務定義方式服務注冊
創建目錄/etc/consul.d(.d 后綴意思是這個路徑包含了一組配置文件Consul會載入該目錄下的所有文件。
例如我現在有個測試服務test01端口為3010
sudo mkdir /etc/consul.d/test01.json
{
“service”:{
“name”:“test01”,
“tags”:[
“”,
“”
],
“address”:“127.0.0.1”,
“port”:3010,
“enable_tag_override”: false,
“check”:{
“deregisterCriticalServiceAfter”:“90m”,
“http”:“http://127.0.0.1:3010/health”,
“interval”:“10s”
}
}
}
服務定義配置文件含義
? name服務名
? tags服務的tag自定義可以根據這個tag來區分同一個服務名的服務
? address服務注冊到consul的IP服務發現發現的就是這個IP
? port服務注冊consul的PORT發現的就是這個PORT
? enable_tag_override標簽是否允許覆蓋
? check健康檢查部分
o deregisterCriticalServiceAfter
o http指定健康檢查的URL調用后只要返回20Xconsul都認為是健康的
o interval健康檢查間隔時間每隔10s調用一次上面的URL
重啟Agent設置配置目錄
consul agent -dev -config-dir /etc/consul.d
看以下運行結果
啟動之后控制臺輸出了Synced service "test01"意思是Agent從配置文件中載入了服務定義且成功注冊到服務目錄另外右邊的服務test01也收到了健康檢查接口調用
采用HTTP API服務注冊
調用/v1/agent/service/register接口進行注冊請求Method為PUT方式
請求Body值為服務定義中的service值看一下示例
curl -X PUT
http://127.0.0.1:8301/v1/agent/service/register
-H ‘cache-control: no-cache’
-H ‘content-type: application/json’
-H ‘postman-token: 6b672c02-350f-3d1c-7793-1a0d9e800fc9’
-d ‘{
“id”: “test01”,
“name”:“test01”,
“tags”:[
“”,
“”
],
“address”:“127.0.0.1”,
“port”:3010,
“check”:{
“deregisterCriticalServiceAfter”:“90m”,
“http”:“http://127.0.0.1:3010/health”,
“interval”:“10s”
}
}’
四、 Consul系列之集群搭建
測試用建議本地搭建幾臺虛擬機用于調試，這里的虛擬機分別為3臺Server模式，1臺Client模式，共以下4臺：
? 192.168.6.128 Server模式（初始設置為Leader）
? 192.168.6.129 Server模式
? 192.168.6.130 Server模式
? 192.168.6.131 Client模式
下載相應平臺版本的Consul解壓copy至/usr/local/bin/（系統的環境變量）目錄，這里以1.4.0版本為例，具體安裝參照上篇-consul下載安裝指南。
創建 /usr/src/consul目錄，存放Consul的啟動配置文件consul_config.json：
{
“datacenter”: “consul_cluster”,
“node_name”: “consul_1”,
“server”: true,
“bootstrap_expect”: 3,
“data_dir”: “/usr/src/consul/data”,
“log_level”: “DEBUG”,
“enable_syslog”: true,
“enable_script_checks”: true,
“bind_addr”: “192.168.6.128”,
“client_addr”: “192.168.6.128”,
}
? node_name：節點名稱，等同于-node
? data_dir：數據存放目錄
? enable_syslog：consul日志寫入系統的syslog目錄是否啟用
? enable_script_checks：是否啟用監控檢測腳本
? bind_addr：等同于-bind
? client_addr：等同于-client
Server端部署
? 部署第一臺192.168.6.128
注意：在第一臺啟動的時候加上-ui，只初始化一次，在其它2個節點進行相同操作，但是配置文件中的node_name、bind_addr、client_addr要進行更改，每臺機器保持唯一。
$ sudo consul agent -ui -config-file=/usr/src/consul/consul_config.json
-config-file：加載啟動的配置文件
? 部署第二臺192.168.6.129
修改/usr/src/consul/consul_config.json：
{
“datacenter”: “consul_cluster”,
“node_name”: “consul_2”,
“server”: true,
“bootstrap_expect”: 3,
“data_dir”: “/usr/src/consul/data”,
“log_level”: “DEBUG”,
“enable_syslog”: true,
“enable_script_checks”: true,
“bind_addr”: “192.168.6.129”,
“client_addr”: “192.168.6.129”,
}
執行命令啟動命令
$ sudo consul agent -config-file=/usr/src/consul/consul_config.json
? 部署第三臺192.168.6.130
修改/usr/src/consul/consul_config.json：
{
“datacenter”: “consul_cluster”,
“node_name”: “consul_3”,
“server”: true,
“bootstrap_expect”: 3,
“data_dir”: “/usr/src/consul/data”,
“log_level”: “DEBUG”,
“enable_syslog”: true,
“enable_script_checks”: true,
“bind_addr”: “192.168.6.130”,
“client_addr”: “192.168.6.130”
}
執行命令啟動命令
$ sudo consul agent -config-file=/usr/src/consul/consul_config.json
截止目前服務端已經全部啟動，但是還沒有加入集群，因此還只是單節點的集群，可以在某臺機器上查看成員情況：
注意：直接使用consul members會報錯，需要綁定ip地址
$ consul members --http-addr 192.168.6.128:8500
Node Address Status Type Build Protocol DC Segment
consul_1 192.168.6.128:8301 alive server 1.4.0 2 consul_cluster
Server端集群建立
每個Consul Agent之后，都是相對獨立的并不知道其它節點的存在，現在我們要做的是加入集群，將上面創建的consul_2、consul_3加入到同一個集群consul_1中。
? 第二臺192.168.6.129加入到consul_1中
$ consul join --http-addr 192.168.6.129:8500 192.168.6.128
Successfully joined cluster by contacting 1 nodes. # 成功返回的消息
? 第三臺192.168.6.130加入到consul_1中
$ consul join --http-addr 192.168.6.130:8500 192.168.6.128
目前服務端的集群已經創建完畢，可以看下我們目前的集群成員情況：
consul members --http-addr 192.168.6.128:8500
Node Address Status Type Build Protocol DC Segment
consul_1 192.168.6.128:8301 alive server 1.4.0 2 consul_cluster
consul_2 192.168.6.129:8301 alive server 1.4.0 2 consul_cluster
consul_3 192.168.6.130:8301 alive server 1.4.0 2 consul_cluster
? 通過HTTP API的方式查看集群leader
$ curl 192.168.6.128:8500/v1/status/leader
“192.168.6.128:8300”
? 通過HTTP API的方式查看集群成員
$ curl 192.168.6.128:8500/v1/status/peers
[“192.168.6.129:8300”,“192.168.6.130:8300”,“192.168.6.128:8300”]
Client端部署
現在開始客戶端的部署，方式同服務端有不同
修改/usr/src/consul/consul_config.json：
{
“datacenter”: “consul_cluster”,
“node_name”: “consul_4”,
//“server”: true, 不指定為服務端，默認走客戶端
// “bootstrap_expect”: 3, 只在server模式有效
“data_dir”: “/usr/src/consul/data”,
“log_level”: “DEBUG”,
“enable_syslog”: true,
“enable_script_checks”: true,
“bind_addr”: “192.168.6.131”,
“client_addr”: “192.168.6.131”
}
執行啟動命令：
通過-join參數也可以加入一個已經啟動的集群
$ sudo consul agent -config-file=/usr/src/consul/consul_config.json -join=192.168.6.128
在查看當前集群成員，可以看到為3個Server模式和1個Client模式
$ consul members --http-addr 192.168.6.128:8500
Node Address Status Type Build Protocol DC Segment
consul_1 192.168.6.128:8301 alive server 1.4.0 2 consul_cluster
consul_2 192.168.6.129:8301 alive server 1.4.0 2 consul_cluster
consul_3 192.168.6.130:8301 alive server 1.4.0 2 consul_cluster
consul_4 192.168.6.131:8301 alive client 1.4.0 2 consul_cluster
管理工具中查看
在部署第一臺192.168.6.128機器的時候，consul agent之后有跟一個-ui參數，這個是用于啟動WebUI界面，這個是Consul本身所提供的Web可視化界面，瀏覽器輸入http://192.168.6.128:8500進行訪問
五、 Consul系列之服務注冊與服務發現
以下是上節做Consul集群的時候列的機器列表，下面我們將192.168.6.131機器安裝了Node服務，起了兩個端口
機器 模式 節點名稱
192.168.6.128 Server consul_1（初始設置為Leader）
192.168.6.129 Server consul_2
192.168.6.130 Server consul_3
192.168.6.131 Client consul_4
? 服務一：order_service
$ curl http://192.168.6.131:3010/health
ok
? 服務二：user_service
$ curl http://192.168.6.131:3011/health
ok
服務注冊
對order_service、user_service兩個服務在consul_4節點上進行服務定義，配置中包含了服務的名稱、地址、端口以及每10秒中對服務進行一次健康檢查。
? 注冊服務一：order_service
order_service.json
{
“service”:{
“name”:“order_service”,
“address”:“192.168.1.131”,
“port”: 3010,
“enable_tag_override”: false,
“check”:{
“deregisterCriticalServiceAfter”:“90m”,
“http”:“http://192.168.1.131:3010/health”,
“interval”:“10s”
}
}
}
? 注冊服務二：user_service
user_service.json
{
“service”:{
“name”:“user_service”,
“address”:“192.168.1.131”,
“port”: 3011,
“enable_tag_override”: false,
“check”:{
“deregisterCriticalServiceAfter”:“90m”,
“http”:“http://192.168.1.131:3011/health”,
“interval”:“10s”
}
}
}
? 啟動consul_4進行服務注冊
Consul Agent啟動過程中通過指定-config-dir參數可以定位到配置文件所在目錄，且目錄下文件為.json的都會被Consul Agent配置文件所讀取。
$ sudo consul agent -config-file=/usr/src/consul/consul_config.json -join=192.168.6.128 -config-dir=/etc/consul.d
服務注冊成功之后查看我們的Web管理界面，在consul_4中展示了我們上面定義的兩個服務及端口號
下圖為Web管理界面展示的健康檢查情況，可以看到進行了接口請求，且響應狀態為200，輸出結果為ok。
服務發現
Consul服務發現支持HTTP API和DNS兩種方式
? HTTP API
$ curl http://192.168.6.128:8500/v1/catalog/service/order_service?passing=true
執行命令之后返回Consul的注冊信息、服務信息及健康檢查信息，且指定passing=true，表示返回時過濾掉一些不健康的節點。
[
{
“ID”:“cf35869a-edba-5e1f-77e0-922b55ddfad4”,
“Node”:“consul_4”,
“Address”:“192.168.6.131”,
“Datacenter”:“consul_cluster”,
“TaggedAddresses”:{
“lan”:“192.168.6.131”,
“wan”:“192.168.6.131”
},
“NodeMeta”:{
“consul-network-segment”:""
},
“ServiceKind”:"",
“ServiceID”:“order_service”,
“ServiceName”:“order_service”,
“ServiceTags”:[
]
? DNS方式
現在使用第二種DNS方式查詢具體的服務，Consul提供了默認的名字NAME.service.consul，NAME代指注冊的服務名稱。
對于上面注冊的兩個Web服務對應域名分別為order_service.service.consul和user_service.service.consul，下面先對于order_service.service.consul進行服務查詢
$ dig @192.168.6.128 -p 8600 order_service.service.consul
; <<>> DiG 9.10.3-P4-Ubuntu <<>> @192.168.6.128 -p 8600 order_service.service.consul
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31324
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 2
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;order_service.service.consul. IN A
;; ANSWER SECTION:
order_service.service.consul. 0 IN A 192.168.6.131
;; ADDITIONAL SECTION:
order_service.service.consul. 0 IN TXT “consul-network-segment=”
;; Query time: 1 msec
;; SERVER: 192.168.6.128#8600(192.168.6.128)
;; WHEN: Thu Mar 28 16:55:27 PDT 2019
;; MSG SIZE rcvd: 109
如上所示，ANSWER SECTION:一個A記錄返回了一個服務所在的節點IP地址為：192.168.6.131
為了展示更詳細的信息，在dig命令中我們可以加上SRV參數，可以返回服務所在的節點信息、端口號。
$ dig @192.168.6.128 -p 8600 order_service.service.consul SRV
; <<>> DiG 9.10.3-P4-Ubuntu <<>> @192.168.6.128 -p 8600 order_service.service.consul SRV
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52707
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 3
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;order_service.service.consul. IN SRV
;; ANSWER SECTION:
order_service.service.consul. 0 IN SRV 1 1 3010 consul_4.node.consul_cluster.consul.
;; ADDITIONAL SECTION:
consul_4.node.consul_cluster.consul. 0 IN A 192.168.6.131
consul_4.node.consul_cluster.consul. 0 IN TXT “consul-network-segment=”
;; Query time: 1 msec
;; SERVER: 192.168.6.128#8600(192.168.6.128)
;; WHEN: Thu Mar 28 17:19:29 PDT 2019
;; MSG SIZE rcvd: 164
如上所示，ADDITIONAL SECTION:一個A記錄不止，返回了一個服務所在的節點IP地址為：192.168.6.131，還有節點名稱及數據中心，在ANSWER SECTION:中還可以看到服務的端口號信息。
服務異常情況
現在我們來做些處理將consul_4節點上的order_service服務停掉，此時可以看到故障服務order_service已經不在當前結果列表頁了，保證了客戶端在服務發現過程中只能獲取當前可用的服務節點。
$ dig @192.168.6.128 -p 8600 order_service.service.consul
; <<>> DiG 9.10.3-P4-Ubuntu <<>> @192.168.6.128 -p 8600 order_service.service.consul
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 45049
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;order_service.service.consul. IN A
;; AUTHORITY SECTION:
consul. 0 IN SOA ns.consul. hostmaster.consul. 1553830680 3600 600 86400 0
;; Query time: 0 msec
;; SERVER: 192.168.6.128#8600(192.168.6.128)
;; WHEN: Thu Mar 28 20:38:00 PDT 2019
;; MSG SIZE rcvd: 107
如上所示，已經沒有了ADDITIONAL SECTION:區域信息。
再來看下在健康檢查端，列出了不健康的節點consul_4，標注了哪些是健康狀態和哪些是非正常狀態的服務。
點擊consul_4可以看到詳細的健康檢查信息結果，例如上面我們停掉的order_service服務返回鏈接被拒。
六、 Consul系列之問題匯總
Consul Agent 啟動報錯
$ consul agent -dev -config-dir /etc/consul.d
==> Starting Consul agent…
==> Error starting agent: Failed to start Consul server: Failed to start RPC layer: listen tcp 127.0.0.1:8300: bind: address already in use
這個地址已經在使用了，說明你已經啟動了。
命令ps -ef | grep consul查看使用情況
$ ps -ef | grep consul
root 16140 1 0 Jan20 ? 09:22:26 consul agent -dev
root 21018 19751 0 16:45 pts/0 00:00:00 grep --color=auto consul
如果想要關閉，執行命令kill -9 consul_pid強制殺死進程，第一個元素（上面的16140）就是進程id
查看集群成員報錯
$ consul members
Error retrieving members: Get http://127.0.0.1:8500/v1/agent/members?segment=_all: dial tcp 127.0.0.1:8500: connect: connection refused
原因是由于在啟動Consul時候綁定了IP地址，而默認的為127.0.0.1:8500，解決辦法其實就是進行顯示綁定，看以下用法：
$ consul members --http-addr 192.168.6.128:8500
Node Address Status Type Build Protocol DC Segment
consul_1 192.168.6.128:8301 alive server 1.4.0 2 consul_cluster
關于開啟Consul Web可視化界面的一些問題
這是最簡單快速的啟動方式，在啟動consul時直接啟動webui界面，跟上-ui參數參考以下示例，端口默認為8500
consul agent -server -bootstrap -ui -data-dir=/data/soft/consul_1.4/consul-data -bind=0.0.0.0 -client=0.0.0.0 -node=120.27.239.212
如果阿里云或其他云廠商服務器，在開啟了Web 可視化界面之后，但是瀏覽器輸入 http://127.0.0.1:8500/ui 無法訪問，可能是鏈接被拒等情況，如果使用阿里云請注意安全組是否開啟。
如上所述，為阿里云服務器在安全組規則里做以上設置開啟端口。
七、 Consul配置參數大全
命令行選項
以下選項全部在命令行中指定。
? -advertise - 通告地址用于更改我們通告給集群中其他節點的地址。默認情況下，-bind地址是通告的。但是，在某些情況下，可能存在無法綁定的可路由地址。這個標志使閑聊不同的地址來支持這一點。如果此地址不可路由，則節點將處于持續振蕩狀態，因為其他節點會將非可路由性視為故障。在Consul 1.0和更高版本中，這可以設置為 go-sockaddr 模板。
? -advertise-wan - 廣告WAN地址用于更改我們向通過WAN加入的服務器節點發布的地址。這也可以在與translate_wan_addrs配置選項結合使用時在客戶端代理上設置。默認情況下，-advertise地址是通告的。但是，在某些情況下，所有數據中心的所有成員都不能位于同一個物理或虛擬網絡上，尤其是混合云和專用數據中心的混合設置。該標志使服務器節點能夠通過WAN的公共網絡閑聊，同時使用專用VLAN來相互閑聊以及彼此的客戶端代理，并且如果遠程數據中心是遠程數據中心，則允許客戶端代理在從遠程數據中心訪問時訪問此地址配置translate_wan_addrs。在Consul 1.0和更高版本中，這可以設置為 go-sockaddr 模板
? -bootstrap - 該標志用于控制服務器是否處于“引導”模式。每個數據中心最多只能運行一個服務器，這一點很重要。從技術上講，一個處于引導模式的服務器可以自我選擇為Raft領導者。只有一個節點處于這種模式非常重要; 否則，一致性不能保證，因為多個節點能夠自我選擇。不建議在引導群集后使用此標志。
? -bootstrap-expect - 此標志提供數據中心中預期服務器的數量。不應該提供此值，或者該值必須與群集中的其他服務器一致。提供時，Consul會等待指定數量的服務器可用，然后引導群集。這允許初始領導者自動選舉。這不能與遺留-bootstrap標志結合使用。該標志需要-server模式。
? -bind - 應為內部集群通信綁定的地址。這是集群中所有其他節點都應該可以訪問的IP地址。默認情況下，這是“0.0.0.0”，這意味著Consul將綁定到本地計算機上的所有地址，并將 第一個可用的私有IPv4地址通告給群集的其余部分。如果有多個私有IPv4地址可用，Consul將在啟動時退出并出現錯誤。如果你指定“[::]”，領事將 做廣告第一個可用的公共IPv6地址。如果有多個公共IPv6地址可用，則Consul將在啟動時退出并出現錯誤。Consul同時使用TCP和UDP以及相同的端口。如果您有任何防火墻，請確保同時允許這兩種協議。在Consul 1.0和更高版本中，可以將其設置為要綁定到的空間分隔的地址列表，或者可能會解析為多個地址的 go-sockaddr模板。
? -serf-wan-bind - 應該被綁定到Serf WAN八卦通信的地址。默認情況下，該值遵循與-bind命令行標志相同的規則，如果未指定該值，-bind則使用該選項。這在Consul 0.7.1及更高版本中可用。在Consul 1.0和更高版本中，這可以設置為 go-sockaddr 模板
? -serf-lan-bind - Serf LAN八卦通信應該綁定的地址。這是群集中所有其他LAN節點應可訪問的IP地址。默認情況下，該值遵循與-bind命令行標志相同的規則，如果未指定該值，-bind則使用該選項。這在Consul 0.7.1及更高版本中可用。在Consul 1.0和更高版本中，這可以設置為 go-sockaddr模板
? -client - Consul將綁定客戶端接口的地址，包括HTTP和DNS服務器。默認情況下，這是“127.0.0.1”，只允許回送連接。在Consul 1.0和更高版本中，可以將其設置為要綁定到的空間分隔的地址列表，或者 可能會解析為多個地址的 go-sockaddr模板。
? -config-file - 要加載的配置文件。有關此文件格式的更多信息，請閱讀配置文件部分。該選項可以多次指定以加載多個配置文件。如果指定了多次，稍后加載的配置文件將與先前加載的配置文件合并。在配置合并期間，單值鍵（string，int，bool）將簡單地將它們的值替換，而列表類型將被附加在一起。
? -config-dir - 要加載的配置文件的目錄。Consul將加載后綴為“.json”的所有文件。加載順序是按字母順序排列的，并使用與上述config-file選項相同的合并例程 。可以多次指定此選項以加載多個目錄。不加載config目錄的子目錄。有關配置文件格式的更多信息，請參閱 配置文件部分。
? -config-format - 要加載的配置文件的格式。通常，Consul會從“.json”或“.hcl”擴展名檢測配置文件的格式。將此選項設置為“json”或“hcl”強制Consul解釋任何帶或不帶擴展名的文件，以該格式解釋。
? -data-dir - 此標志為代理存儲狀態提供了一個數據目錄。這對所有代理都是必需的。該目錄在重新啟動時應該是持久的。這對于在服務器模式下運行的代理尤其重要，因為它們必須能夠保持群集狀態。此外，該目錄必須支持使用文件系統鎖定，這意味著某些類型的已裝入文件夾（例如VirtualBox共享文件夾）可能不合適。注意：服務器和非服務器代理都可以在此目錄中的狀態下存儲ACL令牌，因此讀取訪問權限可以授予對服務器上的任何令牌的訪問權限，并允許訪問非服務器上的服務注冊期間使用的任何令牌。在基于Unix的平臺上，這些文件使用0600權限編寫，因此您應確保只有受信任的進程可以與Consul一樣的用戶身份執行。在Windows上，您應確保該目錄具有適當的權限配置，因為這些權限將被繼承。
? -datacenter - 此標志控制運行代理程序的數據中心。如果未提供，則默認為“dc1”。Consul對多個數據中心擁有一流的支持，但它依賴于正確的配置。同一個數據中心內的節點應該位于單個局域網中。
? -dev - 啟用開發服務器模式。這對于在關閉所有持久性選項的情況下快速啟動Consul代理非常有用，從而啟用可用于快速原型開發或針對API進行開發的內存服務器。此模式不適合生產使用，因為它不會將任何數據寫入磁盤。
? -disable-host-node-id - 將此設置為true將阻止Consul使用來自主機的信息生成確定性節點標識，并將生成隨機節點標識，該標識將保留在數據目錄中。在同一臺主機上運行多個Consul代理進行測試時，這非常有用。Consul在版本0.8.5和0.8.5之前缺省為false，因此您必須選擇加入基于主機的ID。基于主機的ID是使用https://github.com/shirou/gopsutil/tree/master/host生成的，與HashiCorp的Nomad共享 ，因此如果您選擇加入基于主機的ID，則Consul和Nomad將使用信息在主機上在兩個系統中自動分配相同的ID。
? -disable-keyring-file - 如果設置，密鑰環不會被保存到文件中。任何已安裝的密鑰在關機時將丟失，只有在給定的 -encrypt密鑰在啟動時可用。這默認為false。
? -dns-port - 偵聽的DNS端口。這將覆蓋默認端口8600.這在Consul 0.7和更高版本中可用。
? -domain - 默認情況下，Consul響應“consul”中的DNS查詢。域。該標志可用于更改該域。該域中的所有查詢都假定由Consul處理，不會遞歸解決。
? -enable-script-checks這將控制是否在此代理上啟用執行腳本的運行狀況檢查，并且默認為false運營商必須選擇允許這些腳本。如果啟用，建議啟用ACL以控制允許哪些用戶注冊新的檢查以執行腳本。這是在Consul 0.9.0中添加的。
? -encrypt - 指定用于加密Consul網絡流量的密鑰。該密鑰必須是Base64編碼的16字節。創建加密密鑰的最簡單方法是使用 consul keygen。群集中的所有節點必須共享相同的加密密鑰才能進行通信。提供的密鑰會自動保留到數據目錄并在代理程序重新啟動時自動加載。這意味著為了加密Consul的閑話協議，這個選項只需要在每個代理的初始啟動序列中提供一次。如果Consul在使用加密密鑰初始化后提供，則忽略提供的密鑰并顯示警告。
? -hcl - HCL配置片段。此HCL配置片段將附加到配置中，并允許在命令行上指定配置文件的全部選項。該選項可以多次指定。這是在Consul 1.0中添加的。
? -http-port - 要監聽的HTTP API端口。這覆蓋了默認端口8500.當將Consul部署到通過環境傳遞HTTP端口的環境時，此選項非常有用，例如像CloudFoundry這樣的PaaS，允許您通過Procfile直接設置端口。
? -join - 啟動時加入的另一位代理的地址。這可以指定多次以指定多個代理加入。如果Consul無法加入任何指定的地址，代理啟動將失敗。默認情況下，代理在啟動時不會加入任何節點。請注意，retry_join在自動執行Consul集群部署時，使用 可能更適合幫助緩解節點啟動競爭條件。
在Consul 1.1.0和更高版本中，這可以設置為 go-sockaddr 模板
? -retry-join- 類似于-join第一次嘗試失敗時允許重試連接。這對于知道地址最終可用的情況很有用。該列表可以包含IPv4，IPv6或DNS地址。在Consul 1.1.0和更高版本中，這可以設置為 go-sockaddr 模板。如果Consul正在非默認的Serf LAN端口上運行，則必須指定。IPv6必須使用“括號”語法。如果給出多個值，則按照列出的順序嘗試并重試它們，直到第一個成功為止。這里有些例子：
? # Using a DNS entry
? $ consul agent -retry-join “consul.domain.internal”
? # Using IPv4
? $ consul agent -retry-join “10.0.4.67”
? # Using IPv6
? $ consul agent -retry-join “[::1]:8301”
?云端自動加入
從Consul 0.9.1開始，retry-join使用go-discover庫接受使用云元數據進行自動集群加入的統一接口 。有關更多信息，請參閱云端自動加入頁面。
Using Cloud Auto-Joining
$ consul agent -retry-join “provider=aws tag_key=…”
? -retry-interval - 加入嘗試之間的等待時間。默認為30秒。
? -retry-max- -join在退出代碼1之前嘗試執行的最大嘗試次數。默認情況下，它設置為0，將其解釋為無限次重試。
? -join-wan - 啟動時加入的另一個WAN代理的地址。可以指定多次以指定要加入的多個WAN代理。如果Consul無法加入任何指定的地址，代理啟動將失敗。默認情況下，代理-join-wan啟動時不會有任何節點。
在Consul 1.1.0和更高版本中，這可以設置為 go-sockaddr 模板。
? -retry-join-wan- 與retry-join第一次嘗試失敗時允許重試wan連接類似。這對于我們知道地址最終可用的情況很有用。截至領事0.9.3 云支持自動加入。
在Consul 1.1.0和更高版本中，這可以設置為 go-sockaddr 模板
? -retry-interval-wan- 兩次-join-wan嘗試之間的等待時間。默認為30秒。
? -retry-max-wan- -join-wan在退出代碼1之前嘗試執行的最大嘗試次數。默認情況下，它設置為0，將其解釋為無限次重試。
? -log-level - Consul代理啟動后顯示的日志級別。這默認為“信息”。可用的日志級別是“跟蹤”，“調試”，“信息”，“警告”和“錯誤”。您始終可以通過consul monitor并使用任何日志級別連接到代理。另外，日志級別可以在配置重載期間更改。
? -node - 集群中此節點的名稱。這在集群內必須是唯一的。默認情況下，這是機器的主機名。
? -node-id - 在Consul 0.7.3及更高版本中可用，即使節點或地址的名稱發生更改，該節點仍然是該節點的唯一標識符。這必須采用十六進制字符串的形式，長度為36個字符，例如 adf4238a-882b-9ddc-4a9d-5b6758e4159e。如果未提供（最常見的情況），那么代理將在啟動時生成一個標識符，并將其保存在數據目錄中， 以便在代理重新啟動時保持相同。如果可能，主機的信息將用于生成確定性節點ID，除非-disable-host-node-id設置為true。
? -node-meta- 在Consul 0.7.3及更高版本中可用，這指定了一個任意的元數據鍵/值對，與表單的節點相關聯key:value。這可以指定多次。節點元數據對具有以下限制：
o 每個節點最多可注冊64個鍵/值對。
o 元數據密鑰的長度必須介于1到128個字符（含）之間
o 元數據鍵只能包含字母數字-，和_字符。
o 元數據密鑰不能以consul-前綴開頭; 這是保留供內部使用的領事。
o 元數據值的長度必須介于0到512（含）之間。
o 開頭的密鑰的元數據值rfc1035-在DNS TXT請求中逐字編碼，否則元數據kv對將根據RFC1464進行編碼。
? -pid-file - 此標志為代理存儲其PID提供文件路徑。這對發送信號很有用（例如，SIGINT 關閉代理或SIGHUP更新檢查確定
? -protocol - 要使用的Consul協議版本。這默認為最新版本。這應該只在升級時設置。您可以通過運行查看Consul支持的協議版本consul -v。
? -raft-protocol - 它控制用于服務器通信的內部版本的Raft一致性協議。必須將其設置為3才能訪問自動駕駛儀功能，但不包括cleanup_dead_servers。Consul 1.0.0及更高版本默認為3（以前默認為2）。有關 詳細信息，請參閱 Raft協議版本兼容性。
? -raft-snapshot-threshold - 這將控制保存到磁盤的快照之間的最小數量的木筏提交條目。這是一個很少需要更改的低級參數。遇到磁盤IO過多的非常繁忙的群集可能會增加此值以減少磁盤IO，并最大限度地減少所有服務器同時進行快照的機會。由于日志會變得更大并且raft.db文件中的空間直到下一個快照才能被回收，所以增加這一點會使磁盤空間與磁盤IO之間的交易關閉。如果由于需要重播更多日志而導致服務器崩潰或故障切換時間延長，服務器可能需要更長時間才能恢復。在Consul 1.1.0和更高版本中，這個默認值為16384，在之前的版本中它被設置為8192。
? -raft-snapshot-interval - 控制服務器檢查是否需要將快照保存到磁盤的頻率。他是一個很少需要改變的低級參數。遇到磁盤IO過多的非常繁忙的群集可能會增加此值以減少磁盤IO，并最大限度地減少所有服務器同時進行快照的機會。由于日志會變得更大并且raft.db文件中的空間直到下一個快照才能被回收，所以增加這一點會使磁盤空間與磁盤IO之間的交易關閉。如果由于需要重播更多日志而導致服務器崩潰或故障切換時間延長，服務器可能需要更長時間才能恢復。在Consul 1.1.0及更高版本中，這個默認設置為30s，并且在之前的版本中設置為5s。
? -recursor - 指定上游DNS服務器的地址。該選項可以提供多次，功能上與recursors配置選項等效。
? -rejoin - 提供時，領事將忽略先前的休假，并在開始時嘗試重新加入集群。默認情況下，Consul將休假視為永久意圖，并且在啟動時不會再嘗試加入集群。該標志允許先前的狀態用于重新加入群集。
? -segment - （僅限企業）此標志用于設置代理所屬網段的名稱。代理只能加入其網段內的其他代理并與其通信。有關更多詳細信息，請參閱網絡細分指南。默認情況下，這是一個空字符串，它是默認的網段。
? -server - 此標志用于控制代理是否處于服務器或客戶端模式。提供時，代理將充當領事服務器。每個Consul集群必須至少有一個服務器，理想情況下每個數據中心不超過5個。所有服務器都參與Raft一致性算法，以確保事務以一致的，可線性化的方式進行。事務修改所有服務器節點上維護的集群狀態，以確保節點發生故障時的可用性。服務器節點還參與其他數據中心中服務器節點的WAN八卦池。服務器充當其他數據中心的網關，并根據需要轉發流量。
? -non-voting-server - （僅限企業）此標志用于使服務器不參與Raft仲裁，并使其僅接收數據復制流。在需要大量讀取服務器的情況下，這可用于將讀取可伸縮性添加到群集。
? -syslog - 該標志啟用記錄到系統日志。這僅在Linux和OSX上受支持。如果在Windows上提供，將會導致錯誤。
? -ui - 啟用內置的Web UI服務器和所需的HTTP路由。這消除了將Consul Web UI文件與二進制文件分開維護的需要。
? -ui-dir - 此標志提供包含Consul的Web UI資源的目錄。這將自動啟用Web UI。目錄必須對代理可讀。從Consul版本0.7.0及更高版本開始，Web UI資產包含在二進制文件中，因此不再需要此標志; 僅指定-ui標志就足以啟用Web UI。指定’-ui’和’-ui-dir’標志將導致錯誤。
?配置文件
除了命令行選項之外，配置還可以放入文件中。在某些情況下，這可能更容易，例如使用配置管理系統配置Consul時。
配置文件是JSON格式的，使得它們易于被人類和計算機讀取和編輯。該配置被格式化為一個單獨的JSON對象，并在其中進行配置。
配置文件不僅用于設置代理，還用于提供檢查和服務定義。這些用于向其他群集宣布系統服務器的可用性。它們分別在檢查配置和 服務配置下分別記錄。服務和檢查定義支持在重新加載期間進行更新。
?示例配置文件
{
“datacenter”: “east-aws”,
“data_dir”: “/opt/consul”,
“log_level”: “INFO”,
“node_name”: “foobar”,
“server”: true,
“watches”: [
{
“type”: “checks”,
“handler”: “/usr/bin/health-check-handler.sh”
}
],
“telemetry”: {
“statsite_address”: “127.0.0.1:2180”
}
}
?示例配置文件，帶有TLS
{
“datacenter”: “east-aws”,
“data_dir”: “/opt/consul”,
“log_level”: “INFO”,
“node_name”: “foobar”,
“server”: true,
“addresses”: {
“https”: “0.0.0.0”
},
“ports”: {
“https”: 8080
},
“key_file”: “/etc/pki/tls/private/my.key”,
“cert_file”: “/etc/pki/tls/certs/my.crt”,
“ca_file”: “/etc/pki/tls/certs/ca-bundle.crt”
}
尤其請參閱ports設置的使用：
“ports”: {
“https”: 8080
}
除非https已為端口分配了端口號，否則Consul將不會為HTTP API啟用TLS > 0。
?配置密鑰參考
? acl_datacenter - 這指定了對ACL信息具有權威性的數據中心。必須提供它才能啟用ACL。所有服務器和數據中心必須就ACL數據中心達成一致。將它設置在服務器上是集群級別強制執行所需的全部功能，但是為了使API正確地從客戶端轉發，它必須在其上進行設置。在Consul 0.8和更高版本中，這也可以實現ACL的代理級執行。有關更多詳細信息，請參閱ACL指南。
? acl_default_policy - “允許”或“否認”; 默認為“允許”。默認策略在沒有匹配規則時控制令牌的行為。在“允許”模式下，ACL是一個黑名單：允許任何未被明確禁止的操作。在“拒絕”模式下，ACL是白名單：任何未明確允許的操作都會被阻止。注意：在您設置acl_datacenter 為啟用ACL支持之前，這不會生效。
? acl_down_policy - “允許”，“拒絕”或“擴展緩存”; “擴展緩存”是默認值。如果無法從令牌acl_datacenter或領導者節點讀取令牌策略，則應用停機策略。在“允許”模式下，允許所有操作，“拒絕”限制所有操作，“擴展緩存”允許使用任何緩存ACL，忽略其TTL值。如果使用非緩存ACL，“extend-cache”就像“拒絕”一樣。
? acl_agent_master_token- 用于訪問需要代理讀取或寫入權限的代理端點或節點讀取權限，即使Consul服務器不存在以驗證任何令牌。這應該只在運行中斷時使用，應用程序通常會使用常規ACL令牌。這是在Consul 0.7.2中添加的，只有在acl_enforce_version_8設置為true 時才會使用 。有關更多詳細信息，請參閱 ACL Agent Master Token。
? acl_agent_token - 用于客戶端和服務器執行內部操作。如果沒有指定，那么 acl_token將被使用。這是在領事0.7.2中添加的。
該令牌至少必須具有對其將注冊的節點名稱的寫入訪問權限，以便設置目錄中的任何節點級別信息，例如元數據或節點的標記地址。還有其他地方使用了這個令牌，請參閱ACL代理令牌 了解更多詳情。
? acl_enforce_version_8 - 用于客戶端和服務器，以確定在Consul 0.8之前預覽新ACL策略是否應該執行。在Consul 0.7.2中添加，Consul版本在0.8之前默認為false，在Consul 0.8和更高版本中默認為true。這有助于在執行開始前允許策略就位，從而輕松過渡到新的ACL功能。有關更多詳細信息，請參閱ACL指南。
? acl_master_token- 僅用于服務器acl_datacenter。如果該令牌不存在，將使用管理級權限創建該令牌。它允許運營商使用眾所周知的令牌ID引導ACL系統。
在acl_master_token當服務器獲取集群領導只安裝。如果您想要安裝或更改acl_master_token，請acl_master_token 在所有服務器的配置中設置新值。一旦完成，重新啟動當前領導者以強制領導人選舉。如果acl_master_token未提供，則服務器不會創建主令牌。當你提供一個值時，它可以是任何字符串值。使用UUID將確保它看起來與其他標記相同，但并非絕對必要。
? acl_replication_token- 僅用于acl_datacenter運行Consul 0.7或更高版本以外的服務器。如果提供，這將啟用使用此令牌的ACL復制來檢索ACL并將其復制到非權威本地數據中心。在Consul 0.9.1及更高版本中，您可以啟用ACL復制enable_acl_replication ，然后使用每臺服務器上的代理令牌API設置令牌。如果acl_replication_token在配置中設置，它將自動設置enable_acl_replication為true以實現向后兼容。
如果存在影響授權數據中心的分區或其他中斷，并且 acl_down_policy設置為“extend-cache”，則可以使用復制的ACL集在中斷期間解析不在緩存中的令牌。有關更多詳細信息，請參閱 ACL指南復制部分。
? acl_token - 提供時，代理向Consul服務器發出請求時將使用此令牌。通過提供“？token”查詢參數，客戶端可以基于每個請求重寫此令牌。如果未提供，則會使用映射到“匿名”ACL策略的空令牌。
? acl_ttl - 用于控制ACL的生存時間緩存。默認情況下，這是30秒。此設置會對性能產生重大影響：減少刷新次數會增加刷新次數，同時減少刷新次數。但是，由于緩存不會主動失效，所以ACL策略可能會過時到TTL值。
? addresses - 這是一個允許設置綁定地址的嵌套對象。在Consul 1.0和更高版本中，這些可以設置為要綁定的空間分隔的地址列表 ，也可以將可以解析為多個地址的go-sockaddr模板設置為空格分隔列表。
http支持綁定到Unix域套接字。套接字可以在表單中指定unix:///path/to/socket。一個新的域套接字將在給定的路徑上創建。如果指定的文件路徑已經存在，Consul將嘗試清除該文件并在其位置創建域套接字。套接字文件的權限可以通過unix_socketsconfig結構調整。
在Unix套接字接口上運行Consul agent命令時，使用 -http-addr參數指定套接字的路徑。您也可以將所需的值放在CONSUL_HTTP_ADDR環境變量中。
對于TCP地址，變量值應該是端口的IP地址。例如：10.0.0.1:8500而不是10.0.0.1。但是，ports在配置文件中定義端口時，端口將在結構中單獨設置 。
以下鍵有效：
o dns - DNS服務器。默認為client_addr
o http - HTTP API。默認為client_addr
o https - HTTPS API。默認為client_addr
? advertise_addr等同于-advertise命令行標志。
? serf_wan等同于-serf-wan-bind命令行標志。
? serf_lan等同于-serf-lan-bind命令行標志。
? advertise_addr_wan等同于-advertise-wan命令行標志。
? autopilot在Consul 0.8中增加的這個對象允許設置多個子鍵，這些子鍵可以為Consul服務器配置操作友好的設置。有關自動駕駛儀的更多信息，請參閱自動駕駛儀指南。
以下子鍵可用：
o cleanup_dead_servers - 這可以控制定期和每當將新服務器添加到群集時自動刪除已死的服務器節點。默認為true。
o last_contact_threshold - 在被認為不健康之前，控制服務器在沒有與領導聯系的情況下可以走的最長時間。必須是持續時間值，例如10s。默認為200ms。
o max_trailing_logs - 控制服務器在被認為不健康之前可以跟蹤領導者的最大日志條目數。默認為250。
o server_stabilization_time - 在添加到集群之前，控制服務器在“健康”狀態下必須穩定的最短時間。只有當所有服務器運行Raft協議版本3或更高時才會生效。必須是持續時間值，例如30s。默認為10s。
o redundancy_zone_tag- （僅限企業）-node-meta當Autopilot將服務器分為多個區域進行冗余時，這將控制使用的密鑰。每個區域中只有一臺服務器可以同時成為投票成員。如果留空（默認），則此功能將被禁用。
o disable_upgrade_migration- （僅限企業）如果設置為true，此設置將禁用Consul Enterprise中的Autopilot升級遷移策略，等待足夠的新版本服務器添加到群集，然后再將其中的任何一個升級為選民。默認為false。
? bootstrap等同于 -bootstrap命令行標志。
? bootstrap_expect等同于-bootstrap-expect命令行標志。
? bind_addr等同于 -bind命令行標志。
? ca_file這為PEM編碼的證書頒發機構提供了一個文件路徑。證書頒發機構用于使用適當的verify_incoming或 verify_outgoing標志檢查客戶端和服務器連接的真實性。
? ca_path這提供了PEM編碼證書頒發機構文件目錄的路徑。這些證書頒發機構用于檢查具有適當verify_incoming或 verify_outgoing標志的客戶端和服務器連接的真實性。
? cert_file這提供了一個PEM編碼證書的文件路徑。證書提供給客戶或服務器來驗證代理的真實性。它必須隨同提供key_file。
? check_update_interval 此間隔控制檢查穩定狀態檢查的輸出與服務器同步的頻率。默認情況下，它被設置為5分鐘（“5米”）。許多處于穩定狀態的檢查會導致每次運行的輸出略有不同（時間戳等），從而導致不斷的寫入。該配置允許推遲檢查輸出的同步，以減少給定時間間隔的寫入壓力。如果支票更改狀態，則新狀態和相關輸出立即同步。要禁用此行為，請將該值設置為“0s”。
? client_addr等同于 -client命令行標志。
? datacenter等同于 -datacenter命令行標志。
? data_dir等同于 -data-dir命令行標志。
? disable_anonymous_signature禁止使用更新檢查提供匿名簽名以進行重復數據刪除。看disable_update_check。
? disable_host_node_id 等同于-disable-host-node-id命令行標志。
? disable_remote_exec 禁用對遠程執行的支持。設置為true時，代理將忽略任何傳入的遠程exec請求。在0.8版之前的Consul版本中，這個默認為false。在Consul 0.8中，默認值更改為true，以使遠程exec選擇加入而不是選擇退出。
? disable_update_check 禁用自動檢查安全公告和新版本發布。這在Consul Enterprise中被禁用。
? discard_check_output 在存儲之前丟棄健康檢查的輸出。這減少了健康檢查具有易失性輸出（如時間戳，進程ID，…）的環境中Consul raft日志的寫入次數。
o discovery_max_stale - 為所有服務發現HTTP端點啟用陳舊請求。這相當于max_staleDNS請求的 配置。如果此值為零（默認值），則將所有服務發現HTTP端點轉發給領導者。如果此值大于零，則任何Consul服務器都可以處理服務發現請求。如果領隊服務器超過領導者discovery_max_stale，則將對領導者重新評估該查詢以獲得更多最新結果。Consul代理還會添加一個新的 X-Consul-Effective-Consistency響應標頭，用于指示代理是否執行了陳舊的讀取。discover-max-stale 在Consul 1.0.7中引入，作為Consul操作員在代理級別強制來自客戶端的陳舊請求的方式，默認值為0，與先前Consul版本中的默認一致性行為相匹配。
? dns_config此對象允許設置多個可以調節DNS查詢服務的子密鑰。有關更多詳細信息，請參閱DNS緩存指南 。
以下子鍵可用：
o allow_stale - 啟用DNS信息的陳舊查詢。這允許任何Consul服務器而不僅僅是領導者來服務請求。這樣做的好處是您可以通過Consul服務器獲得線性讀取可擴展性。在0.7之前的Consul版本中，默認為false，意味著所有請求都由領導者提供服務，從而提供更強的一致性，但吞吐量更低，延遲更高。在Consul 0.7及更高版本中，為了更好地利用可用服務器，默認為true。
o max_stale- 什么時候allow_stale 被指定，這是用來限制陳舊結果被允許的。如果領隊服務器超過領導者max_stale，則將對領導者重新評估該查詢以獲得更多最新結果。在領事0.7.1之前，這默認為5秒; 在Consul 0.7.1和更高版本中，默認為10年（“87600h”），這有效地允許任何服務器回答DNS查詢，不管它多么陳舊。實際上，服務器通常只比領導者短幾毫秒，所以這可以讓Consul在沒有領導者可以選舉的長時間停工場景中繼續提供請求。
o node_ttl - 默認情況下，這是“0”，因此所有節點查找均以0 TTL值提供服務。通過設置此值可以啟用節點查找的DNS緩存。這應該用“s”后綴表示第二個或“m”表示分鐘。
o service_ttl - 這是一個允許使用每項服務策略設置TTL服務查找的子對象。當沒有特定的服務可用于服務時，可以使用“”通配符服務。默認情況下，所有服務均以0 TTL值提供服務。通過設置此值可啟用服務查找的DNS緩存。
o enable_truncate - 如果設置為true，則將返回超過3條記錄或超過適合有效UDP響應的UDP DNS查詢將設置截斷標志，指示客戶端應使用TCP重新查詢以獲得滿載記錄集。
o only_passing - 如果設置為true，任何健康檢查警告或嚴重的節點將被排除在DNS結果之外。如果為false，則默認情況下，只有健康檢查失敗的節點將被排除。對于服務查找，會考慮節點自身的運行狀況檢查以及特定于服務的檢查。例如，如果某個節點的健康狀況檢查非常重要，則該節點上的所有服務都將被排除，因為它們也被視為關鍵。
o recursor_timeout - Consul在遞歸查詢上游DNS服務器時使用的超時。查看recursors 更多細節。缺省值是2s。這在Consul 0.7和更高版本中可用。
o disable_compression - 如果設置為true，則不會壓縮DNS響應。Consul 0.7中默認添加并啟用了壓縮。
o udp_answer_limit - 限制包含在基于UDP的DNS響應的答案部分中的資源記錄數。此參數僅適用于小于512字節的UDP DNS查詢。此設置已棄用，并由Consul 1.0.7替換a_record_limit。
o a_record_limit - 限制A，AAAA或ANY DNS響應（包括TCP和UDP）答案部分中包含的資源記錄數。在回答問題時，Consul將使用匹配主機的完整列表，隨機隨機洗牌，然后限制答案的數量a_record_limit（默認：無限制）。此限制不適用于SRV記錄。
在實施和實施RFC 3484第6節規則9的環境中（即DNS答案總是被排序并因此決不是隨機的），客戶端可能需要設置該值1以保留預期的隨機分配行為（注意： RFC 3484已被過時 RFC 6724，因此它應該越來越不常見，需要用現代的解析器來改變這個值）。
? domain等同于 -domain命令行標志。
? enable_acl_replication在Consul服務器上設置時，啟用ACL復制而不必通過設置復制令牌acl_replication_token。相反，啟用ACL復制，然后在每臺服務器上使用代理令牌API引入令牌。查看acl_replication_token更多細節。
? enable_agent_tls_for_checks 當設置時，使用代理人的TLS配置的一個子集（key_file，cert_file，ca_file，ca_path，和 server_name），以建立HTTP客戶端的HTTP健康檢查。這允許使用代理的憑證檢查需要雙向TLS的服務。這是在Consul 1.0.1中添加的，默認為false。
? enable_debug設置后，啟用一些額外的調試功能。目前，這僅用于設置運行時概要分析HTTP端點。
? enable_script_checks等同于 -enable-script-checks命令行標志。
? enable_syslog等同于-syslog命令行標志。
? encrypt等同于 -encrypt命令行標志。
? encrypt_verify_incoming - 這是一個可選參數，可用于禁用對輸入八卦執行加密，以便在正在運行的群集上從未加密的文件升級到加密的八卦。有關更多信息，請參閱此部分。默認為true。
? encrypt_verify_outgoing - 這是一個可選參數，可用于禁用強制執行傳出八卦的加密，以便在正在運行的群集上從未加密的文件轉換為加密的八卦文件。有關更多信息，請參閱此部分。默認為true。
? disable_keyring_file- 相當于 -disable-keyring-file命令行標志。
? key_file這提供了一個PEM編碼私鑰的文件路徑。密鑰與證書一起用于驗證代理的真實性。這必須隨同提供cert_file。
? http_config 該對象允許為HTTP API設置選項。
以下子鍵可用：
o block_endpoints 此對象是要在代理程序上阻止的HTTP API端點前綴的列表，默認為空列表，表示所有端點都已啟用。與此列表中的一個條目具有共同前綴的任何端點將被阻止，并且在訪問時將返回403響應代碼。例如，為了阻斷所有V1 ACL端點，此設定為 ["/v1/acl"]，這將阻止/v1/acl/create，/v1/acl/update以及與開始其它ACL端點/v1/acl。這只適用于API端點，而不是，/ui或者 /debug必須禁用它們各自的配置選項。任何使用禁用端點的CLI命令都將不再起作用。對于更通用的訪問控制，Consul的ACL系統應該被使用，但是這個選項對于完全去除對HTTP API端點的訪問是有用的，或者對特定的代理來說是非常有用的。這在Consul 0.9.0及更高版本中可用。
o response_headers 該對象允許向HTTP API響應添加標題。例如，可以使用以下配置在HTTP API端點上啟用 CORS：
o {
o “http_config”: {
o “response_headers”: {
o “Access-Control-Allow-Origin”: ""
o }
o }
o }
? leave_on_terminate如果啟用，當代理收到TERM信號時，它將向Leave群集的其余部分發送消息并正常離開。此功能的默認行為根據代理是否作為客戶端或服務器運行而不同（在Consul 0.7之前默認值被無條件設置為false）。在客戶端模式下的代理程序中，默認為true 服務器模式的代理程序，對于服務器模式中的代理程序，缺省為false。
? limits在Consul 0.9.3及更高版本中可用，這是一個嵌套對象，用于配置代理執行的限制。目前，這只適用于客戶端模式的代理，而不是Consul服務器。以下參數可用：
o rpc_rate - 通過將此代理允許為Consul服務器發出的RPC請求的最大請求速率設置為每秒請求數，配置RPC速率限制器。默認為無限，這會禁用速率限制。
o rpc_max_burst - 用于對RPC速率限制器進行再充電的令牌桶的大小。默認為1000個令牌，并且每個令牌都適用于對Consul服務器的單個RPC調用。有關 令牌桶速率限制器如何操作的更多詳細信息，請參閱https://en.wikipedia.org/wiki/Token_bucket。
? log_level等同于 -log-level命令行標志。
? node_id等同于 -node-id命令行標志。
? node_name等同于 -node命令行標志。
? node_meta可用于Consul 0.7.3及更高版本，此對象允許將任意元數據鍵/值對與本地節點相關聯，然后可用于過濾某些目錄端點的結果。有關更多信息，請參閱 -node-meta命令行標志。
? {
? “node_meta”: {
? “instance_type”: “t2.medium”
? }
? }
? performance在Consul 0.7和更高版本中可用，這是一個嵌套對象，允許調整Consul中不同子系統的性能。請參閱服務器性能指南獲取更多詳細信息 以下參數可用：
o leave_drain_time - 服務器在優雅休假期間居住的時間，以便允許對其他Consul服務器重試請求。在正常情況下，這可以防止客戶在執行Consul服務器滾動更新時遇到“無領導者”錯誤。這是在Consul 1.0中添加的。必須是持續時間值，例如10秒。默認為5秒。
o raft_multiplier - Consul服務器用于縮放關鍵Raft時間參數的整數乘法器。忽略該值或將其設置為0將使用下面描述的默認時間。較低的值用于收緊時間并提高靈敏度，而較高的值用于放松時間并降低靈敏度。調整這會影響Consul檢測領導者失敗并執行領導者選舉所花的時間，但需要更多的網絡和CPU資源才能獲得更好的性能。
默認情況下，Consul將使用適用于最小Consul服務器的較低性能時序，當前相當于將此值設置為5（此默認值可能會在未來版本的Consul中進行更改，具體取決于目標最小服務器配置文件是否更改）。將此值設置為1會將Raft配置為其最高性能模式，相當于Consul在0.7之前的默認時間，并且建議用于生產Consul服務器。有關調整此參數的更多詳細信息，請參閱上次接觸時間的說明。最大允許值是10。
o rpc_hold_timeout - 客戶或服務器在領導者選舉期間將重試內部RPC請求的持續時間。在正常情況下，這可以防止客戶遇到“無領導者”的錯誤。這是在Consul 1.0中添加的。必須是持續時間值，例如10秒。默認為7秒。
? ports 這是一個嵌套對象，允許為以下鍵設置綁定端口：
o dns - DNS服務器，-1禁用。默認8600。
o http - HTTP API，-1禁用。默認8500。
o https - HTTPS API，-1禁用。默認-1（禁用）。
o serf_lan - Serf LAN端口。默認8301。
o serf_wan - Serf WAN端口。默認8302.設置為-1以禁用。注意：這將禁用不推薦的WAN聯合。各種目錄和廣域網相關端點將返回錯誤或空的結果。
o server - 服務器RPC地址。默認8300。
? protocol等同于 -protocol命令行標志。
? raft_protocol等同于 -raft-protocol命令行標志。
? raft_snapshot_threshold等同于 -raft-snapshot-threshold命令行標志。
? raft_snapshot_interval等同于 -raft-snapshot-interval命令行標志。
? reap這將控制Consul的子進程自動收集，如果Consul在Docker容器中以PID 1的形式運行，這將非常有用。如果沒有指定，則Consul會自動收集子進程，如果它檢測到它正在以PID 1運行。如果設置為true或false，則無論Consul的PID如何，它都會控制收割（強制分別開啟或關閉） 。Consul 0.7.1中刪除了該選項。對于Consul的更高版本，您將需要使用包裝器收獲流程，請參閱 Consul Docker圖像入口點腳本 以獲取示例。如果您使用的是Docker 1.13.0或更高版本，則可以使用該命令的新–init選項，docker run并且docker將啟用PID 1的初始化進程，以便為容器收集子進程。有關Docker文檔的更多信息。
? reconnect_timeout這將控制從集群中徹底刪除發生故障的節點需要多長時間。默認值為72小時，建議將其設置為至少為節點或網絡分區的預期可恢復的最大停機時間的兩倍。警告：將此時間設置得太低可能會導致Consul服務器在擴展節點故障或分區過程中從法定數中刪除，這可能會使群集恢復復雜化。該值是一個帶單位后綴的時間，可以是秒，分鐘或小時的“s”，“m”，“h”。該值必須> = 8小時。
? reconnect_timeout_wan這是reconnect_timeout參數的WAN等效項，用于控制從WAN池中完全刪除發生故障的服務器所需的時間。這也默認為72小時，并且必須> 8小時。
? recursors此標志提供用于遞歸解析查詢（如果它們不在Consul的服務域內）的上游DNS服務器的地址。例如，節點可以直接使用Consul作為DNS服務器，并且如果該記錄不在“領事”范圍內。域，查詢將在上游解決。從Consul 1.0.1開始，遞歸可以作為IP地址或go-sockaddr模板提供。IP地址按順序解析，重復項被忽略。
? rejoin_after_leave等同于-rejoin命令行標志。
? retry_join- 相當于-retry-join命令行標志。
? retry_interval等同于 -retry-interval命令行標志。
? retry_join_wan等同于 -retry-join-wan命令行標志。每次嘗試加入廣域網地址列表，retry_interval_wan直到至少有一個加入工作。
? retry_interval_wan等同于 -retry-interval-wan命令行標志。
? segment（僅限企業）等同于 -segment命令行標志。
? segments（僅限企業）這是一個嵌套對象列表，它允許設置網段的綁定/通告信息。這只能在服務器上設置。有關更多詳細信息，請參閱 網絡細分指南。
o name - 細分受眾群的名稱。必須是長度介于1到64個字符之間的字符串。
o bind - 用于分組的八卦圖層的綁定地址。-bind如果未提供，則缺省為該值。
o port - 用于細分的八卦圖層的端口（必需）。
o advertise - 用于分組的八卦圖層的廣告地址。-advertise如果未提供，則缺省為該值。
o rpc_listener- 如果為true，則會-bind在rpc端口上的該段地址上啟動單獨的RPC偵聽器。只有段的綁定地址與地址不同時才有效 -bind。默認為false。
? server等同于 -server命令行標志。
? non_voting_server- 相當于 -non-voting-server命令行標志。
? server_name提供時，將覆蓋node_nameTLS證書。它可以用來確保證書名稱與我們聲明的主機名相匹配。
? session_ttl_min 允許的最小會話TTL。這確保會話不會在TTL小于指定的限制時創建。建議將此限制保持在默認值以上，以鼓勵客戶發送頻繁的心跳。默認為10秒。
? skip_leave_on_interrupt這類似于leave_on_terminate但僅影響中斷處理。當Consul收到一個中斷信號（比如在終端上打Control-C）時，Consul會優雅地離開集群。將其設置為true禁用該行為。此功能的默認行為根據代理是否作為客戶端或服務器運行而不同（在Consul 0.7之前默認值被無條件設置為false）。在客戶端模式下的代理上，默認為false服務器模式下的代理，并且默認為true （即服務器上的Ctrl-C將服務器保留在群集中，因此是仲裁，并且客戶端上的Ctrl-C將優雅地離開）。
? start_join-join啟動時指定節點地址的字符串數組。請注意，retry_join在自動執行Consul集群部署時，使用 可能更適合幫助緩解節點啟動競爭條件。
? start_join_wan-join-wan啟動時指定WAN節點地址的字符串數組。
? telemetry 這是一個嵌套對象，用于配置Consul發送其運行時遙測的位置，并包含以下鍵：
o circonus_api_token 用于創建/管理支票的有效API令牌。如果提供，則啟用度量標準管理。
o circonus_api_app 與API令牌關聯的有效應用名稱。默認情況下，它被設置為“consul”。
o circonus_api_url 用于聯系Circonus API的基本URL。默認情況下，它被設置為“ https://api.circonus.com/v2 ”。
o circonus_submission_interval 指標提交給Circonus的時間間隔。默認情況下，它被設置為“10s”（十秒）。
o circonus_submission_urlcheck.config.submission_url來自先前創建的HTTPTRAP檢查的Check API對象 的字段。
o circonus_check_id從先前創建的HTTPTRAP檢查中 檢查ID（不檢查包）。check._cidCheck API對象中字段的數字部分。
o circonus_check_force_metric_activation 強制激活已存在且當前未激活的度量標準。如果啟用了支票管理，則默認行為是在遇到新的指標時添加新指標。如果該指標已經存在于支票中，則不會被激活。此設置將覆蓋該行為。默認情況下，它被設置為false。
o circonus_check_instance_id 唯一標識來自此實例的度量標準。當它們在基礎架構內移動時，它可用于維護度量連續性，即瞬態或短暫實例。默認情況下，它被設置為主機名：應用程序名稱（例如“host123：consul”）。
o circonus_check_search_tag 一個特殊的標簽，當與實例ID結合使用時，有助于在未提供提交URL或檢查ID時縮小搜索結果的范圍。默認情況下，它被設置為service：application name（例如“service：consul”）。
o circonus_check_display_name 指定一個名稱以在創建時進行檢查。該名稱顯示在Circonus UI Checks列表中。可用于Consul 0.7.2及更高版本。
o circonus_check_tags 用逗號分隔的附加標簽列表在創建時添加到支票中。可用于Consul 0.7.2及更高版本。
o circonus_broker_id 創建新支票時使用的特定Circonus Broker的ID。broker._cidBroker API對象中字段的數字部分。如果啟用指標管理并且未提供提交URL和檢查ID，則將嘗試使用實例ID和搜索標記搜索現有檢查。如果找不到，則會創建一個新的HTTPTRAP檢查。默認情況下，不會使用此選項，并選擇隨機企業代理或默認的Circonus Public Broker。
o circonus_broker_select_tag 當未提供經紀人代碼時，將使用特殊標簽選擇Circonus經紀人。這個最好的用途是作為代理應該基于針對所使用的提示，其中該特定的實例正在運行（例如一個特定的地理位置或數據中心，DC：SFO）。默認情況下，這是留空，不使用。
o disable_hostname 這將控制是否在計算機主機名的前面加上運行時間遙測，默認為false。
o dogstatsd_addr這提供了格式中DogStatsD實例的地址host:port。DogStatsD是statsd協議兼容的風格，增加了用標簽和事件信息修飾指標的功能。如果提供，領事將發送各種遙測信息到該實例進行聚合。這可以用來捕獲運行時信息。
o dogstatsd_tags這提供了將被添加到發送到DogStatsD的所有遙測包的全局標簽列表。它是一個字符串列表，其中每個字符串看起來像“my_tag_name：my_tag_value”。
o filter_default 這將控制是否允許過濾器未指定的度量標準。默認為true，這將允許在沒有提供過濾器時的所有指標。如果設置為false不使用過濾器，則不會發送指標。
o metrics_prefix 寫入所有遙測數據時使用的前綴。默認情況下，它被設置為“consul”。這是在Consul 1.0中添加的。對于之前版本的Consul，使用statsite_prefix相同結構中的配置選項。由于此前綴適用于所有遙測提供商，因此它已重新命名為Consul 1.0，而不僅僅是statsite。
o prefix_filter 這是一個過濾規則列表，適用于通過前綴允許/屏蔽指標，格式如下：
o [
o “+consul.raft.apply”,
o “-consul.http”,
o “+consul.http.GET”
o ]
前導的“ + ”將使用給定前綴的任何度量標準，并且前導“ - ”將阻止它們。如果兩個規則之間有重疊，則更具體的規則優先。如果多次列出相同的前綴，則阻塞將優先。
o prometheus_retention_time 如果該值大于0s（缺省值），則可以使Prometheus導出度量標準。持續時間可以使用持續時間語義來表示，并將在指定的時間內匯總所有計數器（這可能會影響Consul的內存使用情況）。此參數的價值至少是普羅米修斯刮擦間隔的2倍，但您也可能需要很長的保留時間，例如幾天（例如744h才能保留至31天）。使用prometheus獲取指標然后可以使用/v1/agent/metrics?format=prometheusURL 執行，或者通過發送值為Accept的Accept頭來text/plain; version=0.0.4; charset=utf-8 執行/v1/agent/metrics（如普羅米修斯所做的那樣）。格式與普羅米修斯本身兼容。在此模式下運行時，建議啟用此選項disable_hostname以避免使用主機名的前綴度量標準。
o statsd_address這以格式提供statsd實例的地址host:port。如果提供，領事將發送各種遙測信息到該實例進行聚合。這可以用來捕獲運行時信息。這僅發送UDP數據包，可以與statsd或statsite一起使用。
o statsite_address這提供了格式中的一個statsite實例的地址host:port。如果提供，領事將匯集各種遙測信息到該實例。這可以用來捕獲運行時信息。這通過TCP流，只能用于statsite。
? syslog_facility何時 enable_syslog提供，這將控制向哪個設施發送消息。默認情況下，LOCAL0將被使用。
? tls_min_version在Consul 0.7.4中添加，它指定了TLS的最低支持版本。接受的值是“tls10”，“tls11”或“tls12”。這默認為“tls10”。警告：TLS 1.1及更低版本通常被認為不太安全; 避免使用這些如果可能。這將在Consul 0.8.0中更改為默認值“tls12”。
? tls_cipher_suites在Consul 0.8.2中添加，它將支持的密碼組列表指定為逗號分隔列表。源代碼中提供了所有支持的密碼套件列表。
? tls_prefer_server_cipher_suites 在Consul 0.8.2中添加，這將導致Consul更喜歡服務器的密碼套件而不是客戶端密碼套件。
? translate_wan_addrs如果設置為true，Consul 在為遠程數據中心中的節點提供DNS和HTTP請求時，會優先使用配置的WAN地址。這允許使用其本地地址在其自己的數據中心內訪問該節點，并使用其WAN地址從其他數據中心到達該節點，這在混合網絡的混合設置中很有用。這是默認禁用的。
從Consul 0.7和更高版本開始，響應HTTP請求的節點地址在查詢遠程數據中心中的節點時也將優選節點配置的WAN地址。一個X-Consul-Translate-Addresses當翻譯被啟用，以幫助客戶知道地址可以被翻譯標題將出現在所有響應。在TaggedAddresses響應中域也有一個lan地址，需要該地址的知識，無論翻譯的客戶。
以下端點轉換地址：
o /v1/catalog/nodes
o /v1/catalog/node/
o /v1/catalog/service/
o /v1/health/service/
o /v1/query//execute
? ui- 相當于-ui 命令行標志。
? ui_dir- 相當于 -ui-dir命令行標志。從Consul版本0.7.0及更高版本開始，此配置密鑰不是必需的。指定此配置鍵將啟用Web UI。沒有必要指定ui-dir和ui。指定兩者都會導致錯誤。
? unix_sockets - 這可以調整Consul創建的Unix域套接字文件的所有權和權限。只有在HTTP地址配置了unix://前綴時才使用域套接字。
需要注意的是，這個選項可能對不同的操作系統有不同的影響。Linux通常會觀察套接字文件權限，而許多BSD變體會忽略套接字文件本身的權限。在特定的發行版上測試此功能非常重要。此功能目前在Windows主機上無法使用。
以下選項在此構造內有效，并全面應用于Consul創建的所有套接字：
o user - 將擁有套接字文件的用戶的名稱或ID。
o group - 套接字文件的組ID標識。該選項目前僅支持數字ID。
o mode - 在文件上設置的權限位。
? verify_incoming- 如果設置為true，Consul要求所有傳入連接都使用TLS，并且客戶端提供證書頒發機構從ca_fileor中簽名的證書ca_path。這適用于服務器RPC和HTTPS API。默認情況下，這是錯誤的，Consul不會強制使用TLS或驗證客戶的真實性。
? verify_incoming_rpc- 如果設置為true，Consul要求所有傳入的RPC連接都使用TLS，并且客戶端提供由證書頒發機構從ca_fileor中簽名的證書ca_path。默認情況下，這是錯誤的，Consul不會強制使用TLS或驗證客戶的真實性。
? verify_incoming_https- 如果設置為true，則Consul要求所有傳入的HTTPS連接都使用TLS，并且客戶端提供由證書頒發機構從ca_fileor中簽名的證書ca_path。默認情況下，這是錯誤的，Consul不會強制使用TLS或驗證客戶的真實性。要啟用HTTPS API，您必須通過ports配置定義HTTPS端口。默認情況下，HTTPS被禁用。
? verify_outgoing- 如果設置為true，則Consul要求所有傳出連接都使用TLS，并且服務器提供由證書頒發機構從ca_fileor中簽名的證書ca_path。默認情況下，這是錯誤的，Consul不會使用TLS進行傳出連接。這適用于客戶端和服務器，因為兩者都會建立傳出連接。
? verify_server_hostname - 如果設置為true，則Consul會驗證所有傳出連接，即服務器提供的TLS證書與“server。。”主機名匹配。這意味著verify_outgoing。默認情況下，這是錯誤的，并且Consul不驗證證書的主機名，只驗證它是由受信任的CA簽署的。此設置對于防止受損客戶端作為服務器重新啟動很重要，從而能夠執行MITM攻擊或添加為Raft對等設備。這在0.5.1中是新的。
? watches - Watches是手表規范的列表，允許在更新特定數據視圖時自動調用外部進程。有關更多詳情，請參閱 手表文檔。手表可以在配置重新加載時修改。
?使用的端口
Consul最多需要6個不同的端口才能正常工作，有些使用TCP，UDP或兩種協議。下面我們記錄每個端口的要求。
? 服務器RPC（默認8300）。這由服務器用來處理來自其他代理的傳入請求。僅限TCP。
? Serf LAN（默認8301）。這是用來處理局域網中的八卦。所有代理都需要。TCP和UDP。
? Serf WAN（默認8302）。這被服務器用來在WAN上閑聊到其他服務器。TCP和UDP。從Consul 0.8開始，建議通過端口8302在LAN接口上為TCP和UDP啟用服務器之間的連接，以及WAN加入泛濫功能。另見： Consul 0.8.0 CHANGELOG和GH-3058
? HTTP API（默認8500）。這被客戶用來與HTTP API交談。僅限TCP。
? DNS接口（默認8600）。用于解析DNS查詢。TCP和UDP。
總結
以上是生活随笔為你收集整理的consul知识梳理与环境搭建的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： JavaSE基础知识（附上代码实现）1
- 下一篇： 计算机应用基础实训室,计算机应用基础实训