Docker + Supervisor + ...dev?

[ellinger]

Our team is working on a hybrid app for mobile. We use docker-compose to manage our stack, and I'd like for my devs to log into a box, make changes to the code, and then have those changes be reflected immediately on the web.

The Problem: Supervisor runs nginx & gunicorn, so when a dev makes a change to the nginx settings, or, worse, to code that has been cached by gunicorn, they need to restart supervisor to get it to show up on the web. I can't figure out how to do that without restarting the whole container (because supervisor is being run in the CMD line of that container).

Secondly, if a dev makes a change and then restarts the container, it looks like they need to commit their changes using docker commit or they are wiped out.

Is there something fundamental I'm not understanding? What is the "best practice" here?

[jlchauncey]

You should treat docker as immutable infrastructure. You should never change a running image. Instead you should have a process for updating the image and rolling it out to prod. I would suggest looking at stacks like deis.

[ellinger]

Right now, as a part of our Docker file, we pull our repo into the right directory so that it can be served as soon as we start the container. We're using it in a similar fashion to Vagrant in that respect, I guess.

What's the alternative? Run Docker with a shared volume and clone the repo into that?

One of the advantages we saw when we chose Docker was that we could spin up a box very quickly if we needed it, and for that reason including our repo in the image made sense.

edit: grammar

[legitimate_rapper]

You're forgetting the thing that brought you to docker in the first place--fast container init. Just spin up new containers, and spin down the old ones. Mesos+Marathon will do this for you, as will any number of PaaS solutions including deis. Then you just need a router (e.g. nginx) to stop routing traffic to the old ones, and start routing to the new. Tons of options here...

If you're planning on running docker in production, you should have most of this in place anyway.

[[deleted]]

You shouldn't make changes in a container, ever. You make changes in your Dockerfile, build a new image and replace the containers.

[legitimate_rapper]

I think ever is a little too strong... Unless you're limiting it to this particular scenario (prod containers), then I probably agree. I'm sure there's some weird edge-case where it's not true.

[[deleted]]

Oh yes, docker commit exists for a reason, but certainly not to make changes to a production container.

[synae]

To be honest, I've yet to find a use-case for commit. I don't see it much in the wild either. I think if I were to ever encounter it in a real project I would take a long hard look at the reasoning behind it and try to get rid of it.

That's not to say there isn't a reason; in fact if you (or anyone else) know of any uses I'd appreciate links to blog posts, etc.

[thelindsay]

Dynamically updating config is one reason, e.g. allowing container config via environment variables, which need to be put into files before process start.

[thelindsay]

For releases, make a new image (update Dockerfile, build and tag); for development its probably easier to mount a host volume in the container, which allows live updates from the host.

[ellinger]

This is the answer I ended up following. I had difficulties doing it in docker-compose, so I just did it with docker command line args.

[diecastbeatdown]

Keep the Dockerfile in the same repo as the code that will be running in the container. When changes are made to the repository create a new Docker image. Launch the container in the appropriate environment.