首页 开发技术Docker正文

【Docker】5. Dockerfile 定制镜像

拾年之璐 Docker 2020-09-17 19:09:29 57 0

Docker

Dockerfile 定制镜像

1. 概述

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

使用Dockerfile,可以实现一次构建,到处运行

2. 示例1

下面以在Tomcat中运行项目为示例,进行演示。

1.在用户目录下创建一个index.jsp 的文件,其内容为 Hello World

创建测试文件
创建测试文件

2.然后创建配置文件Dockerfile

vi Dockerfile

写入信息如下:

#继承Tomcat,可以带版本号,如:FROM tomcat:8.55.22
FROM tomcat:latest

#将index.jsp复制到ROOT目录下
COPY index.jsp /usr/local/tomcat/webapps/ROOT/

写入配置信息
写入配置信息
配置信息详情
配置信息详情

注:上图中的ROOT后边应该有/

3.构建镜像(命令如下):

docker build -t helloworld .

参数说明:

  • -t helloworld :设置镜像的名字

  • . (末尾的点):指Dockerfile文件在当前目录,切只能在最外层目录,其主要目的如下:

  • 在当前目录找到 Dockerfile 配置文件

  • 指定Dockerfile 的上下文目录,并打包文件,传输到Docker Server,在Docker里构建

镜像创建过程
镜像创建过程

4.运行镜像(命令如下):

docker run -p 8080:8080 -d --name hello helloworld

参数说明:

  • -p 8080:8080 :设置端口映射

  • -d :后台启动

  • --name hello:容器的名字

  • helloworld : 镜像的名字

启动成功
启动成功

在浏览器中访问尝试:

访问创建的镜像
访问创建的镜像

上面的乱码是汉字编码问题,这里演示无需在意。

3. 常用命令

3.1 FROM

继承镜像

3.2 COPY 与 ADD(复制文件,不要用ADD)

COPY和ADD都有复制文件到指定目录的功能,其区别主要在:

  • COPY只可以进行复制

  • ADD在复制压缩包(*.tar.gz等)的时候,实现复制并解压功能,也可以将原路径为URL的文件下载到目标目录中,不过权限为600,需要增加额外的配置。

使用COPY时应注意:

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

COPY package.json /usr/src/app/

<源路径> 可以是多个,甚至可以是通配符,其通配符规则要满足 Go 的 filepath.Match 规则,如:

COPY hom* /mydir/
COPY hom?.txt /mydir/

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

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

使用ADD时应注意:

在 Docker 官方的 Dockerfile 最佳实践文档 中要求,尽可能的使用 COPY,因为 COPY 的语义很明确,就是复制文件而已,而 ADD 则包含了更复杂的功能,其行为也不一定很清晰。最适合使用 ADD 的场合,就是所提及的需要自动解压缩的场合。

另外需要注意的是,ADD 指令会令镜像构建缓存失效,从而可能会令镜像构建变得比较缓慢。

因此在 COPY 和 ADD 指令中选择的时候,可以遵循这样的原则,所有的文件复制均使用 COPY 指令,仅在需要自动解压缩的场合使用 ADD

3.3 CMD与ENTRYPOINT(执行脚本)

CMD 指令的格式和 RUN 相似,是两种格式:

  • shell 格式:CMD <命令>

  • exec 格式:CMD ["可执行文件", "参数1", "参数2"…]

  • 参数列表格式:CMD ["参数1", "参数2"…]。在指定了 ENTRYPOINT 指令后,用 CMD 指定具体的参数。

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

这两种命令主要用来执行shell命令。

但是,这两种命令,分别只能使用一次。

对于CMD命令,如果有多条,只执行最后一条。

对于要执行多条shell命令时,可以将其卸载.sh文件中,使用ENTRYPOINT来执行.sh文件。

3.4 ENV(配置环境变量)

格式有两种:

  • ENV

  • ENV = =…

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

ENV VERSION=1.0 DEBUG=on \
    NAME="Happy Feet"

这个例子中演示了如何换行,以及对含有空格的值用双引号括起来的办法。

示例:设置MYSQL的版本:

EVN MYSQL_VERSION 5.7.22

3.5 VOLUME(数据卷配置)

格式为:

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

  • VOLUME <路径>

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

VOLUME /data

这里的 /data 目录就会在运行时自动挂载为匿名卷,任何向 /data 中写入的信息都不会记录进容器存储层,从而保证了容器存储层的无状态化。当然,运行时可以覆盖这个挂载设置。比如:

docker run -d -v mydata:/data xxxx

在这行命令中,就使用了 mydata 这个命名卷挂载到了 /data 这个位置,替代了 Dockerfile 中定义的匿名卷的挂载配置。

3.6 EXPOSE(暴露端口)

格式为 EXPOSE <端口1> [<端口2>...]

示例:暴露两个端口

EXPOSE 8080 3306

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

此外,在早期 Docker 版本中还有一个特殊的用处。以前所有容器都运行于默认桥接网络中,因此所有容器互相之间都可以直接访问,这样存在一定的安全性问题。于是有了一个 Docker 引擎参数 --icc=false,当指定该参数后,容器间将默认无法互访,除非互相间使用了 --links 参数的容器才可以互通,并且只有镜像中 EXPOSE 所声明的端口才可以被访问。这个 --icc=false 的用法,在引入了 docker network 后已经基本不用了,通过自定义网络可以很轻松的实现容器间的互联与隔离。

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

3.7 WORKDIR

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

像命令 CD,但有区别。

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

之前提到一些初学者常犯的错误是把 Dockerfile 等同于 Shell 脚本来书写,这种错误的理解还可能会导致出现下面这样的错误:

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

如果将这个 Dockerfile 进行构建镜像运行后,会发现找不到 /app/world.txt 文件,或者其内容不是 hello。原因其实很简单,在 Shell 中,连续两行是同一个进程执行环境,因此前一个命令修改的内存状态,会直接影响后一个命令;而在 Dockerfile 中,这两行 RUN 命令的执行环境根本不同,是两个完全不同的容器。这就是对 Dockerfile 构建分层存储的概念不了解所导致的错误。

之前说过每一个 RUN 都是启动一个容器、执行命令、然后提交存储层文件变更。第一层 RUN cd /app 的执行仅仅是当前进程的工作目录变更,一个内存上的变化而已,其结果不会造成任何文件变更。而到第二层的时候,启动的是一个全新的容器,跟第一层的容器更完全没关系,自然不可能继承前一层构建过程中的内存变化。

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

4. 示例2(压缩包)

1.首先创建一个压缩包,如下:

创建压缩包
创建压缩包

2.修改配置文件

#继承Tomcat,可以带版本号,如:FROM tomcat:8.55.22
FROM tomcat:latest

# 执行删除命令
RUN rm -fr /usr/local/tomcat/webapps/ROOT/*

#将hello.tar.gz复制到ROOT目录下
COPY hello.tar.gz /usr/local/tomcat/webapps/ROOT/

# 指定工作目录
WORKDIR /usr/local/tomcat/webapps/ROOT

# 解压并删除
RUN tar -zxvf hello.tar.gz \
    && rm -fr hello.tar.gz

# 暴露端口
EXPOSE 8080

如下:

修改配置文件
修改配置文件

3.构建镜像

构建镜像
构建镜像

4.运行镜像:

运行镜像
运行镜像

运行结果如下所示:

运行结果
运行结果

5. 补充:镜像构建上下文

如果注意,会看到 docker build 命令最后有一个 .. 表示当前目录,而 Dockerfile 就在当前目录,因此不少初学者以为这个路径是在指定 Dockerfile 所在路径,这么理解其实是不准确的。如果对应上面的命令格式,你可能会发现,这是在指定 上下文路径。那么什么是上下文呢?

首先我们要理解 docker build 的工作原理。Docker 在运行时分为 Docker 引擎(也就是服务端守护进程)和客户端工具。Docker 的引擎提供了一组 REST API,被称为 [Docker Remote API](),而如 docker 命令这样的客户端工具,则是通过这组 API 与 Docker 引擎交互,从而完成各种功能。因此,虽然表面上我们好像是在本机执行各种 docker 功能,但实际上,一切都是使用的远程调用形式在服务端(Docker 引擎)完成。也因为这种 C/S 设计,让我们操作远程服务器的 Docker 引擎变得轻而易举。

当我们进行镜像构建的时候,并非所有定制都会通过 RUN 指令完成,经常会需要将一些本地文件复制进镜像,比如通过 COPY 指令、ADD 指令等。而 docker build 命令构建镜像,其实并非在本地构建,而是在服务端,也就是 Docker 引擎中构建的。那么在这种客户端/服务端的架构中,如何才能让服务端获得本地文件呢?

这就引入了上下文的概念。当构建的时候,用户会指定构建镜像上下文的路径,docker build 命令得知这个路径后,会将路径下的所有内容打包,然后上传给 Docker 引擎。这样 Docker 引擎收到这个上下文包后,展开就会获得构建镜像所需的一切文件。

如果在 Dockerfile 中这么写:

COPY ./package.json /app/

这并不是要复制执行 docker build 命令所在的目录下的 package.json,也不是复制 Dockerfile 所在目录下的 package.json,而是复制 上下文(context)目录下的 package.json

因此,COPY 这类指令中的源文件的路径都是相对路径。这也是初学者经常会问的为什么 COPY ../package.json /app 或者 COPY /opt/xxxx /app 无法工作的原因,因为这些路径已经超出了上下文的范围,Docker 引擎无法获得这些位置的文件。如果真的需要那些文件,应该将它们复制到上下文目录中去。

现在就可以理解刚才的命令 docker build -t nginx:v3 . 中的这个 .,实际上是在指定上下文的目录,docker build 命令会将该目录下的内容打包交给 Docker 引擎以帮助构建镜像。

如果观察 docker build 输出,我们其实已经看到了这个发送上下文的过程:

docker build -t nginx:v3 .

# 输出如下
Sending build context to Docker daemon 2.048 kB

理解构建上下文对于镜像构建是很重要的,避免犯一些不应该的错误。比如有些初学者在发现 COPY /opt/xxxx /app 不工作后,于是干脆将 Dockerfile 放到了硬盘根目录去构建,结果发现 docker build 执行后,在发送一个几十 GB 的东西,极为缓慢而且很容易构建失败。那是因为这种做法是在让 docker build 打包整个硬盘,这显然是使用错误。

一般来说,应该会将 Dockerfile 置于一个空目录下,或者项目根目录下。如果该目录下没有所需文件,那么应该把所需文件复制一份过来。如果目录下有些东西确实不希望构建时传给 Docker 引擎,那么可以用 .gitignore 一样的语法写一个 .dockerignore,该文件是用于剔除不需要作为上下文传递给 Docker 引擎的。

那么为什么会有人误以为 . 是指定 Dockerfile 所在目录呢?这是因为在默认情况下,如果不额外指定 Dockerfile 的话,会将上下文目录下的名为 Dockerfile的文件作为 Dockerfile。

这只是默认行为,实际上 Dockerfile 的文件名并不要求必须为 Dockerfile,而且并不要求必须位于上下文目录中,比如可以用 -f ../Dockerfile.php 参数指定某个文件作为 Dockerfile

当然,一般大家习惯性的会使用默认的文件名 Dockerfile,以及会将其置于镜像构建上下文目录中。


声明:本文由作者原创发布,转载请联系原作者。

评论

关于我们
这里是网站的说明
关注本站微信号,享受更多服务!
联系方式
电话:159******00
地址:武汉市武昌区
Email:cxh@cxh.work
邮编:430000
Copyright ©2019-2020.Powered by©Z-BlogPHP&拾年之璐  鲁ICP备18018164号