可以选择现有的镜像，比如centos、debian、apline等，特殊镜像scratch，它是一个空镜像。
如果你以?scratch?为基础镜像的话，意味着你不以任何镜像为基础，接下来所写的指令将作为镜像第一层开始存在。
不以任何系统为基础，直接将可执行文件复制进镜像的做法并不罕见，比如swarm、coreos/etcd。对于 Linux 下静态编译的程序来说，并不需要有操作系统提供运行时支持，所需的一切库都已经在可执行文件里了，因此直接?FROM scratch?会让镜像体积更加小巧。使用 Go 语言开发的应用很多会使用这种方式来制作镜像，这也是为什么有人认为?Go?是特别适合容器微服务架构的语言的原因之一。
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 定制镜像，超详细！