Re: [Puppet Users] Dynamically adding app servers behind web server
On 11/19/2016 08:30 AM, Ryan Murphy wrote: I've looked at exported resources, but I'm just not sure how to use them to do what I want to accomplish. The puppetlabs/haproxy[1][2] module might be of interest to you. It uses that approach to allow dynamic management of HAProxy proxy backend members. [1]: https://forge.puppet.com/puppetlabs/haproxy [2]: https://github.com/puppetlabs/puppetlabs-haproxy -- Richard _ This email has been filtered by SMX. For more info visit http://smxemail.com _ -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/b15b868f-3df9-d8d7-edc7-d6b090c191e8%40smxemail.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Multi environment and multi system
On 03/10/15 13:08, Joao Morais wrote: How to manage a Puppet Server with multi-environment and multi-system? This is something I have also been grappling with lately. We too, have a number of environments (development, staging, production) that a host might belong to, and a deployment model that propagates changes through the environments from dev, to staging, to production. When we initially deployed this infrastructure, we created Puppet dynamic environments corresponding to those physical environments (i.e. Puppetfile and Hiera repos, each with dev, staging, and production branches on each). In hindsight, I think this was a mistake to have this direct relationship between Puppet environments and physical host environments, for the reasons you suggest. Changes accumulate quickly in the dev environment, and it becomes challenging to promote certain changes to staging or production. You either merge the entire branch, and have to coordinate releases carefully with everyone working on dev, or you cherry pick particular commits from Dev, and then have to somehow manage keeping the environments in sync. My plan now, is to change this to a model where nearly every host (dev, staging, and prod) is in a single 'production' Puppet dynamic environment. Rather than having puppet environments that correspond to physical environments, the single production Puppet environment represents the stable tested version of our Puppet code and Hiera config. That is, the way we deploy a dev or staging box, should be exactly the same as the way we deploy a production box. Where we are developing or testing a puppet module, we create a new feature branch/environment, and move a host to that environment for testing. Then once the change is tested, the feature branch is merged into production and applied to all hosts, and the testing host is moved back into the production environment. The idea here is that environments other than 'production' are generally for short-term use. Because all hosts are on the same Puppet environment most of the time, we capture the differences between them in Hiera. Each of our hosts has a site code, which captures the host's geographic location and physical environment in a short alphanumeric id. This id is exposed as a fact, and incorporated into our Hiera hierarchy so we can target configuration to all hosts in a particular site. As with modules, config changes can be tested in a temporary feature branch before merging to production, and we can also use the Hiera hierarchy to scope changes to individual hosts, whole sites, or to all environments. Gary Larizza describes a similar model, more cogently than I have, in a blog post here: http://garylarizza.com/blog/2014/03/26/random-r10k-workflow-ideas/ I'd be interested to hear from anyone who is already using such a model, and particularly if you've run into any problems with it. -- Richard Gray _ This email has been filtered by SMX. For more info visit http://smxemail.com _ -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/561198D3.5010306%40smxemail.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Help with NTP module provided by puppetlabs
Hi,
If you have Foreman configured as an ENC, the location parameter will be
available to Hiera as a fact. e.g. In the master section of puppet.conf,
you'll have something like (node.rb comes from Foreman):
external_nodes = /etc/puppet/node.rb
Then in hiera.yaml you can reference the location fact with
#{::location}. Parameters such as location are passed to puppet from an
ENC through the hash structure described at
https://docs.puppetlabs.com/guides/external_nodes.html#enc-output-format
Cheers,
Richard
On 17/08/15 19:17, Eddie Mashayev wrote:
Hi Richard,
Just wondering, I do have now a locations configured on my Foreman
(:locations_enabled: true), how can I access this data?
For example if I have a Facter variable named $location or $os_version
so I can use it on mypuppet scripts. How can I use Foreman locations
variable?
Hope I made myself clear :)
Thanks,
EddieM
On Tuesday, August 11, 2015 at 6:12:58 PM UTC+3, Eddie Mashayev wrote:
Thanks for the help :)
On Tuesday, August 11, 2015 at 1:24:48 AM UTC+3, Richard Gray wrote:
On 10/08/15 20:12, Martin Alfke wrote:
You need to create a hiera.yaml config file.
The config file may look like this:
:backends:
- yaml
:yaml:
:datadir: ‘/etc/puppet/data’
:hierachy:
- “nodes/#{::certname}”
- “location/#{::timezone}”
- global
Further to Martin's comment, you may be interested to know
that the Foreman location and environment are available to
Hiera, so you might prefer to use those rather than the
timezone fact. E.g.
:backends:
- yaml
:yaml:
:datadir: ‘/etc/puppet/data’
:hierachy:
- “nodes/#{::certname}”
- “location/#{::location}”
- global
--
*Richard Gray* | Senior Operations Engineer
*DDI:* +64 9 950 2196 *Fax:* +64 9 302 0518
*Mobile:* +64 21 050 8178 *Freephone:*0800 SMX SMX (769 769)
*SMX Limited:* Level 15, 19 Victoria Street West, Auckland,
New Zealand
*Web:* http://smxemail.com
SMX | Cloud Email Hosting Security
This email has been filtered by SMX. For more information
visit smxemail.com http://smxemail.com/.
--
You received this message because you are subscribed to the Google
Groups Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send
an email to puppet-users+unsubscr...@googlegroups.com
mailto:puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/bd0b95d1-bf7d-4c2a-aab8-50cfbba97906%40googlegroups.com
https://groups.google.com/d/msgid/puppet-users/bd0b95d1-bf7d-4c2a-aab8-50cfbba97906%40googlegroups.com?utm_medium=emailutm_source=footer.
For more options, visit https://groups.google.com/d/optout.
--
*Richard Gray* | Senior Operations Engineer
*DDI:* +64 9 950 2196 *Fax:* +64 9 302 0518
*Mobile:* +64 21 050 8178 *Freephone:*0800 SMX SMX (769 769)
*SMX Limited:* Level 15, 19 Victoria Street West, Auckland, New Zealand
*Web:* http://smxemail.com
SMX | Cloud Email Hosting Security
_
This email has been filtered by SMX. For more info visit http://smxemail.com
_
--
You received this message because you are subscribed to the Google Groups Puppet
Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/55D258F5.6030107%40smxemail.com.
For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Help with NTP module provided by puppetlabs
On 10/08/15 20:12, Martin Alfke wrote:
You need to create a hiera.yaml config file.
The config file may look like this:
:backends:
- yaml
:yaml:
:datadir: ‘/etc/puppet/data’
:hierachy:
- “nodes/#{::certname}”
- “location/#{::timezone}”
- global
Further to Martin's comment, you may be interested to know that the
Foreman location and environment are available to Hiera, so you might
prefer to use those rather than the timezone fact. E.g.
:backends:
- yaml
:yaml:
:datadir: ‘/etc/puppet/data’
:hierachy:
- “nodes/#{::certname}”
- “location/#{::location}”
- global
--
*Richard Gray* | Senior Operations Engineer
*DDI:* +64 9 950 2196 *Fax:* +64 9 302 0518
*Mobile:* +64 21 050 8178 *Freephone:*0800 SMX SMX (769 769)
*SMX Limited:* Level 15, 19 Victoria Street West, Auckland, New Zealand
*Web:* http://smxemail.com
SMX | Cloud Email Hosting Security
_
This email has been filtered by SMX. For more info visit http://smxemail.com
_
--
You received this message because you are subscribed to the Google Groups Puppet
Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/55C9229C.4010605%40smxemail.com.
For more options, visit https://groups.google.com/d/optout.
