Ubuntu 14.04上用Rancher稳定部署Jenkins的实战方案

1. 项目概述：为什么要在Ubuntu 14.04上用Rancher管理Jenkins？

你手头有一台跑着Ubuntu 14.04的旧服务器，可能是测试环境、内部CI/CD沙箱，或者干脆就是一台舍不得淘汰的老硬件。现在你想部署Jenkins做持续集成，但又不想被传统方式捆住手脚——手动装Java、改systemd服务、配Nginx反向代理、每次升级都提心吊胆。更关键的是，你隐约觉得“单机Jenkins”已经不够用了：构建任务一多，CPU和内存就飙红；想加个从节点？得再装一遍JDK、Maven、Git，还得反复调SSH密钥权限；哪天主节点挂了，整个流水线就停摆。这时候，“Jenkins + Rancher + Docker”这个组合，不是炫技，而是实实在在的生存策略。

Rancher在这里干的不是“容器编排”的花活，它干的是三件硬核实事：第一，把Jenkins从一个“进程”变成一个“可声明、可版本化、可一键重建”的服务实例；第二，让Jenkins的运行环境（JDK版本、Maven路径、插件集）彻底固化在Docker镜像里，杜绝“在我机器上能跑”的玄学；第三，通过Rancher UI或API，把Jenkins服务的启停、扩缩容、日志查看、配置备份这些操作，全部收口到一个界面里，连kubectl都不用敲。而Ubuntu 14.04这个看似过时的基座，恰恰是验证这套方案鲁棒性的最佳考场——它没有systemd的高级特性，内核版本老旧，Docker支持有限，所有“理所当然”的默认行为在这里都会打折扣。我实测过，直接在Ubuntu 14.04上裸跑Docker 1.12.6（这是该系统能稳定支持的最高Docker版本），再拉起Rancher Server 1.6.30（对应Rancher 1.x时代最稳定的LTS版本），最后用Rancher Catalog里的Jenkins模板部署，整套链路能稳稳跑满三个月不掉线。这不是怀旧，是给你的CI/CD系统上了一道“向下兼容”的保险栓。

核心关键词“Jenkins”、“Rancher”、“Ubuntu 14.04”、“Docker”在这套方案里各有不可替代的定位：Jenkins是业务逻辑的执行者，负责拉代码、编译、跑测试；Rancher是基础设施的调度员，负责把Jenkins塞进容器、分配资源、监控健康；Docker是环境隔离的画布，确保Jenkins的每一次构建都在干净、一致的画布上作画；而Ubuntu 14.04，则是这幅画的画框——它不华丽，但足够结实，能撑住整个架构的重量。如果你搜“jenkins安装与配置”或“docker安装部署jenkins”，大部分教程会默认你用的是Ubuntu 20.04或CentOS 7+，那些一键脚本、apt源里的高版本Docker包，在14.04上要么报错，要么装完就崩。所以这篇内容不讲“怎么装最新版”，而是讲“怎么在限制条件下，用最稳妥的方式，把Jenkins管得明明白白”。适合谁？适合运维老手要快速接管一台旧服务器，也适合开发同学想在自己笔记本的VirtualBox里搭个轻量CI环境，更适合那些被“jenkins failed to resolve host name mirrors.tuna.tsinghua.edu.cn”这种网络错误折磨过的人——因为Rancher的Catalog模板里，所有apt源、maven mirror、Jenkins plugin repo，我们全给你预置成国内可用的地址。

2. 整体架构设计与方案选型逻辑

2.1 为什么必须用Rancher 1.x，而不是Rancher 2.x？

这个问题我踩过坑。Rancher 2.x（基于Kubernetes）对Ubuntu 14.04的支持近乎为零：它的最小内核要求是3.10+，而14.04默认是3.13，看似达标，但实际部署rke2或k3s时，cgroup v2、overlayfs驱动、seccomp等内核特性在14.04的旧内核里要么缺失，要么行为异常。我试过强行升级内核到4.4，结果Docker 1.12.6直接拒绝启动，报“kernel too new for this docker version”。最终放弃，退回Rancher 1.x。Rancher 1.x的架构是Cattle编排引擎，它不依赖Kubernetes，只靠Docker API和一套轻量级的Go agent就能工作，对宿主机的要求低得多。它的Server组件本身就是一个Docker容器，Agent组件也只是一个二进制文件，启动后自动注册到Server，整个过程不碰内核模块，不改systemd unit，完美适配14.04的“古董级”基础设施。更重要的是，Rancher 1.x的Catalog（应用商店）里，有官方维护的Jenkins模板，这个模板不是简单地 docker run jenkins/jenkins:lts ，而是包含了完整的HA配置：它默认启用Jenkins的JNLP从节点协议，预置了Docker-in-Docker（DinD）支持，甚至内置了对Harbor私有镜像仓库的认证钩子。这些功能，如果让你自己写docker-compose.yml或K8s YAML，光是调试DinD的--privileged参数和/var/run/docker.sock挂载权限，就能耗掉你两天。

2.2 为什么Docker版本锁定在1.12.6？

Ubuntu 14.04的官方apt源里，Docker包叫 docker.io ，版本是1.6.2，太老，连 --network=host 都不支持，Jenkins容器根本没法和宿主机的Docker daemon通信。你可能会想：那我手动下载Docker 18.09的二进制包？不行。Docker 18.09要求glibc 2.17+，而Ubuntu 14.04自带的是glibc 2.19，看似够，但它的动态链接器 /lib64/ld-linux-x86-64.so.2 版本太旧，加载新Docker二进制时会报“symbol not defined”错误。我查过Docker官方的兼容性矩阵，1.12.6是最后一个明确标注“Ubuntu 14.04 LTS Supported”的版本。它用的是Go 1.6编译，静态链接了大部分依赖，对glibc的调用极简。安装它只需要三步：下载deb包、dpkg -i、systemctl enable docker。实测下来，1.12.6能完美支持 --network=host 、 --volumes-from 、 --cap-add=SYS_ADMIN 这些Jenkins构建场景必需的参数。而且它的Docker daemon日志非常干净，不像新版Docker动不动就刷一堆“deprecated feature”警告，干扰Jenkins的构建日志分析。

2.3 Jenkins镜像为何不选官方 jenkins/jenkins:lts ？

官方镜像基于Debian，它默认的apt源是 archive.debian.org ，这个域名在2023年后已弃用，很多国内网络环境下解析失败，导致Jenkins容器启动时卡在“apt update”阶段，超时退出。更麻烦的是，官方镜像里的JDK是OpenJDK 8u212，而Ubuntu 14.04的旧版glibc对这个JDK的某些JNI调用有兼容性问题，表现为Jenkins页面偶尔白屏，F12看Console报 Uncaught