我们内网打算部署 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 用得很深的同学拍砖,给点建议。
恩,可能你现在还没有感受到 docker 的好处,这也挺正常的。刚开始接触 docker 的人多多少少都会有这个想法的。 你可以想象一下, 现在你们只有 2 套测试环境,环境也不复杂,没有多少服务,所以用 jenkins+shell 是没问题的。 如果你的环境数量扩大 10 倍,20 倍,30 倍,甚至 100 倍的话,纯虚拟机 +shell 还管不管的过来呢?模块更新的时候, 环境依赖变更的时候,服务挂掉的时候, 甚至是环境迁移的时候 (由于某种原因该服务器下线或者迁移到其他机房,这期间难道环境就这么不可用不管了么?) 还有所有这些环境的配置管理和服务发现怎么办?运维成本会变成一个噩梦,有多少人都会累的像条狗。所以这时候 docker+ 容器编排框架就体现出了无穷的优势,只要有镜像,可以迅速更新所有的环境,增容扩容也很简单,同时监控,容灾,持久化等等都做的好好的。 以你现在测试环境的规模确实是很难感受到 docker 的好处的,在这种体量下用 docker 还是虚拟机都无所谓,区别不大。
我现在用 docker+k8s 管理着一个容器集群,高峰期七八十套环境共存,加上测试服务,监控,集群管理,测试执行机器也在这里面跑着。 而运维的人只有我一个,而且我还是带搭不惜理的管着 (我平时有测试任务和开发任务)。 这时候就体现出了 docker 的巨大优势和其强大的生态圈,k8s 的自动化运维做的很强,所以我才可以这么悠闲的管着这么多环境。
其实除了部署和管理的便利性,docker 还有一个大的好处是开箱即用。以前我们往线上发布的是 war 包,服务器测试运维各管各的,用了 docker 以后发布的就是一个完整的容器,使用统一的镜像就可保证所有环境参数测试环境和线上是一致的,所以说容器的特性天生就符合持续交付的要求,当然前提你线上也已经开始用 docker。如果只是两三台服务器,线上也没有用 docker,我觉得用 shell 也差别不大,但对 docker 的技术必须保持关注,毕竟这个是大势。
我最近也用 docker 将我们整个大数据环境迁移到了 docker 容器里。不过我不是将每个服务制作成一个镜像,然后去用 k8s 编排。主要是因为大数据的服务组件实在太多,而大数据有自身的部署工具 ambari,我是借助了 ambari,先启用一堆基础容器(debian),利用 ambari 在这些容器内部署各个大数据组件,然后将各个容器 commit 成镜像,出来一套容器镜像套件。然后用了 Swarm 去做容器跨主机的调度,监控用的是 Rancher。这些工作都是一个人在搞,不知道飞哥能不能给我这种方式一些点评和指导。
目前整个集群也是支持多环境的并行,利用的是 swarm 的 label 来区分不同环境。各个环境利用 docker 的跨主机通信机制,搭建自己的私有 overlay 网络。
个人的经验,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 就是这么方便。
如果你有多个环境,或者频繁需要启用一个临时环境时,用 docker 维护起来方便很多,也更容易确保环境配置的一致性。docker 本身的一个目标是开发、测试、生产都采用相同的配置,减少因为环境差异(如服务版本、系统版本等)引起的问题和风险。
如果是固定环境,或者环境数量少,我觉得差异不大。开箱即用这个特性用到的频率并不高。
从你的情况看,如果 tomcat 的配置不常改,而且两个环境每次上线是按顺序使用的(如用完第一个肯定会用第二个,固定顺序),那么用不用 docker 差异不会太大。但如果两个环境是相互独立,每次上线只会用其中一个,建议用 docker 便于确保两个环境的一致性,否则后面某个环境版本滞后,要升级到最新版会很痛苦。。。
恩,前期的工作没有白做,真的很让人叹服,哈哈。综合考虑我们这的情况,我们这种量级加上对 docker 不熟,我觉得暂时还是先以实际运用和落地为首要目标,如果环境多余5个了,我再做 docker 化,趁着间隙期间,充点电。哈哈哈
在有限的人力状态下,新技术如果可以提高单位人员的生产力,应该是没有问题的。现在我们单位代码规模扩张的很厉害,有 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 组合 + 自动部署脚本
其实,组合技术有千千万万种。没有最优,只有适合自己的。。。任何事物都是一样。。。
谢谢。我也知道 dockerfile 绝对是更好的方式,但是我们这种好像没办法用 dockerfile 来搞。因为没办法去制作单独的容器镜像,只能通过 ambari 界面化的 ui 部署工具,一体化地部署一堆组件,让 ambari 去处理各个组件之间的依赖关系。。。也考虑到 commit 的方式会让容器的体积越发庞大,所以我们只能基于此制定了一套镜像升级规范来约束镜像升级操作
使用一个技术,应该是你的业务遇到壁垒,而不是别人用什么你用什么。我不排斥新技术,比如 apache 的 ignite 非常好,有些业务场景非常实用。
但是 docker 没感觉有啥用,自己也搭建了使用了一下。可能我写 shell 写习惯了。用到 docker 的某种功能,花几分钟写个 shell 就完事了。弄个 docker 也要有人维护的,估计成本会稍小一些而已。
但是真的没啥必要,我们所在的公司 20 台服务器吧,创建环境、部署脚本加一起估计 1000 行?反正我是有两天就写完了。变成 100 台这脚本还能用不是?
PS:jenkins 我也放弃了,jenkins 如果你只是用来部署的话,有 200 行 shell 就足以替换掉 jenkins 了。半天的事,何必引入一个新的技术,随时可能出问题的技术。
挺好的,够用就行,其他的服务不用都追求极致。 根据你们的需求来就行。 swarm 我当初只是在调研方案的时候搞过一个单节点的出来,了解的不深,不知道加一些容灾,持久化,7 层路由等需求是不是特别麻烦。k8s 是自带就有这些方案的。 不过你们测试环境体量没那么大的话也没必要搞这些。够用就好。就是尽量别 commit, 能做 dockerfile 还是用 dockerfile 比较好。以防以后环境变化的时候会很麻烦