Pastebin like service for sharing Profiles?

[comport3]

Presumably the majority of participants in this group are using the 'Roles and Profiles' patterns in their Puppet deployments.

Although there is little to be gained from the Roles portion, often the way technologies are integrated is driven by the logic in the Profiles section.

Has there been a discussion (or better, an existing service or method) of freely sharing and exchanging those Profiles?

I think observing and reusing (and hopefully, improving) the logic in these would benefit all in the community.

Example: https://pastebin.com/gkFibUQt

[Martin Alfke]

Hi,

For most people it is difficult to share their roles/profiles as they usually have private information on infrastructure or passwords hard coded.
At example42 we are working on making a set of reusable profiles available (https://github.com/example42/puppet-psick.git) which we use in our control-repository (https://github.com/example42/psick.git).

Feel free to analyze and contribute.

Best,
Martin

[Tim Skirvin]

comport3 <comp...@gmail.com> writes:

> Has there been a discussion (or better, an existing service or method) of
> freely sharing and exchanging those Profiles?

> I think observing and reusing (and hopefully, improving) the logic in these
> would benefit all in the community.

My local solution to this: instead of putting modules into a
single module called 'profiles', I have an additional module path set
up with reasonably-named per-topic modules, prefixed with 'p_' to avoid
namespace collisions. So I have 'p_firewall' (wrappers around the
puppetlabs/firewall), 'p_puppet_client', 'p_docker', 'p_root' (which
contains separate manifests for mail forwarding, password setting, and
others), etc. These are differentiated from regular modules because a)
they can and generally do contain data, b) they can refer to shared hiera
variables, and c) they aren't really meant for wide distribution (so no
r10k + the forge, but I can probably share most of them with other teams
easily enough).

Has anybody else come up with anything like this system? It has
kept us sane and scaling for years now, and I can't imagine working within
a single crowded profiles directory.

- Tim Skirvin (tski...@fnal.gov)
--
HPC Systems Administrator / Developer http://www.linkedin.com/in/tskirvin
USCMS-T1 Collaboration Fermilab ECF

[comport3]

Thanks Martin, the PSIC repos are excellent - thanks!

And Tim, the logic of having the p_ modules avoiding namespace collisions also makes perfect sense at scale.

I was thinking more of a searchable, more goal oriented view of sharing Profiles that implement 1 or more technologies to form a "stack".

Eg, 'Securing SSH', 'Achieving an A-Grade with NGiNX TLS on Qualys SSL test, with maximum compatibility', 'WordPress/Magento/Drupal battle tested hosting stacks', etc.

[Rob Nelson]

Hrm, I wonder how much this has to do with definitions of what a profile module is. To me, a profile module includes a lot of component modules and conditional logic and an occasional primitive (include apache, include a logrotate config, conditionally manage all cron jobs or not). What you're describing sounds a lot like component modules I incorporate into profiles with an "include ssh" or "include wordpress" statement, possibly accompanied by some hiera data (Firefox keeps a good list of ssh ciphers depending on your OS, for example, https://wiki.mozilla.org/Security/Server_Side_TLS). Sometimes I have let a profile get too large, at which point I have split it into a component module, and it's often tricky to find that line. Ultimately, for me, a profile is implementation-specific; a component is technology- or concept-specific and not implementation-specific.

Of course, the forge is a great place to share component modules when possible (some of us aren't allowed to share stuff that starts internal, unfortunately), but not profiles. While, as Martin noted, profiles tend to be pretty specific to implementations and cannot be shared, there are certainly good or common patterns that would be useful to share (like the conditional management of cron jobs mentioned earlier), but short of treating profiles like component modules, I haven't found a good place to host them. That's an interesting possibility, to make at least some "base" profiles into a component module. I do think it might be more helpful as a reference project than as a module people include in their Puppetfile (there are bound to be conflicts and disagreements with any opinionated codebase that limits their usefulness), BUT that is still a worthwhile endeavor for those interested.

Rob Nelson

--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/71988a6c-d0f4-4f04-a768-b3f4caf49bce%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Trevor Vaughan]

The SIMP project came up with the idea of 'component profiles'. These are profiles that are meant to be shared but that work best within a specific ecosystem.

Though our naming is a little askew at the moment, we currently use 'simp_<thing>' as the component profile and '<thing>' as the component module.

For example:

• https://github.com/simp/pupmod-simp-rsyslog
  
• https://github.com/simp/pupmod-simp-simp_rsyslog
  

The first is "just rsyslog" and the second is "rsyslog the SIMP way".

Profiles are generally part of frameworks and can be abstracted but, to do so, have to be designed for abstraction.

Technically, our main 'simp' module at https://github.com/simp/pupmod-simp-simp is *the* SIMP profile from which all things spring and one of the main integration testing points.

Doing it this way means that we don't have to have alternate paths, just a different module name similar to the '_p' suggestion above.

Trevor

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CAC76iT_90u%2BuCMbsetswR5apA%3DKFCi0UFQDK-jkO0iAiJa4K2g%40mail.gmail.com.

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

--

Trevor Vaughan
Vice President, Onyx Point, Inc

(410) 541-6699 x788

-- This account not approved for unencrypted proprietary information --