D7net
Home
Console
Upload
information
Create File
Create Folder
About
Tools
:
/
usr
/
share
/
doc
/
hiera-1.3.4
/
Filename :
README.md
back
Copy
# Hiera [](https://travis-ci.org/puppetlabs/hiera) A simple pluggable Hierarchical Database. - **Tutorials:** Check the docs directory for tutorials. ## Why? Hierarchical data is a good fit for the representation of infrastructure information. Consider the example of a typical company with 2 datacenters and on-site development, staging etc. All machines need: - ntp servers - sysadmin contacts By thinking about the data in a hierarchical manner you can resolve these to the most correct answer easily: <pre> /------------- DC1 -------------\ /------------- DC2 -------------\ | ntpserver: ntp1.dc1.example.com | | ntpserver: ntp1.dc2.example.com | | sysadmin: dc1noc@example.com | | | | classes: users::dc1 | | classes: users::dc2 | \-------------------------------/ \-------------------------------/ \ / \ / /------------- COMMON -------------\ | ntpserver: 1.pool.ntp.org | | sysadmin: "sysadmin@%{domain}" | | classes: users::common | \----------------------------------/ </pre> In this simple example machines in DC1 and DC2 have their own NTP servers, additionaly DC1 has its own sysadmin contact - perhaps because its a remote DR site - while DC2 and all the other environments would revert to the common contact that would have the machines domain fact expanded into the result. The _classes_ variable can be searched using the array method which would build up a list of classes to include on a node based on the hierarchy. Machines in DC1 would have the classes _users::common_ and _users::dc1_. The other environment like development and staging would all use the public NTP infrastructure. This is the data model that extlookup() have promoted in Puppet, Hiera has taken this data model and extracted it into a standalone project that is pluggable and have a few refinements over extlookup. ## Enhancements over Extlookup Extlookup had just one backend, Hiera can be extended with your own backends and represent a few enhancements over the base Extlookup approach thanks to this. ### Multiple backends are queried If you have a YAML and Puppet backend loaded and your users provide module defaults in the Puppet backend you can use your YAML data to override the Puppet data. If the YAML doesnt provide an answer the Puppet backend will get an opportunity to provide an answer. ### More scope based variable expansion Extlookup could parse data like %{foo} into a scope lookup for the variable foo. Hiera retains this ability and any Arrays or Hashes will be recursively searched for all strings that will then be parsed. The datadir and defaults are now also subject to variable parsing based on scope. ### No CSV support by default We have not at present provided a backward compatible CSV backend. A converter to YAML or JSON should be written. When the CSV backend was first chosen for Puppet the Puppet language only supports strings and arrays of strings which mapped well to CSV. Puppet has become (a bit) better wrt data and can now handle hashes and arrays of hashes so it's a good time to retire the old data format. ### Array Searches Hiera can search through all the tiers in a hierarchy and merge the result into a single array. This is used in the hiera-puppet project to replace External Node Classifiers by creating a Hiera compatible include function. ## Future Enhancements * More backends should be created * A webservice that exposes the data * Tools to help maintain the data files. Ideally this would be Foreman and Dashboard with their own backends ## Installation Hiera is available as a Gem called _hiera_ and out of the box it comes with just a single YAML backend. Hiera is also available as a native package via apt (http://apt.puppetlabs.com) and yum (http://yum.puppetlabs.com). Instructions for adding these repositories can be found at http://docs.puppetlabs.com/guides/installation.html#debian-and-ubuntu and http://docs.puppetlabs.com/guides/installation.html#enterprise-linux respectively. At present JSON (github/ripienaar/hiera-json) and Puppet (hiera-puppet) backends are availble. ## Configuration You can configure Hiera using a YAML file or by providing it Hash data in your code. There isn't a default config path - the CLI script will probably assume _/etc/hiera.yaml_ though. The default data directory for file based storage is _/var/lib/hiera_. A sample configuration file can be seen here: <pre> --- :backends: - yaml - puppet :logger: console :hierarchy: - "sites/%{location}" - common :yaml: :datadir: /etc/puppet/hieradata :puppet: :datasource: data </pre> This configuration will require YAML files in _/etc/puppet/hieradata_ these need to contain Hash data, sample files matching the hierarchy described in the _Why?_ section are below: _/etc/puppet/hieradata/sites/dc1.yaml_: <pre> --- ntpserver: ntp1.dc1.example.com sysadmin: dc1noc@example.com </pre> _/etc/puppet/hieradata/sites/dc2.yaml_: <pre> --- ntpserver: ntp1.dc2.example.com </pre> _/etc/puppet/hieradata/common.yaml_: <pre> --- sysadmin: "sysadmin@%{domain}" ntpserver: 1.pool.ntp.org </pre> ## Querying from CLI You can query your data from the CLI. By default the CLI expects a config file in _/etc/hiera.yaml_ but you can pass _--config_ to override that. This example searches Hiera for node data. Scope is loaded from a Puppet created YAML facts store as found on your Puppet Masters. If no data is found and the facts had a location=dc1 fact the default would be _sites/dc1_ <pre> $ hiera acme_version 'sites/%{location}' --yaml /var/lib/puppet/yaml/facts/example.com.yaml </pre> You can also supply extra facts on the CLI, assuming Puppet facts did not have a location fact: <pre> $ hiera acme_version 'sites/%{location}' location=dc1 --yaml /var/lib/puppet/yaml/facts/example.com.yaml </pre> Or if you use MCollective you can fetch the scope from a remote node's facts: <pre> $ hiera acme_version 'sites/%{location}' -m box.example.com </pre> You can also do array merge searches on the CLI: <pre> $ hiera -a classes location=dc1 ["users::common", "users::dc1"] </pre> ## Querying from code This is the same query programatically as in the above CLI example: <pre> require 'rubygems' require 'hiera' require 'puppet' # load the facts for example.com scope = YAML.load_file("/var/lib/puppet/yaml/facts/example.com.yaml").values # create a new instance based on config file hiera = Hiera.new(:config => "/etc/puppet/hiera.yaml") # resolve the 'acme_version' variable based on scope # # given a fact location=dc1 in the facts file this will default to a branch sites/dc1 # and allow hierarchical overrides based on the hierarchy defined in the config file puts "ACME Software Version: %s" % [ hiera.lookup("acme_version", "sites/%{location}", scope) ] </pre> ## Extending There exist 2 backends at present in addition to the bundled YAML one. ### JSON This can be found on github under _ripienaar/hiera-json_. This is a good example of file based backends as Hiera provides a number of helpers to make writing these trivial. ### Puppet This is much more complex and queries the data from the running Puppet state, it's found on GitHub under _ripienaar/hiera-puppet_. This is a good example to learn how to map your internal program state into what Hiera wants as I needed to do with the Puppet Scope. It includes a Puppet Parser Function to query the data from within Puppet. When used in Puppet you'd expect Hiera to log using the Puppet infrastructure, this plugin includes a Puppet Logger plugin for Hiera that uses the normal Puppet logging methods for all logging. ## License See LICENSE file. ## Support Please log tickets and issues at our [Projects site](http://projects.puppetlabs.com)