Rainbond

今天我们给社区带来了 Rainbond v5.0.4 版本更新，提前恭祝大家升级成功， Rainbond 是开源的 企业应用云操作系统 ，支撑企业应用的开发、架构、交付和运维的全流程，通过 无侵入架构 ，无缝衔接各类企业应用，底层资源可以对接和管理IaaS、虚拟机和物理服务器。 Rainbond 5.0 版本系列发布以来我们已经持续更新了4个BUG修复版本， Rainbond v5.0.4 也将是V5.1发布前的最后一个BUG修复发行版。我们重视向下的兼容，Rainbond V5.0版本的用户都可以快速升级到 Rainbond v5.0.4 ，升级方式如下 【 升级到V5.0.4 】 当前版本我们带来了如下的优化： 优化 增加了对PHP语言源码检查项目，源码主目录必须存在composer.lock文件 增加了对Gradle语言的内存默认设置，Gradle项目默认内存设置为1G 优化了网关策略存储模型，移除了group_name, group_id字段 优化了网关策略设置的UI页面，增加了属性的默认选项 grctl命令行工具增加命令 grctl node condition ，管理节点检查项目 增加了对Dockerfile ARG参数值的动态解析支持 优化了安装程序，支持机器只有公网IP时的安装 BUG修复 【重要】解决了运行Zookeeper集群应用时触发的DNS的BUG

为什么要写这篇文档？ 在交付了很多企业级用户后，我们发现很多用户的环境都是离线的。我们一直在探索离线环境下实现源码构建的方案，以期让这些企业用户可以也可以体验到Rainbond源码构建功能带来的便捷。 那么，在离线环境下，实现源码构建会有哪些难点呢？其实这个问题的答案就是整套源码构建流程中有那些点对于互联网有依赖： - 代码仓库：源码构建过程的起点是一个可用的代码仓库，离线环境下我们不可以使用 Github、Gitee 等基于互联网的代码仓库。Gitlab、Gogs 等私有代码仓库成为了最佳选择。有些用户已经拥有了自己的私有代码仓库，这种情况下，保证Rainbond管理节点所在的服务器可以正常访问到该代码仓库即可；而对于还没有搭建自己的私有代码仓库的用户而言，如何快速搭建一个Gitlab或者Gogs就是离线源码构建需要攻克的第一关。 - 构建私服：构建私服是指在源码构建过程中，获取依赖包的仓库，常见的有 Nexus、Artifactory 等。有些用户已经拥有了自己的私有构建私服用以管理自己的依赖包，这种情况下，我们提供方案让 Rainbond 可以直接对接私服；而对于还没有搭建自己的构建私服的用户而言，Rainbond自带的 rbd-repo 组件可以作为本地仓库使用。 - 应用运行时：应用运行时是指服务运行所依赖的环境，比如对于Java应用而言，运行时就是环境中安装的 Jdk

Zach Jory 构建微服务很容易，操作微服务体系结构很困难。 许多公司都成功地将Kubernetes等工具用于部署，但仍面临着运行时的复杂性问题。而Service Mesh便是解决这些挑战的良方。它极大地简化了容器化应用的管理，使监视和保护基于微服务的应用变得更加容易。 那么考虑使用Service Mesh的最重要的三个因素是什么？ 安全 由于Service Mesh是在数据平面（data plane）上操作的，可以跨网格提供应用安全保障，相比Kubernetes等多层环境提供了更大的安全性。Service Mesh确保了服务间的通信，这样您就可以知道服务正在与谁通信以及通信是否可信。 可观察性 微服务空间中的大多数故障发生在服务之间的交互过程中，因此对这些事务的“视图化”可以帮助团队更好地管理体系结构以避免故障。Service Mesh为您的服务相互交互时所发生的事情提供了一个视图。Service Mesh还大大提高了跟踪能力，并提供了添加跟踪而不触及所有应用的能力，也就是我们所说的Service Mesh代码无侵入和透明性。 简单 Service Mesh不是一种新技术，而是一种模式，使基础设施层的管理更加简单。例如当我们在服务发现方面只需要找到服务并进行连接，那么DNS就够了，但DNS不能提供快速重试或健康度监视，而这是Service Mesh可以提供的

默认提供的JDK Rainbond官方提供了多个版本的OpenJDK供用户使用。这些OpenJDK的安装包托管于好雨科技官方的OSS（对象存储）中。能够接入互联网的Rainbond平台，可以通过rbd-repo组件的代理获取这些资源，而不用人工干预。 用户通过WEB界面配置，或在源码根目录创建 system.properties ，设定 java.runtime.version 来指定OpenJDK版本。 WEB界面设置的值优先级高于 system.properties 中设定的值。 WEB界面指定： system.properties 指定方式： # system.properties 目前Rainbond能识别的版本值为11,10,1.9,1.8,1.7,1.6 java.runtime.version=1.8 在不做出其他任何调整的情况下，在Rainbond执行源码构建时，会获取以下版本的OpenJDK资源： OpenJDK版本 资源地址 1.8（默认） http://lang.goodrain.me/jdk/cedar-14/openjdk1.8.0_201.tar.gz 1.6 http://lang.goodrain.me/jdk/openjdk1.6.0_27.tar.gz 1.7 http://lang.goodrain.me/jdk/cedar-14

Rainbond v5.1.2发布，微服务架构应用便捷管理和交付 Rainbond是开源的企业应用云操作系统，支撑企业应用的开发、架构、交付和运维的全流程，通过无侵入架构，无缝衔接各类企业应用，底层资源可以对接和管理IaaS、虚拟机和物理服务器。 2019年3月，Rainbond发布v5.1版本，经过1个月在上百家企业的实际使用，团队持续跟进版本缺陷，迄今为止发布了2个BUG修复版本。 Rainbond开源产品的目标是成为企业IT系统的云操作系统，作为基础平台支持各行各业的企业用户，优化IT软件开发企业的开发流程和交付流程，做到一站式开发和交付。作为广大行业IT厂商的合作伙伴，为其提供稳定的、好用的、高效的基础平台，服务于行业软件的架构、开发和交付，Rainbond在这条路上砥砺前行。在V5.1版本中我们引入了以下功能体系来服务用户。 支持第三方微服务集成和管理 Rainbond在众多的企业中落地使用的过程中出现了两类共同的问题： 循序渐进的迁移策略，已经上Rainbond的服务如何与遗留服务通信和统一管理。 Rainbond应用网关很好用，但是遗留的服务没办法与Rainbond上的服务共享外网端口或域名。 Rainbond V5.1版本中在提出了第三方服务的概念，即将运行于Rainbond集群外且与Rainbond可以正常网络通信的服务称为第三方服务。对于此类服务

[toc] 持续交付（CD, Continuous delivery）就是说每次提交代码时立即构建，并可以将构建部署到生产环境中，本文将分享一些持续交付相关的方法和经验。 自动化（Automation） 自动化对于完善的CD管道来说必不可少，我们理应尽可能的用自动化取代手动工作以获得最大利益。 过去，我们的开发团队可能在将代码发布到生产环境之前一般会做测试，其中一些可能是手动的，一些则是自动的。但在持续交付的情况下，每次提交都要进行代码测试，因此最好的办法就是“自动化一切可自动化的东西”，并且不应仅限于开发团队。 软件中所有重要部分的自动化都是必要的—— 测试（Tests） - 单元测试、集成测试、UI测试、回归测试、性能测试... 数据库的安装、备份和恢复 产品及其依赖项的安装和测试 代码文档和用户文档 根据我们的产品不同，可能还会有很多其他可自动化的部分，例如基于云计算的产品，可以自动配置基础架构。 经常提交、尽快提交（Commit often, Commit soon） CD流程的第二个重要基础是“经常提交、尽快提交”的能力，在交付软件时，快速的反馈周期可以带来极大的不同。 然而不幸的是，大爆炸开发方法和部署（Big bang development approach and deployments）仍是业界的常态。用这种方式，每隔几个月、一次性发布大量代码到生产环境中很常见

本期主题 Rainbond与Service Mesh微服务架构 时间 2018年04月19日 本周四 晚8:00 直播大纲 浅谈微服务架构 api-gateway快速搭建微服务框架 Service Mesh加速传统应用服务化改造 通过Rainbond落地多种模式微服务 观看方式 提前五分钟加入ZOOM语音直播间 房间号 948-095-8255 直接进入 或 下载ZOOM 进入上述房间 Rainbond技术社群 微信扫描下方二维码，添加「入群接头人」并确认邀请入群 关于Rainbond Rainbond 是一款以应用为中心的开源PaaS，深度整合基于Kubernetes的容器管理、Service Mesh微服务架构最佳实践、多类型CI/CD应用构建与交付、多数据中心资源管理等技术，为用户提供云原生应用全生命周期解决方案，构建应用与基础设施、应用与应用、基础设施与基础设施之间互联互通的生态体系，满足支撑业务高速发展所需的敏捷开发、高效运维和精益管理需求。 来源： oschina 链接： https://my.oschina.net/u/584116/blog/1796784

Service Mesh（服务网格）会是今年微服务生态的主角吗？从趋势来看，众多企业正在将这项理微服务复杂性的技术/工具，搬进他们的IT“火药库”之中。 什么是Service Mesh？ 根据Linkerd CEO William Morgan定义，Service Mesh是用于处理服务间通信的基础设施层，用于在云原生应用复杂的服务拓扑中实现可靠的请求传递。在实践中，Service Mesh通常是一组与应用一起部署，但对应用透明的轻量级网络代理。 Service Mesh与传统基础设施层不同之处在于，它形成了一个分布式的互连代理网络，以sidecar形式部署在服务两侧，服务对于代理无感知，且服务间所有通信都由代理进行路由。 为什么需要Service Mesh？ “Smart endpoint and dumb pipes”是微服务架构在集成服务时采用的一个核心理念，这一理念改变了过去臃肿集中的ESB（企业服务总线），无疑是正确方向上的一大进步，但同时也给我们出了一些难题——多智能才不会过于智能，而服务轻重大小的程度如何拿捏？我们应该如何处理微服务系统中服务间交互的复杂性？放在服务内部还是外部？如果是内部，如何处理业务逻辑关系，或者应该与基础设施更为相关？如果是外部，如何避免重蹈ESB的覆辙？ 皮的不谈，先来看看处理服务间通信时需要关注的点： 服务发现 负载均衡 路由 流量控制

Rainbond 5.1.4发布, 复杂微服务架构整体升级和回滚 今天为大家带来Rainbond 5.1系列第四个更新版本，本次版本更新的主要内容是复杂微服务架构应用整体升级和回滚，能实现复杂微服务架构的持续交付，和复杂架构企业级应用快速交付和升级，另外还有一些小的优化和BUG的修复。 Rainbond是开源的企业应用云操作系统，支撑企业应用的开发、架构、交付和运维的全流程，通过无侵入架构，无缝衔接各类企业应用，底层资源可以对接和管理IaaS、虚拟机和物理服务器。 复杂微服务架构应用整体升级和回滚 面对复杂的微服务架构，微服务组件可能几十个，服务之间存在业务依赖；微服务的版本管理复杂；开发测试流程低效，针对以上问题，单个微服务管理的模式已经不适用，需要考虑微服务架构整体管理。这次的更新能实现复杂微服务架构的整体版本，微服务独立开发，测试环境和生产环境整体升级和回滚，升级的过程只更新变化的服务和配置，过程滚动更新，实现业务不间断升级。 升级和回滚的过程通过Rainbond应用市场实现，Rainbond应用市场定义了一种对应用的存储、共享、交付、管理途径. Rainbond应用市场与传统意义上的镜像仓库不同之处在于，它基于镜像仓库、包仓库和对象存储等存储系统支持，定义了支持大型、分布式数字化业务系统的标准云原生应用模型，并针对应用模型提供创建、发布、存储、交付、安装

Rainbond（云帮）是一款以应用为中心的开源PaaS，深度整合基于Kubernetes的容器管理、Service Mesh微服务架构最佳实践、多类型CI/CD应用构建与交付、多数据中心资源管理等技术，为用户提供云原生应用全生命周期管理解决方案，构建应用与基础设施、应用与应用、基础设施与基础设施之间互联互通的生态体系，满足支撑业务高速发展所需的敏捷开发、高效运维和精益管理需求。 在年度第一次大版本升级 v3.5 基础之上, 本次v3.5.1迭代对部分功能特性进行了补充和优化，并修复了部分情况下可能会出现的BUG，其中 rbd-worker 及 rbd-entrance 组件将通过本次迭代支持高可用部署，至此Rainbond所有组件实现了对HA的全面支持。 详细更新情况如下： 特性 rbd-worker 和 rbd-entrance 组件支持高可用，Rainbond至此全面支持高可用（ #61 ） 源码构建应用 - 支持缓存源码，加快代码获取速度 镜像构建应用 - 支持在启动参数中携带环境变量（ #52 ） 引入全新的应用安装程序，支持单节点安装和计算节点扩容（ rainbond-install ） 应用市场 - 支持远程更新、本地卸载应用 BUG修复 修复由于应用在不同节点部署造成的性能分析数据冗余问题 修复部分情况下应用健康检查禁用无效的问题