I can’t really speak to #1 because we are using Hosted Chef.
As for #2, however, I would strongly suggest setting up an SSH gateway in order to do this. The other methods of automating this bootstrapping process are all pretty complicated to pull off.
If you can’t go the gateway route, I created a fork of the knife-ec2 plugin that tries to solve this problem by adding a “without-ssh” option (https://github.com/evertrue/knife-ec2/). Basically the bootstrap template is uploaded to an S3 bucket, then a URL for that template with a very short expiration time is included in the node user data. This allows the node to bootstrap completely “headless.” It does make debugging the bootstrap process a bit tricky, but it works.
The problem with the “adding an elastic IP” route is that it requires the addition of a second network interface which must reside on a public subnet. At least on Ubuntu, this interface is not automatically configured by the OS, and even after it’s configured, the OS will not understand how to route traffic to your management console over it without the addition of a static route. This makes it almost impossible to bootstrap a server this way if you don’t want it to reside primarily on a public subnet (at least by any way that I’ve been able to decipher).
I hope this helps. Feel free to email me directly if you want more detailed help getting this working. I’ve spent a lot of time mucking with the VPC bootstrapping process at this point.
On Feb 10, 2014, at 10:14 PM, Ritesh Angural firstname.lastname@example.org wrote:
Just trying to get an idea of best practices or thoughts on using chef server with VPC.
Specifically I have two questions, but I would like to leave this open to any other suggestions
or “how we’ve done it” as well.
Having the chef server itself in the VPC vs having it as a public EC2. Is this a good idea or bad idea?
When bootstrapping nodes into VPC via knife-e2, we need to attach elastic ip to the node first.
(See this post). What’s the best way to do this, or how have you done it?