Docker进阶-一-DockerFile解析

目录

    • 在这里插入图片描述
    • 构建过程解析
    • 保留字
      • FROM
      • MAINTAINER
      • RUN
      • EXPOSE
      • WORKDIR
      • USER
      • ENV
      • VOLUME
      • COPY
      • ADD
      • CMD
      • ENTRYPOINT
      • 总结
    • 参考

Dockerfile是用来构建Docker镜像的文本文件,是由一条条构建镜像所需的指令和参数构成的脚本,类似于Linux的MakeFile。现在,假设我们需要构建一个包含vim/ifconfig的ubuntu镜像,我们需要run一个原始ubuntun镜像,然后在其中安装vim/ifconfig,最后通过commit来生成镜像。但是,如果需要多次安装,就要多次重复上述commit步骤,很麻烦。那么,能不能将需要安装的东西列一个清单,然后一次性搞定呢?==> Dockerfile。

Dockerfile就像一个图纸,把镜像需要安装的东西全部写进去,然后build生成镜像时一口气直接装完。可以看到,commit是通过Container来生成镜像的,而Dockerfile则不需要操作者通过手动运行Container来对镜像进行增强。

Docker进阶-一-DockerFile解析_第1张图片

构建过程解析

每条保留字指令都必须为大写字母,且后面要跟随至少一个参数,如COPY保留字:
Docker进阶-一-DockerFile解析_第2张图片
指令按照从上到下,顺序执行,每条指令都会创建一个新的镜像层并对镜像进行提交,#表示注释。至于镜像层,简单来说,就是Docker镜像是一层层构成的,这样才能使我们可以在一个初始镜像的基础上生成新的镜像,具体分层概念将在下一篇博客中讲述。

【Dockerfile执行流程】

1> Docker从基础镜像运行一个Container。

2> 顺序执行一条指令并对Container作出修改。

3> 执行类似commit的操作来提交一个新的镜像层。

4> Docker再基于刚提交的镜像运行一个新的Container。

5> 执行Dockerfile中的下一条指令直到所有指令都执行完成。

从应用软件的角度来看,Dockerfile、Docker镜像与Docker容器分别代表了软件的三个不同阶段:

Dockerfile使软件的设计图纸

Docker镜像使软件的交付品

Docker容器则是软件镜像的运行态,也即运行实例

Docker进阶-一-DockerFile解析_第3张图片

总的来说,Dockerfile定义了最终的容器进程需要的一切东西。Dockerfile涉及的内容包括执行代码或者是文件、环境变量、依赖包、运行时环境、动态链接库、操作系统的发行版、服务进程和内核进程(当应用进程需要和系统服务和内核进程打交道时,需要考虑如何设计namespace的权限控制)等等。


保留字

参考tomcat8的Dockerfile入门:https://github.com/docker-library/tomcat,这里罗列了12个最常用的保留字。

FROM

基础镜像,说明当前新镜像是基于哪个镜像的,指定一个已经存在的镜像作为模板,Dockerfile的第一条指令必须是FROM。

FROM [--platform=]  [AS ]  # or
FROM [--platform=] [:] [AS ]  #or
FROM [--platform=] [@] [AS ]

MAINTAINER

可以通过该保留字留下维护者的姓名和邮箱地址,非必须。

MAINTAINER 

新版本中,官方建议用LABEL来替代它:

LABEL org.opencontainers.image.authors="[email protected]"

RUN

容器构建镜像时需要运行的命令,有两种格式,shell格式和exec格式。注意,RUN是在docker build时运行的,那为什么会和容器有关呢?就像前文说的,dockerfile每一条指令实质上就是在前一步运行的新的Container上进行操作,然后通过类似commit的操作来构建新镜像,所以实际上是对容器的操作。两种格式分别为:

# shell 格式
RUN <命令行命令>
# <命令行命令>等同于,在容器终端操作的shell命令。
# exec 格式
RUN ["可执行文件","参数1","参数2"]
# RUN ["./test.php", "dev", "offline"]等价于RUN ./test.php dev offline

以shell格式为例,如果我们想要安装vim,那么在容器中就需要使用命令yum -y install vim,然后出容器使用docker commit来构建镜像。现在有了dockerfile,只需要在其中加一句RUN yum -y install vim即可,docker运行完该指令会自动commit。

EXPOSE

暴露出容器将要提供服务所开放的端口,严格来说,是用该dockerfile构建的镜像,运行出的容器提供的服务对外暴露的端口。

EXPOSE <端口1>[/传输格式] [<端口2>[/传输格式]...]
# EXPOSE 8080/tcp

注意,EXPOSE指令是声明运行时容器提供服务端口,这只是一个声明,在运行时并不会因为这个声明就开启这个端口的服务。在Dockerfile中写入这样的声明有两个好处,一个是帮助镜像使用者理解这个镜像服务的守护端口,以方便配置映射;另一个用处则是在运行时使用随机端口映射时,也就是docker run -P时,会自动随机映射EXPOSE的端口。

要将EXPOSEdocker run -p <宿主端口>:<容器端口>区分开来。-p,是将宿主端口映射向容器端口,也就是说将容器端口向宿主机外暴漏。而EXPOSE,仅仅是声明容器内暴露的端口。

一般使用docker run -p <宿主端口>:EXPOSE端口来指定宿主机端口和该容器暴露端口的映射,或者使用-P来进行随机映射。这样一想,我们最终在外部直接访问的仍然是宿主机上的端口,EXPOSE只是在设置-p/-P时提醒操作者容器内服务的端口是多少,从而构成映射吗,是不是有些鸡肋?我个人觉得是的,它只是起到声明和提醒的作用。

但是,EXPOSE也有中有趣的玩法,那就是不使用端口映射,让端口直接暴露在宿主机外。怎么做?==> host模式。在docker run时设置--net=host,这样一来容器就和宿主机公用同样的网络配置,包括端口。运行之后,使用docker inspect containerID发现没有任何端口映射信息,因为容器的端口直接就是宿主机的端口。
Docker进阶-一-DockerFile解析_第4张图片

这样一来,就可以在使用EXPOSE端口来访问容器内的服务了,不再需要-p/-P映射。

WORKDIR

指定构建的镜像运行出容器后,终端默认的初始工作目录,也就是落脚点。比如,tomcat容器的落脚点为/usr/local/tomcat,它的dockerfile就这样写:

ENV CATALINA_HOME /usr/local/tomcat
# ...
WORKDIR $CATALINA_HOME

USER

指定该镜像以什么样的用户去执行,如果都不指定,默认为root

USER [:] #or
USER [:]

ENV

用来在构建镜像过程中设置环境变量,注意,是构建过程中,不是构建后。这个环境变量可以在后续的任何RUN指令中使用,也可以在其他指令中直接使用,比如WORKDIR,引用时加$

ENV NAME VALUE

VOLUME

容器数据卷,不用多说,相当于docker run -v ...,用于数据保存和持久化工作。

FROM ubuntu
RUN mkdir /myvol
RUN echo "hello world" > /myvol/greeting
VOLUME /myvol

上述指令会在容器的/myvol目录下设置一个挂载点,并在宿主机上创建一个数据卷和其相关联,由于没有指定宿主机目录,所以是默认的,类似于 docker run -v /myvol 镜像名。可以使用docker inspect 容器名/ID来查看相关联的宿主机目录的路径,会发现数据卷名是一串编号:

/var/lib/docker/volumes/0ab0aaf0d6ef391cb68b72bd8c43216a8f8ae9205f0ae941ef16ebe32dc9fc01/_data

当然,也可以同时创建多个挂载点,每个挂载点都有独立的数据卷:

VOLUME ["/data1","/data2"]
"Mounts": [
        {
            "Name": "d411f6b8f17f4418629d4e5a1ab69679dee369b39e13bb68bed77aa4a0d12d21",
            "Source": "/var/lib/docker/volumes/d411f6b8f17f4418629d4e5a1ab69679dee369b39e13bb68bed77aa4a0d12d21/_data",
            "Destination": "/data1",
            "Driver": "local",
            "Mode": "",
            "RW": true
        },
        {
            "Name": "6d3badcf47c4ac5955deda6f6ae56f4aaf1037a871275f46220c14ebd762fc36",
            "Source": "/var/lib/docker/volumes/6d3badcf47c4ac5955deda6f6ae56f4aaf1037a871275f46220c14ebd762fc36/_data",
            "Destination": "/data2",
            "Driver": "local",
            "Mode": "",
            "RW": true
        }
    ],

COPY

把宿主机目录下的文件和目录拷贝进镜像中,将从构建上下文目录中 <源路径> 的文件/目录复制到新的一层的镜像内的 <目标路径> 位置。

COPY src dest #or
COPY ["src","dest"]
# :源文件或者源目录
# :容器内的指定路径,该路径不用事先建好,路径不存在的话,会自动创建

ADD

将宿主机目录下的文件拷贝进镜像且会自动处理URL和解压tar压缩包,即COPY的升级版:COPY+解压,一般用这个就行。

CMD

指定容器启动后要干的事情。注意,这个容器是运行最终镜像的容器,而不是构建镜像过程中的临时容器,也就是说,这个时候已经和镜像的构建无关了。

RUN是在docker build时运行

CMD是在docker run时运行

CMD指令和RUN的格式相似,外加了一个参数列表格式:

# shell 格式
CMD <命令>
# exec 格式
CMD ["可执行文件","参数1","参数2"...]
# 参数列表格式,在指定了ENTRYPOINT后,用CMD指定具体参数
CMD ["参数1","参数2"...]

Dockerfile中可以有多个CMD指令,但只有最后一个生效,并且,CMD会被docker run设定的运行命令替换。比如,tomcat的dockerfile的最后一行为:

CMD ["catalina.sh", "run"]

即,运行tomcat容器后会在WORKDIR下执行命令catalina.sh run。但是,如果在docker run之后加入了/bin/bash,就会发现tomcat服务并没有启动,因为原本应该执行的catalina.sh run被自己写的/bin/bash覆盖了,因此只启动了容器,并没有启动服务。

ENTRYPOINT

也是用来指定一个容器启动时要运行的命令,类似于CMD指令,但不同的是,ENTRYPOINT不会被docker run后面的命令覆盖,而且这些命令行参数会被当作参数送给ENTRYPOINT指令指定的程序。

# exec 格式
ENTRYPOINT ["executable", "param1", "param2"]
# shell 格式
ENTRYPOINT command param1 param2

ENTRYPOINT可以和CMD一起使用,一般是变参才会使用CMD,这里的CMD等于是在给ENTRYPOINT传参。当指定了ENTRYPOINT之后,CMD的含义就发生了变化,不再是直接运行其命令,而是将CMD的内容作为参数传递给ENTRYPOINT,它们两个组合成 来执行。

比如,通过Dokcerfile构建nginx:test镜像,规定运行时指令,分为定参和变参两部分:

FROM nginx
#...
ENTRYPOINT ["nginx","-c"] # 定参
CMD ["/etc/nginx/nginx.conf"] # 变参
不传参 传参
Docker命令 docker run nginx:test docker run nginx:test /etc/nginx/new.conf
衍生出的容器命令 nginx -c /etc/nginx/nginx.conf nginx -c /etc/nginx/new.conf

如果Dockerfile中存在多个ENTRYPOINT指令,仅最后一个生效。

总结

Docker进阶-一-DockerFile解析_第5张图片

参考

[1] 尚硅谷docker教程
[2] dockerfile官方文档
[3] final-heart dockerfile EXPOSE

你可能感兴趣的:(docker,容器,运维,云计算)