Docker docker 的使用必要性求建议

windanchaos · November 24, 2017 · Last by youcanwin2088 replied at August 12, 2019 · 4832 hits

我们内网打算部署2套独立的测试环境。
单个测试环境包含5台服务器,每个服务器上部署2-3个单独的应用,1个应用一个tomcat。等于说,每个tomcat都有自己的配置。

我所调研的docker能力是交付。而,在我这种测试场景下,环境是稳定的。想了下如果要用docker,我大概需要做:
1、构建自己的tomcat image,(换jdk的fonts)
2、每个应用要单独处理server.xml的配置,日志要方便查看,所以要本地持久化日志和应用的conf目录。

发版的时候,要做的事:
1、基于image按规则生成容器并启动容器。
2、重启需求的情况,重启容器。

而,如果不使用docker。每个服务器就部署2-3个tomat。操作要简单很多。这方面jenkins+shell处理已经很成熟。

所以,我还有什么理由用docker呢?

欢迎docker用得很深的同学拍砖,给点建议。

共收到 18 条回复 时间 点赞

恩,可能你现在还没有感受到docker的好处,这也挺正常的。刚开始接触docker的人多多少少都会有这个想法的。 你可以想象一下, 现在你们只有2套测试环境,环境也不复杂,没有多少服务,所以用jenkins+shell是没问题的。 如果你的环境数量扩大10倍,20倍,30倍,甚至100倍的话,纯虚拟机+shell还管不管的过来呢?模块更新的时候, 环境依赖变更的时候,服务挂掉的时候, 甚至是环境迁移的时候(由于某种原因该服务器下线或者迁移到其他机房,这期间难道环境就这么不可用不管了么?)还有所有这些环境的配置管理和服务发现怎么办?运维成本会变成一个噩梦,有多少人都会累的像条狗。所以这时候docker+容器编排框架就体现出了无穷的优势,只要有镜像,可以迅速更新所有的环境,增容扩容也很简单,同时监控,容灾,持久化等等都做的好好的。 以你现在测试环境的规模确实是很难感受到docker的好处的,在这种体量下用docker还是虚拟机都无所谓,区别不大。

我现在用docker+k8s管理着一个容器集群,高峰期七八十套环境共存,加上测试服务,监控,集群管理,测试执行机器也在这里面跑着。 而运维的人只有我一个,而且我还是带搭不惜理的管着(我平时有测试任务和开发任务)。 这时候就体现出了docker的巨大优势和其强大的生态圈,k8s的自动化运维做的很强,所以我才可以这么悠闲的管着这么多环境。

孙高飞 回复

我最近也用docker将我们整个大数据环境迁移到了docker容器里。不过我不是将每个服务制作成一个镜像,然后去用k8s编排。主要是因为大数据的服务组件实在太多,而大数据有自身的部署工具ambari,我是借助了ambari,先启用一堆基础容器(debian),利用ambari在这些容器内部署各个大数据组件,然后将各个容器commit成镜像,出来一套容器镜像套件。然后用了Swarm去做容器跨主机的调度,监控用的是Rancher。这些工作都是一个人在搞,不知道飞哥能不能给我这种方式一些点评和指导。

目前整个集群也是支持多环境的并行,利用的是swarm的label来区分不同环境。各个环境利用docker的跨主机通信机制,搭建自己的私有overlay网络。

其实除了部署和管理的便利性,docker还有一个大的好处是开箱即用。以前我们往线上发布的是war包,服务器测试运维各管各的,用了docker以后发布的就是一个完整的容器,使用统一的镜像就可保证所有环境参数测试环境和线上是一致的,所以说容器的特性天生就符合持续交付的要求,当然前提你线上也已经开始用docker。如果只是两三台服务器,线上也没有用docker,我觉得用shell也差别不大,但对docker的技术必须保持关注,毕竟这个是大势。

Nisir 回复

挺好的,够用就行,其他的服务不用都追求极致。 根据你们的需求来就行。 swarm我当初只是在调研方案的时候搞过一个单节点的出来,了解的不深,不知道加一些容灾,持久化,7层路由等需求是不是特别麻烦。k8s是自带就有这些方案的。 不过你们测试环境体量没那么大的话也没必要搞这些。够用就好。就是尽量别commit, 能做dockerfile还是用dockerfile比较好。以防以后环境变化的时候会很麻烦

孙高飞 回复

谢谢。我也知道dockerfile绝对是更好的方式,但是我们这种好像没办法用dockerfile来搞。因为没办法去制作单独的容器镜像,只能通过ambari界面化的ui部署工具,一体化地部署一堆组件,让ambari去处理各个组件之间的依赖关系。。。也考虑到commit的方式会让容器的体积越发庞大,所以我们只能基于此制定了一套镜像升级规范来约束镜像升级操作

Nisir 回复

恩,那也可以,只是第一次commit就好了。 以后根据这个镜像写dockefile就好了

如果你有多个环境,或者频繁需要启用一个临时环境时,用 docker 维护起来方便很多,也更容易确保环境配置的一致性。docker 本身的一个目标是开发、测试、生产都采用相同的配置,减少因为环境差异(如服务版本、系统版本等)引起的问题和风险。

如果是固定环境,或者环境数量少,我觉得差异不大。开箱即用这个特性用到的频率并不高。

从你的情况看,如果 tomcat 的配置不常改,而且两个环境每次上线是按顺序使用的(如用完第一个肯定会用第二个,固定顺序),那么用不用 docker 差异不会太大。但如果两个环境是相互独立,每次上线只会用其中一个,建议用 docker 便于确保两个环境的一致性,否则后面某个环境版本滞后,要升级到最新版会很痛苦。。。

孙高飞 回复

这倒是一个很好的建议! 我之前没有想到,基于这组基础镜像写dockerfile

孙高飞 回复

看到这么牛皮复杂的环境,一个人就爱答不理的就解决了,docker生产力效率确实是高。感谢!

windanchaos 回复

其实也没那么轻描淡写,前期封装这套体系的时候也是费了不少功夫的。前期打好基础了后面才能这么逍遥

孙高飞 回复

恩,前期的工作没有白做,真的很让人叹服,哈哈。综合考虑我们这的情况,我们这种量级加上对docker不熟,我觉得暂时还是先以实际运用和落地为首要目标,如果环境多余5个了,我再做docker化,趁着间隙期间,充点电。哈哈哈

个人的经验,docker适合打包一个复杂的测试环境,并且非常适合到处迁移和扩展。举三个例子:1、假设你的测试环境需要配置jdk1.7和python2.7,而测试服务器上的环境是jdk1.8和python3,而你又不能随便修改服务器上的配置(可能已经作他用),docker就比较方便了。2、假如你在A服务器搭了一套复杂的环境,某天需要同时在B服务器搭一套同样的环境,没有docker的话你只能从头来一遍了,特别是当A是ubuntu系统而B是centos系统,搭建相同的环境会让抓狂,而docker的话只需要一台docker pull命令即可。还有一种情况是某种测试环境可能几个月才用一次,你觉得留一台服务器比较好还是留一个docker镜像比较好?3、假如做压力测试的时候一台服务器压力不够,docker可以快速扩展到多台机器,而且可以保证环境完全一样。
其实我觉得docker还有一个好处,和git差不多,假如你在开发一个复杂的测试代码,随着不断更新和完善,产生了v1和v2版本,v1比较成熟,v2可能会有bug,再没有docker的情况下,如果v2发现了bug,想回退到v1,你们只能把代码切回v1,和其他的环境也切回v1,v1还v2切来切去是个大麻烦,特别是v1需要python2.7而v2需要python3.0的时候,如果使用docker,你只需要把v2实例删除,启动一个v1的实例就可以了,docker就是这么方便。

blueshark 回复

你用docker做压力测试和git类比的视角很独特,赞一个

使用一个技术,应该是你的业务遇到壁垒,而不是别人用什么你用什么。我不排斥新技术,比如apache的ignite非常好,有些业务场景非常实用。
但是docker没感觉有啥用,自己也搭建了使用了一下。可能我写shell写习惯了。用到docker的某种功能,花几分钟写个shell就完事了。弄个docker也要有人维护的,估计成本会稍小一些而已。
但是真的没啥必要,我们所在的公司20台服务器吧,创建环境、部署脚本加一起估计1000行?反正我是有两天就写完了。变成100台这脚本还能用不是?
PS:jenkins我也放弃了,jenkins如果你只是用来部署的话,有200行shell就足以替换掉jenkins了。半天的事,何必引入一个新的技术,随时可能出问题的技术。

大机器人 回复

在有限的人力状态下,新技术如果可以提高单位人员的生产力,应该是没有问题的。现在我们单位代码规模扩张的很厉害,有3个团队加起来40多号人,10个以上的子系统,都有构建发版的需求,使用jenkins+shell驱动,把工具交付出去,让他们自己玩,生产力解放了。

这个问题也困扰了我很久,断断续续的关注了docker的技术,领导似乎对docker很感兴趣,我虽然不排斥,但是也觉得没有必要。
我是公司唯一的运维,目前手上管理近百台的服务器,技术栈:java/php/前端,全部使用阿里云。
生产环境很单一,虽然不是以微服务的方式跑的,但是基本上各个模块也是分开的,生产环境中基本上只跑一个或者两个应用。
在云的环境中,我认为并没有使用docker的必要,我认为主要有几点:
一、云资源基本上是按需要开的,并不会出现过多的资源闲置,和传统的IDC不一样,需要购买很多的硬件资源备用,云资源的弹性伸缩也提供了硬件资源的扩容。
二、因为是按需开资源,所以基本上一台云服务器只跑一两个应用,也不存在资源抢占、环境变化或者环境不一致问题。(测试环境也在云上)
三、云资源提供的镜像的功能,也可以通过镜像生成各种环境。

我不知道在云环境中使用docker还有什么好处?可能是因为业务不够庞大和复杂,还没有体会到docker的好处,也可能我们是自有业务,没有交付给其他第三方用户的产品,所以体会不到docker的好处。

近期我们上了一个新的项目,这个项目需要交付给第三方用户,领导有意要使用docker交付,一个配置文件就能马上生成一个系统,听上去爽歪歪,但是不知道客户的接受程度如何。

但是如果交付的用户也是云环境的,我更偏向使用用镜像交付。

虽然这两天一直在学,除了一次编排到处运行的好处外,依然没有体会到docker的其他好处。

为了参加讨论特意注册了账号,还请各位大神不吝赐教。

大机器人 回复

本人的看法与你相同。确实,我觉得没有什么环境是部署脚本不能做的。

觉得docker的产生,还是跟分布式计算有关系。当你的一个同类的应用很多很多(商业上很成功,一个网站后台的同种的tomcat应用需要部署多份,做负载均衡,快速地分发到不同的服务器,那么确实用docker比vm要更快,更节省服务器资源)。但这只适合有一定规模的公司;或者说,适合那些向往着进入有一定规模公司的人,为了锤炼技术而在自己目前小一点的公司做技术尝试的人。

VM > Docker > 多tomcat + 多mysql+ 自动部署脚本 > 单一tomcat + 单一mysql组合 + 自动部署脚本

其实,组合技术有千千万万种。没有最优,只有适合自己的。。。任何事物都是一样。。。

windanchaos 关闭了讨论 07 Oct 13:20
windanchaos 重新开启了讨论 07 Oct 13:20
需要 Sign In 后方可回复, 如果你还没有账号请点击这里 Sign Up