Docker 调试技巧

『重用』容器名

但我们在编写/调试Dockerfile的时候我们经常会重复之前的command，比如这种 docker run --name jstorm-zookeeper zookeeper:3.4，然后就容器名就冲突了。

可以在运行  docker run 时候加上 --rm flag, 容器将在退出之后销毁。无需手动 docker rm CONTAINER

debug Dockerfile

在写  Dockerfile 的时候，通常并不会一气呵成。有的时候容器启动就crash 直接退出，有的时候build image 就会失败，或者想验证Dockerfile是否符合预期，我们经常要debug Dockerfile。

如果build 失败可以直接 查看stdout的错误信息，拆分指令，重新build。

logs 查看 stdout

所有容器内写到stdout的内容都会被捕获到host中的一个history文件中, 可以通过  docker logs CONTAINER查看。

即使是容器已经退出的也可以看到，所以可以通过这种方式来分析非预期的退出。这些文件一直保存着，直到通过 docker rm把容器删除。文件的具体路径可以通过 docker inspect CONTAINER 获得。
（然后osx上你并找不到这些文件，因为其实osx的docker实际是运行在”VM”中，具体就不展开了，但是可以通过  screen ~/Library/Containers/com.docker.docker/Data/com.docker.driver.amd64-linux/ttytouch上”VM”的tty）

在使用 docker logs 的时候加一些参数来过滤log，默认输出所有log。

attach 实时查看stdout

如果你想实时查看容器的输出你可以用  docker attach CONTAINER 命令。

默认会绑定stdin，代理signals， 所以如果你  ctrl-c 容器通常会退出。很多时候大家并不想这样，只是想分离开，可以 ctrl-p ctrl-q。

执行任意command

可以通过 docker exec CONTAINER COMMAND，来在容器内执行任意 command，比如 cat 一些东西来debug。

也可以直接通过 exec 在容器内启动一个 shell 更方便地调试容器，不必一条条执行 docker exec。

docker exec 只能在正在运行的容器上使用，如果已经停止了退出了就不行了，就只好用  docker logs了。

重写 entrypoint和 cmd

每个Docker镜像都有  entrypoint 和  cmd , 可以定义在  Dockerfile 中，也可以在运行时指定。这两个概念很容易混淆，而且它们的试用方式也不同。

entrypoint 比  cmd 更”高级”， entrypoint 作为容器中pid为1的进程运行（docker不是虚拟机，只是隔离的进程。真正的linux中pid为1的是 init）。
cmd 只是  entrypoint的参数:

当我们没有指定  entrypoint 时缺省为  /bin/sh -c。所以其实  entrypoint 是真正表达这个docker应该干什么的，通常大家有一个shell 脚本来代理。
entrypoint 和  cmd 都可以在运行的时候更改，通过更改来看这样设置 entrypoint是否优雅合理。

任何  docker run 命令中在image名后的内容都作为 cmd的内容传给  entrypoint当参数。

暂停容器

使用  docker pause 可以暂停容器中所有进程。这非常有用。

top 和  stats 获得容器中进程的状态

docker top CONTAINER 和在容器里执行  top 的效果类似。

通过  inspect 查看容器的详细信息

docker inspect CONTAINER 饭后镜像和容器的详细信息。比如：

• State —— 容器的当先状态
• LogPath —— history(stdout) file 的路径
• Config.Env —— 环境变量
• NetworkSettings.Ports —— 端口的映射关系

环境变量非常有用很多问题都是环境变量引起的。

history 查看 image layers

可以看到各层创建的指令，大小和哈希。可以用来检查这个image是否符合你的预期。