CMD 容器启动命令
Docker 不是虚拟机，容器中的应用都应该以前台执行，而不是像虚拟机、物理机里面那样，用
systemd
去启动后台服务，容器内没有后台服务的概念。
对于容器而言，其启动程序就是容器应用进程，容器就是为了主进程而存在的，主进程退出，容器就失去了存在的意义，从而退出，其它辅助进程不是它需要关心的东西。
CMD
指令的格式和
RUN
相似，也是两种格式：
-
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" ]
这就是为什么我们可以使用环境变量的原因，因为这些环境变量会被 shell 进行解析处理。
提到
CMD
就不得不提容器中应用在前台执行和后台执行的问题。这是初学者常出现的一个混淆。
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
可执行文件，并且要求以前台形式运行。比如：
| 1 | |
ENTRYPOINT 入口点
ENTRYPOINT
的格式和
RUN
指令格式一样，分为
exec
格式和
shell
格式。
ENTRYPOINT
的目的和
CMD
一样，都是在指定容器启动程序及参数。
ENTRYPOINT
在运行时也可以替代，不过比
CMD
要略显繁琐，需要通过
docker run
的参数
--entrypoint
来指定。
当指定了
ENTRYPOINT
后，
CMD
的含义就发生了改变，不再是直接的运行其命令，而是将
CMD
的内容作为参数传给
ENTRYPOINT
指令，换句话说实际执行时，将变为：
<ENTRYPOINT> "<CMD>"
那么有了
CMD
后，为什么还要有
ENTRYPOINT
呢？这种
<ENTRYPOINT> "<CMD>"
有什么好处么？让我们来看几个场景。
场景一：让镜像变成像命令一样使用
假设我们需要一个得知自己当前公网 IP 的镜像，那么可以先用
CMD
来实现：
| 1 2 3 4 5 | |
假如我们使用
docker build -t myip .
来构建镜像的话，如果我们需要查询当前公网 IP，只需要执行：
假如我们使用
docker build -t myip .
来构建镜像的话，如果我们需要查询当前公网 IP，只需要执行：
$ docker run myip
当前 IP：61.148.226.66 来自：北京市 联通
嗯，这么看起来好像可以直接把镜像当做命令使用了，不过命令总有参数，如果我们希望加参数呢？比如从上面的
CMD
中可以看到实质的命令是
curl
，那么如果我们希望显示 HTTP 头信息，就需要加上
-i
参数。那么我们可以直接加
-i
参数给
docker run myip
么？
| 1 2 | |
可以看到可执行文件找不到的报错，
executable file not found
。之前我们说过，跟在镜像名后面的是
command
，运行时会替换
CMD
的默认值。因此这里的
-i
替换了原来的
CMD
，而不是添加在原来的
curl -s https://ip.cn
后面。而
-i
根本不是命令，所以自然找不到。
那么如果我们希望加入
-i
这参数，我们就必须重新完整的输入这个命令：
| 1 | |
显然不是很好的解决方案，而使用
ENTRYPOINT
就可以解决这个问题。现在我们重新用
ENTRYPOINT
来实现这个镜像：
| 1 2 3 4 5 | |
再来尝试直接使用
docker run myip -i
：
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 | |
可以看到，这次成功了。这是因为当存在
ENTRYPOINT
后，
CMD
的内容将会作为参数传给
ENTRYPOINT
，而这里
-i
就是新的
CMD
，因此会作为参数传给
curl
，从而达到了我们预期的效果。
场景二：应用运行前的准备工作
启动容器就是启动主进程，但有些时候，启动主进程前，需要一些准备工作。
比如
mysql
类的数据库，可能需要一些数据库配置、初始化的工作，这些工作要在最终的 mysql 服务器运行之前解决。
此外，可能希望避免使用
root
用户去启动服务，从而提高安全性，而在启动服务前还需要以
root
身份执行一些必要的准备工作，最后切换到服务用户身份启动服务。
或者除了服务外，其它命令依旧可以使用
root
身份执行，方便调试等。
这些准备工作是和容器
CMD
无关的，无论
CMD
为什么，都需要事先进行一个预处理的工作。
这种情况下，可以写一个脚本，然后放入
ENTRYPOINT
中去执行，而这个脚本会将接到的参数（也就是
<CMD>
）作为命令，在脚本最后执行。
比如官方镜像
redis
中就是这么做的：
| 1 2 3 4 5 6 7 8 | |
可以看到其中为了 redis 服务创建了 redis 用户，并在最后指定了
ENTRYPOINT
为
docker-entrypoint.sh
脚本。
| 1 2 3 4 5 6 7 8 9 | |
该脚本的内容就是根据
CMD
的内容来判断，如果是
redis-server
的话，则切换到
redis
用户身份启动服务器，否则依旧使用
root
身份执行。
比如：
| 1 2 | |
![Docker：可视化管理工具LazyDocker[图]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)