Rainbond

如果在公有云(比如阿里云, AWS)上的分布式数据库, 无法迁移到 Rainbond 上; 或是其他尚未迁移到 Rainbond 的数据库, 那么你可以使用 第三方服务 将它们注册到 Rainbond 中, 从而使得集群内服务也可以访问它们。本文将演示如何把集群外的 MySQL 通过第三方服务注册到 Rainbond 集群中, 并为其定义共享环境变量，从而解决多个服务重复定义数据库连接信息变量的问题。 如果Rainbond安装在阿里云，请注意使用阿里云RDS云数据库时必须与Rainbond集群处于同一个区域。 前期准备 请确保你已经安装了 Rainbond V5.1 或更高的版本。 需要添加的服务, 本文使用的是 Rainbond 集群外的一个 MySQL。 phpMyAdmin, 可以在应用云市中安装, 也可以通过 镜像 的方式创建. 你可以假设这个 MySQL 是非常复杂的, 比如它是一个分布式, 主从复制, 读写分享的 MySQL, 迁移的难度比较在; 那么你可以先不迁移这个 MySQL, 通过第三方服务将这个 MySQL 的实例添加到 Rainbond 集群中, 让它也可以使用 Rainbond 服务通信治理, 服务拓扑关系等功能. 步骤 1: 填写第三方服务信息 登录 Rainbond 控制台, 进入 创建应用 -> 添加第三方服务 . 填写 服务名称 , 应用名称 ,

如果在公有云(比如阿里云, AWS)上的分布式数据库, 无法迁移到 Rainbond 上; 或是其他尚未迁移到 Rainbond 的数据库, 那么你可以使用 第三方服务 将它们注册到 Rainbond 中, 从而使得集群内服务也可以访问它们。本文将演示如何把集群外的 MySQL 通过第三方服务注册到 Rainbond 集群中, 并为其定义共享环境变量，从而解决多个服务重复定义数据库连接信息变量的问题。 如果Rainbond安装在阿里云，请注意使用阿里云RDS云数据库时必须与Rainbond集群处于同一个区域。 前期准备 请确保你已经安装了 Rainbond V5.1 或更高的版本。 需要添加的服务, 本文使用的是 Rainbond 集群外的一个 MySQL。 phpMyAdmin, 可以在应用云市中安装, 也可以通过 镜像 的方式创建. 你可以假设这个 MySQL 是非常复杂的, 比如它是一个分布式, 主从复制, 读写分享的 MySQL, 迁移的难度比较在; 那么你可以先不迁移这个 MySQL, 通过第三方服务将这个 MySQL 的实例添加到 Rainbond 集群中, 让它也可以使用 Rainbond 服务通信治理, 服务拓扑关系等功能. 步骤 1: 填写第三方服务信息 登录 Rainbond 控制台, 进入 创建应用 -> 添加第三方服务 . 填写 服务名称 , 应用名称 ,

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

Richard Li 随着越来越多企业开始落地微服务架构，Service Mesh和相关的解决方案在社区内的讨论热度开始逐渐上涨。Service Mesh所提倡的“全栈可观察性”、透明安全性、系统弹性等特性令人着迷，但它真的是云原生应用的绝配吗？本文将对Service Mesh何时make sense、何时不那么make sense作出一些思考。 做好微服务架构可以让我们更敏捷 当下来看，产品和服务的“time to market”决定了企业的竞争力，能够对市场和客户需求快速反应的公司想不成功都难。微服务架构为软件敏捷性和整个工作流的“速度”提供了强有力的支持，通过授权不同团队分别处理应用的不同部分，决策是“去中心化”的。 “去中心化”的决策带来了两个关键结果。首先，软件团队可以在架构、发布、测试等方面作出“本地化”的最优决策，不需要依赖全局标准。举个例子，每个团队都有自己的发布工具，而不是单一的标准化应用发布。第二，团队可以更快进行决策，传统模式下韵味、架构等等集中功能之上的阻碍减少了。 微服务架构不是“免费”的——带来了新的失败模式 采用微服务对您的组织、流程和体系结构具有深远的影响。微服务架构本身是一个分布式系统，在基于微服务架构的应用中，业务逻辑分布在通过网络相互通信的多个服务之间，而分布式系统有更多的故障模式（failure mode）。 考虑到这些失败模式

默认提供的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

​​本次 3.6.1 版本更新，重点修复了3.6.0版本部分情况下会出现的BUG，同时改进了内部市场、参数验证、历史消息等功能，详细更新记录如下—— ​​ 3.6.1 功能改进 云帮初次使用跳转至注册页面 消息添加查看历史消息功能 调整内部市场功能，所有企业均可用 管理后台添加相关参数验证 3.6.1 Bug修复 修复删除应用后操作动态不显示的问题 修复应用重启按钮重复Bug 修复超级管理员无法查看应用组的Bug 修复插件重复安装问题 修复创建应用对内端口开放后删除环境变量依旧存在Bug 修复Rainbond LOGO加载失败问题 修复未配置sftp信息和hub仓库信息（开源版）不能进行云端备份的Bug 修复应用恢复的Bug 修复了Node服务与kube-apiserver通讯时服务自动发现的性能问题 修复websocket推送页面卡顿的Bug 修复依赖服务页面翻页后不能依赖的问题 修复应用备份时应用文件权限问题 修复了云市安装插件可以再次共享的Bug 修复了删除应用程序无事件记录的Bug 修复了由软链接文件引起的磁盘统计信息中的Bug 修复了由于envoy侦听器名称不一致导致侦听失败的问题 修复拉去代码程序崩溃的问题 关于Rainbond Rainbond 是一款以应用为中心的开源PaaS，由好雨基于Docker、Kubernetes等容器技术自主研发

应用是Rainbond可管理的最小服务单元，用户可以将多个应用组成一个复杂的业务系统，这套业务系统可以对外提供服务，也可以分享给其他组织独立部署。本文将会通过Solo＋Pinpoint( Pinpoint-java性能分析最佳实践 )这个例子，演示“如何制作一个可分享的云市应用”， 分享后的应用可供团队、公司或云市的用户一键安装部署完整的服务体系，实现标准化得一键交付部署。 对于还没有了解Rainbond，或者还没有成功安装Rainbond的同学，建议先到以下的两个链接进行学习： Rainbond介绍 Rainbond一键部署 创建应用 应用的创建有3种方式，分别是从源码创建、从Docker镜像创建和从应用市场安装，详情请参见： 创建一个应用 接下来将会用从源码创建和从应用市场安装—— 同步应用到内部市场 如果内部市场里没有要创建的应用，则需要先从云端下载。 创建应用 首先，通过从应用市场（应用市场是好雨提供的一项公有云服务，提供了常用的开发应用及工具）安装的方式装Pinpoint。这是在云帮平台上部署应用非常简单的一种方式。这种部署方式对于像pinpoint这种多组件的复杂应用来说，最大程度的降低了部署难度与工作量。 进入Rainbond，选择【从云市安装】 在搜索栏中搜索【pinpoint】 选择已有的【应用组】，或者创建一个新的【应用组】 点击【确定】，等待一小段时间后

Ben Sears Kubernetes是时下最流行的管理和编排工具，它提供了一个配置驱动的框架，让我们可以通过定义和操作获得整个网络、磁盘和应用，并以可伸缩且易于管理的方式进行。 如果我们还没有完成应用容器化，那么把应用转移到Kubernetes上会是一件高强度的工作，本文目的则是介绍应用与Kubernetes集成的方法。 Step 1 — 将应用容器化 容器是可以独立运行的基本操作单元，不同于传统虚拟机依赖模拟操作系统，容器利用各种内核特性来提供与主机隔离的环境。 对于有经验的技术人员来说，整个容器化过程不算复杂——使用docker，定义一个包含安装步骤和配置（下载包、依赖等等）的dockerfile，最后构建一个可以让开发人员使用的镜像即可。 Step 2 — 采用一个多实例架构 在我们把应用迁移到Kubernetes之前，需要确认向最终用户交付的方式。 传统web应用的多租户结构，是所有用户共享单个数据库实例和应用实例，这种形式在Kubernetes中工作没什么问题，但我们建议考虑把应用改造成多实例架构，以充分利用Kubernetes和容器化应用的优势特性。 采用多实例架构的好处包括: 稳定性 ——单点故障，不影响其他实例； 可伸缩 ——通过多实例架构，扩展也就是增加计算资源的事；而对于多租户架构，需要创建集群应用体系结构的部署可能会有些麻烦； 安全性 —

GitHub Octoverse数据以及专家们的一致看好印证了一个事实：开了香槟的Kubernetes并不打算放慢成功的脚步！ 人们在很久以前就展现出了对于Kubernetes的热情，然而这份爱在最近几年急剧升温并且愈演愈烈。过去一年中各路专家的表态也证明了，Kubernetes在管理容器化工作负载和服务方面的领先地位。 大家都在学习Kubernetes，甚至思考KaaS的可能（Kubernetes as an infrastructure），Kubernetes想必会成为我们的“通用语（Lingua Franca）” ——Erkan Yanar, freelance consultant Kubernetes已经在容器编排工具对决中胜出了，它为我们提供了一致、开发、独立的管理和运行工作负载的方式。 ——Nicki Watt, CTO at OpenCredo 除了专家的表态，GitHub Octoverse 2017中的数据也进一步表明，2017年对于Kubernetes来说是一个非常充实和成功的一年。 准确地说，在讨论热度和review榜单中，有三个项目是与Kubernetes相关的。 在社群讨论方面，开发者们在Kubernetes项目中发表了超过388,000条讨论，帮助K8s以巨大优势摘得桂冠。亚军属于另一个基于Kubernetes的项目——Openshift

概述 本文档讲述基于Rainbond实现微服务常见的三种发布方式，滚动发布，蓝绿发布及灰度发布的原理、思路、及具体方式。 一. 滚动发布 Rainbond平台 无状态应用 滚动更新与 有状态应用 滚动更新区别： **无状态应用：**滚动更新时，首先会生成新的实例，新的实例启动后在后台运行，平台会使用健康监测机制去监听端口，判断新实例内应用是否运行正常，一旦监听到应用运行正常，就会上线新的应用，销毁旧的应用，以此完成滚动发布的流程。 **有状态应用：**如果是非集群化的应用，生成新的实例前，旧的实例会停止运行，待新的实例更新完毕，旧的实例会被废除，如果是集群化的应用，不必担心服务会中断，可以进行分批次更新。以保障服务的运行。 Rainbond平台滚动发布实践 这里以无状态应用为例 切换构建源 切换代码分支 重新检测 伸缩实例数量 开始构建 此时就会产生两个新的实例，查看新的实例是否被创建，若新实例内应用运行正常，旧的实例将会被废除，新的版本上线完成 此时再查看构建历史记录，可以回滚到构建成功的任意版本 二. 蓝绿发布 蓝绿部署是不停老版本，部署新版本然后进行测试，确认OK，将流量切到新版本，然后老版本同时也升级到新版本。 基于权重使用平台网关功能的蓝绿发布实践 web服务绑定域名 Web服务 域名 权重 Web V1 www.test.com 100 Web V2 www.test