COPY and ADD commands in Dockerfile

Dockerfile provides two very similar commands to COPY and ADD, this article attempts to explain the basic functions of the two commands, as well as their similarities and differences, and then summarizes their respective appropriate application scenarios.

concept of Build context

When you create a mirror from Dockerfile using the Docker Build command, a build context is generated. The so-called build context is the set of files in the path or URL specified by the Docker build command. Any file in the context can be referenced in the image build process, such as the COPY and ADD commands we want to introduce, to reference the files in the context.

Docker build-t Testx by default. In the command. Represents the current directory for the build context. 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 file found in the root directory of the context.

Copy and ADD commands cannot copy local files outside the context
For the copy and ADD commands, if you want to copy the local file to the mirror, the local file must be a file in the context directory. This is a good explanation, because when the build command is executed, theDocker client sends all the files in the context to the Docker daemon. Considering the situation where the Docker client and Docker daemon are not on the same machine, the build command can only fetch files from the context. If we reference a file that is not in the context in the COPY and ADD command of Dockerfile, we receive an error similar to the following:

Working together with Workdir

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

Workdir/appcopy 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

The copy command is most appropriate if you are simply copying local files to the container image. The format of its command is:
COPY <src> <dest>

In addition to specifying the full file name, the COPY command supports GO-style wildcard characters, such as:

Copy check*/testdir/           # Copy all files at the beginning of the check copy check?. log/testdir/       #? is a placeholder for a single character, such as a matching file Check1.log

For catalogs, the copy and ADD commands have the same characteristics: Copy only the contents of the directory and not the directory itself. For example, we add the following command to the Dockerfile:

Workdir/appcopy nickdir.

Where the Nickdir directory is structured 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 level of directory Nickdir is missing. If you want to keep file1 and file2 in the Nickdir directory, you need to specify the name of the directory in the destination path, such as:

Workdir/. /nickdir

The

COPY command differs from the one used by the ADD command in a multistage scenario. about Multistage's introduction and usage, please refer to the author's "Dockerfile in the Multi-Stage" article. In multistage usage, you can use the Copy command to copy the product of the previous phase build 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/htmlcopy app.go. RUN cgo_enabled  =0  goos=linux go build-a-installsuffix CGO-certificatesworkdir /root/< Span style= "COLOR: #ff0000" >  COPY--from=0/go/src/github.com/sparkdevo/href-counter/    app.   CMD [  " ./app   "] 

This code refers to the article "Multi-Stage in Dockerfile", where the copy command copies the product of the previous phase to the current image by specifying the--from=0 parameter.

ADD command can also do other things

The ADD command has the same format as the COPY command and is also:
ADD <src> <dest>

In addition to being unable to use the multistage scenario, the ADD command can complete all functions of the COPY command, and can also accomplish two cool features:

• Unzip the compressed files and add them to the image
• Copy files from URL to image

Of course, these features also make the ADD command more complex to use than the COPY command to be intuitive.

Unzip the compressed files and add them to the image
If we have a zipped package, and we need to add the files in this package to the image. Do you need to unpack the package first and then execute the COPY command? Of course you don't! We can do this one time with the ADD command:

Workdir/appadd nickdir. tar. gz.

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

Copy files from URL to image
This is a more cool usage! But the best practice in Docker's official documentation is strongly advised not to use it!! Docker officials recommend that you use the Curl or wget command instead of the ADD command when you need to copy files remotely. The reason is that when you use the ADD command, more mirror layers are created and of course the size of the mirror is larger (the following two code is from the Docker official document):

ADD http://example.com/big.tar.xz/usr/src/things/tar -xjf/usr/src/things/big. tar. xz-c/usr/src/ make-c/usr/src/things all

If you use the following command, not only the number of layers for mirroring is reduced, but also the Big.tar.xz file is not included in the image:

mkdir -p/usr/src/things \    && curl-sl http://example.com/big.tar.xz \< /c11>    tar -xjc/usr/src/things \    make-c/usr/src/things all

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

tips for accelerating image building

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

Where myhc.py files change infrequently, and the three files of checkmongo.py, checkmysql.py, and checkredis.py are constantly changing, we can design Dockerfile files like this:

Workdir/appcopy myhc.py. COPY Check*.

Let COPY myhc.py. Occupy a mirrored layer separately, and once the build has been completed, the three-file checkmongo.py, checkmysql.py, and checkredis.py will not be re-build COPY myhc.py each time it is changed. Mirroring layer:

As shown, the second and third steps do not rebuild the mirroring layer, but instead use the previous cache, starting with the fourth step to rebuild the mirroring layer. When the file size is large and the number of files is more, especially if you need to perform installation operations, such a design for the build speed improvement is still obvious. So we should try to choose the Dockerfile notation that can use the cache.

Summary

When you see the COPY and ADD commands for the first time, you are puzzled. But after the analysis, you will find that the COPY command is designed for the most basic usage, with clear concepts and simple operation. The ADD command is basically a superset of the copy command (in addition to the multistage scenario), enabling some handy, cool copy operations. The add command adds functionality while increasing the complexity of using it, such as compressing files from a URL copy to ills greater than the benefit. Hopefully this article will be able to solve your doubts about the COPY and ADD commands in Dockerfile.

reference:
docker copy:dockerfile best Practices
best Practices for writing dockerfiles
dockerfile COPY
dockerfile ADD