业务容器化后，运维面对的不再是一台台实实在在的物理机或者虚拟机了，而是一个个 Docker 容器，它们可能都没有固定的 IP，这个时候要想服务发布该怎么做呢？
这时候就需要一个面向容器的新型运维平台，它能够在现有的物理机或者虚拟机上创建容器，并且能够像运维物理机或者虚拟机一样，对容器的生命周期进行管理，通常我们叫它“容器运维平台”。
一个容器运维平台通常包含以下几个组成部分：镜像仓库、资源调度、容器调度和服务编排。
镜像仓库
Docker 容器运行依托的是 Docker 镜像，也就是说要发布服务，首先必须把镜像发布到各个机器上去，这个时候问题就来了，这个镜像该放在哪？如何把镜像发布到各个机器上去？这时候你就要依靠镜像仓库了。
镜像仓库的概念其实跟 Git 代码仓库类似，就是有一个集中存储的地方，把镜像存储在这里，在服务发布的时候，各个服务器都访问这个集中存储来拉取镜像，然后启动容器。
对于大部分业务团队来说，出于安全和访问速度的需要，都会搭建一套私有的镜像仓库。那么具体该如何搭建一套私有的镜像仓库呢？
1）权限控制
镜像仓库首先面临的第一个问题就是权限控制的问题，也就是说哪些用户可以拉取镜像，哪些用户可以修改镜像。
一般来说，镜像仓库都设有两层权限控制：一是必须登录才可以访问，这是最外层的控制，它规定了哪些人可以访问镜像仓库；二是对镜像按照项目的方式进行划分，每个项目拥有自己的镜像仓库目录，并且给每个项目设置项目管理员、开发者以及客人这三个角色，只有项目管理员和开发者拥有自己镜像仓库目录下镜像的修改权限，而客人只拥有访问权限，项目管理员可以给这个项目设置哪些人是开发者。
这个权限控制就跟大厦办公楼的管理类似，你要进入大厦里的一个办公室，首先必须具备进入大厦的权限，这个权限是在大厦里所有办公的人都有的。然后你还得具备大厦里你办公室所在楼层的门禁，这样才能进入办公室。不同楼层的人权限不同，只能进入自己楼层的办公室。如果某个办公室有新来的员工，首先要给他分配大厦的进入权限，然后还要这个办公室的管理员给他分配办公室的权限。
2）镜像同步
在实际的生产环境中，往往需要把镜像同时发布到几十台或者上百台集群节点上，单个镜像仓库实例往往受带宽原因限制无法同时满足大量节点的下载需求，这个时候就需要配置多个镜像仓库实例来做负载均衡，同时也就产生镜像在多个镜像仓库实例之间同步的问题了。
一般来说，有两种方案，一种是一主多从，主从复制的方案，比如开源镜像仓库Harbor采用了这种方案；另一种是 P2P 的方案，比如阿里的容器镜像分发系统蜻蜓采用了 P2P 方案。
Harbor 所采取的主从复制的方案是，把镜像传到一个主镜像仓库实例上去，然后其他从镜像仓库实例都从主镜像仓库实例同步，它的实现就像下图所描述的一样。
除此之外，Harbor 还支持层次型的发布方式，如果集群部署在多个 IDC，可以先从一个主 IDC 的镜像仓库同步到其他从 IDC 的镜像仓库，再从各个从 IDC 同步给下面的分 IDC，它的实现就像下图所描述的一样。
3）高可用性
既然 Docker 镜像是 Docker 容器运行的基础，那么镜像仓库的高可用性就不言而喻了。一般而言，高可用性设计无非就是把服务部署在多个 IDC，这样的话即使有 IDC 出问题，也可以把服务迁移到别的正常 IDC 中去。同样对于镜像仓库的搭建，也可以采用多 IDC 部署，那么需要做到的就是不同 IDC 之间的镜像同步。
比如镜像仓库会部署在永丰、土城两个内网 IDC 内，两个 IDC 内的镜像同步采用 Harbor 的双主复制策略，互相复制镜像，这样的话即使有一个 IDC 出现问题，另外一个 IDC 仍然能够提供服务，而且不丢失数据。
资源调度
Docker 镜像要分发到哪些机器上去？这些机器是从哪里来的？这其实涉及的是资源调度的问题。
服务部署的集群主要包括三种：
1、物理机集群。大部分中小团队应该都拥有自己的物理机集群，并且大多按照集群 - 服务池 - 服务器这种模式进行运维。物理机集群面临的问题，主要是服务器的配置不统一，尤其对于计算节点来说，普遍存在的一种情况就是几年前采购的机器的配置可能还是 12 核 16G 内存的配置，而近些年采购的机器都至少是 32 核 32G 内存的配置，对于这两种机器往往要区别对待，比如旧的机器用于跑一些非核心占用资源量不大的业务，而新采购的机器用于跑一些核心且服务调用量高的业务。
2、虚拟机集群。不少业务团队在使用物理机集群之后，发现物理机集群存在使用率不高、业务迁移不灵活的问题，因此纷纷转向了虚拟化方向，构建自己的私有云，比如以 OpenStack 技术为主的私有云集群在国内外不少业务团队都有大规模的应用。它的最大好处就是可以整合企业内部的服务器资源，通过虚拟化技术进行按需分配，提高集群的资源使用率，节省成本。
3、公有云集群。现在越来越多的业务团队，尤其是初创公司，因为公有云快速灵活的特性，纷纷在公有云上搭建自己的业务。公有云最大的好处除了快速灵活、分钟级即可实现上百台机器的创建，还有个好处就是配置统一、便于管理，不存在机器配置碎片化问题。
通过 Docker Machine 可以在企业内部的物理机集群，或者虚拟机集群比如 OpenStack 集群，又或者公有云集群比如 AWS 集群等上创建机器并且直接部署容器。Docker Machine 的功能虽然很好，但是对于大部分已经发展了一段时间的业务团队来说，并不能直接拿来使用。
这主要是因为资源调度最大的难点不在于机器的创建和容器的部署，而在于如何对接各个不同的集群，统一管理来自不同集群的机器权限管理、成本核算以及环境初始化等操作，这个时候就需要有一个统一的层来完成这个操作。这个对有历史包袱的团队，比如公司内网的物理机集群已经有一套运维体系来说，挑战不小，需要针对新的模式重新开发这套运维平台。
