关于云原生:私有化场景下大规模云原生应用的交付实践

本文依据作者在 CSDN 云原生 Meetup 深圳站的演讲内容整顿，分享云原生趋势下网易数帆在私有化场景下大规模利用的交付实际，包含在实际过程中遇到的问题，如何实现标准化、高效率且高质量的交付计划，以及获得成果。

背景介绍

软件私有化交付部署是建设在企业自有基础设施的根底之上的，是为一个企业客户独自应用而构建的硬件 / 软件运行环境；因此可能提供对数据安全、合规审计和服务质量的无效管制。

软件的私有化是由市场供需关系决定的。也分为甲方和乙方，甲乙双方各取所需从而使面向企业的私有化市场失常运行，例如以下单方的一些诉求：

甲方（资金提供方）诉求

• 政策性的行业合规和平安化诉求。
• 企业网络齐全隔离限度，不能和互联网建设通信，无奈应用私有云产品。例如金融企业内网。
• 企业经营的数据具备敏感性，不适宜间接运行在公共互联网。例如政府企业沟通交流的工具应用企业微信、企业钉钉等数据要求相对窃密。
• 头部互联网企业的云技术能力强，投入力度大，产品整体绝对较好，冀望应用当先的云技术能力。例如冀望在外部应用阿里云、腾讯云、华为云以及数帆数帆轻舟或大数据等产品。
• 传统企业心愿进行数字化转型，然而自研体系能力欠缺，从头开发成本太高且周期较长，心愿洽购相干成熟的产品助力疾速数字化转型。
• 企业有本人的机房和服务器，但资源扩散且利用率不高，心愿一些公有产品能充分利用这类资源。
• 业务管理与协同沟通割裂，着力搭建一体化老本合适、平安高效组织协同治理平台。
• 不足统一标准撑持平台，根底供应能力产品容易反复建设，用户体验参差不齐。
• 难以疾速响应业务翻新。多年信息化的重叠，垂直化的建设导致集成能力和凋谢能力不适宜业务翻新环境。
• 其余因为非凡场景须要却缺失的能力，心愿通过单干的形式由其余供应商来帮助建设。

乙方（产品提供方）诉求

• 私有云厂商的私有云业务增长速度不迭预期，心愿通过反对私有化交付的形式拓展新的业务市场。
• 产品设计之初就是面向其余企业的，而不是面向公网 C 端用户的。像一些 ERP 零碎、网易数帆轻舟平台等等。

通过以上甲乙方的诉求能够晓得，如果乙方刚好能够满足甲方的一个或多个需要，那么就有了单干和软件私有化交付的场景呈现。

是否有遇到过如下场景？

测试环境与生产环境隔离。一些企业因为外部的流程或平安标准的要求，测试环境与生产环境是隔离的状态。例如运行节点间隔离或网络策略的隔离，甚至是物理上的隔离须要更换设施能力拜访生产环境，这时在测试环境测试验证的服务如何上线到生产环境？

生产环境禁止拜访 Git 执行流水线。代码是企业的外围资产之一，保障源代码的平安是企业重点保障的资产；生产环境个别有本人的机房，或者一些第三方的私有云环境，企业个别不会容许将外围源代码裸露到公网上的，这些状况下生产环境是禁止拜访内网的 Git 代码托管平台的。而且，在生产环境从新执行 CI 流水线构建的镜像，并不是 QA 团队在测试环境测试回归验证过的镜像，即便他们的源码雷同，但实质上是两个镜像。

在 Kubernetes 中部署利用时波及较多类型资源管理问题。在 Kubernetes 集群中部署服务并不是简略的将 Image 镜像运行起来就能够了，实际上还会波及一些其余相干的 Kubernetes 的资源，例如常见的资源有 Deployment、Service、Ingress、Secret、ConfigMap、PV/PVC、ServiceAccount、RBAC 等等以及其余扩大服务的相干资源，如 Prometheus-operator 的 ServiceMonitor。这么多类型的文件该如何保护治理能力高效且不出错呢？

利用上线须要合乎公司标准。为了保障上线的顺利，合乎上线的品质、平安等要求，企业都会对业务上线制订一些流程或者标准。同时，在多人合作的团队中，如果没有肯定的标准参考领导，会因为信息不统一导致利用管理混乱。比方最常见的就是镜像的命名标准，同一个服务可能会呈现 myapp:v20211129、myapp:v1.3.11、myapp:1.3.11、myapp:v1.3.11-20211129、my_app:v1.3.11、my-app:v1.3.11 甚至是 yourapp:v1.3.11。这些镜像 tag 实际上是指同一个 Git Release v1.13.11 的代码版本，但因为没有标准束缚导致治理难，而且容易出错。

多部门或子公司开发的产品复用。在企业外部一个部门开发了好的一款优良的利用，其余部门也心愿可能应用这个利用，特地是大型企业有多个子公司时尤为显著。这类利用例如：日报周报零碎、设施日志零碎、发票管理系统、ERP 零碎等等。这时如何将这些利用分享给其余部门会成为一个挑战，如果交付过程太过简单就会导致推广受限，进而在团体层面产生资源的节约。

软件私有化交付到客户环境。如前文提到的 ERP 零碎、网易数帆轻舟平台等，这些 toB 私有化产品在交付时会有很多的艰难，如何高效高质量的将交付软件到客户环境成为这类企业外围关注的重点之一。

本文次要探讨的就是网易数帆轻舟团队在私有化场景下大规模利用的交付实际，在实际过程中同样会波及到上述的这些问题，通过本文提供的实际给上述的场景提供一些参考。

软件私有化交付的痛难点

软件私有化交付时个别都不会太顺利，在不同的阶段，不同的角色或维度会有各种各样问题，这些问题有些可能会决定整个我的项目是否延期，有些问题甚至影响我的项目是否胜利。

在我的项目晚期，如果能评估到一些痛难点，提前准备相干的应答策略，将会给产品的私有化交付提供很大的帮忙。

站在交付方，以私有化交付全局的维度来剖析我的项目交付前后的痛难点，能够分三大类，别离是用户侧、交付侧和工程售后侧。

用户侧痛难点

产品性能需要多样。规范的产品不满足企业的需要，须要软件提供商依照企业的需要进行产品的批改或适配，然而跨企业的协同效率绝对较低，经常出现返工批改以及环境频繁降级的问题。
资源筹备周期长。工夫长, 或者资源变更批改时流程长。因为企业外部资源申请须要通过多层的审核和审批，如果不合乎企业标准要求调整申请又须要从新审批流程，这个周期可能是周，甚至是月。
企业业务上线标准。用户有本人的上线运维标准，交付软件须要满足他们的运维或平安的标准。例如有等保三级，性能指标、平安扫描、上线工夫窗口短等等标准要求，但这些在做产品时可能没有全副思考到。
用户侧的变更。因为设施搬迁、网络变更、设施降级、关机等没有，导致无奈开展交付。
没有依照部署布局要求筹备资源。探讨好的资源需要申请，因为客户外部的某些起因无奈依照后期布局的计划交付，或用户筹备的资源环境不稳固。

交付侧痛难点

交付人员要求高。交付过程波及操作系统、Docker/Kuberentes、交付产品自身以及用户流程和基础设施等方面问题，须要交付人员有较强的技术根底和用户沟通的能力。
测试验证简单。在部署实现后，为了保障交付品质的，个别都会要求有测试验证的流程，对于自动化测试无奈笼罩还须要人工手动回归来保障交付的环境质量。交付产品越简单，测试验证也就会越简单。
跨企业协同艰难。在我的项目开始部署前，都会设计部署实施方案并和用户沟通，但因为单方没有对齐导致的计划和资源不统一，现场施行时碰壁。即便能够调整计划，但依旧会给我的项目带来延期的危险。
用户的网络隔离与限度。企业思考到平安等起因，网络无法访问互联网，在交付施行过程中遇到问题时查找材料，寻求近程帮助以及下载更新文件都是受限的。
部署包较大，上传文件工夫长。应用容器化公有交付时，个别都是将程序构建成离线的 Image 镜像。Image 镜像即便通过镜像层的复用升高了整体的大小，但因为交付零碎自身的简单导致依旧会有大量无奈复用的层，后果就是离线镜像包或部署包比拟大。特地是传统企业用户的网络品质和带宽并没有互联网企业那样好，这就导致了我的项目交付用到的部署包即应用移动硬盘复制到客户现场，上传到理论的部署运行环境依旧会破费较多的工夫。

工程售后侧痛难点

基础设施多样。在私有化场景下，不同的企业客户有本人独有的基础设施。比方不同的硬件，有的客户洽购了华为的服务器硬件，有的客户洽购了 HP 的服务器硬件，也有的客户本人定制服务器。操作系统也是各有不同，例如在企业外部常见的操作系统有 CentOS/Debian/Ubuntu/Redhat/ 统信 UOS/ 麒麟 OS 等等。CPU 架构也可能不同，有 x86 的服务器，也有 ARM 的服务器。
私有化的产品简单。如果私有化的产品自身比较复杂，在私有化版本公布时须要真正的可能了解产品并对私有化交付体系有较粗浅意识的负责人来把整体控私。否则因为私有化技术选型、版本的治理、自动化的封装、场景的认知有余、筹备的资料缺失或者其余考虑不周全导致产品的交付和治理简单且凌乱。
产品自身品质不高。因为新性能的退出频繁的需要变动，导致产品性能不稳固 Bug 数量比拟多，QA 的测试把控不到位的话，会导致现场交付时剖析定位和解决 Bug。现场定位解决问题不仅不不便，同样会耗费较多的工夫。
文档资料缺失。在做私有化时，倡议提供匹配的文档工程师。企业在进行内部洽购时，有些资料是强制要求有的，否则不会验收该我的项目。而且，如果每次用户有文档需要时都是首次筹备，品质是否高暂且不说，给用户的感觉也不好，显得不够业余。
我的项目数量逐年增长 。我的项目数量的增长自身阐明产品卖的好，但也会带来运维和售后的老本增长。在适合工夫应该做好人力的评估，及时裁减团队和人员，否则会给以后的员工带来较为沉重的工作工作进而导致人员流动较大。
客户环境离线，前期保护难度大。因为网络离线无奈及时收取异样告警信息，须要用户收取到告警反馈给售后人员，可能因为技术的差别导致问题定位和修复过程不顺利。因为离线，一些预期内的变更或降级须要出差客户现场，反对的老本比拟高。
用户基础设施影响。如果交付的是软件产品，因为基础设施如机器、网络、电源等都是由用户其余部门保护，基础设施异样时，会影响下层的软件的稳固运行。

因为上述的一些起因导致软件在私有化交付时交付周期长，交付品质差、交付老本高。如果老本太高，这个我的项目可能就因为投入太多而亏损。

为了保障软件私有化的失常交付，在进行架构设计和技术选型时应该联合以后支流技术体系，抉择适合的解决方案。

基于 Helm 的利用封装、交付、降级与环境保护

软件应用交付现状

软件的交付部署有多种形式，依照交付形式能够分为传统根底交付、自动化交付和云原生交付三种。

传统根底交付。传统的利用交付是利用交付的根底形式，比方罕用的 rpm 软件包或者间接二进制的形式装置运行，比拟适宜场景绝对固定的基础设施。如果有较多的软件包依赖，个别还会搭建一些 YUM 或 DEB 的软件源来疾速装置依赖。这类服务的运行个别能够通过 systemd 或者 supervisor 的形式来治理。自动化交付和云原生交付也是在这种形式之上构建的。

自动化交付。如果软件数量较多，装置部署过程有着简单的逻辑时，应用手动 rpm/yum 装置会比拟繁琐且易出错。个别都会应用自动化的形式封装，如 shell 和 Ansible 就是支流的自动化工具。

云原生交付。因为云原生的概念衰亡，加上晚期的 DevOps 理念的长期陶冶，利用又有了新的交付模式。在云原生的场景下，应用基于流水线的 CI/CD（继续集成与继续交付）模式成为了新的支流，提供了疾速高效的利用迭代节奏。云原生交付运行的环境基本上都是基于 Kubernetes 平台，所以也有一些工具能够间接治理和部署利用，比方 KubeVela。然而，目前真正在企业内生产环境应用的，并且曾经属于 CNCF 毕业的我的项目只有 Helm。

依照交付部署时是否可能联通各个系统，可分为在线交付和离线交付。

在线交付。在线交付是指在交付部署过程中全副或者局部资料运行在其余服务器上，在装置部署时能够通过网络的形式获取到这些数据。比方常见的基于 Nginx 的 YUM 软件源，或者企业外部的 Harbor 镜像仓库，外部的 Gitlab 代码参考，或者公网的 Maven 仓库等。在线交付的益处是不须要提前准备筹备这些资源，须要什么资源就到对应的服务器上获取即可。

离线交付。离线交付和在线交付刚好相同，部署时依赖的资源无奈内部获取，须要独自筹备依赖的资源。没有 YUM 软件源就本地长期搭建一套或者把离线的软件包以及依赖的软件包都下载下来筹备好一起装置。在离线场景下有很多服务须要部署时搭建，这也给我的项目的交付减少了很多的艰难。

简单的客户基础设施带来了简单的交付场景。如果基于传统和自动化的形式交付，会有一个长长的适配反对兼容清单，例如硬件设施、CPU 架构、操作系统等等，这无疑是给企业带来了大量的人力老本耗费。

然而，如果抉择了云原生的形式交付利用，就有机会将这种差别的场景人力耗费降到最低。

轻舟利用交付工具选型

基于容器化的交付。面对用户环境的多样，基于 Docker 容器化的形式封装利用可能屏蔽底层基础设施的差别，使交付的制品依据有普适性。

基于 Kubernetes 的运行平台。容器的运行调度、故障的发现与主动解决、弹性的扩缩容、简略的网络环境等环境比拟单薄，而 Kubernetes 刚好解决这些痛点问题。应用 Kubernetes 作为容器的运行环境，能大大降低交付和运维的复杂度。

基于 Helm 的利用构建与交付部署。Helm 可能治理利用的多个不同的 Kubernetes 资源，依照肯定的策略来使其在集群中失效。同时，和 rpm/deb 相似也能标准化定义利用，有 Helm 定义的标准化利用就是 Chart。

Helm 的版本抉择

首选 Helm3。在曾经有 Kubernetes 集群的状况下，只须要一个 kubeconfig 就能够实现环境的交付部署。

Helm 的版本抉择有 Helm2 和 Helm3 两种。如果您是老手，当看到这篇文章时，强烈建议您间接抉择 Helm3；如果您曾经应用了 Helm2，也同样建议您尽快降级到 Helm3。Helm3 不仅在架构上简略了很多，在性能上，应用和易用上都有了很大的优化。

Helm3 于 2019 年 11 月 13 日公布。Helm3 公开公布 12 个月后，对 Helm 2 的反对正式完结。

云原生利用的定义与标准化

当应用 Helm Chart 来定义云原生利用时，应该也很心愿相似 RPM/DEB 软件包一样能够定义肯定的标准规范。侥幸的是 Helm 也是反对的，Helm 定义标准分两种，强制规范和举荐规范。

强制规范是指在 Helm Chart 的目录构造上，有一些文件名称搁置的地位，内置的函数或变量，模板的渲染形式和资源的优先级等是必须准守的，否则 Helm 无奈失常的工作。比方 values.yaml 是默认的参数配置文件，templates 目录是 Kubernetes 的资源模板目录等。

举荐规范是指在强制规范根底之上，企业依据业务需要和治理标准来定义的 Chart 规范。例如利用的命名标准、Kubernetes 资源文件命名标准、环境变了的命名标准、装置降级的逻辑标准等。

对于强制标准是必须恪守的，否则 Chart 无奈失常工作。而对于举荐规范是通过人为束缚或定义脚手架的形式来治理。新利用应用脚手架的形式创立手，就曾经是符合标准的利用。

1. 定义变量：export XDG_DATA_HOME=/root/.helm
2. 脚手架门路：/root/.helm/helm/starters/chartstarter
3. 新建利用：helm create --starter chartstarter myapp

即便在后续的迭代的过程中，利用的一些配置和规范偏移了，也同样能够应用自动化的 Check 的形式来扫描是否违反了规范。

制品的治理

在云原生场景下的软件包制品常见的有 code 源码、编译或打包的可执行文件、构建的零碎软件包（可选，如 RPM 包）、构建的镜像、以及 Helm Chart 包。

最小原子化。在制作 Chart 包时，依据业务的场景个性决定一个 Chart 中蕴含的业务服务数量。轻舟的 Helm Chart 是基于利用代码仓库作为最小单元，即一个 Chart 中只有一个功能性程序镜像。如果业务零碎不是很大，只有几个利用的话，也能够思考应用子 Chart 的形式来治理多个服务，如 WordPress Helm Chart。

版本可追溯。最小原子化后，在联合肯定的外部标准就能够做到 GitRelease，镜像 Tag，ChartAppVersion 统一，部署或运行时可依据环境 Chart 版本疾速溯源代码版本。

例如：

1.Git Release：myapp  Rlease/v1.23.6
2.Image:   myapp:v1.23.6
3.Chart:    myapp-v1.23.6.tgz

Helm Chart 中变量的复用与默认

Helm Chart 的装置时能够指定多个 values.yaml 文件，命令行参数左边的 values.yaml 内容会笼罩右边 values.yaml 的内容。

Chart 中默认的 values.yaml 。values.yaml 只有 myapp 本人 Chart 会用到的配置项，配置项尽量以默认的形式配置在 values.yaml 中，如默认：

1.global.imagePullSecret
2.global.clusterDnsDomain
3.myapp.resources
4.myapp.mysql.dbname

values-global.yaml。反对所有的配置项，但并不需要所有配置，如环境差别配置：

1.global.imageRegistry.addr（project,user,passwd)
2.global.mysql.host（port,user,passwd)

values-myapp.yaml。在 values-global.yaml 定义了该字段，然而因为某些起因须要调整的内容。比方有 10 个利用应用到了 MySQL，然而其中有 9 个应用一套 MySQL 集群，另外一个利用独自应用一套独立的 MySQL，这时能够独自给这个利用定义一个差异化的 Values-myapp.yaml 来笼罩 values-global.yaml 中的 MySQL 字段即可。如

global.mysql.host（port,user,passwd）
例如 myapp-v1.23.6.tgz Chart 装置命令

helm install -n ns1  myapp  -f values-global.yaml -f values-myapp.yaml ./myapp-v1.23.6.tgz

装置时文件的优先级程序 Chart 中默认的 values.yaml < values-global.yaml < values-myapp.yaml

装置和依赖的治理

在单个 Helm Chart 装置时能够应用 helm install 的形式装置，然而如果 Chart 数量十分多，而且有程序依赖时手动装置并不适合，这时举荐编写一个自动化的工具来治理和装置，能够是 shell 脚本或者装置部署平台。

轻舟部署应用的 Sail 零碎就是一套自研的私有化交付零碎，它可能提供环境的部署布局、配置的渲染、装置逻辑的解决、部署工作的执行以及环境信息的对立治理等性能。

Helm 降级利用

软件交付无论是晚期的自动化交付还是当今的 Helm 云原生利用交付，带有结构化数据的利用降级都不是一件容易的事件。常常会因为降级时波及到表字段的更新增大了降级的危险。

在云原生利用交付场景下，Kubernetes 资源文件申明式反对，个别不须要非凡解决，Kubernetes 的滚动更新与 Helm 的差别内容更新能够很好的解决。

但对于 SQL 的解决，因为波及到业务自身的逻辑，Helm 作为工具也是无能为力。但 Helm 为咱们提供了 Hook 的性能，能够让我在装置或降级的某个阶段中插入肯定的工作。对于这个工作能够由业务方来决定如何解决 SQL。

对于 SQL 的解决一种思路如下：

SQL 文件依照如下规定定义逻辑，Job 应用 pre-upgrade hook 作为降级根据：

• 备份待降级的数据库
• 获取环境运行中 Release 信息中的 Chart 版本（内部工具获取）
• 应用 .Chart.appVersion 示意指标版本
• 获取环境 Release 版本和指标 Chart 版本的短少版本
• 判断是否满足降级兼容性

• 依照版本顺次执行 SQL 导入

  SQL 保护办法

• 保护初始的全量 SQL 文件，如果大于 1M 就拆分成多个 SQL 文件
• 每个版本的增量都作为独立的 SQL 文件，SQL 文件标准命名和版本标准保持一致。如 v1.1.0.sql/v1.1.1.sql/v1.1.2.sql
• 应用 ConfigMap 来挂载一个大版本的全量和增量 SQL 到 Job 容器的固定目录（如：/data/upgrade/sql/）

那么在降级时就能够通过如下命令来主动降级到指标的版本

$ helm upgrade -n ns1 -f values-global.yaml -f values-myapp.yaml   -set release.chartVersion=v1.23.1 myapp ./myapp-v1.23.7.tgz

环境治理

在基于 Helm Chart 的云原生利用交付的模式下，业务环境的定义能够简略了解为就是 Chart 列表和部署时的 Values.yaml 文件。

依照标准定义的 Chart 列表可能阐明环境中部署的产品和组件都有哪些以及应用的版本是什么。

Values.yaml 中保留了以后环境中所有的差异性配置，联合 Chart 中默认的配置，就能够还原该环境运行的服务所有的配置信息。

在私有化场景下，环境信息保护尤为重要。在无奈实时拜访客户环境时，部署时保护的 Chart 列表和 Values 文件可能帮忙售后疾速的定位和解决问题，在进行 bug 修复或版本升级时也能疾速的输入降级资料。

基于 Helm 实际的成果与收益

网易数帆轻舟应用 Helm 的现状

因为晚期 Helm3 还未公布前，轻舟私有化交付是基于 Ansible 的形式来交付的，在越来越多的我的项目交付起来后，场景的差别也越来越多，兼容适配的老本也越来越高。

在 Helm3 公布后，轻舟所有的服务全副进行 Helm 化的革新，以以后的状态和之前相比有很大的提高：

• 单个利用版本公布周期：6 个月 ==> 1 个月
• 场景化适配：无奈预测的多种 OS 零碎适配 ==> Docker 镜像单次 x86/ARM 适配即可
• 我的项目交付效率：均匀 2 周 / 套 ==> 均匀 2~3 天 / 套
• 交付品质：均匀每套环境交付问题数 大于 10 个 ==> 小于 3 个

交付的产品能力涵盖云原生的容器云、微服务、服务网格、CICD、API 网关、分布式事务、APM 以及 PaaS 中间件等产品。

基于这套私有化交付工程，反对了公司内外大量的私有化客户我的项目，保障了我的项目的顺利交付。

总结

商业私有化交付时客户环境基础设施品种繁多、场景简单，基于容器和 Kubernetes 能极大的升高场景适配和前期运维的工作量。

非在线场景下 Helm 是以后云原生利用的打包和交付的最佳抉择之一。

优良的 Helm Chart 实践经验须要案例积攒，并可能传承，举荐基于代码的形式传承教训。

作者简介：赵文宇，网易数帆轻舟交付解决方案专家。负责网易数帆轻舟我的项目交付和解决方案相干的工作，从 0 到 1 构建了轻舟私有化交付体系，给客户提供从我的项目布局到交付落地的技术撑持。对云原生场景下组件高可用计划与利用打包交付有着丰盛教训，对轻舟生态技术体系有着深刻的了解，相熟云原生场景下软件私有化交付模式。