Ohai Chefs!
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.
My questions:
-
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 posthttp://clarkdave.net/2013/05/creating-ec2-instances-in-an-amazon-vpc-using-chef-and-knife/).
What’s the best way to do this, or how have you done it?
Thanks!
Ritesh
Hi Ritesh,
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 (GitHub - evertrue/knife-ec2: Opscode Chef knife plug-in for 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 ritesh.angural@gmail.com wrote:
Ohai Chefs!
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.
My questions:
-
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?
Thanks!
Ritesh
On Feb 10, 2014, at 9:14 PM, Ritesh Angural ritesh.angural@gmail.com wrote:
- Having the chef server itself in the VPC vs having it as a public EC2. Is this a good idea or bad idea?
In my experience, so long as you only ever have just the one VPC, you're fine with having the Chef server on a subnet inside that VPC.
Where I have seen things break in the past is when you have more than one VPC and you have a need to route traffic from one to the other -- like talking to your Chef server.
The "easy" way out of this problem is to put the Chef server out in EC2-land, and not have to try to route from one VPC to another.
I have yet to hear of any solutions to the problem of needing to route from one VPC to another.
- 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?
What I have been able to do [0], is to create the elastic IP first, then create the node, and then assign the elastic IP to the node.
[0] By "do", I mean something that I have done manually via the AWS console. I have never tried to do this in an automated fashion, whether with Chef or CloudFormation, or anything else.
--
Brad Knowles brad@shub-internet.org
LinkedIn Profile: http://tinyurl.com/y8kpxu
Note that there is this flag for knife-ec2:
--associate-eip IP_ADDRESS Associate existing elastic IP address with instance after launch
On Feb 10, 2014, at 11:41 PM, Brad Knowles brad@shub-internet.org wrote:
On Feb 10, 2014, at 9:14 PM, Ritesh Angural ritesh.angural@gmail.com wrote:
- Having the chef server itself in the VPC vs having it as a public EC2. Is this a good idea or bad idea?
In my experience, so long as you only ever have just the one VPC, you're fine with having the Chef server on a subnet inside that VPC.
Where I have seen things break in the past is when you have more than one VPC and you have a need to route traffic from one to the other -- like talking to your Chef server.
The "easy" way out of this problem is to put the Chef server out in EC2-land, and not have to try to route from one VPC to another.
I have yet to hear of any solutions to the problem of needing to route from one VPC to another.
- 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?
What I have been able to do [0], is to create the elastic IP first, then create the node, and then assign the elastic IP to the node.
[0] By "do", I mean something that I have done manually via the AWS console. I have never tried to do this in an automated fashion, whether with Chef or CloudFormation, or anything else.
--
Brad Knowles brad@shub-internet.org
LinkedIn Profile: http://tinyurl.com/y8kpxu