Hi
Okay so what i am getting from this is. have 2 maybe 3 environments production - production puppet code testing - testing modules and dev - another testing / developer Inside production I can use a "ENC" ? to force nodes into groups production sim inf inside there I can allocate "environment stuff" Again I am unsure how I implement what I am trying to do. I will pick winbind - just to highlight the difference not the package etc etc. My plan was to create a profile lets say "alex winbind" it would have all of my config info for the module. this profile and others would be pulled together into roles and the roles assigned to nodes. So in my puppet production environment I would have 1 module called alex winbind and because its all in 1 puppet environment I then have to have lots of if statements (or case statement) inside it that basically says if node is in prod use this module if node is in sim use this module if node is in inf use this module is that right ???? A On 25 June 2016 at 13:28, Rob Nelson <rnels...@gmail.com> wrote: > > On Friday, June 24, 2016, Alex Samad <a...@samad.com.au> wrote: >> >> The point i was trying to make was not the how. But that a group of >> nodes will have 1 config and another a different config. It seems >> like environments would be the way to group that. > > > Alex, > > Environment is a very overloaded term. In this case, 'environment' means 'a > discrete set of puppet code and data.' It has no direct relation to > 'environment' meaning 'an operational status of a set of services' (or > however one might deceive the concepts of 'production' vs 'development' vs > …). It is important not to confuse those two, or any other use of the term > environment. > > The reason there is no direct relationship between those two versions of the > term is because a node that is in the operational status of production can > switch between the production environment and any other environment of your > puppet code without affecting its operational status (whether it should is a > very different question!). You may also have two nodes that are both > production nodes that receive different values for e.g. their mail relay. > > This data is better separated via hiera, where you can say "all nodes in the > Sydney datacenter use mail relay A, and all those in Perth use mail relay > B." They don't have to be in separate puppet environments for that to occur. > > Environments are more often used in your code development workflow, where > environments map to your version control branches. You branch off of > development to a branch called feature_a. None of your actual nodes check in > against either of these environments, but your CI pipeline and your > developers test against these with vagrant or similar. You maybe even take a > canary node that normally uses the puppet environment production and have it > check in against the feature_a environment instead. When the feature works > properly, you merge feature_a->development and delete the branch feature_a, > which deletes the environment feature_a. > > You repeat this for a few features, and then you merge from > development->production. Now the code that was tested in CI is being used by > the operational production nodes, which are using the operational > environment as well. Then you go back to making more feature branches and > repeat. > > Along the way, a given node may check into one puppet environment 99% of the > time, but nothing prevents the node from using a different puppet > environment, for testing or urgent fixes or for any other reason. The puppet > environment can be pretty fluid without changing the data and configuration > a given node receives much if at all. > > I hope that's not too confusing. You did say you haven't managed a puppet > install yet, and I think if you set something up in vagrant or a lab, some > of the concepts would become clear a lot quicker than when we discuss them > in the abstract. > > > -- > > Rob Nelson > rnels...@gmail.com > > -- > You received this message because you are subscribed to a topic in the > Google Groups "Puppet Users" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/puppet-users/mZBLZQKZ0xM/unsubscribe. > To unsubscribe from this group and all its topics, 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/CAC76iT_ZScBbqvtOJ7xdkwr8--JspDnYBgKGjJ-%3DvdDp-tAcJQ%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/CAJ%2BQ1PVafiLtM5dQ8Kx-HTGyxDnUZrHE4Ur%3DkdxAMD%2Bw%2BrpAmA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
