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


Chronological Thread 
  • From:
  • To:
  • Subject: [chef] Re: Re: defining a global variable to avoid sprinkles
  • Date: Mon, 9 Jan 2012 13:25:31 -0800

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.
 
> > 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.

> 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.

> Hope this helps?
 
it does. thanks!

> Cheers,
> 
> --AJ



Archive powered by MHonArc 2.6.16.

§