Visual Docker: Images and Containers

Containers = Images + Trickery!

Imagine a company that provides TTTaaS—Tic-Tac-Toe as a Service. The website is the destination for Tic-Tac-Toe players around the globe! When people land on the home page and start a new game of Tic-Tac-Toe, they're starting a new Tic-Tac-Toe container where they can enjoy a game with a friend, like this:

Behind the scenes, the code that starts the container looks something like this:

docker start tic-tac-toe

Containers are platforms that deliver services—in this case, a game. A game, like an application, has rules and an environment where the activity takes place.

But containers are more than they appear to be!

More Than Meets the Eye!

The container in the video above tricked you into thinking you watched two people play an ordinary game of Tic-Tac-Toe.

You actually saw two things.

You saw the container, where the moves were made and persisted, but you also saw the Tic-Tac-Toe image! But how could you see both things at once?

The container is really just a thin, transparent layer superimposed on top of the image. When it's peeled away, it reveals the image beneath:

The image is the Tic-Tac-Toe board we see, plus some embedded metadata and instructions—the rules for playing the game.

We run an image to create a container. The single required argument of the docker run command is the image name:

docker run tic-tac-toe

Running Images

What happens behind the scenes when running a container?

Step 1: Prepare the Game

First, Docker creates a new, empty layer for the container and arranges it over the image in a picture frame. In Docker, that picture frame is called a union filesystem (known also as a merge or overlay filesystem). The picture frame keeps everything neatly aligned.

Union filesystems, like picture frames, have three layers, called lower, upper, and merge.

• The image is the lower layer—the game board and rules.
• The container is the upper layer—a thin, transparent sheet of glass or plastic that's initially empty.
• Your perception is the merge layer, a combination of the image and anything extra drawn onto the protective container layer.

Step 2: Start the Game

Next, Docker starts the game and the players begin taking turns.

Container Properties

Container design is unique and allows them to do weird and wonderful things!

Every Game Uses the Same Image

Multiple games of Tic-Tac-Toe that all share one image—not a copy—the exact same image!

Activity in individual containers never reaches the parent image, so it safely delivers the lower layer for every container, where the pre-made board and rules embedded mean every game is guaranteed to start and work identically!

Containers Persist State

Stopping and restarting the game doesn't change the container layer, where moves—the game's state—are saved (persisted).

Images Don't Change

The thin container layer protects the image from changes. Getting "inside" the container really just means that you've reached the clear plastic sheet. The image below is protected and never changes. All of the gameplay happens in the container layer—never in the image. Since images are unreachable and can't change, we say that they're stateless and immutable.

Containers Start Quickly

Whether it's a small and simple game, like Tic-Tac-Toe, or a big and complicated game like Chess, the time needed to start the game is the same—as long as it takes to build the picture frame that superimposes the thin, transparent container layer over the image.

Containers Achieve Greater Density

A server's container capacity is far higher than its comparable VM capacity.

Let's say the rule book for Tic-Tac-Toe is 99 pages, and every game uses one additional page. Each VM requires 100 pages per game, meaning a host with space for 1,000 pages can support ten Tic-Tac-Toe VMs:

10 * (99 + 1) = 1,000

By separating the rules and instruction book into a common image and saving moves in individual containers, the same machine supports 901 Tic-Tac-Toe containers:

99 + (901 * 1) = 1,000

Summary

What did we learn?

• Images provide the playing surface and rules for games.
• Containers deliver games as services.
• Each container is a thin layer superimposed over the image.
• The layers are assembled in a union filesystem that works like a picture frame.
• Plays accumulate and persist in dedicated container layers.
• Every game shares the same board and rules and therefore behaves identically.
• A server hosting one image and many thin container layers supports more games, uses fewer resources, and reduces costs.

In the next installment, I'll explain immutability and why images can't change!