Hi folks,
A month (or more) back a few of us had a discussion about what other AWS modules we’d like to see as a priority. We also outlined a short-term vision for using Ansible with AWS, best summed up with the following statement I think:
“Enable the provisioning of a common stack of EC2 resources and subsequent workload(s) which can be easily replicated between regions.”
Comments very welcome here. For such a foundation, there are a number of resources which really are mandatory for this: keypairs and security groups, idempotent modules would be great. On top of this, we have plenty of folks who are working with services like ELB and AutoScaling, so some way of adding and removing instances from load balancers and autoscaling groups would be good. Another very useful module would be one for Route53, which would be super-slick 
Some of the existing modules also need a tidy up and additional features added, happy to go into this in more detail if it interests folks.
I think if we had a set of modules which handled all of the above we’d be in pretty darn good shape
Thoughts? Maybe we can spend some time discussing all of this at AnsibleFest in a breakout? I’m pretty interested in getting further insight from those using AWS in production.
Kind Regards,
Lester
I’m relatively new to ansible but it seems like if you use cloudformation directly, the cloudformation module or AWS provisioning modules there will need to be two steps, one for provisioning and one for configuration.
Here what we are currently considering is creating a cloudformation template for our entire stack which consists of:
- Several different clusters of EC2 instances (rabbit, elasticsearch, applications, etc)
- RDS
- Elastic cache
Creating these resources with tags defined in the cfn template would give us a way to feed network topology information into ansible for configuration with some simple changes to the ec2.py script to add discovery for the other resources.
I would also be interested in meeting up with other folks who use AWS regularly at ansiblefest.
-John
Right, I was just talking to some AWS folks about this the other day. Cloudformation is a good way to deploy a stack of resources, since its the AWS-approved way (although maybe its hard to debug failures sometimes). Do we want the option for Ansible to able to orchestrate (i.e. create the resources) in the same way? AWS clearly saw demand from users with the purchase of Peritor and release of OpsWork. Of course, we already have a Cloudformation module so folks can do all of this within Ansible-land.
The approach you outline is absolutely valid, I know folks don’t always want to deal with provisioning through Ansible but certainly do want to address those hosts for configuration management after. This is kinda the “half-baked image” approach AWS talk about.
So there already is the Cloud Formation module that James Martin wrote – however, I find it a bit hard to understand Cloud Formation.
Does it make sense to do it differently? I’ll leave it to AWS experts.
I definitely like the idea of the ELB load balancer support – and in particular adapting the lamp_haproxy example in Ansible Examples to take full advantage of initial AWS provisioning, continual management, and AWS native load balancing.
Thanks great to know, thanks! A route53 module is certain to come, maybe not from me immediately but lets wait and see how bandwidth turns out
For others who are interested in AWS configuration examples we are in the process of converting our infrastructure from puppet to ansible and since this is from the ground up we are making everything open source.
https://github.com/edx/configuration
I never expected Ansible’s AWS support to grow as much as it has. It has come a long way since I first wrote the EC2 inventory plugin.
I would like to one day see Ansible with enough AWS modules to replace CloudFormation entirely, and if possible, be better/easier than OpsWorks. I would also like for Ansible to be an excellent way for building AMIs too, as well as ad-hoc changes to running systems (I do this now, but it is not clean and pretty).
@Lester, is that the vision you have as well?
@Michael, does this conflict with anything you have planned?
I wasn’t planning on going to AnsibleFest, but certainly don’t want to miss out of talking more about this. Perhaps I should reconsider.
Peter Sankauskas
I support Peter’s vision. +1
Peter,
Definitely something I’d love to see.
I think it’s an easy way to understand EC2 intuitively – we can definitely do the same around other cloud services too (Rackspace, etc) – but I want to see us have a very clean way to understand that makes AWS understandable, rather than the rather complex entity that it seems to non-AWS users from the out side.
I definitely think we can have a much cleaner solution than OpsWorks as well
–Michael
Peter, yes, this is precisely it and exactly what I think we should be aiming for. It’s entirely possible to serve the various camps and schools of thoughts around provisioning and management of resources in the cloud. The way I see it, we have three main use-cases or methodologies to cater for, at the moment:
- Folks who like CloudFormation
- Folks who want to provision with their orchestration tool of choice (inc. OpsWorks)
- Folks who don’t really want to use any config mgmt but rather just bring up and tear down resources based on fully-baked EMI’s
We can address all three of these pretty strongly I think. For (1) and (2), we can continue to build up the library of core AWS modules (and not to mention we also have the CloudFormation module) and the EC2 inventory plugin. For (3), we demonstrate how to build machine images using Ansible playbooks, locally, hypervisor staged or in EC2 itself with a bundle + register step.
After all, many of the same principles will apply to other cloud providers as they mature. There will be competing products/services in regards to CloudFormation and OpsWorks.
What type of sadistic individuals fall into category (1) really?
I haven’t put too much thought into using ansible as a tool if what you are thinking for number (2) are some modules to serve as wrappers over the boto api.
Hand editing JSON is awful but it does serve the purpose of provisioning my stack and grouping all of the various AWS components (ELBs, cache, RDS, EC2) into one launch configuration. My current approach is to keep the provisioning and the configuration separate.
I’ve been thinking of fully baked AMIs in the context of auto-scaling and I think I’m generally against the idea of putting a bunch of sensitive bits in a disk image.
That would mean for us running ansible on bring-up and since ansible is run externally maybe there would be a notification of some sort that would trigger an ansible run from a deploy server.
I guess the pull rather push model (chef/puppet) might fit a little better for that use-case but I am definitely interested if other people have spent brain cycles on it.
-John
“What type of sadistic individuals fall into category (1) really? :)”
Exactly.
What we want is a way to make AWS consumable for everyone. To me, that means lots of AWS modules that are super easy to use, and a really good ansible-examples repo example of using a lot of them in conjunction.
I tend to concur that provisioning playbooks and configuration could/should be seperate in many cases, because you might be doing a rolling update or reconfiguring, and it doesn’t always mean the streams should be crossed.
“run externally maybe there would be a notification of some sort that would trigger an ansible run from a deploy server.”
ansible-pull does exist for this purpose today.
When you say:
I think I’m generally against the idea of putting a bunch of sensitive bits in a disk image.
What is the concern here?
I think data at rest on S3 is safer than a running EC2 instance that has ports open.
In general though, you want to be using AutoScaling Groups on EC2 so that when things go bad (such as an AZ going down), you don’t need to manually intervene. How fast the instances to come up is based on this scale:
Fast Slow
------------------------------------------------------------------------------|
Fully baked AMI with code Base AMI configured on boot
I think the closer you can get to the left, the more reliable your scaling will be.
Peter Sankauskas
Autoscaling doesn’t preclude having instances in multiple AZs.
There is another scale here:
Slow Fast
------------------------------------------------------------------------------|
Fully baked AMI based code updates Incremental updates
Where I am defining the left side as having to re-build an entire AMI on every code update.
You could probably do something in-between where you have most of the requirements satisfied in your reference AMI and then ansible/whatever is run before the instance joins the pool to catch it up.
-John
BTW, with the chroot plugin, we have a pretty good answer to AMI builds, I think, with a little glue.
We should write up something for ansible-examples showing this
I know quite a bit about generating AMIs. I'd be interested in
tackling the AMI-creation playbook/script/thing, whatever that might
look like. It should be relatively trivial and I can definitely
contribute it back to ansible-examples.
There are some decent creation tools floating around out there, like
ami-creator (https://github.com/katzj/ami-creator) and
ubuntu-vm-builder. I wonder if we should try piggy-backing on those?
-Tim
ubuntu-vm-builder is really great for creating… ubuntu images. (Don’t get me wrong, I love me ubuntu images, but it’s a big limitation on a VM image creation tool to support only one distro). I believe the Debian downstream (!) version of this adds support for… Debian images.
For creating non-Ubuntu images, I’m partial to Oz <https://github.com/clalancette/oz/wiki>
Lorin
What type of sadistic individuals fall into category (1) really?
That would be me. I wrote the CloudFormation module :). The main
reason behind it was I already had a slew of CloudFormation templates
that I had been working with, and for someone who is constantly
building up and ripping down multi-tier environments (think VPC,
internal and external load balancers, NAT device, bastion host,
multiple security gruops, database servers and frontend servers with
ebs backed all around), it provides a very easy way to do that. And
it puts on the responsibility on AWS to take care of building it up
and taking it down. And like you said, I like provisioning the
infrastructure with ansible and configuring it with a subsequent
ansible run.
Hand editing JSON is awful
Yes, editing JSON by hand is shit, but who's doing that? I use the
cloudformation python module to do that. There are also some GUI
tools as well for folks who like doing that.
- James
Very nice discussions and plans for EC2 module.
-Rodney
I think CloudFormation module is great for people who’s brains fit CloudFormation.
Not suggesting removal, but … I think it’s less flexible to have to write a huge JSON blob rather than to have AWS tasks all throughout your module.
Definitely reduces the learning curve.