如何在具有多个管理器/工作人员的生产 Docker swarm 集群中正确管理（访问/归档/轮换）日志，并且在任何情况下都不会丢失？

Question

背景/问题描述

在我的团队中，我们目前正在研究一种方法来替换我们的实际生产环境以进行容器化应用程序编排和管理。实际上，我们有一个运行 Docker 的独特虚拟机，其中包含一个简单（但很长！）

docker-compose.yml

文件，其中包含大约 10 个服务。

我们没有足够的时间也没有能力建立一个合适的 Kubernetes 集群（并在之后每天管理它），所以我们的选择是迁移到 Docker Swarm 集群，这是基本

docker-compose.yml

文件和真正的 Kubernetes 之间的中间解决方案集群，有 3 名经理和至少 3 名工人。

我们关于日志记录的问题如下：

对于某些应用程序，我们绝对需要能够归档并保存生成的所有日志。这些应用程序有一个副本（其背后有特定的业务原因），但是，了解 Swarm 的原理，副本可以随着时间的推移而移动。当副本被移动时，它实际上在原点被停止/杀死/销毁，并在其他节点上重新创建，同时丢失了第一个实例生成的日志。我们不希望这样。
对于其他一些人，我们将拥有多个副本，因此我们对一种正确的方法来管理来自不同实例的日志、将其一起或单独存档、如何命名这些文件、将其存储在何处（NFS挂载）感到尴尬、数据库、第三方应用程序）。

我们已经考虑了几种选择：

docker 服务日志命令正确合并来自不同运行副本的标准输出的日志，但不保留已终止副本的日志
将日志（同一应用程序的所有副本）写入共享文件夹（通过 NFS 或其他方式安装）中的单个文件会引发并发问题和文件损坏，这是我们不希望发生的事情
将日志（同一应用程序的所有副本）写入共享文件夹（通过 NFS 或其他方式安装）中每个副本的专用文件解决了并发问题，但我们面临文件命名问题（副本/任务 ID？）之后，服务能够自动清除旧日志历史记录（配置保留策略）
建立一个专门的解决方案来管理所有这些日志（如 Splunk、GrayLog 等）是一种可能性，但对于我们来说，对于我们的小型基础设施来说，这似乎有些过头了

因此，问题是存在所有这些限制：是否存在我们不知道的最佳实践、我们在某处遗漏的提示和技巧，或者其他简化日志管理的事情，涉及并发写入、一致性、多实例和需要绝对不丢失某些关键应用程序的任何日志？

Answer 1

首先，

docker service logs <service name or id>

将以任意顺序返回所有历史和当前任务的日志。所以你总是想生成一个任务列表，然后查询每个任务：

docker service logs <task id>

。

接下来，Docker 有许多日志驱动程序，可以在 daemon.json 中全局设置，也可以按服务/容器设置。该列表可以通过

docker info

找到，并包含许多可以保存日志的选项。

docker 在没有第三方组件的情况下支持的唯一日志系统是

local

和

json-file

日志，它们将日志存储在

/var/lib/docker/containers/<container-id>/**.log

中。当容器被修剪时，这些显然会被收获。

Base docker 不会自动修剪容器。另一方面，Docker swarm 跟踪活动和停止的任务及其容器，并具有定义它将保留多少任务/容器的任务历史记录。同样，

docker info

会告诉您这个限制，并且

docker swarm update --task-history-limit

可用于在运行的群体上更改它。每个副本应该有一个活动任务容器，以及任务历史限制历史容器的日志。