Oleksiy Mark - Fotolia
Explore Docker vs. LXC through the lens of a three-tier app
Containers are not small virtual machines, and they're not all the same under the hood. To make smart deployment choices, understand the nuanced differences between container types.
While Docker is synonymous with containers, that doesn't mean it's the only kind available.
Docker containers are just one implementation of the kernel-sharing application isolation technology with a specific purpose. There are more general-use types of Linux containers (LXC) that solve other problems.
To compare application and system containers, look at Docker vs. LXC, archetypal examples of each container virtualization type and how they handle a typical three-tier web application.
Build a three-tier application
Developers compose a three-tier web application to include web, application and database servers. The front end, which is the UI, is the web server. It accesses the application server, the second tier, where the app executes its business logic. Neither the web nor the application server holds the critical data, which is stored in the database server, the third tier. Every container technology can accommodate multiple software options on each tier.
Kubernetes and Docker containerize applications
Docker facilitates consistent application delivery. A single Linux or Windows server runs multiple isolated applications. Each Docker container runs a single application executable from a Docker image, which makes Docker an application container platform.
Kubernetes is a well-known management and orchestration platform for containerized applications that enables administrators to not have to look after individual containers. Together, Docker and Kubernetes deliver typically large-scale applications to users.
The three-tier application needs a minimum of three Docker containers -- one for each tier. This architecture enables admins to scale each component of the overall application separately. If the web servers are overloaded, Kubernetes can start more containers for only that tier.
Docker containers can be miniscule, without any OS components that are not specifically required by the code they contain, so organizations can buy and manage less storage than they would for a comparable deployment on physical or virtualized host servers.
The downside is the number of containers. A complex application tier might need dozens of different containers and dozens of copies of each one running, which is why Docker and the at-scale management tool Kubernetes are paired for this example.
Kubernetes basics
In the time since this article originally published in 2017, Kubernetes has become the de-facto choice for container orchestration in the enterprise. Because of this changing dynamic of container management, the editors added this information about the primary components of a Kubernetes cluster:
- Pods -- The basic computing unit for Kubernetes. Pods group together one or more containers that share the same resources.
- Nodes -- A collection of IT resources that supports one or more containers and provides the necessary services to run pods. Each cluster has at least one master node, which manages at least one worker node.
- Kubelet -- The agent that supports communication between master and worker nodes, and manages the pods.
Add the OS for Docker vs. LXC
LXC is a system container tool. This type of container makes a single Linux system act as many. LXC delivers containers that include a complete Linux system, much like a VM, with its own file system, networking and multiple applications. All three tiers of the web application can share one LXC container, although that's not the intended use. More typically, a user puts the web and application servers into a single LXC container and spins up multiple copies to provide scalability and redundancy. The database then runs in another LXC container and scales independently from the other tiers in the shared container.
Web hosting companies use LXC to provide each customer with independent Linux servers without physical servers dedicated to each one. LXC takes the place of VMs as a lighter resource-consuming option for workload isolation.
Docker initially relied on LXC as its container interface, but because LXC provides each container with a full Linux system in an isolated namespace, Docker developed the containerd runtime as a replacement. When comparing Docker vs. LXC, consider the main difference that containerd is only used for single application containers, while LXC is able to run multiple applications inside system containers.
What is LXD?
LXD is an interface to manage LXC system containers, not a platform or type of container. LXD features include snapshots and image control. It increases the capabilities of LXC technology. For example, with LXD's OpenStack interface, LXC containers act as OpenStack compute resources, without requiring a hypervisor and VMs.
Docker and LXC vs. virtual machines
System and application containers use the OS kernel of their parent server, so both container types are faster to start and require fewer resources than a VM for a comparable workload.
To get a complete OS and still isolate applications requires a VM. Multiple VMs running on a single server can each run a different OS, because the full OS kernel is required for every VM. This hardware-level isolation, rather than OS-level, gives VMs more flexibility than containers but increases resource consumption and means administrators have significantly more OSes to update and patch. The three tiers of the example web application would each require a full OS.
Many organizations run containers inside VMs for the increased isolation and additional abstraction layer. IT teams are familiar with the management tools and security processes for VMs, which makes a combination of containers and VMs suitable for new container adopters to reap some application portability benefits without sacrificing production readiness.
