# ec2\_run\_instance library module **URL:** \ **Category:** Ansible Project\ **Created:** [October 25, 2012, 6:17am UTC](https://forum.ansible.com/t/ec2-run-instance-library-module/12025 "2012-10-25T06:17:25Z")\ **Posts on this page:** 4\ **Page:** 1
**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:** [October 25, 2012, 6:17am UTC](https://forum.ansible.com/t/ec2-run-instance-library-module/12025/1 "2012-10-25T06:17:25Z")
Not sure if anyone else has already done this. But I needed to start up an instance, get back the instance id cleanly so I could then setup the instance. So I hacked this up last night: [https://github.com/skvidal/ansible/blob/devel/library/ec2\_run\_instance](https://github.com/skvidal/ansible/blob/devel/library/ec2_run_instance) I put in a pull request for it to ansible itself - but it may belong to ansible-provisioning more accurately. Here's how I was using it from a playbook: - hosts: 210.121.212.112    user: root    gather\_facts: False   tasks:    - name: spin it up      local\_action: ec2\_run\_instance keypair=skvidal image=emi-3F1C4010 type=m1.large      register: inst\_res    - name: assign it a special ip      local\_action: shell euca-associate-address -i ${inst\_res.instances[0].id} 210.121.212.112    - name: wait for the reassignation      local\_action: wait\_for host=210.121.212.112 port=22 delay=20    - name: give it a better hostname:      action: command hostname ec2\_ansibled my eventual goal is to use this from my admin host to keep certain cloud instances always up and to make sure they get a specific ip, volumes attached, etc. it does not implement everything that euca-run-instance implements but I got all of the functionality I care about at this very moment. If anyone wants to add things on - patches welcome. -sv ---
**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:** [October 25, 2012, 11:06am UTC](https://forum.ansible.com/t/ec2-run-instance-library-module/12025/2 "2012-10-25T11:06:46Z")
Very very cool. If the host already existed in inventory (and we do need to think about dynamic inventory, REST API is going to help), you could easily pass in some parameters with --extra-vars and have a pretty tight solution for deploying it and then starting to manage it, probably including some very nice wrapper scripts. Assuming the "euca-associate-address" stuff is Eucalyptus specific, so not entirely sure of how that looks in ec2, but very interested in exploring. I have suggested we merge this with the ansible-provisioning project: [https://github.com/ansible/ansible-provisioning](https://github.com/ansible/ansible-provisioning) (BTW, I still am going to make Contrib modules move from a README.md to part of the docs project so everybody finds it -- and that can include a short blurb about my people should explore ansible-provisioning) There are some assumptions about ansible-provisioning that I think we still need to change, such as the usage of 'cmdb' variables. Not everyone is going to have a 'cmdb', so we should probably just rename those to something simple. What we may do in the near short-term, I don't know, is make library modules be able to live in subfolders, so we can namespace them. So you could do things like "provisioning\_blarg" Perhaps pedantic, but I think the "ec2\_run\_instance" is a bit long, maybe "ec2\_launch" ? ---
**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:** [October 25, 2012, 12:50pm UTC](https://forum.ansible.com/t/ec2-run-instance-library-module/12025/3 "2012-10-25T12:50:50Z")
> Very very cool. If the host already existed in inventory (and we do > need to think about dynamic inventory, REST API is going to help), you > could easily pass in some parameters with --extra-vars and have a > pretty tight solution for deploying it > and then starting to manage it, probably including some very nice > wrapper scripts. Which is exactly what I'm gonna do. > Assuming the "euca-associate-address" stuff is Eucalyptus specific, so > not entirely sure of how that looks in ec2, but very interested in > exploring. No - that's an ec2-generic. It's not euca-special. > I have suggested we merge this with the ansible-provisioning project: > [https://github.com/ansible/ansible-provisioning](https://github.com/ansible/ansible-provisioning) No problem - I'll talk to dag about that. > (BTW, I still am going to make Contrib modules move from a README.md > to part of the docs project so everybody finds it -- and that can > include a short blurb about my people should explore > ansible-provisioning) > > There are some assumptions about ansible-provisioning that I think we > still need to change, such as the usage of 'cmdb' variables. Not > everyone is going to have a 'cmdb', so we should probably just rename > those to something simple. understood - I didn't really get what the cmdb was when I read through the code for the first time so it was kinda blurry to me. I was planning on just storing the variables I need in host\_vars of my inventory. > What we may do in the near short-term, I don't know, is make library > modules be able to live in subfolders, so we can namespace them. So > you could do things like "provisioning\_blarg" not a problem. one nice thing about how ansible fits together is I can just keep this is my local library dir and have it all work w/o a headache 🙂 > Perhaps pedantic, but I think the "ec2\_run\_instance" is a bit long, > maybe "ec2\_launch" ? fine - renaming it doesn't bother me. I just chose run\_instance b/c it's the same name as the script in ec2/euca. thanks for the feedback, -sv ---
**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:** [October 25, 2012, 5:57pm UTC](https://forum.ansible.com/t/ec2-run-instance-library-module/12025/4 "2012-10-25T17:57:02Z")
> There are some assumptions about ansible-provisioning that I think we > still need to change, such as the usage of 'cmdb' variables. Not > everyone is going to have a 'cmdb', so we should probably just rename > those to something simple. The cmdb variables are examples, they might come from your host\_vars or group\_vars, it really does not matter. The modules are not tight to this at all. But I cannot give you an example for provisioning HP iLO, VMware and KVM with a single playbook, without having some clue what each hostname is. Which is where in this case the cmdb\_ variables are used for, as an example. > What we may do in the near short-term, I don't know, is make library > modules be able to live in subfolders, so we can namespace them. So > you could do things like "provisioning\_blarg" I don't think anything needs to be done. The ansible-provisioning rpm just drops the modules in the normal place for those that want to use them.