Hi
I have recently gone through this problem.
I had initial thought to you different branches for the different
environments.
say
prod
uat
sim
inf
dev
But was advised best to go with production and testing.
so I have and I have used a grouping in my ENC to put machines into the
above groups. But I am about ready to go back to more branches again. Why
I have setup my profiles
my_ssh profile this handles all the general setup of ssh server and client
- standard across all machines
so my roles just include profile::my_ssh
My issue with this is if I want to now role out a change to my ssh setup I
can't isolate which box gets its, pot luck, wait long enough and they all
get it.
I am not sure its the best to go to each dev/uat machine and run puppet
--environment <mytest> is the best solution plus my ENC sets the
environment .. don't want pesky dev guys change environments on me.
I don't want to have to create a new profile and attach it to the roles I
want to test on.
So I am thinking ... multiple branches is sounding good.
But im keen to see what comes out of this.
On Friday, 19 August 2016 02:24:58 UTC+10, Rob Nelson wrote:
>
> The term 'environment' is overloaded. In the context of puppet, I prefer
> to think of it as "a set of puppet code/data representing a branch of the
> controlrepo' (puppet environment), rather than 'an environment that nodes
> run in' (dev/qa/prod/etc) (node environment). Since you can make the latter
> part of your hiera hierarchy, the only puppet environment that needs to
> live forever is 'production'. Inside it, the hieradata has ALL the data for
> all of the node environments, so they actually all check into 'production'.
> The hierarchy value for the node environment can be a custom fact,
> calculated or a file on disk, so nodes can get the right node environment
> data from the puppet environment 'production'.
>
> :hierarchy:
> - "nodes/%{::trusted.certname}"
> - "node_env/%{node_env}"
> - "common"
>
> By differenting the various uses of the overloaded term 'environment' a
> bit, you can actually streamline your workflow quite a bit. Now all your
> data is in one place. When you create a feature branch for testing, you can
> then point the canary nodes to that branch (`puppet agent -t --environment
> ticket1234`, or putting `environment = ticket1234` in puppet.conf). Whether
> you're changing roles and profiles, hiera data, or the Puppetfile, it's
> contained in that branch, but you can actually have production, dev, qa
> nodes check into it and get the new results, so you aren't surprised when a
> Puppetfile change in dev trickles up to prod and suddenly things blow up.
> Of course, you need to have some canary nodes in each node environment (or
> place a LOT of trust in --noop mode) to get there, but I think that's a
> reasonable goal to work toward.
>
>
>
> Aside: I know we have discussed workflows and the various types of
> environments on this list quite a bit this Spring/Summer. Does anyone have
> a good reference article for this already, or do we need to come up with
> one? I think this is an important gap to fill.
>
>
> Rob Nelson
> [email protected] <javascript:>
>
> On Thu, Aug 18, 2016 at 12:07 PM, Mike Sharpton <[email protected]
> <javascript:>> wrote:
>
>> The static branches are basically Puppet environments in which nodes are
>> bound/pointed to them in their puppet.conf. This way we can open CR's per
>> set of nodes and move up the chain. Also, I may have found another option
>> on Gary's site. We could r10k our hiera data and split it from our control
>> repo. More to come. Thanks again for thoughts.
>>
>>
>> On Thursday, August 18, 2016 at 10:00:01 AM UTC-5, Christopher Wood wrote:
>>
>>> I'm missing why you need static branches. I'm picturing something more
>>> like:
>>>
>>> git checkout production
>>> git checkout -b ticket1234
>>> # make changes, commit, push, test, repeat
>>> git merge production # catch up on any prod changes, retest
>>> git tag ticket.1234
>>> git checkout production
>>> git merge ticket1234
>>> git branch -d ticket1234
>>>
>>> That way everybody's changes are working pretty close to what production
>>> is right now.
>>>
>>> The alternatives are curating your branches, periodically re-branching
>>> from production, or just accepting the current state, as near as I can tell
>>> off the cuff. If you want to maintain something it requires maintenance
>>> work no matter the tool you pick.
>>>
>>>
>>> On Thu, Aug 18, 2016 at 05:27:40AM -0700, Mike Sharpton wrote:
>>> > Thanks for your reply. We based our initial design on shit Gary
>>> says.
>>> > This may be our only option as you say, to have hiera data changes
>>> made
>>> > to each static branch/puppet environment by hand and not merge. We
>>> need
>>> > the static branches for separation of Puppet environments. Problem
>>> with
>>> > this approach is humans will make errors between each branch
>>> sometimes or
>>> > always. The branches/environments will eventually become snow
>>> flakes over
>>> > time as far as Hieradata. Perhaps we can possibly merge them
>>> weekly to
>>> > lower this risk. Assuming no code changes are in flight, which
>>> there most
>>> > likely always will be. The search continues. Thanks again,
>>> > Mike
>>> >
>>> > On Wednesday, August 17, 2016 at 3:52:31 PM UTC-5, Christopher Wood
>>> wrote:
>>> >
>>> > It sounds like these might help:
>>> >
>>> > [1]https://puppet.com/blog/git-workflows-puppet-and-r10k
>>> >
>>> > [2]http://garylarizza.com/blog/categories/r10k/
>>> >
>>> > Seems like you would benefit from having all teams work from
>>> branches of
>>> > current production and merge back, rather than maintaining a
>>> > semi-permanent dev branch shared by everybody. This is usually
>>> where I
>>> > suggest that people review commits and talk to each other and
>>> figure out
>>> > what's good, but sometimes that's like pulling teeth.
>>> >
>>> > On Wed, Aug 17, 2016 at 01:21:45PM -0700, Mike Sharpton wrote:
>>> > > Hey all,
>>> > > We are coming up on an issue in our environment in where we
>>> have
>>> > multiple
>>> > > Puppet environments that are backed by git branches in a
>>> puppet
>>> > control
>>> > > repo. Our Hiera data is stored inside these branches and
>>> changed
>>> > > frequently by our Operations teams. Of which we then have
>>> them
>>> > merge
>>> > > changes up the environment chain and r10k through our Puppet
>>> > environments.
>>> > > This is all fine.
>>> > > Ex, dev -> test -> production, hiera data changes are moved
>>> up and
>>> > tested
>>> > > each step of the way.
>>> > > When things aren't fine is when we are testing code in our
>>> dev or
>>> > test
>>> > > branch and we have changed the tags for modules/repos inside
>>> the
>>> > > Puppetfile of those branches that we don't want in
>>> production right
>>> > away
>>> > > (dev/test). This code only applies to dev environment, on
>>> purpose.
>>> >
>>> > > Our operations team then comes along with their hiera
>>> changes and
>>> > merges
>>> > > the puppetfile module/repo changes up the chain along with
>>> the
>>> > hiera data.
>>> > > Effectively moving our Puppetfile changes up the chain when
>>> we
>>> > don't want
>>> > > to. We have thought about splitting hiera data out our
>>> puppet
>>> > control
>>> > > module like it was before Puppet 4, but this leaves us no
>>> room to
>>> > test
>>> > > hiera data up our environment chain and also leaves us with
>>> some CI
>>> > work
>>> > > to make this feasible. Having the hieradata in each
>>> environment is
>>> > too
>>> > > nice. We also attempted to monkey with .gitignore, but this
>>> is not
>>> > meant
>>> > > to do what we are trying to do. Don't merge Puppetfile
>>> unless I
>>> > want to.
>>> > > Has anyone ran into this and found a somewhat elegant
>>> solution?
>>> > > Everything we are coming up with is either not easy to
>>> manage, or
>>> > just
>>> > > doesn't make sense to do. Perhaps we are missing something
>>> simple
>>> > and are
>>> > > over thinking things. Thanks in advance.
>>> > > Mike
>>> > >
>>> > > --
>>> > > 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 [1][3][email protected].
>>> > > To view this discussion on the web visit
>>> > >
>>> > [2][4]
>>> https://groups.google.com/d/msgid/puppet-users/9d9e18a4-a6e4-4d04-b0b3-377b848a8504%40googlegroups.com.
>>>
>>>
>>> > > For more options, visit [3][5]
>>> 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 [6][email protected].
>>> > To view this discussion on the web visit
>>> > [7]
>>> https://groups.google.com/d/msgid/puppet-users/cfcde2dc-2904-4286-bd01-c934857c0ee5%40googlegroups.com.
>>>
>>>
>>> > For more options, visit [8]https://groups.google.com/d/optout.
>>> >
>>> > References
>>> >
>>> > Visible links
>>> > 1. https://puppet.com/blog/git-workflows-puppet-and-r10k
>>> > 2. http://garylarizza.com/blog/categories/r10k/
>>> > 3. javascript:
>>> > 4.
>>> https://groups.google.com/d/msgid/puppet-users/9d9e18a4-a6e4-4d04-b0b3-377b848a8504%40googlegroups.com
>>>
>>> > 5. https://groups.google.com/d/optout
>>> > 6. mailto:[email protected]
>>> > 7.
>>> https://groups.google.com/d/msgid/puppet-users/cfcde2dc-2904-4286-bd01-c934857c0ee5%40googlegroups.com?utm_medium=email&utm_source=footer
>>>
>>> > 8. 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] <javascript:>.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/puppet-users/b4d986ee-a5e4-4c40-9e0e-2d3d32f35b18%40googlegroups.com
>>
>> <https://groups.google.com/d/msgid/puppet-users/b4d986ee-a5e4-4c40-9e0e-2d3d32f35b18%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>> 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/1527405f-dda2-4a6b-b35a-70cea5618021%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
