How to organizing puppet code on the master

[jeffster]

Good day all,

Newbie looking for some insight on how to organize manifests on puppet master. Simple setup with only a couple of machines to manage. One of my main sticking point is that according to the literature I've seen, they all seem to agree upon the fact that code must be organized using modules. My question is--If my setup is so simple, can I do without them? All I have are a few manifest files and templates.

Secondly, should I go with the modules approach and divide my code in said modules, what happens when a portion of puppet code doesn't really fit logically into any of them? Would the code be kept at the site.pp level instead?

Thank you

jeff

[Arnau]

Hi,

my opinion: create modules for everything, even if it's a single file copy. But create something that you can expand in the future.

It's quite easy to create a puppet module (http://fullstack-puppet-docs.readthedocs.io/en/latest/puppet_modules.html) so it will take you 5 minutes to write your own module(s).

No matter how you start, working with modules is something that you'll thank in the future when you decide to add more stuff (code/hosts) to your puppet installation..

Then, create a manifest.pp and configure your nodes like:

node 'abc' {

}

node 'xyz' {

}

HTH,

Arnau

--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/bb6a05e9-fe38-4bdf-9a77-702cc8227824%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[jcbollinger]

On Tuesday, May 15, 2018 at 4:17:58 PM UTC-5, jeffster wrote:

Good day all,

Newbie looking for some insight on how to organize manifests on puppet master. Simple setup with only a couple of machines to manage. One of my main sticking point is that according to the literature I've seen, they all seem to agree upon the fact that code must be organized using modules. My question is--If my setup is so simple, can I do without them? All I have are a few manifest files and templates.

 

It is possible to build a functional manifest set that does not use modules, but it is a poor idea.  Most sites have at least one (local) module for configuration details specific to that site, however, and it may be that putting your few manifests and templates all into one such module will be sufficient for you, at least to start.

 

Secondly, should I go with the modules approach and divide my code in said modules, what happens when a portion of puppet code doesn't really fit logically into any of them? Would the code be kept at the site.pp level instead?

All classes should belong to modules, but you may use a local site module such as I already described as a catch-all for miscellany. Precious little is appropriately placed at top scope in the site manifest.  Node blocks, if you use them, are by far the most prominent among those.  With very few (situational) exceptions, all other manifest code should go into classes or node blocks.  The decision is not about logical fit, but rather about the semantics of top-scope code vs. more narrowly scoped code.

Note, too, that there is nothing inherently wrong with very small modules, if that seems to be a reasonable alternative for some of your code.

John

[jeffster]

John, Arnau -- 

hank you for your responses. I feel more confident about how to approach organizing my code and how modules are used.

cheers!

JF

[Andrew Grimberg]

I know some folks think this is heresy, but I personally dislike
defining each node in the default manifest.

I think it's better to drive as much data as possible from hiera as
possible, as such I do it more like this. I define a node definition
that does a hiera lookup to determine what role to apply and drive it
from there.

My current Puppet 5 implementation of this setup can be see here (yes,
this is my live configuration, yes I'm aware that seems horrible running
the whole thing out there like this :D )

Main puppet: https://github.com/tykeal/puppetserver-v5-main

Hiera: https://github.com/tykeal/puppetserver-v5-hiera (uses
hiera-eyaml-gpg for secrets management)

All profiles: https://github.com/tykeal/puppetserver-v5-mod-profile

All roles: https://github.com/tykeal/puppetserver-v5-mod-role

Mind you, I'm working on re-implementing a green field puppet 5 setup.
I've got a working puppet 4 one. All the same repos, just drop the -v5-
from the name.

Check the main repo Puppetfile for all forge / custom modules in play.

-Andy-

On 05/16/2018 02:51 AM, Arnau wrote:
> Hi,
>
> my opinion: create modules for everything, even if it's a single file
> copy. But create something that you can expand in the future.
>
> It's quite easy to create a puppet module
> (http://fullstack-puppet-docs.readthedocs.io/en/latest/puppet_modules.html)
> so it will take you 5 minutes to write your own module(s).
>
> No matter how you start, working with modules is something that you'll
> thank in the future when you decide to add more stuff (code/hosts) to
> your puppet installation..
>
> Then, create a manifest.pp and configure your nodes like:
>
> node 'abc' {
> }
>
> node 'xyz' {
> }
>
> HTH,
> Arnau
>
> 2018-05-15 23:00 GMT+02:00 jeffster <jol...@gmail.com

> <mailto:jol...@gmail.com>>:

>
> Good day all,
>
> Newbie looking for some insight on how to organize manifests on
> puppet master. Simple setup with only a couple of machines to
> manage. One of my main sticking point is that according to the
> literature I've seen, they all seem to agree upon the fact that code
> must be organized using modules. My question is--If my setup is so
> simple, can I do without them? All I have are a few manifest files
> and templates.
>
> Secondly, should I go with the modules approach and divide my code
> in said modules, what happens when a portion of puppet code doesn't
> really fit logically into any of them? Would the code be kept at the
> site.pp level instead?
>
> Thank you
>
> jeff
>
> --
> 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...@googlegroups.com
> <mailto:puppet-users...@googlegroups.com>.

> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/bb6a05e9-fe38-4bdf-9a77-702cc8227824%40googlegroups.com

> <https://groups.google.com/d/msgid/puppet-users/bb6a05e9-fe38-4bdf-9a77-702cc8227824%40googlegroups.com?utm_medium=email&utm_source=footer>.

> For more options, visit https://groups.google.com/d/optout

> <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...@googlegroups.com
> <mailto:puppet-users...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/puppet-users/CAM69jx93Qgt4OShRycGzjibCv%2Bb%3DiNer3GAXrBhT5hWWb3vTyQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/puppet-users/CAM69jx93Qgt4OShRycGzjibCv%2Bb%3DiNer3GAXrBhT5hWWb3vTyQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[jcbollinger]

On Wednesday, May 16, 2018 at 4:51:08 PM UTC-5, Andrew Grimberg wrote:

I know some folks think this is heresy, but I personally dislike
defining each node in the default manifest.

I think it's better to drive as much data as possible from hiera as
possible, as such I do it more like this. I define a node definition
that does a hiera lookup to determine what role to apply and drive it
from there. 

Who thinks that approach heretical?  It's perfectly valid.  In fact, some people take it a step further and do much the same without any node blocks at all.  That would constitute one of the situational exceptions I mentioned to putting code at top scope in the site manifest.  Others do similar, with or without node blocks, by using an ENC to declare each node's role class.

This has been a thing for years.  I like it and recommend it, especially for building out new sites.

John