Because there are different use cases. About 100% of the people I talk to that use docker, are using it to make a separate set of dependencies available in a possibly-different distribution. For THOSE people, the ephemeral, stateless nature of docker is a huge detriment in usability, and a chroot would be far more appropriate. I see docker users waste countless hours working around its statelessness. All the time. YMMV
> ephemeral, stateless nature of docker is a huge detriment in usability, and a chroot would be far more appropriate
But ephemeral changes (e.g. inside the running container) are the opposite of statelessness in the comment you are responding to?
And if you have required intricate custom changes in mounted host volumes (config, ...) that are not living alongside the compose file in the same repository, you can have "statefulness" that survives killing the containers.
If you want stateful filesystems, you should be using a different tool. https://12factor.net/ outlines the design philosophy of serving compute resources in the cloud that containers (not docker, containers) attempt to solve. Inventing use cases for containers that are not the intended purpose, is not surprising you are having issues. You can make holes in things with drills and guns, but only one of those tools is being used for their intended purpose.
