If you use RabbitMQ for development frequently, sometimes you might have found it uses too much resources (it's normal while programming to have a lot of queues or tasks 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 turned out to be just the tool for the work, and so far with a little simple configuration it can run as expected.
There is already a docker image for RabbitMQ, which can be automatically pulled, and then run, for example:
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]{.title-ref}). 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]{.title-ref} (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]{.title-ref} 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 approach to be very versatile for a development environment, and with RabbitMQ being the first pilot, I think I can migrate more applications to docker instead of having them installed on the system (as long as possible).