I like slack. I like automating things. I hate email. Therefore, I like Hubot. I’ve written Hubot scripts that integrate with our ticketing system and launch Skype calls to everybody in the channel. Earlier this week, I added autoscaling notifications to Slack when our servers automatically scale up or down. To go along with this, I wanted to see all the servers we’re currently running in EC2.
I found some scripts that did roughly what I wanted, but those scripts 1) Did more than I wanted and 2) didn’t have the formatting I wanted for the ls command and 3) didn’t filter in the way I wanted. Based on yoheimuta’s scripts I created a new npm package, hubot-ec2, that just lists instances.
Installation is straight forward in your hubot instance:
npm install --save hubot-ec2
After installing, set 3 environment variables
The keys used should be a user with the IAM Policy AmazonEC2ReadOnlyAccess.
Once thats all set, deploy your bot and you’ve got a new command:
hubot ec2 ls
You can filter by instance name:
hubot ec2 ls i-abcd1234
or by tag name:
hubot ec2 ls production-*
It will look something like this when its all wired up:
Do you use hubot and slack? What have you done to make it awesome?
Dev-ops has become a little bit of a buzz-word, but its something I’ve come to embrace and enjoy; automating our infrastructure and deployments has streamlined our software development lifecycle. One piece of our infrastructure is AWS Autoscaling. With AWS Autoscaling, we can easily add new servers in response to shifting usage patterns. For instance, during the night, we might drop down to 1 server as our site quiets down and as usage grows during the day, automatically scale up to as many as 6 servers. Its been a useful cost savings measure and its also forced us to get our server provisioning correct through Ansible.
I wanted to know, via slack, when we scaled up our down. AWS doesn’t provide this functionality directly, but with a few hoops, it wasn’t too hard to add.
- Setup Amazon Simple Notification Service (SNS) to receive messages
- Use Amazon Lambda to transform SNS messages to Slack webhooks
- Configure Autoscaling to send SNS messages
Because we need the Lambda function before we setup the SNS endpoint, we’ll do that first
Setup Lambda Function
AWS Lambda is a snippet of your code, running somewhere in the cloud. You don’t manage the server and you only pay for the time you use. Lambda currently supports Java, Python and Node. We’ll write a simple node script that sends an SNS message to a Slack incoming webhook
- Login to your AWS console and find the Lambda functions
- Create a new Lambda
- Skip the blueprint selection, start with a blank script
- Give your lambda function a name (autoscaling2Slack), optional description and pick the node runtime (4.3 as of this writing)
- Configure the script below as the lambda function with your slack webhook URL
- Create a new IAM role for the lambda function (basic execution role)
To test your lambda you can use this SNS message. To view the real SNS messages, you can add some console.log statements to the lambda function and view them when autoscaling runs.
If you’ve set it up correctly, you should see the test message come through to slack:
Setup SNS Endpoint
With the Lambda in place, the SNS endpoint can be created.
- Login to your Amazon Console and find the SNS and create a new topic (slackSNS).
- Create a subscription to send to your Lambda function.
When you’ve got it setup, it should look something like this:
Send SNS messages when autoscaling occurs:
- Login to your EC2 console.
- In your autoscaling groups, add a new notification to your SNS topic.
When its setup, the ASG notifications should look something like this:
I like slack and I hate email. This lets me see autoscaling notifications from an SNS message that doesn’t go to email. Hopefully you’ve found this useful.