docker DockerFile技术

92 阅读9分钟

什么是docker DockerFile技术

Docker通过读取Dockerfile里面的内容可以自动build image,Dockerfile是一个包含了build过程中需要执行的所有命令的文本文件。也可以理解为Dockfile是一种被Docker程序解释的脚本,由一条一条的指令组成,每条指令对应Linux系统下面的一条命令,由Docker程序将这些Dockerfile指令翻译成真正的Linux命令。Dockerfile有自己书写格式和支持的命令,Docker程序解决这些命令间的依赖关系,类似于Makefile。

Docker程序将读取Dockerfile,根据指令生成定制的image。相比image这种黑盒子,Dockerfile这种显而易见的脚本更容易被使用者接受,它明确的表明image是怎么产生的。有了Dockerfile,当我们需要定制自己额外的需求时,只需在Dockerfile上添加或者修改指令,重新生成image即可,省去了敲命令的麻烦。

Dockerfile的不足:

  1. 层数过多:过多行的Dockerfile
  2. 不能清理volume等配置:volume、expose等多个参数只能单向增加。不能删除。比如在某个镜像层加入了VOLUME /var/lib/docker。那么在该镜像之后的所有层将继承这一属性。
  3. IMPORT功能

比如在搜索hub.docker.com/_/centos 选择其中一个版本的centos去GitHub看一下镜像,示例如下图

Dockerfile编写规则及指令说明

Dockerfile的指令是忽略大小写的,建议使用大写,使用#作为注释,每一行只支持一条指令,每条指令可以携带多个参数。

Dockerfile的指令根据作用可以分为两种:构建指令和设置指令。构建指令用于构建image,其指定的操作不会在运行image的容器上执行;设置指令用于设置image的属性,其指定的操作将在运行image的容器中执行,理解示意图

FROM(指定基础image)

构建指令,必须指定且需要在Dockerfile其他指令的前面。后续的指令都依赖于该指令指定的image。FROM指令指定的基础image可以是官方远程仓库中的,也可以位于本地仓库。

该指令有两种格式:

1FROM <image>

指定基础image为该image的最后修改的版本。或者:

1FROM <image>:<tag>

指定基础image为该image的一个tag版本。

MAINTAINER(用来指定镜像创建者信息)

构建指令,用于将image的制作者相关的信息写入到image中。当我们对该image执行docker inspect命令时,输出中有相应的字段记录该信息。格式:

1MAINTAINER <name>

RUN(执行命令)

构建指令,RUN可以运行任何被基础image支持的命令。如基础image选择了centos,那么软件管理部分只能使用centos的命令。该指令有两种格式:

12RUN <command> (the command is run in a shell - `/bin/sh -c`)RUN ["executable", "param1", "param2" ... ] (exec form)

CMD(设置容器启动时执行的操作)

设置指令,用于container启动时指定的操作。该操作可以是执行自定义脚本,也可以是执行系统命令。该指令只能在文件中存在一次,如果有多个,则只执行最后一条。该指令有三种格式:

12CMD ["executable","param1","param2"] (like an exec, this is the preferred form)CMD command param1 param2 (as a shell)

CMD主要用于container时启动指定的服务,当Docker run command的命令匹配到CMD command时,会替换CMD执行的命令。

当Dockerfile指定了ENTRYPOINT,那么使用下面的格式:

1CMD ["param1","param2"] (as default parameters to ENTRYPOINT)

ENTRYPOINT指定的是一个可执行的脚本或者程序的路径,该指定的脚本或者程序将会以param1和param2作为参数执行。所以如果CMD指令使用上面的形式,那么Dockerfile中必须要有配套的ENTRYPOINT。

ENTRYPOINT(设置容器启动时执行的操作)

container启动时执行的命令,但是一个Dockerfile中只能有一条ENTRYPOINT命令,如果多条,则只执行最后一条。ENTRYPOINT没有CMD的可替换特性。两种格式:

12ENTRYPOINT ["executable", "param1", "param2"] (like an exec, the preferred form)ENTRYPOINT command param1 param2 (as a shell)

该指令的使用分为两种情况,一种是独自使用,另一种和CMD指令配合使用。

当独自使用时,如果你还使用了CMD命令且CMD是一个完整的可执行的命令,那么CMD指令和ENTRYPOINT会互相覆盖只有最后一个CMD或者ENTRYPOINT有效。

123# CMD指令将不会被执行,只有ENTRYPOINT指令被执行;CMD echo "Hello, World!"ENTRYPOINT ls -l

另一种用法和CMD指令配合使用来指定ENTRYPOINT的默认参数,这时CMD指令不是一个完整的可执行命令,仅仅是参数部分;ENTRYPOINT指令只能使用JSON方式指定执行命令,而不能指定参数。

123FROM ubuntuCMD ["-l"]ENTRYPOINT ["/usr/bin/ls"]

USER(设置容器的用户)

设置指令,设置启动容器的用户,默认是root用户。

123# 指定memcached的运行用户;ENTRYPOINT ["memcached"]USER daemon

1ENTRYPOINT ["memcached", "-u", "daemon"]

EXPOSE(暴露容器端口)

EXPOSE可以用来暴露端口,或者在docker run时指定 --expose=1234,这两种方式作用相同。但是, --expose可以接受端口范围作为参数,比如 --expose=2000-3000。但是,EXPOSE和 --expose都不依赖于宿主机器。默认状态下,这些规则并不会使这些端口可以通过宿主机来访问。

基于EXPOSE指令的上述限制,Dockerfile的作者一般在包含EXPOSE规则时都只将其作为哪个端口提供哪个服务的提示。使用时,还要依赖于容器的操作人员进一步指定网络规则,需要配合 docker run -p PORT:EXPORT使用,这样EXPOSE设置的端口号会被指定需要映射到宿主机器的端口,这时要确保宿主机器上的端口号没有被使用。如果直接指定 docker run-p EXPORT,这样EXPOSE设置的端口号会被随机映射成宿主机器中的一个端口号。不过通过EXPOSE命令文档化端口的方式十分有用。

本质上说,EXPOSE或者 --expose只是为其他命令提供所需信息的元数据(比如容器间link操作就依赖EXPOSE元数据),或者只是告诉容器操作人员有哪些已知选择。

格式:

1EXPOSE <port> [<port>...]

EXPOSE指令可以一次设置多个端口号,相应的运行容器的时候,可以配套的多次使用-p选项。

1234567891011121314# 暴露一个端口;EXPOSE port1 # 如果想代理EXPOSE端口, 相应的运行容器使用的命令;docker run -p port1 image # 暴露多个端口;EXPOSE port1 port2 port3 # 如果想代理EXPOSE端口, 相应的运行容器使用的命令;docker run -p port1 -p port2 -p port3 image # 还可以指定需要映射到宿主机器上的某个端口号;docker run -p host_port1:port1 -p host_port2:port2 -p host_port3:port3 image

注意,EXPOSE仅仅是暴露一个端口,一个标识,在没有定义任何端口映射时,外部是无法访问到容器提供的服务。而端口映射(-p)是docker比较重要的一个功能,原因在于我们每次运行容器的时候容器的IP地址不能指定,而是在桥接网卡的地址范围内随机生成的。宿主机器的IP地址是固定的,我们可以将容器的端口的映射到宿主机器上的一个端口,免去每次访问容器中的某个服务时都要查看容器的IP的地址。对于一个运行的容器,可以使用docker port加上容器ID和EXPOSE暴露的端口来查看该端口号在宿主机器上的映射端口。

12$ docker port redis 63790.0.0.0:6380

ENV(用于设置环境变量)

构建指令,在image中设置一个环境变量。格式:

1ENV <key> <value>

设置了后,后续的RUN命令都可以使用,container启动后,可以通过docker inspect查看这个环境变量,也可以通过在docker run –env key=value时设置或修改环境变量。

假如你安装了JAVA程序,需要设置JAVA_HOME,那么可以在Dockerfile中这样写:

1ENV JAVA_HOME /path/to/java/dirent

 ADD(从src复制文件到container的dest路径)

构建指令,所有拷贝到container中的文件和文件夹权限为0755,uid和gid为0;如果是一个目录,那么会将该目录下的所有文件添加到container中,不包括目录;如果文件是可识别的压缩格式,则docker会帮忙解压缩(注意压缩格式);如果<src>是文件且<dest>中不使用斜杠结束,则会将<dest>视为文件,<src>的内容会写入<dest>;如果<src>是文件且<dest>中使用斜杠结束,则会<src>文件拷贝到<dest>目录下。
格式:

1ADD <src> <dest>

<src>:是相对被构建的源目录的相对路径,可以是文件或目录的路径,也可以是一个远程的文件url。

<dest>:是container中的绝对路径。

VOLUME(指定挂载点)

设置指令,使容器中的一个目录具有持久化存储数据的功能,该目录可以被容器本身使用,也可以共享给其他容器使用。我们知道容器使用的是AUFS,这种文件系统不能持久化数据,当容器关闭后,所有的更改都会丢失。当容器中的应用有持久化数据的需求时可以在Dockerfile中使用该指令。格式:

1VOLUME ["&lt;mountpoint&gt;"]

 

12FROM baseVOLUME ["/tmp/data"]

运行通过该Dockerfile生成image的容器,/tmp/data目录中的数据在容器关闭后,里面的数据还存在。例如另一个容器也有持久化数据的需求,且想使用上面容器共享的/tmp/data目录,那么可以运行下面的命令启动一个容器:

1$ docker run -t -i -rm -volumes-from container1 image2 bash

container1为第一个容器的ID,image2为第二个容器运行image的名字。

WORKDIR(切换目录)

设置指令,可以多次切换(相当于cd命令),对RUN,CMD,ENTRYPOINT生效。格式:

1WORKDIR /path/to/workdir

 

12# 在/p1/p2下执行vim a.txt;WORKDIR /p1 WORKDIR p2 RUN vim a.txt

ONBUILD(在子镜像中执行)

1ONBUILD <Dockerfile关键字>

ONBUILD指定的命令在构建镜像时并不执行,而是在它的子镜像中执行。

---------------------------------------------------------------------------------------------------------------------------------------------------------------------

如何做Dockerfile

Dockerfile调试

Dockerfile更多的像一个脚本,类似于安装脚本。特别是大篇幅的脚本,想一次写成是比较有难度的。免不了进行一些调试。调试时最好利用Dockerfile的cache功能,可以大幅度节约调试的时间。

举个例子,如果我现在有一个Dockerfile。但是我发现。我还需要再开几个端口,或者再安装其他的软件。这个时候最好不要直接修改已经有的Dockerfile的内容。而是在后面追加命令。这样再build的时候,可以利用已有的cache。

Dockerfile优化

调试过后的Dockerfile当然可以作为最终的Dockerfile,提供给用户。但是调试的Dockerfile的缺点就是层数可能过多,而且不易越多。所以最好进行一定的优化和整理。经过整理的Dockerfile生成出来的镜像可以使得层数更少,条理更清晰,也可以更好的复用。

DockerOne里有一篇文章写得很好,可以参考。

这里有两点要强调:

  • 尽量生成一个base:这样便于版本的迭代和作为公用镜像。
  • 清晰的注释:有一些注释会帮助别人理解这些命令的目的


Dockerfile自动build

有了Dockerfile,很多人都是在本地build。其实这个是相当耗时的。这个工作其实完全可以交给registry.hub.docker.com来完成。

具体的做法就是:

  1. 把你的Dockerfile上传到GitHub上。
  2. 进入到registry.hub.docker.com的自己的账户中,选择Automated Build。
  3. 然后就可以build了。


根据你的Dockerfile内容大小,build时长不确定。但是应该算是比较快了。docker源码的Dockerfile在我本地build了一个多小时。但是registry.hub.docker.com只用了半小时左右。大约是因为外国的月亮比较圆吧。

build完成后,可以在线查看版本信息等。本地需要的话,可以直接pull下来。

国内有多家公司提供了registry.hub.docker.com的Mirror服务,可以直接从国内的源中pull下来。速度快很多。