我们为什么需要docker

      有业务开发、测试、运维经历的同学可能会有所共鸣,像测试环境调试、线上资源扩容等工作往往会成为系统上线的最后一道坎,甚至说是最难缠的噩梦也不为过。作为开发经常会想,我代码写的没问题呀,为啥发到测试环境全是错,甚至连系统都启动不了。测试同学面对错综复杂的环境问题,同样也会束手无策,各种环境、hosts等交叉起来就像蜘蛛网一样剪不断理还乱。对于运维同学估计也是不堪其扰,环境有一点问题,估计都会找到运维同学这边来,运维也不得不安排1,2个人,甚至是更多人员来专门处理这种环境问题。
环境问题就像一个紧箍咒戴在开发、测试、运维的头上,严重制约着技术人员的生产力。有没有银弹可以解决这个问题呢?我想,或许有,如果有的话那就将会是docker。之前研究消息队列来解决服务之间异步处理问题,接下来研究spring cloud来解决架构问题并封装了容器,当然这两个部分还有更深入研究的价值,不过这不是本文讨论的重点。本文的重点将在docker上,利用docker可以做到封装环境,来彻底解决测试环境以及系统扩容等问题。这样可以做到带着环境一起交付,将开发、测试和运维同学从环境调试中彻底解放出来。
      docker是一种轻量级容器管理引擎,和虚拟机不同的是,虚拟机虚拟运行于硬件之上,而docker运行在操作系统内核上的用户空间中。由于这个原因,docker只能运行与宿主机相类似的操作系统,不过这往往不是一个问题,实际中很少有需求需要虚拟不同的操作系统。得益于现代linux内核的一些特性,如cgroup、命名空间等,docker和宿主机以及不同的docker实例之间的隔离也可以做到比较彻底,每个docker实例都会有独立的网络和存储栈,还有独立的资源管理能力,这使得同一台宿主机中的不同docker实例都可以友好共存。
      docker的设计目标就是要加强开发人员写代码的开发环境和应用程序部署的测试环境以及在线环境的一致性,降低“开发一切正常,部署就出问题”这一风险。docker改变了咱们传统代码交付的概念,现在开发人员完成开发工作实际上交付的是代码,这里边最大的问题其实就是执行环境的问题,这使得技术人员不得不花大量精力来解决环境而导致代码执行出现的各种问题。而依赖的执行环境是无法控制的,不能标准化的。而Docker可以将代码和其执行的环境绑定在一起,以镜像形式交付。让开发完成的代码在标准的容器中,在标准的环境下执行。个人感觉这是革命性的一个改进,将大大改进现有的开发->测试->上线流程。相信无论是开发人员、测试人员还是运维人员都会爱上它,通过发布完成的镜像,与其他服务集成,使得开发流程自动化。在服务部署方面,无需再对配置进行变更,所谓的发布就是销毁这个服务并重建一个,而由于这样的操作,使得线上扩容也不再是一个问题。使用docker线上扩容则几乎不需要测试,因为每次扩容的过程就是发布时进行的操作。
      在现有的技术栈中引入docker是一项挑战性的工作,这需要开发、运维、测试等技术人员的共同推动以及转换现有的工作思路。但越艰难的事情越值得去做,收获也会越大。我想我们准备好了,那么就从现在开始吧~

3 个评论

真不错,我以前就听过docker,但是具体什么作用还真是一知半解,现在明白多了!
感谢分享,现在我们公司就被环境困扰,最怕的就是机房当机或者停电,总会出现一些奇葩问题,目前公司有本地开发环境,开发环境,测试环境,集成环境,预生产环境,线上环境,偶尔会冒出一个性能测试环境或者培训环境,想想都可怕。
目前用不上docker,而且也没觉docker得在我们的场景下会解放生产力

要回复文章请先登录注册