Running RabbitMQ server on Docker

If you use Ra­bbit­MQ for de­ve­lo­p­ment fre­quen­tl­y, so­me­ti­mes you mi­ght ha­ve foun­d it uses too mu­ch re­sour­ces (i­t’s nor­mal whi­le pro­gra­m­ming to ha­ve a lot of queues or ta­sks being queued and that makes the CPU usage to spike).

Having RabbitMQ installed on the OS seems the perfect approach for production, but on development I’d rather do something different, in order to isolate the process. I know I could bound it (for example order it not to start automatically as a dæmon), by means of systemd but a few weeks ago I decided to try docker and see how it results.

It tur­ned out to be just the tool for the wo­rk, and so far wi­th a li­ttle sim­ple ­con­fi­gu­ra­tion it can run as ex­pec­te­d.

The­re is al­ready a do­cker ima­ge for Ra­bbit­M­Q, whi­ch can be au­to­ma­ti­ca­lly pu­lle­d, and then run, for exam­ple:

sudo docker pull rabbitmq
sudo docker run -d -e RABBITMQ_NODENAME=my-rabbit --cpuset="1" --name docker.rabbitmq -p 5672:5672 rabbitmq:3

The -d option indicates the process to start detached, then by passing -e we pass some environment variables (in this case, the RABBITMQ_NODENAME is a particular variable for rabbit indicating how to set the name of the node it is starting). Optionally, we can limit the CPU usage with the --cpuset, as in this case which sets the process to use the second core of the machine (it starts at 0). Then the --name is a name for the docker being created.

The most important part in this case is the port mapping, made by the -p option which in this case maps the port used by RabbitMQ directly (1:1) with the host machine. This makes the docker process to run transparently, as the other applications that try to communicate with a RabbitMQ won’t notice any difference, making it look like is executing an actual RabbitMQ service. Finally there is the name of the docker image to run.

What I usually do is to manage the docker image by its instance_id (a number that is displayed after listing the docker images, by doing sudo docker ps -a). Then we can manage it by sudo docker [start|stop] <instance_id>.

There is another command to see the output being generated by the process which is docker logs rabbitmq.docker. Notice in this case the name designated to the image was used instead of the instance_id. In addition we can see internal data for the process by running the inspect command (again we can use the instance_id or the name we assigned).

docker inspect rabbitmq.docker
sudo docker logs docker.rabbitmq

It’s important to notice that docker is actually not a virtualization platform, but a mechanism that runs processes in containers, meaning that in this case the entire RabbitMQ is running as a single process within a container, with some other limitations and bounds constrained by docker.

I found this appro­ach to be ve­ry ver­sati­le for a de­ve­lo­p­ment en­vi­ron­men­t, and wi­th Ra­bbit­MQ being the first pi­lo­t, I thi­nk I can mi­gra­te mo­re appli­ca­tions to do­cker ins­tead of ha­ving them ins­ta­lled on the sys­tem (as long as po­s­si­ble).