Blog

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

Alexander Lomov

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 with a BOSH release

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 https://github.com/allomov/admin-ui-boshrelease.git && 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.

 
Related post:

23 Comments
  • Sekhar Hari

    Hey – Thanks for sharing this. I am going to try it now. But just wondering, what will be the URL (an example would suffice) that I should use to access the admin-ui after deploying the way you wrote.

    Thanks,
    Sekhar H.

    • Alexandr Lomov

      Hi, Sekhar,

      Currently we are using admin-ui as an internal tool that is accessed through the internal DNS (we can use any domain in this case, an example URL can be http://admin-ui.cf-utils.altoros.com). You can also access admin-ui through IP.

      Feel free to join the discussion on this topic in this pull request: https://github.com/cloudfoundry-incubator/admin-ui/issues/123

      • Sekhar Hari

        Thanks, Alexandr.

        May be you have seen this error before, and can point me in the right direction. When I deploy, I get the error – Error 190012: Can’t find template `register_admin_ui’: Please see below for details. I used the “make_manifest” script to generate the deployment manifest.

        Deploying

        ———

        Deployment name: `admin-ui.local.yml’

        Director name: `microbosh-openstack’

        Director task 221

        Started preparing deployment

        Started preparing deployment > Binding deployment. Done (00:00:00)

        Started preparing deployment > Binding releases. Done (00:00:00)

        Started preparing deployment > Binding existing deployment. Done (00:00:00)

        Started preparing deployment > Binding resource pools. Done (00:00:00)

        Started preparing deployment > Binding stemcells. Done (00:00:00)

        Started preparing deployment > Binding templates. Failed: Can’t find template `register_admin_ui’ (00:00:00)

        Error 190012: Can’t find template `register_admin_ui’

        Task 221 error

        ————————————————————————————————————————————–

        Manifest:

        =======

        compilation:

        cloud_properties:

        instance_type: m1.small

        network: cf1

        reuse_compilation_vms: true

        workers: 2

        director_uuid: 4d577e21-1d96-45b4-b335-04703a9d7a21

        jobs:

        – instances: 1

        name: admin_ui

        networks:

        – name: cf1

        static_ips: 10.154.0.20

        persistent_disk: 5120

        resource_pool: xsmall_z1

        template: admin_ui

        – instances: 1

        lifecycle: errand

        name: register_admin_ui

        networks:

        – name: cf1

        resource_pool: xsmall_z1

        template: register_admin_ui

        – instances: 1

        lifecycle: errand

        name: deregister_admin_ui

        networks:

        – name: cf1

        resource_pool: xsmall_z1

        template: deregister_admin_ui

        meta:

        admin_ui_uaa_client:

        id: admin-ui

        secret: c1oudc0w

        network: cf1

        subdomain: admin

        name: admin-ui

        networks:

        – name: cf1

        subnets:

        – cloud_properties:

        net_id: 255db713-7ddc-4588-ab99-ef449b1c3a2a

        security_groups:

        – default

        – bosh

        – cf-private

        – cf-public

        – ssh

        – cf

        gateway: 10.154.0.1

        range: 10.154.0.0/24

        static:

        – 10.154.0.2 – 10.154.0.60

        type: manual

        properties:

        admin_ui:

        admins:

        – admin

        ccdb:

        address: 10.154.0.7

        database: ccdb

        password: c1oudc0w

        port: 5524

        scheme: postgres

        username: ccadmin

        cloud_controller_ssl_verify_none: true

        cloud_controller_uri: http://api.10.154.0.18.xip.io

        uaa:

        admin_client_secret: c1oudc0w

        client:

        id: admin-ui

        secret: c1oudc0w

        scopes:

        admin: null

        user: null

        url: http://uaa.10.154.0.18.xip.io

        uaadb:

        address: 10.154.0.7

        database: uaadb

        password: c1oudc0w

        port: 5524

        scheme: postgres

        username: uaaadmin

        uri: admin.10.154.0.18.xip.io

        users: null

        cc:

        srv_api_uri: http://api.10.154.0.18.xip.io

        databases:

        address: 10.154.0.7

        db_scheme: postgres

        port: 5524

        roles:

        – name: ccadmin

        password: c1oudc0w

        tag: admin

        – name: uaaadmin

        password: c1oudc0w

        tag: admin

        nats:

        address: 10.154.0.2

        password: c1oudc0w

        port: 4222

        user: nats

        networks:

        apps: cf1

        ssl:

        skip_cert_verify: true

        system_domain: 10.154.0.18.xip.io

        uaa:

        admin:

        client_secret: c1oudc0w

        url: http://uaa.10.154.0.18.xip.io

        release:

        name: admin-ui

        version: latest

        resource_pools:

        – cloud_properties:

        instance_type: m1.xsmall

        name: xsmall_z1

        network: cf1

        size: 3

        stemcell:

        name: bosh-openstack-kvm-ubuntu-trusty-go_agent

        version: 2719.3

        update:

        canaries: 1

        canary_watch_time: 30000-600000

        max_in_flight: 1

        serial: true

        update_watch_time: 5000-600000

        • Alexandr Lomov

          Hey again!

          My bad. I’ve run the script that errand job does manually, so I didn’t include errand job in my manifest. You should add to your manifest the errand job definition, like is done here: https://github.com/Altoros/admin-ui-boshrelease/blob/master/templates/admin-ui-deployment.yml#L35-L41

          Quick tip: next time use https://gist.github.com/ to share manifest, it will save lay out and add suitable mark up.

          • Sekhar Hari

            That is defined in my manifest, already. Please see below the snippet from my manifest:

            instances: 1
            lifecycle: errand
            name: register_admin_ui
            networks:
            – name: cf1
            resource_pool: xsmall_z1
            template: register_admin_ui

            The situation is the same for ‘deregister_admin_ui’ also. Any further thoughts?

            Thanks,
            Sekhar H.

          • Alexandr Lomov

            Today will try to run it with CF v192. Will write you about result.

          • Sekhar Hari

            Thanks. Awaiting for the results. BTW, I am using CF189. However, not sure why BOSH complaints about “can’t find register_admin_ui template”.

            Cheers,
            Sekhar H.

          • Alexandr Lomov

            Hey again, Sekhar.

            Today I’ve tried out to deploy admin-ui v192. Here you can find a gist with script I run [1]. Pay attention that I use my own fork of admin-ui boshrelease there [2] , branch called i18n. Since I’ve deployed CF with bosh-bootstrap [3] to get fast result I didn’t generated cf manifest with spiff. Here you can see diff [4] with changes I needed to perform to initial CF manifest.

            After I redeployed admin-ui I didn’t have any errors with running `bosh run errand register_admin_ui`. The only one thing I’ve found out that I need to register admin into admin_ui scope manually [5].

            Possible solution in your case is to try to redeploy admin ui together with CF or run uaa registration manually with uaac [6].

            Please write here how you did cope with the problem. And have a good day.

            [1] https://gist.github.com/allomov/64a88eaac8e26b77a481
            [2] https://gist.github.com/allomov/64a88eaac8e26b77a481#file-add-admin-ui-sh-L1
            [3] https://github.com/cloudfoundry-community/bosh-bootstrap
            [4] https://gist.github.com/allomov/64a88eaac8e26b77a481#file-manifest-diff
            [5] https://gist.github.com/allomov/64a88eaac8e26b77a481#file-add-admin-ui-sh-L16-L18
            [6] https://github.com/cloudfoundry-incubator/admin-ui#running-with-bosh-lite-cloudfoundry

          • Alexandr Lomov

            Also could you re-share your manifest with gist. I suppose I could miss something because of the broken layout. Thank you.

  • Sekhar Hari

    Hello there – Sorry, I was away from this particular work; and got a chance yesterday to re-look at this. I could deploy the admin-ui successfully now. Everything in it works well. Many thanks for making this release available through BOSH, and assisting me in my questions. You have a good day, and weekend.

    Cheers,
    Sekhar H.

  • V Kumar

    I also tried deploying bosh release for Admin UI, i am getting error as “Can only target Bosh Lite Director. Please use ‘bosh target’ before running this script”.I found EXPECTED_DIRECTOR_NAME=”Bosh Lite Director” in make_manifest.Is AdminUI is supported in only bosh lite ?I am using bosh to install cloud foundry.

    • Alexandr Lomov

      In common case using warden infrastructure implies that you run manifest generator for bosh-lite [1]. If you set you bosh target to your bosh-lite deployment, the manifest will be generated automatically using information fetched from bosh-director of bosh-lite about cf deployment.

      This is done to ease deployment of admin-ui to bosh-lite. Otherwise you’ll need to provide cf deployment amnifests and stub as it done for other infrastructures. In case you don’t want to set target to your bosh-lite deployment, you can run this steps manually [2].

      [1] https://github.com/cloudfoundry-community/admin-ui-boshrelease/blob/7bee4d869cbdd62ab226310713acf8c58fcaef04/make_manifest#L17

      [2] https://github.com/cloudfoundry-community/admin-ui-boshrelease/blob/7bee4d869cbdd62ab226310713acf8c58fcaef04/make_manifest#L27-L40

      • V Kumar

        Thanks Alexandr for quick reply.Now i am wrting my own manifest file.I found two link.
        https://github.com/cloudfoundry-community/admin-ui-boshrelease

        https://github.com/cloudfoundry-incubator/admin-ui

        I need some clarification on above two link First one is bosh release and i am using it for bosh release.I want to know about second link.What is second one.Why does second one do.Do we need to configure both ?Please explain.

        • Alexandr Lomov

          The thing here is that bosh release works as a package that contains source code for an application and information about how it should be built and run. The first link is bosh release that you provide to your BOSH, the second one contains source code of admin-ui that are stored in admin-ui-boshrelease in src folder [1] (as git submodule). The application you find on the second link can be installed and run without bosh just by providing valid configuration, still bosh can be used to deploy and configure it easily.

          Hope I answered your question.

          [1] https://github.com/cloudfoundry-community/admin-ui-boshrelease/tree/master/src

          • V Kumar

            Thanks Yes is answered my question.I have couple of more question.
            1) I have cloud foundry deployment with deployment name “cf-devtest2”.admin ui deployment name should be different or i should use same deployment as CF deployment i.e cf-devtest2 ?
            2)Cloud foundry and admin ui will be there in Linux machine and I am planning to access admin ui from my windows.how can i access.I mean what url i should use.where to configure this url.

          • Alexandr Lomov

            1. It depends. In casual case I would suggest to include admin-ui release in the same deployment with CF (upload admin-ui release, add reference to it to manifest and add job with admin-ui template from admin-ui release). This will allow to avoid mess. You can also create a new deployment from scratch, with different name and deploy admin-ui there.

            2. you can find some discussion on how to expose admin-ui in comments to this article [1].

            [1] http://blog.altoros.com/cloud-foundry-monitoring-admin-ui-overview.html

          • V Kumar

            Thanks Alexadr for your input.It would good if you share admin-ui-deployment.yml file with value.

          • V Kumar

            Hi Alexandr now i am able to succesfuly deploy admin Ui bosh release. my uri in config.yml is http://admin.devtest2.io. when i do “curl http://admin.devtest2.io” says curl: (6) Could not resolve host: admin.devtest2.io.

            sudo netstat -nlp | grep 8070

            [sudo] password for vcap:

            tcp 0 0 0.0.0.0:8070 0.0.0.0:* LISTEN 5260/ruby

            Please help me access admin ui

          • V Kumar

            My bosh vm for admin ui is two ip address private ip 10.20.0.218 and floating ip (public)128.107.34.124.When i run wget -S http://10.20.0.218:8070 or wget -S http://1128.107.34.124:8070 from the network 10.20.0.x i am getting response.

            when do wget -S http://1128.107.34.124:8070 from outyside network i amgetting following error.let me know what is wrong here

            Location: http://uaa.devtest1.io/oauth/authorize?response_type=code&client_id=admin_ui_client&redirect_uri=http://128.107.34.124:8070/login [following]

            –2016-01-15 04:16:06– http://uaa.devtest1.io/oauth/authorize?response_type=code&client_id=admin_ui_client&redirect_uri=http://128.107.34.124:8070/login

            Resolving uaa.devtest1.io (uaa.devtest1.io)… failed: Name or service not known.

            wget: unable to resolve host address ‘uaa.devtest1.io’

          • V Kumar

            My bosh vm for admin ui is two ip address private ip 10.20.0.218 and floating ip (public)128.107.34.124.When i run wget -S http://10.20.0.218:8070 or wget -S http://1128.107.34.124:8070 from the network 10.20.0.x i am getting response.

            when do wget -S http://1128.107.34.124:8070 from outyside network i amgetting following error.let me know what is wrong here

            Location: http://uaa.devtest1.io/oauth/authorize?response_type=code&client_id=admin_ui_client&redirect_uri=http://128.107.34.124:8070/login [following]

            –2016-01-15 04:16:06– http://uaa.devtest1.io/oauth/authorize?response_type=code&client_id=admin_ui_client&redirect_uri=http://128.107.34.124:8070/login

            Resolving uaa.devtest1.io (uaa.devtest1.io)… failed: Name or service not known.

            wget: unable to resolve host address ‘uaa.devtest1.io’

  • V Kumar

    I am able to see only admin-ui log in browser.Is there any way to get logs of cloud controller,haproxy and other service in cloud foudnry deployment in browser.i tried this log_files: [/var/vcap/sys/log/cloud_controller_ng/*.log,/var/vcap/sys/log/admin_ui/admin_ui.log] .it is not showing cloud controller logs.It seems it works when logs available locally in admin ui vm. how can admin_ui fetches logs from cloud controller and show it browser ?

    • Alexandr Lomov

      Hey, V Kumar.

      Sorry for delay in response and thank you for your question. We used ELK bundle to fetch logs of all CF components. You can find releases for it here [1, 2]. In the same time, in theory, you can get all logs on you VM with admin-ui using syslog, but be careful with this solution (setup log rotation and etc.).

      [1] https://github.com/logsearch/logsearch-boshrelease
      [2] https://github.com/logsearch/logsearch-for-cloudfoundry

  • V Kumar

    I am trying open route for admin_ui in haproxy.

    My app is running as bosh vm and have opened a route in haproxy. I am trying to access https://myappexample.com/adminui. I am getting Page Not found.
    Please see the curl output result.

    curl https://myappexample.com/adminui

    > Host: myappexample.com

    > Accept: */*

    >

    GET / HTTP/1.1

    > User-Agent: curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3

    > Host: admin.devtest3.io

    haproxy.config

    frontend http-in

    acl adminui path_beg /adminui

    frontend https-in

    acl adminui path_beg /adminui

    backend bk_adminui

    mode http

    http-request set-header Host admin.devtest3.io

    reqirep ^([^ :]*) /(.*)$ 1 /2

    balance roundrobin

    server node0 0.router.ccc-bosh-net.cf-devtest3.microbosh:80 check inter 1000

    server node1 1.router.ccc-bosh-net.cf-devtest3.microbosh:80 check inter 1000

    > Accept: */*

    >

    < HTTP/1.1 303 See Other

Benchmarks and Research

Subscribe to new posts

Get new posts right in your inbox!