Docker 在守护程序重新启动后将新日志配置应用于所有容器

在守护进程重新启动后，

daemon.json

中的新配置是否可以应用于所有容器

Docker似乎不会将

daemon.json中的日志配置更改应用于已经运行的容器，即使该守护进程已重新启动：

在
daemon.json
中运行带有一些日志配置的容器（c1），如
。。。“最大文件”：“3”…
docker inspect c1
显示配置
将
daemon.json
更改为
。。。“最大文件”：“5”…
使用
service docker Restart
docker inspect c1
显示旧配置

如果我运行一个新的容器（c2）和
docker inspect c2
，新配置将应用于此容器
我没想到会有这种行为。
不是你想听的，但是

这种行为是意料之中的。容器从其配置中的创建点开始是静态的。

为了强调这条语句，下面是一个带有存储驱动程序的示例。如果选择另一个存储驱动程序，则当前容器将不再工作。您可以在此处找到此特定信息：


重要提示：更改存储驱动程序时，任何现有映像和
容器变得无法接近。这是因为它们的层不能
由新的存储驱动程序使用。如果您恢复更改，您将
能够再次访问旧图像和容器，但任何
使用新驱动程序拉取或创建的文件将无法访问


要将您在deamon中所做的更改角色化，您需要在系统上重新创建所有容器

保存数据

您是否将数据存储在命名卷或主机路径卷中？如果是这样的话，您应该没问题，否则您可以使用从容器中复制任何需要的数据

docker cp container:/path/to/files /target/folder/on/host


如果使用orchestrator，例如，您可以排空节点，从而终止主机上的所有容器，并在成功排空后将节点添加回集群。具体的命令将取决于您选择的编排器


更新
问题：我不明白数据量如何与日志配置相关。如果我将数据存储在命名卷或主机路径卷中，我会很好，但我没有看到与我的问题的关系

回答：正确，从功能角度来看，只是为您添加了有关卷的信息，这样您就不会在不知不觉/无法恢复的情况下丢失数据。
遗憾的是，这是不可能的。它将覆盖容器的静态属性。只要重新加载即可对daemon.json进行任何更改，无需重新启动。如果未设置
实时还原属性
，则重新启动将杀死旧容器。


来看看你能做的可能的解决方案列表


-如果旧容器不影响您，您可以手动重新启动它们，当然是在后台程序上重新加载配置之后。


-如果您不需要将静态数据和日志转入新容器，您可以运行另一个容器，即复制容器，缓慢移动流量并远离旧容器。


-您手动取回正在运行的容器，我的意思是使用
docker save
保存容器，杀死它，然后使用
docker load
加载容器，以带回包含容器数据的新容器。


-如果您不希望重新启动容器，甚至不希望以蓝绿方式重新启动，那么请运行另一个容器-apache或您自己的实现提供的日志滚动服务，将该容器链接到您正在运行的容器，以便它能够访问您的旧容器数据，然后开始拉出日志或执行内务管理。


以上是我现在能想到的选择。如果你能找到更好的方法，我很想知道
 我没有使用任何编曲器。我不明白数据卷如何与日志配置相关。如果您不使用orchestrator，我的答案仍然正确。您所说的“数据卷”是什么意思？我是指docker卷。你说如果我有数据存储在命名卷或主机路径卷中，我会相信，但我没有看到与我的问题的关系。我现在明白了，您正在谈论重新创建和保存数据的方法。没问题。听说没有别的路可走，很难过。谢谢你的回答。请详细说明一下：-如果旧容器不影响您，您可以手动重新启动它们，当然是在守护进程上重新加载配置之后。您的意思是重新启动守护进程和容器应该应用更改吗？我没有那种感觉，没有。重新加载守护进程并手动重新启动容器。它最类似于杀死容器并再次启动它们。