A Dockerfile is a text file, where each line consists of an instruction followed by one or more arguments:

INSTRUCTION arguments

There are many types of instructions. Here, we will explain the most important ones.

For a complete reference of all instructions and arguments in a valid Dockerfile, refer to the Dockerfile reference at docs.docker.com/engine/reference/builder/:

• FROM: This specifies the base image, which is the Docker image we are basing our own image on. Each Dockerfile must have a FROM instruction as the first instruction. For example, if we want our application to run on an Ubuntu 18.04 machine, then we’d specify FROM ubuntu:bionic.
• RUN: This specifies the command(s) to run at build time, when we run docker build. Each RUN command corresponds to a layer that comprises our image.
• CMD / ENTRYPOINT: This specifies the command to execute at runtime, after the container is initiated with docker run. At least one of the CMD and/or the ENTRYPOINT command should be specified. CMD should be used to provide default arguments for an ENTRYPOINT command. There should be one, and only one, CMD instruction in a Dockerfile. If multiple are provided, the last one will be used.
• ADD / COPY: This copies files, directories, or remote file URLs to a location inside the filesystem of the image. COPY is similar to ADD except it does not support remote URLs, it does not unpack archive files, and it does not invalidate cached RUN instructions (even if the contents has changed). You can look at COPY as a lightweight version of ADD. You should use COPY over ADD whenever possible.
• WORKDIR: This changes the working directory for any RUN, CMD, ENTRYPOINT, COPY, and ADD instructions that come after the WORKDIR instruction in the Dockerfile
• ENV: This sets environment variables that are available during build and runtime.
• ARG: This defines variables that can be defined at build time (not runtime) by passing the --build-arg <varname>=<value> flag into docker build.

ENV and ARG both provide variables during build time, but ENV values also persist into the built image. In cases where ENV and ARG variables share the same name, the ENV variable takes precedence:

• EXPOSE: This acts as a form of documentation that informs developers of which ports are being listened to by services running inside the container.

There are other, less commonly used instructions:

• ONBUILD: This allows you to add commands that are to be run by child images (images which use the current image as a base image). The commands would be run immediately after the FROM instruction in the child image.
• LABEL: This allows you to attach arbitrary metadata, in the form of key-value pairs, to the image. Any containers loaded with the image would also carry that label. Uses for labels are very broad; for example, you can use it to enable load balancers to identify containers based on their labels.
• VOLUME: This specifies a mount point in the host’s filesystem where you can persist data, even after the container is destroyed.
• HEALTHCHECK: This specifies commands that are run at regular intervals to check that the container is not just alive, but functional. For example, if a web server process is running, but unable to receive requests, it would be deemed unhealthy.
• USER: This specifies the username or UID to use when building/running the image.
• STOPSIGNAL: This specifies the system call signal that will be sent to the container to exit.

Dockerfile instructions are case-insensitive. However, the convention is to use UPPERCASE. You can also add comments in Dockerfiles using hashes (#):

# This is a docker comment