Skip to Content

The challenge

RabbitMQ is a well know message broker that you can use to implement resilience for micro-services in cloud foundry. If you look at the documentation, there are several tools that will aid you to either monitor, troubleshoot or even interact(API) with the RabbitMQ. Such features are called plugins.

I was particularly interested on the Management plugin. According to the documentation, this is a feature that can be accessed with by pointing a browser to the host name and the default port (15672/tcp). With that I should be able to see a RabbitMQ Cockpit full of statistics about Connections, Channels, Queues and much more.

However, when we are dealing with an instance of RabbitMQ on Cloud Foundry we don’t have direct access to the IP address. Therefore we need to somehow proxy the request from a publicly available URL application to the internal ports of MQ in order to call the management Web UI.

I was hopping the RabbitMQ instance “actions” in the cockpit would give me the access that I needed. But, instead it opened the “service fabrik-broker” page – which is basically a list of very useful information on the instance that is running – including the ports I was interested on. But no way of accessing it indirectly.

Of course I could just open an ssh tunnel with CF CLI and open the port directly via localhost. However, in order to do it I would need to deploy an application anyway. But this approach seemed to me a little complex (not difficult). Plus I didn’t want to keep checking for a tunnel availability whenever I wanted to check on my RabbitMQ instance. I would make more sense to have an application that would deal with the whole thing for me, just as if the instance was running locally.

Solution

While researching this I came across a proxy made in NodeJS which I could adapt to work on SAP’s CF. It is basically a generic HTTP proxy but it fitted my needs. I followed the readme.md file, changed the manifest.yml file to reflect my trial instance. However, the VCAP_SERVICES is not formatted quite the same. On the git repository the author uses a VCAP_SERVICES that already contains a separate session for managament URI that contains the complete URI I need to forward requests to.

With little effort I changed the following lines of code and I was able to run it:

...
const serviceUrl = vcapServices.rabbitmq[0].credentials;
const address = {
  host: serviceUrl.hostname,
  port: serviceUrl.ports["15672/tcp"],
};
...

 

I was very glad that the dev instance of RabbitMQ already comes with the plugin I was interested on.

Once you deploy the application in CF it should bind itself to the RabbitMQ instance (if you changed the yml file accordingly).

 

Logging into the RabbitMQ Web UI

Once you open the application URL, you should be presented with the following login screen.

To be able to login, you have to look into the VCAP_SERVICE variable to retrieve the username and password. You can look it up on the cockpit by opening the application environment variables, like so:

Or you could inspect the variable with CF CLI:

# cf env <application_name>

The output should be something like this:

 

Result

 

I think this might help others to troubleshoot issues with this excellent message broker.

You can also access other endpoints, such as ‘/api’:

 

Enjoy,

Ivan

 

 

 

To report this post you need to login first.

2 Comments

You must be Logged on to comment or reply to a post.

  1. Wolfgang Röckelein

    Hi Ivan,

    thanks for your helpful blog.

    Shouldn’t it also possible to utilize the app-router (which will be included in a lot CF deployments anyway) for this management plugin access?

    Regards,

    Wolfgang

    (0) 
    1. Ivan Mirisola Post author

      Hi Wolfgang,

      I bet there is a way to use the app router to do just that. You are correct.

      The way I see it, the monitoring access could faced two ways: it could permanent or temporary (during development). If you are looking into a more permanent way the AppRouter would be a better choice – for security reasons. If all you really need is a simple way to access it than this procedure would be much faster and simpler to deploy.

      IMHO the management access of such backing services should be provided by SAP via Cockpit and not by mechanisms such as those mentioned here.

      Best regards,
      Ivan

      (0) 

Leave a Reply