RabbitMQ is a message broker, and its primary job is to make sure your applications can talk to each other reliably, even if they’re written in different languages or running on different machines. Think of it as a very sophisticated post office for your software.
Let’s get this running. We’ll install it on a single Ubuntu 22.04 machine.
First, update your package lists and install RabbitMQ:
sudo apt update
sudo apt install rabbitmq-server
This installs the core RabbitMQ server and its dependencies, including Erlang, which RabbitMQ is built upon.
Once installed, the service should start automatically. You can check its status with:
sudo systemctl status rabbitmq-server
You should see active (running). If not, start it with sudo systemctl start rabbitmq-server and enable it to start on boot with sudo systemctl enable rabbitmq-server.
Now, let’s enable the management plugin. This gives us a nice web UI to inspect queues, exchanges, and connections.
sudo rabbitmq-plugins enable rabbitmq_management
After enabling the plugin, you need to restart the RabbitMQ server for the changes to take effect:
sudo systemctl restart rabbitmq-server
By default, RabbitMQ comes with a user named guest that can log in from localhost only. To access the management UI from your machine (assuming it’s not localhost), you’ll need to create a new user and grant it permissions.
First, let’s add a user. We’ll call this user admin with the password password123 (change this to something secure!).
sudo rabbitmqctl add_user admin password123
Next, we need to grant this user administrator privileges so it can manage the entire RabbitMQ system.
sudo rabbitmqctl set_user_tags admin administrator
Finally, we need to give this user permissions on the default virtual host (/). This allows the user to create and manage queues, exchanges, and bindings within that virtual host.
sudo rabbitmqctl set_permissions -p / admin ".*" ".*" ".*"
The .* patterns mean "all resources" for configure, write, and read permissions.
Now, open your web browser and navigate to http://YOUR_SERVER_IP:15672. You should see the RabbitMQ management login page. Log in with the admin user and password123.
You’re now looking at the RabbitMQ management interface. On the left, you’ll see your default virtual host (/). This is like a namespace for your messaging. Applications connect to a virtual host to send and receive messages.
Inside a virtual host, there are three main components: exchanges, queues, and bindings.
- Exchanges: These are like mail sorters. When an application sends a message, it sends it to an exchange. The exchange’s job is to figure out where that message should go next. There are different types of exchanges (direct, topic, fanout, headers) that dictate how they route messages.
- Queues: These are like mailboxes. Messages sit in queues until an application consumes them. A queue is bound to an exchange, meaning it’s listening for messages that the exchange routes to it.
- Bindings: These are the rules that connect exchanges to queues. A binding tells an exchange to send messages matching certain criteria (like a routing key) to a specific queue.
Let’s create a simple fanout exchange named logs_exchange and a queue named log_queue. Then we’ll bind them.
In the management UI, go to the "Exchanges" tab. Click "Create new exchange".
- Name:
logs_exchange - Type:
fanout - Durable: checked (this means the exchange will survive a RabbitMQ restart)
- Auto-delete: unchecked
- Internal: unchecked
Click "Create exchange".
Now, go to the "Queues" tab. Click "Create new queue".
- Name:
log_queue - Durable: checked
- Auto-delete: unchecked
- Exclusive: unchecked
Click "Create queue".
Now we need to bind them. Go back to the "Exchanges" tab, find logs_exchange, and click the "Bind" button next to it.
- Queue:
log_queue - Routing key: (leave blank for fanout)
- Arguments: (leave blank)
Click "Bind".
With this setup, any message sent to logs_exchange will be delivered to log_queue, regardless of the routing key. This is useful for broadcasting messages to all listening consumers.
A key configuration detail often overlooked is the vm_memory_high_watermark. This setting determines how much RAM RabbitMQ is allowed to use before it starts applying backpressure to publishers. If this isn’t set appropriately for your server’s memory, RabbitMQ can be killed by the OS’s OOM killer, or it can become unresponsive. The default is often 40% of system memory. To check it, you can look at the RabbitMQ configuration files, typically located in /etc/rabbitmq/rabbitmq.conf or /etc/rabbitmq/rabbitmq-env.conf. If you want to set it to 50% of available memory, you’d add vm_memory_high_watermark.relative = 0.5 to rabbitmq.conf. After changing this, remember to restart RabbitMQ.
You’ve now got a functional RabbitMQ server with a management interface and a basic exchange-queue setup. The next step is usually to explore different exchange types like topic or direct for more nuanced routing patterns.