Role vs hiera

[Ugo Bellavance]

Hi,

I've seen tutorials where they add the role as a fact in an client and then can use the role for hiera data. Is there a better way to do so (ie without having to configure anything on the client)?

Thanks,

[Matt Zagrabelny]

As a matter of fact there is a better way.

If you use an ENC, then you can return the role as a top scope
variable and your hiera configs can leverage those top scope
variables.

Here is an example where I've scrubbed any of our site data:

# puppet-enc ldap.example.com
---
classes:
role::directory_server: null
environment: production
parameters:
context: production
role: role::directory_server

The "classes" at the top and its "role" are for the classifying of the
ENC, but the "context" and "role" in the "parameters" near the bottom
are variables that get exposed - hiera is one of the things that can
use those variables.

This works super slick for us.

For what it is worth, we also use a notion of context that allows our
ENC to describe whether a node is a "testing" or "production" type
system - we have hiera lookups based on that data, too.

Let me know if you want the hiera configs.

-m

[Ugo Bellavance]

Hi,

I was actually wondering if it could be done without an ENC as we don't have one for now.

Thanks a lot for your input though.

Ugo

[Matt Zagrabelny]

On Tue, Oct 25, 2016 at 2:09 PM, Ugo Bellavance <ug...@lubik.ca> wrote:
> Hi,
>

> I was actually wondering if it could be done without an ENC as we don't have
> one for now.

Not sure. I don't think so, though. I would work on getting an ENC set up.

-m

[Rob Nelson]

I believe you're asking if there's anything in between hiera classification and creating an ENC? For FOSS, the answer is no. If you purchase Puppet Enterprise, it has its own classifier which you can use as an ENC rather than generating your own.

Rob Nelson
rnel...@gmail.com

--
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/abc28af3-5bce-4241-b219-8929c383d9a1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Luke Bigum]

It may not be as difficult as you think, and, you can *just* use it to insert a fake Fact, you don't have to start actually classifying your node classes with it.

I supplied our ENC to the list a while ago, it's just a bit of Python that reads YAML:

https://groups.google.com/forum/#!searchin/puppet-users/luke$20bigum%7Csort:date/puppet-users/XWAcm152cyQ/P_rpi50XBAAJ

[Thomas Müller]

Am Dienstag, 18. Oktober 2016 20:34:25 UTC+2 schrieb Ugo Bellavance:

Hi,

I've seen tutorials where they add the role as a fact in an client and then can use the role for hiera data. Is there a better way to do so (ie without having to configure anything on the client)?

you could add a hiera call to your main site.pp* to define a top-scope variable which then is also usable in the hiera hiearchy.

$role = hiera('role', 'default')

node "default" {
  include "::role::${::role}"
  # or hiera_include*
  hiera_include()
}

hiera.yaml example:

:backends:
  - yaml
:yaml:
  :datadir: "/etc/puppetlabs/code/environments/%{environment}/hieradata"
:hierarchy:
  - "nodes/%{::trusted.certname}"
  - "virtual/%{::role}"
  - "osfamily/%{::osfamily}"
  - common

there are more pretty solutions like https://github.com/ripienaar/puppet-classifier on Puppet4 and with the new lookup() functions with supports "knockout".

- Thomas

* https://docs.puppet.com/puppet/latest/reference/dirs_manifest.html 

https://docs.puppet.com/hiera/3.2/puppet.html#assigning-classes-to-nodes-with-hiera-hierainclude

https://docs.puppet.com/hiera/3.2/complete_example.html

https://www.devco.net/archives/2016/03/13/the-puppet-4-lookup-function.php

[Ugo Bellavance]

That looks great, thanks!

However, I just realized that my server roles are somewhat related to the server names.  For example, I could call my webservers something like www1, www2, www3.  If all those 3 servers have the same config, is there a way to create a file that would apply to all of them?  Something like /hiera/hosts/www?.yaml ?

If not, could I use a hard or soft link?

Thanks,

[Rob Nelson]

I do exactly that with a custom fact called `puppet_role`, which is listed in my hierarchy as `- "puppet_role/%{puppet_role}'​"`. See https://github.com/puppetinabox/controlrepo/blob/production/dist/profile/lib/facter/puppet_role.rb, feel free to copy that if it helps.

[Thomas Mueller]

Am 27.10.2016 um 15:43 schrieb Ugo Bellavance:
> That looks great, thanks!
>
> However, I just realized that my server roles are somewhat related to
> the server names. For example, I could call my webservers something
> like www1, www2, www3. If all those 3 servers have the same config,
> is there a way to create a file that would apply to all of them?
> Something like /hiera/hosts/www?.yaml ?

no there is no wildcard option. If your hostnames contain the role, you
could do something like this:


if $trusted['certname'] =~ /^([a-z]+)[0-9]+\./) {
$role = $1
} else {
fail('Could not determine role')
# or set some default role? or call $role = hiera('role'), ... whatever you like
}

I really only would do it by hostname if you are sure your dns names
reflect the roles now and forever (or if you are in position to decide
that it will be that way forever).

or like Rob has written, creating a custom fact works too.

>
> If not, could I use a hard or soft link?

This should work IMHO.

- Thomas

[Ugo Bellavance]

Considering our size, I think I'll go that way.

Thanks everyone for all your help!

Ugo

[Martijn]

Op dinsdag 18 oktober 2016 21:50:37 UTC+2 schreef Matt Zagrabelny:

If you use an ENC, then you can return the role as a top scope
variable and your hiera configs can leverage those top scope
variables.

 

Let me know if you want the hiera configs.

-m

Hi Matt,

That's interesting. What are you using for ENC?

And I'd love to see your hiera configs, please.

Thanks, Martijn  

[Matt Zagrabelny]

On Sat, Nov 19, 2016 at 2:27 PM, Martijn <mar...@heemels.com> wrote:
> Op dinsdag 18 oktober 2016 21:50:37 UTC+2 schreef Matt Zagrabelny:
>>
>>
>> If you use an ENC, then you can return the role as a top scope
>> variable and your hiera configs can leverage those top scope
>> variables.
>>
>
>>
>> Let me know if you want the hiera configs.
>>
>> -m
>
>
> Hi Matt,
>
> That's interesting. What are you using for ENC?

Custom python script that uses a custom database to hold node names,
roles, and "production" vs "testing" status.

Since puppet has already claimed the "environment" noun for the
filesystem serving space, I use "context" as the variable name that
holds the "production" vs. "testing" status.

In hiera, we have the following hierarchy, which is repeated in the
hiera.yaml config further down.

1. Node specific hiera data is closest to the node.
2. Whatever role a node is has the next priority for hiera data.
3. The "context" (production vs. testing) is closer to the global
(common) hiera space - so context comes after role.
4. Lastly, the global (common) hiera lookup file.

The 3rd item on the list allows us to have a single place for
application/database passwords with different passwords for testing
and production systems without having to duplicate the password in
some.fqdn.node.yaml files.

Pretend that the following 2-D grid are nodes that have their
respective roles and contexts.

Context
prod | test
role app_0_server | app_0_server
role db_0_server | db_0_server
role app_1_server | app_1_server
role db_1_server | db_1_server
role . | .
role . | .
role . | .

Thus the production app_0_server and db_0_server can easily have a
shared password that is different from the testing app_0_server and
db_0_server due to the vertical slicing of the hierarchy.

> And I'd love to see your hiera configs, please.

% cat /etc/puppet/hiera.yaml
---
:backends:
- yaml
:yaml:
:datadir: /etc/puppet/hiera
:hierarchy:
- "environments/%{::environment}/node/%{clientcert}"
- "environments/%{::environment}/role/%{role}"
- "environments/%{::environment}/context/%{context}"
- "environments/%{::environment}/common"

-m