[sp332]

I felt like everything had to be set up outside the container, before starting it up. To get something simple like ZNC running, I had to write the config file beforehand and then add it to the dockerfile. I guess I can see how that would be useful in a big deployment. But for a one-off like this, it's much easier to boot the container, install ZNC, then edit the config. And if (when) I screwed up the config, I could just edit the file instead of rebuilding the container.

[ekidd]

OK, that makes sense.

Since you asked, the drawback of just logging into an image, editing files, and installing software is that you can only reproduce that image by grabbing an entire file system.

When I use Docker, I create a git repository containing a 'Dockerfile', which is basically a series of shell commands to configure a machine. I also add copies of any configuration files I'll need, and use the Dockerfile to copy them onto the machine during setup.

This can be extremely fast in practice: Docker has a caching system which "runs" unchanged lines in Dockerfile by looking up a cached VM image, so I can often edit the Dockerfile and rebuild the image in a second or so.

This approach is really nice when I have to look at an image a year later and figure out how I created it, perhaps with the goal of upgrading to a new OS release or whatever. I just glance at the Dockerfile, change the base OS version, and re-run it.

[sp332]

I wonder if the UI could be improved. Like a "dockerfile creator" that lets you log in and make changes, then at the end lets you look at a list of changes or "history" entries and selectively pull them into a dockerfile.

[opendais]

http://blog.codiez.co.za/2013/09/setup-a-docker-container-wi...

sudo docker run -i -t ubuntu /bin/bash sudo docker commit [container id] [tag]

Is that what you are looking for?

[wmf]

docker commit produces an opaque container image that's not documented or repeatable.

[vidarh]

"docker diff [container]" will show you what files have changed since the image was started, and you can then "docker cp" files out of the container to the host.

But for my part I tend to just layer changes piece by piece. So e.g. I have a docker image that's a "base development" image, and create separate docker containers to run each web app I'm experimenting with, with a shared volume with a separate docker container that I ssh into and run a screen session in with the code/git repositories. In effect that means that bringing up a new docker image for a new project is at most a couple of lines of change unless the project has particular/different dependencies.

[derefr]

I'm not sure there is truly such a thing as a "one-off" in the sense you're using it. What happens when your server dies (e.g. catastrophic disk failure, etc)—how do you get your service set up again? If your answer is basically "I re-make it from scratch", then Docker will save you a lot of time, no matter what scale you're operating at. Every Dockerfile is effectively a reproducible build; you'll never need to wonder what dark magicks brought the current state of the system about, because they're all explicitly documented right there, starting from a known-to-its-very-SHA base-image.

If you ever heard some of Heroku's propaganda surrounding "eternal applications", it also applies here: the stack you're deploying on will never update out from under you, because it's pinned by your Dockerfile. You can confidently move your app to any old server and it'll run exactly the same. One good analogy I've heard is that a Docker image is the reductio ad absurdum of a static binary: it doesn't depend on your system, just on itself.

[sp332]

Where do you put all of your data? Edit: specifically, ZNC keeps an archive of some channels for me. If I ran it in a Docker container, would the data be saved somewhere if, say, the power went out?

[shykes]

Just in case you missed it: you can "docker commit" the state of a container at any time (and "docker diff" to see what has changed on disk since creation). Would that solve your problem?