dockerfile原理

基于dockerfile文件，通过docker build运行进行，将from指定的基础镜像作为底层镜像层，然后执行第二条命令，添加标签，生成一个可写层，如果没有文件变化，则保存为空，如果有文件变化，则该层级会被保存下来，将层级封 装成一个完整镜像，如果还有下一层，同样的道理，以此类推

1. FROM（指定基础 image）

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

FROM centos:7.2FROM centos

2. MAINTAINER（用来指定镜像创建者信息）

构建指令，用于将 image 的制作者相关的信息写入到 image 中。当我们对该

image 执行 docker inspect 命令时，输出中有相应的字段记录该信息。

MAINTAINER wangyang "wangyang@itxdl.cn"

3. LABEL（将元数据添加到镜像）

标签的定义，具有继承功能，继承基础镜像的标签，也可覆盖

# 指令将元数据添加到镜像。`LABEL` 是键值对。要在 `LABEL` 值中包含空格，请像在命令行中一样使用引号和反斜杠

LABEL "com.example.vendor"="ACME Incorporated"LABEL com.example.label-with-value="foo"LABEL version="1.0"

LABEL description="This text illustrates \that label-values can span multiple lines."

# 多行标签定义方式

LABEL multi.label1="value1" multi.label2="value2" other="value3"

LABEL multi.label1="value1" \ multi.label2="value2" \ other="value3"

标签的继承

基础或父镜像（`FROM` 行中的镜像）中包含的标签由您的镜像继承。如果标签已经存在但具有不同的值，则最近应用的值将覆盖任何先前设置的值查看镜像标签

docker image inspect --format='' myimage

案例

# 构建镜像

docker build -t wangyanglinux:0.0.1 . --no-cache

# 安装 jq

yum install epel-release

yum install jq

# 查看标签

docker image inspect linux:0.0.1 --format

"{{json .ContainerConfig.Labels}}" | jq{

"author": "wangyanglinux"

}

4. RUN（安装软件用）

构建指令，RUN 可以运行任何被基础 image 支持的命令。如基础 image 选择

了 Centos，那么软件管理部分只能使用 Centos 的包管理命令

RUN cd /tmp && curl -L

'http://archive.apache.org/dist/tomcat/tomcat-7/v7.0.8/bin/apache-tomcat-7.0.8.tar.gzhttp://archive.apache.org/dist/tomcat/tomcat-7/v7.0.8/bin/apache-tomcat-7.0.8.tar.gz' | tar -xz

只能执行基础镜像中有的命令

5. USER（设置container容器的用户）

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

USER daemon = ENTRYPOINT ["memcached", "-u", "daemon"]

6. EXPOSE（指定容器需要映射到宿主机器的端口）

设置指令，该指令会将容器中的端口映射成宿主机器中的某个端口。当你需要 访问容器的时候，可以不是用容器的 IP 地址而是使用宿主机器的 IP 地址和映射后的端口。要完成整个操作需要两个步骤，首先在 Dockerfile 使用EXPOSE 设置需要映射的容器端口，然后在运行容器的时候指定 -P 选项加上 EXPOSE 设置的端口，这样 EXPOSE 设置的端口号会被随机映射成宿主机器中的 一个端口号。也可以指定需要映射到宿主机器的那个端口，这时要确保宿主机器上的端口号没有被使用。EXPOSE指令可以一次设置多个端口号，相应的运行容器的时候，可以配套的多次使用 -p 选项

# 映射多个端口

EXPOSE port1 port2 port3

# 随机暴露需要运行的端口

docker run -P image

# 相应的运行容器使用的命令

docker run -p port1 -p port2 -p port3 image

# 还可以指定需要映射到宿主机器上的某个端口号

docker run -p host_port1:port1 -p host_port2:port2 -p

host_port3:port3 image

提示重要端口，可以设置没有开启的端口，与外界连接毫无关系

7. ENV（用于设置环境变量）

构建指令，在 image 中设置一个环境变量。设置了后，后续的 RUN 命令都可以使用，container 启动后，可以通过 docker inspect 查看这个环境变量，也可以通过在 docker run --env key=value 时设置或修改环境变量。假如你 安装了 JAVA 程序，需要设置 JAVA_HOME，那么可以在 Dockerfile 中这样写：

ENV JAVA_HOME /path/to/java/direntdocker run --name test --env nginx=2.0 -d test:v3命令执行优先级较高

docker exec test env #查看运行容器的环境变量 8. ARG（设置变量）

起作用的时机

- arg 是在 build 的时候存在的, 可以在 Dockerfile 中当做变量来使用- env 是容器构建好之后的环境变量, 不能在 Dockerfile 中当参数使用

案例

FROM redis:3.2-alpine

LABEL maintainer="wangyanglinux@163.com"

ARG REDIS_SET_PASSWORD=456

ENV REDIS_PASSWORD $REDIS_SET_PASSWORD

RUN echo $REDIS_SET_PASSWORD > /root/redis_password.txtEXPOSE 6379

CMD ["sh", "-c", "exec redis-server --requirepass \"$REDIS_PASSWORD\""]

docker run --env REDIS_PASSWORD=123 -d xxx

9. ADD（从src复制文件到container 的dest路径，传入自动解压）

ADD  

 是相对被构建的源目录的相对路径，可以是文件或目录的路

径，也可以是一个远程的文件 url;  是 container 中的绝对路径

10. COPY （从 src 复制文件到 container 的 dest 路径）

COPY  

11. WORKDIR（切换目录）

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

WORKDIR /p1 WORKDIR p2 RUN vim a.txt

12. CMD（设置 container 启动时执行的操作）

设置指令，用于 container 启动时指定的操作。该操作可以是执行自定义脚本，也可以是执行系统命令。该指令只能在文件中存在一次，如果有多个，则只执行最后一条，镜像需要封装前台进程才可以启动

CMD echo “Hello, World!”

CMD /usr/sbin/httpd && tail -f /var/log/httpd/access_log

13. ENTRYPOINT（设置container启动时执行的操作）

指定容器启动时执行的命令，可以多次设置，但只有最后一个有效。

两种使用情况，一种是独自使用，另一种和 CMD 指令配合使用。

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

CMD echo “Hello, World!”

ENTRYPOINT echo “Hi, World!” docker run --rm nginx:v3Hi, World!

# CMD 指令将不会被执行，只有 ENTRYPOINT 指令被执行

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

FROM 163

CMD echo ["nginx"]

ENTRYPOINT ["echo"]

14. CMD 与 ENTRYPOINT 的较量

官方释义：Dockerfile reference | Docker Documentation

cmd 给出的是一个容器的默认的可执行体。也就是容器启动以后，默认的执行的命令

如果我们在 run 时指定了命令或者有entrypoint，那么cmd就会被覆盖，而

ENTRYPOINT无法覆盖

shell模式任何run和cmd的参数都无法被传入到entrypoint里

15. ONBUILD（在子镜像中执行）

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

ONBUILD ADD . /app/src

ONBUILD RUN /usr/local/bin/python-build --dir /app/src

16. STOPSIGNAL signal

STOPSIGNAL 指令设置将发送到容器以退出的系统调用信号。这个信号可以是一 个有效的无符号数字，与内核的`syscall`表中的位置相匹配，例如`9`，或者是`SIGNAME`格式的信号名，例如：SIGKILL SIGHUP 1 A 终端挂起或者控制进程终止SIGINT 2 A 键盘中断（如break键被按下）

SIGQUIT 3 C 键盘的退出键被按下SIGILL 4 C 非法指令

SIGABRT 6 C 由abort(3)发出的退出指令SIGFPE 8 C 浮点异常 SIGKILL 9 AEF Kill信号 SIGSEGV 11 C 无效的内存引用

SIGPIPE 13 A 管道破裂: 写一个没有读端口的管道SIGALRM 14 A 由alarm(2)发出的信号SIGTERM 15 A 终止信号

SIGUSR1 30,10,16 A 用户自定义信号1SIGUSR2 31,12,17 A 用户自定义信号2SIGCHLD 20,17,18 B 子进程结束信号

SIGCONT 19,18,25 进程继续（曾被停止的进程）SIGSTOP 17,19,23 DEF 终止进程

SIGTSTP 18,20,24 D 控制终端（tty）上按下停止键SIGTTIN 21,21,26 D 后台进程企图从控制终端读SIGTTOU 22,22,27 D 后台进程企图从控制终端写

17. SHELL （覆盖命令的shell模式所使用的默认 shell）

Linux 的默认shell是 [“/bin/sh”, “-c”]，Windows 的是 [“cmd”,

“/S”, “/C”]。SHELL 指令必须以 JSON 格式编写。SHELL 指令在有两个常 用的且不太相同的本地 shell:cmd 和 powershell，以及可选的 sh 的windows 上特别有用

18. HEALTHCHECK （容器健康状况检查命令）

HEALTHCHECK [OPTIONS] CMD command

[OPTIONS] 的选项支持以下三中选项

--interval=DURATION 两次检查默认的时间间隔为 30 秒

--timeout=DURATION 健康检查命令运行超时时长，默认 30 秒

--retries=N 当连续失败指定次数后，则容器被认为是不健康的，状态为

unhealthy，默认次数是3

CMD后边的命令的返回值决定了本次健康检查是否成功，具体的返回值如下：

0: success - 表示容器是健康的1: unhealthy - 表示容器已经不能工作了2: reserved - 保留值

HEALTHCHECK NONE

# 第一个的功能是在容器内部运行一个命令来检查容器的健康状况# 第二个的功能是在基础镜像中取消健康检查命令

# 为了帮助调试失败的探测，command写在stdout或stderr上的任何输出文本

（UTF-8编码）都将存储在健康状态中，并且可以通过docker inspect进行查 询。这样的输出应该保持简短（目前只存储前4096个字节）注意

HEALTHCHECK 命令只能出现一次，如果出现了多次，只有最后一个生效

模板

HEALTHCHECK --interval=5m --timeout=3s \

CMD curl -f http://localhost/http://localhost/|| exit 1

查看容器的健康状态

docker inspect -format '{{json .State.Health.Status}}'  cID

二、镜像多级构建

FROM xxx as aliasName

COPY --from=0/aliasName

Docker image Build 高级

镜像 Cache 机制

Docker Daemnon 通过 Dockerfile 构建镜像时，当发现即将新构建出的镜像与已有的某镜像重复时，可以选择放弃构建新的镜像，而是选用已有的镜像作为构建结果，也就是采取本地已经 cache 的镜像作为结果

Cache 机制的注意事项：

1. ADD 命令与 COPY 命令：Dockerfile 没有发生任何改变，但是命令ADDrun.sh / 中 Dockerfile 当前目录下的 run.sh 却发生了变化，从而将直接导致镜像层文件系统内容的更新，原则上不应该再使用 cache。那么，判断ADD 命令或者 COPY 命令后紧接的文件是否发生变化，则成为是否延用 cache的重要依据。Docker 采取的策略是：获取 Dockerfile 下内容（包括文件的部分 inode 信息），计算出一个唯一的 hash 值，若 hash 值未发生变化，则可以认为文件内容没有发生变化，可以使用 cache 机制；反之亦然**

2. RUN 命令存在外部依赖：一旦 RUN 命令存在外部依赖，如RUN apt-getupdate，那么随着时间的推移，基于同一个基础镜像，一年的 apt-getupdate 和一年后的 apt-get update， 由于软件源软件的更新，从而导致产生的镜像理论上应该不同。如果继续使用 cache 机制，将存在不满足用户需求的情况。Docker 一开始的设计既考虑了外部依赖的问题，用户可以使用参

数 确保获取最新的外部依赖，命令为docker build --no-cache -t="my_new_image" .

3. 树状的镜像关系决定了，一次新镜像的成功构建将导致后续的 cache 机制

全部失效：这一点很好理解，一旦产生一个新的镜像，同时意味着产生一个新

的镜像 ID，而当前宿主机环境中肯定不会存在一个镜像，此镜像 ID 的父镜

像 ID 是新产生镜像的ID。这也是为什么，书写 Dockerfile 时，应该将更多

静态的安装、配置命令尽可能地放在 Dockerfile 的较前位置