Human friendly wrapper around Docker
Redock is a human friendly wrapper around Docker, the Linux container engine. Docker implements a lightweight form of virtualization that makes it possible to start and stop “virtual machines” in less than a second. Before Docker the use of virtualization meant conventional virtual machines with all of the associated bloat. Docker makes it ridiculously cheap and fast to start/save/kill containers. This opens up exciting new possibilities for DevOps:
- Complex build environments can be split up into isolated containers where each container is concerned with the build requirements of a single project. If a project’s build goes out of hand you just trash the container and go on your merry way :-)
- The correctness of automated deployment systems (and distributed systems in general) can be verified by using containers to host the configuration management server and agents.
- To be honest, Docker is so fast that I could imagine myself building a test suite of a complete cluster on top of it.
The last point is the reason why I started working on Redock. In my initial experiments with Docker I found a lot of sharp edges (both in the lack of documentation and in the implementation of Docker and its Python API) but at the same time my fingers were itching to wrap Docker in an easy to use and human friendly wrapper to try and unleash its potential.
What Redock gives you is Docker without all the hassle: When you create a container, Redock will install, configure and start an SSH server and open an interactive SSH session to the container. What you do with the container after that is up to you…
Redock should be considered alpha quality software. So far it has been used by a single person (me). Right now it’s intended for development work, not production use. This might change over time, depending on my experiences with Docker over the coming weeks / months (I’m specifically concerned with stability and performance).
By the way the same can and should be said about Docker (its site says as much). During heavy testing of Redock I’ve experienced a number of unhandled kernel mode NULL pointer dereferences that didn’t crash the host system but certainly also didn’t inspire confidence ;-). It should be noted that these issues didn’t occur during regular usage; only heavy testing involving the creation and destruction of dozens of Docker containers would trigger the issue.
There’s one thing I should probably mention here as a disclaimer: Redock rewrites your SSH configuration (~/.ssh/config) using update-dotdee. I’ve tested this a fair bit, but it’s always a good idea to keep backups (hint).
I’m currently using Redock on Ubuntu 12.04 with Docker 0.6.3 and a Linux 3.8.0 kernel (as suggested in Docker’s installation instructions for Ubuntu). I’ve only just switched to these versions and it seems they may have solved the stability issues I mentioned above (time will tell :-).
You will need to have Docker installed before you can use Redock, please refer to Docker’s installation instructions. You may also want to add your user account to the docker group so you can connect to Docker without sudo (this took me a while to realize when I switched to Docker 0.6 :-). After you’ve installed Docker you can install Redock using the following command:
$ pip install redock
This downloads and installs Redock using pip (the Python package manager). Redock is written in Python so you need to have Python installed. Redock pulls in a bunch of dependencies so if you’re familiar with virtual environments you might want to use one :-). Once you’ve installed Docker and Redock, here’s how you create a container:
$ redock start test
If you run this command interactively and you start a single container, Redock will start an interactive SSH session that connects you to the container. In any case you will now be able to connect to the container over SSH using the name you gave to the container suffixed with -container:
$ ssh test-container
This works because your ~/.ssh/config has been updated to include a host definition for the container. This means you can connect using rsync or anything else which works on top of SSH (e.g. to bootstrap a configuration management system). When you’re done playing around with the container you can save your changes with the following command:
$ redock commit test
This command will persist the state of the container’s file system in a Docker image. The next time you run Redock with the same name it will create a container based on the existing disk image. To kill and delete a running container you use the following command:
$ redock kill test
This will discard all changes made to the file system inside the container since the last time that redock commit was used. The Docker image associated with a container can be deleted like this:
$ redock delete test
In the examples above the name test is used. This name is used by Redock to identify the running container (created with redock start) and any associated images (created with redock commit). By using multiple names you can run multiple containers in parallel and you can suspend / resume “long term” containers.
The names accepted by Redock are expected to be of the form repository:tag (two words separated by a colon):
- The first part (repository in the example) is a top level name space for Docker images. For example there is a repository called ubuntu that contains the official base images. Similarly Redock uses the repository redock for the base image it creates on the first run.
- The second part (tag in the example) is the name of a specific container and/or image; I usually just sets it to the host name of the system that will be running inside the container.
If the colon is missing the repository will be set to your username (based on the environment variable $USER).
The latest version of Redock is available on PyPI and GitHub. The API documentation is hosted on Read The Docs. For bug reports please create an issue on GitHub. If you have questions, suggestions, etc. feel free to send me an e-mail at firstname.lastname@example.org.
This software is licensed under the MIT license.
© 2013 Peter Odding.