做好企业应用的交付始终是 ToB 软件厂商的关注重点。Rainbond Application Model（RAM）是 Rainbond 提出的一种利用模型，通过将企业应用进行模型化的形象，搭配 Rainbond 平台的利用市场机制，最终实现了一键装置 / 降级。高度自动化的交付体验，晋升了企业应用交付效率，升高交付老本。
通过利用模型实现自动化交付
企业应用指的是反对企业、事业单位或者政府等机构各项业务运作的软件系统。除了反对机构外部的协同工作之外，企业应用也反对企业与其供应商、业务搭档和用户的合作与协调。
每一套企业应用的复杂程度不尽相同，但往往能够细分出相互协作的多个组件。以轻量级的零碎举例，也要至多划分成业务零碎与数据库两个局部。大型的零碎则有可能蕴含数十个组件，若干组件也能够造成模块。这些组件或模块之间还须要定义一些配置，来实现彼此之间的关联依赖。如此简单的场景，确实难为到了 ToB 软件厂商的施行交付人员。
企业应用在传统模式下的施行部署与降级，其难度、老本都与企业应用本身的复杂性成正比。这是因为在传统模式下，施行交付人员更多的通过人工的形式，手动部署服务组件、编辑配置文件。无奈自动化解决的流程都具备低效与易错的通病，企业应用的组件数量和复杂性会将这些通病叠加起来。
云原生时代的企业应用交付都依附各种容器化交付平台落地，通过施展容器化、平台化的劣势，解决了环境一致性、自动化运维、故障自愈等问题。而在简化利用交付与降级这一场景中，所选用平台的能力就非常重要。
Rainbond 是开源的云原生多云利用治理平台，兼具 Kubernetes 集群自动化治理能力，以及企业应用一键装置降级能力。Rainbond Application Model（RAM）是基于 Rainbond 提出的一种利用模型，通过将企业应用进行模型化的形象，搭配 Rainbond 平台的利用市场机制，最终实现了一键装置 / 降级。高度自动化的交付体验，晋升了企业应用交付效率，升高交付老本。
RAM 模型的形象，囊括了企业应用所蕴含的所有服务组件以及组件间的关联关系。这一高级形象无关乎企业应用外部蕴含多少服务组件，也无关乎组件间的关联关系是否简单。利用模版（RAM 模型在利用市场畛域的具体实现）能够公布到 Rainbond 特有的利用市场中，公布出的利用模版能够作为企业应用的安装包对待，无论原有架构如许简单、外部组件多寡，都能够实现一键装置与降级。
为了适应更宽泛的交付畛域，RAM 模型正在致力向 Open Application Model（OAM）演进。OAM 是业界新提出的一种利用模型，其设计是为了可能以简略的形式，在简单环境两头交付更加强壮的企业应用。
应用 Rainbond 一键装置企业应用
Rainbond 的利用模版是利用模型的具体实现，是企业应用一键装置的载体，如何制作利用模版能够参考上面的教程。
制作利用模版教程
当制作好了利用模版，公布到利用市场，就能够通过利用模版一键装置，一键装置过程能够将企业应用从开发环境中完满复刻到交付环境中。组件的个性、镜像、插件、依赖关系都得以放弃原样。
就实际操作而言，点击利用模版右侧的装置，选定团队、集群、利用、版本等必要信息后，确定即可开始装置指标企业应用。
Rainbond 自身能反对各类客户环境，不论是服务器还是虚拟机，是联网还是离线，X86 还是国产 CPU 都能反对，
只有客户环境能装置 Rainbond，就能够通过利用模版一键装置。
制作一个能够一键装置的利用模版
利用模版所承载的企业应用，借助一键装置能力未然能够疾速的交付部署。然而交付实现的企业应用是否能够在装置实现后主动进入可用的状态，和利用模版的制作过程有很大的关系。接下来，咱们来介绍下，一键装置即可用的利用模版，应该具备怎么的“自我涵养”。
环境变量定义连贯信息
可被拜访的地址，是组件之间的互相关联调用的要害。通常状况下，可被拜访的地址会以 IP:Port 或域名的模式体现。然而 IP 的变更，在交付场景中是必然呈现的，这重大影响了一键装置即可用的能力。所以不要将连贯地址写成固定值，而是将其设计成为能够通过环境变量的形式动静拾取并配置的模式。Rainbond 平台提供十分弱小的连贯信息注入性能，专门用于解决组件间的拜访地址。
数据主动初始化
企业应用的长久化数据，应该与程序文件拆散。所有须要长久化的数据，都应该具备独立的目录，这些目录在容器启动前，能够为空。如果有多个目录须要被长久化时，它们最好领有雷同的父级目录。所有的数据库中间件、业务长久化数据须要反对主动初始化。数据的初始化有多种形式可供选择，开发人员能够依据理论状况自行抉择：
- 业务代码治理数据版本（举荐）
由开发人员在企业应用程序外部增加逻辑，实现对数据库表构造的初始化操作。这是一种十分通用的办法，企业应用在启动时自动检测可连贯到的数据库中是否存在指定的表构造，如不存在则进行一次初始化。这种形式更被推崇的起因在于开发人员也能够借助这一形式实现数据库表构造的降级操作。参考 源码构建实现数据库表构造自在降级回滚 能够理解一种基于 Liquibase 联合 Rainbond 源码构建能力的数据库版本解决方案。
- 官网镜像提供的能力
对于市面上常见的各类数据库中间件而言，其官网镜像均具备数据主动初始化的能力。包含但不限于 Mysql、Mongo、Postgresql 等常见数据库。
- 针对非结构化数据制作初始化插件
对于更一般化的场景，平台反对以插件机制来针对服务组件的指定长久化目录进行数据初始化，这种形式借助了内部的对象存储来放弃须要被初始化的数据。该插件的应用形式，参考 通用数据初始化插件 理解这一最佳实际。
正当的解耦计划
为了实现一键装置企业应用的指标，须要划分出能够被解耦的不同模块，并且将模块以利用模版的形式公布进去。每一个模块对应的利用模版，都应该是能够被独立装置并运行的。交付施行人员依据最终客户的业务需要，按需一键部署出多个利用模块，并在图形化界面下进行拼装，即实现了企业应用的整体交付。对于企业应用开发人员来说，正当的解耦计划，能够达成模块化复用的成果，升高开发人员的反复工作量。
深刻理解到如何正当划分模块：应用 Rainbond 打包业务模块，实现业务积木式拼装
应用 Rainbond 一键降级企业应用
由 RAM 实现而来的利用模版是具备版本控制机制的，这意味着在同个利用模版的不同版本之间能够疾速的降级与回滚。
对于开发人员而言，在源利用一侧作出须要的变更，无论是代码的改变后构建，还是新退出其余组件，都会在下一次利用模版公布过程中叠加到新版本的利用模版中去。开发人员务必留神公布时定义的版本号，Rainbond 通过它来确定是否进行降级。
对于交付人员而言，只须要将不同版本的利用模版导入到交付环境中，Rainbond 会自动识别同个利用模版的不同版本，并执行一键降级操作。
而在曾经交付实现，正在运行的利用页面中，小 A 找到了降级的入口。Rainbond 辨认到了最新的版本，而降级操作也是一键触发，十分好用。
一键装置和一键降级的实现原理
基于 RAM 模型实现的利用模版为何能做到一键装置简单利用？首先须要理解利用模版外部结构。
利用模版由两个局部组成：利用元数据、容器镜像压缩包。
利用元数据
利用元数据负责形容利用以及其外部组件的特色。换句话说，利用元数据是对 RAM 模型的形容。这些元数据会保留在 Rainbond 数据库中，Rainbond 通过拾取这些元数据，理解到须要装置的是一个什么样子的利用。这些元数据次要包含的内容如下：
| 属性 | 级别 |
|---|---|
| 利用名称 | 利用 |
| 利用版本 | 利用 |
| 组件间依赖关系 | 利用 |
| 网关策略 | 组件 |
| 组件名称 | 组件 |
| 组件镜像 | 组件 |
| 组件环境变量 | 组件 |
| 组件插件配置 | 组件 |
| 组件存储 | 组件 |
| 组件端口配置 | 组件 |
| 组件部署形式 | 组件 |
| 组件健康检查策略 | 组件 |
容器镜像
业务容器镜像的起源，利用模版一经导入后，容器镜像会被装载到 Rainbond 所援用的容器镜像仓库中。启动每一个组件时，Rainbond 会依据元数据中记录的镜像地址拉取对应的镜像。
通过利用元数据的解析插入，以及容器镜像的导入，交付人员就能够在客户环境中一键装置企业应用了。
企业应用一键装置实现后，Rainbond 能够保障让其运行起来。如果心愿能更进一步，确保企业应用外部的业务逻辑也可能失常工作，则须要在利用模版的制作过程中留神更多的自动化改良。
降级
一键降级和一键装置的原理相似，一键降级的过程实际上是别离对利用元数据和容器镜像进行了版本的变更。
容器镜像的降级很好解决，只须要援用不同的 tag 即可。而对于可降级利用内的所有组件而言，降级的过程中会笼罩以下利用元数据变更。
| 属性 | 级别 | 规定 |
|---|---|---|
| 组件 | 利用 | 新增, 更新 |
| 插件 | 利用 | 新增 |
| 配置组 | 利用 | 新增 |
| 镜像 | 组件 | 更新 |
| 启动命令 | 组件 | 更新 |
| 环境变量 | 组件 | 新增 |
| 组件连贯信息 | 组件 | 新增 |
| 端口 | 组件 | 新增，更新 |
| 存储 | 组件 | 新增 |
| 配置文件 | 组件 | 新增，更新 |
| 衰弱检测探针 | 组件 | 新增，更新，删除 |
| 监控图表 | 组件 | 新增, 更新 |
| 监控点 | 组件 | 新增, 更新 |
| 插件 | 组件 | 新增 |
| 组件依赖关系 | 组件 | 新增, 删除 |
| 存储依赖关系 | 组件 | 新增, 删除 |
值得注意的是，基于利用模版的降级，仅蕴含了应用程序的降级。理论环境中，常常波及到长久化数据的变更。最常见的一种状况，是企业应用所应用的数据库的表构造，须要追随应用程序的降级而变动。前文中介绍的 源码构建实现数据库表构造自在降级回滚 计划，就能够解决这种表构造的版本控制。
企业应用的治理与运维
企业应用的装置与降级都是一次性的，而治理与运维则是短暂继续的。
当企业应用被交付到客户环境之后，运维人员须要掌控治理运行环境的能力。古代 IT 基础设施是非常复杂的，运维人员想要在物理机、虚拟机等不同环境之间兼顾有度已属不易，想要在私有云、公有云乃至混合云之间熟能生巧更是对其技术能力提出了挑战。如果能有一款易用的平台抹平不同基础设施之间的差别，那就将极大的简化运维人员的管理工作。
理解 云原生利用治理，像治理手机 APP 一样治理企业应用。
总结
本文重点讲述了企业应用自动化装置和降级的实现过程，这个过程非常适合企业产品没有性能定制化的标准化交付，对接开发环境能够实现客户的继续交付，进步 10 倍以上交付效率。然而，标准化交付在企业产品交付过程中只能占多数，对于须要性能定制化的个性化交付场景该如何提供交付效率呢？咱们将在下一篇文章将具体介绍。