当我把Docker版本更新到0.8.0后,我在输入sudo Docker version时得到了一个错误消息:

Client version: 0.8.0
Go version (client): go1.2
Git commit (client): cc3a8c8
2014/02/19 12:54:16 Can't connect to docker daemon. Is 'docker -d' running on this host?

我按照说明,输入命令sudo docker -d,我得到了这个:

[/var/lib/docker|2462000b] +job initserver()
[/var/lib/docker|2462000b.initserver()] Creating server
open /var/lib/docker/aufs/layers/cf2414da53f9bcfaa48bc3d58360d7f1cfd3784e4fe51fbef95197709dfc285d: no such file or directory[/var/lib/docker|2462000b] -job initserver() = ERR (1)
2014/02/19 12:55:57 initserver: open /var/lib/docker/aufs/layers/cf2414da53f9bcfaa48bc3d58360d7f1cfd3784e4fe51fbef95197709dfc285d: no such file or directory

我怎么解决这个问题?


当前回答

如果你在OS X上使用Docker工具,请遵循以下步骤。

重新启动守护进程并配置您的环境:

docker-machine restart

然后

docker-machine env

最后,

eval $(docker-machine env)

测试守护进程是否正在运行:

Docker ps -a或Docker -machine ls。这将列出所有的容器。

其他回答

我也遇到了同样的问题——“无法连接到docker守护进程。”(除了我在试图启动服务器时没有得到任何“文件未找到”错误。)

“ps”表示“/usr/bin/docker -d”仍在运行

我意识到我自己从来没有成功地运行过服务器。每一次尝试都产生了结果

...
2014/03/24 21:57:29 pid file found, ensure docker is not running or delete /var/run/docker.pid

所以我后来才意识到,安装docker可能已经注册了upstart守护进程,upstart已经为我启动了它。因此,试图杀死守护进程以手动重新启动它会失败(不允许操作)。所以我做了一个

sudo kill -9 <PID>

守护进程。另一个守护进程立即取代了它的位置,这个新的守护进程现在让我的CLI客户端连接:

$ sudo docker info
Containers: 0
Images: 0
Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Dirs: 0
WARNING: No memory limit support
WARNING: No swap limit support

我也有类似的问题。我不得不注销并再次登录到shell,因为我刚刚安装了Docker,下面的命令在我的环境中没有显示。

export DOCKER_HOST=127.0.0.1:4243 >> ~/.bashrc

Linux

要在Linux上运行docker守护进程(从CLI),执行以下命令:

$ sudo service docker start # Ubuntu/Debian

注意:在复制和粘贴时跳过$字符。

在RedHat/CentOS操作系统上执行:sudo systemctl start docker。

要初始化“base”文件系统,运行:

$ sudo service docker stop
$ sudo rm -rf /var/lib/docker
$ sudo service docker start

或者手动操作:

$ sudo docker -d --storage-opt dm.basesize=20G

在Linux上安装docker-machine

在Linux上安装机器二进制文件:

本地: install -vm755 <(curl -L https://github.com/docker/machine/releases/download/v0.5.3/docker-machine_linux-amd64) $HOME/bin/docker-machine 全球: sudo bash -c 'install -vm755 <(curl -L https://github.com/docker/machine/releases/download/v0.5.3/docker-machine_linux-amd64) /usr/local/bin/docker-machine'

操作系统

在macOS上,docker二进制文件只是一个客户端,你不能用它来运行docker守护进程,因为docker守护进程使用linux特定的内核特性,因此你不能在OS x中本机运行docker。所以你必须安装docker-machine才能创建VM并附加到它。

在macOS上安装docker-machine

如果你还没有docker-machine命令,可以通过以下方式安装它:

使用Brew命令:Brew install docker-machine docker。 手动从GitHub: 安装-v <(curl https://github.com/docker/machine/releases/download/v0.5.3/docker-machine_linux-amd64) /usr/local/bin/docker-machine

参见:开始使用Mac版Docker。

在macOS上配置docker-machine

通过Homebrew启动Docker Machine,运行:

brew services start docker-machine

要创建一个默认机器(如果你没有,请参阅:docker-machine ls):

docker-machine create --driver virtualbox default

然后为Docker客户端设置环境:

eval "$(docker-machine env default)"

然后通过列出容器进行再次检查:

docker ps

请参见:从Docker Machine和本地VM开始。


安装码头工人。macOS应用程序

除了上述解决方案,你还可以通过以下方式安装Docker应用:

brew cask install docker

查看这篇文章了解更多细节。请参见:无法连接到macOS上的Docker守护进程

I also had the same issue. The problem was in sockets allocated to docker-daemon and docker-client. First, permission was not set for the docker-client on docker.sock You can set it using "sudo usermod -aG docker $USER" Then check your bash file where the docker-client is running, For me it was on 0.0.0.0:2375, while docker-daemon was running on unix socket.(It was set in the configuration file of dockerd). Just comment the bash-line and it'll work fine. But if you want to make it work on TCP port instead of unix socket, change the configuration file of dockerd and set it on 0.0.0.0.2375 and keep the line in bash as it is if present or set it to 0.0.0.0:2375.

找出Docker不能工作的原因的最好方法是手动运行守护进程。

$ sudo service docker stop
$ ps aux | grep docker  # do this until you don't see /usr/bin/docker -d
$ /usr/bin/docker -d

Docker守护进程记录到STDOUT,因此它将开始输出它正在做的任何事情。

这就是我的问题所在:

[8bf47e42.initserver()] Creating pidfile
2015/01/11 15:20:33 pid file found, ensure docker is not running or delete /var/run/docker.pid

这是因为实例是从另一个虚拟机克隆的。我只需要删除pidfile,之后一切都正常了。

当然,我并不是盲目地假设这样可以工作,而是建议再次手动运行守护进程,并在启动服务备份之前检查日志输出是否有其他错误。