There are several documented ways of setting up autoscaling groups with the help of ansible, including the official ansible docs.
EC2 auto-scaling does, however, assume that servers launched with the AMI will be ready to serve traffic,
meaning that the AMI has to be pre-baked (with ansible or other tools) and tightly couples code with the AMI.
So, you would have to re-build the AMI for every code release, which is less than ideal in certain environments -
particularly when deploys happen more often and you have a large number of servers.
I posted how you could re-use the same AMI to bootstrap Chef in an EC2 auto-scaling group in a previous post,
and it turns out you can apply the same concepts when bootstrapping nodes with ansible.
Posted Sun 26 October 2014
by Ivan Dyedov
(Amazon Web Services, Ubuntu, ansible, autoscale, Python)
There are lots of ways for setting up auto-scaling for EC2 nowadays,
there's Amazon's own products like the recently announced AWS OpsWorks
and CloudFormation. The benefit of using these tools is
integration with other AWS services. But, there's also downsides, as
OpsWorks cannot integrate with ELB currently, and using CloudFormation
will probably involve you writing funky JSON templates.
There's also third-party solutions, like open-source Asgard from
Netflix and rightscale, an enterprise cloud management service.
These services can also be used for some basic configuration management,
though I feel that is not their primary purpose. We chose to go with a
separate solutions for that - Opscode Chef.
There are lots of guides on how to set up EC2 auto-scaling, as well as
guides on integrating Chef with CloudFormation, like Amazon's own
docs, however there isn't much information on how to do this without
CloudFormation. Specifically, if you just want auto-scaling without the
extra complexity of CloudFormation and still want to use Chef for
configuration management, here's what you need to do.
Posted Thu 28 February 2013
by Ivan Dyedov
(Amazon Web Services, Ubuntu, Opscode Chef, autoscale)