How to deploy the admin-ui as a Cloud Foundry application and improve its performances
At SAP we use the open source project “admin-ui” dashboard to help Cloud Foundry operators find useful Cloud Foundry data without needing manual connections to the database.
The admin-ui was initially deployed in a dedicated virtual machine, but we decided to migrate it to a simpler environment where less effort is required to perform lifecycle operations.
While it may not be typical to deploy an “administration dashboard” on the platform you want to “administrate,” in our use case, the application is not crucial for the platform. Its role is to help operators find information more quickly.
The challenge was to wrap the admin-ui in a way that enabled us to specify all relevant configuration parameters in the Cloud Foundry application manifest. The solution? Override the default start command of the application with a shell script that reads the configuration from the environment variables in the container and writes them to a file before the app gets started.
Some security-groups and an uaa-client are also necessary to allow the application to connect to Cloud Foundry internal endpoint. By default, all connections to underlying platform components are not permitted.
After we figured out how to deploy the application, our second challenge was the performance. The application subscribes to the Firehose endpoint in Cloud Foundry to receive information about the status of the platform, but at the time of writing, Firehose does not allow granular filters on the data request. As a result, the admin-ui receives an extraordinary amount of information that is not necessary and therefore is dropped.
Depending on the load of the platform, this can make the admin-ui unusable, with tens of seconds before each reaction to a user’s request. Luckily, it is now easy to develop another application and put it between Firehose and admin-ui to filter all unnecessary data before it reaches its final destination. We called it “admin-ui-nozzle.”
You can try the nozzle here – but please note we publish it with no warranty, so use it at your own risk!
The results were satisfying, as the amount of data filtered has an average of 95 percentage in productive systems. The time the operator needs to wait to load the admin-ui has been cut in half.
The best solution is to have a filter implemented in the nozzle that sends only the requested data, but until the feature is implemented on Loggregator, we will probably stick with our solution.
The takeaway from this little project is that even if an application was not designed to be deployed on a PaaS, it might still pay to do it in terms of lifecycle operations and flexibility while integrating the application into a wider picture.
To get more insight on the topic, you can look at the slides and video of the related talk at Cloud Foundry Summit Silicon Valley 2017.
