Releasing TurbotUtils SDK

Posted by Michael Osburn on Fri 03 March 2017

Over the past year I have been dealing more and more with automating some of TurbotHQ's functionality and was getting frustrated with having to remember all the REST commands for each action that I needed to do. Since Turbot is still in a 0.X release the team behind it just does not have the time to provide an official Python SDK while working on new features and improvements to the core software. I do not blame them at all for that as I would much rather have a solid system and then a SDK then a solid SDK and a crappy system behind it. To work around this, at least until Turbot provides an official SDK, I have started writing a python module to provide this functionality so my scripts.

Turbot is an application designed to be a single point to manage multiple AWS accounts and does it well, but there is some features that do not make sense for them to provide and a lot of Amazon's emails leave much to be desired when it comes to identifying the correct point of contact when you are managing hundreds of accounts. An example of this is an email I received this morning:

We have important news about your account (AWS Account ID: 123456789012). EC2 has detected degradation of the underlying hardware hosting
your Amazon EC2 instance (instance-ID: i-12345678) in the us-east-1 region. Due to this degradation, your instance could already be
unreachable. After 2017-03-14 20:00 UTC your instance, which has an EBS volume as the root device, will be stopped.

With this email I know which account is going to be impacted, but I cannot quickly tell who is responsible for this account or who needs to be notified that there is an issue. With tagging resources I can now fire off a python script with the account id and the instance id to be able to generate the necessary details of who I have to contact for this. My output shows the following all generated by gathering the data from Turbot and AWS. With this information I can quickly send a notification to the affected team letting them know that AWS is failing on that instance, and since it is Autoscaling it could already have been replaced/no action needs to be taken. However, if an action has not already happened, they will need to do something about it.

Output of get_instance_owner.py script

$ get_instance_owner.py --account_id 123456789012 --instance_id i-12345678 --region us-east-1
Account Name: XYZ team - Lower Environment
Account Owner: Some Person
Lead Developer: Super Developer
Lead Ops: Ops Ninja
Issue Board: Jira/blah <link_to_their_board>
Instance: Super App Web Front-end 15
In Autoscaling: Yes

New workflow: kick off get_instance_owner.py with details from the Amazon email file a ticket on the correct issue board

This type of automation becomes extremely critical when you are managing hundreds of AWS accounts because the alternative is this workflow:

  • Load up turbot
  • log in
  • search for account id
  • log into the account (if you have permissions to do so)
  • find the instance
  • Look up the name tags and validate if it is in Autoscaling or not
  • find the wiki page for that team
  • get the contact information
  • finally send the action/notification ticket

turbotutils has been written on Python3.6 and tested on OSX and Linux and is available via pip.

pip install turbotutils

All of the code is hosted on github at https://github.com/mosburn/turbot_utils so please feel free to log issues and submit merge requests. I am working on the contributing documents/guides for this project.

If you want to know more about turbot, please see their website and contact them https://turbothq.com/, The team there is really great to work with.