Does anyone have any suggestions about how to deal with multiple environments/tiers? For instance, we have several environments ( production, dev, qa, etc.. ) and within each environment, different tiers ( web, data, app, etc ). Each tier is a different IP network segment, so all the hosts in each tier have different configurations for certain things like resolv.conf, ntp.conf and so on. We do subdomain each tier off, so we have web.qa.example.com, data.qa.example.com, etc. Should I just be defining a module for say, resolv.conf, with a case statement on $domain and just point to the proper resolv.conf file for the tier? Any suggestions on how to proceed and architect this would be helpful. :) Thanks. steve --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
I have the same question with you, at this time, I define some vaules
to do this.
like $app,$env. then when get the file from puppetmaster, I use this
mainifest.
file{ "somefile":
source=>"puppet:///somefile.${app}.${env}"};
On May 6, 3:20 pm, "hajdu...@gmail.com" <hajdu...@gmail.com>
wrote:> Does anyone have any suggestions about how to deal with multiple
> environments/tiers?
>
> For instance, we have several environments ( production, dev, qa,
> etc.. ) and within each environment, different tiers ( web, data, app,
> etc ). Each tier is a different IP network segment, so all the hosts
> in each tier have different configurations for certain things like
> resolv.conf, ntp.conf and so on.
>
> We do subdomain each tier off, so we have web.qa.example.com,
> data.qa.example.com, etc.
>
> Should I just be defining a module for say, resolv.conf, with a case
> statement on $domain and just point to the proper resolv.conf file for
> the tier?
>
> Any suggestions on how to proceed and architect this would be
> helpful. :)
>
> Thanks.
>
> steve
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---
I would follow this approach:
- a single inheritance tree where relevant variable can be defined at
different leves: node inherits tier inherits environment
- differentiation of files according to templates that used $env $tier
variables defined in respective places OR, according to each case,
sourcing of differnet files as described by huangminyou with something
like source=>"puppet:///somefile.${app}.${env}, even if, according to
me, the usage of two variables on the same filename may lead to a
plethora of different files (in these cases a template would be
better).
For example:
node basenode {
$puppet_server = "CHANGE:Ip"
$ntpserver = "CHANGE:Ntpserver"
$update = "no" # Auto Update packages (yes|no)
$root_email = "CHANGE:Email" # Noc Email
}
node dev inherits basenode {
$local_network = "CHANGE:Network"
$update = "yes" # Overrides previosly defined settings
$dnsserver = "CHANGE:DNSserver"
$env = "dev"
}
node production inherits basenode {
$local_network = "CHANGE:Network"
$ntpserver = "CHANGE:Ntpserver" # Overrides general
timeserver
$dnsserver = "CHANGE:DNSserver"
$env = "production"
}
[...]
node dev_web inherits dev {
$local_network = "CHANGE:Network"
$tier = "web"
}
node dev_app inherits dev {
$local_network = "CHANGE:Network"
$tier = "app"
}
[...]
node production_web inherits production {
$local_network = "CHANGE:Network"
$dnsserver = "CHANGE:DNSserver" # Overrides DNS
defined in production
$tier = "web"
}
and something like that.
The startup tree may be quite long (number of environments * number or
tiers) but if you have just one inheritance tree from single host to
general node, you can smoothly place variables at the more convenient
level and should avoid the probable hell of managing non linear
inheritance trees.
The usage of $env and $tier custom variables can be useful for
managing differences in templates or when sourcing files.
I think it''s better to define $tier as something like "web"
and not
like "production_web" because you''ll probably have some
configurations
related to the tier which must be the same on all the environments
(you can always have different values according to tier AND
environment using both the variables).
Your question has been interesting for me, since I''m trying to define
a general purpose puppet site design method which can adapt to
different IT architectures (i derived what has been written here
from
http://live.lab42.it/puppetinfrastructure/browser/modules/project_general/manifests
)
I would like to know if you consider a similar layout efficient for
your case.
Greets,
al
On 6 Mag, 09:43, huangmingyou <ther...@gmail.com>
wrote:> I have the same question with you, at this time, I define some vaules
> to do this.
> like $app,$env. then when get the file from puppetmaster, I use this
> mainifest.
>
> file{ "somefile":
source=>"puppet:///somefile.${app}.${env}"};
>
> On May 6, 3:20 pm, "hajdu...@gmail.com"
<hajdu...@gmail.com> wrote:
>
> > Does anyone have any suggestions about how to deal with multiple
> > environments/tiers?
>
> > For instance, we have several environments ( production, dev, qa,
> > etc.. ) and within each environment, different tiers ( web, data, app,
> > etc ). Each tier is a different IP network segment, so all the hosts
> > in each tier have different configurations for certain things like
> > resolv.conf, ntp.conf and so on.
>
> > We do subdomain each tier off, so we have web.qa.example.com,
> > data.qa.example.com, etc.
>
> > Should I just be defining a module for say, resolv.conf, with a case
> > statement on $domain and just point to the proper resolv.conf file for
> > the tier?
>
> > Any suggestions on how to proceed and architect this would be
> > helpful. :)
>
> > Thanks.
>
> > steve
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---
Well, a tier doesn''t really inherit anything from an environment. An
environment is essentially a logical grouping of tiers and that''s it -
so we don''t actually have any configurations that we have to put in a
tier. In a sense, we could just call each of our tiers an
''environment'' I suppose.
We identified the files and configurations for each tier that had to
be different depending on what tier the system was in. A tier really
only is different for us in terms of network segments and shared
services. So that means stuff like NFS filers, NTP servers, DNS
servers, syslog servers, routes, etc - are different. Although we can
get away with some trickery by using duplicate short hostnames amongst
tiers ( ie - we always point at ntp1 and ntp2 and the system figures
out the FQDN. ) We also have the issue of having AIX, which has a
horrible propensity to make itself different than any other Unix in
terms of file layout and location. Because of that, I''m thinking of
using straight files, rather than templates.
I''m thinking of something like this ( although I''m too new to
Puppet
to say if this would work or not )
class tierconfig {
case $domain {
"web.prod.example.com": { $tier = "web.prod" }
"data.prod.example.com": { $tier = "data.prod" }
"app.prod.example.com": { $tier = "app.prod" }
}
include tier
}
class tier {
# an example file, although resolv.conf is the same between both AIX
and Linux hosts.
file { "resolv.conf":
source: puppet:///resolv.conf.$operatingsystem.$tier
}
}
node base {
# some base OS stuff
}
node "node1.web.prod.example.com" inherits base {
include tierconfig
}
This has some ambiguity, in that you have to look at the node name to
determine exactly what it''s going to be sourcing when it includes
tierconfig. Any opinions on this would be welcome. I''m also going to
take a harder look at the puppet environments and see if we just can''t
define each of our tiers as an environment.
Al, as far as your config goes, I think that is a good path for when
there is more sharing of configuration between tiers and environments,
but in our case, our tiers within an environment don''t share any
similarities - they are their own islands and we ease alot of our need
for different configs by using duplicate shortnames in DNS.
--
sh
On May 6, 3:43 am, "Al @ Lab42" <lab42...@gmail.com>
wrote:> I would follow this approach:
> - a single inheritance tree where relevant variable can be defined at
> different leves: node inherits tier inherits environment
> - differentiation of files according to templates that used $env $tier
> variables defined in respective places OR, according to each case,
> sourcing of differnet files as described by huangminyou with something
> like source=>"puppet:///somefile.${app}.${env}, even if, according
to
> me, the usage of two variables on the same filename may lead to a
> plethora of different files (in these cases a template would be
> better).
>
> For example:
>
> node basenode {
> $puppet_server = "CHANGE:Ip"
> $ntpserver = "CHANGE:Ntpserver"
>
> $update = "no" # Auto Update packages (yes|no)
> $root_email = "CHANGE:Email" # Noc Email
> }
>
> node dev inherits basenode {
> $local_network = "CHANGE:Network"
> $update = "yes" # Overrides previosly defined
settings
> $dnsserver = "CHANGE:DNSserver"
>
> $env = "dev"
> }
>
> node production inherits basenode {
> $local_network = "CHANGE:Network"
> $ntpserver = "CHANGE:Ntpserver" # Overrides
general
> timeserver
> $dnsserver = "CHANGE:DNSserver"
>
> $env = "production"
> }
> [...]
>
> node dev_web inherits dev {
> $local_network = "CHANGE:Network"
>
> $tier = "web"
> }
>
> node dev_app inherits dev {
> $local_network = "CHANGE:Network"
>
> $tier = "app"
> }
> [...]
>
> node production_web inherits production {
> $local_network = "CHANGE:Network"
> $dnsserver = "CHANGE:DNSserver" # Overrides DNS
> defined in production
>
> $tier = "web"
> }
>
> and something like that.
> The startup tree may be quite long (number of environments * number or
> tiers) but if you have just one inheritance tree from single host to
> general node, you can smoothly place variables at the more convenient
> level and should avoid the probable hell of managing non linear
> inheritance trees.
> The usage of $env and $tier custom variables can be useful for
> managing differences in templates or when sourcing files.
> I think it''s better to define $tier as something like
"web" and not
> like "production_web" because you''ll probably have some
configurations
> related to the tier which must be the same on all the environments
> (you can always have different values according to tier AND
> environment using both the variables).
>
> Your question has been interesting for me, since I''m trying to
define
> a general purpose puppet site design method which can adapt to
> different IT architectures (i derived what has been written here
> from
http://live.lab42.it/puppetinfrastructure/browser/modules/project_gen...
> )
> I would like to know if you consider a similar layout efficient for
> your case.
>
> Greets,
> al
>
> On 6 Mag, 09:43, huangmingyou <ther...@gmail.com> wrote:
>
> > I have the same question with you, at this time, I define some vaules
> > to do this.
> > like $app,$env. then when get the file from puppetmaster, I use this
> > mainifest.
>
> > file{ "somefile":
source=>"puppet:///somefile.${app}.${env}"};
>
> > On May 6, 3:20 pm, "hajdu...@gmail.com"
<hajdu...@gmail.com> wrote:
>
> > > Does anyone have any suggestions about how to deal with multiple
> > > environments/tiers?
>
> > > For instance, we have several environments ( production, dev, qa,
> > > etc.. ) and within each environment, different tiers ( web, data,
app,
> > > etc ). Each tier is a different IP network segment, so all the
hosts
> > > in each tier have different configurations for certain things
like
> > > resolv.conf, ntp.conf and so on.
>
> > > We do subdomain each tier off, so we have web.qa.example.com,
> > > data.qa.example.com, etc.
>
> > > Should I just be defining a module for say, resolv.conf, with a
case
> > > statement on $domain and just point to the proper resolv.conf
file for
> > > the tier?
>
> > > Any suggestions on how to proceed and architect this would be
> > > helpful. :)
>
> > > Thanks.
>
> > > steve
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---
Alright, so after a quick glance at the environment stuff - could I simply do something like this? in puppet.conf for master: environments = webprod, dataprod, appprod [webprod] modulepath = /etc/puppet/modules-webprod:/usr/share/puppet/modules [dataprod] modulepath = /etc/puppet/modules-dataprod:/usr/share/puppet/modules [appprod] modulepath = /etc/puppet/modules-appprod:/usr/share/puppet/modules Then run the puppet client with the appropriate environment setting? The disadvantage to this is that you''re duplicating the modules into alot of places and it depends on how much separation you like amongst your different configs from environment, or you''d rather keep the config together and differentiate the environment within the module instead. Thoughts? On May 6, 9:31 am, "hajdu...@gmail.com" <hajdu...@gmail.com> wrote:> Well, a tier doesn''t really inherit anything from an environment. An > environment is essentially a logical grouping of tiers and that''s it - > so we don''t actually have any configurations that we have to put in a > tier. In a sense, we could just call each of our tiers an > ''environment'' I suppose. > > We identified the files and configurations for each tier that had to > be different depending on what tier the system was in. A tier really > only is different for us in terms of network segments and shared > services. So that means stuff like NFS filers, NTP servers, DNS > servers, syslog servers, routes, etc - are different. Although we can > get away with some trickery by using duplicate short hostnames amongst > tiers ( ie - we always point at ntp1 and ntp2 and the system figures > out the FQDN. ) We also have the issue of having AIX, which has a > horrible propensity to make itself different than any other Unix in > terms of file layout and location. Because of that, I''m thinking of > using straight files, rather than templates. > > I''m thinking of something like this ( although I''m too new to Puppet > to say if this would work or not ) > > class tierconfig { > case $domain { > "web.prod.example.com": { $tier = "web.prod" } > "data.prod.example.com": { $tier = "data.prod" } > "app.prod.example.com": { $tier = "app.prod" } > } > include tier > > } > > class tier { > # an example file, although resolv.conf is the same between both AIX > and Linux hosts. > file { "resolv.conf": > source: puppet:///resolv.conf.$operatingsystem.$tier > } > > } > > node base { > # some base OS stuff > > } > > node "node1.web.prod.example.com" inherits base { > include tierconfig > > } > > This has some ambiguity, in that you have to look at the node name to > determine exactly what it''s going to be sourcing when it includes > tierconfig. Any opinions on this would be welcome. I''m also going to > take a harder look at the puppet environments and see if we just can''t > define each of our tiers as an environment. > > Al, as far as your config goes, I think that is a good path for when > there is more sharing of configuration between tiers and environments, > but in our case, our tiers within an environment don''t share any > similarities - they are their own islands and we ease alot of our need > for different configs by using duplicate shortnames in DNS. > > -- > sh > > On May 6, 3:43 am, "Al @ Lab42" <lab42...@gmail.com> wrote: > > > I would follow this approach: > > - a single inheritance tree where relevant variable can be defined at > > different leves: node inherits tier inherits environment > > - differentiation of files according to templates that used $env $tier > > variables defined in respective places OR, according to each case, > > sourcing of differnet files as described by huangminyou with something > > like source=>"puppet:///somefile.${app}.${env}, even if, according to > > me, the usage of two variables on the same filename may lead to a > > plethora of different files (in these cases a template would be > > better). > > > For example: > > > node basenode { > > $puppet_server = "CHANGE:Ip" > > $ntpserver = "CHANGE:Ntpserver" > > > $update = "no" # Auto Update packages (yes|no) > > $root_email = "CHANGE:Email" # Noc Email > > } > > > node dev inherits basenode { > > $local_network = "CHANGE:Network" > > $update = "yes" # Overrides previosly defined settings > > $dnsserver = "CHANGE:DNSserver" > > > $env = "dev" > > } > > > node production inherits basenode { > > $local_network = "CHANGE:Network" > > $ntpserver = "CHANGE:Ntpserver" # Overrides general > > timeserver > > $dnsserver = "CHANGE:DNSserver" > > > $env = "production" > > } > > [...] > > > node dev_web inherits dev { > > $local_network = "CHANGE:Network" > > > $tier = "web" > > } > > > node dev_app inherits dev { > > $local_network = "CHANGE:Network" > > > $tier = "app" > > } > > [...] > > > node production_web inherits production { > > $local_network = "CHANGE:Network" > > $dnsserver = "CHANGE:DNSserver" # Overrides DNS > > defined in production > > > $tier = "web" > > } > > > and something like that. > > The startup tree may be quite long (number of environments * number or > > tiers) but if you have just one inheritance tree from single host to > > general node, you can smoothly place variables at the more convenient > > level and should avoid the probable hell of managing non linear > > inheritance trees. > > The usage of $env and $tier custom variables can be useful for > > managing differences in templates or when sourcing files. > > I think it''s better to define $tier as something like "web" and not > > like "production_web" because you''ll probably have some configurations > > related to the tier which must be the same on all the environments > > (you can always have different values according to tier AND > > environment using both the variables). > > > Your question has been interesting for me, since I''m trying to define > > a general purpose puppet site design method which can adapt to > > different IT architectures (i derived what has been written here > > from http://live.lab42.it/puppetinfrastructure/browser/modules/project_gen... > > ) > > I would like to know if you consider a similar layout efficient for > > your case. > > > Greets, > > al > > > On 6 Mag, 09:43, huangmingyou <ther...@gmail.com> wrote: > > > > I have the same question with you, at this time, I define some vaules > > > to do this. > > > like $app,$env. then when get the file from puppetmaster, I use this > > > mainifest. > > > > file{ "somefile": source=>"puppet:///somefile.${app}.${env}"}; > > > > On May 6, 3:20 pm, "hajdu...@gmail.com" <hajdu...@gmail.com> wrote: > > > > > Does anyone have any suggestions about how to deal with multiple > > > > environments/tiers? > > > > > For instance, we have several environments ( production, dev, qa, > > > > etc.. ) and within each environment, different tiers ( web, data, app, > > > > etc ). Each tier is a different IP network segment, so all the hosts > > > > in each tier have different configurations for certain things like > > > > resolv.conf, ntp.conf and so on. > > > > > We do subdomain each tier off, so we have web.qa.example.com, > > > > data.qa.example.com, etc. > > > > > Should I just be defining a module for say, resolv.conf, with a case > > > > statement on $domain and just point to the proper resolv.conf file for > > > > the tier? > > > > > Any suggestions on how to proceed and architect this would be > > > > helpful. :) > > > > > Thanks. > > > > > steve--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
On May 6, 2008, at 11:43 AM, hajducko@gmail.com wrote:> Alright, so after a quick glance at the environment stuff - could I > simply do something like this? > > in puppet.conf for master: > environments = webprod, dataprod, appprod > > [webprod] > modulepath = /etc/puppet/modules-webprod:/usr/share/puppet/modules > > [dataprod] > modulepath = /etc/puppet/modules-dataprod:/usr/share/puppet/modules > > [appprod] > modulepath = /etc/puppet/modules-appprod:/usr/share/puppet/modules > > Then run the puppet client with the appropriate environment setting? > > The disadvantage to this is that you''re duplicating the modules into > alot of places and it depends on how much separation you like amongst > your different configs from environment, or you''d rather keep the > config together and differentiate the environment within the module > instead.Yeah, that''s basically how environments should be used. You do have duplication, but that duplication actually exists in your configurations across the environments, so you can''t really avoid it. -- I happen to feel that the degree of a person''s intelligence is directly reflected by the number of conflicting attitudes she can bring to bear on the same topic. -- Lisa Alther --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---