RainbondV5.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 更新带来哪些改进有进一步的了解吗？如果还想了解更多知识或者相关内容，请关注创新互联行业资讯频道，感谢大家的支持。