dockerfile

￡神魔★判官ぃ 2022-12-02 15:19 199阅读 0赞

### dockerfile ###

*  指令介绍
 *   *  FROM   指定基础镜像
     *  MAINTAINER   指定作者
     *  RUN   执行命令
     *  COPY   复制文件
     *  ADD   更高级的复制文件
     *  CMD   容器启动命令
     *   *   *  RUN与CMD的区别
     *  ENTRYPOINT
     *   *   *  CMD与ENTRYPOINT
             *  RUN、CMD、ENTRYPOINT三者的区别
     *  ENV   设置环境变量
     *  ARG   构建参数
     *  VOLUME   定义匿名卷
     *  EXPOSE   声明端口
     *  WORKDIR   指定工作目录
     *  USER   指定当前用户
     *  HEALTHCHECK   健康检查
     *  ONBUILD

# 指令介绍 #

## FROM   指定基础镜像 ##

**功能为指定基础镜像，并且必须是第一条指令。**

如果不以任何镜像为基础，那么写法为：FROM scratch。

同时意味着接下来所写的指令将作为镜像的第一层开始  
语法：  
**FROM <image>  
FROM <image>:<tag>  
FROM <image>:<digest>**  
三种写法，其中<tag>和<digest> 是可选项，如果没有选择，那么默认值为latest

FROM nginx

## MAINTAINER   指定作者 ##

**指定作者**  
语法：

MAINTAINER <name>

## RUN   执行命令 ##

RUN 指令是用来执行命令行命令的。由于命令行的强大能力， RUN 指令在定制镜像时是最常用的指令之一。其格式有两种：

*  shell 格式： RUN <命令> ，就像直接在命令行中输入的命令一样。

RUN echo 'zyy' > /var/www/html/index.html

*  exec 格式： RUN \[“可执行文件”, “参数1”, “参数2”\]，这更像是函数调用中的格式。

RUN ["/bin/bash","-c","echo hello"]

既然 RUN 就像 Shell 脚本一样可以执行命令，那么我们是否就可以像 Shell 脚本一样把每个命令对应一个 RUN 呢？比如这样：

FROM debian:jessie
    RUN apt-get update
    RUN apt-get install -y gcc libc6-dev make
    RUN wget -O redis.tar.gz "http://download.redis.io/releases/redis-3.2.5.tar.gz"
    RUN mkdir -p /usr/src/redis
    RUN tar -xzf redis.tar.gz -C /usr/src/redis --strip-components=1
    RUN make -C /usr/src/redis
    RUN make -C /usr/src/redis install

Dockerfile 中每一个指令都会建立一层， RUN 也不例外。每一个 RUN 的行为，就和刚才我们手工建立镜像的过程一样：新建立一层，在其上执行这些命令，执行结束后， commit 这一层的修改，构成新的镜像。

而上面的这种写法，创建了 7 层镜像。这是完全没有意义的，而且很多运行时不需要的东西，都被装进了镜像里，比如编译环境、更新的软件包等等。结果就是产生非常臃肿、非常多层的镜像，不仅仅增加了构建部署的时间，也很容易出错。

上面的 Dockerfile 正确的写法应该是这样：

ROM debian:jessie
    RUN buildDeps='gcc libc6-dev make' \
        && apt-get update \
        && apt-get install -y $buildDeps \
        && wget -O redis.tar.gz "http://download.redis.io/releases/redis-3.2.5.tar.gz" \
        && mkdir -p /usr/src/redis \
        && tar -xzf redis.tar.gz -C /usr/src/redis --strip-components=1 \
        && make -C /usr/src/redis \
        && make -C /usr/src/redis install \
        && rm -rf /var/lib/apt/lists/* \
        && rm redis.tar.gz \
        && rm -r /usr/src/redis \
        && apt-get purge -y --auto-remove $buildDeps

首先，之前所有的命令只有一个目的，就是编译、安装 redis 可执行文件。因此没有必要建立很多层，这只是一层的事情。因此，这里没有使用很多个 RUN 对一一对应不同的命令，而是仅仅使用一个 RUN 指令，并使用 && 将各个所需命令串联起来。将之前的 7 层，简化为了1 层。在撰写 Dockerfile 的时候，要经常提醒自己，这并不是在写 Shell 脚本，而是在定义每一层该如何构建。

并且，这里为了格式化还进行了换行。Dockerfile 支持 Shell 类的行尾添加 \\ 的命令换行方式，以及行首 \# 进行注释的格式。良好的格式，比如换行、缩进、注释等，会让维护、排障更为容易，这是一个比较好的习惯。

此外，还可以看到这一组命令的最后添加了清理工作的命令，删除了为了编译构建所需要的软件，清理了所有下载、展开的文件，并且还清理了 apt 缓存文件。这是很重要的一步，之前有说过，镜像是多层存储，每一层的东西并不会在下一层被删除，会一直跟随着镜像。因此镜像构建时，一定要确保每一层只添加真正需要添加的东西，任何无关的东西都应该清理掉。

## COPY   复制文件 ##

复制命令

格式：  
**COPY <src>… <dest>  
COPY \["<src>",… “<dest>”\]**

<目标路径> 可以是容器内的绝对路径，也可以是相对于工作目录的相对路径（工作目录可以用 WORKDIR 指令来指定）。目标路径不需要事先创建，如果目录不存在会在复制文件前先行创建缺失目录。

此外，还需要注意一点，使用 COPY 指令，源文件的各种元数据都会保留。比如读、写、执行权限、文件变更时间等。这个特性对于镜像定制很有用。特别是构建相关文件都在使用 Git进行管理的时候。

## ADD   更高级的复制文件 ##

一个复制命令，把文件复制到镜像中。  
如果把虚拟机与容器想象成两台linux服务器的话，那么这个命令就类似于scp，只是scp需要加用户名和密码的权限验证，而ADD不用。  
语法如下：

**1. ADD <src>… <dest>  
2. ADD \["<src>",… “<dest>”\]**

*  复制本地主机的（为Dockerfile所在目录的相对路径，文件或目录）为容器中的。目标路径不存在时会自动创建。
 *  路径的填写可以是容器内的绝对路径，也可以是相对于工作目录的相对路径，**推荐写成绝对路径**
 *  可以是一个**本地文件或者是一个本地压缩文件（会自动解压为目录）**，还可以是一个url
 *  **如果把写成一个url，那么ADD就类似于wget命令**  
    示例

ADD test /zyy
    ADD http://example.com/foobar /

如果 <源路径> 为一个 tar 压缩文件的话，压缩格式为 gzip , bzip2 以及 xz 的情况下， ADD 指令将会自动解压缩这个压缩文件到 <目标路径> 去。

ADD files/zyy.gz  /

## CMD   容器启动命令 ##

shell 格式： **CMD <命令>**  
exec 格式： **CMD \[“可执行文件”, “参数1”, “参数2”…\]**  
参数列表格式： **CMD \[“参数1”, “参数2”…\]** 。在指定了 ENTRYPOINT 指令后，用 CMD 指定具体的参数。

CMD apt-get install python3
    CMD ["apt-get", "install", "python3"]

#### RUN与CMD的区别 ####

**RUN**

*  RUN命令是创建Docker镜像（image）的步骤，RUN命令对Docker容器（ container）造成的改变是会被反映到创建的Docker镜像上的。一个Dockerfile中可以有许多个RUN命令。

**CMD**

*  CMD命令是当Docker镜像被启动后Docker容器将会默认执行的命令。一个Dockerfile中只能有一个CMD命令。通过执行docker run $image $other\_command启动镜像可以重载CMD命令。

不要把RUN和CMD搞混了。
    
    RUN是构件容器时就运行的命令以及提交运行结果
    
    CMD是容器启动时执行的命令，在构件时并不运行，构件时紧紧指定了这个命令到底是个什么样子

## ENTRYPOINT ##

shell 格式： **ENTRYPOINT <命令>**  
exec 格式： **ENTRYPOINT \[“可执行文件”, “参数1”, “参数2”…\]**

#### CMD与ENTRYPOINT ####

**Dockerfile中的ENTRYPOINT指令和CMD指令都可以设置容器启动时要执行的命令**，但用途是有略微不同的。

ENTRYPOINT指令和CMD指令虽然是在Dockerfile中定义，但是在构建镜像的时候并不会被执行，**只有在执行docker run命令启动容器时才会起作用**。

*  在Dockerfile中，只能有一个ENTRYPOINT指令，如果有多个ENTRYPOINT指令则以最后一个为准。
 *  在Dockerfile中，只能有一个CMD指令，如果有多个CMD指令则以最后一个为准。
 *  在Dockerfile中，ENTRYPOINT指令或CMD指令，至少必有其一。

#### RUN、CMD、ENTRYPOINT三者的区别 ####

Dockerfile中RUN，CMD和ENTRYPOINT都能够用于执行命令，下面是三者的主要用途：

*  RUN命令执行命令并创建新的镜像层，通常用于安装软件包
 *  CMD命令设置容器启动后默认执行的命令及其参数，但CMD设置的命令能够被docker run命令后面的命令行参数替换
 *  ENTRYPOINT配置容器启动时的执行命令（不会被忽略，一定会被执行，即使运行 docker run时指定了其他命令）

## ENV   设置环境变量 ##

**ENV <key> <value>  
ENV <key1>=<value1> <key2>=<value2>…**  
定义了环境变量，那么在后续的指令中，就可以使用这个环境变量。比如在官方 node 镜像 Dockerfile 中，就有类似这样的代码：

ENV NODE_VERSION 7.2.0
    RUN curl -SLO "https://nodejs.org/dist/v$NODE_VERSION/node-v$NODE_VERSION-linux-x64.ta
    r.xz" \
        && curl -SLO "https://nodejs.org/dist/v$NODE_VERSION/SHASUMS256.txt.asc" \
        && gpg --batch --decrypt --output SHASUMS256.txt SHASUMS256.txt.asc \
        && grep " node-v$NODE_VERSION-linux-x64.tar.xz\$" SHASUMS256.txt | sha256sum -c - \
        && tar -xJf "node-v$NODE_VERSION-linux-x64.tar.xz" -C /usr/local --strip-components=1 \
        && rm "node-v$NODE_VERSION-linux-x64.tar.xz" SHASUMS256.txt.asc SHASUMS256.txt \
        && ln -s /usr/local/bin/node /usr/local/bin/nodejs

在这里先定义了环境变量 NODE\_VERSION ，其后的 RUN 这层里，多次使用 $NODE\_VERSION 来进行操作定制。可以看到，将来升级镜像构建版本的时候，只需要更新 7.2.0 即可， Dockerfile 构建维护变得更轻松了。

**在Dockerfile中使用变量的方式**

*  $varname
 *  $\{varname\}
 *  $\{varname:-default value\}
 *  $(varname:+default value\}

第一种和第二种相同  
第三种表示当变量不存在使用-号后面的值  
第四种表示当变量存在时使用+号后面的值（当然不存在也是使用后面的值）

## ARG   构建参数 ##

格式：  
**ARG <参数名>\[=<默认值>\]**

构建参数和 ENV 的效果一样，都是设置环境变量。所不同的是， ARG 所设置的构建环境的环境变量，在将来容器运行时是不会存在这些环境变量的。但是不要因此就使用 ARG 保存密码之类的信息，因为 docker history 还是可以看到所有值的。

Dockerfile 中的 ARG 指令是定义参数名称，以及定义其默认值。该默认值可以在构建命令 docker build 中用 --build-arg <参数名>=<值> 来覆盖。

在 1.13 之前的版本，要求 –build-arg 中的参数名，必须在 Dockerfile 中用 ARG 定义过了，换句话说，就是 –build-arg 指定的参数，必须在 Dockerfile 中使用了。如果对应参数没有被使用，则会报错退出构建。从 1.13 开始，这种严格的限制被放开，不再报错退出，而是显示警告信息，并继续构建。这对于使用 CI 系统，用同样的构建流程构建不同的 Dockerfile 的时候比较有帮助，避免构建命令必须根据每个 Dockerfile 的内容修改。

## VOLUME   定义匿名卷 ##

**可实现挂载功能，可以将宿主机目录挂载到容器中**

容器运行时应该尽量保持容器存储层不发生写操作，对于数据库类需要保存动态数据的应用，其数据库文件应该保存于卷(volume)中。为了防止运行时用户忘记将动态文件所保存目录挂载为卷，在 Dockerfile 中，我们可以事先指定某些目录挂载为匿名卷，这样在运行时如果用户不指定挂载，其应用也可以正常运行，不会向容器存储层写入大量数据。

VOLUME /data

这里的 /data 目录就会在运行时自动挂载为匿名卷，**任何向 /data 中写入的信息都不会记录进容器存储层，从而保证了容器存储层的无状态化**

## EXPOSE   声明端口 ##

EXPOSE 指令是**声明运行时容器提供服务端口，这只是一个声明，在运行时并不会因为这个声明应用就会开启这个端口的服务。**

EXPOSE <port>/<tcp/udp>

要将`EXPOSE`和在运行时使用 `-p <宿主端口>:<容器端口>`区分开来。 **-p ，是映射宿主端口和容器端口**，换句话说，就是将容器的对应端口服务公开给外界访问，而 **EXPOSE 仅仅是声明容器打算使用什么端口而已，并不会自动在宿主进行端口映射**。

## WORKDIR   指定工作目录 ##

格式为  
**WORKDIR <工作目录路径>**

WORKDIR /path/to/workdir

使用 WORKDIR 指令可以来指定工作目录（或者称为当前目录），以后各层的当前目录就被改为指定的目录，**如该目录不存在， WORKDIR 会帮你建立目录。**  
   
**dockfile不是shell脚本，因此下面的写法是错误的**

RUN cd /app
    RUN echo "hello" > world.txt

如果将这个 Dockerfile 进行构建镜像运行后，会发现找不到 /app/world.txt 文件，或者其内容不是 hello 。原因其实很简单，  
**在 Shell 中，连续两行是同一个进程执行环境，因此前一个命令修改的内存状态，会直接影响后一个命令**；  
**而在 Dockerfile 中，这两行 RUN 命令的执行环境根本不同，是两个完全不同的容器**。  
这就是对 Dockerfile 构建分层存储的概念不了解所导致的错误。  
   
之前说过每一个 RUN 都是启动一个容器、执行命令、然后提交存储层文件变更。第一层 RUNcd /app 的执行仅仅是当前进程的工作目录变更，一个内存上的变化而已，其结果不会造成任何文件变更。而到第二层的时候，启动的是一个全新的容器，跟第一层的容器更完全没关系，自然不可能继承前一层构建过程中的内存变化。

**因此如果需要改变以后各层的工作目录的位置，那么应该使用 WORKDIR 指令。**

WORKDIR /app
    RUN echo "hello" > world.txt

## USER   指定当前用户 ##

格式：  
**USER <用户名>**

USER 指令和 WORKDIR 相似，都是改变环境状态并影响以后的层。 WORKDIR 是改变工作目录， **USER 则是改变之后层的执行 RUN , CMD 以及 ENTRYPOINT 这类命令的身**份。当然，和 WORKDIR 一样， USER 只是帮助你切换到指定用户而已，**这个用户必须是事先建立好的，否则无法切换。**

RUN groupadd -r redis && useradd -r -g redis redis
    USER redis

## HEALTHCHECK   健康检查 ##

**HEALTHCHECK 指令是告诉 Docker 应该如何进行判断容器的状态是否正常**

格式：  
**HEALTHCHECK \[选项\] CMD <命令>** ：设置检查容器健康状况的命令  
**HEALTHCHECK NONE** ：在基础镜像中取消健康检查命令

当在一个镜像指定了 HEALTHCHECK 指令后，**用其启动容器，初始状态会为 `starting`，在 HEALTHCHECK 指令检查成功后变为 `healthy` ，如果连续一定次数失败，则会变为 `unhealthy`** 。

**HEALTHCHECK 支持下列选项**：

*  interval=<间隔> ：两次健康检查的间隔，默认为 30 秒；
 *  timeout=<时长> ：健康检查命令运行超时时间，如果超过这个时间，本次健康检查就被视为失败，默认 30 秒；
 *  retries=<次数> ：当连续失败指定次数后，则将容器状态视为 unhealthy ，默认 3 次。

**注意：**

和 CMD , ENTRYPOINT 一样， HEALTHCHECK 只可以出现一次，如果写了多个，**只有最后一个生效。**

在 HEALTHCHECK \[选项\] CMD 后面的命令，格式和 ENTRYPOINT 一样，分为 shell 格式，和 exec 格式。命令的返回值决定了该次健康检查的成功与否：

*  0 ：成功；
 *  1 ：失败；
 *  2 ：保留，不要使用这个值。

FROM nginx
    RUN apt-get update && apt-get install -y curl && rm -rf /var/lib/apt/lists/* HEALTHCHECK --interval=5s --timeout=3s \ CMD curl -fs http://localhost/ || exit 1

这里我们设置了每 5 秒检查一次（这里为了试验所以间隔非常短，实际应该相对较长），如果健康检查命令超过 3 秒没响应就视为失败，并且使用`curl -fs http://localhost/ || exit 1` 作为健康检查命令。

想要查看状态

docker ps
    
    
    root@harbor002 ~]# docker ps
    CONTAINER ID        IMAGE                                COMMAND                  CREATED             STATUS                 PORTS                       NAMES
    afd340298a22        goharbor/harbor-jobservice:v2.0.2    "/harbor/entrypoint.…"   4 hours ago         Up 4 hours (healthy)                               harbor-jobservice

## ONBUILD ##

格式：  
**ONBUILD <其它指令>。**

ONBUILD 是一个特殊的指令，它后面跟的是其它指令，比如 RUN , COPY 等，而这些指令，**`在当前镜像`构建时`并不会被执行`**。**只有当`以当前镜像为基础镜像`，去构建下一级镜像的时候才会被`执行`。**