4 ms·
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 s
by 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 agoI 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.