Liberty Admin Center将Docker服务器显示为正在运行，而不是

我在Ubuntu x64上使用Liberty 16.0.0.2。 当我使用REST在另一台主机上部署远程Liberty Docker容器时，它全部可用，但是当我手动停止这些远程容器（使用docker stop xxx命令）时，pipe理中心仍然显示这些容器正在运行，即使重新启动集合控制器后也是如此。

我已经为我的Docker容器定义了自动缩放，并且由于策略而导致某些容器被停止，但是一些真正运行的容器在pipe理中心中显示为已停止。 这里是正在运行的容器列表：

 $ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES fb59f94cd25b liberty_img "/opt/ibm/wlp/bin/ser" 41 minutes ago Up 41 minutes liberty_container11 5fd2d5858f60 liberty_img "/opt/ibm/wlp/bin/ser" 42 minutes ago Up 42 minutes liberty_container10 98117dac4f69 liberty_img "/opt/ibm/wlp/bin/ser" 42 minutes ago Up 42 minutes liberty_container9 cdce71905081 liberty_img "/opt/ibm/wlp/bin/ser" 8 hours ago Up 3 hours liberty_container6 

以下是pipe理中心显示的内容（注意容器5和11）：

如何解决这个问题，以便控制器发现我的Docker容器的正确状态？

messages.log文件已附加 ，但是在这里我没有看到任何有趣的内容。

Answer 1

由于您直接执行docker stop命令，集合成员基本上被终止，所以它不会向控制器报告它正在被停止。 因此，控制器报告该服务器的最后已知状态（由该服务器向控制器发布;成员将信息推送给控制器）​​。 非dockerLiberty成员的这一行为也是如此，他们的进程被杀死（而不是“正确的”删除）。

如果docker成员被serverCommands mbean（通过pipe理中心，swagger，java，jconsole，JMX REST连接器等等）或通过'/ wlp / bin ./server stop {memberName}'命令停止，你不应该看到这个问题，因为成员会首先向控制器报告它正在停止。 由于它与您的环境有关，所以我会注意到，如果要通过pipe理中心停止/启动/重新启动自动调整的服务器，则首先需要从该成员中删除自动调整function，或者将该成员置于维护模式。

为了回到你的集体的正确的状态，你只需要等到心跳超时到达成员三次（心跳默认值是60秒，所以总共3分钟），之后控制器应该标记为停止（因为在约定的时间内没有收到）。 或者，您可以启动成员备份，然后“正常”停止它们（这可以通过pipe理中心将停止的成员置于维护模式（正弦，他们被自动调整），然后select“重启”来启动成员备份，然后“停止”停止，然后可以删除维护模式）。

Answer 2

重要的是要注意，控制器反映了它所知道的成员的状态。 所以，如果一个成员join，但之后无法与控制器通信，它将显示为已停止，因为控制器从未收到来自成员的信息。 就控制器而言，停止。

对于没有出现在AdminCenter中但在存储库中的成员，我怀疑存储库中的内容不完整。 我相信还有另外一个问题报告，其中重复使用相同的容器名称导致这样的行为。 由于预先存在的数据，容器与控制器的连接实际上失败了。 这是可能的在你的情况？