Hello all,
Was just curious how to accomplish this. Right now I am launching all instances at once, so I am maximizing my chances to have all the EC2s as close as possible. As AWS and common sense advises, it’s desirable to have it like so, any subsequent EC2 launch targeting the same placement group would be having significantly lower chances to benefit from that smaller physical distance between the hypervisors.
I am managing them using the instances tags.
Thing is, I want to go the “deny all” way and the first stop for that are the Security Groups.
With my current playbooks, I can’t see any way of doing:
- create the VPC
- create the security groups with their custom settings within the VPC
- launch the WHOLE batch of EC2s at once, each EC2 in its destined security group.
The underlined part is giving me a hard time.
Perhaps someone has tried this as well and might want to share some ideas.
Thanks!
A possible approach that I will try today is:
- create the VPC
- create the security groups with their custom settings within the VPC and a dummy one
- launch the WHOLE batch of EC2s at once, in the dummy SG
4. have some subsequent tasks moving random EC2s (as they share exactly the same specs) in different SGs.
5. play around with the EC2s based on their SG membership
Unfortunately, the ec2 module (neither of the AWS related modules for that matter) doesn’t allow you modify the attributes of an EC2 instance (i.e. change its security group). I’d go as far as actually submitting this as a feature suggestion if more agree on that.
By following the steps in the second numbered list, I was able to successfully achieve my goal: launch a batch of identical EC2 instances in a placement group and automatically distribute them in their final, intended security groups.
If anyone would be interested, I can share my playbooks.
If the libraries we're using support it I think that modifying
attributes makes sense. There's many other modules which allow
modification of attributes. Care to submit a pull request for that?
-Toshio
Due to lack of time, I ended up doing it like so: created a task, delegated it to localhost and called the AWS API from the AWS CLI tools. Works nicely but too hackish.
I’ll try to dive deeper in it this weekend and see how we can do it by only using Ansible modules and then come back with a PR.
Thanks.