On Thursday, June 23, 2016 at 6:11:11 PM UTC-5, Alex Samad wrote: > > On 24 June 2016 at 00:16, jcbollinger <john.bo...@stjude.org <javascript:>> > wrote: >
[...] > > In the first place, I recommend not using multiple Puppet environments > > unless you have a Puppet-related reason for doing so. The prime reason > in > > this category would be that you want to allow for use of different > versions > > of the same Puppet modules to be used with one group of nodes than with > > another. When no such reason applies, environments do not provide a > benefit > > commensurate with the extra complication and work they involve. > > > > In the second place, yes, you're wrong. The Puppet environment to which > a > > node is assigned affects the details of the catalogs built for it, which > in > > turn affects those nodes' configurations. The master makes decisions > based > > on node environment, but nodes need not and should not care why they are > > configured as they are. For example, nodes do not need to know or care > > about the meaning of the contents of their MOTD; they just need to > present > > the text -- whatever it is -- to users when they log in and when they > ask > > I agree but how do you make them difference for different nodes, if I > specify a group of nodes that have a specific MOTD... the nodes don't > care but ( i was using it as an example). maybe a better one would be > say smtp setup - all nodes have it, non prod must point to the non > prod smtp server. > > How is configuring which SMTP server a node uses fundamentally different from configuring a node's MOTD? In either case you're just plugging the right data into the right hole. The holes are even similar in shape: part or all of a particular text file in a known location (or on Windows, the holes are sometimes registry entries). You said earlier that your master will assign nodes to environments, and at that time you were identifying Puppet environments with operational environments. It follows that you anticipate that your master will have enough information to identify nodes' intended operational environments. How the master should translate that information into node configurations is an entirely different question, and largely orthogonal to whether Puppet environments are associated with operational environments. Surely you don't suppose that every machine in the same operational environment will be configured identically to every other, so even if you do match Puppet environments to operational environments, that does not in itself address questions about how to assign configurations to nodes -- or, in Puppet speak, how to *classify* nodes. In fact, Puppet has several mechanisms for that, one of them being the one that you already plan on using to assign nodes to environments: the external node classifier (ENC) <https://docs.puppet.com/guides/external_nodes.html>. Puppet also makes heavy use of external data for configuring nodes, generally accessed via its Hiera <https://docs.puppet.com/hiera/latest/> hierarchical data subsystem. Hiera data can be used to directly classify nodes (hiera_include()), or to supplement classification performed primarily elsewhere (automated data binding, hiera(), hiera_hash(), hiera_array()). I prefer to put most of the load on Hiera, myself, but the reasons for that would be an entirely separate discussion. Furthermore, how you structure your manifest set plays heavily into how easily this all works out. If you are not already aware of Craig Dunn's "Roles and Profiles" pattern <http://www.craigdunn.org/2012/05/239/>, then you should familiarize yourself with it. You are not obligated to use it, but I think it synergizes with your objectives, and it has been applied with great success in a lot of places. > > for it. Likewise, they do not need to know why they are configured to > > access a particular database server, why they have the particular vhosts > > configured that they do, why they have the particular users and > passwords > > they have, why they mount the particular remote file systems they mount, > > etc.. > > > > > Sorry our argument seems counter intuitive. Maybe I am miss > understanding. > > For example I have had a lot of issue with winbind. (centos 6.x). So > my thought is > > production environment - has all the prod nodes. > It has a specific version of winbind, might be old but it works > > My other environments have different newer versions of winbind. > > > if you can explain how I can do that with 1 environment . happy to > learn. I haven't done a puppet setup before - which is why i'm asking > and questioning. > In the first place, this still has nothing to do with nodes being mindful of which Puppet environment they are assigned to, nor even of which operational environment they are assigned to. Nodes will use whichever winbind (for example) is installed on them, regardless of which environments you label them with. The nodes themselves don't much care what you *call* them -- they simply operate according to the way you *configure* them. In the second place, if the master has enough information to determine nodes' intended operational environments, and it knows how nodes in those operational environments should be configured, then it can configure those nodes appropriately. If not, then not. Puppet environments are one vehicle for expressing such knowledge, but using them that way for your particular purposes would be clumsy, would take more work in the long run, and would interfere with using Puppet environments for other purposes to which they are better suited and in which they confer much greater advantage. I already mentioned external node classifiers and Hiera -- these are Puppet's primary mechanisms for matching configuration details to nodes. You can also use node blocks in conjunction with one or both of those, though these days the practical role of node blocks seems a bit diminished. That still has no essential bearing on either Puppet environments or operational environments. Even if you planned on using node blocks as your sole means of node classification, that would not require you to use Puppet environments to achieve your objectives. > >> > >> My thought had been to align production environment with production > >> server, infra with infra servers and non prod non infra in the non > >> prod environment. > > > > > > > > Even if you ignore my advice and do that, what I'm saying is that you > should > > not identify Puppet's sense of "environment" with any external concept > going > > by the same name. I maintain that nodes probably don't need to be > > explicitly aware of the label of their operational environment, either, > but > > especially if you're exerting central control over Puppet environments, > > there is no reason for nodes to care how Puppet labels those > environments. > > so environments should only really align with puppets production code > and none prod code. and by non prod code you are talking only about > puppet module code ? > Puppet environments are highly appropriate for change management in your Puppet infrastructure itself, if that's what you're saying. There is no good reason for coupling that with change management for your product / service pipeline -- you have the substantially the same uptime and service availability requirements for your dev and QA machines that you do for your prod machines; it's the applications running on top where you can afford instability. Do you want all your developers stalled in the event that upgrading the version of a Puppet module on the master has an unanticipated negative effect? But that's not the only reasonable use of environments. For example, some organizations maintain a central Puppet master, but afford different divisions control over their own configurations. This can be done by assigning a different environment to each division, and allowing that division to control the contents of that environment. Environment isolation is pretty firm in the latest versions of Puppet (slightly less so in earlier versions) so that works fairly well. There are other applications. Moreover, no, I am not talking about only Puppet modules. Environments do have -- or can have -- their own module sets, but they can also have their own ENCs, their own data, and their own site manifests. There are good applications for environments that use all of those things; what you described just isn't one of them. If you're looking for a rule of thumb, though, then it might be reasonable to use the need (or the potential need) for a different module set as a criterion for judging whether establishing a separate Puppet environment is a good solution to a given problem. John -- 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/c327cef8-5dd5-448a-97cc-4c743db4b8a7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
