How to Deploy Hubot

Finding a good excuse to learn a new technology is something I’ve been interested in for a while particularly as the pace of change and technology adoption only ever seems to be increasing. Knowing that the IT world is in an ongoing state of flux, finding an engaging way to learn about the tech that technologists are expected to know is more than idle curiosity, it’s essential for career success.

Revisiting Chatbots, a topic I encountered through a Wired article from summer 2015, I discovered that getting a chatbot up and running, and more importantly, useful and usable, involved a wide variety of different technologies. As the article was heaped so much praise on Github’s bot, I decided to try it out with a view to having it do some useful tasks around AWS administration, one of the two challenges that had been put up to our 2016 interns.

This led me to having to work with a number of interesting and topical technologies, including:

  1. Hubot – the Github chatbot
  2. Node.js and npm
  3. Git
  4. Redis
  5. AWS CLI
  6. systemd
  7. Slack
  8. Coffeescript

To get started, as I wanted my bot to work with AWS, it was necessary to prepare a couple of things on that side.

I created an AWS IAM account for my bot to use. I didn’t assign a password to the account as I don’t intend for the account to be used interactively (i.e. for logging onto the console), what I was after was an access key and secret key that can be used with the AWS Command Line and therefore could be used by the bot.

With the AWS pieces in place, I moved on to setting up the host in AWS itself, and selected a Red Hat Enterprise Linux 7.2 machine to act as my Hubot host, as this would approximate a production deployment.

Onto my new RHEL server, I installed and configured the AWS CLI.


$ curl "https://s3.amazonaws.com/aws-cli/awscli-bundle.zip" -o "awscli-bundle.zip"
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 6984k 100 6984k 0 0 4106k 0 0:00:01 0:00:01 --:--:-- 4105k

$ unzip awscli-bundle.zip
Archive: awscli-bundle.zip
inflating: awscli-bundle/install
inflating: awscli-bundle/packages/jmespath-0.9.0.tar.gz
inflating: awscli-bundle/packages/simplejson-3.3.0.tar.gz
inflating: awscli-bundle/packages/botocore-1.4.43.tar.gz
inflating: awscli-bundle/packages/ordereddict-1.1.tar.gz
inflating: awscli-bundle/packages/awscli-1.10.53.tar.gz
inflating: awscli-bundle/packages/rsa-3.4.2.tar.gz
inflating: awscli-bundle/packages/futures-3.0.5.tar.gz
inflating: awscli-bundle/packages/docutils-0.12.tar.gz
inflating: awscli-bundle/packages/s3transfer-0.1.1.tar.gz
inflating: awscli-bundle/packages/colorama-0.3.7.zip
inflating: awscli-bundle/packages/argparse-1.2.1.tar.gz
inflating: awscli-bundle/packages/pyasn1-0.1.9.tar.gz
inflating: awscli-bundle/packages/virtualenv-13.0.3.tar.gz
inflating: awscli-bundle/packages/python-dateutil-2.5.3.tar.gz
inflating: awscli-bundle/packages/six-1.10.0.tar.gz

$ sudo ./awscli-bundle/install -i /usr/local/aws -b /usr/local/bin/aws
Running cmd: /bin/python virtualenv.py --python /bin/python /usr/local/aws
Running cmd: /usr/local/aws/bin/pip install --no-index --find-links file:///home/ec2-user/Downloads/awscli-bundle/packages awscli-1.10.53.tar.gz
You can now run: /usr/local/bin/aws –version

$ aws configure

Up next was configuring the EPEL yum repository so that I could use Yum to install things like Redis.


$ wget -r --no-parent -A 'epel-release-*.rpm' http://dl.fedoraproject.org/pub/epel/7/x86_64/e/
$ sudo rpm -Uvh dl.fedoraproject.org/pub/epel/7/x86_64/e/epel-release-*.rpm
warning: dl.fedoraproject.org/pub/epel/7/x86_64/e/epel-release-7-8.noarch.rpm: Header V3 RSA/SHA256 Signature, key ID 352c64e5: NOKEY
Preparing...                ################################# [100%]
Updating / installing...
1:epel-release-7-8          ################################# [100%]
$ ll /etc/yum.repos.d
total 32
-rw-r--r--. 1 root root  957 Jul 23 17:37 epel.repo
-rw-r--r--. 1 root root 1056 Jul 23 17:37 epel-testing.repo
-rw-r--r--. 1 root root  358 Nov  9  2015 redhat.repo
-rw-r--r--. 1 root root  607 Aug  9 04:08 redhat-rhui-client-config.repo
-rw-r--r--. 1 root root 8679 Aug  9 04:08 redhat-rhui.repo
-rw-r--r--. 1 root root   80 Aug  9 04:08 rhui-load-balancers.conf

With the appropriate repos in place, I was able to install redis


$ sudo yum install redis –y

$ sudo systemctl start redis.service

$ sudo systemctl status redis.service

redis.service - Redis persistent key-value database

Loaded: loaded (/usr/lib/systemd/system/redis.service; disabled; vendor preset: disabled)

Drop-In: /etc/systemd/system/redis.service.d
└─limit.conf

Active: active (running) since Tue 2016-08-09 04:37:35 EDT; 5s ago

Main PID: 4971 (redis-server)
CGroup: /system.slice/redis.service
└─4971 /usr/bin/redis-server 127.0.0.1:6379

Aug 09 04:37:35 ip-192-168-20-246.eu-west-1.compute.internal systemd[1]: Started Redis persistent key-value database.
Aug 09 04:37:35 ip-192-168-20-246.eu-west-1.compute.internal systemd[1]: Starting Redis persistent key-value database...

Hubot is basically a bunch of node.js, so it was necessary to get it and the Node Package Manager installed too.


wget https://nodejs.org/dist/v6.3.1/node-v6.3.1-linux-x64.tar.xz

sudo tar --strip-components 1 -xf /home/ec2-user/Downloads/node-v6.3.1-linux-x64.tar.xz

I called my Hubot “Io” (as in I/O), and created a directory for Io to live in. Once installed, Hubot can be started in a basic “shell” mode that enables testing and local interactions with the bot on the host server.


$ sudo npm install -g yo generator-hubot

$ cd /io

$ yo hubot

$ bin/hubot

At this point, a working Hobot is in place but it isn’t very useful. In order to get more out of him, Hubot can be extended by adding scripts. In the fine tradition of Open Source, many scripts that others have developed are available to download and install via NPM, and of course you can create your own.

Up next, extending Hubot through scripts.

Solving Problems with Chatbots

Employee engagement is a big issue for any company, put simply disengaged employees leads to departing talent, so it’s vital to constantly be looking for ways to develop teams, especially those working with technology, in ways that result in high levels of ongoing engagement.

During a recent conversation about engagement and issues around internal communications, a colleague of mine suggested making better use of the screens we have deployed around the office to help keep everyone in the loop and up to date. This is an admirable idea but like all comms plans depends on the content more so than the delivery mechanism; the medium may be the message, but it’s important to have a message in the first place!

The conversation about content reminded me of an article in Wired from about a year ago about Github and how they had deployed a chatbot. What was interesting for me in that article was the story of how Github employees are extending the chatbot’s capabilities by scripting new features. What makes this doubly interesting is that not only are the engineers at Github doing this but so are non-technical people. One example in the piece was about someone from the marketing department creating a script that their chatbot uses to check on the status of local street vendors.

It occurred to me that a chatbot system like this could help out with two focus areas for developing team engagement. Firstly, it could provide that content that can be so hard to source. By making a conversational interface to a content management and deployment system, the process of gathering and displaying interesting material could be dramatically improved by providing a reason to generate content as it would give everyone an excuse to interact with the cahtbot. Secondly, having a chatbot system in place could provide an outlet for non-developers who want to spend some time learning development as it could provide a purpose beyond developing the standard issue “Hello World” script, without which too many people abandon their learning efforts.

anatomy_of_a_chatbot
Content generation would be part of the Workflow use case for a bot

Every summer we get a bunch of interns, and in addition to their regular assigned work they are tasked with completing a technical challenge. The challenge is meant to be, well challenging, and this year we settled on Chatbots (I suspect this was entirely my fault and an abject lesson in reaping what you sow)! One team of interns was tasked with setting up a bot that can field queries about one part of the business, while the other (my team) looked at connecting a bot to AWS in order to complete Cloud tasks through a chat interface.

It is something of a tradition that while the interns get on with developing a solution in their own way, I go ahead and do the challenge myself in my own way to determine if it can be done and how differently I’d tackle the solution over how the interns go about it.

As the interns had gone down the AIML route, I decided to deploy Hubot, Github’s own chatbot.

hubot

Up next: Getting started with Hubot