云原生之容器编排-Docker Swarm

1. 前言

        上一篇我们讲到Docker Compose可以定义和运行多容器应用程序，用一个YAML配置文件来声明式管理服务，在一台安装了Docker engine的Linux系统上可以很好的工作，但是现实中不可能只有一台Linux系统，一台Linux系统不可能有足够的资源运行所有的云原生应用系统，为了支撑整个业务平台，势必要在很多台Linux系统运行云原生应用系统，共同组成一个容器集群，Docker Compose工具并不能管理这样的容器集群，势必有新工具出现。

        开源界管理容器集群的系统一般叫作容器编排系统，主要有三个系统：Docker Swarm、Mesos、Kubernetes。当然众所周知，Mesos背后的支撑公司已经出现了问题，Docker Swarm也是有气无力的状态，只有Kubernetes如日中天，成为事实上的标准。

        既然Kubernetes是事实上的标准，为什么四年前我还是选择了Docker Swarm？基于简单的三个理由：

1.  系统的规模：我们的最大客户线上环境只有几十台Linux服务器，100台物理机都不到，其实也不是所有机器都安装容器集群，存储系统和大数据集群也占了一少部分机器。最小的客户线上环境才10几台Linux服务器，规模就更小了。Docker Swarm足够管理这点容器集群了，一直以来运行基本没出现过问题。
2.  操作的复杂度：K8s从安装到运维技术复杂性众所周知，而Docker Swarm本身就集成进Docker Engine中，操作相对来说算非常简单了，中小公司只有少量的运维人员，而且技艺也不够精，选择Docker Swarm就显得更为适合了。
3.  内网的问题：大部分在互联网工作的企业，安装什么软件都非常方便，但是少部分安全行业，系统都是部署在严格控制的内网环境里，绝对不能访问外部互联网、移动互联网等，只有一条只准进不准出的FTP通道给企业发包使用。在这样的环境下，大部分Linux服务器已经存在，不可能搬出来到外网安装软件了，如果我们安装K8s难度有多大不可而知，但是我们用二进制包去安装Docker Engine，部署Docker Swarm，整个过程非常顺利。

        所以我推荐选择Docker Swarm而不是K8s，如果你的真实系统环境和我差不多的话，不要给公司运维人员带来额外的技术债务。

2. Docker Swarm简介

        从Docker Engine 1.12版本开始，Docker Swarm已经包含在其中了，负责容器集群管理和编排。下面列举一下Docker Swarm有哪些特性：

• 集群管理功能直接整合进Docker引擎中：不需要额外单独安装容器编排软件，操作命令直接集成进docker工具里，降低了学习曲线。
• 去中心化设计：在运行时处理任何特殊化，而不是在部署时，也就是部署时不需要管不同角色的节点问题，你能使用Docker engine提供的工具，同时部署managers和works两种类型的nodes。反正我们用docker swarm提供的命令对管理节点和工作节点进行操作即可。
• 声明式服务模式：Docker引擎使用声明性方法来定义应用程序栈中各种服务的所需状态，一般就是在编排文件docker-compose.yml里定义各种状态参数，如容器数量。
• 弹性：对每一个服务，你都可以在编排文件中定义它容器运行的数量，当你增加或减少编排文件里服务的容器数量时，swarm管理功能会自动增加和删除运行容器的数量，不需要人工干预。
• 期望状态的调节功能：管理节点一直监控着集群的运行状态&#x