>You asked what they do.
I asked for their ostensible justification. A valid answer should not involve making up a justification I never referred to, with the implication I had done so, with you refuting said justification, even if other people proffer said justification.
And the reason that I asked, was because the first reply eye-rolled at the problem I ran into, and then (seriously, as best I can tell) suggested I should have solved it by nesting a VM within the existing VM to control the dependency chain that led to the problem — even though that was what the first VM exists to solve!
To clarify, here is that (dubious) reply again:
> That's not what containerization is about as can be easily demonstrated by simply running your container on a kernel that's built without some config option you rely on.
That is, surrounding the container by a controlled environment would avoid the problem… but I was already controlling the environment by a VM that exists to solve that problem! Hence, (sardonically) wondering what the first one is accomplishing.
> The most useful feature is they reduce the pain associated having negligently-large build and runtime dependency trees.
No, the most useful feature is locking down a machine spec that Just Works. When I have to go and debug things about that machine that suddenly fail, for reasons Docker (not the machine) introduced, I lost the most useful feature.
Sating my desire to have my app point at port 8000 and no other … is way, way down the list.