1.exit status 127; not expected-》#！
exit status 0; not expected
http://supervisord.org/subprocess.html
autorestart=false
startretries=0
command=/bin/bash -c "exec /tmp/start_spider.sh > /dev/null 2>&1 -DFOREGROUND"
autostart=true
autorestart=unexpected
startretries=0
exitcodes=1
2.Error mounting devices cgroup: mountpoint for devices not found （执行docker -d&）
cgroup设备在宿主主机没有挂载
3.docker dead but subsys locked
解决方法：
rm /var/run/docker.*
rm /var/lock/subsys/docker
rm -rf /var/lib/docker/*
4.Bringing up interface kbr0: Error: Connection activation failed: Failed to determine connection's virtual interface name
service NetworkManager stop
chkconfig NetworkManager off
5.Finished Dependency Resolution
Error: Package: openvswitch-2.3.0-1.x86_64 (/openvswitch-2.3.0-1.x86_64)
Requires: /usr/local/bin/python
You could try using --skip-broken to work around the problem
You could try running: rpm -Va --nofiles --nodigest
6./usr/local/bin/python is needed by XX.rpm
解决方式：
可以在build这个XX.rpm包时，在其SEPC文件中写上”Autoreq: 0″这一行来取消自动添加依赖关系，然后重新build这个rpm包即可（http://smilejay.com/2011/11/denpendency_need_python/）
7.Bringing up interface kbr0: Incorrect number of arguments for command
Usage: brctl addbr <bridge> add bridge
解决方式：
/etc/sysconfig/network-scripts/ifcfg-kbr0中增加 DEVICE=kbr0
8.Running modprobe bridge nf_nat failed with message: , error: exit status 1
9.Couldn't run auplink before unmount: exec: \"auplink\
You need to install aufs-tools, apt-get install aufs-tools should fix it.
10.Error: Package: python-meld3-0.6.7-1.el6.x86_64 (epel)
Requires: python(abi) = 2.6
Installed: python-2.7.5-34.el7.x86_64 (@CentOS)
python(abi) = 2.7
python(abi) = 2.7
Error: Package: python-meld3-0.6.7-1.el6.x86_64 (epel)
Requires: libpython2.6.so.1.0()(64bit)
Error: Package: supervisor-2.1-9.el6.noarch (epel)
Requires: python(abi) = 2.6
Installed: python-2.7.5-34.el7.x86_64 (@CentOS)
python(abi) = 2.7
python(abi) = 2.7
11.配置的java环境不起作用
docker exec cid -it /bin/bash进去查看java环境变量已经配置,java命令找不到
通过ｓｓｈ登录却能找到ｊａｖａ命令
原因：设置ENV>>>docker exec 进去，环境变量生效 写入/etc/profile>>>ssh进去，环境变量生效
12.docker中定时任务无法生效
解决方式：
首先检查是否开启rsyslogd和crond服务
如果开启，cron无法生效则查看/var/log/cron日志，pam若提示
(root) FAILED to open PAM security session (Cannot make/remove an entry for the specified session)
则需修改/etc/pam.d/crond中pam选项的required为sufficient即可
13.313455e5087f
Error response from daemon: Cannot destroy container c3fbc467e11d: Driver devicemapper failed to remove root filesystem c3fbc467e11de41dd0252f328af28a1e6bead13c35e241bb38652a96e97d5bcc: Device is Busy
解决方法：umount /var/lib/docker/devicemapper/mnt/c3fbc467e11de41dd0252f328af28a1e6bead13c35e241bb38652a96e97d5bcc
14.docker: relocation error: docker: symbol dm_task_get_info_with_deferred_remove, version Base not defined in file libdevmapper.so.1.02 with link time reference(centos6.5下安装docker)
解决方式：安装 device-mapper-libs 包即可解决，第一次启动用service docker start
端口转发到主机
端口转发只能用在Boot2Docker下的VM。 如果你也想用同一端口转发到你的主机，比如你正在测试Android应用程序的后台或者想分享VM呢？
你有两个选择：
到VirtualBox的设置里去添加一个Bridged adapter。 现在当你再启动docker-machine，你的VM就会得到一个正式的LAN地址。 这时你就可以从网络上的其它任何设备访问虚拟机，而且docker-compose的端口转发也可以使用。
等到Issue #691（或相关）得到解决。 就可以允许你使用SSH端口转发。唯一的问题是你必须手动的操作需要的每一个端口。
docker-machine ssh -L <host-port>:localhost:<machine-port>
性能低
默认情况下，当你用docker-machine创建一个VM，只得到非常低的配置（1CPU，1GB RAM）。 运行“docker-machine help create”去了解相应的flag后，就可用它们来增加CPU/RAM。 例如：
docker-machine create \
--driver virtualbox \
--virtualbox-cpu-count 2 \
--virtualbox-memory 2048 \
dev
符号链接错误
有多种原因导致这种错误发生，但是最常见的一种是VirtualBox缺少 Guest Additions 。 请确定它被安装了（VirtualBox > Preferences > Extensions）并要匹配VirtualBox的版本。 这大多发生在VirtualBox是单独安装的。
共享文件夹不能得到更新
在Boot2Docker中，这是一个已知的bug。因为它为了考虑提升速度而只是缓存NFS文件。所以你需要刷新文件系统缓存。
docker-machine ssh <name-of-your-machine>
sudo cache-clear
(OR)
sudo su
# echo 3 > /proc/sys/vm/drop_caches
有些commands/languages忽略FS的缓存。 例如：当运行npm、less、vi等等，你将不会发现这些错误。但其他的命令都使用缓存 —cat、python、Apache SendFile等等。
在VirtualBox中，这个问题也涉及到Apache SendFile bug。
网络错误
有时你会看到怪异的网络错误，像地址不能解析、不能ping通等等。通常是由于主机的网络配置被更改了（例如，你切换到了WiFi网络等），这时可以重启VM获得更新过的网络配置。
构建和相关性
你的Dockerfile通常被用来编译和构建应用，并准备启动。 当以Volume去挂载你的文件夹（如通常在开发的情况下），这会导致各种问题。
有些语言（Ruby、Python等等）的安装依赖于用户目录的共享文件夹。 其他的（Node/NPM）直接在当前的应用程序文件夹中安装。 因此，尽管构建容器的时候有“npm install“，但以后当你用共享的volume运行“docker-compose up”，“node_modules”文件夹消失了！
类似的，build文件夹也没了。 结果，容器用来启动应用的CMD多数情况下就不能工作。
这是棘手的，即使你在dev和prod用不同的Dockerfile。 因为这不是一个build image时的问题，而是一个容器的运行时的问题。 目前的解决方法依赖于你的语言（rake/grunt/gulp/fabric/etc）对应的Task runner，并在Docker的CMD中用它去开发。 不要在Dockerfile中填写应用的“build”逻辑，相反地请使用task runner。
# gulp/grunt/rake/...
# have a "build" task
# Dockerfile
# used for normal production deployment
# here you use separate tasks as needed
COPY package.json /myapp/
RUN npm install
COPY . /myapp
RUN gulp build
CMD ["npm", "start"]
# docker-compose
# when developing, combine all the above commands
myservice:
volumes: ".:/myapp"
command: "sh -c 'npm install && gulp build && npm start'"
.dockerignore
确定你的“.dockerignore”文件在跨平台时能忽略常见的特殊文件。 这些不必要的文件将无效Docker的构建缓存。 有了正确的”.dockerignore“的文件，build的时候你可以简单地运行”COPY ./myapp“去复制你的整个app源代码，而不是一个文件夹又一个文件的去复制。
# Ignore .git folder
.git*
# Ignore all Windows, Linux and OSX special files
# https://www.gitignore.io/api/windows,linux,osx,vim
# Ignore all your language-specific build folders
build/
target/
node_modules/
.bundler/
etc
使用gitignore.io获取对应语言/平台的常见文件清单。 但请记住，”.gitignore”和”.dockerignore”甄别这些文件的方式不同。 dockerignore要求整个文件名必须匹配。 所以在gitignore里，你可以写”node_modules“去忽略整个文件夹，但在dockerignore你不得不用”node_modules/*“。
清理
下面的 docker-clean命令可以删除所有没有tag的image和停止的容器。 可定期运行该命令去清理VM。
docker ps -aqf status=exited | xargs docker rm
docker images -qf dangling=true | xargs docker rmi
单元测试/ CI
可以用一个单独的docker-compose.test.yml，从平常的”docker-compose.yml“去”extend“服务，但这只是直接覆盖“command”set来运行测试。 然后在CI上，运行以下命令：
docker-compose -f docker-compose.test.yml run <service_name>
这将直接启动所有的链接服务，并运行测试，然后会用你的测试脚本的状态码退出。 现在，您的CI可以简单地安装docker-compose，并可以为每个服务运行上面的命令而不需要了解特定的服务！
链接
当运行测试时，docker-compose很容易把所有的微服务链接在一起。 对于pet项目，这通常不是问题，但对于规模较大的项目就比较头痛。 尽早避免它， 可以像stubby4node那样，用一个描述stubbed endpoints的简单的YAML文件去使用stub servers。
时钟同步错误
当docker-machine VM的时钟与实际时间不同步，你会得到很多奇怪的错误，如签名错误（各种AWS服务）。 在这种情况下，只要重新启动该VM去同步时钟。 这通常发生在暂停/恢复你的笔记本电脑或台式机。 你的主机操作系统更新了时间，但挂起的VM却滞后了。 同样的情况对于Vagrant也是如此。
忘记关闭虚拟机
”无耻的plug“：当我们正在Docker上开发一个菜单栏的应用程序，我们往往在离开时让docker-machine VM一直运行，忘记将其关闭
1、Docker 和虚拟机有啥不同？
Docker 是轻量级的沙盒，在其中运行的只是应用，虚拟机里面还有额外的系统。
2、Docker 安全么？
Docker 利用了 Linux 内核中很多安全特性来保证不同容器之间的隔离，并且通过签名机制来对镜像进行验证。大量生产环境的部署证明，Docker 虽然隔离性无法与虚拟机相比，但仍然具有极高的安全性。
3、如何清理后台停止的容器？
可以使用 sudo docker rm $sudo( docker ps -a -q) 命令。
4、如何查看镜像支持的环境变量？
可以使用 docker run IMAGE env 命令。
5、当启动容器的时候提示：exec format error？ 如何解决问题
检查启动命令时候有可执行权限，进入容器手工运行脚本进行排查。
6、本地的镜像文件都存放在哪里？
与 Docker 相关的本地资源都存放在/var/lib/docker/目录下，其中container目录存放容器信息，graph目录存放镜像信息，aufs目录下存放具体的内容文件。
7、如何退出一个镜像的bash，而不终止它？
按 Ctrl-p Ctrl-q。
8、退出容器时候自动删除?
使用 –rm 选项，例如 sudo docker run –rm -it ubuntu
9、怎么快速查看本地的镜像和容器？
可以通过docker images来快速查看本地镜像；通过docker ps -a快速查看本地容器
加速DockerImage下载方法
1、利用阿里云
如果你是Centos系统，你可以执行如下命令开启加速 ：
sudo sed -i 's|OPTIONS=|OPTIONS=--registry-mirror=http://zbseumga.mirror.aliyun.com |g' /etc/sysconfig/docker
sudo service docker restart
如果你是Ubuntu 系统，你可以执行如下命令开启 :
echo "DOCKER_OPTS=\"\$DOCKER_OPTS --registry-mirror=http://zbseumga.mirror.aliyun.com\"" | sudo tee -a /etc/default/docker
sudo service docker restart
如果你使用的是Mac，你可以执行如下命令开启 :
boot2docker ssh
sudo su
echo "EXTRA_ARGS=\"--registry-mirror=http://zbseumga.mirror.aliyun.com\"" >> /var/lib/boot2docker/profile && exit
exit
boot2docker restart
1.Docker中同种类型不同tag的镜像并非可互相替代
问题描述
Docker 中同种类型的镜像，一般会用tag来进行互相区分。如Docker中的mysql镜像，镜像tag有很多种，有5.6.17，5.6.22，latest 等。用户的环境中若已经熟练使用mysql:5.6.17,并不代表用户如果使用mysql:5.6.22，环境依旧工作。
原因剖析
不同tag同种类型的Docker镜像，会因为以下的原因导致镜像差异。 (1).Docker镜像内容不同。同种类型Docker镜像的tag不同，很大程度上是因为镜像中应用版本的差异。Dockerfile代表 Docker镜像的制作流程，换言之是Dockerfile的不同，导致Docker镜像的不同。 (2).Docker镜像的entrypoint.sh不同。entrypoint.sh代表容器中应用进程按照何种形式启动，entrypoint.sh的差异直接导致应用容器的使用差异。举例说明：mysql:5.6.17和mysql:5.6.22的 entrypoint.sh存在很大差异，两者对于隔离认为重要的环境变量的定义就不一致，使用的差异自然存在。
解决方案
不同tag的同类型镜像作为替代品时，需谨慎。查看Docker镜像layer层的差异，查阅Dockerfile与entrypoint.sh的差异，可以提供起码的保障。
2.不同时间段使用tag为latest的镜像，效果不尽相同
问题描述
在一个时间点使用latest镜像，应用容器运行正常;之后的另一个时间点按照相应的Dockerfile，build出镜像再运行应用容器，失效。
原因剖析
Docker 官方关于同种类型Docker镜像的latest标签，并未永久赋予某一指定的Docker镜像，而是会变化。举例说明：某一个时间点ubuntu镜像的 latest标签属于ubuntu:12.04，之后的另一时间点，该latest标签属于ubuntu:14.04，若Dockerfile在这两个时间点进行build时，结果必然相异。原因回归至上文的第一个坑。
解决方案
慎用latest标签，最好不用，Docker镜像都使用指定的tag。
3.使用fig部署依赖性强的容器时出错
问题描述
使用fig部署两个有依赖关系的容器A和B，容器A内部应用的启动依赖于容器B内应用的完成。容器A内应用程序尝试连接容器B内部应用时，由于容器B内应用程序并未启动完毕，导致容器A应用程序启动失败，容器A停止运行。
原因剖析
容器的启动分为三个阶段，依次为dockerinit、entrypoint.sh以及cmd，三个阶段都会消耗时间，不同的容器消耗的时间不一，这主要取决于docker容器中entrypoint和command到底做了什么样的操作。如mysql容器B的启动，首先执行dockerinit;然后通过 dockerinit执行entrypoint.sh，由于entrypoint.sh执行过程中需要执行mysql_install_db等操作，会占据较多时间;最后由entrypoint.sh来执行cmd，运行真正的应用程序mysqld。综上所述，从启动容器到mysqld的运行，战线拉得较长，整个过程docker daemon都认为mysql容器存活，而mysqld正常运行之前，mysql容器并未提供mysql服务。如果fig中的容器A要访问mysql容器 B时，虽然fig会简单辨别依赖关系，让B先启动，再启动A，当fig无法辨别容器应用的状态，导致A去连接B时，B中应用仍然未启动完毕，最终A一场退出。
解决方案
对自身环境有起码的预估，如从容器B的启动到容器B内应用的启动完毕，所需多少时间，从而在容器A内的应用程序逻辑中添加延时机制;或者使得A内应用程序逻辑中添加尝试连接的机制，等待容器B内应用程序的启动完毕。 笔者认为，以上解决方案只是缓解了出错的可能性，并未根除。
4.Swarm管理多个Docker Node时，Docker Node注册失败
问题描述
笔者的Docker部署方式如下：在vSphere中安装一台ubuntu 14.04的虚拟机，在该虚拟机上安装docker 1.4.1;将该虚拟机制作vm使用的镜像;创建虚拟机节点时通过该镜像创建，从而虚拟机中都含有已经安装好的docker。如果使用Swarm管理这些虚拟机上的docker daemon时，仅一个Docker Node注册成功，其他Docker Node注册失败，错误信息为：docker daemon id已经被占用。
原因剖析
如果多个Docker Host上的Docker Daemon ID一样的话，Swarm会出现Docker Node注册失败的情况。原理如下： (1).Docker Daemon在启动的时候，会为自身赋一个ID值，这个ID值通过trustKey来创建，trustkey存放的位置为~/.docker /key.json。 (2).如果在IaaS平台，安装了一台已经装有docker的虚拟机vm1，然后通过制作vm1的镜像，再通过该镜像在IaaS平台上创建虚拟机 vm2，那么vm1与vm2的key.json文件将完全一致，导致Docker Daemon的ID值也完全一致。
解决方案
(1) 创建虚拟机之后，删除文件~/.docker/key.json ,随后重启Docker Daemon。Docker Daemon将会自动生成该文件，且内容不一致，实现多Docker Host上Docker Daemon ID不冲突。 (2)创建虚拟机镜像时，删除key.json文件。 建议使用方案二，一劳永逸。
5.Docker容器的DNS问题
问题描述
Dockerfile在build的过程中只要涉及访问外网，全部失效。
原因剖析
用户在创建docker容器的时候，不指定dns的话，Docker Daemon默认给Docker Container的DNS设置为8.8.8.8和8.8.4.4。而在国内这个特殊的环境下，这两个DNS地址并不提供稳定的服务。如此一来，只要 Docker Container内部涉及到域名解析，则立即受到影响。
docker run命令dns失效的解决方案
使用docker run命令启动容器的时候，设定–dns参数，参数值为受信的DNS地址，必须保证该DNS地址Docker Container可访问。
以上解决方案的弊端
如果按以上做修改，仅适用于docker run命令。而使用docker build的时候其实是多个docker run的叠加，由于docker build没有dns参数的传入，因此docker container不能保证域名的成功解析。
docker build命令dns失效的解决方案
启动Docker Daemon的时候设定DOCKER_OPTS，添加–dns参数，这样可以保证所有的docker run默认使用这个DNS地址。