26 微服务容器化运维:镜像仓库和资源调度
专栏上一期我给你讲解了容器化技术解决了单体应用拆分为微服务后,所带来的服务测试和发布运维复杂度提升的问题,可以说容器化技术天生就是为微服务而生。但微服务容器化后又带来了一个新的挑战,那就是容器如何运维的问题。
为什么微服务容器化的运维又成了新问题?
对于大部分业务团队来说,在进行容器化以前,服务都是部署在物理机或者虚拟机上,运维往往有一套既有的运维平台来发布服务。我就以微博的运维平台JPool来举例,当有服务要发布的时候,JPool会根据服务所属的集群(一般一个业务线是一个集群)运行在哪个服务池(一般一个业务线有多个服务池),找到对应的物理机或者虚拟机IP,然后把最新的应用程序代码通过Puppet等工具分批逐次地发布到这些物理机或者虚拟机上,然后重新启动服务,这样就完成一个服务的发布流程。
但是现在情况变了,业务容器化后,运维面对的不再是一台台实实在在的物理机或者虚拟机了,而是一个个Docker容器,它们可能都没有固定的IP,这个时候要想服务发布该怎么做呢?
这时候就需要一个面向容器的新型运维平台,它能够在现有的物理机或者虚拟机上创建容器,并且能够像运维物理机或者虚拟机一样,对容器的生命周期进行管理&#