I highly recommend going with Gary Larizza’s functional puppet workflow unless you’ve got lots of prior experience. You can find part 1 here:
http://garylarizza.com/blog/2014/02/17/puppet-workflow-part-1/ It’s a 3 part series, and there are good follow-ups on r10k and environments (http://garylarizza.com/blog/2014/03/26/random-r10k-workflow-ideas/) and an update to that post to cover directory environments (http://garylarizza.com/blog/2014/08/31/r10k-plus-directory-environments/) Start there - there are criticisms to be had but it’s a good, tested functional workflow at use at a lot of orgs. -Eric -- Eric Shamow Sent with Airmail On September 30, 2014 at 4:17:45 PM, Tom Tucker (tktuc...@gmail.com) wrote: I just got back from PuppetConf last week and several presenters mentioned using more than one Git repo with Puppet. Some even recommend having a repo per module. For our initial Puppet deployment this seems a bit excessive. My plan was to have three repos for each of our environments (Dev, QA and Production). The contents of these repos would contain Puppet Enterprise directory of /etc/puppetlabs/puppet. Deployment strategy - Upload changes to Dev repo - Deploy Dev changes to Dev master - Test - Merge Dev changes to QA repo - Rinse and repeat Thoughts? Any tips for a Puppet and Git newbie in regards to file hierarchy, Git repo strategies, etc. Thank you in advance, Tom Sample tree and repo of /etc/puppetlabs/puppet # tree * auth.conf autosign.conf console.conf # File excluded this is site specific. We will have a unique Puppet master for each env. environments ├── development │ ├── hieradata │ │ └── environmentX.yaml │ ├── manifests │ │ └── site.pp │ └── modules └── production fileserver.conf hieradata ├── defaults.yaml ├── master.mydomain.com.yaml └── production.yaml hiera.yaml [error opening dir] manifests ├── hieradata │ └── hostgroups.yaml └── site.pp modules ├── custom puppet.conf # File excluded this is site specific. We will have a unique Puppet master for each env. puppetdb.conf # File excluded this is site specific. We will have a unique Puppet master for each env. routes.yaml ssl # Directory excluded this is site specific < extra lines removed> # cat hiera.yaml --- :hierarchy: - "hieradata/fqdn/%{::fqdn}" - "%{environment}/%{::osfamily}" - "%{environment}/hieradata/%{::network_location}" - "%{environment}/hieradata/%{::systemrole}" - "hieradata/common" :backends: - yaml :yaml: :datadir: /etc/puppetlabs/puppet/environments -- 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/CAGymF1DKrTsh%2BNO%3DQLMpP1pM80ac3MMxvbo2p0aN9q9USXLj5Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout. -- 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/etPan.542b464a.238e1f29.160a6%40rassilon.local. For more options, visit https://groups.google.com/d/optout.
