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 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/CAC76iT_ZScBbqvtOJ7xdkwr8--JspDnYBgKGjJ-%3DvdDp-tAcJQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
