> A “container” is just a term people use to describe a combination of Linux namespaces and cgroups. Linux namespaces and cgroups ARE first class objects. NOT containers.
Wow.
I have always wondered in which cases one would use "containers". I have asked so many Docker enthusiasts, "Why would I use containers instead of the strong process separation functionality that's built into the operating system, like users, cgroups, SELinux, etc?"
The answer has freakishly invariably been "Containers are lighter than virtual machines. Virtual machines use up all your resources. Containers can run just a single application, where virtual machines must emulate a whole operating system."
Now you're probably going, "How is that an answer to the question?"
And I know! It's not. These Docker enthusiasts have been impossible to get an answer out of. They have appeared like they're just parroting whatever they've heard from someone else as long as it seemed vaguely related to the question.
Now that I finally have an answer to my original question, it all makes sense again. And I'm inclined to agree that if you're stuck in the wrong bubble, we're both stuck in the same bubble.
I started using Linux containers long time ago and I have used it to achieve compatibility and ease of use.
Before LXC was introduced it was somewhat painful to manage multiple environments using chroot, managing network, etc.
But running the same software in a single environment wasn't always easy. You had to take care of different software versions. And it wasn't uncommon for things to break frequently because of that.
While things like python venv, ruby rvm, etc. helped dealing with it, there was no universal tool for whole filesystem environments besides virtualization.
When LXC came out, I started using it for everything. Nowadays I use LXD and sometimes Docker and it is so nice and requires minimal effort. I know that without those tools it would be very inconvenient to manage my own servers. I have separate auto-updating containers for everything and if one thing breaks, it doesn't take everything down with it. And when everything is contained and each system has minimal set of packages set up, over the years rarely anything ever breaks.
And let's not forget that these Linux features also enabled the universal packages (flatpaks, snaps, etc.) which make it easier for Desktop users to get up to date software easily.
Of course I know that it is not virtualization. But why do people say "containers are not really containers"? It still contains different environments. No one said it is about containing memory or something else.
I figure Docker wraps stuff up into a nice "thing" that you can use, with documentation, a logo, and mindspace. You can put "Docker" on your CV and there's some hope that a recruiter will know what that means.
Wow.
I have always wondered in which cases one would use "containers". I have asked so many Docker enthusiasts, "Why would I use containers instead of the strong process separation functionality that's built into the operating system, like users, cgroups, SELinux, etc?"
The answer has freakishly invariably been "Containers are lighter than virtual machines. Virtual machines use up all your resources. Containers can run just a single application, where virtual machines must emulate a whole operating system."
Now you're probably going, "How is that an answer to the question?"
And I know! It's not. These Docker enthusiasts have been impossible to get an answer out of. They have appeared like they're just parroting whatever they've heard from someone else as long as it seemed vaguely related to the question.
Now that I finally have an answer to my original question, it all makes sense again. And I'm inclined to agree that if you're stuck in the wrong bubble, we're both stuck in the same bubble.