SREWorks持续交付云原生化: 镜像构建

原创
05/31 11:58
阅读数 2.2K

作者:邓洋杰

1 背景

在应用运维领域中,CI/CD已逐步演化成持续集成(Continous Integration)、持续交付(Continous Delivery)和持续部署(Continous Deployment)三个核心阶段,以支持更加复杂的大型系统建设。

CI依然代表应用开发人员的开发、测试、合并等自动化阶段,而CD已分化成持续交付和持续部署两个关联阶段,为云原生背景下的应用运维提供了更多的可操作空间。其中,持续交付在不同的阶段,都有相对应的事实标准,大致可分为“On-Machine”阶段,“On-Container”阶段以及目前的“On-CloudNative”阶段。

本文主要讲解一下SREWorks在持续交付阶段,镜像构建云原生化的解决方案,一句话概括就是:SREWorks在执行镜像构建时,按需启动一个Pod去执行镜像构建任务。

1.1  发展阶段

“On-Machine”阶段: 交付应用往往以一个编译后能正确运行的语言包组成,比如Jar包等;

“On-Container”阶段: 容器技术的出现,此时,容器镜像Image作为应用交付的最终形态,解决了语言包对机器运行环境的强依赖,进一步提升了应用运维的效率;

“On-CloudNative”阶段: 是以“On-Container”为基础的,是前者在云原生时代的高级形态。“On-CloudNative”阶段最终交付物不仅包含最基本的容器镜像Image,还包含了一系列的运维特性,以支持容器编排等云原生场景需求。

1.2  持续交付云原生化

云原生是以分布式和云架构为基础的,但其对各种技术架构提出了更标准化的要求。在云原生思想逐步扩展开后,云原生能为传统的CI/CD带来什么影响,成为SREWorks考虑的主要问题之一。

其中最基本的,我们希望持续交付可以基于底座资源池去做弹性构建(按需启动一个构建pod,构建完释放资源),而不用常置一台特定的构建机去做构建。

SREWorks团队在经过不断的探索实践之后,认为云原生化的持续交付应包含以下几个显著的特点:

  • 资源弹性:根据构建需要从资源池申请cpu等资源,提高资源利用率;
  • 安全性:实时动态地执行构建任务,有明确的归属和权限隔离管控;
  • 免运维:不再需要管理特定的构建机器或进程,机器管理统一由底座集群完成;
  • 快速交付:底座集群保证构建任务容器能正确调度执行,自动规避故障节点,快速响应构建请求。 SREWorks正是基于上述的几个点,逐步完成自己的镜像构建云原生化建设。

2  架构演进

2.1  Docker build 机制

按照Docker官方文档给出的架构图,Docker主要分为Client,Host,Registry三个部分。

Docker按照C/S架构,通过ClientHost进行通信。Host作为后端,负责处理所有Client请求以及后端模块的调度及管理工作。Registry作为中心化的镜像仓库,存储所有需要保存的镜像。

此处,我们主要关注   docker build  命令。可以看到Host中Docker daemon模块负责接受和处理Client的命令请求。Docker daemon内部架构此处不做详细描述,只需要知道Docker daemon在接受到  docker build  命令之后,会启动一个create job去执行构建。在构建过程中,可能会需要到远程Regiestry中心镜像仓库拉取基础镜像(如果本地不存在的话)。在构建完成之后,Host会将构建好的镜像保存在本地的Repository中。

Docker daemon作为docker的服务端,由于需要系统的ROOT权限等要求,导致其不能天然地运行在另一个docker容器之中。这也为镜像构建云原生化提出了新的技术问题。

2.2  初始态:Docker out of K8S

在Docker build机制的支持下,在最初阶段是通过在K8S外搭建构建机器做镜像的构建任务,其架构如下: AppManager:是SREWorks的中心管控服务,负责与K8S底座交互,应用构建发布及生命周期管理等核心功能。

在初始态,AppManager在需要执行镜像构建时,直接连接部署在K8S之外的某个ECSDocker daemon来执行镜像构建。依然处于“On-Machine”的发展阶段。

这种方式的缺点包括但不限于:

  • 安全性差:当这台ECS被劫持之后,恶意程序通过在镜像构建过程中注入非法代码,能够影响所有部署在云上的应用;
  • 效率较低:当构建任务过多时,一起抢占ECS机器资源,会引起构建拥塞。

2.3  过渡态:Docker out of Docker

Docker out of Docker,下面简称“DooD”,依然使用docker build机制的远程构建能力,每个执行构建任务的pod都连接到本地node的Docker daemon实现镜像构建。

通过DooD的方式,AppManager可以动态的在集群层面拉起pod去执行镜像构建任务,而不用再去跟集群外部服务打交道。镜像构建任务可以均匀的分布到每台node,避免构建拥塞。且DooD通过操作基础设施node节点,实现了一种“伪弹性构建”的能力。

DooD的缺点也是显而易见的:

  • 实施成本高:需要人工为每台Node节点安装Docker daemon程序,并保证其正确运行;
  • 安全性差:构建Pod有能力通过node节点Docker daemon进程影响其他Pod;
  • 资源浪费:由于每台node节点都常置Docker daemon服务进程,不仅没有减少资源消耗,反而加重了资源浪费,这也是为什么称其为“伪弹性构建”。

2.4  终态:Docker in Docker

Docker in Docker,下面简称“DinD”,与DooD是对应的,表示容器内client直接连接容器自身的Docker daemon进程来完成镜像构建任务。其架构如下: DinD的架构,实现了按需拉起执行镜像构建任务的Pod,并在任务完成后及时归还Pod资源。构建任务的Pod也不再感知Node机器,所有管控及调度工作由K8S等云底座统一实现。其优点包括:

  • 弹性构建:所有构建Pod所需资源由K8S等云底座统一调度和回收;
  • 安全可靠:构建Pod满足所有资源及权限管控要求,更加安全可控;
  • 无服务器:Pod是容器化的,不再运行在ECS等机器之上;
  • 快速交付:在集群层面完成构建任务调度,更加及时且可扩展。

3  基于Kaniko的设计实现

目前支持在容器内部进行镜像构建的开源技术有很多:KanikoBuildKitImg等,其中Kaniko作为Google官方开源的容器化构建解决方案,目前收获了最高的star数量,社区活跃度也最高。排名其后的BuildKit和Img也通过其自身的技术优点吸引了一大批粉丝。

从架构上看,BuildKitImg都是通过内置一个非Root权限的嵌套容器去执行构建。而Kaniko没有拉起嵌套容器去做构建,而是直接实现了Docker daemon中create job的功能,更加的轻量、高效、安全。因此,SREWorks基于Kaniko去做云原生下的镜像构建。

在引入Kaniko之后,SREWorks的中心管控appmanager服务按照如下架构来对接ApiServer拉起和管控执行构建任务的pod。

  • AppManager关键模块讲解:

  • Provider模块:AppManager内置了一系列的Provider负责处理Client客户端的请求; 构建任务状态管理器(ComponentPackageTaskStateActionManager):负责监听各类构建任务状态更新事件,进而调用不同构建阶段的子处理器;

  • RunningStateFailureStateSuccessState等模块:具体负责处理不同构建阶段的事务;

  • ComponentPackageBuilderService模块:负责具体的镜像构建、构建Pod管控等工作。 这里主要讲一下镜像构建的主要工作流程:

a. 将应用Component包 (每个应用可包含多个Component,每个Component又可包含多个Container) 拆解为多个Container构建任务;
b. 启动构建Pod Informer监听;
c. 下载每个Container构建源代码,并渲染Dockerfile文件;
d. 渲染并下发构建Pod yaml并监听构建pod状态;
e. 当构建pod到达终态时,进行Component交付包生成、资源清理等工作。

4  设计反思

通过以上基于Kaniko架构设计和实现,SREWorks提出了持续交付云原生化的设计要求,并为此设计并实现了自己的解决方案。在此罗列一些目前的架构Feature供大家深入发掘一下:

  • 内置了Dockerfile参数动态渲染功能,这为运维人员提供了可操作空间。

  • 由于目前云底座K8S等,都已支持所有实现了Container Runtime Interface(CRI)的容器运行时(例如Docker、containerd、CRI-O),所以本文所提DinD,在目前云原生形态下称其为DinC(Container)更为准确。

  • SREWorks的持续交付物的核心是镜像,在某些特殊场景下,交付物即使转变为机器时代的Jar包或者比镜像更高级的形态,但是本文的弹性架构设计依然适用。

  • 共享PV下发构建tar包:可以去除MinIO的依赖,执行构建任务的pod直接从共享PVC内读取构建tar包。但是由于在某些云底座上,无内置“ReadWriteMany”访问模式的PV,所以暂时关闭了这项功能。

  • 构建Pod替换成Job:使用Pod进行构建的初衷是足够轻量化,且AppManager具有绝对的管控权限。目前还没有足够的替换理由。

5  云原生建设感悟浅谈

广义地来看,可以说现在的几乎所有云产品都是云原生的,因为他们都或多或少满足了云原生所标榜的微服务、容器、持续交付、DevOps。但是,狭义地来看,在某些场景下,其往往又不能完全满足云原生的某些特性:例如可复用、免运维、资源池化等。

正如CNCF对云原生的定义:“云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中,构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式 API”。在作者看来,其内在含义代表着一种以产品能力为导向的最佳上云实践。

脱离“产品”这个导向,云原生化往往是没有意义的;“最佳实践”代表云原生化是不断迭代的;以本文镜像构建的演进为例,也是在产品能力的指导下,不断迭代和完善的,这就是云原生化的意义。


同时也欢迎大家多提issue,协力将SREWorks打造得更好,欢迎各位加入钉钉群或微信群分享和交流~

欢迎加入钉钉答疑交流群:35853026

SREWorks开源地址:

https://github.com/alibaba/sreworks

更多开源项目合集:

https://www.aliyun.com/activity/bigdata/opensource_bigdata__ai


更多推荐:

SREWorks前端低代码工程设计概览

SREWorks v1.1 版本发布 | 组件插拔场景化部署能力

基于Elasticsearch生长的SREWorks数据化运维体系

更多详情请关注微信公众号:阿里智能运维!!

展开阅读全文
加载中

作者的其它热门文章

0
0 收藏
分享
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部