[chef] Re: Re: Re: Knifing multiple different chef servers

[Joshua Timberman < >]

I used a similar approach to select the chef server based on git branch name.

begin
  require 'grit'
  branch = Grit::Repo.new("#{current_dir}/..").head.name
rescue LoadError
  puts "Unable to load grit. Are you using the correct RVM gemset?"
  branch = "master"
end

case branch
when "production"
  chef_server_url "https://chef.production.example.com";
else
  chef_server_url "http://chef.development.example.com:4000";
end

On Fri, Sep 30, 2011 at 4:59 PM, KC Braunschweig
<
 >
 wrote:
> Thanks for the inspiration! In my situation i basically just have 2
> chef servers, preprod and production. I was just symlinking
> ~/.chef/knife.rb to the knife config of the server i wanted at the
> moment (I didn't really want the files in my repo). Now I've instead
> symlinked ~/bin/pknife to /usr/bin/knife and created 1 knife.rb with
> this:
>
> if File.basename($0) == 'pknife' then
>  <prod-specific stuff>
> else
>  <preprod stuff>
> end
>
> <general configs>
>
> This way by running knife I get preproduction. When I wanna touch
> prod, I just use pknife instead. No need to edit any files/symlinks
> and its always clear what I'm gonna touch if I forget what state I
> left things in. Ruby config files are cool!
>
> KC
>
>
> On Thu, Sep 29, 2011 at 6:18 AM, Bryan Brandau 
> <
 >
>  wrote:
>> In my Knife file I'm just using a simple if block like so:
>> environment = "Prod"
>> #environment = "Stage"
>> #environment = "Dev"
>> if environment ==" Prod"
>> <stuff here>
>> elseif environment == "Stage"
>> <stuff here>
>> elseif environment == "Dev"
>> <stuff here>
>> end
>>
>> All I do is change the comment to the environment/application that I want.
>>  It's worked well and simple.
>>
>> On Thu, Sep 29, 2011 at 7:34 AM, Geoff Meakin Acid
>> <
 >
>>  wrote:
>>>
>>> Hi all,
>>> I came across an annoyance in that, I now have set up several chef
>>> infrastructures, production/staging/test/dev etc., and opted to have each
>>> one have its own chef server as they span different physical locations.
>>> However the standard knife client reads its config from /etc/chef/*.pem ,
>>> or ~/.chef/*.pem  by default.
>>> I notice you can override this to locations of your choice via a knife.rb
>>> file, which can be located in $(pwd)/.chef/knife.rb  or ~/.chef/knife.rb 
>>> or
>>> /etc/chef/knife.rb
>>> Which is great, as now I can have multiple knife files in different
>>> locations, for each of the chef servers (which I've done).
>>> Only problem is "knife configure -i" which is the documented way to
>>> register yourself as a client of each chef server… this attempts to 
>>> override
>>> whatever knife.rb file it finds.. not very helpful as I've already
>>> configured my various knife.rb files to look at different servers with
>>> different 'environment' attributes. I dont want to have all these manual
>>> steps of post-configuring knife.rb files, I want my knife.rb files 
>>> committed
>>> to git so I can just run&go (™)
>>>
>>>
>>> For my solution, I created a bunch of different directories -
>>> chef-production / chef-staging / chef-dev etc., and in each of those had a
>>> .chef/knife.rb file configuring knife to the correct place.
>>> Furthermore, in each of the directories, I had a subdir "setup" with a
>>> script which copies the relevant validation/webui.pems into ~/.chef, runs
>>> knife against them with no setup/.chef/knife.rb to be found (it doesnt
>>> exist), and copies the resultant client.pem out into the correct
>>> directories, so each knife client is totally self contained with all its
>>> certs. It drives knife configure -i via expect to do this.
>>> A bit of jumping through hoops, but it works a treat.
>>> However, it strikes me as inelegant and I would be interested to hear your
>>> views on how you solved this (for those that did).
>>>
>>>
>>>
>>> --
>>> Geoff
>>
>



-- 
Opscode, Inc
Joshua Timberman
IRC, Skype, Twitter, Github: jtimberman