Images and containers

// 1.1

Files and settings

Every image has two halves. The files are a whole Linux file tree: commands, libraries and, for the order app, Java and Main.class. The settings say what to run and how. docker image inspect prints everything Docker knows about an image, and --format picks out one field. Pick an image and a tab.

// 1.2

The default command

The most important setting is the command a container runs when you don’t give one. Whatever you write after the image name replaces it. Click each part of the command.

// 1.3

The image never changes

A container can change, add or delete any file it sees, even a system command. Watch one container break itself, then start the next one from the same image.

// 1.4

Images are built on images

Nobody writes a Java image from nothing. order-app:1.0 starts from the official Java image, which starts from Ubuntu, and each level adds files and settings. Click a level to ask the image about it.

// 1.5

Game: file or setting?

Twelve things you meet when you run order-app:1.0. Is each one a file in the image, a setting of the image, something each container gets when it runs, or something that comes from the host?

// 1.6

Checkpoint: what an image is made of

Eight quick questions on Part 1. Pick an answer to see why it is right or wrong.

// 2.1

The image ID

Docker computes an image’s ID from its content with SHA-256, a fingerprint function: the same content always gives the same ID, and any change gives a new one. Click each part of the ID.

// 2.2

A tag is a label

docker tag sticks one more name on an image that already exists. Nothing is copied: the new row in docker images has the same ID.

On the Tag board two images sit side by side: 1.0 and 2.0 of the order app. Move the tags stable and latest, pick a command, and say what it will print before you see the real run.

// 2.3

The latest trap

When you leave the tag out, Docker uses the tag latest. It sounds like “the newest version”, but it is only a name, and it points wherever someone last put it.

// 2.4

Untag or delete

docker rmi removes a tag. Only when the last tag of an image goes does Docker delete the image itself. Watch the tags on the board as each command runs.

// 2.5

Game: which image runs?

Twelve short stories about tags. Image A prints the 1.0 line; image B prints the line with “delivery on Friday”. Which one runs?

// 2.6

Checkpoint: names, tags and IDs

Eight quick questions on Part 2. Pick an answer to see why it is right or wrong.

// 3.1

Each container is its own

These are the three containers from the start of the lesson. Click a column of the table to see what each container has for itself and what all three share.

// 3.2

The writable layer: copy-on-write

A container sees the image’s files, but it never writes into them. Every change goes into a thin writable layer on top that belongs to this container alone. Changing a file first copies it up into that layer: this is called copy-on-write. Try the four actions and watch where each file lives.

Now the same changes in a real container. docker diff lists what a container changed compared with its image.

// 3.3

How big is a container?

The writable layer is usually tiny, because it holds only the changes. A second container writes a 5 MB file, and docker ps -a -s adds a SIZE column for both.

// 3.4

An image in use cannot be removed

The three stopped containers still need order-app:1.0: they start from its files when you start them again (lesson 4). So Docker refuses to delete the image while they exist.

// 3.5

Game: A, C or D?

Twelve containers from alpine, each running one small script. What does docker diff print for the path in the question: A (added), C (changed), D (deleted), or no line at all? Every answer shows our real run.

// 3.6

Checkpoint: containers from one image

Eight quick questions on Part 3. Pick an answer to see why it is right or wrong.

// 4.1

docker commit: a container becomes an image

l3-w from 3.2 still exists, with its new /data/n.txt and without /etc/motd. docker commit saves its writable layer on top of the image’s layers as a new image, l3-notes:1.

// 4.2

A snapshot or a recipe

A commit saves whatever is in the container, but not how it got there. A Dockerfile is a short text file with the steps that build an image. Compare the two ways for the same job.

// 4.3

Image commands and container commands

Most Docker commands come in pairs: one for images, one for containers. Two commands are bridges between them. Click a row to see a real run from this lesson.

// 4.4

Game: image or container command?

Twelve commands. Does each one work on images, work on containers, or is it a bridge from one to the other?

// 4.5

Checkpoint: from a container back to an image

Eight quick questions on Part 4. Pick an answer to see why it is right or wrong.

// 5.1

Key takeaways

1. An image is files plus settings. The files are a whole Linux file tree; the settings include the default command, environment variables, the working directory and the platform. docker image inspect --format reads them.

2. The default command runs when you give none. Anything you write after the image name in docker run replaces it.

3. An image is read-only. Whatever a container changes goes into its own writable layer (copy-on-write); the next container starts from the unchanged image. docker diff lists the changes with A, C and D, and docker ps -a -s shows each container’s own size.

4. Images are built on images: order-app:1.0 adds one file and two settings to eclipse-temurin:25-jre, which adds Java to Ubuntu. Settings such as JAVA_HOME are inherited.

5. The image ID is a SHA-256 fingerprint of the content. A tag is a movable label on an ID; one ID can have many tags.

6. latest is only the tag Docker uses when you leave the tag out. It points wherever someone last put it, not at the newest version.

7. docker rmi removes a tag; the image is deleted with its last tag. An image that any container still uses, even a stopped one, cannot be deleted: remove the containers first.

8. Each container has its own ID, name, status and writable layer, and remembers its image’s ID. Image commands and container commands come in pairs; docker run and docker commit are the bridges, and a Dockerfile beats a commit because it can be repeated and reviewed.

// 5.2

Check yourself

Twenty questions on the whole lesson, in the order of the parts. Outputs in the questions are real runs.

Your checkpoints

// 5.3

Homework

Fifteen tasks in three levels. You have Docker now, so most tasks ask you to run commands on your own machine. Write down what you expect first, then run, then open Check yourself to compare with our run.

IDs, names, times, sizes and the platform are different on your machine; everything else should match. A model answer is one good answer, not the only one. Your ticks are saved in this browser only.

// 5.4