乐趣区

关于云原生-cloud-native:云原生赋能传统行业软件离线交付

一. 离线交付的痛点

在传统行业,如政府、能源、军工、公安、工业、交通等行业,为了避免数据泄露和运行平安思考,个别状况下网络会采取内外网隔离的策略,以防备不必要的危险,毕竟在平安防护方面,网络物理隔离是网络安全进攻最无效的伎俩,而网络隔离在软件交付过程中,对于内部软件开发厂商来说将会带来一系列的交付难题,也减少大量老本投入。例如:

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 间接进行离线代码开发工作,包含源码编译、配置组件运行环境等,在交付环境中实现所有定制工作。

  • 离线环境客户继续交付

    对于我的项目施行团队而言,在施行过程中须要一直将 新性能、缺点修复 等疾速落实到交付环境或用户手中,传统的继续交付过程中,离线环境下须要交付人员驻场,手动执行更新上线操作,该过程不仅减少了交付工夫,且长期的手动执行操作会减少部署的危险;而 Rainbond 的继续交付能力,可能实现利用后续的 增量导入、导出和版本升级,可能带来以下劣势:

    • 通过自动化形式实现,无效缩短代码提交到部署上线的工夫。
    • 软件在整个生命周期内都处于可部署降级的状态。
    • 简化降级步骤,使软件版本更加清晰。
    • 让交付过程成为可预期的、可视化的过程。
  • 离线环境下自动化运维

    服务高可用,自容错和自复原机制,缩小人工运维,进步业务零碎稳定性。

六. 对于 Rainbond

Rainbond 是一个开源的云原生利用治理平台,应用简略,不须要懂容器和 Kubernetes,反对治理多个 Kubernetes 集群,提供企业级利用的全生命周期治理,性能包含利用开发环境、利用市场、微服务架构、利用继续交付、利用运维、利用级多云治理等。

已有上百家企业应用 Rainbond 治理要害业务场景,涵盖制作、能源、高校、公安、政府、交通、军工等十几个行业。客户有 京东方、百胜中国、中航信、中公高科等大型企业。

退出移动版