[chef] Re: Re: Re: defining a global variable to avoid sprinkles


Chronological Thread 
  • From: AJ Christensen < >
  • To:
  • Subject: [chef] Re: Re: Re: defining a global variable to avoid sprinkles
  • Date: Tue, 10 Jan 2012 10:46:12 +1300

Hey hey,

On 10 January 2012 10:25,  
< >
 wrote:
> On Tue, 10 Jan 2012, AJ Christensen wrote:
>
>> Yo,
>>
>> Couple of anti-patterns emerging in this post, quick attempt to enlighten:
>
> hi. yeah i was feeling kinda anti-patterny here... and realizing my example
> here wrt setting a subdomain isn't a good example. anyway, good learning
> opportunity. see inline (not much more to add, just responses)..
>
>
>> On 10 January 2012 09:40,  
>> < >
>>  wrote:
>> >
>> > i'm finding myself sprinkling my cookbooks with repeated code, and 
>> > wondering
>> > how i can do this differently. i'm in ec2. let's say i want to define
>> > subdomains keyed off of 2 things: a userdata setting and
>> > placement_availability_zone:
>> >
>> > if userdata contains "-e dev" and av zone matches us-east-1, subdomain 
>> > is dev.abfabreunion.com.
>> > if userdata contains "-e prod" and av zone matches us-east-1, subdomain 
>> > is prod.abfabreunion.com.
>> > and so on.
>> >
>> > i'd want to make that derived subdomain available to all of my 
>> > cookbooks. is
>> > there a way to do that in chef without sprinkling my code with the 
>> > following?
>> >
>>
>> In general the logical identifier of a node as a hostname is often set
>> up by sysadmins.
>>
>> Are the hostnames you mention below registered automatically via API
>> or similar, or manually managed?
>
> at this time hostnames such as mail1.dev.abfabreunion.com are manually
> managed. one goal here is to have easily derivable smtp relay hosts "per
> environment", however the bounds of an environment are defined.

Something to consider here may be the dnsimple or dynect cookbooks,
check them out. Once you can logically identify these machines by
role/environment, you could easily have them register their own host
names.

https://github.com/heavywater/chef-dnsimple
https://github.com/opscode/cookbooks/tree/master/dynect

disclaimer: I am partnered with http://www.hw-ops.com/ who manage
operations for dnsimple, we use this cookbook for the majority of our
clients that require automated DNS

>
>> > mrepo/attributes/default.rb:
>> >
>> > if node[:ec2][:userdata] =~ /-e dev/ && 
>> > node[:ec2][:placement_availability_zone] =~ /us-east-1/
>> >  node.default[:mrepo][:smtpserver] = "mail1.dev.abfabreunion.com"
>> > elsif node[:ec2][:userdata] =~ /-e prod/ && 
>> > node[:ec2][:placement_availability_zone] =~ /us-east-1/
>> >  node.default[:mrepo][:smtpserver] = "mail1.prod.abfabreunion.com"
>> > elsif node[:ec2][:userdata] =~ /-e prod/ && 
>> > node[:ec2][:placement_availability_zone] =~ /us-west-2/
>> >  node.default[:mrepo][:smtpserver] = "mail1.prod2.abfabreunion.com"
>> > end
>>
>> In this particular case, the obvious solution to me is to use Chef
>> Search to locate the smtp server for the environment.
>
> ah yes, Chef Search. i'm just starting to scratch at that..
>
>> Consider something like
>>
>> # just a node, so you can access the usual stuff
>> mrepo_smtpserver = search(:node, "role:whatever_smtp_role AND
>> ec2_placement_availability_zone:us-east-1 AND
>> chef_enviornment:#{node.chef_environment}")
>> mrepo_smtpserver[:ec2][:public_hostname]
>>
>> You could easily store these attributes in a databag, instead of on
>> the node itself, too.. e.g.:
>>
>> mrepo_smtpserver = data_bag_item "mrepo_smtpserver", node.chef_environment
>
> i will give both of these suggestions a try. it's still not clear to
> me when to use attrs vs data bags.

I tend to use data bags when the information I'm storing is illogical
to store on a node - when it is not node-centric at all, more business
centric, or human-knowledge-required.. Credentials and stuff like
that. EBS device grouping/mappings.. SSL certificates.. that kind of
stuff.

>
>> Anyway I'm circling back to my original point: you should avoid hard
>> coding "target" attributes on client systems and instead make use of
>> one of many methods for dynamically registering or locating parts of
>> your infrastructure.
>
> absolutely agreed. this is a part of chef i need to start getting
> practice on.

There are some more advanced tools which may be worth researching down
the track, or alongside, in order to gain a better view of dynamic
infrastructure composition.

John Vincent's Noah springs to mind, and the zookeeper example
cookbooks that Netflix published may be handy too.

https://github.com/lusis/noah
https://github.com/Netflix/curator/tree/master/curator-recipes/src/main/java/com/netflix/curator/framework/recipes

>> Hope this helps?

--AJ



Archive powered by MHonArc 2.6.16.

§