Creating a BOSH Release for Admin UI, a Monitoring Tool for Cloud Foundry

by Alexander LomovNovember 6, 2014
BOSH releases help to achieve high availability. Learn how to create a BOSH release for a new version of Admin UI.

Some Cloud Foundry components must be available, even if Router fails. Admin UI, a monitoring tool from the Cloud Foundry incubator, is a good example of a utility that you want to have access to no matter what. Getting updates directly from the NATS messaging bus, it gives admins access to CF components, their logs, statistics on DEAs and applications deployed to them, user rights, and other things not available in the Cloud Foundry CLI.

BOSH releases help to achieve high availability by installing important components outside the main CF deployment. By doing so, you can avoid exposing them with Router or deploying them as apps. In addition, they provide the easiest way to bind Cloud Foundry components and custom services.

In this post, I share my experience with creating a BOSH release (not yet available at the time this was published) for a new version of Admin UI. I also provide a temporary workaround for those who need to deploy Admin UI now and cannot wait for the next BOSH release.


The need to update the BOSH release

Not so long ago, one of our customers needed to add localization to the latest version of Admin Ul. After we had finished translating the app, we created a pull request to the official Admin UI branch and decided to use the Admin UI BOSH release to deploy our changes. However, soon we discovered that it does not support the latest version that we used. In addition, the developer introduced a number of changes that made it hard to update the BOSH release. For example:

  • To increase performance, Admin UI now looks directly into CC and UAA databases. This requires building gems with native extensions for PostgreSQL, MySQL, and SQLite (version 3).

  • In the latest version, authentication is performed through UAA. So you need to use your CF credentials to log in.


Making the BOSH release work

To update Admin UI in a BOSH release, we created a pull request. Since Admin UI started to use sequel_pg that required the pg gem, which—in its turn—needed libpq-dev installed, I decided to take it from this BOSH release (as suggested by @cppforlife). Soon after that, @rkoster added another pull request based on mine. His changes involved using errand jobs to register Admin UI in UAA.

Still, the main challenge I faced when creating this BOSH release was the hooks that run on your computer before the release is uploaded and built in BOSH. The issue was in the pre_packaging script that executed the bundle package to save gems in the vendor/cache folder. Although the bundle package saved the gems normally on my OS X Mavericks, BOSH failed to compile them on Ubuntu because of native extensions. This is partly a Bundler issue and there is a feature request for it and lots of discussions (e.g., #1, #2, #3, etc.). I also created a discussion in the bosh-dev google group with a description of this error, because I think using a pre_packaging script in this form is a not the best idea. I also created a pull request to get rid of it in the Admin UI BOSH release for now.


An alternative way to deploy Admin UI

Currently, the Admin UI BOSH release v4 is not available on the S3 cloudfoundry-community blobstore, but it will be soon. For now, I created an alternative way to deploy it.

You will need to use the Altoros/admin-ui-boshrelease repo with the i18n branch, that has ready-to-use blobs in the blobs folder and an updated src/admin_ui submodule for the latest Admin UI version with i18n. You can use the script below to upload and deploy the release:

# download Admin UI BOSH release:
git clone -b i18n && cd admin-ui-boshrelease
git submodule init
git submodule update
# create and deploy Admin UI BOSH release:
bosh create release --force
bosh upload release <path-to-release-manifest.yml>     # the last line from an output of the last command
bosh -n deploy
bosh run errand register_admin_ui

The errand job registers Admin UI in UAA and you will be able to use your CF admin credentials to log into AdminUI. This is the only authentication method in the new AdminUI. You can find the scripts that can register Admin UI in UAA in admin-ui README or the errand job script. Note that if you compile manifests with Spiff you can use this template: admin-ui-deployment.yml.

Now you should be able to get your highly available Admin UI up and running. As you can see from this case, despite being relatively new, BOSH is a powerful utility. It also provides many useful non-trivial solutions. In addition, it has a friendly community that you can always rely on when looking for answers in google groups or forums. If you have any questions about this blog post, feel free to leave a comment below.


Further reading