This is the situation I have:
All my hosts are the* same OS.*
All my host are in the* same puppet environment,* so I cannot use
%{environment}
I have a module that sets all the *basic* functionality for the OS,
resolution, authentication, security, packages, etc
I have a module for each application hosted.
At the moment all the 'data' is in Puppet, mostly in parametrised classes
in site.pp.
What I want to get is a hiera set-up that allows me to use this structure:
:hierarchy:
- global # source of application names (classes? modules?) and
environments list
- basic # data for the basic class
- prod/%{application}/%{hostname} # hostname files for specific
data
- prod/%{application}/%{env} # environmental data for
each application (module)
- prod/%{application}/default # default data for an
application
- nonprod/%{sysclass}/%{hostname}
- nonprod/%{sysclass}/%{env}
- nonprod/%{sysclass}/default
Then to have something like this under the datadir:
#├── global.yaml
#├── basic.yaml
#├── nonprod
#│ ├── app1
#│ │ ├── common-integration.yaml << Alfresco common
integration
#│ │ ├── continuous-integration.yaml
#│ │ ├── dev.yaml
#│ │ ├── default.yaml
#│ │ ├── host1.yaml
#│ │ ├── host2.yaml
#│ │ ├── performance.yaml
#│ │ ├── qa.yaml
#│ │ ├── test.yaml
#│ │ └── uat.yaml
#│ └── app2
#└── prod
# ├── app1
# └── app2
#
# etc.
In global.yaml
---
:classes:
basic:
app1:
app2:
app3:
app4:
:env:
test:
dev:
commonint:
continuousint:
dev:
performance:
qa:
test:
uat:
in app1 default.yaml:
---
classes:
app1:
app1_version: 'latest'
in app1 dev.yaml:
---
app1_version: '3.0'
If I wanted host1 and host2 to be part of dev for app1:
host1.yaml:
---
classes:
basic:
app1:
env:
dev:
maybe in host2 I want to override version too:
host2.yaml
---
classes:
basic:
app1:
env:
dev:
app1_version: '3.1'
So in short, I would like hiera to be a source of facts, where I can get
information that feeds Puppet in order to classify the nodes and to feed
the parametrised classes.
I recently found this blog entry:
http://garyhetzel.com/2012/04/12/hiera_as_a_puppet_enc
Gary has been very helpful and I have got an idea of what needs doing. I
can query all the data the way I want using the hiera command. Something
like these:
hiera app1_version sysclass=app1 env=dev
Returns the expected '3.0' and if I query by adding teh host:
hiera app1_version sysclass=app1 env=dev hostname=host1
I get 3.1. Cool!
Example using Gary's approach:
/opt/puppet-data/nonprod/hieratest/default.yaml
---
classes: hieratest
env: hieratest_default
/opt/puppet-data/nonprod/hieratest/host1.yaml
---
classes:
hieratest:
env: 'hieratest_performance'
# hiera env sysclass=hieratest --debug
DEBUG: Wed Sep 26 16:40:46 +0100 2012: Hiera YAML backend starting
DEBUG: Wed Sep 26 16:40:46 +0100 2012: Looking up type in YAML backend
DEBUG: Wed Sep 26 16:40:46 +0100 2012: Looking for data source global
DEBUG: Wed Sep 26 16:40:46 +0100 2012: Looking for data source basic
DEBUG: Wed Sep 26 16:40:46 +0100 2012: Looking for data source
nonprod/hieratest/default
DEBUG: Wed Sep 26 16:40:46 +0100 2012: Found env in
nonprod/hieratest/default
hieratest_default
# hiera type sysclass=hieratest hostname=host1 --debug
DEBUG: Wed Sep 26 16:40:57 +0100 2012: Hiera YAML backend starting
DEBUG: Wed Sep 26 16:40:57 +0100 2012: Looking up type in YAML backend
DEBUG: Wed Sep 26 16:40:57 +0100 2012: Looking for data source global
DEBUG: Wed Sep 26 16:40:57 +0100 2012: Looking for data source basic
DEBUG: Wed Sep 26 16:40:57 +0100 2012: Looking for data source
nonprod/hieratest/host1
DEBUG: Wed Sep 26 16:40:57 +0100 2012: Found env in nonprod/hieratest/host1
hieratest_performance
But when it comes to use this in Puppet the results are not as I expect,
nothing happens, it just does a run no classes are used. I see that the
basic class custom facts are loaded, but nothing gets executed, as if the
catalogue for host1 would not include it.
In Puppet I expect to just have:
in site.pp:
node default {}
And then in each application’s init.pp:
$env = hiera("env") << this allows me to get the right config files (with
are maintained in a git repo)
$app1_version = hiera("app1_version") << this allows me to set the right
RPM version (from satellite/spacewalk/RHN)
As per Gary's post, I can use hiera as node terminus, and so it is set in
puppet.conf.
I would like to make emphasis in this: Gary's hiera as an ENC works, but
for a more simple scenario than the one I am proposing, if I only wanted to
classify Classes and Hosts, it does work fine. Where I have not been able
to succeed is in adding an 'env' layer after the application (classes,
organised in modules).
I can get to organise things solely by host-name too (I could have a huge
list of hundreds of hosts and manage that), but what I need is to be able
to split them into directories as these are managed by each team
responsible for the applications.
I a a beginner in ruby, and I am willing to help as much as I can to get
the use of hiera as an ENC as much as possible.
Do I have the right approach given the requirements?
Is there a better approach to this one?
Kind regards,
Guillem
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/kFpoqN97hncJ.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
