5 complete operating systems that work perfectly in a docker container, including macOS and Steam Headless

[Redaktion]

The idea of running an entire operating system (especially one as bloated as Windows) in a container defeats the entire purpose of Docker. However, you can, and there are at least some valid reasons why you might want to. Whether it's a headless gaming machine, a throwaway OS for testing potential malware or even security research, you can run pretty much every major OS in a container.

https://www.notebookcheck.net/5-complete-operating-systems-that-work-perfectly-in-a-docker-container-including-macOS-and-Steam-Headless.879397.0.html

[Erm]

Unless you're some kind of DevOp or sysadmin, why should the average person care and attempt to learn how to use docker? What are the specific advantages and disadvantages compared to say running in another kind of container or VM?

I know full fledged veteran open source developers that don't go near docker, so why should the average joe need to? Seems like a very niche market use case, like if you work for a company in enterprise and their policy is literally have to use it.

[Bish]

What are the specific advantages and disadvantages compared to say running in another kind of container or VM?

I wouldn't consider myself an expert, and don't work in DevOps, but do have plenty of experience using both docker containers and traditional VMs, and would point to two main advantages for docker:

1. Lower performance costs: there are exceptions to every rule, especially this one, but your average docker container spun up with a lightweight Linux and tasked with running one app only is in most cases going to require less resources than a full-fledged OS running in a VM.

2. Transferability: of course you can migrate VMs, I frequently do, both at work and at home, but with a docker container, preferably one built with a Dockerfile I wrote (or at least read and understood) myself on top of a stable well-known image, I can be 100% sure that if it runs on box A and box B can run docker, it will also run exactly the same on box B (allowing for slower/faster) - I effectively don't need to know anything else about box B and I don't have to worry about any other config issues (as long as I'm not relying on some specific local paths). With VMs, there's usually a lot more to double check to be sure that your disk image will boot somewhere else.

Of course all advantages are disadvantages in the right/wrong context: sometimes you want or need all the features of a full OS, and sometimes keeping everything containerised is too limiting and prevents you from being able to get the work done.

As this article shows, it's entirely possible to find solutions to the limitations of docker (and other container platforms) and even run full GUI OSes as containers - I'm not sure it's the best solution, and personally I'll probably carry on using containers for single function/app/group services, and VMs for terminal servers and bigger projects, but it's pretty cool that it's even possible to spin up an instance of a full GUI OS like Windows or macOS with a single short terminal command.