Loading

Docke--Dockerfile指令介绍

Dockerfile 构建镜像常用指令

 Dockerfile 是一个文本文件,其内包含了一条条的指定(Instruction),每一条指令构建一层,因此每一条指定的内容,就是描述该层应当如何构建。

  通过使用build 命令,根据Dockerfile的描述来构建镜像

  通过源代码的方式

  通过标准输入流的方式

通过源代码的路径:

  Dockerfile需要放置在项目的跟目录位置

  在构建的时候,Dockerfile client会把整个context打包发送到Docker Server端,然后由server端负责build镜像,在构建成功后,会删除context目录

  docker build -t {镜像名字} {项目的路径可以是相对路径}

通过标准输入流:

  通过标准输入流的方式获取Dockerfile的内容

  client不会打包上传context目录,因此对于一些ADD、COPY等涉及host本地文件复制的操作不能够支持

  docker build -t {镜像名字} - < Dockerfile路径

已nginx 示例:

[root@server ~]# mkdir myNginx  #创建一个存放Dockerfile的目录
[root@server ~]# cd myNginx
[root@server myNginx]# vim Dockerfile  #编辑Dockerfile
FROM nginx
RUN echo '<h1>Hello, My Dockerfile Nginx!</h1>' > /usr/share/nginx/html/index.html

这个Dockerfile很简单,就两行。涉及到两条指令,FROM 和RUN。

FROM 指定基础镜像

所谓的定制镜像,必须是以一个镜像为基础,在其上进行定制。一个 Dockerfile 中的 FROM 是必备的指定,并且必须是第一条指令。

FROM {bash镜像}

RUN 执行命令

RUN 指令是用来执行命令行命令的,一个Dockerfile可以包含多个 RUN,按照定义顺序执行。

RUN 支持两种运行格式:

  • shell 格式:RUN <cmd>,这个会当做/bin/sh -c “cmd” 运行,就像直接在命令行中输入的命令一样。比如上面的:
    RUN echo '<h1>Hello, My Dockerfile Nginx!</h1>' > /usr/share/nginx/html/index.html
  • exec 格式:RUN ["可执行文件", "参数1", "参数2", ...],Docker 把它当做json的顺序来解析,必须使用双引号,且可执行文件必须是完整路径。

RUN 就像Shell脚本一样可以执行命令,但是也不建议一个命令对应一个RUN,像下面这样的写法

FROM centos
RUN yum install -y gcc make cmake
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 xf redis.tar.gz -C /usr/src/redis --stript-components=1
RUN cd /usr/src/redis
RUN make
RUN make install

 因为Dockerfile 中的每一个指令都会建立一层,RUN 也不例外,每一个RUN 的行为,就和我们手工创建景象的过程一样,新建一层,上面的这种写法创建了7层,这样会产生非常臃肿、非常多层的镜像,不仅仅增加了构建部署的时间,也容易出错。上面的Dockerfile正确写法应该如下:

FROM centos
RUN yum install -y gcc make cmake \
    && wget -O redis.tar.gz "http://download.redis.io/releases/redi s-3.2.5.tar.gz"  \
    && mkdir -p /usr/src/redis \
    && tar xf redis.tar.gz -C /usr/src/redis --stript-components=1 \
    && cd /usr/src/redis \
    && make \
    && make install

首先,之前所有的命令只有一个目的,就是编译、安装redis 可执行文件。因此没有必要建立很多层,这只是一层的事情。因此 只需要使用一个RUN 指令,使用&& 将各个所需命令串联起来。将前面的7层简化为1层。

COPY 复制文件

格式:

  • COPY <源路径> ... <目标路径>
  • COPY ["<源路径1>", ... "<目标路径>"]

 和 RUN 指令一样,也有两种格式,一种类似于命令行,一种类似于函数调用。

COPY 指令将从构建上下文目录中 <源路径> 的文件/目录复制到新的一层的镜像内的 <目标路径> 位置。例如:

[root@server ~]# mkdir myCentos  #创建一个文件夹
[root@server ~]# cd myCentos/  
[root@server myCentos]# echo "hello world" >> file.txt  #准备测试文件
[root@server myCentos]# mkdir dir  #准备测试目录
[root@server myCentos]# touch dir/test{1..5}.txt  #准备测试目录里面的文件
[root@server myCentos]# vim Dockerfile  #编辑Dockerfile
FROM centos
COPY file.txt /mydir/
COPY dir /mydir/
[root@server myCentos]# ls  #查看宿主主机的当前的测试文件
dir  Dockerfile  file.txt
[root@server myCentos]# ls dir/  #查看宿主机的当前的测试文件
test1.txt  test2.txt  test3.txt  test4.txt  test5.txt
[root@server myCentos]# docker build
-t mycentos:v1 .  #构建一个叫mycentos,标签为v1的镜像 Sending build context to Docker daemon 6.144kB Step 1/3 : FROM centos ---> 1e1148e4cc2c Step 2/3 : COPY file.txt /mydir/ ---> 16250be2483b Step 3/3 : COPY dir /mydir/dir ---> 2296f62ff0b3 Successfully built 2296f62ff0b3 Successfully tagged mycentos:v1 [root@server myCentos]# docker run -it --rm --name myC mycentos:v1 /bin/bash  #启动一个容器,使用上面创建的镜像,进去并执行shell命令 [root@cc87d839493f /]# ls mydir/  #查看容器内的mydir文件夹 dir file.txt [root@cc87d839493f /]# ls mydir/dir/  #查看容器内mydir文件夹下面的dir文件夹的文件 test1.txt test2.txt test3.txt test4.txt test5.txt

从上面示例可以看出, <目标路径> 可以是容器内的相对路径,如果该路径不存在,会自动在复制文件前创建缺失目录,且<目标路径>也可以是相对路径(工作目录可以用WORKDIR 指令来指定)

如果是拷贝目录, 那么在 目标地址 也必须写上 拷贝的目录的名称 。否则是将该目录下的所文件拷贝到目标路径

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

ADD 更高级的复制文件

 ADD 指令和COPY 的格式和性质基本一致。但是在 COPY 基础上增加了一些功能。

比如 <源路径> 可能是一个 URL,这种情况下,会自动去下载这个链接的文件到 <目标路径>里,下载完成的文件权限自动设置为 600,如果不是想要的权限,那么可以通过 RUN 进行权限调整。

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

示例

[root@server ~]# mkdir myCentos1 && cd myCentos1  #创建构建编写Dockerfile的目录并进入
[root@server myCentos1]# wget http://nginx.org/download/nginx-1.14.2.tar.gz  #方便测试,先准备一个nginx1.14-2版本的
[root@server myCentos1]# vim Dockerfile  #编写Dockerfile
FROM centos
ADD http://nginx.org/download/nginx-1.12.2.tar.gz /nginx/
ADD nginx-1.14.2.tar.gz /nginx/
[root@server myCentos1]# ls   #编写完成查看当前目录下的文件
Dockerfile  nginx-1.14.2.tar.gz

[root@server myCentos1]# docker build -t mycentos:v2 .  #开始构建一个名字叫mycentos:v2的镜像
Sending build context to Docker daemon  1.018MB
Step 1/3 : FROM centos
 ---> 1e1148e4cc2c
Step 2/3 : ADD http://nginx.org/download/nginx-1.12.2.tar.gz /nginx/
Downloading [==================================================>]  981.7kB/981.7kB
 ---> a1c9717e9a03
Step 3/3 : ADD nginx-1.14.2.tar.gz /nginx/
 ---> 068c9e89ae0e
Successfully built 068c9e89ae0e
Successfully tagged mycentos:v2
[root@server myCentos1]# docker run -it --rm --name myC  mycentos:v2 /bin/bash  #进入容器,并执行/bin/bash命令
[root@197da52295fa /]# ls /nginx/  #查看nginx目录
nginx-1.12.2.tar.gz  nginx-1.14.2

 从上面示例可以看出,ADD指令,如果我们跟的是一个URL的文件,那么会自动下载并放到 <目标路径>,如果跟的是一个压缩文件,那么会自动解压到 <目标路径>

注意:如果我们只是单纯的想复制一个文件或者一个压缩包,那么建议还是使用COPY,如果需要像上面这样用到下载,或解压缩,采用ADD

CMD 容器启动命令

容器不是虚拟机,容器就是进程,既然是进程,那么在启动容器的时候,需要指定所运行的程序及参数。CMD 指令就是用于指定容器默认的主进程启动命令的。

CMD 指令有三种格式:

  • shell 格式: CMD <命令>
  • exec 格式:CMD ["可执行文件","参数1","参数2", ...]
  • 参数列表格式:CMD ["参数1","参数2",...] , 这个时候CMD作为 ENTRYPOINT的参数。

在指令格式上,一般推荐使用exec 格式,这类格式在解析时会被解析为JSON数组,因此一定要使用双引号 “” ,而不要使用单引号。

如果使用shell 格式的话,实际的命令会被包装为 sh -c 的参数的形式进行执行。比如:

CMD echo $HOME

在实际执行中,会将其变更为:

CMD ["sh", "-c", "echo $HOME"]

在运行时可以指定新的命令来替代镜像设置中的这个默认命令,比如,centos镜像默认的 CMD 是 /bin/bash, 如果我们直接 docker run -it centos 的时候,会直接进入 bash。我们也可以在运行时指定别的命令,如 docker run -it centos cat /etc/passwd 。这就是用 cat /etc/passwd命令替换了默认的 /bin/bash 命令了。

前台执行和后台执行的问题:
    Docker 不是虚拟机,容器中的应用都应该以前台执行,而不是像虚拟机、物理机里面那样,用 start / systemctl 去启动后台服务,容器内没有后台服务的概念。
比如:如果我们将CMD 写成这样:
CMD service nginx start
然后会发现容器执行后就立刻退出了,甚至在容器内使用systemctl 命令结果却发现根本执行不了。这就是因为没有搞明白前台、后台的概念,没有区分容器和虚拟机的差异,依旧在以传统虚拟机的角度去理解容器
对于容器而言,其启动程序就是容器应用进程,容器就是为了主进程而存在的,主进程退出,容器就失去了存在的意义,从而退出,其它辅助进程不是它需要关心的东西。
而使用 service nginx start 命令,则是希望 start来已后台守护进程形式启动nginx服务。而 CMD service nginx start 会被理解为 CMD ["sh", "-c", "service nginx start"],因此主进程实际上是sh, 那么当service nginx start 命令结束后,sh 也就结束了, sh 作为主进程退出了,自然就会令容器退出。
正确的做法是直接执行 nginx 可执行文件,并且要求以前台形式。如:
CMD ["nginx", "-g"," daemon off;"]
理解前台执行和后台执行

ENTRYPOINT 入口点

ENTRYPOINT 的格式和 RUN 指令格式一样,分为 exec 格式 和shell格式。

ENTRYPOINT 的目的和 CMD 一样,都是在指定容器启动程序及参数。ENTRYPOINT 在运行时也可以替代,不过比CMD要繁琐,需要通过 docker run 的参数 --entrypoint 来指定。

当指定了 ENTRYPOINT 后,CMD 的含义就发生了改变,不再是直接运行其命令,而是将 CMD 的内容作为参数传给 ENTRYPOINT 指令,换句话说实际执行时,将变为:

ENTRYPOINT "<CMD>"

那么问题来了? 有了CMD ,为什么还要有ENTRYPOINT呢? 这种 ENTRYPOINT "<CMD>" 有什么好处呢?

场景一:让镜像变成命令一样使用

假设我们需要一个得知自己当前公网IP的镜像,那么可以使用CMD来实现:

[root@server myCentos2]# cat Dockerfile   #查看Dockerfile文件内容
FROM centos
CMD ["curl", "-s", "https://ip.cn"]
[root@server myCentos2]# docker build -t mycentos:v3 .  #创建一个镜像
[root@server myCentos2]# docker run mycentos:v3  #启动一个容器
当前 IP: 116.24.66.227 来自: 广东省深圳市 电信

这样看起来是可以当做命令来使用,不过命令一般有参数,CMD 中实质的命令是 curl, 如果希望显示HTTP头信息,就需要加上 -i 参数。

[root@server myCentos2]# docker run mycentos:v3 -i
docker: Error response from daemon: OCI runtime create failed: container_linux.go:348: starting container process caused "exec: \"-i\": executable file not found in $PATH": unknown.

这里可以看到可执行文件找不到的报错, executable file not found。上面说过,跟在镜像名后面的是 command, 运行时会替换 CMD 的默认值,因此这里的 -i 替换了原来的 CMD,而不是添加在原来的 curl -s https://ip.cn 后面,而 -i 根本不是命令,所以找不到。

那么如果我们希望加入 -i 参数,我们就必须重新完整的输入这个命令:

[root@server myCentos2]# docker run mycentos:v3 curl -i https://ip.cn

显然这不是好的解决办法,而是用 ENTRYPOINT 就可以解决这个问题:

[root@server myCentos2]# cat Dockerfile   #查看修改后的Dockerfile
FROM centos
ENTRYPOINT ["curl", "-s", "https://ip.cn"]
[root@server myCentos2]# docker build -t mycentos:v4 .  #再次生成一个新的镜像
[root@server myCentos2]# docker run mycentos:v4   #测试不加参数启动镜像
当前 IP: 116.24.66.227 来自: 广东省深圳市 电信
[root@server myCentos2]# docker run mycentos:v4 -i   #测试加上参数启动镜像
HTTP/1.1 200 OK
Date: Wed, 09 Jan 2019 13:23:09 GMT
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Connection: keep-alive
Set-Cookie: __cfduid=d67dbccf782da9ec6788bf87a78993a701547040189; expires=Thu, 09-Jan-20 13:23:09 GMT; path=/; domain=.ip.cn; HttpOnly
Expect-CT: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
Server: cloudflare
CF-RAY: 49673780decb961f-SJC

当前 IP: 116.24.66.227 来自: 广东省深圳市 电信

从上面可以看出,不加-i 参数可以运行成功, 加上-i参数也可以运行成功,且达到了curl -i 的效果。这是因为当存在 ENTRYPOINT 后,CMD 的内容将会作为参数传递给 ENTRYPOINT ,而这里 -i 就是新的CMD,因此会作为参数传递给curl,从而达到了我们预期的效果。

场景二:应用运行前的准备工作

 启动容器就是启动主进程,但有些时候,启动主进程前,需要一些准备工作。比如 mysql 类的数据库,可能需要一些数据库配置、初始化的工作,这些工作要在最终的mysql 服务器运行之前解决。此外,可能希望避免使用root 用户去启动服务器, 从而提高安全性,而在启动还需要以 root 身份执行一些必要的准备工作,最后切换到服务用户启动服务等。或者除了服务外,其它命令依旧可以使用 root 身份执行,方便调试等。

这些准备工作是和容器 CMD 无关的,无论CMD 是什么,都需要事先进行一个预处理的工作。这种情况下,可以写一个脚本,然后放入 ENTRYPOINT 中去执行,而这个脚本会接到的参数 (也就是CMD)作为指令,在脚本最后执行。比如官方的redis 中就是这样做的:

FROM alpine:3.4 
...
RUN addgroup -S redis && adduser -S -G redis redis 
...
ENTRYPOINT ["docker-entrypoint.sh"]
EXPOSE 6379 
CMD ["redis-server"]

可以看到其中为了 redis 服务创建了redis 用户,并在最后指定了 ENTRYPOINT 为 docker-entrypoint.sh 脚本。

#!/bin/bash
...
# allow the container to be started with `--user` 
if [ "$1" = 'redis-server' -a "$(id -u)" = '0' ]; then
    chown -R redis .
    exec su-exec redis "$0" "$@"
fi

exec "$@"

该脚本的内容就是根据 CMD 的内容来判断,如果是 redis-server 的话,则切换到 redis用户身份启动服务,否则依旧使用 root 身份执行。比如:

# docker run -it redis id
uid=0(root) gid=0(root) groups=0(root)

ENV 设置环境变量

格式:

  • ENV <key><value>
  • ENV<key1>=<value1> <key2>=<value2>

这个指令很简单,就是设置环境变量,无论是后面的其它指令,如RUN,还是运行时的应用,都可以直接使用这里定义的环境变量。

[root@server myCentos3]# cat Dockerfile   #查看编辑好的Dockerfile文件内容
FROM centos
ENV name1 xiaobai
ENV name2=zhazha name3=cainiao
[root@server myCentos3]# docker build -t mycentos:v5 .  #构建镜像
[root@server myCentos3]# docker run --rm -it --name test mycentos:v5  #启动一个容器,并以交互式启动 
[root@b55929b2c63f /]# echo $name1  #进入容器后调用环境变量name1
xiaobai
[root@b55929b2c63f /]# echo $name2 $name3  #调用环境变量name2,name3
zhazha cainiao

定义了环境变量,可以在后续的指令中直接使用环境变量

FROM centos
ENV URL="https://nginx.org/download/" 
ADD $URLnginx.1.12.2.tar.gz /usr/local/

ARG 构建参数

格式:

  • ARG <参数名>[=<默认值>]

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

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

VOLUME 定义匿名卷

格式:

  • VOLUME ["<路径1>","<路径2>"...]
  • VOLUME <路径>

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

[root@server myCentos4]# cat Dockerfile   #编写Dockerfile文件,内容如下
FROM nginx
VOLUME /usr/share/nginx/html/
[root@server myCentos4]# docker build -t mynginx:v1 .  #创建一个mynginx:v1的镜像
[root@server myCentos4]# docker run -it --rm --name nginx mynginx:v1 /bin/bash  #利用mynginx:v1镜像启动一个名字叫做nginx的容器
root@eaa3ffb6dda7:/# ls /usr/share/nginx/html/  #查看nginx网站目录的文件
50x.html  index.html

# 此时打开第二个终端,第一个终端不要关闭
[root@server ~]# docker inspect nginx  #在第二个终端查看启动的nginx 容器挂载信息,会发现在宿主机上面自动挂载到了一个目录
        "Mounts": [
...
                "Source": "/var/lib/docker/volumes/47794aa178f1aa829d8e778f319a6bb678349926a8107f459fcb10d3b00ff8b5/_data",
...
        ],
[root@server ~]# ls /var/lib/docker/volumes/47794aa178f1aa829d8e778f319a6bb678349926a8107f459fcb10d3b00ff8b5/_data  #查看挂载的目录,和容器中的目录一样,有同样的文件
50x.html  index.html
[root@server ~]# echo "<h1>hello docker</h1>" >> /var/lib/docker/volumes/47794aa178f1aa829d8e778f319a6bb678349926a8107f459fcb10d3b00ff8b5/_data/test.html #在该目录添加文件

# 此时回到nginx容器启动的第一个终端
root@eaa3ffb6dda7:/# ls /usr/share/nginx/html/  #再次查看该目录会发现也有上面新添加的文件
50x.html  index.html  test.html
root@eaa3ffb6dda7:/# cat /usr/share/nginx/html/test.html   #并且查看文件内容
<h1>hello docker</h1>

从上面可以看出,实际Dockerfile中只做了一件事,那就是将nginx网站目录挂载到了一个宿主机的一个匿名目录,且通过 docker inspect可以找到该目录,这样就实现了动态的更改网站数据目录的内容了。从而提高了灵活性。

同样还可以在运行容器的时候指定挂载:

[root@server myCentos4]# docker run -it --rm -v mydata:/usr/share/nginx/html/ --name nginx mynginx:v1 /bin/bash  #指定挂载的目录启动容器
root@f5c496cc9846:/# 

# 打开第二个终端查看挂载目录
[root@server ~]# docker inspect nginx  #查看挂载信息
        "Mounts": [
...
                "Source": "/var/lib/docker/volumes/mydata/_data",
                "Destination": "/usr/share/nginx/html",
...
        ],

这样 使用了 mydata 这个命令卷挂载到了/usr/share/nginx/html 这个位置,替代了Dockerfile 中定义的匿名卷的挂载配置

EXPOSE 声明端口

格式:

  • EXPOSE <端口1> [<端口2>...]

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

WORKDIR 指定工作目录

格式:

  • WORKDIR <工作目录路径>

使用 WORKDIR 指令可以来制定工作目录(或者称为当前目录),以后各层的当前目录就被改为指定的目录,如该目录不存在,则会自动创建。

可以为RUN、CMD、ENTRYPOINT指令配置工作目录,可以使用多个WORKDIR指令,后续参数如果是相对路径,则会基于之前的命令指定的路径。如:WORKDIR /home   WORKDIR test。最终路径为/home/test。path路径也可以是环境变量,比如有环境变量HOME=/home,   WORKDIR $HOME/test也就是/home/test

[root@server myCentos5]# cat Dockerfile   #查看编辑好的Dockerfile文件
FROM centos
WORKDIR /home/testdir
[root@server myCentos5]# docker build -t mycentos:v6 .  #创建一个名字叫做mycentos:v6的镜像
[root@server myCentos5]# docker run --rm -it mycentos:v6   #使用上面创建的镜像启动一个容器
[root@4f7ae938d471 testdir]# pwd  #进入容器后查看当前工作目录
/home/testdir

USER 指定当前用户

格式:

  • USER <用户名>

USER 和WORKDIR 相似,都是改变环境状态并影响以后的层。WORKDIR是改变工作目录,USER 则是指定运行容器时的用户名或UID,后续的RUN、CMD、ENTRYPOINT 也会已该用户身份去运行命令。

当然,USER 只是能够切换到指定用户而已,这个用户必须事先建立好,否则无法切换。

RUN groupadd -r redis && useradd -r -g redis redis
USER redis
RUN ["redis-server"]

HEALTHCHECK 健康检查

格式:

  • HEALTHCHECK [选项] CMD <命令>:设置检查容器健康的命令
  • HEALTHCHECK NONE:如果基础镜像有健康检查指令,使用这行可以屏蔽掉其健康检查指令

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

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

HEALTHCHECK 支持下列选项:

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

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

在HEALTHCHECK [选项] CMD 后面的命令,格式和  ENTRYPOINT  一样,分为 shell  格式,和 exec 格式。命令的返回值决定了该次健康检查的成功与 否:0:成功; 1 :失败; 2  :保留,不要使用这个值。
假设我们有个镜像是个最简单的    Web    服务,我们希望增加健康检查来判断其    Web 服务是否在正常工作,我们可以用  curl 来帮助判断,其 Dockerfile  的  HEALTHCHECK可以这样写:

[root@server myNginx1]# cat Dockerfile 
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
[root@server myNginx1]# docker build -t mynginx:v2 .
[root@server myNginx1]# docker run -d --name web -p 80:80 mynginx:v2

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

当运行改镜像启动的容器后,可以通过 docker ps 看到最初的状态为(health:starting):

[root@server myNginx1]# docker ps 
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS                            PORTS                NAMES
fb9c72f7a6de        mynginx:v2          "nginx -g 'daemon of…"   6 seconds ago       Up 4 seconds (health: starting)   0.0.0.0:80->80/tcp   web

 再等待几秒钟后,再次 docker ps,就会看到健康检查状态变成了 (healthy):

[root@server myNginx1]# docker ps 
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS                    PORTS                NAMES
fb9c72f7a6de        mynginx:v2          "nginx -g 'daemon of…"   18 seconds ago      Up 17 seconds (healthy)   0.0.0.0:80->80/tcp   web

如果健康检查连续失败超过了重试次数,状态就会变为 (unhealthy)。

 

posted @ 2019-01-09 23:47  别来无恙-  阅读(8094)  评论(0编辑  收藏  举报