docker集群化自建方案有哪些？
??俗話說雞蛋不要都放在一個籃子里面,把各種集群的節(jié)點拆分部署,應該把各種節(jié)點分機器部署,多個宿主機這樣部署。在自建集群之前，由于不同應用的依賴環(huán)境千差萬別，每添加一個應用，不得不考慮主機上的現(xiàn)有環(huán)境和已經(jīng)在跑的服務，而且部署和測試也是比較繁瑣，沒有辦法滿足我快速嘗試新點子的需求。而 Docker 恰好可以解決應用部署的環(huán)境問題，自建 Docker 集群可以充分利用我手上的閑置 VPS，并且提高應用的可用性。下面就由小編和大家聊一聊docker集群化自建方案。
我們是于2013年開始的成都網(wǎng)站建設公司,提供網(wǎng)站建設,電商網(wǎng)站設計開發(fā),外貿(mào)網(wǎng)站制作,響應式網(wǎng)頁設計,微信小程序開發(fā)、等服務。為客戶創(chuàng)造有價值的品牌營銷體驗，讓互聯(lián)網(wǎng)提升企業(yè)的競爭力！
自建集群有 8 臺 VPS，其中 4 臺性能比較好的 Vultr 中低配小雞，一臺騰訊云低配 VPS，一臺搬瓦工 CN2 小雞，一臺 CloudCone 低配小雞，還有一臺朋友送的 VirMach 小雞。
手上還有幾臺谷歌，不過考慮到用不長久，而且流量貴，就沒在自建集群的考慮范圍內(nèi)。
[root@ctrl-bwh-01 scripts]# docker node ls ID HOSTNAME STATUS AVAILABILITY MANAGER STATUS ENGINE VERSION q0kllzk1ezr9h449cjatak17z GLBS-CC-01 Ready Active 18.09.5 ioacz1khl94m01wul1z70qatu * ctrl-bwh-01 Ready Active Reachable 18.09.5 1sj867qzlrgdp72705pcnvleb db-vultr-01 Ready Active 18.09.5 dua8lh9h6yt5b58jwwn5vtlu6 db-vultr-02 Ready Active 18.09.5 rk4newk0r7z51lvgjil564bar web-qq-01 Ready Active 18.09.5 xaq6d5n4kzcxj7phnvc32xw21 web-virmach-01 Ready Active 18.09.5 1e2a4scv0eskgq0og3xqpedco web-vultr-01 Ready Active Reachable 18.09.5 5jw8pe7vkzr2iwo3m1rrr1ef5 web-vultr-02 Ready Active Leader 18.09.5
二、集群方案
說到 Docker 集群，一般都會提到鼎鼎有名的 k8s。而我覺得 k8s 太重了，我的眾多低配 VPS 跑 k8s 之后，能分配給應用的資源就少得可憐，所以 k8s 是直接就被我 pass 掉的。
雖然也有 k3s 之類的輕量級 k8s 解決方案，不過我還是選擇了原生的 docker swarm。VPS 安裝好 Docker 之后，不需要額外安裝軟件，就可以馬上建立集群。
# 集群初始化，節(jié)點成為 manager 節(jié)點 docker swarm init --advertise-addr=x.x.x.x # 集群丟失 Leader 時，強制重建集群 docker swarm init --advertise-addr=x.x.x.x --force-new-cluster # 獲取作為 worker 節(jié)點加入集群的命令 docker swarm join-token worker # 獲取作為 manager 節(jié)點加入集群的命令 docker swarm join-token manager # 加入集群 docker swarm join --token xxx x.x.x.x:xxx --advertise-addr=x.x.x.x
官方文檔中有提到，Docker 會自動設置--advertise-addr，該參數(shù)非必填。不過根據(jù)個人經(jīng)驗來看，還是強烈建議顯式指定該參數(shù)，尤其當 VPS 有多個網(wǎng)卡時。
三、統(tǒng)一的服務入口
在集群內(nèi)部通過docker service create xxx的命令創(chuàng)建服務之后，如果有設置對外暴露端口，那么可以向集群中任意一臺 VPS 的指定端口請求服務。
手上的應用還是 Web 應用居多，而它們都需要 80 或 443 端口，為了讓它們都能正常提供服務，集群需要一個統(tǒng)一的前端應用提供負載均衡服務，根據(jù)一定的規(guī)則（比如）轉(zhuǎn)發(fā)給后端應用。
雖然 nginx 也可以比較方便地實現(xiàn)負載均衡，但是我此處選用的是相對專業(yè)的、功能更完善的 traefik。traefik 提供服務自動發(fā)現(xiàn)、HTTPS 證書自動生成、服務監(jiān)測指標數(shù)據(jù) 等功能，感興趣的同學可以前往官網(wǎng)了解詳情。
Traefik 還提供了簡易的 Web UI，可以看到當前集群的服務數(shù)量和服務狀態(tài)。
四、集群管理面板
雖然可以登錄到 manager 節(jié)點，敲命令行管理集群節(jié)點、服務，但還是稍麻煩些，而且不太希望所有維護人員都有權(quán)限直接操作機器。
可以管理 Docker Swarm 集群管理面板也不少，能入法眼的就 Rancher 和 Portainer，然而由于 Rancher 對宿主機配置要求比較高，消耗資源較多，我最終選擇了輕量級的 Portainer。
Portainer 官網(wǎng)提供了比較多的管理方式，踩了比較多的坑之后，我采用的是 agent portainer 這種方式。以 global 模式在每個節(jié)點部署 agent 服務，portainer 部署時需要指定連接 agent 服務。欲知詳情，請看官方文檔。
Portainer 還提供了服務更新的 WebHook，我現(xiàn)在的博客和部分站點的代碼倉庫更新后，通過在 GitLab 設置的 CI-CD 配置，自動打包鏡像，然后觸發(fā) WebHook 自動更新，省時省力。
當然，Portainer 也是有不完善的地方，比如查看集群服務時，會偶爾出現(xiàn)「無法連接」的報錯，而且不能連接數(shù)據(jù)庫，所以部署 Portainer 服務時，要限制它固定在某臺宿主機上。不然，會出現(xiàn)頻繁設置密碼等現(xiàn)象。
五、監(jiān)控和告警系統(tǒng)
traefik 提供的管理面板是非常簡單的，僅能查看一些基礎數(shù)據(jù)，比如某個服務有多少后端，整體的服務狀態(tài)。為了能夠定制化監(jiān)控集群中的服務，并且在需要的時候觸發(fā)告警，讓物理人介入進行維護，需要一個監(jiān)控和告警系統(tǒng)。
而 Grafana 恰好可以滿足需求，配合 Prometheus 以及 Prometheus 相關的 Exporter，一個五臟俱全的監(jiān)控告警系統(tǒng)呼之欲出。
因為騰訊的帶寬極小、性能又比較一般，提供對外服務不太合適，為了充分利用資源，我便把監(jiān)控和告警系統(tǒng)相關的大多服務都部署在上面。本來還想搞一個 ES 在騰訊上，無奈配置太低，只好作罷。
有了監(jiān)控面板，可以清楚地知道具體服務的服務狀態(tài)和服務數(shù)據(jù)規(guī)律，下圖中的柱狀圖表示了以 5 分鐘為統(tǒng)計周期的「每秒處理請求數(shù)」。注：該面板的標題Total requests over容易產(chǎn)生誤解。
下圖是站點升級結(jié)束時，Redis 的服務數(shù)據(jù)。一般情況下，Clients 會在 10 以下，當 Clients 飆升到 50 以上，就要額外關注站點的服務狀態(tài)。通過合理設置閾值，可以讓 Grafana 在超過閾值時發(fā)送告警通知，提醒維護人員對服務進行擴容等操作。
原有服務都是單機部署，需要改造并打包 Docker 鏡像。改造難點其實在于持久化數(shù)據(jù)的存儲與讀寫，比如 Web 應用的 Session 存儲、圖片存儲、附件存儲等。
對于 Session 存儲，可以搭建中心化的數(shù)據(jù)中心解決，或者是改用 token 方式進行登錄驗證。對于圖片存儲、附件存儲，我的改造方案是，將全量數(shù)據(jù)存放在 BackBlaze 中，每個應用按需從云存儲中心拉取數(shù)據(jù)，并定期刪除冷門數(shù)據(jù)。小伙伴們要想獲得更多docker集群化的內(nèi)容，請關注創(chuàng)新互聯(lián)！
當前名稱：docker集群化自建方案有哪些？
網(wǎng)址分享：http://m.jiaotiyi.com/article/sdjhco.html