sirkubax
2015-07-14 12:16:49 UTC
*THE PROBLEM:*
I've just realised why sometimes my playbook fills the template with false
data
This happens, when the instance is in my VPC subnet (with internet
gateway), while in configuration there is *NAT route table on the system
level*, then *reguest to the internet goes through NAT instance *and the
AWS response is *covered.*
Then the* NAT_instance facts *are *returned*, NOT the current_instance
facts about.
*THE DEBUGGING:*
If You look into the code, the ec2_facts fetch a bunch of requests to
'http://169.254.169.254/latest/meta-data'
in Example:
curl http://169.254.169.254/latest/meta-data/local-ipv4
*172.16.0.200*
while* real data* is
eth0: ***
inet *172.16.0.110*/24 brd 172.16.0.255 scope global eth0
THE INSTANCE CONFIGURATION:
$ ip r
default via 172.16.0.200 dev eth0
172.16.0.0/24 dev eth0 proto kernel scope link src 172.16.0.110
172.16.0.0/16 via 172.16.0.1 dev eth0
$ ip a
eth0: ***
inet *172.16.0.110*/24 brd 172.16.0.255 scope global eth0
If You keep remote files, You can check it Yourself
export ANSIBLE_KEEP_REMOTE_FILES=1
and then
python
/home/ubuntu/.ansible/tmp/ansible-tmp-1436872330.49-72199016469620/ec2_facts
will return as one of the facts:
"ansible_ec2_local_ipv4": "172.16.0.200",
(or run a curl)
curl http://169.254.169.254/latest/meta-data/local-ipv4
*THE CURRENT WORKAROUND:*
1. do NOT use (in *roles *nor *tasks*)
1. - action: ec2_facts
2. DRAWBACKS:
1. You will not have some variables available (*ansible_ec2_* will
be unavailable)*
2. You will have only *ec2_* facts *from you LOCAL* inventory
cache (ec2.py* if I'm correct now)
3. If You add in playbook ("gather_facts: True") then You can also
use *ansible_* facts *gathered by *setup.py* module
1. so instead of *ansible_ec2_local_ipv4* You can use
*ansible_eth0['ipv4]['address']*
4. *BUT* this can bring some problems when You have a role, that
expects some vatiable (example: ansible_hostname), but in the playbook You
have disabled system fact gathering ("gather_facts: False") - You
will have to be carefull
5. *OR* You would like to access some AWS variable, independent
form Your LOCAL cache
2. configure you VPC routing tables so it will point to
NAT-instance-interface, rather than IP address
1. 0.0.0.0/0 eni-xxx / i-xxx
1. instead of:
1. 0.0.0.0/0 igw-zzzzz + system routing tables
2. Then You do not have to override the routing table on the system
level
3. You rely on AWS Router
4. DRAWBACKS
1. You will have to change the routing table in the VPC, pointing
to other phisical interface, when Your NAT instance will shut down
1. vs
2. If kept with system routing table, You will lunch new
NAT-instance with "old IP address" attached
*QUESTIONS / CONCLUSION:*
1. Be aware about ec2_facts limitation
2. If possible - rely on Amazon Routing Table
1. How You prevent SPOF in Your VPC subnets?
2. What is Your best-practise to configure VPC subnet (private and
public), so they have internet outside access (for github, apt), and are
still safe without SPOF that is NAT-instance?
I've just realised why sometimes my playbook fills the template with false
data
This happens, when the instance is in my VPC subnet (with internet
gateway), while in configuration there is *NAT route table on the system
level*, then *reguest to the internet goes through NAT instance *and the
AWS response is *covered.*
Then the* NAT_instance facts *are *returned*, NOT the current_instance
facts about.
*THE DEBUGGING:*
If You look into the code, the ec2_facts fetch a bunch of requests to
'http://169.254.169.254/latest/meta-data'
in Example:
curl http://169.254.169.254/latest/meta-data/local-ipv4
*172.16.0.200*
while* real data* is
eth0: ***
inet *172.16.0.110*/24 brd 172.16.0.255 scope global eth0
THE INSTANCE CONFIGURATION:
$ ip r
default via 172.16.0.200 dev eth0
172.16.0.0/24 dev eth0 proto kernel scope link src 172.16.0.110
172.16.0.0/16 via 172.16.0.1 dev eth0
$ ip a
eth0: ***
inet *172.16.0.110*/24 brd 172.16.0.255 scope global eth0
If You keep remote files, You can check it Yourself
export ANSIBLE_KEEP_REMOTE_FILES=1
and then
python
/home/ubuntu/.ansible/tmp/ansible-tmp-1436872330.49-72199016469620/ec2_facts
will return as one of the facts:
"ansible_ec2_local_ipv4": "172.16.0.200",
(or run a curl)
curl http://169.254.169.254/latest/meta-data/local-ipv4
*THE CURRENT WORKAROUND:*
1. do NOT use (in *roles *nor *tasks*)
1. - action: ec2_facts
2. DRAWBACKS:
1. You will not have some variables available (*ansible_ec2_* will
be unavailable)*
2. You will have only *ec2_* facts *from you LOCAL* inventory
cache (ec2.py* if I'm correct now)
3. If You add in playbook ("gather_facts: True") then You can also
use *ansible_* facts *gathered by *setup.py* module
1. so instead of *ansible_ec2_local_ipv4* You can use
*ansible_eth0['ipv4]['address']*
4. *BUT* this can bring some problems when You have a role, that
expects some vatiable (example: ansible_hostname), but in the playbook You
have disabled system fact gathering ("gather_facts: False") - You
will have to be carefull
5. *OR* You would like to access some AWS variable, independent
form Your LOCAL cache
2. configure you VPC routing tables so it will point to
NAT-instance-interface, rather than IP address
1. 0.0.0.0/0 eni-xxx / i-xxx
1. instead of:
1. 0.0.0.0/0 igw-zzzzz + system routing tables
2. Then You do not have to override the routing table on the system
level
3. You rely on AWS Router
4. DRAWBACKS
1. You will have to change the routing table in the VPC, pointing
to other phisical interface, when Your NAT instance will shut down
1. vs
2. If kept with system routing table, You will lunch new
NAT-instance with "old IP address" attached
*QUESTIONS / CONCLUSION:*
1. Be aware about ec2_facts limitation
2. If possible - rely on Amazon Routing Table
1. How You prevent SPOF in Your VPC subnets?
2. What is Your best-practise to configure VPC subnet (private and
public), so they have internet outside access (for github, apt), and are
still safe without SPOF that is NAT-instance?
--
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/e901c654-1d06-46c2-8c7b-09253c96d235%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
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/e901c654-1d06-46c2-8c7b-09253c96d235%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.