When we talk about containers, we are indirectly referring to two main concepts—a container image and a running container image.
A container image is the definition of the container, wherein all software stacks are installed as additional layers, as depicted by the following diagram:
A container image is typically made up of multiple layers.
The first layer is given by the base image, which provides the OS core functionalities, with all of the tools needed to get started. Teams often work by building their own layers on these base images. Users can also build on more advanced application images, which not only have an OS, but which also include language runtimes, debugging tools, and libraries, as shown in the following diagram:
Base images are built from the same utilities and libraries that are included in an OS. A good base image provides a secure and stable platform on which to build applications. Red Hat provides base images for Red Hat Enterprise Linux. These images can be used like a normal OS. Users can customize them for their applications as necessary, installing packages and enabling services to start up just like a normal Red Hat Enterprise Linux Server.
Red Hat also provides more advanced application images that already include extra software. Examples include language runtimes, databases, middleware, storage, and independent software vendor (ISV) software. The software included in these images are tested, preconfigured, and certified to work out of the box. These prebuilt images make it easy to deploy multi-tier applications from existing components, without the effort of building your own application images.
The layering structure significantly simplifies patching procedures, since a layer needs to be patched only once, and then any image built using that layer will contain the applied patch.
Container platforms like OpenShift have the ability to track existing containers that use a certain layer, and, if patched, trigger a series of image builds and deployments for existing and running containers, in order to apply the patched layer across all containers and prevent security breaches.
Although it is possible to run every application on a single VM, the operational overhead and resource cost of the multitude of extra VMs required generally invalidates the perceived benefits.
VMs have the advantage of providing hypervisor-level isolation for the application. However, that comes at the cost of running a complete OS for each application, which consumes more memory and CPU utilization. Furthermore, VM compute and memory capacity is predefined, and does not provide any elasticity or consuming more when an application requires more memory or computing power.
Containers provide isolation by taking advantage of kernel technologies, like cgroups, kernel namespaces, and SELinux, which have been battle-tested and used for years at Google and the US Department of Defense, in order to provide application isolation.
Since containers use a shared kernel and container host, they reduce the amount of resources required for the container itself, and are more lightweight when compared to VMs. Therefore, containers provide an unmatched agility that is not feasible with VMs; for example, it only takes a few seconds to start a new container. Furthermore, containers support a more flexible model when it comes to CPU utilization and memory resources, and allow for resource burst modes, so that applications can consume more resources when required, within the defined boundaries.
Linux containers are, in a way, a virtualization technology. VMs are for virtualizing the hardware, while containers are for virtualizing application processes, no matter where they run (bare metal, virtualized, or in the cloud).
Containers provide application portability, due to the standard image format (Open Container Initiative) and the fact that they are only dependent on Linux. This gives teams better control over the infrastructure in which they deploy applications. A container host provides a common ground for running containers on any infrastructure, from your own laptop to bare-metal, virtualization, and private and public clouds.
Nevertheless, portability does not guarantee compatibility. Portability is often believed to mean that you can take a container image and run it on any container host built from any Linux distribution, but that is not technically accurate. Linux container images are collections of files, including libraries and binaries that are specific to the hardware architecture and OS. When the container image is run, the binaries inside of the image run just like they would on a normal Linux OS. There must be compatibility between the container image and the container host. For example, you cannot run 64-bit binaries on a 32-bit host.
These inconsistencies can range from sporadic failure (which is hard to debug) to complete failure, wherein the container will not run at all. Worse, incompatibilities can lead to performance degradation or security issues. The portability of Linux containers is not absolute; using different Linux distributions, or widely differing versions of the same Linux distribution, can lead to serious problems.
In order to guarantee portability and compatibility, it is a best practice to run a consistent version and distribution of Linux in all containers and on all container hosts, across environments and infrastructures. This guarantees compatibility, both horizontally and vertically.
OCI standard containers, when combined with a standard container host like Red Hat Enterprise Linux, provide a portable and compatible application delivery combination that guarantees that your applications run in the exact same way across all environments and infrastructures.
Immutability is also one of the key benefits of OCI—standard container images, without being tied to a specific machine image format, like you have with VM images (such as AMI on AWS). That's why you have even seen Netflix adopting containers to enable the same CD workflows, but in a more portable and efficient manner.
However, the term Linux containers is mainly associated with Docker.