We are using what you called option 3. The main reason to use option 3
instead of 1 was that this way we can have our "truth" under version
control.
El 29/06/15 a las 16:50, Nicola V escribió:
Hello,
We're considering to migrate away from node definitions to something
more future proof, with the idea to introduce an ENC into our
infrastructure. I found some discussions loosely touching the topic from
a few years back, and I'd love to hear what would be the "way to go"
now, in 2015.
Foreman is the tool that impressed us the most for the abundance of
features, especially the inventory tracking and host deployment
capabilities (the Discovery plugin is powerful).
At the same time Hiera seems to be gaining a lot of traction, being able
to provide ENC capabilities and hierarchical parameters assignment, but
obviously none of the asset tracking and deployment feats of Foreman.
The two can interoperate, from what I see, being different tools for
different jobs. Yet, they seem to overlap a bit in their scope. Here's
how I see them fit in the picture:
1. Foreman for host deployment, asset tracking, reporting, node
classification (ENC) and parameter assignment. No Hiera
2. Foreman for host deployment, asset tracking, reporting, node
classification (ENC). Hiera for parameter assignment. The popular
roles/profiles paradigm would be implemented via Foreman's Config Groups
(profiles) and Host Groups (roles). Hiera provides the parameters to the
classes.
3. Foreman for host deployment, asset tracking and reporting. Hiera acts
as an ENC and assigns roles and profiles via include. Parameters are
provided by Hiera, too
Let's see the situation:
Option 1 is good for centralization: in essence, Foreman would be the
only "data store" or "source of truth" about the infrastructure. I don't
find the smart parameters/smart classes feature intuitive enough. I'm
afraid it might prove non-scalable in the long run, and not so clear to
debug, considering smart-matchers at class level have to be used (unless
I got it completely wrong). Also, it's not immediately versionable.
Option 2 is a good trade off, but there would be two different places
where to store information about nodes (roles/profiles in Foreman,
params in Hiera). This might confuse people.
Option 3 might be the best: Foreman would complement Hiera and the
infrastructure would be almost entirely versionable in case YAML or JSON
files are used as a Hiera backend.
Any opinion in regard from the Foreman/Puppet community? It seems like
there's many way to approach this and I'm quite confused.
Thanks
Nicola
--
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
<mailto:puppet-users+unsubscr...@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/09e80665-22dd-43ba-87d5-3aaeec7041fe%40googlegroups.com
<https://groups.google.com/d/msgid/puppet-users/09e80665-22dd-43ba-87d5-3aaeec7041fe%40googlegroups.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.
--
Angel L. Mateo Martínez
Sección de Telemática
Área de Tecnologías de la Información
y las Comunicaciones Aplicadas (ATICA)
http://www.um.es/atica
Tfo: 868887590
Fax: 868888337
--
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/5593867C.1060208%40um.es.
For more options, visit https://groups.google.com/d/optout.
