# ansible-ec2 **URL:** \ **Category:** Ansible Project\ **Created:** [November 9, 2012, 1:21am UTC](https://forum.ansible.com/t/ansible-ec2/12074 "2012-11-09T01:21:04Z")\ **Posts on this page:** 14\ **Page:** 1
**Author:** ![Peter\_Sankauskas](https://avatars.discourse-cdn.com/v4/letter/p/ea666f/32.png) [@Peter\_Sankauskas](https://forum.ansible.com/u/Peter_Sankauskas)\ **Post date:** [November 9, 2012, 1:21am UTC](https://forum.ansible.com/t/ansible-ec2/12074/1 "2012-11-09T01:21:04Z")
Many months ago, I talked about working on ansible-ec2. I am happy to say I have finally had time to do just that, and would like feedback on what I have done so far. You can find it here: > [https://github.com/pas256/ansible-ec2](https://github.com/pas256/ansible-ec2) Functionality is quite limited, but this allows for the maximum amount of feedback to be incorporated easily. Right now, the main use cases are getting information about running instances > ansible-ec2 info --sg default > ansible-ec2 list --type m1.small and opening an interactive SSH session to a specific instance > ansible-ec2 ssh --name Web1 I have focused more on the interface, rather than the functionality, with everything having documentation by using -h or ansible-ec2 help COMMAND. In the future, more and more commands can be added, like launching an instance, bootstrapping it, and running a playbook. Please let me know what you think. Thanks, Peter Sankauskas ---
**Author:** ![Peter\_Sankauskas](https://avatars.discourse-cdn.com/v4/letter/p/ea666f/32.png) [@Peter\_Sankauskas](https://forum.ansible.com/u/Peter_Sankauskas)\ **Post date:** [December 17, 2012, 5:58pm UTC](https://forum.ansible.com/t/ansible-ec2/12074/2 "2012-12-17T17:58:17Z")
That sounds like a good idea to me. It is easy enough to add - start - stop - reboot - terminate Please create an Issue in Github, or if you feel like jumping into code, I will accept a PR for it. Peter ---
**Author:** ![Brian\_Coca1](https://avatars.discourse-cdn.com/v4/letter/b/278dde/32.png) [@Brian\_Coca1](https://forum.ansible.com/u/Brian_Coca1)\ **Post date:** [December 18, 2012, 12:30am UTC](https://forum.ansible.com/t/ansible-ec2/12074/3 "2012-12-18T00:30:36Z")
i believe the ec2 module in core already does that ---
**Author:** ![Peter\_Sankauskas](https://avatars.discourse-cdn.com/v4/letter/p/ea666f/32.png) [@Peter\_Sankauskas](https://forum.ansible.com/u/Peter_Sankauskas)\ **Post date:** [December 18, 2012, 12:42am UTC](https://forum.ansible.com/t/ansible-ec2/12074/4 "2012-12-18T00:42:24Z")
If it does, its not documented. Based on > [http://ansible.cc/docs/modules.html#ec2](http://ansible.cc/docs/modules.html#ec2) all it does is bring up a single instance ---
**Author:** ![Michael\_DeHaan](https://avatars.discourse-cdn.com/v4/letter/m/c4cdca/32.png) [@Michael\_DeHaan](https://forum.ansible.com/u/Michael_DeHaan)\ **Post date:** [December 18, 2012, 12:47am UTC](https://forum.ansible.com/t/ansible-ec2/12074/5 "2012-12-18T00:47:21Z")
Yeah it just spawns instances. I am cool with it doing more. The way the virt module works should probably be used as somewhat of a baseline, even if it is just a subset. ---
**Author:** ![Brian\_Coca1](https://avatars.discourse-cdn.com/v4/letter/b/278dde/32.png) [@Brian\_Coca1](https://forum.ansible.com/u/Brian_Coca1)\ **Post date:** [December 18, 2012, 12:54am UTC](https://forum.ansible.com/t/ansible-ec2/12074/6 "2012-12-18T00:54:45Z")
well, the hard part is getting it up and running, once inside shutdown and reboot should be available (but I can see wanting to be able to do it from outside). I’ll be setting up some instances soon, it might give me the excuse to add those. Feel free to beat me to it 😉 ---
**Author:** ![Peter\_Sankauskas](https://avatars.discourse-cdn.com/v4/letter/p/ea666f/32.png) [@Peter\_Sankauskas](https://forum.ansible.com/u/Peter_Sankauskas)\ **Post date:** [December 18, 2012, 1:20am UTC](https://forum.ansible.com/t/ansible-ec2/12074/7 "2012-12-18T01:20:01Z")
At the risk of being controversial, I disagree with the ec2 module being part of core. As it stands now, the ec2 module is just a wrapper around euca2ools (Eucalyptus), which already means I won’t use it. It could have used boto directly and removed that dependency. It also promotes running a single instance - which may be fine for R&D, but far from best practices for a production environment. In production, you would be using autoscaling groups across multiple availability zones, specific security groups, cost allocation tagging, cloudwatch alarms going to SNS, etc. All of these have dependencies between each other, but act as a single stack. That stack then needs to be easily brought up in different regions, and even different AWS accounts. This should not be part of ansible. EC2 is much bigger than any single ansible module should have to handle, which is why I believe having a separate project specific to AWS and EC2 is a better approach. It can use as much of ansible as possible, follow the same way of thinking, and provide a better process/interface than CloudFormation. Peter P.S. Werner’s keynote hit the nail on the head: [http://youtu.be/PW1lhU8n5So](http://youtu.be/PW1lhU8n5So) ---
**Author:** ![Brian\_Coca1](https://avatars.discourse-cdn.com/v4/letter/b/278dde/32.png) [@Brian\_Coca1](https://forum.ansible.com/u/Brian_Coca1)\ **Post date:** [December 18, 2012, 1:31am UTC](https://forum.ansible.com/t/ansible-ec2/12074/8 "2012-12-18T01:31:22Z")
There is also a ec2\_create in ansible-provisioning project, maybe a quick list of features/goals for each project might avoid too much overlap. ---
**Author:** ![Peter\_Sankauskas](https://avatars.discourse-cdn.com/v4/letter/p/ea666f/32.png) [@Peter\_Sankauskas](https://forum.ansible.com/u/Peter_Sankauskas)\ **Post date:** [December 18, 2012, 1:45am UTC](https://forum.ansible.com/t/ansible-ec2/12074/9 "2012-12-18T01:45:38Z")
There was: [https://github.com/ansible-provisioning/ansible-provisioning/commit/22b2db7ec88ceb6fcff6458a530cab444d0f83cb](https://github.com/ansible-provisioning/ansible-provisioning/commit/22b2db7ec88ceb6fcff6458a530cab444d0f83cb) ---
**Author:** ![Dag\_Wieers](https://avatars.discourse-cdn.com/v4/letter/d/45deac/32.png) [@Dag\_Wieers](https://forum.ansible.com/u/Dag_Wieers)\ **Post date:** [December 18, 2012, 11:24am UTC](https://forum.ansible.com/t/ansible-ec2/12074/10 "2012-12-18T11:24:58Z")
The ansible-provisioning project already has some modules doing similar things and we may want to use a similar interface for doing similar things. We have modules for libvirt (kvm), hpilo, vsphere and virtualbox. ---
**Author:** ![Seth\_Vidal](https://avatars.discourse-cdn.com/v4/letter/s/7ba0ec/32.png) [@Seth\_Vidal](https://forum.ansible.com/u/Seth_Vidal)\ **Post date:** [December 18, 2012, 3:16pm UTC](https://forum.ansible.com/t/ansible-ec2/12074/11 "2012-12-18T15:16:06Z")
> At the risk of being controversial, I disagree with the ec2 module being part of core. > As it stands now, the ec2 module is just a wrapper around euca2ools (Eucalyptus), which already means I won't use it. It could have used boto directly and removed that dependency. It could have used boto directly. If I had wanted to duplicate a giant assload of options that were already implemented in the euca2ools. I didn't want to do that. I had other things to do. If you would like to implement the ec2 module in boto I think that would be great. > It also promotes running a single instance - which may be fine for R&D, but far from best practices for a production environment. In production, you would be using autoscaling groups across multiple > availability zones, specific security groups, cost allocation tagging, cloudwatch alarms going to SNS, etc. All of these have�dependencies�between each other, but act as a single stack. That stack > then needs to be easily brought up in different regions, and even different AWS accounts. This should not be part of ansible. Except I wasn't targetting the ec2 module for ec2 use but for eucalyptus and openstack use. also originally it provided for multiple running instances using the count option - you can even see it commented out if you'd read the code. I commented it out at request of mdehaan, iirc > EC2 is much bigger than any single ansible module should have to handle, which is why I believe having a separate project specific to AWS and EC2 is a better approach. It can use as much of ansible > as possible, follow the same way of thinking, and provide a better process/interface than CloudFormation. I disagree - I think discrete modules make it reasonable to quickly get rolling and abstract out what you're doing. For example we have a buildsystem using ansible that spawns out new instances and provisions them using that ec2 module. Not every module must handle every possible case, but you're welcome to if you would like. -sv ---
**Author:** ![Peter\_Sankauskas](https://avatars.discourse-cdn.com/v4/letter/p/ea666f/32.png) [@Peter\_Sankauskas](https://forum.ansible.com/u/Peter_Sankauskas)\ **Post date:** [December 18, 2012, 5:33pm UTC](https://forum.ansible.com/t/ansible-ec2/12074/12 "2012-12-18T17:33:01Z")
> > It also promotes running a single instance - which may be fine for R&D, but far from best practices for a production environment. In production, you would be using autoscaling groups across multiple > > availability zones, specific security groups, cost allocation tagging, cloudwatch alarms going to SNS, etc. All of these have�dependencies�between each other, but act as a single stack. That stack > > then needs to be easily brought up in different regions, and even different AWS accounts. This should not be part of ansible. > > Except I wasn’t targetting the ec2 module for ec2 use but for eucalyptus > and openstack use. Right, it is not an EC2 specific module, but it happens to be called “ec2”. Future users are going to see this as the “ansible way for using EC2”, instead of simply a wrapper around a Eucalyptus script. > > EC2 is much bigger than any single ansible module should have to handle, which is why I believe having a separate project specific to AWS and EC2 is a better approach. It can use as much of ansible > > as possible, follow the same way of thinking, and provide a better process/interface than CloudFormation. > > I disagree - I think discrete modules make it reasonable to quickly get > rolling and abstract out what you’re doing. For example we have a > buildsystem using ansible that spawns out new instances and provisions > them using that ec2 module. You are right - modules are great. I never suggested doing this is 1 module, that is ludicrous. I do however believe that a separate project with many AWS modules is the best approach. Ever better, is if that project does as much as possible using the same thinking and techniques as Ansible. ---
**Author:** ![Seth\_Vidal](https://avatars.discourse-cdn.com/v4/letter/s/7ba0ec/32.png) [@Seth\_Vidal](https://forum.ansible.com/u/Seth_Vidal)\ **Post date:** [December 19, 2012, 6:11am UTC](https://forum.ansible.com/t/ansible-ec2/12074/13 "2012-12-19T06:11:28Z")
>       \> It also promotes running a single instance - which may be fine for R&D, but far from best practices for a production environment. In production, you would be using autoscaling groups >       across multiple >       \> availability zones, specific security groups, cost allocation tagging, cloudwatch alarms going to SNS, etc. All of these have�dependencies�between each other, but act as a single >       stack. That stack >       \> then needs to be easily brought up in different regions, and even different AWS accounts. This should not be part of ansible. > >       Except I wasn't targetting the ec2 module for ec2 use but for eucalyptus >       and openstack use. > > Right, it is not an EC2 specific module, but it happens to be called "ec2". Future users are going to see this as the "ansible way for using EC2", instead of simply a wrapper around a Eucalyptus > script. 1. I originally called it ec2\_create - I was asked to change the name. However it does startup and return info about ec2/euca/openstack instances and it works for a simple, yet broad, set of cases. 2. the nicest thing is you get back a set of instance ids which is important in that you can use that with all the rest of the euca or ec2 tools. 3. And if you combine this module with the ec2 inventory script you end up with a way from ansible to interact with EC2. > � > You are right - modules are great. I never suggested doing this is 1 module, that is�ludicrous. I do however believe that a separate project with many AWS modules is the best approach. Ever better, > is if that project does as much as possible using the same thinking and techniques as Ansible. I don't. I think ansible needs a way to create cloud instances - be they in ec2, euca, cloudstack, openstack or whatever else is out there. I could certainly see an ansible nova module to talk to openstack/rackspace, too. Here's the thing - the yum module, the apt module, the postgres module, the user/group module, the virt module - they don't handle every possible feature of all of those programs - but they do handle the important/significant cases and give lots of room if someone wants to add onto them. I don't think that's unreasonable at all and I really do not understand why it seems like you think it is unreasonable. -sv ---
**Author:** ![Rodney\_Quillo](https://avatars.discourse-cdn.com/v4/letter/r/7ba0ec/32.png) [@Rodney\_Quillo](https://forum.ansible.com/u/Rodney_Quillo)\ **Post date:** [December 19, 2012, 9:11am UTC](https://forum.ansible.com/t/ansible-ec2/12074/14 "2012-12-19T09:11:41Z")
ec2 module is to create cloud instances (openstack,ec2,eucalyptus) as I understand. I think other AWS functionalities (ELB,AutoScaling,RDS, etc) should not be included in that module.