What is a Docker Image? (And how do you use one with IronWorker?)

To start, we need to have an understanding of the Docker nomenclature and environment. There is still not a clear consensus on terms in regards to containers. What Docker calls one thing, Google calls another, and so on. We will only focus on Docker here. (for more on Docker vs Kubernetes, read here).

Docker has three main components that we should know about in relation to IronWorker:

1. Docker file
2. Docker image
3. Docker container

1) Docker File

Let’s keep it simple. Docker files are configuration files that “tell” Docker images what to install, update, etc. Basically the Docker file says what to build that will be the Docker image. These files have everything to eventually build a container. The types of files include dependencies, application code, installations, and everything else that is needed to execute effectively. 

2) Docker Image

A Docker image is the set of processes outlined in the Docker file. It is helpful to think of these as templates created by the Docker files. These are arranged in layers automatically. Each layer is dependent on the layer below it. Each layer then becomes more abstracted than the layer below.

By abstracting the actual “instructions” (remember the Docker files?), an environment that can function with its resources isolated is created. While virtual machines relied on calling OS level resources, containers have eliminated this. In turn, this creates a lightweight and highly scalable system. IronWorker takes these images and begins the process of creating and orchestrating complete containers. 

You can create a docker image by using an existing image and updating its file components for the present container. You can also create the docker image from scratch through the use of a Dockerfile you construct. 

What exactly is the difference between a Docker image and a Docker container? Let’s see.

3) Docker Containers

Finally we come to the containers. To simplify, we can say that when a Docker image is instantiated it becomes a container. By creating an instance that draws on system resources like memory, the container begins to carry out whatever processes are together within the container. 

In other words, a Docker image runs the code in the Docker container. Everything that’s needed to perform a complete task is in the image, but it becomes functional once it is executed within a container. The image may be used once or multiple times. 

While separate image layers may have different purposes, Docker containers are formed to carry out single, specific tasks. That is one reason why typically a Docker image has several layers of files that perform different jobs. They work together to achieve the primary objective of the Docker container. 

To make this distinction even more clear, we can use an example from nature. Think of a bee vs. a beehive. In the community of the hive, individual workers-- bees -- carry out asynchronous tasks to achieve a single goal. In short, containers are packages which hold all of the required dependencies to run an application.

After the container has been run, the Docker image is inert and inactive. This is because Docker image has carried out its purpose and now serves only as a meta reference.