This article has participated in the Denver Nuggets Creators Camp 3 “More Productive writing” track, see details: Digg project | creators Camp 3 ongoing, “write” personal impact.

ENV Sets environment variables

1, the format

  • ENV <key> <value>
  • ENV <key1>=<value1> <key2>=<value2>...

2,

This directive simply sets environment variables, which can be used by any subsequent directive, such as RUN, or by any application at runtime.

ENV VERSION=1.0 DEBUG=on \
    NAME="Happy Feet"
Copy the code

This example shows how to wrap lines and enclose values with Spaces in double quotes, which is consistent with Shell behavior.

An environment variable is defined so that it can be used in subsequent instructions. For example, in the official Node image Dockerfile, there is code like this:

ENV NODE_VERSION 7.2.0 RUN curl - SLO "https://nodejs.org/dist/v$NODE_VERSION/node-v$NODE_VERSION-linux-x64.tar.xz" \ && curl -SLO "https://nodejs.org/dist/v$NODE_VERSION/SHASUMS256.txt.asc" \ && gpg --batch --decrypt --output SHASUMS256.txt  SHASUMS256.txt.asc \ && grep " node-v$NODE_VERSION-linux-x64.tar.xz$" SHASUMS256.txt | sha256sum -c - \ && tar -xJf "node-v$NODE_VERSION-linux-x64.tar.xz" -C /usr/local --strip-components=1 \ && rm "node-v$NODE_VERSION-linux-x64.tar.xz"  SHASUMS256.txt.asc SHASUMS256.txt \ && ln -s /usr/local/bin/node /usr/local/bin/nodejsCopy the code

The environment variable NODE_VERSION is defined first, and then the RUN layer uses $NODE_VERSION several times to customize the operation. As you can see, when upgrading image builds in the future, you only need to update 7.2.0, making Dockerfile builds and maintenance much easier.

The following commands support the expansion of environment variables: ADD, COPY, ENV, EXPOSE, FROM, LABEL, USER, WORKDIR, VOLUME, STOPSIGNAL, ONBUILD, and RUN.

As you can see from this list of instructions, environment variables can be used in many powerful ways. With environment variables, we can make more images of a Dockerfile by using different environment variables.

ARG build parameters

1, the format

  • ARG < parameter name >[=< default value >]

2,

Build parameters have the same effect as ENV, setting environment variables. The difference is that the ARG sets environment variables for the build environment that will not be present when the container runs. But don’t use arGS to store things like passwords, because Docker History will still see all the values.

The ARG directive in a Dockerfile defines the parameter name and its default value. This default value can be overridden in the build command docker build with –build-arg < parameter name >=< value >.

In versions prior to 1.13, the –build-arg parameter names must be defined by arg in the Dockerfile. In other words, the –build-arg parameter names must be used in the Dockerfile. If the corresponding parameter is not used, an error is reported and the build exits. Starting with 1.13, this strict restriction was lifted, and instead of an error exit, a warning message was displayed, and the build continued. This is helpful when using a CI system to build different dockerfiles using the same build process, avoiding the need for the build command to change according to the contents of each Dockerfile.

VOLUME Defines an anonymous VOLUME

1, the format

  • VOLUME ["< path 1>", "< path 2>"...
  • VOLUME < path >

2,

When the container is running, it should try its best to keep no write operations on the container storage layer. For applications that need to store dynamic data in database classes, their database files should be stored in volumes. We will further introduce the concept of Docker volumes in the following chapters. In order to prevent runtime users from forgetting to mount directories stored in dynamic files as volumes, in Dockerfile, we can specify some directories to be mounted as anonymous volumes in advance. In this way, if users do not specify mount at runtime, their applications can run normally without writing a large amount of data to the container storage layer.

VOLUME /data
Copy the code

The /data directory is automatically mounted as an anonymous volume at run time, and any information written to /data is not recorded in the container storage layer, thus ensuring stateless container storage layer. Of course, the runtime can override this mount setting. Such as:

docker run -d -v mydata:/data xxxx
Copy the code

In this command, the named volume mydata is mounted to /data instead of the anonymous volume configuration defined in Dockerfile.