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

How do I use the COPY and ADD commands in Dockerfile? In view of this problem, this article introduces the corresponding analysis and answers in detail, hoping to help more partners who want to solve this problem to find a more simple and feasible way.

The concept of Build context

When you use the docker build command to create a mirror through Dockerfile, a build context (context) is generated. The so-called build context is a collection of files in the path specified by the PATH or URL of the docker build command. During the process of mirroring build, you can reference any file in context, such as the COPY and ADD commands we will introduce, you can reference files in context.

By default, docker build-t testx. In the order. Indicates that the build context is the current directory. Of course, we can specify a directory as the context, such as the following command:

$docker build-t testx / home/nick/hc

We specify the / home/nick/hc directory as the build context, and by default docker uses the Dockerfile files found at the root of the context.

The COPY and ADD commands cannot copy local files outside the context

For the COPY and ADD commands, if you want to copy a local file to an image, the local file must be a file in the context directory. This is easy to explain, because when the build command is executed, the docker client sends all the files in the context to docker daemon. Considering that the docker client and docker daemon are not on the same machine, the build command can only get files from context. If we reference a file that is not in context in the COPY and ADD commands of Dockerfile, we will receive an error similar to the following:

Work with WORKDIR

The WORKDIR command configures the working directory for subsequent RUN, CMD, COPY, ADD, and so on. After the WORKDIR command is set, the relative path in the following COPY and ADD commands is relative to the path specified by WORKDIR. For example, we add the following command to Dockerfile:

WORKDIR / app

COPY checkredis.py.

Then build a container image named testx, and run a container to view the file path:

The checkredis.py file is copied to the WORKDIR / app directory.

Simplicity of the COPY command

If you are just copying local files to the container image, the COPY command is most appropriate. The format of the command is:

COPY

In addition to specifying the full file name, the COPY command also supports Go-style wildcards, such as:

COPY check* / testdir/ # copy all files at the beginning of check

COPY check?.log / testdir/ #? Is a placeholder for a single character, such as the matching file check1.log

For directories, the COPY and ADD commands share the same characteristics: only the contents of the directory are copied, not the directory itself. For example, we add the following command to Dockerfile:

WORKDIR / app

COPY nickdir.

The structure of nickdir directory is as follows:

Rebuild the mirror testx, run a container and view the contents of the / app directory:

There are only file1 and file2, and a layer of directory nickdir is missing. If you want file1 and file2 to still be saved in the nickdir directory, you need to specify the name of the directory in the target path, such as:

WORKDIR / app

COPY nickdir. / nickdir

One use that distinguishes the COPY command from the ADD command is in the multistage scenario. For the introduction and usage of multistage, please refer to the author's article "multi-stage in Dockerfile". In the use of multistage, you can use the COPY command to copy the artifacts built in the previous phase to another image, such as:

FROM golang:1.7.3

WORKDIR / go/src/github.com/sparkdevo/href-counter/

RUN go get-d-v golang.org/x/net/html

COPY app.go.

RUN CGO_ENABLED=0 GOOS=linux go build-a-installsuffix cgo-o app.

FROM alpine:latest

RUN apk-no-cache add ca-certificates

WORKDIR / root/

COPY-from=0 / go/src/github.com/sparkdevo/href-counter/app.

CMD [". / app"]

This code is quoted from the article "multi-stage in Dockerfile", where the COPY command copies the artifacts built in the previous phase to the current image by specifying the-- from=0 parameter.

ADD commands can do other things as well.

The format of the ADD command is the same as the COPY command, which is also:

ADD

Except that it cannot be used in multistage scenarios, the ADD command can perform all the functions of the COPY command, and it can also perform two kinds of cool functions:

Extract the compressed files and add them to the image

Copy files from url to the mirror

Of course, these features also make the ADD command a little more complex to use and not as intuitive as the COPY command.

Extract the compressed files and add them to the image

If we have a compressed package, and we need to add the files in this package to the image. Do you need to unpack the package and then execute the COPY command? Of course not! We can do it all at once with the ADD command:

WORKDIR / app

ADD nickdir.tar.gz.

This should be the best scenario for using the ADD command!

Copy files from url to the mirror

This is a cooler usage! But it is strongly recommended not to be used this way in the best practices of docker official documentation! Docker officials suggest that when we need to copy files remotely, it is best to use the curl or wget command instead of the ADD command. The reason is that when you use the ADD command, more mirror layers are created, and of course the mirror size is larger (the following two pieces of code are from the official docker documentation):

ADD http://example.com/big.tar.xz / usr/src/things/

RUN tar-xJf / usr/src/things/big.tar.xz-C / usr/src/things

RUN make-C / usr/src/things all

If you use the following command, not only the number of layers of the mirror is reduced, but the big.tar.xz file is not included in the mirror:

RUN mkdir-p / usr/src/things\

& & curl-SL http://example.com/big.tar.xz\

| | tar-xJC / usr/src/things\ |

& & make-C / usr/src/things all

Well, it looks like you only need the ADD command to extract the compressed files and add them to the image!

Techniques for accelerating the Construction of Images

There are some tricks we can use to speed up the build process of mirroring when using the COPY and ADD commands. For example, copy operations of files that are least prone to change are placed in a lower mirror layer, so that the cache generated by the previous build is used when re-build the image. For example, the author needs to use the following files when building an image:

The myhc.py file does not change frequently, while the checkmongo.py, checkmysql.py, and checkredis.py files change frequently, so we can design the Dockerfile file like this:

WORKDIR / app

COPY myhc.py.

COPY check*. /

Let COPY myhc.py. Occupy a separate mirror layer, and when the build is passed once, the re-build caused by the changes in checkmongo.py, checkmysql.py and checkredis.py files will not be re-build COPY myhc.py. Mirror layer:

As shown in the figure above, the second and third steps do not re-build the mirror layer, but use the previous cache, re-build the mirror layer from step 4. When the file size is relatively large and the number of files is relatively large, especially when you need to perform operations such as installation, such a design is still very obvious for the improvement of build speed. So we should try to choose Dockerfile writing that can use caching.

This is the answer to the question about how to use COPY and ADD commands in Dockerfile. I hope the above content can be of some help to you. If you still have a lot of doubts to be solved, you can follow the industry information channel to learn more about it.

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.