Comprehending Docker Containers
Container technology has become a standard in the DevOps field. However, if you have never worked with it you probably have some questions like:
How is the actual execution of a container?
When a container start and when does it stop?
The purpose of this article is to make clear essential concepts around this increasingly demanded skill.
Containers and Virtual Machines are tech tools that provide isolated self contained environments for developers to create, experiment, debug, test and deploy applications. The common ground for this family of technologies is the idea of creating spaces where an app can be developed and run, within a controlled environment, without worrying about how the app ecosystem might affect or influence any other environment.
Virtual Machines are emulations of a full hardware stack running a standalone Operating System hosting an app or a set of apps. By running multiple Virtual Machines, each will emulate an isolated hardware stack with its own Guest Operating System.
Virtual Machines work on top of a platform called “Hypervisor” which creates and executes all of them coordinating operations. There are Native Hypervisors that do not require a Host Operating System and Hosted Hypervisors that does. VirtualBox is a very common and widely used example of a Hosted Hypervisor.
What makes containers so different?
Docker defines a container as a “standard unit of software that packages up code and all its dependencies…”
To put it in much simpler words and quoting Ben Corrie “A container is a sandbox for a process”.
From all these definitions, I like to think that a container is a frame for a process or that it is a framed process.
While Virtual Machines are hardware abstractions, Containers work at the application layer being applications abstractions that do share common resources from a Host Operating System and that is the big difference from Virtual Machines: a Container does not need to emulate a complete hardware stack with a Guest Operating System to run an app because a container only need to run processes. It can actually run the app itself and nothing else.
Docker Containers from the execution perspective
Going further in definitions we can also find that “a container is a runnable instance of an image.” So, what is an image?
An Image is a “file system and configuration of our application which are used to create containers…”, “a read-only template with instructions for creating a Docker container.” In a very simple way, an image is a software platform used to make containers. You can find images online and pull them from Docker Hub for example, you can create images by committing existing ones and you can create images from scratch. However, lets not be confused, the image is not the actual container. Images are containers factories.
Ben Corrie again makes a clarifying analogy related to Object Oriented Programming when it comes to explain the relation between images and containers. While in OOP there are classes and objects where objects are instances of classes, similarly, containers are instances of images.
Every time you ask docker to run an instance of an image, a container is created and it ends once the instance has stopped running, once the process has ended.
The image is the source to make a process run, the container is the actual process running. There could be containers running a single task process in a short period of time. There could also be containers running interactively or running processes in the background.
Dockers containers in action
Lets see an actual execution of Docker containers running simple single tasks for the purpose of illustrating the concepts explained so far. We will need Docker Engine so that we can work with the CLI client.
Lets get an image first.
We will work with Alpine , a lightweight image based on Alpine Linux.
(On Linux, you will have to preface the docker command with sudo)
After getting the image, we can see a list of all images. In this case we will have only the Alpine one.
Lets now run a Docker container. Since Alpine is a Linux distribution, we can run bash commands like echo. Running this command will be the container process.
In summary, a container ran, executed the echo command returning the given string and ended immediately.
Lets do the same a couple times more and then see the list of containers. It is important to add the -a flag to see all containers, the ones running and the ones that ended.
Each time we executed the echo command (the process), a container was created executing a single task. Each container only lasted as long as it took to execute the bash command. By default, each execution was a separated, isolated container. Container isolation is a very important security concept from Docker and each container has a unique ID.
There are many more ways to work with containers that would be material for additional blog entries. In addition, understanding images in greater depth and working with dockerfiles is essential to creating custom images and dockerize apps, which is one of the most important and common uses of containers.
#TheBlogChallenge: This was a blog entry inspired by lesson 17 “Messaging & Containers” from Udacity’s Bertelsmann Technology Scholarship Challenge Course-Cloud Track.
#50000chances #UdacityTechScholars #PoweredByBertelsmann
