1) Deploy images vs Dockerfiles is always a tradeoff. If you want to be absolutely sure that your code will run in production, then testing locally and pushing the image to a private registry such as Quay.io (disclaimer: I'm a cofounder of Quay.io) is a better approach. If, on the other hand, you want reproducibility of your execution environment, a Dockerfile can be better. As an example: Quay.io itself is built from source using a Dockerfile, which includes as one of its steps a RUN command that executes our full suite of tests. Users can tie Dockerfiles into Quay.io's Github integration [1] so that on every code push the Dockerfile is built (which includes running tests), and then pushed automatically to their repository. If setup correctly, this allows every single code change to be tested and a production-ready image to be created, all without an external CI or build machine.
2) Again, this is a tradeoff. If the context is sufficiently large or changing, it might be better to rsync the data from an external source every time the image is built (or even when it first starts if the data is EXTREMELY large). On the flip side, having the data inside the image means that you do not need to worry about networking and security issues around your data source. One point to note: The cache that Docker uses when building Dockerfiles is sensitive to file changes in the build package; if your files are changing a lot, make sure they are either on an external volume OR placed late inside the Dockerfile to prevent your earlier images from being rebuilt all the time.
3) HAProxy might be a solution for this; you could pipe different requests to different ports based on the incoming DNS name. We are also working on an (WARNING: experimental) project called gantry(d) [2] that makes handling container-based-components a whole lot easier.
[1] http://blog.devtable.com/2014/03/link-your-quayio-repositori...
[2] https://github.com/DevTable/gantryd
