Hubot script for getting together with Asgard
- Allow a simple interface for convenient (particularly read-only) data demands from Asgard.
- Better mobile support via Fire/Hipchat/XMPP/etc.
- Templated (eco) output enables easy personalization for users.
- Support fundamental and/or fundamental updates which should not want a browser to operate.
- Additional ACL via Hubot Admin and roles
Asgard must be running somewhere, and Hubot needs so that you can can get on. You are able to launch by hand on AWS having a NetflixOSS AMI or one of these simple.
If you prefer a more hands-off approach, hubot-asgard comes bundled with a few asgard-launcher instructions. They are AWS-centric launch utilities for Asgard. After configuration in Hubot, you are able to launch a brand new Asgard instance the following:
After configuring your Asgard instance via internet browser, save a personal AMI which includes your configured AWS credentials. Note that it’s suggested to disable public AMIs when initially configuring your Asgard instance. If you want public AMIs be cautious using the ami listing demands, because they may exceed message size limitations (and presently don’t batch).
asgard-launcher create ami
If you wish to shutdown the instance, use:
Should you produced an ami, asgard-launcher uses that ami for future asgard-launcher run demands. Otherwise, it’ll launch the default ami (requiring configuration) every time.
Asgard-launcher defaults to launching the NetflixOSS AMI with an m1.small instance. Use asgard-launcher ami and asgard-launcher instance type to override these defaults.
Update Hubot’s package.json to set up hubot-asgard from npm, increase Hubot’s exterior-scripts.json file to incorporate the hubot-asgard module.
Update the files to incorporate the hubot-asgard module:
Run npm install to set up hubot-asgard and dependencies.
Hubot-asgard uses Redis to keep information via robot.brain. On initial launch, hubot will attempt to load your HUBOT_ASGARD_URL and HUBOT_ASGARD_REGION in the like-named atmosphere variables. If they are empty, Hubot uses ‘http://127…1’ and ‘us-east-1’.
You are able to retrieve increase these values with Hubot via:
asgard url http://asgard.example.com:8080
asgard region us-west-2
If you are planning to make use of asgard-launcher, you have to set AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY atmosphere variables for effective aws-sdk configuration.
Use hubot help or look into the asgard.coffee file to obtain the full listing of options with short descriptions. The steps below cover checking autoscaling groups and pushing a brand new ami to particular autoscaling group.
Show autoscaling groups:
Show just one autoscaling group:
a as autoscaling-group-name
Begin a moving push:
asgard rollingpush autoscaling-group-name ami-1234abcd
Look into the moving push task:
asgard task 12
Hubot-asgard returns data via (eco) templates. If you’re missing data, or wish to organize things differently, hit the Asgard web interface that matches a request and append the url with ‘.json’. This will demonstrate the information that’s being passed towards the template. Alter the template inside a fork and only rock your individual changes, or submit a pull request everybody to savor.
- List size checking, response batching. Need fundamental safety checks in situation someone tries to obtain the listing of all AMIs in us-east-1 (or has large systems).
- Implement roles – Use HUBOT admin, or entirely separate roles? Most likely both.
- Refine templating
- Wrap additional services