基於Docker的Consul集群實現服務發現

服務發現

/usr/local/server.json 
{
    "datacenter": "dc1",
    "data_dir": "/usr/local/",
    "log_level": "INFO",
    "server": true,
    "bootstrap_expect": 3,
    "bind_addr": "172.18.0.11",
    "client_addr": "0.0.0.0",
    "start_join": ["172.18.0.11","172.18.0.12","172.18.0.13"],
    "ui":true
}

client.json
{
  "data_dir": "usr/local/consuldata",
  "enable_script_checks": true,
  "bind_addr": "172.18.0.21",
  "retry_join": ["172.18.0.11","172.18.0.12","172.18.0.13"],
  "retry_interval": "30s",
  "rejoin_after_leave": true,
  "start_join": ["172.18.0.11","172.18.0.12","172.18.0.13"]
}

{
  "services": 
  [
    {
      "name": "w-master-redis-8888",
      "tags": [
        "master"
      ],
      "address": "172.18.0.21",
      "port": 8888,
      "checks": [
        {
         "args":["sh","-c","/usr/local/consuldata/check_redis_master.sh 172.18.0.21 8888 ******"],
         "Shell":"/bin/bash",
         "interval": "15s"
        }
      ]
    }
  ]
}

redis-slave-8888.json 

{
  "services": 
  [
    {
      "name": "r-slave-redis-8888",
      "tags": [
        "master"
      ],
      "address": "172.18.0.21",
      "port": 8888,
      "checks": [
        {
         "args":["sh","-c","/usr/local/consuldata/check_redis_slave.sh 172.18.0.21 8888 ******"],
         "Shell":"/bin/bash",
         "interval": "15s"
        }
      ]
    }
  ]
}

Consul client節點的Redis主節點（寫節點）服務檢查腳本check_redis_master.sh
以下腳本來源於https://www.cnblogs.com/gomysql/p/8010552.html，做了簡單的修改，在節點的身份判斷邏輯上需要加強。

#!/bin/bash
host=$1
myport=$2
auth=$3
if [ ! -n "$auth" ]
then
auth='\"\"'
fi
comm="/usr/local/redis_instance/redis8888/bin/redis-cli -h $host -p $myport -a $auth " 
role=`echo 'INFO Replication'|$comm |grep -Ec 'role:master'`
echo 'INFO Replication'|$comm
if [ $role -ne 1 ]
then
    exit 2
fi

Consul client節點的Redis從節點服務檢查腳本check_redis_slave.sh

#!/bin/bash
host=$1
myport=$2
auth=$3
if [ ! -n "$auth" ]
then
auth='\"\"'
fi
comm="/usr/local/redis_instance/redis8888/bin/redis-cli -h $host -p $myport -a $auth "
role=`echo 'INFO Replication'|$comm |grep -Ec 'role:slave'`
echo $role
echo 'INFO Replication'|$comm


if [ $role -ne 1 ]
then
    exit 2
fi

Consul服務發現

redis集群配置成功後，重新載入代理服務，consul reload，一切正常的話，consul服務端就可以解析配置的服務了。
如下註冊了兩個服務，分別是r-slave-redis-8888，w-master-redis-8888，分別代表Redis集群的讀寫節點。

r-slave-redis-8888.service.consul服務的解析，指向了三個從節點，172.18.0.24，172.18.0.25，172.18.0.26

故障轉移之後的服務發現:模擬主節點故障，對172.18.0.21節點手動故障轉移，現在172.18.0.21與172.18.0.24角色交換

Redis集群故障轉以後的服務發現解析結果 對於w-master-redis-8888.service.consul這個服務，成功解析到172.18.0.24，172.18.0.22，172.18.0.23三個主節點

Redis集群故障轉以後的服務發現解析結果 對於w-master-redis-8888.service.consul這個服務，成功解析到172.18.0.24，172.18.0.22，172.18.0.23三個主節點

遇到的問題：
1，cosnul服務端集群的時候，clustercenter一開始自定義了一個名稱myconsule_datacenter,導致client節點死活加不進來,按照預設的dc1就沒有問題
目前還不理解這個datacenter的命名規則是什麼？
2，容器節點中的shell腳本要授予可執行許可權chmod +x check_XXX.sh
3，其他異常問題，一定要看日誌，搜索一下基本上都有結果。
以下純粹是Redis集群的問題，與Consul沒有直接關係，僅作為本測試中遇到的問題。
4，容器節點的Redis集群時，需要移除bind_ip的127.0.0.1節點，直接配置docker創建容器時候的IP，創建集群的時候會一致等待，waiting for the cluster to join
這一點redis-cli --cluster做的很扯淡，明明找不到節點，還要死等，不人為終止的話，他會一直waiting
5，Redis集群時候，因為主從都是相對的，需要相互識別對方，主從節點都要指定“masterauth”和“requirepass”，且密碼一致，否則執行cluster  failover提示成功，但故障轉移不成功
6，遇到一個靈異的問題（之前單機多實例的時候也遇到過），在啟動容器上的Redis服務的時候，如果使用絕對路徑啟動，在創建集群的時候會出現從節點無法添加到集群中去的情況，停止服務，以相對路徑方式重啟之後就沒有這個問題

總的來說consul這個中間件使用起來還算是比較簡單，配置也很清爽，不像某些中間件令人作嘔的配置結構（mycat？？？）
這裡沒有配置多數據中心模式，僅配置了單數據中心模式，作為一款服務發現的中間件，是完全沒有問題的，尤其是作為MySQL集群不支持多IP連接驅動的資料庫連接。

參考：