On Tuesday, April 9, 2019 at 10:30:39 AM UTC-5, NgeeGoh wrote: > > Hi all, > > I am new to Puppet and currently doing some Proof of Concept work to see > if Puppet could fit into our processes. > I have set up a puppet master server on Azure and a VM with puppet agent > installed. Since I want to dig in more about the puppet manifests and its > configuration features, I only use the VM with puppet agent installed as a > standalone puppet. >
That's a bit odd. If you are using Puppet only in standalone mode then you do not need a master. Not using a master is the key characteristic of standalone mode. > I have also set up a control repo for the puppet with roles/ profiles model > > I have a couple of questions about what would be the best practices: > 1. I am a bit confused about how to handle resources and data in puppet > manifest. For example, I got a list of windows features that i need to > install/ run in JSON file which is located in a resource folder i created > in the same level as site and manifest, and in the windowsfeature manifest > (in profile) I load the json data and loop through all the data to install/ > run the windows features. Would it be nicer and cleaner if i implemented > Hierra here? To be honest, the implementation of Hierra to me is also not > very clear. > It would be more *conventional*, at least, to use Hiera for data describing the wanted configuration of your nodes, and it would be a bit more tightly integrated with Puppet. Once you get the data into the system, however, there are no operational consequences arising from how you did so. For "resources" in the sense of files that need to be installed on the target node, one of a variety of other approaches would be typical. For smallish flat files that need to be installed verbatim, I think most people would just put a copy of the file in the files/ directory of an appropriate module. Similar for file-content templates of any significant complexity, except those would go in a templates/ directory. Individual pieces of configurable data, however, are generally mapped to class parameters. During catalog building, class parameters values can be and often are automatically populated from Hiera data. > 2. As far as I know, puppet control repo controls different environments > based on branches which i feel a bit strange, while Chef manages all > environments under one folder in git which I find its more manageable since > we can apply the configuration to the different environments with different > data without worrying about changing git branches. Just wondeirng if we > could somehow achieve this in puppet or is there any obvious benefits of > this current model in puppet? > Use of control repos is not a feature of core Puppet. It is a technique that has become popular to use *on top of* Puppet, but you are under no obligation to use it. You absolutely can keep all environments in a single branch of a single repo if that's what you want to do. Puppet will not know or care. It is true, however, that the PE version of Puppet has built-in support for control repos. If that's the direction you're headed then the control-repo approach may be the path of least resistance. But there certainly are benefits to the branch-per-environment model. First and foremost, it provides for better isolation between environments and clearer versioning of environment contents. It also provides a more structured and API-friendly representation of your list of environments, since they map 1:1 to control-repo branches. Moreover, it is relatively easy to structure things with a control repo so that (explicit) branch management plays no part in day-to-day operation and maintenance. The principal difference you would feel is that you need to push and pull changes separately for each environment, but that's part of the point of the approach. Note also that you may be attributing too much significance to environments. People set up multiple environments much more frequently and widely than is in fact warranted. In particular, they tend to associate Puppet "environments" with operational "environments" such as dev / QA / production of the infrastructure being managed, whereas often those would be better mapped to different roles. The point of different *Puppet* environments is to support different sets of *Puppet* modules, data, and nodes. It can be counterproductive map the lifecycle stages of the infrastructure being managed to Puppet environments, because that opens unnecessary opportunities for breakage when you perform a lifecycle advance -- you not only change how your nodes are configured, but you also change the code used to configure them. 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/4ccdf0fc-759b-4dc6-a36b-95d206f434a1%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
