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.
Comments
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.