深入理解Dockerfile —— 筑梦之路

2023-12-30 05:22:09

FROM 基础镜像

可以选择现有的镜像,比如centos、debian、apline等,特殊镜像scratch,它是一个空镜像。

如果你以?scratch?为基础镜像的话,意味着你不以任何镜像为基础,接下来所写的指令将作为镜像第一层开始存在。

不以任何系统为基础,直接将可执行文件复制进镜像的做法并不罕见,比如swarmcoreos/etcd。对于 Linux 下静态编译的程序来说,并不需要有操作系统提供运行时支持,所需的一切库都已经在可执行文件里了,因此直接?FROM scratch?会让镜像体积更加小巧。使用 Go 语言开发的应用很多会使用这种方式来制作镜像,这也是为什么有人认为?Go?是特别适合容器微服务架构的语言的原因之一。

RUN 指令

shell?格式:RUN <命令>,就像直接在命令行中输入的命令一样。刚才写的?Dockerfile?中的?RUN?指令就是这种格式。

exec?格式:RUN ["可执行文件", "参数1", "参数2"],这更像是函数调用中的格式。

Union FS?是有最大层数限制的,比如?AUFS,曾经是最大不能超过 42 层,现在是不能超过 127 层。

构建上下文

如果注意,会看到?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,以及会将其置于镜像构建上下文目录中。

重点需要理解构建上下文,对于构建优化比较重要。

其他用法

1. 从url构建

示例:

docker build https://github.com/twang2218/gitlab-ce-zh.git#:8.14

这行命令指定了构建所需的?Git repo,并且指定默认的?master?分支,构建目录为?/8.14/,然后 Docker 就会自己去?git clone?这个项目、切换到指定分支、并进入到指定目录后开始构建。?

2.?用给定的 tar 压缩包构建?

docker build http://server/context.tar.gz

?ocker?引擎会下载这个包,并自动解压缩,以其作为上下文,开始构建。

3.?从标准输入中读取 Dockerfile 进行构建

docker build - < Dockerfile

cat Dockerfile | docker build -

如果标准输入传入的是文本文件,则将其视为?Dockerfile,并开始构建。这种形式由于直接从标准输入中读取?Dockerfile?的内容,它没有上下文,因此不可以像其他方法那样可以将本地文件?COPY?进镜像之类的事情。?

4.?从标准输入中读取上下文压缩包进行构建?

docker build - < context.tar.gz

如果发现标准输入的文件格式是 gzip、bzip2 以及 xz 的话,将会使其为上下文压缩包,直接将其展开,将里面视为上下文,并开始构建。

更多详情请阅读:如何优雅的使用 Dockerfile 定制镜像,超详细!

文章来源:https://blog.csdn.net/qq_34777982/article/details/135292431
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。