Overview
Let’s take a break from “How to” and let’s take a look at “Why” and “When”…
So far in the series, we’ve:
- Built a server
- Set it up for virtualization
- Built a VM
- Turned it into a samba server
- Built another VM
- Turned it into a Plex server
We could keep creating VMs and installing one service per device on them and this is a relatively good practice, as it isolates each service completely from the other. This provides a separation of concerns, increases security and stability and allows for finer grained control of resources per service.
However, there is a trade-off. All of these wonderful benefits come with a dark side… nothing in life- virtual or otherwise- is free. Requiring each service to have their own VM is very resource intensive, which means you’ll be able to have fewer services up and running at the same time. If for a given service, the CPU and RAM usage is low most of the time but you need to keep extra headroom for when the service gets occasional heavy use, those mostly unused resources are still devoted to that service and will not be sent to help another service that might need it.
It is also a more time-intensive process to create a VM. While virt-manager makes the setup process relatively simple, it is still a multi-step process that culminates in installing an entire OS… which takes time.
So what’s the alternative? Containers! Or more specifically for our series… Docker!
Let’s take a look at Docker and compare it to our VM environments. We will also talk about when and why to use each environment type.
So What is Docker?
Docker is a containerizaton tool. Containerization is the packaging of an application so that it can run on its own. While this sounds an awful lot like installing a single service on a virtual mahcine it does have a few differences.
Instead of virtualizing an entire computer, hardware and all, like a virtual machine, a container only virtualizes a barebones operating system to run one single application. This simplified OS sits on top of the host’s actual operating system and borrows only the CPU and RAM resources it needs from the host’s pool of resources at any given time. No manually assigning and restricting resources for a single purpose! Any computing power not used sits in the host’s resource pool just waiting for anyone to use it!
This type of free access to the host’s resources means that many more services can take advantage of the same larger resource pool at the same time! So one host can have many more services running on it and intelligently sharing resources between themselves as they are required.
Comparison
So if we were to visualize the difference of a virtual machine versus a docker host, a virtual machine would be like a household garage to hold a single automobile, while a docker host would be like a community parking garage.
Sounds great, right? Well, hold on… remember we said that nothing comes without a price, right? So what about the seedy underbelly of containers? What’s the trade-off? How do the Compare to the downsides of VMs? Is there a clear winner? Let’s take a look…
Docker Pros and Cons
Docker has a lot of upside!
Pros
- As we mentioned, all resources of the host are available and transient between containers.
- They are a smaller footprint as they do not need an entire virtualized hardware and OS to function, only a bare-bones kernel and OS (just enough libraries to get the application to run).
- Containers are much quicker to create and start using, Especially when using orchestration and management software like Kubernetes and Rancher (respectively).
Cons
- Just like a community parking garage versus a home garage, there is less security.
- Containers do not completely isolate themselves from the host and share the base of the host’s OS.
- Because of the close proximity of multiple services (cars) that are sharing space (parking garage), these security risks extend to each service (car). If just one service is compromised, the rest on the host could be as well.
Virtual Machine Pros and Cons
We have covered many virtues of virtual machines in this series, but in the interests of fairness and consolidation, let’s review;
Pros
- VMs are fully isolated and are separate entities from the host machine for all intents and purposes.
- Allows for a high level of security.
- Can experiment with or use multiple operating systems
Cons
- VMs are resource hungry compared to containers.
- They cannot share resources between active VMs. Assigned resources are held, whether used or not, while a VM is active (on).
- Longer time frame to create and implement before use.
Verdict- Who’s the Winner?
After reading the above, you might come to your own similar conclusion, but the answer (per usual) is “it depends”…
It depends on your use case. For instance, if I worked in an enterprise environment had an application that dealt with private patient medical data for a large organization, I probably wouldn’t want to put that into a docker host next to a bunch of other applications that may be less secure, would I? No – for that type of application, I would put it in it’s own VM with a securely configured OS, restrict user access, and perform other security measures to keep that info safe.
However, what if I’m experimenting at home with some new-to-me application or service to see if it’s something I’d be interested in using long term? What if the service itself has no important data and is so small a VM would be overkill? There’s no quicker way than a container to get a very performant application up and running without having to build an entire (virtual) computer from scratch!
It should also be noted that the cons of both VMs and Containers can be mitigated to a large extent with proper planning and configuration. So who wins?
Why Choose? Best of Both Worlds?
Since this series is about putting the power of virtualization into the hands of mere mortals rather than enterprise professionals, let’s stick to our use case. A home user with big ideas about bending tech to their will.
If this is the case I think we can absolutely make the argument that we can do both!
Some Services and/or operating systems are best left in a VM. A windows gaming rig with passthrough GPU? yeah… not a container thing. An implementation of pfsense to try to run your home network on? Isolating that to it’s own VM is probably for the best. But…
A DNS level ad-blocker (Pi-hole)? A Digital ebook library (calibre-web)? Now these are services that can be put into containers with ease! A whole VM for each of these services seems a waste.
Plex is a tough one. It could be containerized, but if you really care about your movie and tv experience like I do you’ll want to be able to keep resources reserved for that service. So for this series we will leave Plex as it’s own VM.
Adding Docker to our Virtualization Server?
We could install Docker on our host OS, sure. But remember, when we set out to build this server, we wanted to keep a strong separation of concerns between the host OS and the VM-pool. Now we’re introducing Docker Containers… so where to put them?
How about… in their own VM!!!!
That’s right- Let’s really combine the best of both worlds and keep all of our small footprint and experimental services in their own isolated VM. In the next post we will do just that- create a VM and install Docker. We will also dive into using Rancher- a GUI-based organizational software to be able to quickly spool up containers and apps. It’s like virt-manager for containers!
Stay tuned, folks, we’re just getting started!
