{"id":1622,"date":"2019-04-05T03:48:40","date_gmt":"2019-04-05T03:48:40","guid":{"rendered":"http:\/\/kusuaks7\/?p=1227"},"modified":"2023-08-08T12:46:48","modified_gmt":"2023-08-08T12:46:48","slug":"slimming-down-your-docker-images-part-4-of-learn-enough-docker-to-be-useful","status":"publish","type":"post","link":"https:\/\/www.experfy.com\/blog\/bigdata-cloud\/slimming-down-your-docker-images-part-4-of-learn-enough-docker-to-be-useful\/","title":{"rendered":"Slimming Down Your Docker Images Part 4 of Learn Enough Docker to be Useful"},"content":{"rendered":"

In this article you\u2019ll learn how to speed up your Docker build cycles and create lightweight images. Keeping with our food metaphors, we\u2019re going to be eating salad as we slim down our Docker images\u200a\u2014\u200ano more pizza, donuts, and bagels.<\/p>\n

<\/canvas><\/figure>\n

In Part 3 of this series,\u00a0 we covered a dozen Dockerfile instructions to know. If you missed it, check out the article here<\/a>.<\/p>\n

Here\u2019s the cheatsheet.<\/p>\n

FROM<\/code>\u200a\u2014\u200aspecifies the base (parent) image.
\nLABEL<\/code>\u00a0\u2014provides metadata. Good place to include maintainer info.
\nENV<\/code>\u200a\u2014\u200asets a persistent environment variable.
\nRUN<\/code>\u00a0\u2014runs a command and creates an image layer. Used to install packages into containers.
\nCOPY<\/code>\u200a\u2014\u200acopies files and directories to the container.
\nADD<\/code>\u200a\u2014\u200acopies files and directories to the container. Can upack local\u00a0.tar files.
\nCMD<\/code>\u200a\u2014\u200aprovides a command and arguments for an executing container. Parameters can be overridden. There can be only one CMD.
\nWORKDIR<\/code>\u200a\u2014\u200asets the working directory for the instructions that follow.
\nARG<\/code>\u200a\u2014\u200adefines a variable to pass to Docker at build-time.
\nENTRYPOINT<\/code>\u200a\u2014\u200aprovides command and arguments for an executing container. Arguments persist.
\nEXPOSE<\/code>\u200a\u2014\u200aexposes a port.
\nVOLUME<\/code>\u200a\u2014\u200acreates a directory mount point to access and store persistent data.<\/p>\n

Let\u2019s now look at how we can fashion our Dockerfiles to save time when developing images and pulling containers.<\/p>\n

Caching<\/h3>\n

One of Docker\u2019s strengths is that it provides caching to help you more quickly iterate your image builds.<\/p>\n

When building an image, Docker steps through the instructions in your Dockerfile, executing each in order. As each instruction is examined, Docker looks for an existing intermediate image in its cache that it can reuse instead of creating a new (duplicate) intermediate image.<\/p>\n

If cache is invalidated, the instruction that invalidated it and all subsequent Dockerfile instructions generate new intermediate images. As soon as the cache is invalidated, that\u2019s it for the rest of the instructions in the Dockerfile.<\/p>\n

So starting at the top of the Dockerfile, if the base image is already in the cache it is reused. That\u2019s a hit. Otherwise, the cache is invalidated.<\/p>\n

<\/p>\n

Also a\u00a0hit<\/p>\n

Then the next instruction is compared against all child images in the cache derived from that base image. Each cached intermediate image is compared to see if the instruction finds a cache hit. If it\u2019s a cache miss, the cache is invalidated. The same process is repeated until the end of the Dockerfile is reached.<\/p>\n

Most new instructions are simply compared with those in the intermediate images. If there\u2019s a match, then the cached copy is used.<\/p>\n

For example, when a\u00a0RUN pip install -r requirements.txt<\/code>\u00a0instruction is found in a Dockerfile, Docker searches for the same instruction in its locally cached intermediate images. The content of the old and new\u00a0requirements.txt<\/em>files are not compared.<\/p>\n

This behavior can be problematic if you update your\u00a0requirements.txt<\/em>\u00a0file with new packages and use\u00a0RUN pip install<\/code>\u00a0and want to rerun the package installation with the new package names. I\u2019ll show a few solutions in a moment.<\/p>\n

Unlike other Docker instructions, ADD and COPY instructions do require Docker to look at the contents of the file(s) to determine if there is a cache hit. The checksum of the referenced file is compared against the checksum in the existing intermediate images. If the file contents or metadata have changed, then the cache is invalidated.<\/p>\n

Here are a few tips for using caching effectively.<\/p>\n