Get started Bring yourself up to speed with our introductory content.

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.

Three-tier app architecture
A three-tier application consists of the user-facing web server, the application server and the back-end database server.

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.

Dig Deeper on Managing Virtual Containers

Join the conversation

5 comments

Send me notifications when other members comment.

Please create a username to comment.

Where is your organization on its container adoption journey?
Cancel
I understand the concept of tiered environments but can Containers communicate to applications running outside their environment. 
For instance, Having Python as a container, running SQL queries on an external MSSQL data base, and publishing the results on an Apache webserver container, 
Cancel
Here's a brief response from our senior technical writer, although with the caveat that this is a general reply and with a more specific question you should ask an architect who deploys container-based applications: Containers can pass data through APIs etc, so the code running in a container should be able to communicate with other applications if it's designed and intended to do so. That is, there is nothing indigenous about containers that should prevent it (that I know of).
Cancel
This really doesn't provide much detail on the operational differences between docker and LXC containers.  I don't find the article very useful.
Cancel
@schemaczar try this one out: https://searchitoperations.techtarget.com/tip/When-to-use-Docker-alternatives-rkt-and-LXD 
Cancel

-ADS BY GOOGLE

SearchDataCenter

SearchAWS

SearchServerVirtualization

SearchCloudApplications

TheServerSide.com

SearchCloudComputing

Close