使用Dockerfile构建Nginx镜像
一、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编写规则及指令说明
Dockerfile的指令是忽略大小写的,建议使用大写,使用#作为注释,每一行只支持一条指令,每条指令可以携带多个参数。
Dockerfile的指令根据作用可以分为两种:构建指令和设置指令。构建指令用于构建image,其指定的操作不会在运行image的容器上执行;设置指令用于设置image的属性,其指定的操作将在运行image的容器中执行。
- FROM(指定基础image)
构建指令,必须指定且需要在Dockerfile其他指令的前面。后续的指令都依赖于该指令指定的image。FROM指令指定的基础image可以是官方远程仓库中的,也可以位于本地仓库。
该指令有两种格式:
1 | FROM <image> |
指定基础image为该image的最后修改的版本。或者:
1 | FROM <image>:<tag> |
指定基础image为该image的一个tag版本。
- MAINTAINER(用来指定镜像创建者信息)
构建指令,用于将image的制作者相关的信息写入到image中。当我们对该image执行docker inspect命令时,输出中有相应的字段记录该信息。格式:
1 | MAINTAINER <name> |
- RUN(执行命令)
构建指令,RUN可以运行任何被基础image支持的命令。如基础image选择了centos,那么软件管理部分只能使用centos的命令。该指令有两种格式:
1 2 | RUN <command> (the command is run in a shell - `/bin/sh -c`) RUN ["executable", "param1", "param2" ... ] (exec form) |
- CMD(设置容器启动时执行的操作)
设置指令,用于container启动时指定的操作。该操作可以是执行自定义脚本,也可以是执行系统命令。该指令只能在文件中存在一次,如果有多个,则只执行最后一条。该指令有三种格式:
1 2 | CMD ["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,那么使用下面的格式:
1 | CMD ["param1","param2"] (as default parameters to ENTRYPOINT) |
ENTRYPOINT指定的是一个可执行的脚本或者程序的路径,该指定的脚本或者程序将会以param1和param2作为参数执行。所以如果CMD指令使用上面的形式,那么Dockerfile中必须要有配套的ENTRYPOINT。
- ENTRYPOINT(设置容器启动时执行的操作)
container启动时执行的命令,但是一个Dockerfile中只能有一条ENTRYPOINT命令,如果多条,则只执行最后一条。ENTRYPOINT没有CMD的可替换特性。两种格式:
1 2 | ENTRYPOINT ["executable", "param1", "param2"] (like an exec, the preferred form) ENTRYPOINT command param1 param2 (as a shell) |
该指令的使用分为两种情况,一种是独自使用,另一种和CMD指令配合使用。
当独自使用时,如果你还使用了CMD命令且CMD是一个完整的可执行的命令,那么CMD指令和ENTRYPOINT会互相覆盖只有最后一个CMD或者ENTRYPOINT有效。
1 2 3 | # CMD指令将不会被执行,只有ENTRYPOINT指令被执行; CMD echo "Hello, World!" ENTRYPOINT ls -l |
另一种用法和CMD指令配合使用来指定ENTRYPOINT的默认参数,这时CMD指令不是一个完整的可执行命令,仅仅是参数部分;ENTRYPOINT指令只能使用JSON方式指定执行命令,而不能指定参数。
1 2 3 | FROM ubuntu CMD ["-l"] ENTRYPOINT ["/usr/bin/ls"] |
- USER(设置容器的用户)
设置指令,设置启动容器的用户,默认是root用户。
1 2 3 | # 指定memcached的运行用户; ENTRYPOINT ["memcached"] USER daemon |
或
1 | ENTRYPOINT ["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元数据),或者只是告诉容器操作人员有哪些已知选择。
格式:
1 | EXPOSE <port> [<port>...] |
EXPOSE指令可以一次设置多个端口号,相应的运行容器的时候,可以配套的多次使用-p选项。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | # 暴露一个端口; 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暴露的端口来查看该端口号在宿主机器上的映射端口。
1 2 | $ docker port redis 6379 0.0.0.0:6380 |
- ENV(用于设置环境变量)
构建指令,在image中设置一个环境变量。格式:
1 | ENV <key> <value> |
设置了后,后续的RUN命令都可以使用,container启动后,可以通过docker inspect查看这个环境变量,也可以通过在docker run –env key=value时设置或修改环境变量。
假如你安装了JAVA程序,需要设置JAVA_HOME,那么可以在Dockerfile中这样写:
1 | ENV 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>目录下。
格式:
1 | ADD <src> <dest> |
<src>:是相对被构建的源目录的相对路径,可以是文件或目录的路径,也可以是一个远程的文件url。
<dest>:是container中的绝对路径。
- VOLUME(指定挂载点)
设置指令,使容器中的一个目录具有持久化存储数据的功能,该目录可以被容器本身使用,也可以共享给其他容器使用。我们知道容器使用的是AUFS,这种文件系统不能持久化数据,当容器关闭后,所有的更改都会丢失。当容器中的应用有持久化数据的需求时可以在Dockerfile中使用该指令。格式:
1 | VOLUME ["<mountpoint>"] |
1 2 | FROM base VOLUME ["/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生效。格式:
1 | WORKDIR /path/to/workdir |
1 2 | # 在/p1/p2下执行vim a.txt; WORKDIR /p1 WORKDIR p2 RUN vim a.txt |
- ONBUILD(在子镜像中执行)
1 | ONBUILD <Dockerfile关键字> |
ONBUILD指定的命令在构建镜像时并不执行,而是在它的子镜像中执行。
最后,网上有哥们提供了一张通俗易懂的构建Dockerfile文件用到的指令先后逻辑顺序及其含义,还挺有意思。
三、构建Dockerfile文件
创建一个构建nginx镜像的Dockerfile文件,Git地址:https://github.com/dongwenpeng/nginx。
1 | $ cat dockerfile |
1 2 3 4 5 6 7 8 9 10 11 12 13 | FROM nginx MAINTAINER dkey ENV RUN_USER nginx ENV RUN_GROUP nginx ENV DATA_DIR /data/web ENV LOG_DIR /data/log/nginx RUN mkdir /data/log/nginx -p RUN chown nginx.nginx -R /data/log/nginx ADD web /data/web ADD nginx.conf /etc/nginx/nginx.conf ADD default.conf /etc/nginx/conf.d/default.conf EXPOSE 80 ENTRYPOINT nginx -g "daemon off;" |
做了这么几件事:
1、拉取一个nginx镜像。
2、设置了几个变量。
3、创建了几个需要的目录。
4、把当前目录下的web程序复制到镜像的/data/web目录。
5、把nginx.conf配置文件和default.conf配置文件复制到镜像中。
6、设置一个默认端口。
7、最后设置了容器启动时执行的命令,我用来启动nginx程序,注意这个命令不能错,不然容器启动不了。这样设置后,当你docker run运行此镜像时不需要在后面再次执行需要执行的命令了。
四、构建nginx镜像
脚本写好了,需要转换成镜像(跟dockerfile在同一个目录):
1 | $ docker build -t nginx_01 . |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 | Sending build context to Docker daemon 3.43 MB Step 1 : FROM nginx latest: Pulling from library/nginx
64f0219ba3ea: Pull complete 325b624bee1c: Pull complete Digest: sha256:2a07a07e5bbf62e7b583cbb5257357c7e0ba1a8e9650e8fa76d999a60968530f Status: Downloaded newer image for nginx:latest ---> 19146d5729dc Step 2 : MAINTAINER dkey ---> Running in a9d12e4fa972 ---> 3e6bcc394986 Removing intermediate container a9d12e4fa972 Step 3 : ENV RUN_USER nginx ---> Running in 55e165c28124 ---> 024ba866269e Removing intermediate container 55e165c28124 Step 4 : ENV RUN_GROUP nginx ---> Running in 577cb4556709 ---> 95f5b6de5080 Removing intermediate container 577cb4556709 Step 5 : ENV DATA_DIR /data/web ---> Running in e472aaa991f2 ---> d50decbaf7bc Removing intermediate container e472aaa991f2 Step 6 : ENV LOG_DIR /data/log/nginx ---> Running in 5ccf9955685d ---> 00f1deefcc1b Removing intermediate container 5ccf9955685d Step 7 : RUN mkdir /data/log/nginx -p ---> Running in 63a61c463ad4 ---> 467d1548998c Removing intermediate container 63a61c463ad4 Step 8 : RUN chown nginx.nginx -R /data/log/nginx ---> Running in 00d559b2de7b ---> a550d1639d98 Removing intermediate container 00d559b2de7b Step 9 : ADD web /data/web ---> e75181ff11e0 Removing intermediate container b4c03ff5df61 Step 10 : ADD nginx.conf /etc/nginx/nginx.conf ---> 00dcb2ec895f Removing intermediate container 4a75f67c4f1c Step 11 : ADD default.conf /etc/nginx/conf.d/default.conf ---> 9b2668d59294 Removing intermediate container d57c3e297464 Step 12 : EXPOSE 80 ---> Running in 076209139acf ---> fa3247254200 Removing intermediate container 076209139acf Step 13 : ENTRYPOINT nginx -g "daemon off;" ---> Running in e0a4845172cb ---> fa37625af3ac Removing intermediate container e0a4845172cb Successfully built fa37625af3ac |
从执行过程可以看出一共十三个步骤,都完成了。
下面可以看看镜像了。
1 2 3 4 | $ docker images REPOSITORY TAG IMAGE ID CREATED SIZE nginx_01 latest fa37625af3ac 38 seconds ago 182.7 MB nginx latest 19146d5729dc 6 days ago 181.6 MB |
可以看到从官方拉取了一个nginx镜像,然后在此镜像的基础上构建了nginx_01镜像。注意,由于nginx_01是在nginx镜像的基础上构建出来的,所以如果你要删除nginx镜像是不允许的,只有先删除nginx_01镜像后才可以删除nginx镜像。
同理,你可以接着创建第二个镜像,这个时候你会发现构建速度非常之快。
1 2 3 4 5 6 | $ docker build -t nginx_02 . $ docker images REPOSITORY TAG IMAGE ID CREATED SIZE nginx_02 latest fa37625af3ac 54 seconds ago 182.7 MB nginx_01 latest fa37625af3ac 54 seconds ago 182.7 MB nginx latest 19146d5729dc 6 days ago 181.6 MB |
但你也应该发现,这两个镜像的IMAGE ID是相同的,因为docker检测出你的dockerfile文件没有任何内容改变(包括要复制文件的内容),所以只是做了一个链接。这个时候你可以运行这个镜像看看。
1 | $ docker run --name nginx_01 -d -p 80:80 nginx_01 |
1 2 3 | $ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES fa37625af3ac nginx_01 "/bin/sh -c 'nginx -g" 4 seconds ago Up 3 seconds 0.0.0.0:80->80/tcp, 443/tcp nginx_01 |
1 2 3 4 5 6 | $ docker exec -ti nginx_01 bash root@0dbeb4d3852f:/# ss -nplt State Recv-Q Send-Q Local Address:Port Peer Address:Port LISTEN 0 128 *:80 *:* root@0dbeb4d3852f:/# cat /data/log/nginx/access.log 172.28.24.96 - - [27/Dec/2016:08:37:58 +0000] "GET / HTTP/1.1" 304 0 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) Chrome/55.0.2883.87 Safari/537.36" "-" |
从上面的结果可以看出,这个nginx容器运行一切正常。你可以在浏览器访问看看。
这个时候你可以选择删除一个镜像看看。
1 2 | $ docker rmi nginx_02 Untagged: nginx_02:latest |
成功删除,不管你删除哪个镜像都可以删除,但是只能删除一个。再次删除另一个时就会报错。
1 2 | $ docker rmi nginx_01 Error response from daemon: conflict: unable to remove repository reference "nginx_01" |
如果我们改变了网站代码或者改变了配置文件,再次构建镜像时会怎么样呢?
其实dockerfile中有任何的改动,再次构建镜像时都会重新构建,但是只会从改动的地方开始重新构建。
1 2 3 4 | $ docker build -t nginx_02 . $ docker images REPOSITORY TAG IMAGE ID CREATED SIZE nginx_02 latest 9868ca64a680 9 seconds ago 182.7 MB |
五、使用commit命令提交新镜像
通过上面我们知道,通过dockerfile可以构建一个镜像。同样使用commit也可以提交一个新镜像。跟build不同的是,commit只能从现有的容器之上提交出一个新的镜像。比如,你对nginx镜像做好了基本配置,然后就可以把这个镜像提交为一个新的镜像。
commit语法:
1 | docker commit [OPTIONS] CONTAINER [REPOSITORY[:TAG]] |
提交一个新的镜像。
1 2 3 4 5 6 | $ docker commit -a pengdongwen nginx_01 nginx_10 sha256:2cdae15e08fd9160fc24998a4f6cae270cd2130980fd7c48cc9da70b1b67671e
$ docker images REPOSITORY TAG IMAGE ID CREATED SIZE nginx_10 latest 2cdae15e08fd 6 seconds ago 182.7 MB |
commit是不是很方便,也很好用。
<参考>
更多推荐
所有评论(0)