该系列文章分享了用Docker、Docker-Compose和Rancher完成容器部署工作流的经验。本文将探讨怎样运行Rancher，解决只使用Docker-Compose时面临的主机负载失衡、获取服务状态困难、多环境下主机与集群难以管理等的问题。
在这一部分，我们将一步步的走进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主机
在大多数情况下，想要添加一台主机需要经过一系列的操作：通过鼠标在网页上完成一些点击，接下来切换至某个特定的环境，最后在终端系统上输入命令。然而，如果你使用Rancher API，我们可以在Ansible工具的帮助下使得这一系列的操作转化为完全自动化的设置。出于好奇，在下面我们截取了playbook中有关这一操作的部分内容（大多是根据 Hussein Galas的repo中的内容做出的逻辑上的修改而得到的）。
name: install dependencies for uri module
apt: name=python-httplib2 update_cache=yes
name: check if the rancher-agent is running
command: docker ps –filter ‘name=rancher-agent’
register: containers
name: get registration command from rancher
uri:
method: GET
user: “{{ RANCHER_API_KEY }}”
password: “{{ RANCHER_SECRET_KEY }}”
force_basic_auth: yes
status_code: 200
url: “https://rancher.abc.net/v1/projects/{{ RANCHER_PROJECT_ID }}/registrationtokens”
return_content: yes
validate_certs: yes
register: rancher_token_url
when: “‘rancher-agent’ not in containers.stdout”
name: register the host machine with rancher
shell: >
docker run -d –privileged
-v /var/run/docker.sock:/var/run/docker.sock
{{ rancher_token_url.json[‘data’][0][‘image’] }}
{{ rancher_token_url.json[‘data’][0][‘command’].split() | last}}
when: “‘rancher-agent’ not in containers.stdout”
随着工作的一步步进行，我们已经完成了环境的创建并已经将主机在Rancher server中注册，现在就让我们来了解一下，如何将我们的部署工作流整合至Rancher中。我们知道，对于每一台Docker来说，其中都有着一些正在运行的容器，这些系统的部署是通过Ansible工具借助Jenkins完成的。Rancher提供了以下开箱即用的功能：
- 管理已有的容器（比如：启动、修改、查看日志、启动一个交互式的shell）
- 获得关于运行中的和停止运行的容器的信息（比如：镜像信息、初始化命令信息、命令信息，端口映射信息以及环境变量信息）
- 查看主机和容器层级上的资源使用情况（比如：CPU使用率、内存占用率、以及磁盘和网络的使用情况）
独立的容器
很快，我们就已经将Docker主机注册至Rancher Server中，现在我们可以查看容器在各种环境下的运行状态信息了。不仅如此，如果想要将这些信息分享给其他团队，我们仅仅需要针对某个环境给予他们一些有限的权限。通过以上的方式，在想要获得状态信息时我们就完全没有必要请求操作人员登录Docker主机，再通过人工的方式去查询，同时这样也减少了申请获得环境信息的请求的数目，因为我们已经将某些访问权限分配至各个团队了。举个例子来说，如果为开发团队分配环境信息的只读权限，那么将会在开发团队与部署操作团队之间架起一座沟通的桥梁，这样两个团队都会对这个环境的状态比以往更加的关心。在这个基础上，故障的排除也变成了一种小组间相互合作的过程，而不是以往的那种单向的、依赖同步信息流的解决方式，相互合作的方式也会减少解决突发事件的总时间。
到现在为止，我们已经将已有的Docker主机加入Rancher Server，并且基于已经阅读完了的教程的第一部分关于Jenkins和Rancher的内容，下一步，我们打算改进的部分是我们已有的部署流水线，我们将会对已有的部署流水线进行修改，以便于使用Rancher compose，Rancher Compose将代替之前Ansible工具提到的Docker compose。不过在我们深入下一部分之前，我们首先需要了解关于Rancher的应用、调度、Docker Compose和Rancher Compose的一些信息。
应用与服务：Rancher将每个独立的容器（指的是部署在Rancher之外的容器，或者是通过Rancher UI生成的一次性功能的容器）、应用和服务彼此分离开。简单地说，应用是一组服务，而所有容器都需要利用服务（关于应用和服务的内容之后将会由更加详细的介绍）以构建一个应用。独立的容器需要手动地进行调度。
调度：在之前的部署技术中，运维人员需要决定容器应当在哪一台主机上运行。如果使用的是部署脚本，那么意味着运维人员需要决定部署脚本在哪一台或哪几台主机上运行；如果使用Ansible，这将意味着运维人员需要决定哪些主机或组需要到Jenkins中工作。不论是哪一种方式，都需要运维人员去做一些决定，但是在大多数情况下，他们做出的决定都缺乏一些可靠的依据，这对我们的部署工作很是不利（比如说某一台主机的CPU使用率高达100%）。很多解决方案，比如像Docker Swarm、Kubernetes、Mesos和Rancher都采用了调度器来解决这类问题。对于需要执行的某个操作，调度器将会请求获得一组主机的信息，并判断出哪几台是适合执行这个操作的。调度器会根据默认的需求设定或者用户定义的特定需求，比如CPU使用率高低、亲和性或反亲和性规则（比如：禁止在同一台主机上部署两个相同容器）等类似的需求，以逐渐缩小主机选择的范围。如果我是一个负责部署的运维人员，调度器将会极大的减少我的工作负担（尤其是我在深夜加班忙于部署时），因为调度器对以上信息的计算比我快的多，也准的多。Rancher在我们通过应用部署服务的时候能够提供一个开箱即用调度器。
Docker compose：Rancher使用Docker compose来创建应用并定义服务。由于我们已经将服务转化为Docker compose的文件，我们在此基础上创建应用就变得容易了许多。应用可以手动的从UI界面中创建，也可以通过Rancher compose在命令行（CLI）下快速的创建。
Rancher compose：Rancher compose是一种通过命令行（CLI）让我们得以对Rancher中的每一种环境的应用和服务进行方便的管理的工具。同时，通过rancher-compse.yml文件，Rancher compose还能允许对Rancher工具进行一些其他访问。这是一个纯粹的附加的文件，将不会取代原有的docker-compose.yml文件。在rancher-compose.yml文件中，你可以定义以下内容，比如说：
- 每种服务的升级策略信息
- 每种服务的健康检查信息
- 每种服务的需求规模信息
这些都是Rancher中非常实用的亮点，如果你使用Docker Compose或者Docker daemon，这些内容你都是获取不到的。如果想要查看Rancher Compose能提供的所有特性，你可以查看这个文档
通过将已有的部署工作交给Rancher Compose来替代之前的Ansible工具，我们能够很轻松的将服务迁移并部署为Rancher应用的形式。之后，我们就能够去除DESTINATION参数了，但我们依然保留VERSION参数，因为我们在插入docker-compose.uml文件的时候还要使用它。以下是使用Jenkins部署时，部署逻辑的shell片段：
export RANCHER_URL=http://rancher.abc.net/
export RANCHER_ACCESS_KEY=…
export RANCHER_SECRET_KEY=…
if [ -f docker/docker-compose.yml ]; then
docker_dir=docker
elif [ -f /opt/abc/dockerfiles/java-service-1/docker-compose.yml ]; then
docker_dir=/opt/abc/dockerfiles/java-service-1
else
echo “No docker-compose.yml found. Can’t continue!”
exit 1
fi
if ! [ -f ${docker_dir}/rancher-compose.yml ]; then
echo “No rancher-compose.yml found. Can’t continue!”
exit 1
fi
/usr/local/bin/rancher-compose –verbose
-f ${docker_dir}/docker-compose.yml
-r ${docker_dir}/rancher-compose.yml
up -d –upgrade
阅读完代码段，我们可以发现其主要包括以下内容：
我们定义了以环境变量的方式如何访问我们的Rancher server。
需要找到docker-compose.yml文件，否则将会任务将会报错退出。
需要找到rancher-compose.yml文件，否则任务将会报错退出。
运行Rancher-compose，并告诉它不要block并且使用-d命令输出日志，使用-upgrade命令更新一个已经存在的服务。
也许你已经发现了，在绝大部分，代码的逻辑都是相同的，而最大的区别就是使用rancher-compose代替使用Ansible工具完成部署，并对每一个服务添加了rancher-compose.yml文件。具体到我们的java-service-1应用，docker-compose文件和rancher-compose文件现在是这样的：
docker-compose.yml
java-service-1:
image: registry.abc.net/java-service-1:${VERSION}
container_name: java-service-1
expose:
– 8080
ports:
– 8080:8080
rancher-compose.yml
java-service-1:
scale: 3
在开始部署工作之前，我们先回顾一下部署工作的流程：
- 开发人员将代码的修改推送至git上
- 使用Jenkins对代码进行单元测试，在测试工作结束之后触发下游工作
- 下游工作采用新的代码构建一个docker镜像，并将其推送至我们自己的Docker镜像仓库中
- 创建包含应用名、版本号、部署环境的deployment ticket
DEPLOY-111:
App: JavaService1, branch “release/1.0.1”
Environment: Production
- 部署工程师针对应用运行Jenkins的部署工作，运行时需要将版本号作为参数。
- Rancher compose开始运行，对于某个环境创建或更新应用，并且当达到所需规模的时候，结束这个工作
- 部署工程师以及开发工程师分别手动地对服务进行校验
- 部署工程师在Rancher UI中确认完成升级
关键点
使用Rancher进行我们的服务部署时，我们从Rancher内建的调度、弹性伸缩、还原、升级、和回滚等工具中获得极大的便利，使得我们在部署过程中没有花太大的力气。同时我们发现，在将部署工作从Ansible工具中迁移至Rancher的工作量也是很小的，仅仅需要在原有的基础上增加rancher-compose.yml文件。然而，使用Rancher来处理我们容器的调度意味着我们将难以确认我们的应用到底是在哪台主机上运行的。比方说，之前我们并没有决定java-service-1应用在哪里运行，对于后端，在进行负载均衡相关操作时，该应用就没有一个静态的IP。我们需要找到一种办法，使得我们的各种应用之间能够相互察觉到对方。最终，对于我们的java-service-1应用，我们将明确地将应用容器所在的docker主机的8080端口与应用绑定，不过，如果有其他服务与应用绑定为相同的端口，它将会启动失败。通常负责调度决策的工程师将会对以上的事务进行处理。然而，我们最好将这些信息通知调度器以避免这样的事情发生。
在本教程的最后一个部分，我们将继续探索一些方案来解决在使用亲和性规则、主机标签、服务探索以及智能升级和回滚等特性时出现的问题。
