Is Docker one of those things that works better for big projects than small ones? I tried using it for 3 little projects, just to see what all the fuss was about. But every time it ended up being easier to use bare LXC.
Yes. It is like configuration management [e.g. Chef, Salt]. It doesn't make sense to do for one off projects [unless you already have it as part of your workflow].
Like, I have a generic Flask container repository that I clone as a starting base...change the domain name(s) on the config file, app name, etc. Then just copy things into the src/ directory and spin it up.
For me, this is really easy to spin up a new flask project. I do the same with golang [sort of, it really just downloads a binary+config file into a container that has all of my logging, etc setup].
The problem with doing LXC is where you have inheritance chains like this:
[Base Container of Ubuntu + Logging + Monitoring] -> [Base Flask Container] -> [Flask Container for Website X]
[Base Container of Ubuntu + Logging + Monitoring] -> [Base Flask Container] -> [Flask Container for API for Website X]
[Base Container of Ubuntu + Logging + Monitoring] -> [Container for Mail Service]
[Base Container of Ubuntu + Logging + Monitoring] -> [Container for Kibana]
[Base Container of Ubuntu + Logging + Monitoring] -> [Container for Redis-Cache]
etc.
Tbh, I think that is what docker really fixes. The ability to easily inherit containers so you only have to make changes in one spot to change all of them.
My bet? Docker increasingly is something that will be used even if the user don't know it.
Builds, as an example. This was my first introduction to Docker - scaling Jenkins worker nodes was allocating yet another VM. As you scale to tens or hundreds of build slaves, you realize utilization across the cluster is down. Scaling builds with Docker was simple and efficient to implement and it allowed me to drive utilization up dramatically.
Now there's 15 different companies, integrations, and tooling surrounding this space to make that process repeatable to the masses. Amazing.
We're seeing the same thing in the orchestration, paas, sdn, iaas, YOUR ACRONYM OF CHOICE, and one common theme is that ecosystem is standardizing around Docker. That's pretty powerful.
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.
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.
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.
"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.
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.
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?
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?
That's not true, and it has got nothing to do with the pause/unpause feature. You can see stopped containers with `docker ps -a`, and you can restart them.
Like, I have a generic Flask container repository that I clone as a starting base...change the domain name(s) on the config file, app name, etc. Then just copy things into the src/ directory and spin it up.
For me, this is really easy to spin up a new flask project. I do the same with golang [sort of, it really just downloads a binary+config file into a container that has all of my logging, etc setup].
The problem with doing LXC is where you have inheritance chains like this:
[Base Container of Ubuntu + Logging + Monitoring] -> [Base Flask Container] -> [Flask Container for Website X]
[Base Container of Ubuntu + Logging + Monitoring] -> [Base Flask Container] -> [Flask Container for API for Website X]
[Base Container of Ubuntu + Logging + Monitoring] -> [Container for Mail Service]
[Base Container of Ubuntu + Logging + Monitoring] -> [Container for Kibana]
[Base Container of Ubuntu + Logging + Monitoring] -> [Container for Redis-Cache]
etc.
Tbh, I think that is what docker really fixes. The ability to easily inherit containers so you only have to make changes in one spot to change all of them.