Visual Docker: Images and Containers
Tags: docker, containers, cloudnative
Published: 2023-04-06 11:49:24

## 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:

{% embed https://youtu.be/SBHPgsxr8M8 %}

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:

{% embed https://youtu.be/I-n2ZXMKGJw %}

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!