#wrapITup is a series on CloudwithCaleb where we explore what containers are, why they are all the rage in IT, and how the cloud is the perfect place for them to live.

Last week we took our first look at the containerization craze. We saw that containers provide isolated environments and that they are significantly easier to manage during their lifecycle. What we did not talk about was what actually goes on inside a container. That is exactly what this blog is all about.

The Image inside

I was going to make some existential analogy by linking the container with the body and the soul. But that might be a bit far-fetched. So sticking to the actual container analogy as intended, think of a shipping container; the big, metal box that brings over the cheap gadgets and household items you bought on Aliexpress but don’t need. The container is only the delivery mechanism to get what is really valuable, that which is inside, to you. 

Shipping containers contain pellets or boxes, while software containers house application images. Without an image it’s just a box that does nothing – that won’t work, because containers are always created based on container images.

Quick IMPORTANT side note: Containers and container images can become quite complicated, so the Linux foundation along with some other companies created the Open Container Initiative (OCI). This is basically a set of standards for Containers and Container Images that everyone tends to follow. 

Breaking down the image

You can think of an image as the finished version of an application along with the environment it needs to get it up and running. The image is a single package, that when placed in a container comes to life as the application you need.

So then the logical question is, how and where do you get these magical packages?

Well, you build them!

This is a good point to introduce Docker. A project started in France eventually turned into a company, Docker, that creates software we use to create and manage containers – the software is called, you guessed it, Docker!

Using the terminology that this software uses, containers are referred to as ‘Docker Containers’. The images, that you run inside the containers, are called ‘Docker Images’. And the code you have to write to build these images is called a ‘Docker File’.

You can write a Docker file to create nearly any application image that you need. The file has coded instructions for a specific application along with all the dependencies and commands needed for it to get working. When we have written a complete Docker file, we kindly ask Docker to execute (build) the instructions we coded. Docker goes ahead, builds all the layers, and spits out a Docker image. 

Bringing it all together

That was quite a lot of information at once. So let’s summarize all that we have so far.

We start by writing/coding a Docker file, which spells out all the layers we need to successfully create our Docker image. The Docker image is the finished blueprint of the application we need to run, along with the environment containing everything that it needs to do so in a single package. Once we have a Docker image, we can ask Docker to place it in a Docker container where the application actually runs!

Without seeing what a Docker file looks like, it might be a bit difficult to piece all this together. So from here, we are going to be taking a closer look at a Docker file. See you in #wrapITup 3.