ChatOps journey with Ansible, Hubot, AWS and Windows - Part 2

This is Part 2 of the series of setting up a Chatbot for deploying artifacts to AWS EC2 Windows instances. In this post, I’ll set up the Chatbot using Hubot.

I created another directory bot as the root directory of Hubot code. Hubot stub code can be generated using the Yeoman generator generator-hubot.

1

2

3

$ yarn global add generator-hubot

$ cd bot

$ yo hubot

Now I got the basic code of the Chatbot. The generated code contains unnecessary dependencies, so I removed them. Those dependencies need to be removed from both package.json and external-scripts.json. If you added extra dependencies, they also need to be added in both package.json and external-scripts.json. I also added the hubot-hipchat adapter to communicate with HipChat.

Below is the dependencies in package.json.

1

2

3

4

5

6

7

"dependencies": {

"coffee-script": "^1.12.7",

"hubot": "^2.19.0",

"hubot-help": "^0.2.2",

"hubot-hipchat": "^2.12.0-6",

"hubot-scripts": "^2.17.2"

}

Below is the external-scripts.json file.

1

2

3

[

"hubot-help"

]

Hubot script

Now I can add the script to handle messages. I added the ops.js in the folder scripts, which is the place to add custom handlers. Hubot supports both JavaScript and CoffeeScript.

The first thing to consider is what kinds of messages can be handled by the bot. Hubot supports matching fixed messages and using regular expressions. I decided to turn Hubot into a command-line interface, which is very intuitive for developers. I use yargs to parse incoming messages, then invoke the command ansible-playbook to perform the deployment.

In the code below, robot.respond is the function to handle incoming messages. Here I specified the regular expression /deploy (.*)/i to match all messages starting with deploy. I built the yargs parser with one positional argument for the build number and another optional argument debug for enabling debug mode. After the parsing is successful, I used the spawn to invoke the command ansible-playbook. If debug mode is enabled, the data from stdout of the spawned process is sent to the user. When the ansbile-playbook process exits, I sent different messages based on the exit code. (successful) and (boom) are HipChat emoticons. If the parsing failed, the output of yargs is sent to the user directly, so the user can see the command-line parsing errors. Here I use res.envelope.user.name to get the user’s name to tag the EC2 instances.

Once a Docker container is started, it connects to HipChat and runs as a bot. Now I can try to interact with it by sending messages like <Bot name> deploy 100 and wait for it to do the job.

Deploy to AWS ECS

The deployment to AWS ECS is an easy task. I used the Docker repository provided by ECS and pushed the image to it. The next step is to create the task definition for the Chatbot. Remember to configure the environment variables through the task definition. Finally I create the cluster and run the task using the definition.

That’s all for Part 2. In the next Part 3, I’ll discuss using AWS Lambda to make sure instances are not left running for too long to save money.