Hi everyone,
I’ve just been getting to grips with Chef and AWS the past few weeks so bear with me if I say anything silly.
I’m trying to set up a basic chef configuration (workstation - server - node) within AWS, I had first configured the system with elastic IPs assigned to both the server and node but realized that this could be expensive as I increase the number of nodes. Since the server and node are on the same subnet would it be possible to connect to the server by the public IP from the workstation but then connect the server to each node over their private IPs?
Is there a way to reassign elastic IPs as and when they’re needed which is easy to implement?
Are elastic IPs even required? I would imagine I have to be rebooting the nodes often.
I’d also appreciate any tips or pointers anyone would have in general.
I’ve almost exclusively been using Learn Chef Rally so far.
Thank you for your time 
You definitely don’t need elastic ips on the nodes.
The nodes will reach out to the chef server, using the ip/host name stored in the client.rb. As long as they can resolve and route to that address, they will reach the chef server.
Ohai ingests the public IP, so you can do dynamic things with it, again without using elastic ips.
You can also route to the chef server on a private IP, this is particularly useful as you get to production, as it rarely makes sense for your chef server to be publicly accessible.
-Mobile Galen
1 Like
So configure the chef_server_url of the chef.rb file on the server to connect via the private DNS?
That also makes sense about the chef server. In terms of the actual ChefDK is it advised to install it on an ec2 instance of its own or on a local machine? Or is this just a matter of preference?
Thanks.
UPDATE: Changing the chef_server_url to the internal address of the server is resulting in an ssl verification error, will I have to use openssl to produce one or does chef have an integrated solution?
It doesn’t matter which IP it hits. I recommend you keep the workstation setup and the client setup the same. If you use bootstrap, it’ll populate the client.rb based on your workstation’s knife.rb. So either a DNS name or an IP that both systems can hit makes sense. The nodes don’t need to have a static IP to hit the chef server. The chef server doesn’t care what IP the node has, so no need for elastic IPs, or even public ones so long as they can reach the chef server.
The chef server does care that node’s have unique node names. By default thats the FQDN of the node.
In regards to ChefDK: Wherever you plan to write chef cookbooks is where the ChefDK should go. Some environments that’s in EC2, but primarily that’s your local system.