This is a more charitable interpretation of what I meant: "we can quickly test the value of an idea via a prototype without the cost of making it super well behaved in other areas." Which is an excellent application of containers!

I just sometimes wonder if the cart hasn't gotten in front of the horse on the whole container front. The fact that the term "bare iron" has been hijacked to mean "not under virtualization" made me start to think that something is seriously fucked up.

It very much has. Mix it in with devops and agile, and before you know it everyone is throwing hot code directly to "prod"...

If you have machines with unused capacity, why would deploying a docker container image be easier than deploying a RPM package?

Because either there is no RPM or the RPM conflicts with other RPMs on the machine.

There is software collections for RPMs, which is basically namespacing. Can have quite an operational overhead if the thing you want to install has a lot of dependencies though.

Sounds like then you should learn what a chroot is. All the existing linux platforms already provide the solution to your exact problem with much less overhead than docker.

I agree this is possible, but the tools are somewhat obscure and slow. You can debootstrap in a chroot and then install packages, but it takes a long time, and likely re-downloads hundreds of megabytes packages you already have on the system.

I don't like Docker, but I think it does some differential compression with the layers when you are modifying the image. So you don't have to re-do this install from scratch.

You may also run into issues with user IDs and various system config files in the chroot. Configuring the service with flags, env vars, and config files is a bit of a pain.

Docker is essentially a glorified chroot... I've essentially tried to rebuild it, and it is unfortunately a lot of work.

Only that chroot wont also run on the development machine, running a totally different OS.

This is a self-inflicted problem. 787 engineers don't have to test their work on a Learjet.

You do realize that the scenario you have described could be carried out with chroot just as easily, right? The only way "containers" help (and not containers as is, but Docker specifically) is that they ship the whole chroot OS image with all the dependencies.

I think the "just as easily" is highly debatable. I'm not a container evangelist by any stretch, but if you were going to take a "just chroot it" approach, the very first thing you'd want to do to ease the operational burden is define some kind of standard app packaging format that defines what's in the chroot and an entry point and an environment, and maybe some scheme for mapping external data and various other niceties you get with containers, and at that point, congratulations, you've reinvented containers.

> I think the "just as easily" is highly debatable.

Heads up, you're talking about a different thing. You want to run these things as normal operations, but gunnihinn was talking about deploying an application to check if it is of any value. Chroot is just enough to make a mess as the application's developer instructed in INSTALL.txt without the need to worry about cleaning up afterwards.

And by the way, you seem to be confusing containers and Docker.

I disagree. Just google "doesn't work in chroot" and you'll be reminded of a litany of issues that come up when trying to build/run things in a chroot, and a container containing a linux distro makes a tidy little sandbox which generally avoids those issues. It's somewhere on a spectrum between a chroot and a VM, which I think a lot of people find value in.

And I'm not confusing containers and Docker, I'm just speaking a bit imprecisely. In my experience, conversations about "containers" are rarely about raw containers, but rather some specific containerization scheme and tools (e.g. docker). I suspect everyone in this entire subthread means "docker containers" when they says "containers."

> Just google "doesn't work in chroot" and you'll be reminded of a litany of issues that come up when trying to build/run things in a chroot

Yeah, some newbie forgot to mount-bind a necessary directory like /proc or /dev, didn't provide sensible /etc/resolv.conf, or messed up host's and chroot's paths, either in request or in configuration. Nothing that would render chroot unviable. Is this what you meant?

Why would anyone want to get all that right manually when containers manage all that automatically?

Good question. Why anyone presented with fancy and fashionable third party software would use a mechanism that has been present for decades, ships with the operating system, works reliably and predictably, doesn't change substantially every quarter, doesn't do any magical things to network configuration, and is easy to inspect, debug, and adjust for an outsider? Why indeed?

So you have an organizational problem and you're hacking one problem with another hack. Clearly nothing can go wrong with this approach.

I don't see that as an organizational problem, but a way to try something out safely and faster.

I was referring to how they are unable to provision the right resources to run experiments because of all the red tape and they are getting around the issue by using docker. What happens when the red tape guard get wind of this?