[jbert]

I've just started using docker (I had to reimage my linode to take advantage of the recent upgrade). I've got nginx and postfix containers running. If anyone can offer some thoughts on the following points I'd be grateful.

1) I built two Dockerfiless on my laptop (one for nginx, one for my postfix setup) tested locally, then scp'd the Dockerfiles over to the server, built images and ran them. I didn't really want to pollute the registry with my stuff. Is this reasonable? For bigger stuff, should I use a private registry? Should I be deploying images instead of Dockerfiles?

2) The nginx setup I deployed exports the static html as a VOLUME, which the run command binds to a dir in my home dir, which I simply rsync when I want to update (i.e. the deployed site is outside the container). Should I have the content inside the container really?

3) I'm still using the 'default' site in nginx (currently sufficient). It would be kind of nice to have a Dockerfile in each site I wanted to deploy to the same host. But only one can get the port. I sort of want to have a 'foo.com' repo and a 'bar.org' repo and ship them both to the server as docker containers. Don't really see how to make that work.

What I think I want is:

- a repo has a Dockerfile and represents a service

- I can push these things around (git clone, scp a tgz, whatever) and have the containers "just run"

Not sure how to make that fit with "someone has to own port 80"

[nonsens3]

1) Testing a Dockerfile, then scp'd it to the server, doesn't guarantee that it will build successfully on the server. However if you build successfully an image and push it to a repository - it will definitely work. Based on this, you can decide which one works for your setup. If you are on a production setup, I would say that you should use tested images, instead of hoping that the Dockerfile will build correctly.

3) As far as I understand your problem is that both containers would be running their own nginx, and would have to take port 80 for example. If this is what you mean, you could just EXPOSE port 80 from within the container, and it will automatically be mapped to a random port like 43152. Both containers would be mapped to different random ports (for example 43152 and 43153). You could then install Hipache and route different domain names/sites to different containers, essentially having Hipache proxy in front your Docker containers setup.

EDIT: There is also a project called Shipyard, which is Docker management... what I described above is called "Applications" inside Shipyard.

[0] https://github.com/shipyard/shipyard [1] https://github.com/dotcloud/hipache

[jschorr]

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

[jeffbr13]

Not an expert, but one solution is to have an Nginx configuration file for each website in `/etc/sites-enabled`, which matches requests based on the `server_name` parameter.

Then you can reverse-proxy requests to the right location/port from your Nginx webserver.

This could be provisioned pretty easily, but not from within a Dockerfile. I use a post-receive hook on a remote Git repository, for one of my own websites.

[cdcarter]

Dokku might help you out with the repo-per-site-on-nginx plan!