发布Linux 以及相关云镜像

发布Linux 以及相关云镜像流程

前言

各大厂（阿里，百度，字节跳动）随着规模的庞大，越来越重视自身软件生态系统的完整。为了更好的做到对上层复杂软件的支撑，发布独有的Linux 版本已经成了很重要的一个环节。

据笔者经验， 各大厂Linux 几乎都是基于 Redhat 的贴牌产品。

贴牌Linux = Redhat产品 + 自家的Linux patch（性能优化等等）

而现在云发展如火如荼，在制作传统的Linux ISO产品的同时， 还需要发布各种Linux 云镜像文件。
本文将根据笔者在某一线大厂近六年工作经验， 讲述公司Linux ISO 产品以及 Linux 镜像文件的发布流程。

整体流程

作为开发人员， 一般喜欢流程图， 那就先看一下ISO/云镜像发布整体流程图。

以上发布系统整体来说，分为两大部分：
第一部分是 SCM 管理
第二部分是 基于jenkins 的devops 管理。

SCM 管理部分

先聊聊SCM 部分，

贴牌Linux 的源码来源有三个部分：

（目前流行的包格式有redhat 的rpm ，ubantu 的 deb，本文讲解rpm 格式为主 ）

第一部分： Redhat 发行版以及errata ， 该来源可以提供 specfile 以及 tarball
该部分基本上均可以通过自动化实现，需要主要设计模块分为

• redhat iso 发布的时候， 自动化获取 new/modify/update pkgs list.
  自动化commit 源码到对应repo（svn or git）
  如果公司独有patch ，自动merge 本公司独有patch 到 update package
  -redhat errata 发布的时候， 自动化获取source ，
  如果公司独有patch ， 自动merge 本公司独有patch 到 source

第二部分 upstream ， 例如包nodejs 等， 上游来源提供 tarball
该部分基本上可以通过自动化实现，主要设计模块是
自动化监视上游网站， 发现更新， 自动化download， 并自动创建对应的specfile

第三部分就是本公司的开发维护人员， 在性能优化， 解决bug 过程中会涉及到有关specfile 以及 tarball 的改动，该部分涉及到调试， 所以会有更多的开发人员的手动工作。

源码编译的自动触发

该部分需要修改git hook 或者 svn hook 来检测commit 关键字段， 从而实现jenkins master 的触发。

Jenkins 部分

jenkins 主要实现三部分工作
第一部分是通过源码编译SRPM，RPM
该部分用到的开源工具主要是 mock 以及 Redhat 8 之后的module-build-service,
还需要维护一个数据库， 因为Linux 产品会同时维护很多的包， 有的包在编译过程可能会涉及到特殊的配置， 例如需要安装额外的包， 或者是需要配置特殊的proxy等

第二部分是通过SRPM，RPM，comps.xml ,iso list 编译 ISO。
该部分目前主要用的开源工具是 lorax 进行iso 的编译。
之前在redhat 5 或者 6 可能会用到 anacanda 的build-install ，但是目前基本不会用。
因为 lorax 更加的模块化以及灵活， 更有助于用户自己的配置。

第三部分是通过 ISO 编译云镜像。
该部分主要用到的开源工具是hashcorp 公司 packer。
基于该工具，可以编译各种云平台的云镜像。

性能研究

jenkins 的负载均衡

jenkins slave自身可以配置负载均衡， 笔者曾经测试同时trigger 24组编译，发现成功的负载均衡到4 台slave 上。

24 Parallel test without interval
Schedule like 6+6+6+6

Server 1

#13125 2hr6min
#13124 2hr3min
#13123 2hr6min
#13121 2hr1min
#13120 2hr5min
#13108 2hr5min

Server 2

#13130 2hr25min
#13129 2hr26min
#13122 2hr24min
#13114 2hr25min
#13113 2hr23min
#13110 2hr26min

Server 3

#13119 2hr5min
#13117 2hr5min
#13116 1hr59min
#13115 2hr5min
#13112 2hr3min
#13111 2hr6min

Server 4

#13128 2hr7min
#13127 2hr8min
#13126 2hr6min
#13118 2hr8min
#13109 2hr8min
#13131 1hr59min

mock 相关

‘mock init src’ improvement

不要安装 ‘subversion’ 在kernel 编译过程中
subversion 在kernel 编译中是不需要的, 这个改进可以节省～3 分钟。

‘git archive for uek5’ improvement :

用 ‘git archieve’ 代替 ‘git clone’
该改动可以节省 ~5 minutes.

Use mock ccache plugin

ccache 可以节省cpp 的与处理时间
ccache + bind 插件可以使mock 编译kernel 过程中访问 ccache 分区

编译环境（test vm with 8 cpu, 10 G mem）

• 第一次编译 108 minutes 15 seconds

---

cache directory /var/tmp/ccache
primary config /var/tmp/ccache/ccache.conf
secondary config (readonly) /etc/ccache.conf
cache hit (direct) 14
cache hit (preprocessed) 368
cache miss 25765
cache hit rate 1.46 %
called for link 186
called for preprocessing 4478
unsupported code directive 10
no input file 1750
cleanups performed 0
files in cache 68559
cache size 6.0 GB
max cache size 32.0 GB

• 第二次编译 83 minutes 2 seconds

---

cache directory /var/tmp/ccache
primary config /var/tmp/ccache/ccache.conf
secondary config (readonly) /etc/ccache.conf
cache hit (direct) 25694
cache hit (preprocessed) 818
cache miss 25782
cache hit rate 50.70 %
called for link 372
called for preprocessing 8956
unsupported code directive 20
no input file 3500
cleanups performed 0
files in cache 68652
cache size 6.0 GB
max cache size 32.0 GB

从以上结果可以看出，
第一次ccache hit 是14次
第二次ccache hit 是25694次
节省了大概25 分钟