CCM runs its production servers on Ubuntu Linux. Most of the developers' workstations run Mac OS X and Linux, while some run Windows. This heterogeneity is not a concern for RabbitMQ, which can run natively on all these operating systems.

RabbitMQ provides complete online installation guides for all the supported operating systems (you can access these at http://www.rabbitmq.com/download.html). In our case, we will follow the instructions for Debian/Ubuntu.

For greater control, we do not wish to use the RabbitMQ APT repository; instead, we want to download the Debian package and manually install it, as follows:

$ wget http://www.rabbitmq.com/releases/rabbitmq-server/v3.2.1/rabbitmq-server_3.2.1-1_all.deb
$ sudo dpkg -i rabbitmq-server_3.2.1-1_all.deb
$ sudo apt-get -f --force-yes --yes install

In case you wonder why we first ran the dkpg software followed by the apt-get command, the reason is simple: the first attempt expectedly fails because none of the Erlang dependencies are present in our system. This failure generates a list of unresolved dependencies that the apt-get command picks up and installs, including the installation of the RabbitMQ broker.

We can verify that the RabbitMQ broker is actually working using the standard service command:

$ sudo service rabbitmq-server status
Status of node 'rabbit@ip-172-31-31-18' ...
[{pid,4027},
 {running_applications,[{rabbit,"RabbitMQ","3.2.1"},
                        {mnesia,"MNESIA  CXC 138 12","4.5"},
                        {os_mon,"CPO  CXC 138 46","2.2.7"},
                        {xmerl,"XML parser","1.2.10"},
                        {sasl,"SASL  CXC 138 11","2.1.10"},
                        {stdlib,"ERTS  CXC 138 10","1.17.5"},
                        {kernel,"ERTS  CXC 138 10","2.14.5"}]},
 {os,{unix,linux}},
 {erlang_version,"Erlang R14B04 (erts-5.8.5) [source] [64-bit] [rq:1] [async-threads:30] [kernel-poll:true]\n"},
 {memory,[{total,27085496},
          {connection_procs,2648},
          {queue_procs,5296},
          {plugins,0},
          {other_proc,9040296},
          {mnesia,57776},
          {mgmt_db,0},
          {msg_index,25768},
          {other_ets,752416},
          {binary,1952},
          {code,14546600},
          {atom,1360921},
          {other_system,1291823}]},
 {vm_memory_high_watermark,0.4},
 {vm_memory_limit,247537664},
 {disk_free_limit,50000000},
 {disk_free,7020503040},
 {file_descriptors,[{total_limit,924},
                    {total_used,3},
                    {sockets_limit,829},
                    {sockets_used,1}]},
 {processes,[{limit,1048576},{used,122}]},
 {run_queue,0},
 {uptime,73}]
...done.

If you're wondering what format is used to represent the server status information, it's not JSON but in fact, Erlang lists and tuples. You can notice how the status data contains a lot of contextual information about RabbitMQ and the Erlang VM.

If you take a look at the running processes for RabbitMQ, you'll find both the service wrapper and the Erlang virtual machine (also known as BEAM) running as follows:

$ pgrep -fl rabbitmq
3633 /bin/sh /usr/sbin/rabbitmq-server
3647 /usr/lib/erlang/erts-5.8.5/bin/beam.smp -W w -K true -A30 -P 1048576 -- -root /usr/lib/erlang -progname erl -- -home /var/lib/rabbitmq -- -pa /usr/lib/rabbitmq/lib/rabbitmq_server-3.1.5/sbin/../ebin -noshell -noinput -s rabbit boot -sname rabbit@pegasus -boot start_sasl -config /etc/rabbitmq/rabbitmq -kernel inet_default_connect_options [{nodelay,true}] -sasl errlog_type error -sasl sasl_error_logger false -rabbit error_logger {file,"/var/log/rabbitmq/[email protected]"} -rabbit sasl_error_logger {file,"/var/log/rabbitmq/[email protected]"} -rabbit enabled_plugins_file "/etc/rabbitmq/enabled_plugins" -rabbit plugins_dir "/usr/lib/rabbitmq/lib/rabbitmq_server-3.1.5/sbin/../plugins" -rabbit plugins_expand_dir "/var/lib/rabbitmq/mnesia/rabbit@pegasus-plugins-expand" -os_mon start_cpu_sup false -os_mon start_disksup false -os_mon start_memsup false -mnesia dir "/var/lib/rabbitmq/mnesia/rabbit@pegasus"

Note that by default, the broker service is configured to auto-start when the Linux host starts. You can confirm and configure this via a tool called rcconf as shown in the following screenshot:

The RabbitMQ server service auto-starts by default

By default, RabbitMQ does not embed a web-based management console but offers it as an optional plugin. This management console makes it very easy to peek into a running RabbitMQ instance, so we definitely want to have it installed from the get go.

The Debian package has installed several scripts, one of them being rabbitmq-plugins, whose purpose is to allow the installation and removal of plugins. Let's use it to install the management plugin as follows:

$ sudo rabbitmq-plugins enable rabbitmq_management
The following plugins have been enabled:
  mochiweb
  webmachine
  rabbitmq_web_dispatch
  amqp_client
  rabbitmq_management_agent
  rabbitmq_management
Plugin configuration has changed. Restart RabbitMQ for changes to take effect.

Yes, it is that easy! As invited by the installer, we need to restart RabbitMQ as follows:

$ sudo service rabbitmq-server restart
* Restarting message broker rabbitmq-server        [ OK ]

Using our favorite web browser, we can now reach the home page of the management console by navigating to http://<hostname>:15672 as shown in the following screenshot:

The login screen of the management console

So, what Username and Password can we use to log in to the console? None yet, but we're going to to have a remedy for that too!

One of the scripts installed by the Debian package is rabbitmqctl, which is the RabbitMQ broker control script. It is of paramount importance as it is used to configure all aspects of the broker. We will now use it to configure an administration user in the broker as follows:

$ sudo rabbitmqctl add_user ccm-admin hare123
Creating user "ccm-admin" ...
...done.

$ sudo rabbitmqctl set_user_tags ccm-admin administrator
Setting tags for user "ccm-admin" to [administrator] ...
...done.

By navigating back to the management console login screen, we are now able to log in with ccm-admin and hare123. We are welcomed by this overview of the broker's internals, as shown in the following screenshot:

The main dashboard of the management console

Note that at this point, the ccm-admin user is not able to introspect any exchange or queue in any virtual host. We will address this issue in a moment. But for now, we need another user for development purposes so that our applications can connect to RabbitMQ. So, let's create the ccm-dev user as follows:

$ sudo rabbitmqctl add_user ccm-dev coney123
Creating user "ccm-dev" ...
..done.

As discussed earlier in this chapter, RabbitMQ supports the notion of virtual hosts, which are logical subdivisions of its execution space. We're going to create a virtual host, also known as vhost, for the development environment. So, anything that happens in it happens in isolation from any other environments we can create in the future (such as a QA environment). So, let's create a vhost named ccm-dev-vhost as follows:

$ sudo rabbitmqctl add_vhost ccm-dev-vhost
Creating vhost "ccm-dev-vhost" ...
..done.

As it currently is, neither the ccm-admin nor ccm-dev users have permission to do anything on ccm-dev-vhost. Let's fix this by giving the vhost full rights on it as follows:

$ sudo rabbitmqctl set_permissions -p ccm-dev-vhost ccm-admin ".*" ".*" ".*"
Setting permissions for user "ccm-admin" in vhost "ccm-dev-vhost"
...done.

$ sudo rabbitmqctl set_permissions -p ccm-dev-vhost ccm-dev ".*" ".*" ".*"
Setting permissions for user "ccm-dev" in vhost "ccm-dev-vhost"
...done.

What have we just done? Most of the command is straightforward but the ".*" ".*" ".*" part looks a tad mysterious, so let's analyze it. It is a triplet of permissions for the considered vhost that respectively grant configure, write, and read permissions on the designated resources for the considered user and vhost. Resources, which consist of exchanges and queues, are designated by regular expressions that match their names. Thus, in our case, we are allowing any resource via the .* regular expression.

The actual commands that are granted depend on the resource type and the granted permissions. The reader can get a complete list of the access control policies supported by RabbitMQ at http://www.rabbitmq.com/access-control.html.

As an alternative to all command lines, you can also turn to the user management features of the management console. If you click on the Admin tab of the console and then on the ccm-dev user listed in the Users tab, you'll see what's shown in the following screenshot. The entire user configuration you've set from the command line is visible and editable in the management console.

Details of an individual user in the management console