So I want to share !!
I can’t get into too many details, but the overall concept was that every customer would be running a micro instance with our custom Hubot code installed .. This instance would pull code updates, if any, every 5 minutes and infrastructure updates, if any, every 15 minutes .. In addition, a customer could participate in pilot programs — AKA branch work ..
I really liked how I was able to mitigate the use of a “command node” and just run Ansible locally and on a schedule .. Also, I was able to automate pretty much everything — from VPC creation all the way to autoscaling groups ..
Anyway, here’s the link: https://github.com/gkspranger/failed-chatbot .. Maybe it will help one of you out there in Internets land ..
“Greg, what’s your problem ?? Hal brings you beer !!” .. True, true .. But I want more !! I want to be more like my developer friends and apply an MVC design pattern to my Hubot development .. Specifically, I want my “views” to be beautiful and maintainable, while having the ability to use complex data “models” ..
Hello Handlebars !! Long story short, I can easily build semantic templates, compile output, and send as a Hubot reply .. For example:
Here’s the template:
Here’s the Slack output:
Hal is my Hubot chatbot .. He’s awesome !! He gets me beer !!
He also does things like restart app servers, deploy code, and show me pictures of grumpy cats .. He’s so cool, I’ve started making non-humans to talk to him .. “Greg, what do you mean ??” .. Well, let me show you ..
- I have a Nagios server
- It monitors (allthethings)
- When the “logged in users” alert is triggered, Nagios sends a message to my chat service using hipsaint
- “logged in users” is a monitor I have that alerts me when more than 3 users are logged into a server
- I see the alert and the server in question
- I SSH into the server
- I type who
- I then determine if I need to care
- If not, move on with my life
- If so, dig deeper
The thing is, I have more than
1,000 1,500 2,200 5,000 6,500 active monitors .. That means Nagios can and will send many, many messages to my chat service — depending on the day .. So how can I make my life easier ??
Here’s an easy one: ask Hal who’s on a server ..
My stack is HipChat -> Hubot -> Jenkins -> Ansible .. That means I can damn near do anything I want, all from my chat client ..
Remember what I said earlier — about making non-humans talk to Hal ?? What I did was create a Nagios event handler that sends a message to my chat service using HipChat CLI .. Therefore, I AM NOT asking Hal who’s on a server, it’s NAGIOS WHO IS doing it ..
It doesn’t stop there !! You can create scripted Splunk alerts as well .. Before you know it, you will be making (allthethings) talk to Hal ..
Jenkins (thank you CloudBees !!) is my chosen automation platform, often triggering an Ansible playbook (thank you Michael !!) to automate some mundane task .. I also use HipChat and have implemented a Hubot (thank you GitHub !!) chatbot .. Wouldn’t it be nice to integrate it all ?? For example, in HipChat:
@hal restart tomcat in dev
- Which Hubot recognizes
- Who then builds a Jenkins job
- Which then executes some Ansible playbook
- Which then restarts Tomcat in the development environment
Actually, it’s not that difficult .. For this post, I won’t go into the details on how to setup Hubot (this might help) or how to restart the Tomcat service (this might help) .. What I am most interested in is how to:
- Create a reusable way to build any Jenkins job
- Since Hubot is a Node.js application, an event listener sounds logical
- Invoke this reusable way
- i.e. event trigger
Here is an example of a Hubot event listener that can build a Jenkins job with or without parameters ..
Here is an example of a Hubot command that can trigger the previously defined event listener ..
I hope this helps !!