生产环境中，对于运维来说，可能不需要亲自去编写Dockerfile来构建镜像，大多数是研发部门来做这个事情，但我认为运维岗位有必要清楚Dockerfile的构建过程，再不济也应该知道运行这个image时，最后的进程是怎么样的，这会更有利于测试维护。
在我的公司来说，底层运维和研发是搭不上话的，更别说了解Dockerfile了，这就需要自己来研究。
Docker也很友好的，可以通过命令查看镜像构建过程。
代码语言：javascript复制docker image histroy [IMAGE]
如：
$ docker image history busybox:latest
IMAGE CREATED CREATED BY SIZE COMMENT
a9d583973f65 8 weeks ago /bin/sh -c #(nop) CMD ["sh"] 0B
<missing> 8 weeks ago /bin/sh -c #(nop) ADD file:b49bf6359240618f2? 1.23MB 学习过Dockerfile应该知道，正常结构 CMD 或者 ENTRYPOINT 应该在文件末尾，用来挂起前台进程，docker image history看到的是倒序的，故，我在网上扒了个脚本，如下： 参考站点
代码语言：javascript复制#!/bin/bash
case "$OSTYPE" in
linux*)
docker history --no-trunc --format "{{.CreatedBy}}" $1 | # extract information from layers
tac | # reverse the file
sed 's,^(|3.*)?/bin/(ba)?sh -c,RUN,' | # change /bin/(ba)?sh calls to RUN
sed 's,^RUN #(nop) *,,' | # remove RUN #(nop) calls for ENV,LABEL...
sed 's, *&& *, \n && ,g' # pretty print multi command lines following Docker best practices
;;
darwin*)
docker history --no-trunc --format "{{.CreatedBy}}" $1 | # extract information from layers
tail -r | # reverse the file
sed -E 's,^(|3.*)?/bin/(ba)?sh -c,RUN,' | # change /bin/(ba)?sh calls to RUN
sed 's,^RUN #(nop) *,,' | # remove RUN #(nop) calls for ENV,LABEL...
sed $'s, *&& *, \ \n && ,g' # pretty print multi command lines following Docker best practices
;;
*)
echo "unknown OSTYPE: $OSTYPE"
;;
esac使用方法
代码语言：javascript复制./script.sh [IMAGE]
# ./script.sh nginx:latest只能提供大致的构建过程，至于中间在构建本地copy了什么文件，解压了什么文件，还是无从之晓的。
