理解构建上下文（Build Context）
- 当运行 docker build 命令时，当前工作目录被称为构建上下文，docker本身会将工作目录里面所有的文件都上传给docker daemon，在这个基础之上再去构建容器镜像。（如果你在根目录去构建容器镜像，将根目录作为构建上下文，那么会相当的慢，它会去检索我所在的当前目录，会将当前目录的所有内容都传输给docker daemon，这样构建的效率会非常的底下）
- docker build 默认查找当前目录的 Dockerfile作为构建输入，也可以通过-f指定 Dockerfile。
docker build -f ./Dockerfile
- 当docker build 运行时，首先会把构建上下文传输给docker daemon，把没用的文件包含在构建上下文时，会导致传输时间长，构建需要的资源多，构建出的镜像大等问题。
试着到一个包含文件很多的目录运行下面的命令，会感受到差异：
（1）docker build-f $GOPATH/src/github.com/cncamp/golang/httpserver/Dockerfile
（2）docker build $GOPATH/src/github.com/cncamp/golang/httpserver/
可以通过.dockerignore文件从编译上下文排除某些文件。
- 因此需要确保构建上下文清晰，比如创建一个专门的目录放置 Dockerfile，并在目录中运行docker build。
[root@jenkins dockerfile]# docker build -f ./Dockerfile -t java-demo:v1.1 .
[+] Building 0.1s (7/7) FINISHED docker:default
=> [internal] load build definition from Dockerfile 0.0s
=> => transferring dockerfile: 311B 0.0s
=> [internal] load metadata for docker.io/library/openjdk:8-jdk-alpine 0.0s
=> [internal] load .dockerignore 0.0s
=> => transferring context: 2B docker build -f docker/Dockerfile -t 镜像名字（给镜像起一个名字）：v1.1.1 .
后面这个点. 是打包镜像（这行命令最后有一个‘空格 点’不能忽略）
需要注意的是，在 docker build 命令接收的参数中，提供给 docker build 命令的 -f 选项应该 Dockerfile 路径名。如果 Dockerfile 文件就叫 Dockerfile 那么文件名可省略，如果 Dockerfile 文件就在当前目录下，那么 -f 选项可省略。
docker build -f ./Dockerfile -t xxx .
# 等同于
docker build -f . -t xxx .
# 等同于
docker build -t xxx .
如果你的 Dockerfile 在别处，而且还不叫 Dockerfile 那么你的 docker build 命令就应该形如如下形式：
docker build -f /xxx/yyy/zzz -t xxx .
在上面的例子中，你的 Dockerfile 在 /xxx/yyy 下，名为 zzz 。
