On Saturday, 3 August 2019 02:03:29 UTC+1, Chris Southall wrote: > > Hi Luke. Thanks for a thoughtful and detailed response. > > You are most welcome.
> I'd like to think I grasp the roles/profiles concept, but am just not > convinced it's a better approach. Abstracting away configuration details > and exposing a limited set of parameters results in uniform > configurations. In doing so it also seems it limits flexibility and > ensures that you'll continue to spend a good deal of time maintaining your > collection of profiles/modules. > Absolutely. One of the key points I never told my team was I was enforcing a style that'd make it harder for them to change anything. This is purely entropy reduction. On a very slow day LMAX Exchange trades US$ 100,000 a second, so it's very important to me that say, for example, someone doesn't have the power to easily mess up the indentation on one line of YAML... There by breaking a big hash in Hiera... Which is being used to generate a long list of puppetlabs-firewall rules... Which ends up removing half the firewall rules on a machine. That of course never happened (¬_¬) ... Speaking of hiera tricks, I created an exec resource with the command > defined as a multi-line script to include variables and function > declarations. I use this to collect data and create local facts. The next > puppet run creates additional resources based on the presence of these > facts. This is basically the same as creating a module with external > facts, but doesn't require a module. An upside is that the fact script > doesn't need to execute on every puppet agent run, with the downside being > that the host takes a second puppet run to create all resources. I'm not > sure if I should be proud or ashamed of what I did, but it works! > Two-pass Puppet is often hard to get away from 100%. If it works, and your team can understand it / debug it, that's probably more important. This may be the greatest factor to influence the decision. In my case we > have 2 people working with puppet, and the system we're building is to be > handed over to team with little to no puppet experience. This system runs > at a single site with only a couple hundred managed nodes and maybe a > couple dozen unique configurations. > It sounds like your team size fits your design choice. There's one aspect of the Role Profile pattern that relates to what you say above that I haven't talked about (because I don't do it). It's actually one of the core principals in Craig Dunn's early presentations. When encapsulating business design in Profiles, you create an interface for how that business deliverable can be changed (in my example, a Statistics Collection Server). It's possible to give people outside the Puppet team the ability to configure that interface in standard ways. The core Puppet people produce well tested Profiles that, say, the web developers consume and configure for their purposes. The Web developers only know a little bit of Puppet but they can do basic things like change some web server settings by tweaking the parameters of the Profiles given to them by the core Puppet people. What this looks like in practice is the web developers either having some level of access to Hiera (eg: they can write to a level of the Hierarchy that's lower priority than the Puppet team), or partial write access to a Puppet ENC. If you are a team of two building everything right now and handing over to another team, what you might want to do in future is allow this other team a bit more self-service to make their own changes. You of course still need to be in control of the standard build, but you're not doing every little thing for them. This would work well in a company where various teams can spin up instances of their own cloud infrastructure. Well, you have caused me some guilt that maybe I've taken the easy way out > rather than becoming more proficient with puppet. Once you've had that > first hit and instant high from the hiera crack pipe... it's hard not to go > back. > >From what you've explained about your company, I think your choice of style is appropriate right now. The only thing I can stress is don't this become a limitation in three years when your company grows. The cost of an operational fault is also a factor. If it's relatively inexpensive to fail or break something, fix it, and race on, then optimising for speed of delivery makes perfect sense. Rob's suggestions of learning the Puppet 4/5/6 DSL functions that replace create_resources() are a great starting point. It's sometimes a hard thing to grasp (I have to re-read the Puppet Docs on each function quite often), but if you can master the map(), reduce() and each() functions, you'll learn quite a lot of data manipulation tricks. Then if it becomes more efficient for you down the line, you can begin moving some of your business logic out of Hiera and into code. -Luke -- 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/d1a1ee57-d723-4ab3-8b3a-573df15cd049%40googlegroups.com.
