-
Notifications
You must be signed in to change notification settings - Fork 1
CLI Tools
Download AutoScaling CLI Tools. Follow README.txt installation instructions.
Ensure you've added the following environmental variables (to your bash_profile file, for example):
export AWS_CREDENTIAL_FILE=/Users/grisha/Code/aws-autoscaling/creds
export AWS_AUTO_SCALING_HOME=/Users/grisha/Code/aws-autoscaling
export JAVA_HOME=$(/usr/libexec/java_home)
CLASSPATH="/Users/grisha/Code/aws-autoscaling/lib:${CLASSPATH}"
export CLASSPATH
Adjust according to your dev environment.
Commands
Obtaining information about AutoScaling Groups:
as-describe-auto-scaling-groups groupname --region us-west-2
To find group name of your ELB's environment, you can use CloudFormation's resources tab for your environment.
Set desired capacity (how many instances you want running in the group) - this will ensure 17 instances in the group are running:
as-set-desired-capacity groupname --desired-capacity 17 --region us-west-2
In order to minimize amount of administration work we need to do, we're using Elastic Beanstalk to mainstream the process of setting up and monitoring our development/testing/production environments.
Here's an initial writeup to setting up a Django project on ELB and an architectural overview that Grigory wrote: http://grigory.ca/2012/09/getting-started-with-django-on-aws-elastic-beanstalk/
Currently we're using AWS's small instances as part of the environments. We're not using micro instances because our CPU usage does not coincide with what micro instances were designed for. See an overview here: http://docs.amazonwebservices.com/AWSEC2/latest/UserGuide/concepts_micro_instances.html
ELB uses a CloudFormation template to set up required resources (load balances, autoscaling groups, cloudwatch alarms, etc). It provides an interface to quickly access CloudWatch graphs (CPU utilization, latency, network in/out, etc), as well as a way to tail logs from the instances, deploy code versions, etc.
Cache Security Groups
Default group prevents access to cache cluster. In order to access cluster from an application, create a custom Cache Security Group, and authorize access for an appropriate EC2 security group (the one associated with the Elastic Beanstalk environment in question).
One (regularly very bad, but easy if you've just created an environment) way to find out which security group is used for the beanstalk environment is to scroll through its event logs back to when it was created. Name should be listed in one of the events.
A proper way to look up Beanstalk Security Group is to open CloudFormation AWS console, find the appropriate stack (see Description column), and check in the Resources tab.