DEV Community: Oracle Sean ♠️

Visual Docker: Images are Immutable

Oracle Sean ♠️ — Fri, 07 Apr 2023 11:07:15 +0000

Changing an image alters the rules mid-game

This is the second article in a series dedicated to visually explaining Docker and container concepts using a game of Tic-Tac-Toe and little or no code. It's focused on image immutability and tags, and demonstrates why images can't change.

The last post in this series used a game of Tic-Tac-Toe to show how containers are thin layers projected onto images. The image is the Tic-Tac-Toe board and includes the game's rules. It's shared by every Tic-Tac-Toe game container. Individual containers are layers that start out empty. As players add moves, they're recorded in the container layer.

The game only makes sense when you see both pieces together. On its own, the container layer is just random X's and O's. The game board in the image is perpetually empty because it can't change. In the container world, we say that images are immutable and, therefore, also stateless since altering the state requires saving those changes somewhere.

Change ≠ Replace

Is that really true, though? After all, I can change a Dockerfile and rebuild the image using the same name, which would seem to change the image. More accurately, I replaced the old image and assigned the same name.

It's an important distinction. To illustrate why, let's list the images on the system:

> docker images
REPOSITORY   TAG           IMAGE ID       CREATED      SIZE
games        tic-tac-toe   ec616ed52b3b   1 hour ago   100KB

Then, start a new game container using that image. The "friendly" image name is its REPOSITORY and TAG, joined by a colon:

docker run games:tic-tac-toe

When I list the containers running on my system, I see my game:

> docker ps -a
CONTAINER ID  IMAGE        COMMAND           CREATED       STATUS                 PORTS   NAMES
f8763546a856  ec616ed52b3b "/bin/tictactoe"  1 minute ago  Up 1 minute (healthy)          abundant_fun

Inside the container, players make a series of moves ending in a stalemate:

Recall that the moves are saved in the container layer, but the game board and all of the rules are part of the image. What if I could change the existing image used by a running container? Perhaps rewriting the Dockerfile and shifting the board to the right:

If the container used the changed image, moves in the leftmost column of the container layer would fall off the board, while three new spaces open up on the right! The game is no longer a stalemate! Now, Player O has two paths to victory courtesy of the repositioned game board in the new image, and Player X can block only one!

That demonstrates what would happen if you could change an existing image. But it does raise a question: what happens when you replace an image?

The Repo

Recall the original image was named games:tic-tac-toe. If there were no containers using the image, Docker simply removes and replaces the image. But in the example above, a container was using the "old" image. So, does Docker respond by removing the container? Does it crash or stop responding when its image is replaced? Fortunately not!

In this case, Docker preserves the original image by un-tagging it—removing the friendly name—making the games:tic-tac-toe tag available to the newly built image. Once untagged, the image no longer has a friendly name, which I'll see when I once again list the images on the system:

> docker images
REPOSITORY   TAG           IMAGE ID       CREATED       SIZE
games        tic-tac-toe   2fafb511dc00   1 hour ago    100KB
<none>       <none>        ec616ed52b3b   2 hours ago   100KB

One shows <none> for the REPOSITORY and TAG. Look closely, and you'll see the IMAGE ID matches the original image. By rebuilding the image, Docker untagged the old one but didn't delete it! Any containers that used the "old" image continue to work as before, without any change!

If you see <none> listed for an image repository and tag, it just means it was untagged or replaced while still in use by a running container.

Visual Docker: Images and Containers

Oracle Sean ♠️ — Thu, 06 Apr 2023 11:49:24 +0000

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!

Visual Docker: Introduction

Oracle Sean ♠️ — Tue, 04 Apr 2023 20:02:32 +0000

“Containers are like lightweight virtual machines” is a poor analogy

An effective analogy helps expose the parallels between something you already know or understand and the new thing you're learning. The one that springs to mind for me is the comparison between flowing water and electric circuits. I learned it from my high school physics teacher way back in 1982, and to this day, I can't think of a circuit without picturing water moving through different diameter hoses, with sand or constrictions representing resistance and batteries delivering voltage replaced by pumps generating water pressure.

It gives me a mental picture of a real, physical system that mimics the behavior of something abstract and helps me understand and even predict how the circuit works.

Unfortunately, the Docker world doesn't have a good analogy for containers.

When I give talks on Docker and ask people to describe containers, I hear two answers again and again:

Containers are control groups (cgroups) and namespaces
Containers are like lightweight virtual machines

There are problems with both of these. Saying containers are built from cgroups and namespaces isn't helpful unless you already understand cgroups and namespaces, and chances are that if you do, you probably already have a technical awareness of what containers are!

Since most aren't familiar with these terms, I see most people leaning toward the "Containers are like lightweight virtual machines" comparison. But it has problems, too. It's just not a useful analogy because it doesn't advance our understanding of containers. Why not?

If containers are like lightweight virtual machines, then… what is a lightweight virtual machine? For that matter, what's a virtual machine? Can you describe VMs in non-technical terms that a layperson can understand?

Even if you and your audience understand what virtual machines are, what's this special "lightweight" virtual machine? What makes it lightweight? How is it different from a regular virtual machine? Why not just, "They're like virtual machines?"

An analogy bridges the unknown to the familiar, equating something new to another thing you have experience with or can imagine easily. And a good analogy should work to describe a broad set of behaviors.

Everyone understands that kinking a hose reduces water flow and creates pressure behind it, but "containers are like lightweight virtual machines" doesn't describe anything about containers. It doesn't explain statelessness or immutability. There's no parallel that clarifies the differences between images and containers or accounts for fast startup times.

The Tic-Tac-Toe Analogy

I developed the Tic-Tac-Toe analogy as a better way of visually understanding containers. It's entirely non-technical and describes everything from fast startup times and how containers accomplish high density; to abstract concepts like immutability, persistence, ephemeralness, state, and caching; and constructs and properties like tags, builds, Dockerfiles, layers, union filesystems, and more!

I'll cover each of these in separate posts in this series, beginning with the difference and relationship between images and containers.

I wasn't speeding, your honor...

Oracle Sean ♠️ — Tue, 07 Jan 2020 00:27:12 +0000

...I was using maximum hardware capabilities to take advantage of a more optimized execution plan, reducing highway concurrency.

#jokes #database #humor