Container Virtualization

Note

Parts of this guide are taken (and modified) from the SURESOFT Workshop about Continuous Integration.

A container is a running instance of an image. The container image becomes a container at runtime and encapsulates the required environment together with all dependencies. As a result with containers, it is now possible to isolate and transport software making them portable.

An image is built based on a recipe with instructions of the used run-time environment and dependencies. Or in other words, they are equivalent to a script of how you would install the software manually using the command-line interface.

Fig. 2 The concept of container virtualization, here using docker: Illustration of Dockerfile, Docker image and Docker container. Singularity follows the same concept, only that the Dockerfile is named definition file.

Container vs Virtual Machines

A container encapsulates application code and dependencies in the form of layers which makes it easier when compared to a VM. Unlike a virtual machine (VM) which is an abstraction of the physical hardware with a full copy of an OS, the containers share the machine’s OS system kernel and therefore do not require an OS per application. This makes VM heavier and slower when compared to a container. Moreover, it is possible to run hundreds of containers (whereas it is possible to run only a few VMs - for instance around 4 depending on the system specifications).