Docker Swarm系列第二部：重新调度Redis

摘要：今天，我们将关注如何部署容器并测试当前实验性重新调度功能的当前状态。注意重新调度尚处于实验阶段，其中存在。但也确实有部分用户指出重新调度机制并未生效，或者是在主机恢复后出现了两套容器。

欢迎回来，我们继续本系列的第二篇教程。今天我们将主要关注Redis，希望大家还记得第一部分的主要内容——了解如何安装我们将要使用的环境。

传送门： Docker Swarm系列第一部：利用Flocker部署多节点Cassandra集群

如果大家认真阅读了第一部分，应该记得我们在Swarm部署中使用了--experimental标记。其中包括Swarm 1.1.0中的一项功能——在节点故障时对容器进行重新调度。

今天，我们将关注如何部署Redis容器并测试当前实验性重新调度功能的当前状态。

注意：重新调度尚处于实验阶段，其中存在bug。我们将在示例过程中的对应位置提醒大家可能出现的bug。

如果大家希望在Swarm主机发生故障时对容器进行重新调度，则需要在容器部署中使用特定标记。作为可行方案之一，我们可以使用以下标记：--restart=always -e reschedule:on-node-failure或者类似于-l "com.docker.swarm.reschedule-policy=["on-node-failure"]"的标签。以下示例将使用环境变量方法。

首先，我们使用重新调度标记与由Flocker管理的分卷进行Redis容器部署。

接下来，利用SSH接入Docker主机内的Redis容器运行位置，并查看Redis始终使用的appendonly.aof文件内容。该文件应当位于Flocker分卷中，作为容器起始点存在且不包含任何数据。

然后接入Redis服务器并添加一些键/值对。而后，再次查看appendonly.aof文件内容以确保Redis以正确方式存储数据。

在Flocker分卷中查看数据以验证Redis正确运行。

现在我们将测试故障转移场景，确保我们的Flocker分卷能够将存储在Redis中的数据正确迁移至Swarm重新调度容器的新Docker主机上。

要实现这一目标，我们在Swarm管理器中指定Docker，并利用docker events命令监控各项事件。

要开始测试，首先在运行有Redis容器的Docker主机上运行shutdown -h now以模拟节点故障。大家应该看到与该节点及容器相关的各项事件。

这些事件在告知我们，该容器及其资源由于遭遇故障（包括网络与分卷）需要被移除、断开连接或者卸载。我们看到的事件如下：

Container Kill
Container Die
Network Disconnect
Swarm Engine Disconnect
Volume Unmount
Container Stop

在Docker主机关闭一段时间之后，大家应该会最终看到故障容器正在进行重新调度（即重新创建）。在这里需要提醒的是，在测试中我们发现Swarm 1.1.3版本中仍然存在问题，即其仍然会在被创建在新Docker主机上的容器中运行 Start 。

大家应该会在查看到Create事件记录的同时发现docker events，而后者的作用是对容器重建以及Flocker分卷移动进行初始化。

我们发现，大家可能需要在重新调度完成后，在新主机上手动Start该容器。

注意：容器创建过程中存在一些问题，但在测试中我们并未在容器启动时发现问题。

此事件代表着我们的容器已经经过重新调度并自动创建于新的Docker主机之上。请注意，最新信息中的IP地址发生了变化，这是因为容器被调度到了新的Docker主机中。

下面来看流程回顾：

如果我们对Swarm运行docker ps，则会看到该Redis容器为Created。在这种情况下，我们可以手动进行启动，而Redis也将恢复并运行在新节点上。

下面接入该Redis服务器以确保我们添加的数据仍然存在。

数据仍然存在！不过考虑到重新调度情况，我们不建议大家直接使用这些数据。

在测试当中，大部分用户反映容器能够在新节点上正常启动。但也确实有部分用户指出重新调度机制并未生效，或者是在Docker主机恢复后出现了两套容器。无论如何，工作当中显然还存在着问题，而社区的作用也正在于此——帮助测试、报告并修复这些问题，从而确保其运行效果更为可靠。