Hi Douglas,Our setup may be a bit different than yours but I have opted to use environment data bag items. A lot of our settings, including the environment name, flow down from the outputs on the CloudFormation VPC template we use to launch the environment/vpc. We can setup arbitrary environments and just generate a databag with specifics after it's up. The environment name provided into the CloudFormation VPC flows down into other infrastructure we provision into it. The bootstrap code on the ec2 instances sets the nodes environment based on this, then any recipe that needs to can grab the environment databag to get endpoints for logging, our API server, etc.This has worked well for me with testing locally too. I have a "local" environment databag item and set the environment to "local" in my Vagrant file.-GregOn Tue, Mar 18, 2014 at 9:18 AM, Jeff Byrnes < " target="_blank"> > wrote:
Unfortunate that you had issues using knife-ec2 with an SSH gateway; I worked that out like so:
knife ec2 server create \ --environment stage \ --node-name stage-new-instance \ --flavor m1.small \ --ssh-gateway \ --ssh-user ec2-user \ --security-group-ids sg-dd0bc0b6 \ --run-list "recipe[et_base]"I'd encourage taking one last quick stab at using knife-ec2 for this, as it will simplify a lot of things.
As an aside, eventually, we avoided using an SSH proxy by forking knife-ec2 (see https://github.com/evertrue/knife-ec2) to not handle the initial provision directly, but instead by pushing user data to S3, and using a signed URL to bootstrap the node. See my compatriot’s commits at evertrue/knife-ec2.
On March 17, 2014 at 4:12:52 PM, Daniel Condomitti ( " target="_blank"> ) wrote:
I would just include bc-location::default and place the location-detection logic in that recipe based on the EC2 availability zone or the GCE equivalent. You can always swap out how that’s handled (even a huge case statement for now just to get everything working if you’re facing a deadline) with a better approach later. This way you can keep all that ugly logic abstracted away and out of the rest of your cookbooks.We use a combination of chef searches (service discovery), cookbook attributes (node-specific configuration like users and locations) and data bags (environment-specific configuration data and sensitive stuff like keys) which isn’t perfect but it works well for us.On Monday, March 17, 2014 at 1:07 PM, Douglas Garstang wrote:
Daniel,Using Jeff's approach above, I'd still need to useinclude_recipe "bc-location::#{some-special-key-to-determine-location}"
in every situation where this data was needed, correct? Am I the only one that thinks this is ugly?Doug.
On Mon, Mar 17, 2014 at 12:59 PM, Daniel Condomitti < " target="_blank"> > wrote:
You don’t need to use knife-ec2 to get those attributes. Create /etc/chef/hints/ec2.json (empty file is fine) and ohai will automatically set a LOT of instance metadata attributes including ec2.placement_availability_zone.On Monday, March 17, 2014 at 12:51 PM, Douglas Garstang wrote:
Jeff,We are using EC2 (and GCE). However, we aren't using knife to provision systems. We weren't able to get the knife ec2 plugin to work with an ssh proxy and gave up in the end.I just tried a different approach, where I have one cookbook, with one recipe per location. This gets around the issue of having to depend on an arbitrary list of location cookbooks in the metadata.rb of every cookbook we write. However, the trade-off is that I have to do this:include_recipe "bc-location::#{some-special-key-to-determine-location}"every single time I need to access location data. This is horrid. I simply can't understand why people keep saying not to use roles. Roles are just so much more convenient. All the include magic is done automatically for you.Douglas.
On Mon, Mar 17, 2014 at 11:23 AM, Jeff Byrnes < " target="_blank"> > wrote:
Doug:I’m not sure if you’re using EC2, but if so, and you’re launching instances using knife-ec2, you should have node['ec2']['placement_availability_zone'] available. You could build a single wrapper cookbook, that depends on that attribute’s value, and determines the requisite data center-specific attributes.
On March 17, 2014 at 1:54:21 PM, Douglas Garstang ( " target="_blank"> ) wrote:
Doing what I read to be a best practice, I just took a bunch of roles that defined set attributes for specific data centers, and moved them into cookbooks, one per location, ie:bc-location-u1bc-location.eu1and so on. I just occurred to me that if I do this, then all cookbooks will need to depend (in the metadata.rb) file on ALL of these location based cookbooks.is this correct? What am I missing?Doug
--
Regards,
Douglas Garstang
http://www.linkedin.com/in/garstang
Email: " target="_blank">
Cell: +1-805-340-5627
--
Regards,
Douglas Garstang
http://www.linkedin.com/in/garstang
Email: " target="_blank">
Cell: +1-805-340-5627
Archive powered by MHonArc 2.6.16.