Understanding Container Technology: From Virtual Machines to Scalable Container Clusters

Let me share a secret: how DevOps cloud tools integrate with applications has always been a mystery to me, but over time I realized that understanding large‑scale machine and application configuration is an essential skill for developers, much like learning to play an instrument for a professional musician.

In software development, integrating your code with the broader world is as important as writing the code itself, and DevOps helps achieve this.

To bridge development and operations, I will introduce a new technology—container technology. Containers represent the next stage of machine virtualization, turning a computer from a static asset into a flexible location.

This article will cover the concepts behind containerization, the differences between containers and virtual machines, how containers fit into application architecture, how a lightweight Linux OS supports containers, and how to use images to create reusable containers. Finally, I will show how to scale applications quickly with container clusters.

I will demonstrate a step‑by‑step containerization of an application instance and how to create a host cluster for containerized applications, using Deis on a local VM or a cloud provider.

Now, let’s get started!

Advantages of Virtual Machines

To understand how containers fit into the overall architecture, you first need to know their predecessor: virtual machines.

A virtual machine (VM) is software that emulates a computer on physical hardware; installing a VM is like buying a custom computer where you can configure CPU, memory, and storage, then load an operating system and any required applications.

Multiple VMs can run on a single physical host. A simple schematic is shown below:

VMs improve hardware investment efficiency; you can buy a large machine and run many VMs on it, including database VMs and custom‑application VMs as a cluster. Resources can be added or removed as needed, and unused VMs can be shut down and deleted.

Limitations of Virtual Machines

However, VMs have inherent limitations.

Consider a host with 12 CPUs, 48 GB RAM, and 3 TB storage, running three VMs each allocated 4 CPUs, 16 GB RAM, and 1 TB storage. While this works within the host’s capacity, each VM receives a fixed, dedicated allocation.

If a VM never uses more than 1 GB of its 16 GB RAM, the remaining 15 GB sits idle. Similarly, unused storage remains wasted. This static allocation leads to under‑utilized resources and higher costs.

Additionally, VMs are slower to provision, making rapid infrastructure scaling cumbersome.

Enter Containers

A container is a Linux process that runs in isolation, obeying user‑specified commands, and is assigned its own IP address. With an IP address, a container becomes a recognizable network resource, and the container manager can map this IP to a host IP, making the container appear as an independent networked device, similar to a VM.

Thus, a container is an isolated Linux program with its own IP address, as illustrated below:

Containers share host resources dynamically: a container that needs 1 GB RAM uses only 1 GB, and one that needs 4 GB uses only 4 GB. CPU and storage are allocated similarly, unlike the static allocation of typical VMs. All resource sharing is managed by the container runtime.

Containers also start much faster.

Overall, containers combine the isolation of VMs with dynamic, efficient resource allocation and rapid startup, offering better scalability.

Container Hosting, Configuration, and Management

Linux hosts capable of running containers have become essential. Popular underlying OSes include CoreOS, Red Hat Atomic Host, and Ubuntu Snappy.

All containers on a Linux host share the same kernel, reducing duplication and simplifying deployment. Each container contains only the functionality it needs. The following diagram illustrates this layering:

You can configure containers using layers. A layer corresponds to a container image; the base layer is typically the operating system you want inside the container. Additional layers add components such as Apache, PHP, or Python as needed.

Layers are flexible: if one application requires PHP 5.2 and another needs PHP 5.6, you simply create separate images with the appropriate PHP version, without the heavy re‑installation steps required for VMs.

Container management software—most commonly Docker and Rocket—controls these layers. The diagram below shows a host using Docker on CoreOS to manage containers.

Creating Containers and Images Simultaneously

When you package an application as a container, an image is created simultaneously. An image serves as a template for containers and is stored in a registry, similar to a Maven repository for Java or a NuGet server for .NET.

You define a container configuration file that lists all required images. The container manager builds the container by pulling images from the registry, copying necessary files, and assembling the layers.

The following diagram shows the container creation process:

Step 1: a container configuration file defines what the container needs. Step 2: the manager pulls the base image (and any dependent images) from the cloud registry. Step 3: files are copied into the container’s filesystem.

If you use a configuration service such as Deis, the newly built container image can be deployed to a cloud provider like AWS or Rackspace.

Container Clusters

In favorable conditions, containers provide greater configuration flexibility and higher resource utilization than VMs, but that’s not the only advantage.

When containers are grouped into a cluster, each retains its own IP address, allowing them to sit behind a load balancer. This setup dramatically improves performance and availability.

Below is an example of a container cluster behind a load balancer:

For resource‑intensive applications such as image processing, you can create a container image that includes the processing software and its dependencies, then deploy multiple instances behind the load balancer. The images can serve as backups and can be scaled up as workload increases.

Service‑discovery tools can automatically configure the load balancer as new container instances appear, ensuring balanced traffic routing without manual intervention.

Conclusion

Container technology has filled the gap left by traditional VMs. Host operating systems like CoreOS, RHEL Atomic, and Ubuntu Snappy, combined with Docker and Rocket, have made containers increasingly popular. Although there is a learning curve, once mastered, tools like Deis make creating and deploying containers much easier.

Understanding the concepts is as important as hands‑on practice; without real‑world experience, the ideas remain abstract. The next step in this series will be to actually build some containers.