資訊專欄INFORMATION COLUMN
摘要：本次分享就介紹一下的機制，由于相關內容文檔極其欠缺，本人也只是通過實踐和代碼閱讀分析其原理，如有謬誤歡迎指正。能夠管理多的同時又拆分出各種服務組件，機制是必不可少的。為實現機制，通常我們會采用等中間件來實現。
我們的Rancher官方技術社區已經創立些許時日了，相信通過我們的線下meetup和線上布道工作，很多朋友對Rancher的使用已經掌握得很純熟了。一些高級用戶開始真正把自己的業務進行微服務化并向Rancher遷移，在遷移的過程中，由于業務本身的復雜性特殊性，可能需要利用Rancher的一些高級特性甚至要對Rancher進行一定的擴展，這就需要對Rancher的一些組件的實現機制有些許了解。
本次分享就介紹一下Rancher的event機制，由于相關內容文檔極其欠缺，本人也只是通過實踐和代碼閱讀分析其原理，如有謬誤歡迎指正。
在大規模系統架構中，event機制通常采用消息驅動 ，它對提升分布式架構的容錯性靈活性有很大幫助，同時也是各個組件之間解耦的利器。Rancher能夠管理N多的agent同時又拆分出各種服務組件，event機制是必不可少的。為實現event機制，通常我們會采用RabbitMQ、ActiveMQ、ZeroMQ等中間件來實現。而Rancher則采用了基于websocket協議的一種非常輕量級的實現方式，它的好處就是極大程度的精簡了Rancher的部署，Rancher無需額外維護一個MQ集群，畢竟websocket的消息收發實現是非常簡單的，各種語言庫均可以支持。
這里我們會考慮一個問題，websocket畢竟不是真正工業級MQ的實現，消息不能持久化，一旦某個event的處理出現問題，或者發生消息丟失，Rancher如何保證各個資源的原子性一致性？Rancher中有一個processpool的概念，它可以看做一個所有event的執行池，當API/UI/CLI有操作時，Rancher會把操作分解成多個event并放入processpool中。比如刪除一個容器時會把 compute.instance.remove 放入processpool中，這個event會發送到對應的host agent上，agent處理完成后會發送reply給rancher-server。如果在這個過程中，由于網絡問題消息丟失，或者agent上執行出現問題，rancher-server沒有收到reply信息，cattle會把這個event重新放到processpool中再次重復上面的過程，直到 compute.instance.remove 完成操作，這個容器的狀態才會在DB中更新，否則該容器狀態會一直處于lock不能被其他服務更新。當然cattle不會把這些event不停的重復執行下去，通常會設置一下TIMEOUT超出后便不再執行（有些資源沒有TIMEOUT機制）。
上面的表述，我們其實可以在UI上看到這個過程，RancherUI上的Processes的Running Tab頁上就能實時得看到這些信息，Processes 在排查一些Rancher的相關問題是非常有用的，大家可以養成 ”查問題先查Processes“的好習慣：
那么監聽event的URL怎么設定呢？非常簡單：
ws://:8080/v1/projects/ /subscribe?eventNames=xxxx
除此之外還需要加上basic-auth的header信息
Authorization: Basic +base64encode(: )
如果是Host上的agent組件，還需要添加agentId參數
ws://:8080/v1/projects/ /subscribe?eventNames=xxxx&agentId=xxxx
agentId 是注冊Host時生成的，如果沒有agentId參數，任何有關無關的event都會發送到所有的Host agent上，這樣就會發生類似“廣播風暴”的效果。
Host agent上運行很多組件，其中python-agent是負責接收和回執event信息的，其運行日志可以在Host上的/var/log/rancher/agent.log文件中查看。
細心的朋友可能會有疑問，我們在添加Host時執行agent容器時并沒有指定cattle-access-key和cattle-secret-key，也就是說python-agent運行時如何獲取這兩個秘鑰信息呢？
其實Rancher有兩種apikey：一種是我們熟知的在UI上手動創建的apikey；另外一種就是agentApikey，它是系統級的，專門為agent設定，添加Host時會先把agentApikey發送到Host上。在cattle的credential表中可以查詢到相關信息：
eventNames都定義了哪些呢？下面兩個文件可以參考：
https://github.com/rancher/ca...系統級的event定義
https://github.com/rancher/ca... 詳細到每種資源(host、volume、instance、stack、service等)的event定義。
此外，一旦我們在UI/CLI/API上的某個操作都會被分解成多個event來執行，每個event信息都會被保存在mysql中，每個event執行成功后會設置成purged狀態，所以表中記錄并不會真正刪除，這就會導致相應的表（container_event表、service_event表、process_instance表）會無限膨脹下去。
Rancher為解決此問題提供了周期性清理機制
events.purge.after.seconds 可以清理container_event和service_event，每兩周清理一次；process_instance.purge.after.seconds可以清理process_instance，每天清理一次。這兩個配置我們都可以在 http:// 下面我們來實踐一下，看看如何在程序中實現對Rancher event的監聽。 Rancher提供了resource.change事件，這個事件是不用reply的，就是說不會影響Rancher系統的運行，它是專門開放給開發者用來實現一些自己的定制功能，所以我們就以resource.change作為例子實踐一下。 Rancher的組件大部分都是基于Golang編寫，所以我們也采用相同的語言。 為了能夠快速實現這個程序，我們需要了解一些輔助快速開發的小工具。 Trash，Golang package管理的小工具，可以幫助我們定義依賴包的路徑和版本，非常輕量且方便
Dapper，這個是基于容器實現Golang編譯的工具，主要是可以幫助我們統一編譯環境
go-skel，它可以幫我們快速創建一個Rancher式的微服務程序，可以為我們省去很多的基本代碼，同時還集成了Trash和Dapper這兩個實用的小工具
使用詳情可以參考我之前寫的一篇內容：
扒一扒Rancher社區中的小工具
回到本文的主題，首先我們基于go-skel創建一個工程名為 scale-subscriber （名字很隨意），執行過程需要耐心的等待：
執行完畢后，我們把工程放到GOPATH中，開始添加相關的邏輯代碼。
在這之前我們可以考慮添加一個healthcheck的服務端口，其實縱觀Rancher所有的微服務組件，基本上除了主程序之外都會添加healthcheck port，這個主要是為了與Rancher中的healthcheck功能配合，通過設定對這個端口的檢查機制來保證微服務的可靠性。
我們利用Golang的goroutine機制，分別添加主服務和healthcheck服務：
主服務的核心就是監聽resource.change的信息，同時注冊handler來獲取event的payload信息，從而可以定制擴展自己的邏輯，這里需要利用Rancher提供的 https://github.com/rancher/ev... 庫來快速實現。
如下圖，在 reventhandlers.NewResourceChangeHandler().Handler 中就可以實現自己的邏輯：
這里我們只是演示監聽event的機制，所以我們就不做過多的業務邏輯處理，打印輸出event信息即可。
然后在項目根目錄下執行make，make會自動調用dapper，在bin目錄下生成scale-subscriber，我們執行scale-subscriber就可以監聽resource.change的信息：
這里我們可以看到分別啟動了healthcheck功能和event listener。然后可以在UI上隨意刪除一個stack，scale-subsciber就可以獲取event信息：
如要將其部署在Rancher中，那就可以將scale-subsciber執行程序打包放到鏡像中，通過compose來啟動。
但是我們知道scale-subsciber啟動需要指定CATTLE_URL、CATTLE_ACCESS_KEY、CATTLE_SECRET_KEY，正常的做法就是我們需要先生成好apikey，然后啟動service的時候設置對應的環境變量。
這樣做就會有弊端，就是apikey這種私密的信息不得不對外暴露，而且還要手動維護這些apikey，非常不方便。
Rancher提供了一個非常方便的做法，就是在service中添加兩個label，
io.rancher.container.create_agent: true
io.rancher.container.agent.role: environment
設定這兩個label后，Rancher引擎會自動創建apikey，并把相應的值設置到容器的ENV中，只要你的程序通過系統環境變量來讀取這些值，就會非常順利的運行起來。
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://m.specialneedsforspecialkids.com/yun/27965.html
摘要：年月日社區技術支持計劃全面啟動，本文是研發人員在社區答疑過程中關于的一些心得和思考。初識基于的消息總線可以很好的與前端兼容，讓消息的傳遞不再是后端的專利。 2016年2月14日「Rancher社區技術支持計劃」全面啟動，本文是Rancher研發人員在社區答疑過程中關于Subscribe Rancher Events的一些心得和思考。 引言 幾乎每個大型的分布式的集群軟件，都離不開一樣東...
摘要：官方于月日發布了其容器部署與管理平臺的最新版本，。架構總覽在版本的整體架構圖如下圖所示上，引擎向下深入演化成了基礎設施引擎，這一點上在時代也早有體現。基礎設施引擎初次安裝版本，會發現多了如下圖所示的明顯標識，默認的引擎需要安裝等服務。 Rancher Labs官方于12月1日發布了其容器部署與管理平臺Rancher的最新版本，Rancher v1.2。Rancher v1.2可以說是一...
摘要：官方于月日發布了其容器部署與管理平臺的最新版本，。架構總覽在版本的整體架構圖如下圖所示上，引擎向下深入演化成了基礎設施引擎，這一點上在時代也早有體現。基礎設施引擎初次安裝版本，會發現多了如下圖所示的明顯標識，默認的引擎需要安裝等服務。 Rancher Labs官方于12月1日發布了其容器部署與管理平臺Rancher的最新版本，Rancher v1.2。Rancher v1.2可以說是一...
摘要：微服務基礎層主要是為容器提供計算存儲網絡等基礎資源。微服務訪問層，目前服務對外暴露訪問主要以綁定或是負載均衡方式。除此之外，內置的負載均衡是基于實現的，支持。私有云場景中，很多行業用戶在內部都使用硬件負載均衡來暴露服務訪問地址。 站在微服務的角度看容器的基礎設施服務可以分為三層： 微服務基礎層 微服務構建層 微服務訪問層 showImg(https://segmentfault.c...
摘要：引言已經發布，相信眾多容器江湖的伙伴們正魔拳擦準備好好體驗一番。為了更好的體驗的完整特性，我們選取了測試比較嚴格的運行環境。 引言 Rancher v1.2已經發布，相信眾多容器江湖的伙伴們正魔拳擦準備好好體驗一番。由于Docker能夠落地的操作系統眾多，各種Docker版本不同的Graph driver，所以通常大版本的第一個release都會在兼容性上有一些小問題。為了更好的體驗R...
閱讀 1001·2021-11-15 18:06
閱讀 2369·2021-10-08 10:04
閱讀 2653·2019-08-28 18:03
閱讀 900·2019-08-26 13:42
閱讀 1923·2019-08-26 11:31
閱讀 2426·2019-08-23 17:13
閱讀 928·2019-08-23 16:45
閱讀 2057·2019-08-23 14:11
