>The idea of using an isolated user and a shared filesystem makes no sense;
I do run my stuff in containers, I have about 30 of them setup, each one with it's own service.
However, I still have to login into these containers, which happens as root (for the container). And then having to pivot to the app user is bothersome. Luckily or strangely a lot of applications don't work as root because nobody should be running any service as root.
>On the contrary, it forces good practice by ensuring that you always know how to install the set of dependencies that you need;
I have automated deployment for that. I simply add a python script to my fabric repository and signal which container should install it, the rest is fully automated and tested.
User-local installs are complicated here since it means the deployment script will have to pivot to another user temporarily.
>When you rely on system installs of packages, you create exactly the same problem when you come to run the program on multiple servers, only less fail-fast and harder to diagnose.
I also create a reproducable problem, user-local installs are less reproducable, in my experience.
I can replicate the exact environment of an app server installed via apt-get within a few keystrokes (I wrote a fabric task for that; "fabric copy-deployment <sourcecontainer> <targetcontainer>")
>If you get in a position where that's you're requirement, you've done something wrong. Take a step back and figure out what you really need.
You mean like running multiple instances of the same service? That happens. Maybe you want to deploy three seperate instances of AppSomething for three domains with three seperate datasets. Instead of deploying three containers, I deploy one container.