7 ms·
I'm very excited about Docker[1] as both a development environment and deployment solution. However, from my early experiments, it seems there's an important di
by seldo 13y ago
I'm very excited about Docker[1] as both a development environment and deployment solution. However, from my early experiments, it seems there's an important difference between LXC (which is what Docker manages for you) and a full VM, namely that the model revolves around running one process at a time: you can install mySQL on your docker image, but once it's up, it's running mySQL -- you can't then ssh into it as you would a VM to poke around, modify config files, etc..
There are trivial ways to solve this, obviously. You can stop the image, restart it running bash, use that to modify config files, and then restart it again. But it requires a change of mindset: these things are much more than background processes, but they are less than a full VM. As the piece mentions, configuration management for newly-started images seems to be a missing piece of the puzzle right now, and debugging running Docker images can be... strange. [2] Not necessarily difficult, but different from what you're used to, and learning curves are barriers to adoption.
As this tech matures I think these things will be quickly solved, and I'm looking forward to the results.
[1] Plus Virtualbox, started by Vagrant. See mitchellh's comment.
[2] Unless, of course, I'm missing something. Docker-people: how do you configure vanilla server images to work in your environment?
- nickstinemates 13y agoWell, the canonical way of running a container is as you mention. However! There's a couple of options if you do not have a config you're completely happy with yet. One is to run a process manager like supervisord as your container process, and start up any arbitrary amount of services you wish (like ssh.) It's my understanding that in the future Docker will allow you to call `init` directly, so it becomes more vm like. The other, assuming a sufficiently modern kernel (I believe 3.8+, which is the minimum supported for Docker) is to use the lxc userland tools, specifically `lxc-attach <containerid>` This will allow you to create a shell in the running container and poke about as needed.
- seldo 13y agoMy experiments with lxc-attach always failed; presumably my kernel was wrong in some way (I followed instructions to get to 3.8, but I am sufficiently clueless that I wasn't sure it had worked, or that it was the right flavor of 3.8). But that's only the ad-hoc case: the bigger question is, if you have an image with instructions "RUN apt-get install mysql", you're not even halfway to having a copy of MySQL you can run in production: at a minimum you'll need to install a custom my.cnf to suit your application's operational parameters[1], but really you'll want it to be slightly different every time -- new bind addresses, potentially new master-slave relationship grants, etc.. The way docker images interact with configuration management in a grown-up production environment is still really hazy to me. [1] We are all agreed that running default my.cnf in production is laughable, yes? That information has filtered into the mainstream from the DBA crowd?
- nickstinemates 13y agoHow I would personally tackle that specific problem is the following: 1) Create a Dockerfile which installs the dependencies of my image as a base (maybe in this case all it is is RUN apt-get install mysql) 2) Tag the image as mysql-base. 3) Shell in to mysql-base, and iterate over the changes as needed until its 'production ready.' 4) Once it's suitably 'production ready', `docker diff` the version to see which files changed. 5) Here comes the fork in the road. Either go back and instrument my original Dockerfile to modify the files that were updated to make my image production ready, OR, `docker commit` that image. There are benefits to both sides, but ultimately it will be up to you in terms of maintainability. The definition of 'production ready' will differ from org to org. 6) Push the final image to a private registry.
- contingencies 13y agoWith step #1 ... apt-get install mysql ... what happens when the network repos go down? Like when you have to rebuild the same system four years later? You might wind up with an epic fail. That's not very stable as a packaging format then, is it? But this is just an example challenge from a much larger set... all of which derive from the fact that state is being allowed to seep in from random places. It's not clean. This is essentially one of the core complaints I have with some of these tools. In my own as-yet-unfinished tool's architecture that tackles similar domains, network access is disallowed at deployment time. If a package cannot be installed without network access, then it is not considered a valid package.
- nickstinemates 13y agoIt all depends on your tolerance threshold and the trade-off's that are involved to make an acceptable decision. If you expect apt-get install mysql to fail in the future, there are plenty of mitigating factors (storing the build/deps on your local repo, building from source..) My point is, you can always find pathological cases. Discussing them is great as a straw man for improvement, but not really useful beyond it.
- 13y ago
- peterwwillis 13y agoIf you want to poke around like normal, use supervisord or OpenVZ. (You get more features with OpenVZ like checkpointing and live migration)