Shulou(Shulou.com)06/03 Report--

1. The basic structure of Dockerfile

Dockerfile is a text document that contains commands for combining images. You can use to invoke any command from the command line. Docker automatically generates an image by reading instructions in Dockerfile.

Dockerfile consists of one line of command statements and supports comment lines that begin with #.

Generally, Dockerfile is divided into four parts: basic image information, maintainer information, mirror operation instructions and instructions to execute when the container starts. As follows:

# This dockerfile uses the ubuntu image# VERSION 2-EDITION Author: Ray# Command format: Instruction [arguments / command]. # Maintainer: docker_user (@ docker_user) MAINTAINER Ray 916551518@qq.com# Commands to update the imageRUN echo "deb http://archive.ubuntu.com/ubuntu/ raring main universe" > > / etc/apt/sources.listRUN apt-get update & & apt-get install-y nginxRUN echo "\ ndaemon off;" > > / etc/nginx/nginx.conf# Commands when creating a new containerCMD / usr/sbin/nginx

The image on which it is based must be specified at first, followed by maintainer information, followed by instructions for image operation, such as RUN, COPY, and so on. Each time you run an instruction, a new layer is added to the image and committed. Note: a maximum of 127 layers are allowed for an image. Finally, the CMD instruction specifies the operation instruction when the container is run.

2. The instruction Docker in Dockerfile realizes the automatic construction of image through the sequential parsing of a series of instructions in Dockerfile by using the build command, according to the description of Dockerfiel, to build the image through the source code path through the standard input stream.

1) FROM-- specifies the basic image

Format: FROM or FROM:.

The first instruction must be a FROM instruction, and if you create multiple mirrors in the same dockerfile, you can use multiple FROM instructions (each mirror once, but generally not).

2) MAINTAINER-- specifies maintainer information

The format is MAINTAINER. Used to specify maintainer information.

3) RUN-- run instruction

Format: RUN or RUN ["executable", "param1", "param2"].

The former will run the command / bin/sh-c in the shell terminal; the latter will be executed using exec. Specifying the use of other terminals can be done in a second way, such as RUN ["/ bin/bash", "- c", "echo hello"].

Each RUN instruction executes the specified command based on the current mirror and is submitted as a new mirror. You can use\ to wrap lines when the command is long. (note: if you think there may be too many layers of mirroring, you can use a RUN instruction followed by multiple instructions, with & & in the middle.)

4) COPY-- copy file\ directory

Format is: format is COPY.

Purpose: copy the local (the source file / directory must be in the same directory as Dockerfile) to the container.

COPY is recommended when using the local directory as the source directory.

When using COPY, the specified source file / directory can also be a file in another image in the following format:

COPY-- from=nginx:latest / etc/nginx/nginx.conf / nginx.conf5) ADD-- more advanced replication files\ directory

The format is ADD. It is very similar to COPY, but also requires that the source file and Dockerfile are in the same directory, or that it is a URL. It's more humane than COPY.

This command copies the specified to the container. It can be a relative path to the directory where Dockerfile resides; it can be a URL (automatically download the file corresponding to URL); or it can be a tar file (automatically extracted to a directory).

When using this directive, you can also add the-- chown=: option to change the user and group of the file.

ADD-chown=55:mygroup files* / mydir/ADD-chown=bin files* / mydir/ADD-chown=1 files* / mydir/

The ADD directive invalidates the image build cache, which may slow the image build.

But in some cases, if we really want to copy a compressed file into it without unzipping it, we can't use the ADD command.

So when choosing between the COPY and ADD instructions, you can follow the principle that all file copies use the COPY instruction, and use ADD only where automatic decompression is required.

6) ENV-- sets environment variables

The format is ENV. Specify an environment variable that will be used by subsequent RUN instructions and maintained while the container is running.

Take a chestnut:

[root@master nginx] # cat Dockerfile # testFROM nginx:latestMAINTAINER Ray ENV var1hello worldENV var2 testRUN echo ${var1}, ${var2} > / test.txt# the contents of the test.txt file in the container in which the image runs are as follows: root@262f47a7682a:/# cat test.txt hello world,test# and the defined variables are stored in the environment variables of the container: root@262f47a7682a:/# echo $var1hello worldroot@262f47a7682a:/# echo $var2test7) ARG-- build parameters

Format: ARG [=]

The build parameters have the same effect as ENV, setting environment variables. The difference is that the environment variables of the build environment set by ARG will not exist when the container runs in the future. But don't use ARG to save information like passwords, because docker history can still see all the values.

The ARG instruction in Dockerfile is to define the parameter name and define its default value. This default value can be overridden with-- build-arg = in the build command docker build.

In versions prior to 1.13, it was required that the parameter names in build-arg must be defined in Dockerfile with ARG, in other words, the parameters specified by build-arg must be used in Dockerfile. If the corresponding parameter is not used, an error is reported to exit the build. Since 1.13, this strict restriction has been released, no longer reporting an error exit, but displaying a warning message and continuing to build. This is helpful when using CI systems to build different Dockerfile with the same build process, avoiding that build commands have to be modified according to the contents of each Dockerfile.

8) EXPOSE-- exposed port

The format is: EXPOSE [...].

The function of this directive is to tell the port number exposed by the container on the docker server for use by the interconnected system. When starting the container, the host will automatically assign a port to the specified port and forward it to the specified port.

9) CMD-- container startup command

It supports the following three formats:

CMD ["executable", "param1", "param2"] is executed using exec, recommended; CMD command param1 param2 is executed in / bin/sh and provided to applications that require interaction; CMD ["param1", "param2"] provides default parameters to ENTRYPOINT

The function is to specify the command to be executed when the container is started. There is only one CMD command per dockerfile. If more than one command is specified, the previous command will be overwritten and only the last instruction will take effect.

If the user starts the container with a command to run, the command specified by CMD is overwritten.

As follows:

[root@master nginx] # cat Dockerfile # dockerfile is as follows # testFROM nginx:latestCMD echo hello worldCMD echo hello [root@master nginx] # docker run-t ljz:v2 # only if the last CMD instruction takes effect hello [root@master nginx] # docker run-t ljz:v2 echo 123456 # specifies other instructions when starting the container, it will overwrite all instructions 123456 in dockerfile

I usually use CMD in combination with ENTRYPOINT. This is the third format above.

10) ENTRYPOINT-- entry point

It supports the following two formats:

ENTRYPOINT ["executable", "param1", "param2"]; ENTRYPOINT command param1 param2 (executed in shell).

Configure the commands that are executed after the container starts and cannot be overridden by the parameters provided by docker run.

There can be only one ENTRYPOINT per dockerfile, and when more than one is specified, only the last one takes effect.

Examples of use:

[root@master nginx] # cat Dockerfile # dokerfile file is as follows # testFROM nginx:latestENTRYPOINT echo hello worldENTRYPOINT echo hello [root@master nginx] # docker run-t ljz:v3 # run this image hello[ root @ master nginx] # docker run-t ljz:v3 echo 123456 # the command specified by the runtime will not be executed hello#, but you can overwrite the ENTRYPOINT instruction in the image with the "--entrypoint" directive Can only be used in combination with the command word [root@master nginx] # docker run-- entrypoint hostname-t ljz:v3afb421b81a7d11) ENTRYPOINT and CMD

In some cases, the combination of ENTRYPOINT and CMD can play a greater role.

Using a combination of ENTRYPOINT and CMD, ENTRYPOINT specifies the default run command, and CMD specifies the default run parameters.

Take a chestnut:

[root@master nginx] # cat Dockerfile # Dockerfile file is as follows # testFROM centos:7ENTRYPOINT ["/ bin/ping", "- c" "3"] CMD ["localhost"] [root@master nginx] # docker run-t ljz:v4 # run container PING localhost (127.0.0.1) 56 (84) bytes of data.64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.028 ms64 bytes from localhost (127.0.0.1): icmp_seq=2 ttl=64 time=0.072 ms64 bytes from localhost (127.0.0.1): icmp_seq=3 ttl=64 time=0.074 ms

The last command to view the container is as follows:

The command executed above is a splicing of ENTRYPOINT and CMD instructions. When ENTRYPOINT and CMD exist at the same time, docker splices the CMD command to the ENTRYPOINT command, and the spliced command is the final command. However, as mentioned above, the value of the CMD instruction can be overridden when the docker run command line is executed. If you want the docker image to be started instead of ping localhost, but other ping servers, you can execute docker run like this:

The following table lists the command line you get if you mix the Shell representation with the Exec representation. You can see that it is difficult to get the correct results if the Shell representation exists:

The spliced instruction of Dockerfile CommandENTRYPOINT / bin/ping-c 3CMD localhost # is as follows: / bin/sh-c'/ bin/ping-c 3' / bin/sh-c localhostENTRYPOINT ["/ bin/ping", "- c" The spliced instruction of "3"] CMD localhost # is as follows: / bin/ping-c 3 / bin/sh-c localhostENTRYPOINT / bin/ping-c 3CMD ["localhost"] "# the stitched instruction is as follows: / bin/sh-c'/ bin/ping-c 3' localhostENTRYPOINT [" / bin/ping ","-c "," 3 "] CMD [" localhost "] # the stitched instruction is as follows: / bin/ping-c 3 localhost

From the above, we can see that only when both ENTRYPOINT and CMD are represented by Exec, can we get the desired results.

12) VOLUME-- defines anonymous volumes

When the container is running, you should try to keep the container storage layer from writing operations. For applications where database classes need to save dynamic data, the database files should be saved in volumes (volume). In order to prevent users from forgetting to mount the directories saved by dynamic files as volumes, in Dockerfile, you can specify some directories to be mounted as anonymous volumes in advance, so that if users do not specify mounts at run time, their applications can run normally. Large amounts of data are not written to the container storage tier.

The instruction format is: VOLUME ["/ data"].

Function: the / data directory will be automatically mounted as anonymous volumes at run time, and any information written to / data will not be recorded in the container storage layer, thus ensuring that the container storage layer is stateless. Of course, the runtime can override this mount setting. For example:

Docker run-d-v mydata:/data xxxx

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

This method is docker manager volumes data persistence mode, and does not support Bind mount mount mode (that is, it does not support specifying a local directory).

After running the container based on image, you can view the details of the container by using the command "docker inspect container_name". In the returned result, you can see the corresponding local directory location in the container by viewing the MOUNT field, as shown below:

[root@master volumes] # docker inspect web02

The result returned is as follows:

13) USER-- specifies the current user

The command format is: USER [:].

Specify the user name or UID when the container is run, and subsequent RUN will also use the specified user.

USER instructions are similar to WORKDIR in that they change the state of the environment and affect subsequent layers. WORKDIR is to change the working directory, and USER is to change the identity of the layer to execute commands such as RUN, CMD, and ENTRYPOINT.

Of course, like WORKDIR, USER only helps you switch to a designated user, who must be established in advance, otherwise you can't switch.

RUN groupadd-r redis & & useradd-r-g redis redisUSER redisRUN ["redis-server"]

If you want to change your identity during execution as a script executed by root, for example, you want to run a service process as an established user instead of using su or sudo, these require cumbersome configuration and often make errors in an environment where TTY is missing. Gosu is recommended.

# establish a redis user and use gosu for another user to execute the command RUN groupadd-r redis & & useradd-r-g redis redis# to download gosuRUN wget-O / usr/local/bin/gosu "https://github.com/tianon/gosu/releases/download/1.7/gosu-amd64"\ & & chmod + x / usr/local/bin/gosu\ & & gosu nobody true# to set CMD And execute CMD ["exec", "gosu", "redis", "redis-server"] 14) with another user to specify the working directory

The format is WORKDIR / path/to/workdir.

Configure the working directory for subsequent RUN, CMD, and ENTRYPOINT instructions.

Multiple WORKDIR instructions can be used, and subsequent commands, if the argument is a relative path, are based on the path specified by the previous command. For example

WORKDIR / aWORKDIR bWORKDIR cRUN pwd

The final path is / a/b/c.

15) ONBUILD-- makes wedding clothes for others

The format is ONBUILD [INSTRUCTION].

Configure the operation instructions that are performed when the created mirror is used as the base mirror for other newly created mirrors.

For example, Dockerfile creates a mirror image-A with the following content.

[...] ONBUILD ADD. / app/srcONBUILD RUN / usr/local/bin/python-build-- dir / app/src [...]

If you create a new image based on image-A, when you specify the base image using FROM image-An in the new Dockerfile, the content of the ONBUILD instruction will be executed automatically, which is equivalent to adding two instructions later.

FROM image-A#Automatically run the followingADD. / app/srcRUN / usr/local/bin/python-build-- dir / app/src

Use the image of the ONBUILD directive. It is recommended to indicate it in the tag, such as ruby:1.9-onbuild.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.