本文主要是介绍信也持续构建集群容器化改造之路,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
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节点来调度和管理任务,降低系统复杂度的同时节省物理机资源。
未来规划
- 探索新的构建工具和技术,提升构建效率和构建质量。
- 接入新的构建方式,支持模块化部署。
这篇关于信也持续构建集群容器化改造之路的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!