Skip to Content

RabbitMQ: How to access the Web UI in Cloud Foundry

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

 

 

 

6 Comments
You must be Logged on to comment or reply to a post.
  • 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

    • 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

  • Hi Ivan,

    I’ve tried your suggested method (using the proxy made in NodeJS) and modfiyng it according to my needs.

    The bind is succefull but, unfortunately, the application fails to start.

    Is there any tip you can provide (or just send your modified version)?

    Thanks for your help.

    Luigi

     

    • Hi Luigi,

      You could retrieve the application logs to figure out what went wrong during startup with the following CLI command:

      cf logs rabbitmqProxy --recent

      If you don’t have the CLI installed (I highly recommend you to do it) – then you can inspect the logs by opening the application link on the cockpit and clicking on the menu “Logs”.

      I prefer CLI because it displays the logs in color – where I can focus on the errors in red.

      You will want to take a look at lines with messages of Category “STDERR”. Those should give you a pretty good idea of what went wrong.

      In addition to that I’d say you need to pay attention to a few things:

      • The original code will try to parse the VCAP variable – which is not required. Plus, you need to make sure to use the correct name of the service instance. SAP’s CF implementation will have a VCAP service name as “rabbitmq” instead of the instance name you’ve chosen on your yaml file.
      • The service dependency stated in the “manifest.yml” file needs to reflect the RabbitMQ instance name you’ve created using either the cockpit of the ‘cf’ CLI.
      • As previously stated the original code will process the VCAP variable differently. Since there is no Management URI variable, you need to replace it with the port name assigned to it – the standard management port name is “15672/tcp” which will translate into the tcp port that has been assigned to the RabbitMQ service instance.

      I didn’t change anything in the original code other than the two line mentioned and documented on the blog. When I’ve created the service instance, I’ve used version 3.7-dev plan and given the same name used in the original manifest.yml (just for simplicity) – which is “rabbitmq-ent”.

      I’ve also recommend you to take a look at the application’s environment variables to inspect the VCAP_SERVICES and see how it differs from the one the original code expects. To do it, just open the cockpit and select your application from the list. Then click on the menu “Environment Variables”. VCAP_SERVICES will be listed as ‘System-Provided’.

      Hope this helps. If not, please post the error log here.

      Best regards,

      Ivan

       

  • Hi Ivan,

    I have tried the proxy sample you have shared.
    After trying a few approach, I am able to access to the rabbit management console by using port:”15672″ instead of port “15672/tcp” as shown in this article.
    I realized that My Rabbit Dashboard does not have the list of exposed port as shown in your screenshot above. Shouldn’t the exposed port be the same across all RabbitMQ Dashboard? Are you using trial environment?
    For port “15672/tcp”, the app will have error: 502 Bad Gateway: Registered endpoint failed to handle the request. (This is expected because my Rabbit does not have the ‘15672/tcp’ exposed)
    Regards,
    Hoong Jun
    • I have just tested the same procedure on eu10 trial landscape (Frankfurt) and it works with the exposed port being 15672/tcp. I’m not sure why, in your case, it doesn’t expose the ports. Maybe you should open a support ticket on SAP’s support system.