Rainbond V5.1.7 更新帶來哪些改進

今天就跟大家聊聊有關Rainbond V5.1.7 更新帶來哪些改進，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結了以下內容，希望大家根據這篇文章可以有所收獲。

2019年9月08日，Rainbond發布5.1.7版本，本次版本更新帶來了全新的服務以及實例的狀態控制和UI可視化，服務運行后臺事件實時反饋，使開發者更容易掌握服務運行狀態。

• Rainbond：支撐企業應用的開發、架構、交付和運維的全流程，通過“無侵入”架構無縫銜接各類企業應用，底層資源可以對接和管理IaaS、虛擬機和物理服務器。 Rainbond是什么？

• 發布版本：5.1.7

• 版本更新：推薦

• 更新范圍：服務狀態控制，操作審計記錄，日志推送和存儲

服務升級過程透明

Rainbond的關鍵特點是一鍵完成從代碼獲取到構建打包，滾動上線的完整周期，這樣的體驗追求是好的，然而代碼的構建過程受限于代碼是否規范或者錯誤的代碼而不能正常完成，滾動上線過程依然會取決于服務構建版本是否能夠正常工作，集群狀態是否正常等等不確定因素，在過去的版本中用戶對這一段過程的執行只能關注一個最終狀態而無法方便地看到細節信息，如何在眾多的不確定中提供一個確定的流程形成良好的“人機”互補是一個難題。為了解決這個問題又不能給我們用戶帶來過多的復雜性，我們依然堅持從源碼或鏡像開始的一鍵部署流程，但在流程進行中時在UI中區分三個階段的可視化體驗：

• 構建階段 服務觸發構建后如果停留在操作頁面上時，Rainbond將直接彈出日志實時刷新框，盡可能的還原在終端顯示日志的形態（這里是個挑戰），讓開發者可以更加清晰直接的判斷是否有異常發生，除此之外無需進行其他動作。

• 升級階段 服務構建完成后自動進入升級階段，UI上將展現實例的滾動升級過程，全程體現一個實例從創建、調度、初始化、啟動狀態過程。其中任何環節出現異常，用戶可以快速定位，同時在詳情信息中Rainbond將給出異常處理建議，90%的情況下依然不需要用戶去學習和理解Kubernetes的復雜概念。

• 運行階段 運行階段的服務實例被Rainbond實時監控，一旦出現比如異常退出、OOM、健康檢測不通過的情況下都會詳細記錄事件日志，用戶可以從UI上便捷查詢。

操作審計記錄（beta）

服務的每一項屬性修改和操作對于服務的生命周期都直觀重要，同時也是清晰的責任體現，本次版本更新我們對服務的操作事件記錄架構進行了修改，從過去由控制臺記錄事件統一調整到數據中心進行全量事件記錄，這里的全量包括各類屬性修改、生命周末操作和服務運行態時的系統維護操作和記錄。遺憾的是本次版本周期有限，事件的記錄暫未擴展到應用級和租戶級，當然這是我們社區計劃之一。未來的版本中我們將加快此功能的GA進程，完整記錄所有資源的操作記錄，對于用戶實現細節的權限控制和審計是有益的。

更易用的日志查詢

查詢服務日志是用戶在排查運行服務是否正常工作的關鍵途徑，我們依然堅持服務日志以服務為單位實時推送用戶查看的效果體驗，不同的是本次版本中我們重構了日志推送的WebSocket實現，盡可能保證日志可以準確，及時的推送到前臺UI，同時日志存儲層持久化落盤也更加及時（為了減少管理節點IO占有，日志落盤采用延時、批量落盤機制，最大延遲1分鐘）。在前端UI方面盡可能復原日志樣式，比如保留顏色和格式等，用戶使用起來類似于在系統終端的日志查詢。

其他功能改進和BUG修復

• 應用網關增加策略的合法性強制檢查策略,增強網關的容錯性，減少配置重置頻率。 #321

• 修復Java多模塊代碼檢測生成的編譯命令和參數重復的BUG #356

• 修復rbd-monitor模塊異常停止對部分監控目標的服務發現的BUG #350

• 移除性能分析插件在分析websocket協議時產生的大量錯誤日志 #354

• 修復服務日志超過最大限制后無法再收集的BUG. #371

• 基于源碼創建服務時增加設置子目錄的功能 #219

• 修復了源碼地址過長（超過100字符）無法設置的BUG #225

• 修復基于阿里云鏡像倉庫webhook鏡像名稱驗證不通過的BUG #218

• 修復分享應用時產生的“應用信息處理發生錯誤”異常錯誤 #203

• 修復安裝過程中對磁盤的檢測錯誤 #113

• 修復升級腳本對服務配置文件識別兼容性差的問題

安裝

> 參考Rainbond安裝文檔指南

版本升級

升級要求和注意事項

• V5.1.7版本支持從V5.1.2 - V5.1.6版本升級，如果你還未升級到V5.1.2版本，參考V5.1.x版本升級文檔，先升級至V5.1.2版本：

  grctl version, 例如5.1.6版本顯示如下：Rainbond grctl v5.1.6-release-e98f87c-2019-08-12-01

• 升級過程會重啟管理服務，因此只有單管理節點的集群會短暫影響控制臺操作和應用訪問，請選擇合理的升級時間段。

• 升級過程腳本需要從集群獲取節點數據，請務必在集群正常工作情況下進行升級。

• 升級前請備份控制臺和數據中心數據庫。

• 升級過程的主要耗時點是解壓升級包和導入服務鏡像的過程，根據你的服務器寫入速度而定。

• 如果你手動調整過/opt/rainbond/conf下的服務配置文件導致升級失敗請到社區咨詢。

下載 5.1.7 更新包

離線包鏡像大小約1.3GB，需要保證當前集群磁盤可用空間至少不低于2G

# Rainbond 組件升級包
wget https://pkg.rainbond.com/offline/5.1/rainbond.images.2019-09-03-5.1.7.tgz -O /grdata/services/offline/rainbond.images.upgrade.5.1.7.tgz

# 升級腳本包
wget https://pkg.rainbond.com/offline/5.1/rainbond-ansible.upgrade.5.1.7.tgz -O /grdata/services/offline/rainbond-ansible.upgrade.5.1.7.tgz

第一個管理節點執行下述命令升級平臺

再次提醒，升級前系統比較運行正常，升級過程耗時取決于你的系統磁盤寫入速度，腳本未成功之前請勿主動終止升級。

rm -rf  /tmp/rainbond-ansible
rm -rf /grdata/services/offline/upgrade
mkdir -p /tmp/rainbond-ansible
tar xf /grdata/services/offline/rainbond-ansible.upgrade.5.1.7.tgz -C /tmp/rainbond-ansible
cd /tmp/rainbond-ansible/scripts/upgrade/
bash ./upgrade.sh

平臺升級完成驗證

• 執行 grctl cluster確定所有服務和節點運行正常

• grctl version 確認版本已升級到5.1.7，運行組件鏡像版本為 v5.1.7-release

插件升級

本次版本更新了性能分析插件，請在平臺完成升級后按照如下方式升級插件：

升級腳本已自動更新插件鏡像 goodrain.me/tcm

1. 進入平臺，不同的團隊分別進入插件管理，選擇性能分析插件，點擊插件的構建。

2. 更新使用當前插件的服務，插件即可生效。

看完上述內容，你們對Rainbond V5.1.7 更新帶來哪些改進有進一步的了解嗎？如果還想了解更多知識或者相關內容，請關注億速云行業資訊頻道，感謝大家的支持。