info
之前 柯基数据通过 Rainbond 完成云原生改造，实现离线持续交付客户 这篇文章，开源群里一直有用户想要更详细的文档，渴望自己上手操作。「使用 Rainbond 实现离线环境软件交付」来了，安排 👇。
离线交付的痛点
在传统行业，如政府、能源、军工、公安、工业、交通等行业，为了防止数据泄露和运行安全考虑，一般情况下网络会采取内外网隔离的策略，以防范不必要的风险，毕竟在安全防护方面，网络物理隔离是网络安全防御最有效的手段，而网络隔离在软件交付过程中，对于外部软件开发厂商来说将会带来一系列的交付难题，也增加大量成本投入。例如：
1. 现场安装部署和验收测试，效率低下
交付过程中需要将应用程序及依赖的所有资源安装到离线客户环境，而客户环境有可能是物理服务器、虚拟机、私有云及 K8s 容器等各种环境，加上离线环境网络的限制，就会导致离线环境安装和部署效率低下。由于安装配置过程繁复，容易出错，在最终交付环境中需要重新进行验证测试工作，也需要浪费很多时间。如果部署的是微服务架构的应用系统复杂性更高，工作量还会加倍。
2. 离线环境定制开发和产品升级，成本高
定制开发需要开发人员投入，成本本来就高，在离线环境需要根据客户反馈持续迭代，迭代过程产品不断升级，每升级一次就要走一次安装部署和验证测试过程，成本很高。如果有些工作必须驻场开发，成本更高。
3. 网络不通，无法远程运维
交付完成后，应用需要持续运维，保障运行稳定性和功能持续可用，在网络无法联通的情况下，出任何问题都需要安排人员现场支持，甚至需要安排人员长期驻场。
技术选型
上述问题的根本原因是因为，应用系统的多环境适配、应用安装部署、应用升级、应用运维等操作自动化程度不高，需要大量人员手工操作，所以效率很低，解决问题的重点在解决应用管理的自动化。当前，云原生技术已经越来越成熟，而云原生技术主要解决的就是应用管理的自动化问题，具体有两种开源实现方案 ：
1. Rancher+Helm
Rancher 是一款 K8s 管理工具，他提供 K8s 的管理 UI，包管理使用 Helm。对应离线交付的问题，Rancher 可以安装在多种运行环境（物理服务器、虚拟机、私有云），并且提供部分应用自动化运维功能，它可以解决 多环境适配和 应用运维问题，而 应用安装部署和 应用升级问题可以通过 Helm 包解决。
2. Rainbond+应用模版
Rainbond 是“以应用为中心”的应用管理平台，应用模版是 Rainbond 对应用打包的方案，Rainbond 提供应用的全生命周期管理（应用开发、应用编排、应用交付和应用运维）。Rainbond 可以部署到各种运行环境上（物理服务器、虚拟机、私有云），还可以部署到已有 K8s 集群和 Ranchar 上，解决客户多环境适配问题；Rainbond 提供应用运维面板解决应用运维问题，使用比较简单，不需要懂容器概念；Rainbond 的应用模版是一个亮点，只要在 Rainbond 上运行起来的应用就可以一键发布成应用模版，简化了应用模版的制作，而且应用模版可以导出离线包，特别适合离线环境的 应用安装部署和 应用升级。
下面分别比较一下两个方案
Rainbond 相比 Rancher 最大的优点就是易用性，不需要学习 K8s 和容器相关技术和概念，另外，Rainbond 提供的一体化开发环境和模块编排功能，能大幅度提高定制开发的效率。Rancher 最大的优点是完全兼容 K8s 体系，如果了解 K8s 能很快上手。
Helm 和应用模版比较
| 对比项 | Helm | 应用模板 |
|---|---|---|
| 安装和升级 | 少量配置 | 全自动 |
| 制作流程 | 人工编写 | 全自动 |
| 导出和导入离线包 | 不支持 | 支持 |
| 配置调整 | 支持预定义的配置调整 | 支持 |
| 模块定制 | 不支持 | 支持 |
| 兼容其他 K8s 版本 | 兼容 | 需要预先安装 Rainbond |
Rainbond 的应用模版 跟 OAM 的设计思路完全一致，“以应用为中心”的设计理念，屏蔽掉容器基础设施的复杂性和差异性，为平台的使用者带来低心智负担的、标准化的、一致的应用管理与交付体验。
综合对比，在离线交付场景 Rainbond+应用模版的方案优势明显，下面我们结合实际例子，来讲解 Rainbond+应用模版交付离线客户的整个过程。
使用 Rainbond 应用模版进行离线环境的应用交付
基于 Rainbond 进行离线环境的应用交付，只需将开发环境已开发好的业务发布至应用市场，基于应用市场导出应用模板的离线包，在交付环境中进行导入操作，导入后基于应用市场一键安装即可自动运行。
预先准备环境
拥有两套 Rainbond 集群，模拟开发环境及交付环境(开发环境为在线环境，交付环境为离线环境)。
开发环境安装，参考 在线安装文档；
交付环境安装，参考 离线安装文档；
拥有 U 盘、光盘等离线环境下应用模板离线包传输介质。
1.业务部署
整个流程始于开发环境，我们首先需要将业务搬迁至 Rainbond 之上。在开发环境基于部署自己的业务，可以支持源代码或是镜像。当前以 Spring Cloud 微服务框架 Pig 为例，部署参考SpringCloud Pig 在 Rainbond 部署及应用制作。
2.应用发布
将开发测试环境已开发完成的应用发布至内部组件库：点击应用左侧导航栏 发布 按钮，选择 发布到组件库 ，该过程需要 新建应用模板，应用模板定义了以下信息:
| 选项名 | 说明 |
|---|---|
| 名称 | 定义应用名称（必填） |
| 发布范围 | 应用模板的可见范围，当前团队为当前团队可见，企业所有团队可见（必选） |
| 分类标签 | 应用标签，可按照架构、行业、部署方式进行分类 |
| 简介 | 应用描述，帮助使用者了解此应用 |
| Logo | 应用的 Logo 图片 |
创建应用模板后定义应用发布版本：
| 选项名 | 说明 |
|---|---|
| 版本号 | 当同应用多次发布时，如果版本号相同，则会覆盖已发布的版本，如果不同，将发布为新版本，应用升级或回滚时，平台根据版本判断（必填） |
| 版本别名 | 应用别名，例如 高级版，初级版 |
| 版本说明 | 当前发布版本的说明，可区分不同版本的功能差异等信息 |
发布组件模型配置：
| 选项名 | 说明 |
|---|---|
| 连接信息 | 当连接信息中出现密码类的信息，可选择每次部署时自动生成随机值 |
| 环境变量 | 编辑该组件默认的环境变量 |
| 伸缩规则 | 定义该组件可伸缩的最大最小节点数，及节点伸缩步长，最小安装内存限制。 |
发布插件模型信息：
要发布的应用中其组件携带有插件时，会进行展示并在发布过程中跟随组件发布。
所有信息配置完毕后，点击发布按钮进行发布，业务开发过程中定义的组件间依赖关系、环境配置、持久化存储、插件、运行环境及上述定义的所有信息都将会被打包发布。
3.应用导出
将应用模板进行本地化导出，在首页应用市场中找到已发布的应用，点击最后方扩展按钮，选择导出应用模板，选择应用版本后点击应用模板规范下的导出按钮，导出过程完全自动化，待导出完成后点击下载按钮即可将应用模板下载至本地，保存至 U 盘等移动存储设备中，带到离线交付环境中去。
接下来进入离线交付流程，交付人员携带着装有离线包的 U 盘等移动存储设备，开始导入应用模版。
4.应用导入
使用已导出的应用模板在交付环境中导入，点击应用市场界面的离线导入按钮，选择本地的应用模板上传，上传完毕后选择导入范围： 企业或团队，企业为当前交付环境所有人可见，团队为指定团队下的人员可见；点击确认导入即进入自动化导入步骤。
5.一键部署
应用导入后点击安装按钮在当前交付环境即可一键部署该业务系统，该环境业务运行环境与开发环境完全一致，到此完成离线环境下的软件交付。
6.增量升级
软件在更新迭代过程中需要进行某些模块的升级，进行此类升级时即可使用增量升级来节省发布及导入导出时间。
要达成增量升级的效果，需要重新进行应用发布操作，选择之前已创建的应用模板，修改版本号，如之前版本设置为 2.9，则此次发布设置为 3.0。
在应用发布步骤选择需要进行升级的组件进行发布，而不需要选择所有组件。发布完成后，导出新版本的应用模版离线包，在交付环境中再次导入。
交付环境导入后，平台会对应用模板不同版本进行对比，并通过应用拓扑图中的待升级选项提示用户进行升级。展示版本间属性变更情况，用户选择需要升级的版本进行升级即可，平台将自动执行升级操作，变更组件构建版本。
升级过程中不会变动环境配置类信息，这类信息需要人为改动才会生效：
环境变量的值
配置文件的内容
持久化存储
7.一键回滚
在升级版本上线后出现异常情况需要回滚时，平台提供了一键回滚功能，在升级记录界面选择对应记录点击回滚按钮即可对升级操作进行回滚。
在回滚的过程中，新增组件并不会被删除，如需变更，需要人为操作。
8.应用运维功能
软件产品交付完成以后需要进行长期的运维，在运维层面，交付人员需要考虑服务的可用性、可伸缩性、资源监控，Rainbond 提供了诸多运维功能，例如：
- 服务性能分析
通过 Rainbond 插件机制扩展性能分析功能，服务实时性能分析插件运行在目标分析服务同一个网络空间内，监控网卡的流量来统计分析服务的工作性能，对服务本身的工作流程和性能无影响，收集服务的平均响应时间，吞吐率等主要指标。
资源监控报警
基于 Prometheus 对平台及业务进行监控，基于 ETCD 动态发现 需要监控的 targets，自动配置与管理 Prometheus 服务。
实例伸缩
对服务组件进行垂直伸缩或水平伸缩，在流量高峰期灵活进行扩容。
网关管理
应用网关支持灰度发布和 A/B 测试功能。
场景拓展
上面的例子主要针对常见的离线软件交付场景，但在真实的离线交付场景中，还可能存在以下场景，如：
离线模块定制，每个客户交付的模块不一定，根据需要在客户现场开启或关闭模块，或者模块编排。
离线定制开发，在离线场景下进行完整的软件开发过程，包括源码管理、源码编译、开发测试环境管理、团队协作、版本发布流程等。
总结
本文我们分析了离线交付场景的问题，对比了可能的技术方案，并使用一个例子完整讲解离线交付全过程，整个过程自动化程度很高。使用 Rainbond 进行离线交付肯定可以提高效率，但到底在哪些方面提高我们的效率，我再总结一下：
离线环境应用系统一键导出和导入 交付过程中只需要携带基于 Rainbond 导出的应用模板离线包在交付环境进行导入，即可一键安装整套业务系统。
开发环境和离线环境完全一致 Rainbond 屏蔽了底层环境的差异，基于应用模板进行交付，模板对应用的运行环境、依赖关系进行打包，开发环境和离线环境完全一致，不需要进行重复性测试。
一体化客户定制环境 软件交付过程中，不同的客户会有不同的定制需求，也就意味着需要为不同客户开发不同的模块，这些定制的模块在不同项目中都不尽相同，通过 Rainbond 提供的应用编排，就可以针对不同客户编排和开启不同功能模块；如果需要定制开发，就可基于交付环境已部署的 Rainbond 直接进行离线代码开发工作，包括源码编译、配置组件运行环境等，在交付环境中完成所有定制工作。
离线环境客户持续交付 对于项目实施团队而言，在实施过程中需要不断将 新功能、缺陷修复 等快速落实到交付环境或用户手中，传统的持续交付过程中，离线环境下需要交付人员驻场，手动执行更新上线操作，该过程不仅增加了交付时间，且长期的手动执行操作会增加部署的风险；而 Rainbond 的持续交付能力，能够实现应用后续的增量导入、导出和版本升级，能够带来以下优势:
通过自动化方式实现，有效缩短代码提交到部署上线的时间。
软件在整个生命周期内都处于可部署升级的状态。
简化升级步骤，使软件版本更加清晰。
让交付过程成为可预期的、可视化的过程。
离线环境下自动化运维
服务高可用，自容错和自恢复机制，减少人工运维，提高业务系统稳定性。