ansible-ec2

Archives Ansible Project
1

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

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

2

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

3

i believe the ec2 module in core already does that

4

If it does, its not documented. Based on

http://ansible.cc/docs/modules.html#ec2

all it does is bring up a single instance

5

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.

6

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 :wink:

7

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

8

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.

9

There was:
https://github.com/ansible-provisioning/ansible-provisioning/commit/22b2db7ec88ceb6fcff6458a530cab444d0f83cb

10

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.

11

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

12

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.

13

      > 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

14

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.