5 ms·

I work in a big company. It's much easier for us to spin up a container to run whatever experimental program we've thought might be useful to help us do our job

I work in a big company. It's much easier for us to spin up a container to run whatever experimental program we've thought might be useful to help us do our job than to provision a real box for it to run on or fit it into the whole bureaucracy. If it's actually useful we'll find someplace for it to live (or just in containers if that's all that's needed). If not, finding that out was cheap.

dozzie 9y ago
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.
- hamburglar 9y ago
  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.
  - dozzie 9y ago
    > 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.
    - hamburglar 9y ago
      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."
      - dozzie 9y ago
        > 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?
        jstarks 9y ago
        Why would anyone want to get all that right manually when containers manage all that automatically?
        dozzie 9y ago
        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?
concede_pluto 9y ago
If you have machines with unused capacity, why would deploying a docker container image be easier than deploying a RPM package?
- wmf 9y ago
  Because either there is no RPM or the RPM conflicts with other RPMs on the machine.
  - dkarapetyan 9y ago
    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.
    - coldtea 9y ago
      Only that chroot wont also run on the development machine, running a totally different OS.
      - concede_pluto 9y ago
        This is a self-inflicted problem. 787 engineers don't have to test their work on a Learjet.
    - chubot 9y ago
      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.
dkarapetyan 9y ago
So you have an organizational problem and you're hacking one problem with another hack. Clearly nothing can go wrong with this approach.
- gumby 9y ago
  I don't see that as an organizational problem, but a way to try something out safely and faster.
  - dkarapetyan 9y ago
    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?
- deleted 9y ago
  [deleted]
gumby 9y ago
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.
- digi_owl 9y ago
  It very much has. Mix it in with devops and agile, and before you know it everyone is throwing hot code directly to "prod"...

dozzie 9y ago

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.

hamburglar 9y ago
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.
- dozzie 9y ago
  > 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.
  - hamburglar 9y ago
    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."
    - dozzie 9y ago
      > 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?
      - jstarks 9y ago
        Why would anyone want to get all that right manually when containers manage all that automatically?
        dozzie 9y ago
        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?

concede_pluto 9y ago

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

wmf 9y ago
Because either there is no RPM or the RPM conflicts with other RPMs on the machine.
- dkarapetyan 9y ago
  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.
  - coldtea 9y ago
    Only that chroot wont also run on the development machine, running a totally different OS.
    - concede_pluto 9y ago
      This is a self-inflicted problem. 787 engineers don't have to test their work on a Learjet.
  - chubot 9y ago
    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.

dkarapetyan 9y ago

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

gumby 9y ago
I don't see that as an organizational problem, but a way to try something out safely and faster.
- dkarapetyan 9y ago
  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?
deleted 9y ago
[deleted]

gumby 9y ago

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.

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