关于自动化:自动化离线交付在云原生的应用和思考

3次阅读

共计 1318 个字符,预计需要花费 4 分钟才能阅读完成。

作者:京东科技 王晓飞

前言

本文不议论具体的技术和计划,在对于每一个产品来讲,都有其特殊性存在。繁多的产品解决办法并不适宜所有的产品。然而咱们能够提供一种思路,一种通用办法,甚至咱们已经在某个技术点走的弯路,旨在为各位在离线设计上有更多的案例可循。

对离线的了解

绝对于公网利用,能够从公共镜像仓库拉取镜像,比方 Dockerhub,各大云厂商的公共镜像仓库。二进制编译文件,软件包也十分不便的从 github,各种 yum 源中获取。此时利用无论是部署,交付,生产都处于齐全流程。那么离线就是用户环境是公有云,专有云用户的生产环境无法访问这些公开资源,并且从平安角度来讲,并不能保障其生产平安。在离线环境交付大型生产我的项目,个别要有成熟的根底设置(yum 源,镜像仓库,chart 仓库,NTP 服务等)

解决离线交付会缩小 SRE 和交付团队试错老本,排障老本。并且在肯定水平上可能放弃交付环境的一致性。这里举一个场景例子:

咱们在 K8S 集群时,会依赖特定的内核版本,那么离线交付工具会自动化的进行内核降级,并且依照对立的配置进行下发。

这样一来,整个环境的所有 OS 的内核版本,配置全副保持一致。

插拔式设计

插拔式设计在古代架构设计并不生疏,所以离线交付中须要思考插拔式设计。有诸多能够看到的益处是对已有代码架构侵入不多,齐全能够根据交付需要进行开关。

比方以下代码齐全是判断开关才进行工作:

还有一种重要的思考点是:数据解藕,即离线设计的实现不能对元数据进行强以来,元数据应该以配置或者模版的形式,在离线真正运行是动静读取。

并且可能根据不同的元数据(配置或者模版)进行执行行为的扭转。

依赖感知

依赖模块感知

离线交付是一个链条,须要高低模块感知,并且动静批改配置的形式,传递离线的配置信息。

比方:A 模块须要获取一个镜像,那么在离线模式下,A 模块应该可能感知到离线,并且主动变更获取镜像的地址,指向离线仓库。

零碎主动适配

在理论生产中,往往要兼容不同的 OS 或者平台,那么在离线设计时要进行充沛的思考,离线要可能做到自动识别 OS 或者平台,主动的适配适合的离线包。

下图展现了,咱们在生产中进行分类的办法:

全自动化离线设计

离线的设计,对于用户或者终端来讲,他们并不关怀,次要是交付方为了晋升生产效率进行的行为。所以须要在模块与模块之间,组件与组件之间进行无缝对接。

造成全自动化流程。

比方:A,B,C 都依赖离线,那么当离线开启时,A,B,C 模块都可能依据离线的上下文信息主动批改,并且可能做到不中断。

下图中展现了残缺的离线设计流程,流程尽管简单,然而大多数都应用了流水线。并且在真正实现的局部,又能够做到流程化。

对于用户来讲,无需感知这些。

重在流程设计

离线自身不是独立的流程存在,整个离线须要在以下方面进行设计和实现:

1. 文档和培训,用于离线交付的使用手册以及领导手册;

2. 离线包的制作全自动化,应用流水线性能将离线包构建,版本控制,发行就行全自动化管制,缩小人工参加;

3. 交付团队和 SRE 团队能够疾速的获取离线包。

论断

1. 离线交付是在 ToB,ToG 中十分常见的交付形式;

2. 离线交付理念应该融资在整个架构设计中,而不是将它看成独立的模块性能;

3. 尽可能的应用自动化保护整个离线包;

正文完
 0