nodejs前端项目的CI/CD实现（二）jenkins的容器化部署

一、背景

docker安装jenkins，可能你会反问，这太简单了，有什么好讲的。

我最近就接手了一个打包项目，它是一个nodejs的前端项目，jenkins已在容器里部署且运行OK。

但是，前端组很追求新技术，不断地升级Nodejs的版本，之前是14，现在需要升级到16。

也就是说，原本运行顺畅的打包不灵了，必须得升级Nodejs才行。

我要看下文档，得知道jenkins容器的运行命令，才好去修改并重启容器。

这是我的第一反应，可也正是这个思维，导致走了不少弯路。

文档只有机器的密码，以及jenkins的admin超管账户的密码。

并没有交待Jenkins容器是怎么起来的，而所谓交接也中断不知多久，没人知道此时。。

我的这个固定思维，导致我走了不少弯路。也正因为此，我才想把这期间遇到的问题，梳理出来，希望能够帮助到有需要的同学。

主要需要知道以下信息，对于Jenkins容器来说：

对于本文的情况来说，镜像image和端口映射是很容易看到，最重要的信息莫过于volume持久化。

当然你可以借助于docker inscept命令，我这里是使用portainer界面查看。

从下面详情，也可以看到镜像image名称，使用的就是官方镜像。

从下面的环境变量，可以看到，jenkins使用的版本是2.323。在制作自定义镜像的时候，这个信息可以帮助到我们该选择哪个版本。

从上文，我们不难倒退出目前在运行中的容器，运行脚本大致是：

bash 复制代码

docker run -d -uroot \
-p 8080:8080 \
-p 50000:50000 \
--name jenkins \
-v /opt/jenkins_home:/var/jenkins_home \
jenkins/jenkins:2.323

可是问题来了，jenkins job打包需要的那些命令和工具呢，他们在哪？

也分为几种可能，但都没找到。

前面三处都找了，也没找到，可偏偏遗漏了最后一处。。。因为这种方式，我自己在操作中比较忌讳。

容器一定被删除后，安装的命令和工具就都丢失了，并且对于运维来说，也是透明的。

就是说，别人并不知道你对容器具体有做什么改进，一头雾水。

我试着做了，但总会缺这缺那的，很难真正跑起来。

因为宿主机是centos，而jenkins容器是ubuntu操作系统。

想要在ubuntu系统里，去执行一个centos上的可执行文件，何其难也~~

因为可执行文件还依赖操作系统底层的函数及文件。

可以说，不仅不推荐，似乎本文也行不通。。

这种方式，就是拿容器当虚拟机使用，丢失了容器化的内涵和意义。

缺什么软件，你就去容器里安装，问题是简单地解决了，留给运维一堆坑。

后面接手的人不禁反问一句：如果虚拟机那么好使，还容器化干嘛。绕来绕去，不知不觉中又绕回去了。

限于篇幅，对jenkins的容器化部署就说到这，见下文。。。