3 ms·
> Complex systems require complex interaction, and Docker images do not allow for that Unless you compose a complex system by composing multiple containers - w
by shykes 13y ago
> Complex systems require complex interaction, and Docker images do not allow for that
Unless you compose a complex system by composing multiple containers - which is the whole point of containers.
> they are monolithic, all-or-nothing changes
Compiling a binary is also a monolithic, all-or-nothing change. If you dig deep enough there is always such a change. In the operation of distributed systems (which you claim to be an expert of) that is a desirable property.
> which can only be "modified" by either remaking the entire image (expensive)"
Docker caches build steps. Which means it only rebuilds the layers which need to be rebuilt.
Typically this means the application code is rebuilt when the developer pushes a new version, while the underlying layers are left untouched. You know... the same "rebuilding" your ghetto deployment script currently does.
> or adding another layer of overhead on top, which I don't think anyone has ever investigated to find bottlenecks or overhead problems.
We have been using aufs layers as the build mechanism for lxc containers at dotCloud for roughly 3 years. In that time we've probably deployed half a million containers, and served a few hundred million uniques (and I'm being conservative). These containers included app servers, databases, and everything in between.
So, yeah, they've been "investigated" for bottlenecks and overhead problems.
- peterwwillis 13y ago1. You don't understand what I mean by complex system, and i'm talking about changes to a single file in a container. Running a new container does not change the old container. 2. Compiling a binary is not a 'monolithic change' (?), it is a static configuration with dynamic elements. And please quote the line where I called myself an expert of anything. 3. Uh, I don't have a "ghetto deployment script", but thank you for the kind words. Like I was saying before, your only option is to continue adding on more unions every time you change a file, which I bet will lead to performance degradation, if not just general application headaches in the future. If somehow Docker also prevents the need to stop and restart the container when adding a new layer (which should be possible with Union), that's great too! It still leaves a world of cruft behind in the form of old filesystem layers and a maintenance hassle. Awesome, you have real world performance numbers! So how many layers can you add to a container without it going down before there's performance degredation? How does it affect memory, or disk space from added layers? Does aufs have an upper bound on the number of layers, or any other metrics? Would love to see some numbers on this.