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 ([email protected]) 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 [email protected]. 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 [email protected]. 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.
