0x0 問題

運維從來都是一個“不起眼”的大問題。運維工作還特別瑣碎，一般要花去工程師大量的時間，同時還有突發性，對工程師機動性要求比較高。所以運維自動化一直在困擾暴走漫畫團隊。

雖說大部分運維工作都交給第三方云服務提供商了，但是平時還是有一些機器的維護之類的，繁瑣的事情。

我 做的最多的應該就是加減服務器了。暴漫的流量趨勢非常規律，每年寒暑假是訪問的高峰期，一般會比平時流量高出2倍。所以每年寒暑假之前都要添加足量的服務 器以應對馬上到來的流量高峰，而在寒暑假結束之后，要去掉一部分機器，以節省開支。剛開始完全是人肉運維，我一個人先去開5臺機器，然后一個個上去改配置 文件之類的，感覺好傻。后面就用了ansible作為自動化運維工具，這個要比puppet和chef輕量很多，對付我們這些簡單的運維工作綽綽有余。 于是現在就變成了開完機器，用ansible同步配置，代碼，啟動app server，然后手動更新nginx配置。

使用ansible之后其實已經輕松很多了，但是還不夠，我想象中的自動化集群，應該可以隨意增加刪除node，node不可用的時候自動刪除，當然這些都不能影響服務的訪問。

下面介紹一種自動化的Rails集群方案

0x1 相關技術

• docker
• hashicorp/consul（https://github.com/hashicorp/consul）
• hashicorp/consul-template（https://github.com/hashicorp/consul-template）
• hashicorp/registrator（https://github.com/gliderlabs/registrator）

0X2 整體架構

0x3 實踐

由于不是科普帖，各種工具的詳細信息就不自己介紹了。

這兩個工具是集群中每個節點的基礎服務。我在一臺機器上，所以把consul cluster給省掉了，只用了一個consul節點。下面是docker-compose配置。

需要注意的是consul的啟動參數里的advertise。應該聲明為host機器的docker0的ip。如果不聲明的話會默認使用容器ip，這樣registrator注冊的設備ip都是不可訪問的。

以上配置啟動之后一套自動服務器發現功能就算完工了。

#p#

接下來，我們配置一個web應用測試一下。

這個配置生成了nginx和rails，并且掛載了本地的sites-enabled文件夾作為nginx的配置來源。注意rails的ports是隨機的。

在sites-enabled中配置nginx server已rails作為backend。

upstream backend { 
} 
server { 
    server_name "10.0.2.15"; 
    location / { 
            proxy_pass http://backend; 
    } 
}  

對你并沒有看錯， upstream并沒有定義可用的backend node。這個配置將會有consul-template根據服務列表自動填充。

讓我們啟動這個web應用，訪問80端口是無法訪問的 應為沒有backend node。

接下來需要安裝consule-template, 在github下載對應的release。

然后創建一個配置文件ct-nginx.conf

consul = "127.0.0.1:8500" 
log_level = "warn" 
 
template { 
    source = "/home/vagrant/nginx.ctmpl" 
    destination = "/home/vagrant/sites-enabled/backend.conf" 
    command = "docker-compose -f /home/vagrant/docker-compose.yml restart web" 
}  

我有映射consul的端口，所以直接使用了127.0.0.1。source就是我們配置文件的模板。如下

upstream backend { 
    {{range service "hello-world"}} 
    server {{.Address}}:{{.Port}};{{end}} 
} 
server { 
    server_name "10.0.2.15"; 
    location / { 
            proxy_pass http://backend; 
    } 
} 

consul-template提供了方便的模板查詢語句，可以直接從consul中查詢并渲染出配置文件。這個模板中就找出了所有名字為“hello-world”的service，并且循環輸出service對應的Address，也就是服務ip，Port。

接著看ct-nginx.conf，destination代表模板生成完畢之后的位置， 這里直接放在nginx的配置文件夾，***command是生成配置后的動作，可以重啟各種服務。我們這里在更新nginx之后重啟生效。

OK，配置已經妥當，consul和registrator也已經啟動， 讓我們看看當前的服務列表。

$ curl localhost:8500/v1/catalog/service/hello-world?pretty 
$ [] 

當前并沒有注冊名為hello_world的服務。

#p#

稍微提一下registrator注冊服務的命名機制，registaor默認是通過提取容器各種參數來生成的的服務參數

比如

docker run -d --name nginx.0 -p 4443:443 -p 8000:80 progrium/nginx 

生成的服務信息如下

[ 
{ 
    "ID": "hostname:nginx.0:443", 
    "Name": "nginx-443", 
    "Port": 4443, 
    "IP": "192.168.1.102", 
    "Tags": [], 
    "Attrs": {}, 
}, 
{ 
    "ID": "hostname:nginx.0:80", 
    "Name": "nginx-80", 
    "Port": 8000, 
    "IP": "192.168.1.102", 
    "Tags": [], 
    "Attrs": {} 
} 
] 

當然也可以通過環境變量來指定

$ docker run -d --name nginx.0 -p 4443:443 -p 8000:80 \ 
           -e "SERVICE_443_NAME=https" \ 
           -e "SERVICE_443_ID=https.12345" \ 
           -e "SERVICE_443_SNI=enabled" \ 
           -e "SERVICE_80_NAME=http" \ 
           -e "SERVICE_TAGS=www" progrium/nginx 

[ 
{ 
    "ID": "https.12345", 
    "Name": "https", 
    "Port": 4443, 
    "IP": "192.168.1.102", 
    "Tags": ["www"], 
    "Attrs": {"sni": "enabled"}, 
}, 
{ 
    "ID": "hostname:nginx.0:80", 
    "Name": "http", 
    "Port": 8000, 
    "IP": "192.168.1.102", 
    "Tags": ["www"], 
    "Attrs": {} 
} 
] 

接下來我們啟動consul-template

$ consul-template -config=./ct-nginx.conf 

會直接根據模板生成一個nginx配置 雖然現在并沒有backend node。

$ cat /home/vagrant/sites-enabled/backend.conf 
upstream backend { 
} 
server { 
    server_name "10.0.2.15"; 
    location / { 
            proxy_pass http://backend; 
    } 
}  

然后啟動我們的web應用。

啟動之后，請求服務列表就可以看到helle-world服務，說明已經實現自動服務發現。

$ curl localhost:8500/v1/catalog/service/hello-world?pretty 
[ 
{ 
    "Node": "node1", 
    "Address": "172.17.42.1", 
    "ServiceID": "registrator1:vagrant_rails_1:80", 
    "ServiceName": "hello-world", 
    "ServiceTags": null, 
    "ServiceAddress": "", 
    "ServicePort": 32783 
} 
]  

瀏覽器中可以正常訪問了，Yeah!

#p#

OK, 讓我們更進一步，scale我們的rails node。

$ docker-compose scale rails=4 
 
$ curl localhost:8500/v1/catalog/service/hello-world?pretty 
[ 
{ 
    "Node": "node1", 
    "Address": "172.17.42.1", 
    "ServiceID": "registrator1:vagrant_rails_1:80", 
    "ServiceName": "hello-world", 
    "ServiceTags": null, 
    "ServiceAddress": "", 
    "ServicePort": 32783 
}, 
{ 
    "Node": "node1", 
    "Address": "172.17.42.1", 
    "ServiceID": "registrator1:vagrant_rails_2:80", 
    "ServiceName": "hello-world", 
    "ServiceTags": null, 
    "ServiceAddress": "", 
    "ServicePort": 32784 
}, 
{ 
    "Node": "node1", 
    "Address": "172.17.42.1", 
    "ServiceID": "registrator1:vagrant_rails_3:80", 
    "ServiceName": "hello-world", 
    "ServiceTags": null, 
    "ServiceAddress": "", 
    "ServicePort": 32785 
}, 
{ 
    "Node": "node1", 
    "Address": "172.17.42.1", 
    "ServiceID": "registrator1:vagrant_rails_4:80", 
    "ServiceName": "hello-world", 
    "ServiceTags": null, 
    "ServiceAddress": "", 
    "ServicePort": 32786 
} 
]  

此時nginx已經重啟，我們可以看到4個backend都開始處理請求。

你可以看到，rails服務器只要啟動之后就自動加入集群，如果一臺節點掛掉之后，會自動從集群里去掉，基本上沒有任何影響。

肯定有不足的地方，歡迎討論， 發出來就是為了學習。

博文出處：http://dev.baozou.com/ye-tan-ji-yu-dockerde-railsji-qun/