‘npm install hubot-asgard’ should get you most of the way there, check the readme on either github or npm for additional details about environment variables and configuration. Once installed, ‘hubot help asgard’ will show all the commands.
Concerns about AMI management and deployment to Amazon Web Services quickly lead to the nebulous AutoScaling Group feature of EC2 (why isn’t this in the management console?). Once you find yourself with a handful of scripts using some sdk from Amazon that amount to launch configuration creation and autoscaling group updates with a dash of load balancer add/remove, you start to wonder if there’s an easier way. There are several. Elastic Beanstalk and OpsWorks aim to address this problem, and they do a good job. The only thing I will add is that if you like fine control of your environment, you’ll quickly move from Elastic Beanstalk to OpsWorks (in beta at time of writing), and if that starts to leave you wanting control, eventually you’ll get to Asgard.
Asgard is first and foremost a tool for managing AWS objects for Netflix. They do a great job of making the tool useful for everyone else, but keep in mind that Netflix is probably using (a lot) more AWS objects than you. For those of us who want to manage a couple application stacks with 10 or 20 servers during peak, running an extra medium instance and figuring out the basics of Asgard might seem excessive. Enter hubot-asgard. After setup, your chat room could look something like this:
This is much easier than managing AMI deployment manually, and you have all the tuning control that you want at the application level with Asgard. Since you don’t need all these application level features everytime you want to push a new AMI, deployment with Hubot allows you to ignore the full Asgard installation much of the time. It still looks like a lot of typing though, right? These abbreviated commands work too, and accomplish the exact same outcome as the previous example:
One concern might be running an Asgard instance(s) all the time. If you want to shut down Asgard, that’s cool. Hubot-asgard comes with a few ‘asgard-launcher’ commands for managing your own Asgard instance. Start up a working Asgard from NetflixOSS’s ami, create a custom AMI with your own credentials, and launch/terminate the instance via Hubot. Once hubot is configured with hubot-asgard, it looks like this:
Hubot-asgard will automatically use the newly created ami next launch (using Redis storage). Don’t forget to issue the ‘asgard url http://public-dns:8080/' message so that Hubot knows where your Asgard instance can be reached. If you are terminating and re-launching Asgard, you will need to do this every time - and you should probably create a bug about it.
The example above showed deployment based on a new autoscaling group. Note that the default treatment of hubot-asgard is to start new autoscaling groups without adding them to the configured load balancer. This is why the ‘asgard autoscaling activate new-asg’ command was necessary. If you want to push live instances with no further interaction, you can add a ‘false’ flag to the ‘asgard next’ command, to indicate removal of the ‘trafficAllowed=true’ parameter (EDIT: this had a reversed boolean in the original text).
You could also do a rolling push. Asgard allows you to simply provide a new AMI, and Asgard will roll the new AMI out one instance at a time. It’s configurable, but hubot-asgard uses a basic one-at-a-time style similar to the configuration used in the rolling push on the Asgard REST API wiki page.
I believe the rolling push updates the launch configuration and then uses timers to terminate older instances (I haven’t checked, but it doesn’t matter). DO NOT USE rolling push if you only have one instance running in an autoscaling group. It’s a delete then replace action, not a replace then delete.
Just want to resize an autoscaling group in your application? No problem:
First, sit back and do some image browsing with Hubot while you think about how much time you just saved by using Asgard to manage your AMI deployment.
Now spend some time reading the hubot-asgard help entries and seeing the rest of your options for Asgard interaction from Hubot. Report any issues you find.
Remember that output is all templated, if you want something else, either bug it or customize the eco templates in hubot-asgard/templates.
Now you can start thinking about some of these challenges (if not already addressed):