In this post I’ll try to explain the method I use to avoid having permission issues when using Docker Volumes. This is pre Docker 1.10 (which added user namespaces) and I will talk about those in my next post.

Before we begin let me explain what are Docker Volumes and what they’re used for. The official Docker docs explain this feature as follows:

A data volume is a specially-designated directory within one or more containers
that bypasses the Union File System.

The main use-case for volumes is for persisting data between container runs (seeing as container are ephemeral). This is useful for data directories when running databases (such as PostgreSQL) within containers. Other than persisting databases it’s useful for sharing code folders from your host system to the container when running in your development environment.

If you’ve worked with Django at some point you probably had the need for some background processing of long running tasks. Chances are you’ve used some sort of task queue, and Celery is currently the most popular project for this sort of thing in the Python (and Django) world (but there are others).

While working on some projects that used Celery for a task queue I’ve gathered a number of best practices and decided to document them. Nevertheless, this is more a rant about what I think should be the proper way to do things, and about some underused features that the celery ecosystem offers.

Recently I’ve been reading more and more about Systemd. Now, most distros have already moved to Systemd but I’m using Debian and was stuck with init which was the default. Given the recent discussion on the Debian mailing lists about migrating to systemd as the new default, I was even more inclined to make the switch now and get used to it before it’s forced upon us.

Actually I was really looking forward to it, but as Linux goes I was expecting it to be a pain, so I was pleasantly surprised that it only took me 10 minutes and wasn’t a hassle at all.

I’ve decided to document the steps I’ve taken in case that someone finds it useful.

Docker currently supports getting logs from a container that logs to stdout/stderr. Everything that the process running in the container writes to stdout or stderr docker will convert to json and store in a file on the host machine’s disk which you can then retrieve with the docker logs command.

This is handy but it has its drawbacks because you don’t get any log rotation and the file size of the collected logs can become an issue as it eats up your host’s disk space. Not to mention the fact that every time you run docker logs container_id you get all the logs of that processes from the beginning.

While there are some interesting things being discussed on the docker-dev mailing list, I wanted to see if I could get docker to play along with proven logging systems out there with the functionality I have now.

Recently I’ve been thinking a lot about how to simplify my code. Now, the key thing to note here is that simple != familiar.

Classes for example are familiar to most people. But code consisting exclusively of classes and OOP concepts isn’t necessarily simple all of the time. The question arises: Is there something simpler?

Well, the first thing that comes to mind, of course, good old functions. Functions are universal, everybody understands them, even new programmers that don’t yet get all the fancy concepts about OOP, get plain old functions.

Keep in mind, I’m not saying that classes don’t have their place in our code, but rather that maybe we don’t need them quite as often as we might think.