3. Best Practices for Optimising Docker Images

Question 1

Why is it important to understand the anatomy of Docker images?

Answer 1

Understanding how Docker images are constructed is key to managing their size.

Question 2

Where is the configuration data for an image located in the result from the docker inspect command?

Answer 2

Inside the top-level Config object.

{
   ...
   "Config": { ... }
   ...
}

Question 3

Where is the working directory path for an image located in the result from the docker inspect command?

Answer 3

Inside WorkingDir field of the top-level Config object.

{
   ...
   "Config": { 
        ...
        "WorkingDir": ".",
        ... 
    },
   ...
}

Question 4

How can we inspect a Docker image?

Answer 4

By running the docker inspect command with the image’s tag or id.

docker inspect mini:1.0

Question 5

Where is the filesystem definition for derived containers located in the result from the docker inspect command?

Answer 5

Inside the top-level RootFS object.

{
   ...
   "RootFS": { ... }
   ...
}

Question 6

Where is the content layers information for the image located in the result from the docker inspect command?

Answer 6

Inside the Layers field of the top-level RootFS object.

{
   ...
   "RootFS": {
        ...
        "Layers": [ ... ],
        ... 
   }
   ...
}

Question 7

What are the three types of Dockerfiel instructions?

Answer 7

1. Instructions — Dockerfile instructions define the content and nature of images.
2. Metadata — instructions that define how derived containers will get executed.
3. Content — instructions that create files and directories for the image.

Question 8

What are the three content-creating Dockerfile instructions?

Answer 8

1. COPY — used to copy the build context into an image.
2. ADD — similar to COPY instruction, but can retrieve remote content.
3. RUN — executes commands to generate additional image content.

Question 9

What are the three content-creating Dockerfile instructions?

Answer 9

1. COPY — used to copy the build context into an image.
2. ADD — similar to COPY instruction, but can retrieve remote content.
3. RUN — executes commands to generate additional image content.

Question 10

What are the three content-creating Dockerfile instructions?

Answer 10

1. COPY — used to copy the build context into an image.
2. ADD — similar to COPY instruction, but can retrieve remote content.
3. RUN — executes commands to generate additional image content.

Question 11

What are the three Dockerfiel instructions that add a new content layer to the image?

Answer 11

COPY, ADD, and RUN.

Question 12

Which is the recommended method of copying content from the build context into the image context, COPY or ADD?

Answer 12

COPY wherever we can.

Question 13

What does Docker do with the layers created by content-creating Dockerfile instructions?

Answer 13

When a container is created, Docker assembles the content of each of the image layers to present a homogenous set of files and directories. This forms the basis of the container filesystem.

Question 14

What can be said about the mutability of a Docker image?

Answer 14

The content of the images is read-only and in this way, Docker achieves immutability for images.

Question 15

What can be said about the duplication/sharing of a Docker image’s content when creating other images or building containers from it?

Answer 15

We can build images from other images and build containers that all share the same content without having to duplicate everything due to the immutable nature of containers and images.

Question 16

How can containers write to their filesystem?

Answer 16

To allow this to happen, Docker adds a final layer on top of the layers from the image that the container is built from. This is a unique, temporary writeable layer for every container instance — it’s not a part of the image and is removed when the container is removed.

Question 17

What does copy-on-write mean?

Answer 17

If the container needs to alter the content of a file that is built in one of the read-only layers, it first copies the content to the writeable layer where it can be amended without affecting the content in the image.

Question 18

Where does the container create new files/directories?

Answer 18

In a final, temporary, writeable layer that is separate from all the other layers, which are immutable.

Question 19

What happens when a container attempts to edit some content that is inside one of its immutable layers?

Answer 19

The content is copied into the writeable layer where it can be amended without affecting the content in the image.

Question 20

What happens when a container attempts to delete content that is inside one of its immutable layers?

Answer 20

The content remains in the image layer but is obscured in the union of the layers using a technique called whiteout.

Question 21

Is it a good idea to use CMD instruction to add a package that we temporarily need for another command, and then remove it by using CMD once we’re done using it? Why?

Answer 21

No, it’s not. When we delete something from an image using CMD, it’s obscured at the layer that we issue its deletion. However, it still exists at the layer that it was created in. This means that the image size will stay the same, or it might even get bigger!

Question 22

What is a trick we can use to install a package and delete it after its use in the Dockerfile without increasing the image size?

Answer 22

Instead of using multiple CMD instructions for each operation, use a single CMD and chain commands using the Shell logical “and” operator (&&) to execute each command in sequence.

Question 23

What can we take advantage of Docker’s build cache?

Answer 23

Careful placement of Dockerfile instructions can maximize cache hits and significantly reduce the time it takes to build images.

Question 24

How does the Docker build cache work?

Answer 24

1. Each Dockerfile instruction processed during a build results in the creation of an intermediary image that is part of the build cache.
2. These images are created by commiting containers created from the image associated with the preceding Dockerfile instruction.
3. Images reference their parent image and thereby create an implicit chain of images that represent a sequence of instructions.
4. During an image build, if Docker recognises the sequence of steps that already exists in cache, it desists from executing the Dockerfile instructions that correspond to the sequence. Instead, it reuses the metadata and layer content from the cache intermediary images.

Question 25

How does the Docker build cache work?

Answer 25

1. Each Dockerfile instruction processed during a build results in the creation of an intermediary image that is part of the build cache.
2. These images are created by commiting containers created from the image associated with the preceding Dockerfile instruction.
3. Images reference their parent image and thereby create an implicit chain of images that represent a sequence of instructions.
4. During an image build, if Docker recognises the sequence of steps that already exists in cache, it desists from executing the Dockerfile instructions that correspond to the sequence. Instead, it reuses the metadata and layer content from the cache intermediary images.

Question 26

How does the Docker build cache work?

Answer 26

1. Each Dockerfile instruction processed during a build results in the creation of an intermediary image that is part of the build cache.
2. These images are created by commiting containers created from the image associated with the preceding Dockerfile instruction.
3. Images reference their parent image and thereby create an implicit chain of images that represent a sequence of instructions.
4. During an image build, if Docker recognises the sequence of steps that already exists in cache, it desists from executing the Dockerfile instructions that correspond to the sequence. Instead, it reuses the metadata and layer content from the cache intermediary images.

Question 27

What causes cache invalidation when building Docker images?

Answer 27

1. Instruction change — adding, removing, or altering an instruction invalidates the cache.
2. Checksum check — content change in the build context will invalidate the cache.

Question 28

What seemingly significant change is not checked by Docker when determining the validation of cache?

Answer 28

Command output — consequences of command execution are not checked.

Question 29

What seemingly significant change is not checked by Docker when determining the validation of cache?

Answer 29

Command output — consequences of command execution are not checked.

Question 30

What causes cache invalidation when building Docker images?

Answer 30

1. Instruction change — adding, removing, or altering an instruction invalidates the cache.
2. Checksum check — content change in the build context will invalidate the cache.

Question 31

What is the optimisation issue caused by copying across all files from the build context into the container with a single CMD instruction?

Answer 31

Since we’re copying across dependency files (eg. package.json, yarn.lock) alongside the source code, a change to the source code will invalidate the cache right at that instruction and cause dependencies to be installed all over again.

Question 32

How can we get around the optimisation issue of installing dependencies every time there’s a change to the source code of our project?

Answer 32

By separating the copying across of source code from that of dependency files (eg. package.json, yarn.lock) and placing it afterward. This means that the cache will be valid at the COPY instruction for the dependency files when a change occurs in the source code.

COPY package.json yarn.lock ./
RUN yarn install
COPY spec source ./  # invalidated here, cache is valid for previous steps.

Question 33

What are the three guidelines to follow for taking better advantage of the build cache when writing Dockerfile instructions?

Answer 33

1. Analyze the dependencies between Dockerfile instructions to determine ordering constraints.
2. Order Dockerfile instructions according to the frequency of change; less frequent first, more frequent last.
3. Where it is beneficial, split COPY Dockerfile instructions that copy content from the build context.

Question 34

What is the relationship between multistage Dockerfiles and size optimisation for images?

Answer 34

Multi-stage Dockerfiles can the key to managing the size of Docker images.

Question 35

What is the drawback of using a single instruction to run multiple commands?

Answer 35

If we were to make a change to one of the multiple commands, all the other instructions in that layer will get executed all over again.

Question 36

What is an alternative to using a single instruction to run multiple commands for optimizing Docker image size?

Answer 36

To use a separate stage with every command getting its own RUN instruction, rather than there being a single RUN.

Question 37

What does it practically mean to use multi-stage Dockerfiles?

Answer 37

1. Return to a RUN instruction for each command.
2. Maximize the use of the build cache.
3. Temporary content resides in a previous stage.