目录
CMD 容器启动命令
CMD 指令的格式两种格式：
- shell 格式：
CMD <命令> - exec 格式：
CMD ["可执行文件", "参数1", "参数2"...] - 参数列表格式：
CMD ["参数1", "参数2"...]。在指定了ENTRYPOINT指 令后，用CMD指定具体的参数。
之前介绍容器的时候曾经说过，Docker 不是虚拟机，容器就是进程。既然是进程，那么在启动容器的时候，需要指定所运行的程序及参数。
CMD 指令就是用于指定默认的容器主进程的启动命令的。 在运行时可以指定新的命令来替代镜像设置中的这个默认命令。
比如， ubuntu 镜像默认的 CMD 是 /bin/bash ，如果我们直接 docker run -it ubuntu 的 话，会直接进入 bash 。我们也可以在运行时指定运行别的命令，如 docker run -it ubuntu cat /etc/os-release 。这就是用 cat /etc/os-release 命令替换了默认的 /bin/bash 命令了，输出了系统版本信息。 在指令格式上，一般推荐使用 exec 格式，这类格式在解析时会被解析为 JSON 数组，因此一定要使用双引号 " ，而不要使用单引号。
如果使用 shell 格式的话，实际的命令会被包装为 sh -c 的参数的形式进行执行。比如：
CMD echo $HOME 在实际执行中，会将其变更为：
CMD [ "sh", "-c", "echo $HOME" ]前台执行和后台执行
Docker 不是虚拟机，容器中的应用都应该以前台执行，而不是像虚拟机、物理机 里面那样，用 systemd 去启动后台服务，容器内没有后台服务的概念。 一些初学者将 CMD 写为： CMD service nginx start
然后发现容器执行后就立即退出了。甚至在容器内去使用 systemctl 命令结果 却发现根本执行不了。这就是因为没有搞明白前台、后台的概念，没有区分容器和 虚拟机的差异，依旧在以传统虚拟机的角度去理解容器。
对于容器而言，其启动程序就是容器应用进程，容器就是为了主进程而存在的，主进程退出，容器就失去了存在的意义，从而退出，其它辅助进程不是它需要关心的东西。
而使用 service nginx start 命令，则是希望 upstart 来以后台守护进程形式启动 nginx 服务。而刚才说了 CMD service nginx start 会被理解为 CMD [ "sh", "-c", "service nginx start"]，因此主进程实际上是 sh 。那么当 service nginx start 命令结束后， sh 也就结束了， sh 作为主进程退出了，自然就会令容器退出。
正确的做法是直接执行 nginx 可执行文件，并且要求以前台形式运行。比如： CMD ["nginx", "-g", "daemon off;"]
WORKDIR 指定工作目录
格式为 WORKDIR <工作目录路径> 。
使用 WORKDIR 指令可以来指定工作目录（或者称为当前目录），
以后各层的当前目录就被改为指定的目录，如该目录不存在， WORKDIR 会帮你建立目录。
之前提到一些初学者常犯的错误是把 Dockerfile 等同于 Shell 脚本来书写，这种错误的理解还可能会导致出现下面这样的错误：
`RUN cd /app RUN echo "hello" > world.txt` 如果将这个 Dockerfile 进行构建镜像运行后，会发现找不到 /app/world.txt 文件，或者其内容不是 hello 。
原因其实很简单，在 Shell 中，连续两行是同一个进程执行环境，因此前一个命令修改的内存状态，会直接影响后一个命令；而在 Dockerfile 中，这两行 RUN 命令的执行环境根本不同， 是两个完全不同的容器。
这就是对 Dockerfile 构建分层存储的概念不了解所导致的错误。 之前说过每一个 RUN 都是启动一个容器、执行命令、然后提交存储层文件变更。
第一层 RUN cd /app 的执行仅仅是当前进程的工作目录变更，一个内存上的变化而已，其结果不会造成任何文件变更。而到第二层的时候，启动的是一个全新的容器，跟第一层的容器更完全没关系，自然不可能继承前一层构建过程中的内存变化。因此如果需要改变以后各层的工作目录的位置，那么应该使用 WORKDIR 指令