纵有千金何道富,不如复载五车书
Dockerfile文件由一些列的指令组成,它是用来构建docker镜像的,类似于java的.java文件(dockerfile),使用javac编译(构建)成.class文件(images),不过这里构建docker镜像不是使用javac,而是使用docker build命令来构建的。
用法
docker build命令可以通过Dockerfile这个文件里的指令和指定的上下文目录(递归)来进行构建,命令如下:
docker build [-f Dockerfile] .
-f 表示可以指定Dockerfile的路径,后面的点(当前目录)指定要进行构建的上下文目录,这个目录可以是本地文件的目录,也可以是远程的git目录(URL),一般Dockerfile和需要构建的上文目录放在一起,这样在上下文目录直接运行docker build .
就可以进行构建了。
构建命令不是docker cli执行的,而是docker daemon执行,一旦执行,docker cli将会发送指定的上下文目录(递归)到docker daemon进行处理,构建的上下文千万不要指定/(根目录)
.dockerignore文件
在docker cli发送指定上下文目录给docker daemon之前,它首先会在指定的上下文目录的根路径上寻找是否有.dockerignore文件,如果有,它将会把里面的文件排除再发发送给docker daemon。
文件里的格式如下:
comment
/tmp*
tmp?
*.tmp
rule | behavior |
---|---|
#comment | #后面跟注释 |
*/tmp* | 表示在上下文目录中的任意一级子目录中,只要文件名首字母为tmp的将被排除,如:/somedir/tmpzdf |
*/*/tmp* | 表示在上下文目录中的任意二级子目录中,只要文件名首字母为tmp的将被排除,一级子目录下的将不会被排除,如:/somedir/subdir/tmpzdf |
*/.tmp | 表示将排除上下文目录(递归)中所有以.tmp为后缀的文件 |
tmp? | 表示在上下文目录下的tmp开头只有一个字符结尾的文件将被排除,如:tmpz,tmpd |
*.tmp | 表示在上下文目录下后缀为.tmp的文件将被排除 |
!*.tmp | 表示在上下文目录下后缀为.tmp的文件将不会被排除 |
FROM
格式
FROM <image> [AS <name>]
FROM <image>[:<tag>] [AS <name>]
FROM <image>[@<digest>] [AS <name>]
FROM 指令后面需要写一个已存在的镜像作为基础镜像,这个镜像可以是私有仓库的镜像,也可以是公共仓库下的镜像,类似于代码中的继承。一个有效的Dockerfile文件必须是要有FROM指令且FROM指令需要在文件的最开始就出现(除了ARG指令)。
- FROM指令可以在一个Dockerfile文件出现多次,它可以创建出多个镜像,使用前一个创建出来的镜像作为另一个镜像的依赖。最终最后一个镜像会被保存,其他镜像会被清除,这个特性在构建程序时特别有用,它可以减少镜像的大小和层数。
- FROM指令的可选字段name,在构建多个镜像时特别有用,它可以通过命令FROM,COPY 的--from=<name|index>来引用相应镜像里的文件。
- tag标签是可选的,如果忽略它们,那么默认为latest。
LABEL
格式
LABEL <key>=<value> <key>=<value> <key>=<value> ...
LABEL指令为镜像提供元数据,它是一组键值对。一个镜像可以拥有超过一个的LABEL标签如下:
.
LABEL multi.label1="value1" \
multi.label2="value2" \
other="value3"
你可以使用docker inspect <image>
查看镜像的标签,标签具有继承特性,这里将会包括镜像本身的标签和基础镜像的标签(FROM base),如果它们有相同的键但是值不同,那么最新的标签将会覆盖之前的标签。
MAINTAINER
格式
````MAINTAINER <author name>``
用于设置制作镜像的作者的名字,不过这个指令已经过时,由LABEL指令代替。例如:LABEL maintainer="SvenDowideit@home.org.au"
ENV
格式
ENV <key> <value>
ENV <key>=<value> <key>=<value> ...
ENV指令用于指定环境变量,在构建镜像的过程中会被后续的RUN指令用到,在容器启动后也会存在于容器中,常用设置应用的数据库名和密码注入。在运行容器时可以通过docker run --env <key>=<value>
来覆盖环境变量。一般使用第二种形式来设置环境变量,用\来进行换行,例如:
.
ENV url="mysql" \
username="root" \
password="root"
注意,环境变量的持久性也可能造成一些问题,例如
ENV DEBIAN_FRONTEND noninteractive
,它会让使用 Debian作为基础镜像构建的用户在运行apt-get时看不到输出,所以为了只对单一命令方式生效,请使用这种方式:RUN <key>=<value> <command>.
ADD
格式
ADD [--chown=<user>:<group>] <src>... <dest>
ADD [--chown=<user>:<group>] ["<src>",... "<dest>"] (this form is required for paths containing whitespace)
注意:--chown参数只支持在Linux系统下运行的容器镜像。
ADD指令将复制文件,目录或者远程URL文件到镜像中的<dest>路径下。
<src>,你可以用过通配符指定多个文件或者目录,它们的路径是相对于你的上下文目录的。例如:
.
ADD hom* /mydir/
# 添加所有以hom开头文件
ADD hom?.txt /mydir/
#添加以hom开头,接一个字符,以.txt结尾的文件,如:home.txt
<dest>路径可以是一个绝对路径,也可以是一个相对于WORKDIR的相对路径。例如:
ADD test relativeDir/
# 添加test文件到WORKDIR
/relativeDir/下
ADD test /absoluteDir/
# 添加test文件到/absoluteDir/下
所有复制到镜像中的文件或目录的uid和gid都为0,除非使用--chown标签指定用户和用户组,如下:
.
ADD --chown=55:mygroup files* /somedir/
ADD --chown=bin files* /somedir/
ADD --chown=1 files* /somedir/
ADD --chown=10:11 files* /somedir/
注意:如果你的镜像文件系统不包含/etc/passwd和/etc/group文件,那么你在指定--chown标签时需要使用数字,不能使用用户名或用户组,因为它们不能使用相应的文件解释成数字。
另外ADD指令还需要遵循下列规则:
<src>目录必须是上下文目录里面的,你不能添加其他目录,因为
docker build
是把上下文目录发送到docker daemon。如果<src>是URL,且<dest>不是以/结尾,那么URL的内容会被复制到<dest>目录下,不包括原来的目录。如果<dest>是以/结尾,那么URL的内容包括它的名字都会复制到<dest>目录下,如 ADD https://example.com/filename /example/,那么它会在/example目录下创建一个名为filename的文件或目录(/example/filename)。
如果<src>是一个目录,那么它目录下的内容将全部复制到<dest>下,不包括<src>目录本身。
如果<src>是一个.tar文件,它将会解压复制到<dest>目录下。
如果<src>是指多个资源,那么<dest>目录一定要以/结尾。
如果<src>是一个文件,<dest>没有以/结尾,它将把<src>文件的内容写到<dest>文件,如果<dest>以/结尾,那么它将被复制到<dest>目录下。
如果<dest>目录不存在,那么它将会在相应的路径上自动创建。
COPY
格式
COPY [--chown=<user>:<group>] <src>... <dest>
COPY [--chown=<user>:<group>] ["<src>",... "<dest>"] (this form is required for paths containing whitespace)
COPY指令和ADD指令基本是一样的,需要注意的是COPY指令不支持URL和.tar的压缩文件,在Dockerfile的最佳实践中,如果没有涉及到使用URL或者.tar的压缩文件,推荐使用COPY指令。
EXPOSE
格式
EXPOSE <port> [<port>/<protocol>...]
EXPOSE指令通知Docker daemon容器在运行时监听的端口,你可以指定监听端口的协议是TCP还是UDP,默认是TCP。EXPOSE指令并不会真正的去暴露一个端口或者是打开一个端口,它只是作为文档性的功能,意味着这个端口是构建镜像的人想要去暴露的,运行镜像的人你可以选择去暴露或者不暴露,你可以使用-p hostPort:contanerPort去指定主机上的一个端口或多个端口进行映射,也可以直接使用-P标签,这样它将会把镜像里想要暴露的端口都映射到主机的高端口上去。如下:
.
EXPOSE 80/tcp
EXPOSE 80/udp
指定主机端口映射
docker run -p 80:80/tcp -p 80:80/udp ...
随机映射主机的高位端口
docker run -P ...
VOLUME
格式
VOLUME ["/dir"]
VOLUME /dir1 /dir2
VOLUME指令将会在容器内创建一个相应名字挂载点,它可以挂载本地主机的目录或者其他容器的目录。
当执行docker run
命令初始化一个新的volume,这个volume可能会包含已经在镜像文件中的数据。如下:
FROM ubuntu
RUN mkdir /myvol
RUN echo "hello world" > /myvol/greeting
VOLUME /myvol
执行docker run
命令时,它会创建一个新的挂载点/myvol,并把greeting文件复制到新的挂载点下。
VOLUME指令有一些注意事项如下:
- 如果你使用的是基于windows的容器,那么你卷的目录除了不能是C盘,目录也必须不存在或者为空;
- 在build阶段, 任何在声明VOLUME目录之后的对VOLUME进行的数据操作,都将无效。
- 当使用第一种格式时,必须使用双引号
- Dockerfile中不能指定主机目录,主机目录只能在容器创建时指定。
USER
USER <user>[:<group>]
USER <UID>[:<GID>]
USER指令是设置用户和组的,当镜像运行时或者是Dockerfile文件接下来运行命令的指令RUN,,CMD,ENTRYPOINT时,将以指定的USER去运行。
注意:如果一个用户没有指定属组,那么它将以root组的身份去运行命令
WORKDIR
格式
WORKDIR /path/to/workdir
WORKDIR指令将会为接下来的Dockerfile文件中的RUN, CMD, ENTRYPOINT, COPY 和 ADD 指令设定工作目录。如果WORKDIR指定的目录不存在,那么它将会创建,而且在Dockerfile文件中你可以指定多个WORKDIR指令,如果任何指令中给定一个相对路径,那么它是相对于上一个WORKDIR目录。如下
WORKDIR /a
WORKDIR b
WORKDIR c
RUN pwd
输出将会是/a/b/c
同时WORKDIR还支持环境变量,如下
ENV DIRPATH /path
WORKDIR $DIRPATH/$DIRNAME
RUN pwd
输出将会是/path/$DIRNAME
RUN
格式
RUN <command>
```RUN ["executable", "param1", "param2"] ``
RUN指令是指运行指定的命令,每条RUN指令将会在当前镜像的基础上执行命令,并提交为新的镜像,以供接下来Dockerfile各个步骤使用。上面第一种格式将启动shell终端运行命令,默认是/bin/sh -c;第二种格式使用exec执行,不会启动shell环境,另外,如果需要制定其他shell终端运行命令,通过第二种格式可以实现,例如RUN ["/bin/bash", "-c", "echo hello"]
使用第二种格式必须使用双引号来包括命令
CMD
格式
CMD ["executable","param1","param2"] (exec form, this is the preferred form)
CMD ["param1","param2"] (as default parameters to ENTRYPOINT)
CMD command param1 param2 (shell form)
CMD指令主要是为容器提供默认的执行指令,当它和ENTRYPOINT指令共存时,CMD指令主要是为ENTRYPOINT指令提供默认参数。关于CMD作为执行命令的两种形式的区别,可以参考之前的RUN命令。
使用shell形式
FROM ubuntu
CMD echo "This is a test." | wc -
使用exec形式
FROM ubuntu
CMD ["/usr/bin/wc","--help"]
如果你需要容器每次运行都使用相同的指令和不同的参数,那么你可以考虑结合ENTRYPOINT和CMD使用,当你使用docker run
命令时,后面接上参数将会覆盖CMD命令。
注意:在Dockerfile文件中只能有一个CMD指令,如果有多个,那么只有最新的那一个会产生作用。
ENTRYPOINT
格式
ENTRYPOINT ["executable", "param1", "param2"] (exec form, preferred)
ENTRYPOINT command param1 param2 (shell form)
ENTRYPOINT运行你把一个容器配置为可执行的一个进程,如下:
docker run -i -t --rm -p 80:80 nginx
它将会启动一个只包含nginx进程的容器,即nginx进程在容器里pid为1。
如果以docker run <image>
运行容器,那么它的参数例如 -d将会以exec形式追加到ENTRYPOINT指令第一种形式(exec form)的后面,如/bin/nginx -d
。如果你在运行时指定了CMD参数,那么它将会覆盖Dockerfile中所有已定义的CMD参数。你可以使用--entrypoint来覆盖ENTRYPOINT指令。
如果Dockerfile中使用的是第二种形式构建镜像,那么容器在启动时它的/bin/sh将会是1号进程,ENTRYPOINT指令将是它的子命令,这就意味着不能传入任何进程信号,那么在运行docker stop时,我容器里的nginx将不会收到SIGTERM信号,就不会优雅的退出。
CMD与ENTRYPOINT
CMD和ENTRYPOINT指令都定义了在运行容器时执行的命令,它们需要遵守怎样的规则?又有什么区别呢?
- Dockerfile文件应该制定至少一个CMD指令或者ENTRYPOINT指令。
- 当使用容器作为一个可执行的进程时,应该选用ENTRYPOINT指令。
- CMD指令应该作为参数的形式为ENTRYPOINT指令提供默认参数。
- 当运行容器时使用可选的参数将会覆盖CMD指令。
下表展示了两个命令在执行期间进行协作的效果:
NO ENTRYPOINT | ENTRYPOINT exec_entry p1_entry | ENTRYPOINT [“exec_entry”, “p1_entry”] | |
---|---|---|---|
No CMD | error | /bin/sh -c exec_entry p1_entry | exec_entry p1_entry |
CMD [“exec_cmd”, “p1_cmd”] | exec_cmd p1_cmd | /bin/sh -c exec_entry p1_entry | exec_entry p1_entry exec_cmd p1_cmd |
CMD [“p1_cmd”, “p2_cmd”] | p1_cmd p2_cmd | /bin/sh -c exec_entry p1_entry | exec_entry p1_entry p1_cmd p2_cmd |
CMD exec_cmd p1_cmd | /bin/sh -c exec_cmd p1_cmd | /bin/sh -c exec_entry p1_entry | exec_entry p1_entry /bin/sh -c exec_cmd p1_cmd |