微服務運行指南——For Cattle

站在微服務的角度看容器的基礎設施服務能夠分爲三層：

1. 微服務基礎層

2. 微服務構建層

3. 微服務訪問層

Rancher的服務發現就是基於rancher-dns來實現，建立的stack&service都會生成相應的DNS記錄，用戶能夠經過相應的規則進行訪問，這樣在微服務之間就能夠無需知曉各自的IP地址，直接用服務名進行鏈接便可。

微服務基礎層主要是爲容器提供計算、存儲、網絡等基礎資源。主機計算資源主要是對docker-machine封裝來提供相關服務；容器存儲經過Convoy組件來接入，目前對NFS協議的存儲適配性最佳；容器之間的網絡經過rancher-net組件實現，目前支持ipsec overlay，在Rancher1.2版本會支持CNI標準的網絡插件。

微服務構建層，除了有微服務自己主體程序，還須要有一些額外的輔助工具來完善對應微服務的架構體系。rancher-dns來實現服務發現機制；rancher-metadata能夠靈活動態向微服務所在容器中注入一些配置數據；healthcheck來保證微服務的高可用；同時咱們還須要有微服務打包的工具，保證微服務能夠在任意環境拉起運行。

微服務訪問層，目前服務對外暴露訪問主要以DNS綁定或是負載均衡VIP方式。Rancher提供external-dns、external-lb框架可讓高級用戶hack自身的場景需求，external-dns除了支持公共的DNS服務（如route53），還支持內部DNS服務器（如bind9），而external-lb目前支持F5設備。除此以外，Rancher內置的負載均衡是基於Haproxy實現的，支持L4-L7。

本次分享，我將會以概念介紹原理講解並穿插一些實際案例這樣的方式進行分享。

Rancher的元數據服務rancher-metadata靈活性很是大，比較複雜的微服務架構能夠經過metadata實現必定程度的解耦，尤爲是confd+metadata會有意想不到妙用，這部份內容能夠參考 http://niusmallnan.github.io/...

Rancher的healthcheck基於Haproxy實現，支持TCP/HTTP，當unhealthy觸發時按照預先設置的策略執行：

• 什麼也不作

• 按照scale的容器數量重建

• 保證至少x個healthy的容器數量

當針對某個service建立healthcheck策略後，service中容器所在的agent節點上會啓動Haproxy服務，同時把healthcheck的配置轉化爲Haproxy的配置。如圖中所示添加了backend，其對應的ip就是container的ip。此外還要將Haproxy的stats scket暴露出來，以便讀取backend的狀態信息。

咱們能夠在外部程序中與Haproxy sock通訊，能夠獲取相關backend的狀態信息，因爲咱們在Haproxy中設置check機制，因此backend的狀態是會自動更新的。

Rancher Agent上運行的host-api組件經過Haproxy sock來讀取backend狀態信息，同時經過rancher event機制把狀態信息push給rancher-server，rancher-server根據以前設置的healthcheck策略，來控制相關的rancher agent執行container recreate操做。

若是微服務自己是自帶服務端口（TCP/HTTP），那麼healthcheck規則很好設置，只要正常填寫表單項就能夠。但實際應用中有些微服務並不會有端口暴露，它可能只是一個與DB交互的程序，這時咱們會考慮讓服務自己不要有大的代碼改造，因此就須要用一些小工具來輔助一下。

微服務的訪問入口，除了咱們熟知的LB方式，還能夠經過綁定DNS來實現，尤爲是在私有云場景下，內部DNS的使用其實比單純使用LB暴露IP+Port方式更加簡潔，由於這樣無需考慮微服務的容器漂移致使的服務IP出現變化。

Rancher提供了一個external-dns框架 https://github.com/rancher/ex...，它能夠實現service的服務地址轉換成DNS的記錄。

私有云場景中，不少行業用戶在內部都使用F5硬件負載均衡來暴露服務訪問地址。微服務的改造咱們儘可能控制在程序架構層面，而原有的網絡結構儘可能不要改變，那麼就會引來一個微服務場景如何整合F5設備的問題。

咱們以一個應用場景爲例，生產環境系統中有4個微服務暴露端口分別是9070、907一、907二、9073，出於容災恢復的考慮須要部署兩套環境主環境和備環境，每一個環境三臺主機，全部的數據庫層均放在非容器環境中，全部服務最終經過F5來暴露訪問。

基於Rancher來實現這種應用場景：建立兩個environment分屬主環境和備環境，因爲是不一樣的ENV，因此這兩個環境是從計算存儲網絡層面都是隔離的。每一個環境中建立一個stack，stack下建立4個service，service加上global=true的label，保證每臺host上都運行該service，同時經過portmap把service的服務端口直接暴露在host上，外部的F5設備則將VIP配置到這些HostIP+Port上。

關鍵的F5設置，咱們要考慮最好可以動態設置。Rancher提供了一個external-lb框架 https://github.com/rancher/ex...來解決此問題，F5的驅動亦位列其中，一樣也是經過rancher-metadata組件來獲取微服務的IP+Port信息。

浮動IP本是Iaas的產物，而Caas仍處在不斷演變的過程當中，企業內部的網絡結構仍然須要浮動IP的機制。最主要的場景就是防火牆的規則設置，一般其規則都是針對某個IP，而這個IP就意味着不管後端的服務怎麼變換，它要求IP是不能變化的，不然就要不停的修改防火牆規則，這是企業運維人員最沒法接受的。

本質上咱們須要解決微服務相關的容器發生漂移以後，其對外暴露的IP仍然保持不變。

Rancher的合做夥伴睿雲智合提出過一個浮動IP的解決方案，是一個很不錯的思路。

固然咱們也能夠利用Cattle自有機制來變通地搞定這個問題。

微服務的訪問入口使用內置的rancher-lb方式，能夠經過label scheduling方式，讓rancher-lb的容器只落在固定主機上，相關的防火牆只要配置固定的主機IP便可。

最後，咱們來一塊兒看一下，比較合適的通用的微服務部署結構。

這裏面使用sidekick容器來分離主服務的功能，配置文件和日誌分別由不一樣的容器來處理，同時保證總體性，能夠完整擴容和克隆。配置文件統一放在 convoy鏈接的NFS存儲中，保證配置文件的一致性。logging容器會把日誌統一發送到ELK日誌系統中，便於集中查詢和管理。保證服務的可用性，healthcheck必不可少。外部則使用內置的Rancher LB來暴露訪問。

Q & A

Q：convoy插件的如今有支持ceph或者gluster的catalog麼？

A：gluster的catalog 以前有，可是一直有些問題，如今已經被移除了。convoy目前還不支持ceph。

Q：最後一個架構裏面，是把日誌存到一個volume，而後應用和日誌服務，同時掛載的意思麼？

A：日誌就是經過logging容器發送到ELK中收集起來。

Q：直接用log插件發的麼？

A：log driver只能把標準輸入輸出發送出去，而圖中的架構更適合傳統的寫日誌文件形式，把日誌文件的內容發送到elk中。

Q：具體的操做是否是日誌存在一個sidekick 容易中，讓後讓logging容器來解析和發送？

A：是這樣的。

Q：這樣這個volume 須要mount 本地目錄上去麼？仍是就已一個container的形式存在？

A：一個container足矣。

Q：如今convoy是否是暫時沒有其餘方案把一個集羣的本地host的磁盤利用起來？

A：Rancher有一個longhorn是你說的場景，還在迭代中。