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

This article mainly explains "what is the use of Dockerfile". The content of the explanation in the article is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn "what is the use of Dockerfile"?

About Layer Caching in Docker

Docker uses layer layer to create mirrors, and each command in Dockerfile creates a new layer, each layer containing file system changes mirrored between states before and after the command is executed.

To speed up the build, Docker implements caching:

If the Dockerfile and related files have not changed, you can reuse some existing layers in the local mirror cache when rebuilding (rebuild).

However, in order to take advantage of this cache, you need to understand how it works, which is what we will cover in this article.

The basic algorithm

When you build Dockerfile, Docker will see if it can use the previously built cache results:

For most commands, if the command text has not changed, the version in the cache is used. For COPY, it also checks that the file you want to copy has not changed.

Let's look at an example of using the following Dockerfile:

FROM python:3.7-slim-buster

COPY. .

RUN pip install-- quiet-r requirements.txt

ENTRYPOINT ["python", "server.py"]

The first time you run, all commands run:

$docker build-t example1.

Sending build context to Docker daemon 5.12kB

Step 1/4: FROM python:3.7-slim-buster

-- > f96c28b7013f

Step 2/4: COPY. .

-- > eff791eb839d

Step 3ax 4: RUN pip install-- quiet-r requirements.txt

-- > Running in 591f97f47b6e

Removing intermediate container 591f97f47b6e

-- > 02c7cf5a3d9a

Step 4ax 4: ENTRYPOINT ["python", "server.py"]

-- > Running in e3cf483c3381

Removing intermediate container e3cf483c3381

-- > 598b0340cc90

Successfully built 598b0340cc90

Successfully tagged example1:latest

On the second build, because there is no change, the docker build will use the mirror cache:

$docker build-t example1.

Sending build context to Docker daemon 5.12kB

Step 1/4: FROM python:3.7-slim-buster

-- > f96c28b7013f

Step 2/4: COPY. .

-- > Using cache

-- > eff791eb839d

Step 3ax 4: RUN pip install-- quiet-r requirements.txt

-- > Using cache

-- > 02c7cf5a3d9a

Step 4ax 4: ENTRYPOINT ["python", "server.py"]

-- > Using cache

-- > 598b0340cc90

Successfully built 598b0340cc90

Successfully tagged example1:latest

Note that the Using cache shown above speeds up the build (no need to download any pip dependent packages from the network)

If we delete the mirror, the subsequent build will start from scratch (there is no layer cache):

$docker image rm example1

Untagged: example1:latest

Deleted: sha256:598b0340cc90967501c5c51862dc586ca69a01ca465f48232fc457d3ab122a73

Deleted: sha256:02c7cf5a3d9af1939b9f5286312b23898fd3ea12b7cb1d7a77251251740a806c

Deleted: sha256:d9e9602d9c3fd7381a8e1de301dc4345be2eb2b8488b5fc3e190eaacbb2f9596

Deleted: sha256:eff791eb839d00cbf46d139d8595b23867bc580bb9164b90253d0b2d9fcca236

Deleted: sha256:53d34b2ead0a465d229a4260fee2a845fb8551856d4019cd2e608dfe0e039e77

$docker build-t example1.

Sending build context to Docker daemon 5.12kB

Step 1/4: FROM python:3.7-slim-buster

-- > f96c28b7013f

Step 2/4: COPY. .

-- > 63c32b9b1af6

...

Taking advantage of caching

There is a more important rule for caching algorithms:

If a layer cannot apply a layer cache, subsequent layers cannot be loaded from the layer cache

In the following example, the C layer has not changed before and after the build process, however, since the upper layer is not loaded from the layer cache, the post C layer still cannot be loaded from the cache:

What does layer caching mean for the following Dockerfile?

FROM python:3.7-slim-buster

COPY requirements.txt.

COPY server.py.

RUN pip install-- quiet-r requirements.txt

ENTRYPOINT ["python", "server.py"]

If any file of the COPY command changes, it invalidates all subsequent layer caches: we need to rerun pip install (this layer usually takes a long time without caching).

But if requirements.txt hasn't changed & server.py has changed, why do we have to redo the pip installation? After all, the pip installation uses only requirements.txt.

"

Extended to modern programming languages: the front-end dependent package file paakcage.json, dotnet project management file dotnetdemo.csproj, etc., generally rarely change; business code changes at any time, resulting in subsequent layer cache invalidation (subsequent layers have to be re-downloaded every time & installation dependence).

Therefore, what you need to do is to copy only those files that actually need to run the next step to minimize the chance of cache invalidation.

FROM python:3.7-slim-buster

COPY requirements.txt.

RUN pip install-- quiet-r requirements.txt

COPY server.py.

ENTRYPOINT ["python", "server.py"]

Because server.py is copied to the build context only after the pip installation, the layer created by the last pip installation can still be loaded from the cache as long as the requirements.txt remains the same.

Designing your Dockerfile for caching

If you want to build quickly by reusing previously cached layers, you need to write Dockerfile appropriately:

Copy only the files needed for the next step to minimize cache invalidation during the build process. Try to delay the addition (ADD command) and copy (COPY command) of possible changes to the back of the Dockerfile.

Thank you for your reading, the above is the content of "what is the use of Dockerfile". After the study of this article, I believe you have a deeper understanding of what the use of Dockerfile is, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

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.