Running dashing in a Windows Azure environment

At my current workplace we love hosting our apps and services up on Windows Azure. It’s a great thing, worry-free redundancy and backups, lots of cool features to take advantage of like availability sets and traffic management, etc. etc. But as a tinkerer it goes a little against my grain; I’m used to grabbing an old laptop, firing up a local virtual machine, or pulling out my trusty Raspberry Pi when I want to try something out or fiddle with an idea.

So changing my approach to leveraging Azure services is a little bit of a challenge. I’ve only been working in Azure for about three months now, and while I’m much more used to it than I was there are still times when the disparity between the old and new management portals get me, or when I can’t remember if such a setting was on the cloud service or the instance.

Every chance to set something new up comes with the opportunity to get better though. This week I introduced dashing to my team. I’d been manually monitoring the effects of some regularly timed jobs for a few days by running a couple of SQL scripts and I decided that now was as good a time as any to stretch my Ruby legs and build something we could use for the future. Point worth mentioning: if you’re a not a Ruby developer and have never touched Ruby, it really isn’t that hard. The examples that come with dashing really are great, and you can base most of what you want off of them.

Getting it up and running in Azure is a little more challenging though. I had to scrape through a few tutorials and forum posts to figure out the right approach to do it right, so here’s what I did.

Creating a Linux VM

First, I needed the set up a system that could run Ruby.  As I mentioned, ideally I’d have liked to do it on my Raspberry Pi, so with that in mind a Linux environment seemed the natural way to go (not to mention most tutorials for open source software tend to use the bash shell anyway). The easy way to find one was to use Azure’s Marketplace and search for “ubuntu”, which resulted in a list of suitable virtual machines. I went with Ubuntu 14.04 LTS for this install.

azure_ubuntusearch

Fig. 1: Ubuntu virtual machines in Azure’s marketplace

The next blade presented options for configuring the VM before it was provisioned.  An A0 instance was fine, especially as I didn’t intend to be hosting anything else on the same machine. It took a while to find the right one though, if that’s what you’re going for make sure to keep scrolling through the list of instances until you find what you’re looking for. Microsoft has buried the cheaper options quite far down and it takes a moment’s searching to find them.

Fig 2. Selecting the type of instance

Fig 2. Selecting the type of instance

Setting up the environment

Once Azure had provisioned the new machine, I was able to connect to it through SSH using everyone’s favourite tool, PuTTY. Once in, I could install Ruby with the following commands:

sudo apt-get update
sudo apt-get install ruby1.9.1 ruby1.9.1-dev build-essential libsqlite3-dev nodejs

Dashing also makes use of bundler, allowing you to specify inside the Gemfile which gems are needed to run your dashboard. With Ruby now installed, I could make use of the Gem command to install both it and dashing:

sudo gem install bundler
sudo gem install dashing

As we’re primarily a .NET shop, the dashboard I was seeking to host needed to be able to connect to Microsoft SQL Server to query some of our transactional data. To manage this I discovered the awesome tiny_tds library, which also comes as a Ruby gem, but my attempt to install was thwarted by an error message that I didn’t experience when setting it up in my local development environment:

ERROR: Error installing tiny_tds:
       ERROR: Failed to build gem native extension.

       /usr/bin/ruby1.9.1 extconf.rb

Some research on the matter seemed to point to needing freetds (which is something seen further down the exception trace mentioned above), so I installed it using apt-get, after which I was able to install tiny_tds:

sudo apt-get install freetds-dev
sudo gem install tiny_tds

At this point I could upload my dashing project and start running it. As I did all my work locally all I had to do was connect with Filezilla via SFTP and choose a location on the filesystem to which I uploaded the contents of my dashing project. If you don’t have an existing project, or are seeking to build it direct on the server, be sure to take a look at the dashing’s getting started for more info.

After the upload completed, I was able to install the dependencies with bundle and start it in daemon mode:

bundle install
dashing start -d

This, though, is not quite the end of the story. Azure does not provide any default port mappings other than SSH, so it was necessary to configure a port to point at the running dashing instance. By default dashing will run it’s server on port 3030, so you can choose to open the same port or you can map HTTP port 80 to it, which is what I did. You can go further and protect your data by way of HTTPS, or by locking down the Access Control List (ACL) on the virtual machine.

Fig 3. Configure the HTTP endpoint

Fig 3. Configure the HTTP endpoint

After all that, I was done. I was able to enter in the cloudapp.net address Azure provided for the VM in my browser and check out my new dashboard.  This one will be helping to drive the quality of our development practices, enabling us to keep an eye on how data migrations are going and how we’re stacking up against our targeted goals. I have a whole host of ideas to extend it, both using the available widgets and with some custom ones I hope to build soon.

 

Leave a Reply

Your email address will not be published. Required fields are marked *