用法一:追加参数; 用法二:执行脚本
ENTRYPOINT
两种写法
1 | # exec 格式 ENTRYPOINT ["executable", "param1", "param2"] |
重点
- ENTRYPOINT 指定镜像的默认入口命令,该入口命令会在启动容器时作为根命令执行,所有其他传入值作为该命令的参数
- ENTRYPOINT 的值可以通过 docker run --entrypoint 来覆盖掉
- 只有 Dockerfile 中的最后一条 ENTRYPOINT 指令会起作用
ENTRYPOINT 和 CMD 联合使用
- 当指定了 ENTRYPOINT 后,CMD 的含义就发生了改变,不再是直接的运行其命令,而是将 CMD 的内容作为参数传给 ENTRYPOINT 指令
- 换句话说实际执行时,会变成
1 | <ENTRYPOINT> "<CMD>" |
灵魂拷问
那么有了 CMD 后,为什么还要有 ENTRYPOINT 呢?这种
CMD 和 ENTRYPOINT 区别
1 | CMD # 指定这个容器启动的时候要运行的命令,不可以追加命令 ENTRYPOINT # 指定这个容器启动的时候要运行的命令,可以追加命令 |
啥意思?这其实也是 ENTRYPOINT 的应用场景之一,下面来看
测试 CMD
编写 dockerfile 文件
1 | FROM centos CMD ["ls","-a"] |
构建镜像
1 | docker build -f CMD.dockerfile -t test . |
运行容器
1 | > docker run test |
运行容器并追加命令
1 | > docker run test -l |
- 看到可执行文件找不到的报错,executable file not found
- 跟在镜像名后面的是 command,运行时会替换 CMD 的默认值,因此这里的 -l 替换了原来的 CMD,而不是追加在原来的 ls -a 后面
- 而 -l 根本不是命令,所以自然找不到
如果想加入 -i 参数,必须重写 ls 命令
1 | > docker run test ls -a -l |
可以了,但这明显不是最优选择,ENTRYPOINT 就可以解决这个问题
测试 ENTRYPOINT
编写 dockerfile 文件
1 | FROM centos ENTRYPOINT ["ls","-a"] |
构建镜像
1 | docker build -f ENTRYPOINT.dockerfile -t test . |
运行容器并追加命令
1 | > docker run test -l |
ENTRYPOINT 的第二个应用场景
- 启动容器就是启动主进程,但启动主进程前,可能需要一些准备工作,比如 mysql 可能需要一些数据库配置、初始化的工作,这些工作要在最终的 mysql 服务器运行之前解决
- 还可能希望避免使用 root 用户去启动服务,从而提高安全性,而在启动服务前还需要以 root 身份执行一些必要的准备工作,最后切换到服务用户身份启动服务
- 这些准备工作是和容器 CMD 无关的,无论 CMD 为什么,都需要事先进行一个预处理的工作,这种情况下,可以写一个脚本,然后放入 ENTRYPOINT 中去执行,而这个脚本会将接到的参数(也就是
)作为命令,在脚本最后执行
官方镜像 redis
1 | FROM alpine:3.4 |
docker-entrypoint.sh
1 | #!/bin/sh |
该脚本的内容就是根据 CMD 的内容来判断,如果是 redis-server 的话,则切换到 redis 用户身份启动服务器,否则依旧使用 root 身份执行
1 | [root@poloyy ~]# docker run -it redis id |