看了几篇docker和jenkins持续集成的文章,都是docker里启动一个jenkins
把jenkins丢到docker里这样弄起来很复杂,感觉也没什么优点,想问下这样弄是为什么?
看了几篇docker和jenkins持续集成的文章,都是docker里启动一个jenkins
把jenkins丢到docker里这样弄起来很复杂,感觉也没什么优点,想问下这样弄是为什么?
按题主的情况 docker 作用确实不大,完全可以自由选择:
docker run -p 8080:8080 -p 50000:50000 jenkins/jenkins:lts
多嘴一句:
容器技术主要是让操作系统里的每个进程都能享受“独享操作系统资源”的待遇,这样一来部署时就无需考虑环境差异,用统一的方式做资源映射就行(ps: ip&port、文件系统都算资源)。而 docker 更是基于此做到了相当于把运行环境和软件本身都打包在一块,到处拷贝替换就能完成安装和升级过程,仿佛操作系统镜像一般,但比之要轻便 N 倍、强大 N 的平方倍。
以上是在下眼中的 docker ,这对无数需要开发和维护 7*24 小时运行的软件人来说诱惑实在太大了,哪怕机器数量不大也懒得去折腾了。
回(chui xu)到具体的问题上:
> 1. 把jenkins丢到docker里这样弄起来很复杂
没错,操作不熟悉的东西确实难受。强大的工具多少都有点副作用——复杂,但 docker 控制的还不错。
> 2. 感觉也没什么优点
在你的使用场景下,是的。但那些折腾 7*24 小时运行的服务端软件的人有不同意见。
> 3. 想问下这样弄是为什么?
可能仅仅只是因为那些文章作者因为会用就顺手用了。你不用照搬,用包管理器也一样的。
若是基于容器的CI/CD就不要用jenkins了吧 用这个 https://github.com/drone/drone 大道至简,做一个功能强大的东西不难,做一个功能强大又简单的东西才牛逼。
java的应用放在docker本身意义不太大,尤其是像jenkins这样很方便就能启动的应用
java本身已经有docker的核心特性(集装箱、资源限制等)
但是docker是跨语言的,是一种更优雅的解决方案,放在docker里面统一管理也未尝不可
2 回答2.4k 阅读✓ 已解决
2 回答829 阅读✓ 已解决
1 回答1.4k 阅读✓ 已解决
2 回答1.4k 阅读
2 回答1.3k 阅读
1 回答1.6k 阅读
1.1k 阅读
我以前也曾经把jenkins放进docker,后来发现反而麻烦无比。因为docker适合轻依赖的应用,像jenkins这种依赖非常重的应用是根本不适合放在docker中的