配置Docker守护程序并对其进行故障排除
预计阅读时间:11分钟
成功安装并启动Docker之后,dockerd
守护程序将以其默认配置运行。本主题显示如何自定义配置,手动启动守护程序以及在遇到问题时对守护程序进行故障排除和调试。
使用操作系统实用程序启动守护程序
在典型安装中,Docker守护进程由系统实用程序启动,而不是由用户手动启动。这使得在机器重启时自动启动Docker变得更加容易。
启动Docker的命令取决于您的操作系统。在“安装Docker”下检查正确的页面。要将Docker配置为在系统引导时自动启动,请参阅将Docker配置为在系统引导 时启动。
手动启动守护程序
如果您不想使用系统实用程序来管理Docker守护程序,或者只想进行测试,则可以使用以下dockerd
命令手动运行它。您可能需要使用sudo
,具体取决于您的操作系统配置。
当您以这种方式启动Docker时,它在前台运行,并将其日志直接发送到您的终端。
$ dockerd
INFO[0000] +job init_networkdriver()
INFO[0000] +job serveapi(unix:///var/run/docker.sock)
INFO[0000] Listening for HTTP on unix (/var/run/docker.sock)
要在手动启动Docker时停止它,请Ctrl+C
在终端中发出a 。
配置Docker守护程序
有两种配置Docker守护程序的方法:
- 使用JSON配置文件。这是首选选项,因为它将所有配置都放在一个位置。
- 启动时使用标志
dockerd
。
只要您未同时在标志和JSON文件中指定相同的选项,就可以将这两个选项一起使用。如果发生这种情况,则Docker守护程序将不会启动并显示错误消息。
要使用JSON文件配置Docker守护程序,请/etc/docker/daemon.json
在Linux系统或C:\ProgramData\docker\config\daemon.json
Windows上创建一个文件
。在MacOS上,转到任务栏中的鲸鱼>首选项>守护程序>高级。
配置文件如下所示:
{
"debug": true,
"tls": true,
"tlscert": "/var/docker/server.pem",
"tlskey": "/var/docker/serverkey.pem",
"hosts": ["tcp://192.168.59.3:2376"]
}
通过此配置,Docker守护程序以调试模式运行,使用TLS,并侦听路由到192.168.59.3
port的流量2376
。您可以在dockerd参考文档中了解可用的配置选项
您还可以手动启动Docker守护程序并使用标志对其进行配置。这对于解决问题很有用。
这是一个如何使用与上面相同的配置手动启动Docker守护程序的示例:
dockerd --debug \
--tls=true \
--tlscert=/var/docker/server.pem \
--tlskey=/var/docker/serverkey.pem \
--host tcp://192.168.59.3:2376
您可以在dockerd参考文档中或通过运行以下命令了解可用的配置选项 :
dockerd --help
整个Docker文档中讨论了许多特定的配置选项。接下来要去的地方包括:
Docker守护程序目录
Docker守护程序将所有数据保留在一个目录中。这将跟踪与Docker相关的所有内容,包括容器,映像,卷,服务定义和机密。
默认情况下,该目录为:
/var/lib/docker
在Linux上。C:\ProgramData\docker
在Windows上。
您可以使用data-root
配置选项将Docker守护程序配置为使用其他目录
。
由于Docker守护程序的状态保留在此目录中,因此请确保为每个守护程序使用专用目录。如果两个守护程序共享同一目录(例如,NFS共享),则将遇到难以解决的错误。
对守护程序进行故障排除
您可以在守护程序上启用调试,以了解该守护程序的运行时活动并帮助进行故障排除。如果守护程序完全没有响应,您还可以通过将信号发送到Docker守护程序,
强制将所有线程的完整堆栈跟踪添加到守护程序日志中SIGUSR
。
解决daemon.json
和启动脚本之间的冲突
如果您使用daemon.json
文件并且还dockerd
手动或使用启动脚本将选项传递给命令,并且这些选项发生冲突,则Docker无法启动,并显示以下错误:
unable to configure the Docker daemon with file /etc/docker/daemon.json:
the following directives are specified both as a flag and in the configuration
file: hosts: (from flag: [unix:///var/run/docker.sock], from file: [tcp://127.0.0.1:2376])
如果看到类似于此错误的错误,并且正在使用标志手动启动守护程序,则可能需要调整标志或daemon.json
来消除冲突。
注意:如果看到此特定错误,请继续执行 下一部分,以解决此问题。
如果要使用操作系统的初始化脚本启动Docker,则可能需要以特定于操作系统的方式覆盖这些脚本中的默认设置。
将daemon.json中的hosts键与systemd一起使用
难以解决的配置冲突的一个显着示例是,您想指定一个不同于默认值的守护程序地址。Docker默认情况下侦听套接字。在使用Debian和Ubuntu的系统上systemd
,这意味着-H
启动时始终使用主机标志dockerd
。如果您在中指定了一个
hosts
条目daemon.json
,则会导致配置冲突(如上述消息中所示),并且Docker无法启动。
要变通解决此问题,请创建/etc/systemd/system/docker.service.d/docker.conf
具有以下内容的新文件,以删除-H
默认情况下启动守护程序时使用的参数。
[Service]
ExecStart=
ExecStart=/usr/bin/dockerd
有时您可能需要systemd
使用Docker进行配置,例如
配置HTTP或HTTPS proxy。
注意:如果您覆盖此选项,然后
hosts
在手动启动Docker时未在daemon.json
或-H
标志中指定条目,则Docker无法启动。
sudo systemctl daemon-reload
在尝试启动Docker之前运行。如果Docker成功启动,则它现在正在侦听由hosts
key
daemon.json
而不是套接字指定的IP地址。
重要提示:Windows版Docker桌面或Mac版Docker桌面不支持
hosts
中的设置daemon.json
。
内存不足异常(OOME)
如果您的容器尝试使用的内存超出系统可用的内存,则可能会遇到内存不足异常(OOME),并且内核OOM杀手可能会杀死容器或Docker守护程序。为防止这种情况的发生,请确保您的应用程序在具有足够内存的主机上运行,请参阅了解内存不足 的风险。
阅读日志
守护程序日志可以帮助您诊断问题。日志可能保存在几个位置之一,具体取决于操作系统配置和所使用的日志记录子系统:
操作系统 | 地点 |
---|---|
RHEL,Oracle Linux | /var/log/messages |
德比安 | /var/log/daemon.log |
Ubuntu 16.04 +,CentOS | 使用命令journalctl -u docker.service 或/var/log/syslog |
Ubuntu 14.10- | /var/log/upstart/docker.log |
macOS(Docker 18.01及更高版本) | ~/Library/Containers/com.docker.docker/Data/vms/0/console-ring |
macOS(Docker <18.01) | ~/Library/Containers/com.docker.docker/Data/com.docker.driver.amd64-linux/console-ring |
视窗 | AppData\Local |
启用调试
有两种启用调试的方法。推荐的方法是将debug
密钥设置
true
为daemon.json
文件中的。该方法适用于每个Docker平台。
-
编辑
daemon.json
文件,该文件通常位于中/etc/docker/
。如果该文件尚不存在,则可能需要创建它。在macOS或Windows上,请勿直接编辑文件。而是转到 Preferences / Daemon / Advanced。 -
如果文件为空,请添加以下内容:
{ "debug": true }
如果文件已经包含JSON,则只需添加key即可
"debug": true
,请注意,如果不是结束括号之前的最后一行,请在该行的末尾添加一个逗号。还要验证是否log-level
已设置密钥,将其设置为info
还是debug
。info
是默认的,和可能的值是debug
,info
,warn
,error
,fatal
。 -
HUP
向守护程序发送信号以使其重新加载其配置。在Linux主机上,使用以下命令。$ sudo kill -SIGHUP $(pidof dockerd)
在Windows主机上,重新启动Docker。
除了遵循此过程之外,您还可以停止Docker守护程序,并使用debug标志手动重新启动它-D
。但是,这可能会导致Docker在与主机启动脚本创建的环境不同的环境下重新启动,这可能会使调试更加困难。
强制记录堆栈跟踪
如果守护程序无响应,则可以通过向SIGUSR1
守护程序发送信号来强制记录完整的堆栈跟踪。
-
Linux:
$ sudo kill -SIGUSR1 $(pidof dockerd)
-
Windows Server:
获取dockerd的进程ID
Get-Process dockerd
。运行带有标志的可执行文件
--pid=<PID of daemon>
。
这将强制记录堆栈跟踪,但不会停止守护程序。守护程序日志显示堆栈跟踪或包含堆栈跟踪的文件的路径(如果已将其记录到文件中)。
在处理SIGUSR1
信号并将堆栈跟踪信息转储到日志之后,守护程序将继续运行。堆栈跟踪可用于确定守护程序中所有goroutine和线程的状态。
查看堆栈跟踪
可以使用以下方法之一查看Docker守护程序日志:
- 通过使用以下命令
journalctl -u docker.service
在Linux系统上运行systemctl
/var/log/messages
,/var/log/daemon.log
或/var/log/docker.log
在较旧的Linux系统上
注意:无法在Mac的Docker桌面或Windows的Docker桌面上手动生成堆栈跟踪。但是,如果遇到问题,可以单击Docker任务栏图标,然后选择诊断和反馈以将信息发送给Docker。
在Docker日志中查找如下消息:
...goroutine stacks written to /var/run/docker/goroutine-stacks-2017-06-02T193336z.log
...daemon datastructure dump written to /var/run/docker/daemon-data-2017-06-02T193336z.log
Docker保存这些堆栈跟踪和转储的位置取决于您的操作系统和配置。有时您可以直接从堆栈跟踪和转储中获得有用的诊断信息。否则,您可以将此信息提供给Docker,以帮助诊断问题。
检查Docker是否正在运行
与操作系统无关的检查Docker是否正在运行的方法是使用docker info
命令询问Docker 。
您也可以使用操作系统实用程序,例如
sudo systemctl is-active docker
或sudo status docker
或
sudo service docker status
,或使用Windows实用程序检查服务状态。
最后,您可以dockerd
使用ps
或之类的命令在流程列表中检入该流程top
。