1. 前言
随着应用构建需求增加以及新构建场景引入，公司对构建系统的扩展性、稳定性要求日益提高。多语言构建（如Golang、Java、Python、Node.js 等）所依赖的环境，部署在同一台物理机上时，使构建机环境维护困难；并且多应用同时在一台机器上构建会相互影响；在传统的构建机主从模式下，单一的Master 构建节点会成为系统单点故障源，导致整个构建集群不可用。
通过行业方案调研，决定对构建节点进行容器化改造，实现构建任务隔离的同时，提升构建集群伸缩性。并且对构建集群进行去中心化架构改造，摆脱了对单Master构建节点依赖，使所有构建节点能独立完成构建任务，极大提高构建集群容灾能力。
2. 背景
2.1 现有问题
- 单点故障：Jenkins Master节点宕机会导致整个构建系统不可用。
- 性能瓶颈：Jenkins Master节点负责所有任务调度，负载过高时导致性能瓶颈。
- 构建配置复杂：单slave节点需要同时兼顾多种语言类型站点构建，导致机器配置复杂，维护成本高。
- 迁移难度大：物理机过保时，需要重新搭建构建节点，导致成本高且容易出现问题。
- 软件版本不一致：不同slave节点可能运行在不同操作系统上，需要确保系统版本、JDK、Maven、Python等构建环境版本一致，维护成本高。
3. 改造过程
改造过程主要包括以下步骤：
- 构建节点由master调度构建改造成能独立构建的容器节点
- 构建架构从Jenkins master调度改造成aladdin平台调度
- jenkins构建产物信息安全脱敏改造
- 灰度切换集群调度架构，平稳迁移构建节点
3.1 构建节点独立化、容器化改造
原有主从架构中，Jenkins Master节点负责完成构建任务配置，包括：插件，账号，环境变量等。实现可单独完成构建任务的节点，最快捷稳妥的方式是将Jenkins Master完整复制出来，放入容器中当作构建节点使用。
如何复制？
将现有Jenkins Master的JENKINS_HOME指向的安装目录完整复制放入容器中，在启动jenkins时指定JENKINS_HOME为该文件夹，打包镜像dockerfile如下：
FROM XXXXXXX/aladdin/base_os/centos8:v1.0
ENV LANG=en_US.UTF-8
# 复制 原 jenkins完整的安装目录到基准镜像中
COPY jenkins.war /
COPY jenkins /jenkins
# 复制jdk
COPY jdk-21.0.2 /usr/local/jdk-21.0.2
# 配置jdk环境变量
ENV JAVA_HOME /usr/local/jdk-21.0.2
ENV JRE_HOME=$JAVA_HOME/jre
ENV PATH=$JAVA_HOME/bin:$PATH:$JRE_HOME/bin
ENV CLASSPATH=.:$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar:$JRE_HOME/lib
# 启动jenkins时指定JENKINS_HOME为/jenkins，jenkins启动后访问可发现和原jenkins master配置一致，无需重复配置
ENTRYPOINT java -Dhudson.security.csrf.GlobalCrumbIssuerConfiguration.DISABLE_CSRF_PROTECTION=true -DJENKINS_HOME=/jenkins -jar /jenkins.war --httpPort=80
3.2 调度架构改造
完成jenkins构建节点容器化后，构建容器节点可独立完成构建任务，aladdin平台负责调度构建节点。aladdin持续集成平台本身就是集群部署的，有良好的容灾能力，完美解决原有构建集群单节点故障问题。
3.3 信息安全改造
jenkins在构建时会将项目源码下载到构建机上进行编译打包，项目源码和打包产物可直接在jenkins上查看、下载，且jenkins经常会报出各种漏洞，带来极大安全隐患。 基于上述安全问题，我们需要对jenkins进行访问限制。用户构建项目时需要查看构建日志和单测日志页面，所以，除这两个页面外，通过将jenkins端口办公网络访问权限回收，nginx代理的方式，将jenkins其他页面隐藏。只展示构建日志和单侧日志页面，实现限制直接查看项目源代码和产物，同时避免jenkins漏洞带来的安全隐患。
3.4 平稳迁移构建节点
为了平稳的完成构建集群的灰度切换，因此采用四步走策略：
- 实现影响较小的单元测试节点进行容器化
- 实现低风险业务线构建节点容器化
- 实现主营业务线站点构建容器化
- 实现其他站点构建容器化
4. 遇到的问题
4.1 docker中怎么调用 docker build打包镜像
原构建节点是在虚拟机上通过调用docker build命令完成站点镜像构建。构建节点容器化之后，如何在容器中调用docker build命令完成构建？ 最开始尝试在容器中安装docker命令，但是失败了，会遇到各种奇怪的报错；后来想到可以调用远程docker构建机完成镜像的构建。 我们需要安装jenkins插件docker-plugin,配置好远程docker构建机，即可调用远程构建机构建镜像了,配置如下：
注意： 调用远程docker构建机时，默认会将dockerfile文件所在目录中的文件传送到远程构建机上，需要控制传输文件目录的大小
4.2 容器化后，磁盘占用翻倍
构建节点容器化之后，上线一段时间，服务器突然磁盘容量告警了！ 平台有定时job会清理构建任务，只保留3天的构建量数据，而且构建量也没有明显增加，磁盘怎么突然不够了呢，经过检查发现，/var/lib/docker/overlay2 目录占用了大量的磁盘空间，这显然是docker引起的。
经过排查，是启动容器时，容器内jenkins workspace目录未挂载到宿主机上导致的。
docker 中有两个重要的文件夹：
- diff 文件夹： diff文件夹包含了Docker镜像的变更内容。当对容器进行修改或添加文件时，这些变更会被记录在 diff 文件夹中。用于存储与基础镜像的差异。
- merged 文件夹： merged 文件夹由基础镜像和 diff 文件夹合并而成的。在容器中对文件进行修改或添加新文件，这些修改将存储在 merged 文件夹中。
未配置容器内jenkins workspace目录挂载到宿主机上，导致容器内有大量写的操作发生，从而产生更多的diff和merged文件，占用了大量磁盘空间。
# 原则上如果容器内服务有写文件的行为，应该将文件目录挂载到宿主机上，而不是直接往容器里写。
# 启动容器时，挂载jenkins workspace目录到宿主机上
docker run -itd --name build_jdk8_01 -p 4010:80 -v
/jenkins/workspace:/jenkins/workspace jenkins_server/build_jdk8:v1.6
构建节点改造完成
- 构建环境隔离：构建节点容器化后，每个构建任务都在单独构建服务上构建，互不影响，显著提高构建成功率，构建成功率保持97%左右。
- 容灾能力增强：从单一主节点架构转变为多主节点架构，每个构建节点独立执行任务，大大提高容灾能力。
- 环境一致性保障：通过构建节点容器化确保构建环境的一致性，减少环境配置问题，提升构建稳定性。
- 构建节点快速搭建：容器化使节点搭建和迁移变得便捷。
节省资源：无需Master节点来调度和管理任务，降低系统复杂度的同时节省物理机资源。
未来规划
- 探索新的构建工具和技术，提升构建效率和构建质量。
- 接入新的构建方式，支持模块化部署。
