Quoted from: http://www.cnblogs.com/jsonhc/p/7766841.html
Docker automates the construction of images by sequentially parsing a series of instructions in a Dockerfile
- Build the image as described by Dockerfield by using the build command
- By way of source code path
- via the standard input stream
via source code path
- Dockerfile needs to be placed in the root directory location of the project
- When building, the Dockerfile client will package the entire context and send it to the Docker Server, and then the server will build the image. After the build is successful, the context directory will be deleted.
- docker build -t {image name} {project path can be relative}
- Before docker uses Dockerfile to build a new image, let's take a look at the instructions used in Dockerfile creation
Via the standard input stream:
- Get the contents of the Dockerfile through the standard input stream
- The client will not package and upload the context directory, so some operations involving host local file copying such as ADD and COPY cannot be supported.
- docker build -t {image name} - < Dockerfile path
build cache：
- After each instruction in the Dockerfile is executed, it will be submitted as an image, which ensures that there will be no influence between the instructions
- Dockerfile tries to reuse previously built images whenever possible
- This cache can be disabled by adding --no-cache to the build command
Dockerfile instructions:
- Only supports a set of instructions defined by Docker itself, does not support customization
- Not case sensitive, but all uppercase is recommended
- Execute sequentially according to the contents of the Dockerfile
FROM：
- FROM {base image}
- Must be placed on the first line of the DOckerfile, indicating which baseimage to start building from
MAINTAINER: optional, where to identify the author of the image
RUN：
- Each RUN instruction will be run in a new container and submitted as an image as the base of the next RUN
- A Dockerfile can contain multiple RUNs, which are executed in the defined order
- RUN supports two running modes:
- RUN <cmd> this will run as /bin/sh -c "cmd"
- RUN["executable", "arg1", . . ], Docker parses it as the order of json, so double quotes must be used, and the executable needs to be a full path
RunThey all start a container, execute commands, and then commit the storage layer file changes. The execution of the first layer RUN command1 is only the current process, a change in memory, and the result will not cause any files. When it comes to the second layer, a brand new container is started, which has nothing to do with the container of the first layer. Naturally, it is impossible to inherit the memory changes in the construction process of the previous layer. And if you need to combine two commands or multiple commands to execute, you need to add &&. Such as: cd /usr/local/src && wget xxxxxxx
CMD：
- The role of CMD is as the default behavior when executing the container (the default startup command of the container)
- When the command is declared when running the container, the default command defined by the CMD in the image is no longer used.
- There can only be one valid CMD in a Dockerfile. When multiple CMDs are defined, only the last one will work
Three ways of CMD definition:
- CMD <cmd> This will be executed as /bin/sh -c "cmd"
- CMD ["executable","arg1",....]
- CMD ["arg1", "arg2"], this time CMD is used as the parameter of ENTRYPOINT
EXPOSE declare port
The format is EXPOSE<端口1> [<端口2>...]
EXPOSE指令是声明运行时容器提供服务端口，这只是一个声明，在运行时并不会因为这个声明应用就会开启这个端口的服务。在 Dockerfile 中写入这样的声明有两个好处，一个是帮助镜像使用者理解这个镜像服务的守护端口，以方便配置映射；另一个用处则是在运行时使用随机端口映射时，也就是 docker run -P 时，会自动随机映射 EXPOSE 的端口。
entrypoint：
- entrypoint的作用是，把整个container变成了一个可执行的文件，这样不能够通过替换CMD的方法来改变创建container的方式。但是可以通过参数传递的方法影响到container内部
- 每个Dockerfile只能够包含一个entrypoint，多个entrypoint只有最后一个有效
- 当定义了entrypoint以后，CMD只能够作为参数进行传递
entrypoint定义方式：
- entrypoint ["executable","arg1","arg2"]，这种定义方式下，CMD可以通过json的方式来定义entrypoint的参数，可以通过在运行container的时候通过指定command的方式传递参数
- entrypoint <cmd>，当作/bin/bash -c "cmd"运行命令
ADD & COPY：
- 当在源代码构建的方式下，可以通过ADD和COPY的方式，把host上的文件或者目录复制到image中
- ADD和COPY的源必须在context路径下
- 当src为网络URL的情况下，ADD指令可以把它下载到dest的指定位置，这个在任何build的方式下都可以work
- ADD相对COPY还有一个多的功能，能够进行自动解压压缩包
ENV：
- ENV key value
- 用来设置环境变量，后续的RUN可以使用它所创建的环境变量
- 当创建基于该镜像的container的时候，会自动拥有设置的环境变量
WORKDIR：
- 用来指定当前工作目录（或者称为当前目录）
- 当使用相对目录的情况下，采用上一个WORKDIR指定的目录作为基准
USER：指定UID或者username，来决定运行RUN指令的用户
ONBUILD：
- ONBUILD作为一个trigger的标记，可以用来trigger任何Dockerfile中的指令
- 可以定义多个ONBUILD指令
- 当下一个镜像B使用镜像A作为base的时候，在FROM A指令前，会先按照顺序执行在构建A时候定义的ONBUILD指令
- ONBUILD <DOCKERFILE 指令> <content>
VOLUME：
- 用来创建一个在image之外的mount point，用来在多个container之间实现数据共享
- 运行使用json array的方式定义多个volume
- VOLUME ["/var/data1","/var/data2"]
- 或者plain text的情况下定义多个VOLUME指令
后面针对这些指令的用法有详细的案例。