Looking deeper into ChatOps

Wow few upgrades and summer vacation kept me busy past few months. Lately I have been looking on automation and started to look into ChatOps.

So what is ChatOps? If you look from various sources you get different explanation but to put it really simple you have a chatroom tailored for specific group, be it developers or sysadmins etc and there you have possibilities to perform some background workflows and share common information to everyone.

Sounds quite useful!

I did some initial testing before I committed myself doing “proof-of-concept” with specific software. In the end I went with Stackstorm (https://stackstorm.com/) utilizing Hubot and MatterMost (https://about.mattermost.com/features/).

Stackstorm is described in their own web page as “StackStorm is a powerful open-source automation platform that wires together all of your apps, services and workflows. It’s extendable, flexible, and built with love for DevOps and ChatOps”.

Also it seemed to have already good amount of extensions build up which I have been looking as an example. Still the engine itself requires chat-server for your chatbot and my pick was Mattermost.

Still I see many people utilizing Slack with Stackstorm as well. I’m not going to dive into installation of either as it was quite straightforward and documentation is found from their sites respectively.

One cool thing about Stackstorm was that the actions and workflows are written with YAQL. Also with workflows you can utilize Mistral to make your workflows more dynamic. Learning curve for these was quite small and within few days I was able to build quite nice workflows.

Why would we need ChatOps?

I was thinking possible use cases where we would need ChatOps. A lot of times people either send message on Skype or vie email and ask status of something. “Is the server up?”, “Is the mobile application up for EBS?”, “Is that patch applied?”

All these cases can be resolved with normal monitoring and through EBS own responsibilities (checking if patch is applied) but still they need some effort and always additional few steps from person who is checking them.

From operational point of view these tasks could be easily automated and made available for all people.

Test cases:

First case which I used was when user wants to verify environment status for our EBS. For that I made shell script which checks the URL status, Oracle EBS MWA server and sql script which checks the Internal Concurrent Manager. As a extension for this I would probably add different concurrent managers also.

Running the command !status DEV checks status of our DEV environment by kicking off workflow which runs the shell script. Once the output has been returned it will run second task on the workflow which posts the message on the channel.

Doing this as a first test case was quite useful as it required learning different areas of Stackstorm. Workflows, using shell scripts, posting output to chat etc.

Second test case was to check if specific patch has been applied. Now this was quite simple to do as well. Just check two parameters from the user, patch # and instance where you want to check it and then run sql script against that environment.

There are lot of possibilities to make output the way you want. If this would be published to users then I would definitely want to make adjustments on the output so it would be meaningful for everyone.

In the patch check I just put whole stdout from sql script to the channel.

Third case was something for myself! One great thing would be to download required patch automatically to your patch store on the servers.

Maris Elsins has written program to download patches automatically from My Oracle Support (https://www.pythian.com/blog/getmospatch-v2-is-here/) so I thought I would utilize that in this case. Maris has some other great scripts available from his presentations too!

Again only thing I did was to paste full stdout to chatroom.

Conclusion:

I see lot of potential here if you have simple (or complex!) tasks within your team which you want to automate. And not only that but to have visibility to whole team as well.

As a next step I will build some more complex workflows utilizing Oracle VM Rest API and also seeing if I can pass notification alerts from Enterprise Manager 13.2 to Stackstorm. We do some simple database cloning as well which is already automated so that’s a another possibility.

After few weeks of playing with Stackstorm I think I’m going to look it further and continue using it. Their user community is quite active and documentation is well-written so it’s a good starting point. And if you need to build more complex workflows they have their Enterprise Edition available as well for that.

More updates on this to follow!