Discussion:
[ansible-project] IP whitelisting challenge
Gary Malouf
2015-07-13 15:58:04 UTC
Permalink
We have used Ansible to automate all of our deployments to EC2 (via the EC2
packages included with Ansible) and custom roles for our own services. Our
production instances run in a vpc within public subnets.

In order to do an integration with a partner, we've been asked to provide a
range of ip addresses from which we will send them http requests. While
one approach is to use elastic ips, this is quite limiting if we need to
scale up our number of instances. Is there a cleaner way to do this in EC2
via Ansible - i.e. ensure the public ips of all instances in a subnet fall
within the same range?
--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-project+***@googlegroups.com.
To post to this group, send email to ansible-***@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/daae187d-4809-4c44-9080-90f48112024c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Brian Coca
2015-07-13 16:03:06 UTC
Permalink
I don't think Ansible is your limiting factor, it is AWS.
--
Brian Coca
--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-project+***@googlegroups.com.
To post to this group, send email to ansible-***@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CAJ5XC8kBddXkbQKWbpDgHxo_Rt5GfqBtpXd59qr4RA0e4FAqng%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Jon Hadfield
2015-07-13 17:10:27 UTC
Permalink
I had a similar issue, the difference being that I'm using only private
addresses within the VPC subnets.
As Brian said, your limiting factor is AWS, so apologies if the following
is a bit off-topic for this group...

The solution I used was to use ansible to automate a redundant pair of NAT
instances in separate subnets based on the following
guide: http://aws.amazon.com/articles/2781451301784570. By setting the
service's subnets to have a default gateway of the NAT instance in the
respective AZ, you ensure all instances in the subnet advertise on the
static NAT instance IP. It also allows for auto-scaling as the route is set
at the subnet level and inherited by all instances.

This is a functional solution but does suffer from a number of drawbacks,
e.g. not an instant failover if a NAT instance fails, your throughput is
limited by the instance types for the NAT instances, etc.
--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-project+***@googlegroups.com.
To post to this group, send email to ansible-***@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/02d2861b-61f5-4416-8f48-486cc82b1619%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Gary Malouf
2015-07-13 18:59:46 UTC
Permalink
Thanks Jon, I appreciate hearing how you handled this. Apologies that my
issue was not limited by Ansible.
Post by Jon Hadfield
I had a similar issue, the difference being that I'm using only private
addresses within the VPC subnets.
As Brian said, your limiting factor is AWS, so apologies if the following
is a bit off-topic for this group...
The solution I used was to use ansible to automate a redundant pair of NAT
http://aws.amazon.com/articles/2781451301784570. By setting the service's
subnets to have a default gateway of the NAT instance in the respective AZ,
you ensure all instances in the subnet advertise on the static NAT instance
IP. It also allows for auto-scaling as the route is set at the subnet level
and inherited by all instances.
This is a functional solution but does suffer from a number of drawbacks,
e.g. not an instant failover if a NAT instance fails, your throughput is
limited by the instance types for the NAT instances, etc.
--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-project+***@googlegroups.com.
To post to this group, send email to ansible-***@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/362190ec-84aa-4d87-ad77-1a33d1b5bf75%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Loading...