从运行Docker Swarm集群中任何地方的所有容器转发日志

在本文中，我们将讨论一种从群集内的作为Docker Swarm服务创建的容器中转发日志的方法。 我们将使用ELK堆栈。 它们将从容器转发到LogStash，再从那里转发到ElasticSearch。 一旦进入数据库，它们将可以通过Kibana获得。

环境设定

我们将从创建一个Docker Swarm集群开始。 我将假设您已经至少具有Docker Swarm Mode如何工作的基本知识，并且知道如何创建Docker服务。 如果不这样做，建议您阅读Docker Swarm简介（在Docker 1.12系列中游览）文章或获取DevOps 2.1 Toolkit：Docker Swarm一书。

其中一些文件将在主机文件系统和我们即将创建的Docker Machines之间共享。 Docker Machine在VM内部提供了属于当前用户的整个目录。 因此，请确保将代码克隆到用户的一个子文件夹中。

Windows用户注意事项

建议从Git Bash （通过Docker Toolbox以及Git安装）运行所有示例。 这样，您将在整本书中看到的命令将与应在OS X或任何Linux发行版上执行的命令相同。

git clone https://github.com/vfarcic/cloud-provisioning.git

cd cloud-provisioning

scripts/dm-swarm.sh

我们克隆了cloud-provisioning资源库，并执行了创建生产集群的scripts / dm-swarm.sh脚本。

让我们确认集群的创建确实正确。

eval $(docker-machine env swarm-1)

docker node ls

node ls命令的输出如下（为简洁起见，删除了ID）。

HOSTNAME  STATUS  AVAILABILITY  MANAGER STATUS
swarm-2   Ready   Active        Reachable
swarm-1   Ready   Active        Leader
swarm-3   Ready   Active        Reachable

现在，生产集群已启动并正在运行，我们可以创建ELK服务。

scripts/dm-swarm-services-elk.sh

而已。 我们应该在Swarm集群中运行一些服务。 让我们仔细检查一下。

docker service ls

输出如下（为简洁起见，删除了ID）。

NAME            REPLICAS  IMAGE                               COMMAND
swarm-listener  1/1       vfarcic/docker-flow-swarm-listener
logstash        1/1       logstash:2.4                        logstash -f /conf/logstash.conf
elasticsearch   1/1       elasticsearch:2.4
kibana          1/1       kibana:4.6
proxy           1/1       vfarcic/docker-flow-proxy

最后，我们准备探索如何将日志从我们的Swarm服务发送到LogStash，再从那里发送到ElasticSearch。

将日志转发到LogStash

无论它们在哪里运行，我们如何从所有容器中转发日志？ 一种可能的解决方案是配置日志记录驱动程序 。 我们可以使用--log-driver参数为每个服务指定一个驱动程序。 驱动程序可以是syslog或任何其他受支持的选项。 那将解决我们的日志传送问题。 但是，对每个服务使用该参数很繁琐，更重要的是，我们很容易忘记为一个或两个服务指定参数，只有在遇到问题并且需要日志后才发现遗漏。 让我们看看是否有另一个选项可以完成相同的结果。

我们可以在每个节点上将日志驱动程序指定为Docker守护程序的配置选项。 这肯定会使安装更容易。 毕竟，服务器可能少于服务。 如果要在创建服务时设置驱动程序或作为守护程序配置之间进行选择，我会选择后面的一种。 但是，到目前为止，我们无需更改默认的守护程序配置就可以做到这一点，我希望在不涉及任何特殊配置工具的情况下继续工作。 幸运的是，我们仍然没有穷尽所有选择。

我们可以使用名为logspout的项目从所有容器中运送日志。

LogSpout是在Docker内部运行的Docker容器的日志路由器。 它附加到主机上的所有容器，然后将它们的日志路由到我们想要的任何位置。 它还具有可扩展的模块系统。 这是一个大多数无状态的日志设备。 它并不用于管理日志文件或查看历史记录。 它只是一种使您的日志移至它们所属的其他地方的工具。

如果浏览项目文档，您会发现没有说明如何将其作为Docker服务运行。 这无关紧要，因为到此时，您可以认为自己是创建服务的专家。

我们需要从转发集群中所有节点内运行的所有容器的日志的服务中获得什么？ 由于我们要将它们转发到已经连接到elk网络的LogStash，因此我们也应该将LogSpout附加到它。 我们需要它从所有节点发送日志，因此服务应该是global 。 它需要知道目的地是称为logstash的服务，并且它在端口51415上进行侦听。 最后，LogSpout的要求之一是将主机的Docker套接字安装在服务容器内。 它将使用它来监视日志。

创建满足所有这些目标和要求的服务的命令如下。

docker service create --name logspout \
    --network elk \
    --mode global \
    --mount "type=bind,source=/var/run/docker.sock,target=/var/run/docker.sock" \
    -e SYSLOG_FORMAT=rfc3164 \
    gliderlabs/logspout syslog://logstash:51415

我们创建了一个名为logspout的服务，将其附加到elk网络，将其设置为global ，并安装了Docker套接字。 创建容器后将执行的命令是syslog://logstash:51415 。 它告诉LogSpout，我们要使用syslog协议将日志发送到logstash运行在端口51415 。

该项目是Docker Remote API背后有用性的一个示例。 logspout容器将使用它来检索所有当前正在运行的容器的列表并传输其日志。 这已经是我们集群中使用API​​的第二个产品（第一个是Docker Flow：Swarm Listener ）。

让我们看看我们刚刚创建的服务的状态。

docker service ps logspout

输出如下（为简洁起见，删除了ID）。

NAME          IMAGE                NODE     DESIRED STATE  CURRENT STATE          ERROR
logspout      gliderlabs/logspout  swarm-3  Running        Running 9 seconds ago
 \_ logspout  gliderlabs/logspout  swarm-2  Running        Running 9 seconds ago
 \_ logspout  gliderlabs/logspout  swarm-1  Running        Running 9 seconds ago

该服务以全局模式运行，从而导致每个节点内都有一个实例。

让我们测试logspout服务是否确实将所有日志发送到LogStash。 我们要做的就是创建一个服务，该服务生成一些日志并从LogStash的输出中观察它们。 我们将使用registry来测试到目前为止的设置。

docker service create --name registry \
    -p 5000:5000 \
    --mount "type=bind,source=$PWD,target=/var/lib/registry" \
    --reserve-memory 100m \
    registry

在检查LogStash日志之前，应等待registry运行。

docker service ps registry

如果当前状态仍未运行，请稍等片刻。

现在，我们可以看一下logstash日志，并确认logspout发送了registry生成的日志条目。

LOGSTASH_NODE=$(docker service ps logstash | tail +2 | awk '{print $4}')

eval $(docker-machine env $LOGSTASH_NODE)

LOGSTASH_ID=$(docker ps -q --filter "ancestor=logstash:2.4")

docker logs $LOGSTASH_ID

来自输出的条目之一如下。

{
           "message" => "time=\"2016-10-19T23:14:19Z\" level=info msg=\"listening on [::]:5000\" go.version=go1.6.3 instance.id=87c31e30-a747-4f70-b7c2-396dd80eb47b version=v2.5.1 \n",
          "@version" => "1",
        "@timestamp" => "2016-10-19T23:14:19.000Z",
              "host" => "10.0.0.7",
          "priority" => 14,
     "timestamp8601" => "2016-10-19T23:14:19Z",
         "logsource" => "c51c177bd308",
           "program" => "registry.1.abszmuwq8k3d7comu504lz2mc",
               "pid" => "4833",
          "severity" => 6,
          "facility" => 1,
         "timestamp" => "2016-10-19T23:14:19Z",
    "facility_label" => "user-level",
    "severity_label" => "Informational"
}

和以前一样，当我们使用logger测试LogStash输入时，我们具有message ， timestamp ， host和其他一些syslog字段。 我们还得到了logsource保存生成日志以及集装箱的ID program保存容器名称。 当调试哪个服务和容器产生错误时，两者都将非常有用。

如果返回到我们用来创建logstash服务的命令，您会注意到环境变量LOGSPOUT=ignore 。 它告诉LogSpout应该忽略服务，或更确切地说，构成服务的所有容器。 如果我们没有定义它，LogSpout会将所有logstash日志转发到logstash从而创建一个无限循环。 正如我们已经讨论的，在生产中，我们不应将LogStash条目输出到stdout 。 我们这样做只是为了更好地了解其工作原理。 如果从logstash配置中删除了stdout输出，则不需要环境变量LOGSPOUT=ignore 。 结果， logstash日志也将存储在ElasticSearch中。

现在，我们将所有日志都运送到LogStash并从那里运送到ElasticSearch，我们应该探索查阅这些日志的方法。 您将在kibana服务中找到它们。

open http://$(docker-machine ip swarm-1)/app/kibana

在离开之前，请确保删除我们创建的计算机，并释放您的资源来执行其他一些任务。

docker-machine rm -f swarm-1 swarm-2 swarm-3

您刚读完的文章摘自DevOps 2.1 Toolkit：Docker Swarm一书的“ 定义日志记录策略”一章。

DevOps 2.1工具包：Docker Swarm

如果您喜欢本文，则可能对DevOps 2.1 Toolkit：Docker Swarm一书感兴趣。 与本系列的前一篇文章（ DevOps 2.0工具包：使用容器化微服务自动化持续部署管道 ）提供了对一些最新DevOps实践和工具的总体了解不同，本书完全致力于Docker Swarm及其过程和工具。我们可能需要构建，测试，部署和监视集群中运行的服务 。

这本书仍在“发展中”。 您可以从LeanPub获取副本。 它也可以作为DevOps Toolkit系列软件包使用。 如果您现在下载它，请在其完全完成之前，获得有关新章节和更正的频繁更新。 更重要的是，您可以通过向我发送反馈意见来影响本书的发展方向。

我选择精益方法进行图书出版，因为我相信早期反馈是生产优质产品的最佳方法。 请帮助我，使本书成为任何想要采用Docker Swarm进行集群编排和调度的人的参考。

翻译自: https://www.javacodegeeks.com/2016/10/forwarding-logs-containers-running-anywhere-inside-docker-swarm-cluster.html