7 ms·

> let's say all my 50 containers share a bunch of files (shared libraries like libc, Ruby gems, a base operating system, etc.). It would be nice

> let's say all my 50 containers share a bunch of files (shared libraries like libc, Ruby gems, a base operating system, etc.). It would be nice if I could load all those files into memory just once, instead of 3 times. Correct me if I'm wrong, but doesn't this kind of situation seem like a poor use-case of containers? It seems to me that one of the main points of containerization is to encapsulate the runtime dependencies of a process. If you're conflating that by making two containers depend on the same runtime objects then the point of containerization has been lost. You might as well go back to a virtual machine. That's not to suggest that there are not circumstances where overlay networks and filesystems aren't useful, just that you should not be using them to manage dependencies. Under this architecture, what happens when I want to update my applications to use a new version of a shared library? I either am forced to update all of my applications at once or I must modify the architecture and remove that shared dependency. This breaks down the composition that containerization promises. I think that this advice should be re-examined. I am by no means an expert, but this doesn't seem smart to me...

dkarapetyan 10y ago
This is exactly how the overlay filesystem in docker works. You make a base container with common runtime dependencies and then you layer applications that require those same dependencies on top. The applications can be quite dissimilar. I don't see why the point of containerization has been lost? Just because the same kind of thing is hard to do without an overlay filesystem doesn't mean there is anything wrong with the approach.
- therein 10y ago
  Things get complicated when one the applications decide to write to the shared data. Do you reflect the changes to the other container? How isolated do you wish to keep them? I mean at one point one should consider if they want to share these underlying resources, perhaps they should just be okay with running them as two processes.
  - dkarapetyan 10y ago
    I don't think it's complicated. If you need a shared location so that different containers can write to then you should explicitly mark those locations and mount them inside the respective containers. This wouldn't be any different if you were sharing directories between processes.
  - jacques_chester 10y ago
    Typically the design pattern is that long-lived state is outside the container. So you'd have a volume that you attach.

dkarapetyan 10y ago

This is exactly how the overlay filesystem in docker works. You make a base container with common runtime dependencies and then you layer applications that require those same dependencies on top. The applications can be quite dissimilar. I don't see why the point of containerization has been lost? Just because the same kind of thing is hard to do without an overlay filesystem doesn't mean there is anything wrong with the approach.

therein 10y ago
Things get complicated when one the applications decide to write to the shared data. Do you reflect the changes to the other container? How isolated do you wish to keep them? I mean at one point one should consider if they want to share these underlying resources, perhaps they should just be okay with running them as two processes.
- dkarapetyan 10y ago
  I don't think it's complicated. If you need a shared location so that different containers can write to then you should explicitly mark those locations and mount them inside the respective containers. This wouldn't be any different if you were sharing directories between processes.
- jacques_chester 10y ago
  Typically the design pattern is that long-lived state is outside the container. So you'd have a volume that you attach.