这时虚拟机又怒了,我不用容器了,微服务拆分之后,用 Ansible 自动部署是一样的。
这从技术角度来讲没有任何问题,问题是从组织角度出现的。一般的公司,开发会比运维多得多,开发写完代码就不用管了,环境的部署完全是运维负责,运维为了自动化,写 Ansible 脚本来解决问题。
然而这么多进程,又拆又合并的,更新这么快,配置总是变,Ansible 脚本也要常改,每天都上线,不得累死运维。
所以在如此大的工作量情况下,运维很容易出错,哪怕通过自动化脚本。这时,容器就可以作为一个非常好的工具运用起来。
除了容器从技术角度,能够使得大部分的内部配置可以放在镜像里面之外,更重要的是从流程角度,将环境配置这件事情,往前推了,推到了开发这里,要求开发完毕之后,就需要考虑环境部署的问题,而不能当甩手掌柜。
这样做的好处就是,虽然进程多,配置变化多,更新频繁,但是对于某个模块的开发团队来讲,这个量是很小的,因为 5-10 个人专门维护这个模块的配置和更新,不容易出错。
如果这些工作量全交给少数的运维团队,不但信息传递会使得环境配置不一致,部署量也会大非常多。
容器是一个非常好的工具,就是让每个开发仅仅多做 5% 的工作,就能够节约运维 200% 的工作量,并且不容易出错。
然而原来运维该做的事情开发做了,开发的老大愿意么?开发的老大会投诉运维的老大么?
这就不是技术问题了,其实这就是 DevOps,DevOps 不是不区分开发和运维,而是公司从组织到流程能够打通,看如何合作,边界如何划分,对系统的稳定性更有好处。
所以微服务、DevOps、容器是相辅相成,不可分割的。不是微服务,根本不需要容器,虚拟机就能搞定,不需要 DevOps,一年部署一次,开发和运维沟通再慢都能搞定。
所以,容器的本质是基于镜像的跨环境迁移。
镜像是容器的根本性发明,是封装和运行的标准,其它什么 namespace,cgroup,早就有了,这是技术方面。
在流程方面,镜像是 DevOps 的良好工具。
容器是为了跨环境迁移的,第一种迁移的场景是开发、测试、生产环境之间的迁移。如果不需要迁移,或者迁移不频繁,虚拟机镜像也行,但总是要迁移,带着几百 G 的虚拟机镜像,太大了。
第二种迁移的场景是跨云迁移,跨公有云,跨 Region,跨两个 OpenStack 的虚拟机迁移都是非常麻烦,甚至不可能的,因为公有云不提供虚拟机镜像的下载和上传功能,而且虚拟机镜像太大了,一传传一天。
所以跨云场景下,混合云场景下,容器也是很好的使用场景。这也同时解决了仅仅私有云资源不足,扛不住流量的问题。
所以这是我认为的容器的本质,是最终应该使用容器的正确姿势,当然一开始你不一定完全按照这个来。