如何使用Docker、Docker-Compose和Rancher搭建部署Pipeline（三）

在这一部分，我们将一步步的走进Rancher，细致的探讨Rancher将如何解决在部署与容器管理时出现的种种的问题。回顾教程的第二部分，你会发现我们已经将应用的部署迁移至Docker Compose，并且已经建立了一系列工作步骤来部署我们的应用。这将使得开发人员能够轻松的对他们的应用部署逻辑进行修正，运维人员也可以查看应用的部署时间。当然，在上一个部分教程的一系列操作中，也存在一些显而易见的问题需要解决。

使用Docker-Compose时面临的挑战

首先，运维人员必须手动地调整所有服务的执行计划。部署人员需要决定将哪一个应用部署至哪一台主机，这意味着部署人员需要时刻对每一台主机的剩余可用资源都有了解，如果某一台主机或者容器崩溃了，部署的操作人员将需要对应用进行重新部署。实际生产中，这意味着主机常常处于负载失衡的状态，并且服务在崩溃之后需要很长时间才能得到恢复。

其次，使用Docker-Compose时，想要获得你的服务的当前状态是十分困难的。举个例子来说，我们经常会从运维人员、项目经理以及开发者口中听到这样的问题：“现在部署环境中运行的到底是XX应用程序的哪个版本？”如果我们采用的是手动调整服务的执行计划的方式，想要得到这个问题的答案通常需要询问指定的进行操作的工程师，工程师们需要登陆服务器并运行docker中的ps命令来查看容器的信息。然而面对这些问题，Rancher将会给我们提供极大的便利：每个人都可以非常容易地获取已经部署的服务的信息，而不需要临时请求运维人员的帮助。

使用Rancher之前，我们试着了解过不少其他能够管理Docker主机或集群的解决方案。然而这些解决方案都没有注意到这是对Docker主机或集群在多种环境（multi-environment）下的管理，这将成为最大的麻烦与负担之一。如果有服务以不同的负载运行在8种不同的环境下，我们需要的是一个统一的方式来管理集群，而不会想要访问8个不同的服务。并且，我们希望让重新构建环境对于我们而言，变成分分钟就能完成的任务，这样开发者就可以随意地更改开发环境。然而，对于生产环境而言，我们希望提供给他们的只是有限的只读访问权限。面对这样的需求，一个采用基于角色的访问控制（RBAC）模型的集中管理方案就显得十分必要了。我们最初决定尝试Rancher就是因为它在部署上非常简单。

当Rancher面临这些挑战

在短短半天的时间里，使用AWS ELB、Elasticache、RDS和现有的Docker主机，我们已经将Rancher部署好并成功运行。能够方便地配置认证信息也是Rancher的优点之一。

我们并不会深入Rancher本身部署的细节，Rancher部署文档中已经说的很明白了。相反，我们将从刚刚完成初始设置那一步开始，说明将如何将原有的设置（教程第一部分和第二部分中所提及的）迁移进来。

我们就从创建不同的环境开始吧，为了使得这个过程尽量简单些，我们将对开发环境（dev）、部署环境（stage）以及生产环境（prod）分别进行设置。每个环境都已有运行在Ubuntu之上的Docker主机，且这些Docker主机是由内部的Ansible配置的，Ansible安装了Docker、我们的监控代理、并进行了一些组织特定的更改。在Rancher上，你只需要运行一条命令，将Docker主机在Rancher server内部进行注册，就可以将已有的Docker主机添加至每个环境中。

添加一台Rancher主机

在大多数情况下