I have a singular chef server managing several peered VPC environments.
My concern is with the nodes registering from different accounts and if/when they have matching IP address.
For instance, in VPC-1, instance-1 has x.x.x.x and in VPC-2, instance-1 also manages to get x.x.x.x.
Will the chef server prevent the second one from registering? If I change host name for these things to include something identifying and unique, how does chef-server manage that connection when there are two matching IP addresses behind the scenes?
We have a similar setup with a chef server managing multiple Accounts and
multiple VPcs, and my suggestion would entail have a proper network
architecture in place to avoid these situations, not only for Chef’s sake
but also for AWS as you don’t want to have conflicting IPs in your
landscape.
But to answer your question, I don’t believe chef would be able to
determine by IP only which IP should register unless you have other
identifying attributes that would trigger this response from Chef.
Yeah - think hub-and-spoke - where the chef server is in the middle.
None of the spokes will be connected to each other (so it doesn’t matter for the products what cidr blocks they choose).
My question was more if ip-10-1-1-24 tries to connect to the chef server twice (from two different accounts), how does chef handle this? There will be things about that node that make it unique, just not sure how or if chef can handle this or should I (like you said) rule these networks a bit more with an iron fist.
The IP address of the Chef node should have no bearing for registration or check-in, although if you review Chef logs, Chef Server identifies the node by its unique name in the organization—node name is where you’ll want to be careful and use a guaranteed unique value.
In EC2, I’d use the instance ID as the node name during registration. If the node is registering itself, you can get this from EC2’s instance metadata: curl --silent http://169.254.169.254/latest/meta-data/instance-id