4 ms·

If you're just using docker and running containers yourself, manually, or via simple daemon scripts, you're not far wrong. If you're deploying to a cloud envir

If you're just using docker and running containers yourself, manually, or via simple daemon scripts, you're not far wrong. If you're deploying to a cloud environment and you just want your stuff to run, have no restrictions around being on the same box or different boxes, and make your stuff find the things it needs to via service names, and have stateless things that auto-scale and load-balance transparently, then you need more isolation because you can't have an environment which delivers that kind of functionality without it.

jeffbee 6y ago
There are large-scale existence proofs of environments that do all this without any of network or process or filesystem isolation.
- jayd16 6y ago
  Maybe, but network isolation is an easy way to solve it and the existence of those environments shows its an important thing to solve.
  - peterwwillis 6y ago
    The thing it's solving is not needing to configure the software to bind on a particular port and IP at runtime. I will agree that this is the easiest possible solution from a usability standpoint. But this functionality adds a unique non-portable requirement to the host, in addition to making routing more difficult. An entrypoint could take care of making the port change at runtime, and then we wouldn't need the extra abstraction. One of the biggest problems of running containers in the cloud is that they're not natively rootless. That largely comes from all the extra layers and abstractions and functionality, which again are super useful, but not necessary. The cloud would be a lot easier to manage if we didn't make it so complex.
    - jayd16 6y ago
      I disagree. You'd still have to manage it, except instead of late binding and managing it in the image routing, you need to manage it in your apps instead. Routing may be complex but IMO the system as a whole is a lot less complex. And philosophically its the same arguments for file system isolation. You could just do the hard work to make sure your software knows not to impact other apps running on the server...but that's the whole thing you want to avoid. We use containers because its hard to guess the environment they'll be run in and we made the decision to jump through some hoops to be able to do this configuration at deploy time not dev time.
- barrkel 6y ago
  Like Mesos, or YARN, they still package up an application for orchestration, and they're not as flexible.

jeffbee 6y ago

There are large-scale existence proofs of environments that do all this without any of network or process or filesystem isolation.

jayd16 6y ago
Maybe, but network isolation is an easy way to solve it and the existence of those environments shows its an important thing to solve.
- peterwwillis 6y ago
  The thing it's solving is not needing to configure the software to bind on a particular port and IP at runtime. I will agree that this is the easiest possible solution from a usability standpoint. But this functionality adds a unique non-portable requirement to the host, in addition to making routing more difficult. An entrypoint could take care of making the port change at runtime, and then we wouldn't need the extra abstraction. One of the biggest problems of running containers in the cloud is that they're not natively rootless. That largely comes from all the extra layers and abstractions and functionality, which again are super useful, but not necessary. The cloud would be a lot easier to manage if we didn't make it so complex.
  - jayd16 6y ago
    I disagree. You'd still have to manage it, except instead of late binding and managing it in the image routing, you need to manage it in your apps instead. Routing may be complex but IMO the system as a whole is a lot less complex. And philosophically its the same arguments for file system isolation. You could just do the hard work to make sure your software knows not to impact other apps running on the server...but that's the whole thing you want to avoid. We use containers because its hard to guess the environment they'll be run in and we made the decision to jump through some hoops to be able to do this configuration at deploy time not dev time.
barrkel 6y ago
Like Mesos, or YARN, they still package up an application for orchestration, and they're not as flexible.