docker安装jenkins,可能你会反问,这太简单了,有什么好讲的。
我最近就接手了一个打包项目,它是一个nodejs的前端项目,jenkins已在容器里部署且运行OK。
但是,前端组很追求新技术,不断地升级Nodejs的版本,之前是14,现在需要升级到16。
也就是说,原本运行顺畅的打包不灵了,必须得升级Nodejs才行。
我要看下文档,得知道jenkins容器的运行命令,才好去修改并重启容器。
这是我的第一反应,可也正是这个思维,导致走了不少弯路。
文档只有机器的密码,以及jenkins的admin超管账户的密码。
并没有交待Jenkins容器是怎么起来的,而所谓交接也中断不知多久,没人知道此时。。
我的这个固定思维,导致我走了不少弯路。也正因为此,我才想把这期间遇到的问题,梳理出来,希望能够帮助到有需要的同学。
主要需要知道以下信息,对于Jenkins容器来说:
对于本文的情况来说,镜像image和端口映射是很容易看到,最重要的信息莫过于volume持久化。
当然你可以借助于docker inscept命令,我这里是使用portainer界面查看。
从下面详情,也可以看到镜像image名称,使用的就是官方镜像。
从下面的环境变量,可以看到,jenkins使用的版本是2.323。在制作自定义镜像的时候,这个信息可以帮助到我们该选择哪个版本。
从上文,我们不难倒退出目前在运行中的容器,运行脚本大致是:
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的容器化部署就说到这, 见下文。。。