Yes, but often you are better off isolating these processes from each other, and only allow communication over the network.
Most of the time these processes only need the network to communicate with each other. When there is a legitimate reason for processes to share the same filesystem, process namespace or network address (for example for debugging), that's when `docker exec` becomes helpful.
Sure, if I was designing a production grade system I probably would isolate a lot of the services.
But I thought the whole idea of Docker was I could download something like a "Wordpress image" from the Docker marketplace, and it would just work in a self-contained way. Unless there is some higher level tool to download multiple Docker images for different apps and configure them together to provide a service of some kind.
You're right, ideally you could get the best of both worlds: 1) multi-container stack that mimics the production setting, and 2) something you can 'docker pull' and 'docker run' as a single unit.
For now you need 3d-party tools to define their own multi-container constructs, like Fig or Kubernetes. Eventually Docker needs to implement a multi-container construct of its own, to avoid fragmentation (interoperable containers are not as useful if they're bundled in non-interoperable wrappers). Luckily, the authors of Fig work at Docker and we're working closely with the authors of Kubernetes. So if you use either of those tools, you will probably be familiar with the native Docker version :)
I personally believe this is somewhere something like fig comes into play nicely. You can still have the isolated services, but with super simple setup: download the fig.yml and run fig up.
It seems like phrasing it as "one service per container" (with service being in the SOA sense), might be better.
Certainly, I think of an SOA app being composed of multiple services, and I'm pretty sure the thing you're suggesting that the thing you want one of in the container is what I'm calling a service.
Most of the time these processes only need the network to communicate with each other. When there is a legitimate reason for processes to share the same filesystem, process namespace or network address (for example for debugging), that's when `docker exec` becomes helpful.