Question

我有一个mongodb docker容器（从docker repo下载的库存）。它的日志大小不受约束（/var/lib.docker/containers/'container_id'/'container_id'-json.log）

这最近导致服务器填满，所以我发现我可以指示docker守护进程限制容器日志文件的最大大小以及分割后它将保留的日志文件数。（请原谅天真。这是一个工具环境，所以设置的东西是为了满足眼前的需求而经常缺乏规划）

停止容器是不可取的（尽管它不会带来世界末日），因此这样做可能是一个合适的计划G.

通过实验，我发现运行同一个docker镜像的不同实例并在--log-opt max-size=1m --log-opt max-file=3命令中包含docker run可以很好地完成我想要的。

我了解到我可以将它包含在docker daemon.json文件中，以便它可以对所有容器全局工作。我尝试将以下内容添加到文件“/etc/docker/daemon.json”

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}

然后我向守护进程发送了一个-SIGHUP。我做了观察到守护进程的日志吐出了有关重新加载配置的内容，它提到了我进行编辑的确切文件路径。（注意：此文件以前不存在。我创建了它并添加了内容。）这对正在运行的Mongo容器的日志输出没有影响。

重新加载后台程序后，我还尝试再次实例化Mongo容器的不同实例，并且它也没有观察到守护程序应该具有的日志记录指令。我看到它的日志通过10米标记并继续前进。

我的问题是：

是否有办法更新通过守护程序进行日志记录以影响正在运行的容器？
如果没有，是否有办法告诉容器在运行时重新加载此信息？（我看到docker update但这似乎不是可以更新的配置选项之一。
我的配置有问题吗？我测试了包括一个荒谬的指令，看看错误是否会无声地失败，它们没有。不在架构中的指令在守护程序的日志中引发了错误。这表明我添加的内容（上面显示的内容）至少是预期的，尽管可能是不完整的或其他内容。这些命令似乎在run命令中有效，但在配置中却没有。另外，我最初尝试将“3”作为数字包括在内，也引发了一个错误，当我对其进行字符串化时就消失了。
我确实在文件“/var/lib.docker/containers/'container_id'/hostconfig.json”中看到了Mongo容器的不同实例，其中我在其中包含了指令运行命令，这些设置是可见的。为Mongo容器的生产实例手动编辑此文件以匹配不同概念验证容器的配置是否有效/安全？

请参阅下面的一些系统详情：

Docker版本1.10.3，版本20f81dd
Ubuntu 14.04.1 LTS

我的主要目标是了解为什么全局配置似乎不起作用，以及是否有办法在不中断它的情况下对正在运行的容器进行此更改。

提前感谢您的帮助！

Answer 1

更改daemon.json以运行容器对我不起作用。在编辑/etc/docker/daemon.json之后，重新加载守护进程并重新启动docker，但仅适用于新容器。

docker-compose down
sudo systemctl daemon-reload
sudo systemctl restart docker
docker-compose up -d

Answer 2

此设置将是新创建的容器的新默认值，即使重新启动它们也不是现有容器。新创建的容器将具有新的容器ID。我之所以强调这一点，是因为许多人（包括我自己）试图在不先删除该容器（他们可能已经创建了宠物）的情况下更改现有容器的日志设置，并且在docker中没有受支持的方法。

不必完全停止docker引擎，您只需运行reload命令即可应用此更改。但是，在没有简单的重新加载选项的情况下，某些运行docker的方法（例如桌面环境和基于Docker的Docker中的Docker）可能需要重新启动引擎。

此设置会将json文件限制为3个单独的10兆文件，即介于20到30兆之间的日志，具体取决于文件中第三个日志的位置。填充第三个文件后，将删除最旧的日志，使您回到20兆，在其他日志中进行轮换，然后启动新的日志文件。但是json有很多开销，在我的测试中约为50％，这意味着您将获得大约10-15兆的应用程序输出。

请注意，此设置只是默认设置，任何容器都可以覆盖它。因此，如果看不到任何影响，请仔细检查容器的启动方式，以确认没有日志选项在那里传递。

Docker daemon.json日志配置无效

2 个答案: