By default, Puppet offers you many facts…

[root@puppetserver ~]# facter --yaml | wc -l
221

Display some facts (operating system for example, JSON format by default) :

[root@puppetserver ~]# facter os
{
  architecture => "x86_64",
  family => "RedHat",
  hardware => "x86_64",
  name => "OracleLinux",
  release => {
    full => "7.2",
    major => "7",
    minor => "2"
  },
  selinux => {
    config_mode => "enforcing",
    current_mode => "enforcing",
    enabled => true,
    enforced => true,
    policy_version => "28"
  }
}

Or show the “Desktop Management Interface” (in YAML format) :

[root@puppetserver ~]# facter --yaml dmi
dmi:
  bios:
    release_date: 07/14/2016
    vendor: Xen
    version: 4.4.1-xs126982
  chassis:
    type: Other
  manufacturer: Xen
  product:
    name: HVM domU
    serial_number: f6a9a3ac-1a61-7971-91ce-f9d389c70a3d
    uuid: F6A9A3AC-1A61-7971-91CE-F9D389C70A3D

Create your own facts

On each Puppet node, you can create your own facts, it’s really straightforward.

Use Puppet 4.x release :

[root@puppetserver ~]# puppet --version
4.7.0

Add JSON or YAML format files in “/opt/puppetlabs/facter/facts.d” directory :

[root@puppetserver ~]# cd /opt/puppetlabs/facter/facts.d
  • JSON format :
[root@puppetserver facts.d]# cat my_facts.json
{
  "my_own_fact1": "this is my value for my fact1",
  "my_own_fact2": "this is my value for my fact2"
}
  • YAML format :
[root@puppetserver facts.d]# cat my_facts.yaml
---
my_own_fact3: 'this is my value for my fact3'
my_own_fact4: 'this is my value for my fact4'

Use “facter” utility to read your facts :

[root@puppetserver facts.d]# facter | grep my_own_fact
my_own_fact1 => this is my value for my fact1
my_own_fact2 => this is my value for my fact2
my_own_fact3 => this is my value for my fact3
my_own_fact4 => this is my value for my fact4

Read those facts using Puppet :

[root@puppetserver facts.d]# puppet apply -e 'notify { "${::my_own_fact1} # ${::my_own_fact2} # ${::my_own_fact3} # ${::my_own_fact4}": }'
Notice: Compiled catalog for puppetserver.argonay.wou in environment production in 0.12 seconds
Notice: this is my value for my fact1 # this is my value for my fact2 # this is my value for my fact3 # this is my value for my fact4
Notice: /Stage[main]/Main/Notify[this is my value for my fact1 # this is my value for my fact2 # this is my value for my fact3 # this is my value for my fact4]/message: defined 'message' as 'this is my value for my fact1 # this is my value for my fact2 # this is my value for my fact3 # this is my value for my fact4'
Notice: Applied catalog in 0.11 seconds

Of course, you can use your own facts in a Puppet manifest :

  • Put you example a any directory :
[root@puppetserver facts.d]# mkdir /my_examples && cd /my_examples
  • Here is short manifest example (we execute the class within the same file) :
[root@puppetserver my_examples]# cat own_facts_example.pp
# class definition :
class own_facts_example (
  $debugging = false
)
{
  if $debugging {
    notify { "${::my_own_fact1} # ${::my_own_fact2} # ${::my_own_fact3} # ${::my_own_fact4}": }
  }
}

# execute this class :
class { 'own_facts_example':
  debugging => true,
}
  • Syntax looks good :
[root@puppetserver my_examples]# puppet parser validate own_facts_example.pp
  • Ask Puppet to execute :
[root@puppetserver my_examples]# puppet apply own_facts_example.pp
Notice: Compiled catalog for puppetserver.argonay.wou in environment production in 0.13 seconds
Notice: this is my value for my fact1 # this is my value for my fact2 # this is my value for my fact3 # this is my value for my fact4
Notice: /Stage[main]/Own_facts_example/Notify[this is my value for my fact1 # this is my value for my fact2 # this is my value for my fact3 # this is my value for my fact4]/message: defined 'message' as 'this is my value for my fact1 # this is my value for my fact2 # this is my value for my fact3 # this is my value for my fact4'
Notice: Applied catalog in 0.11 seconds

Now, stop bullsheet, use custom facts and hiera to simplify your Puppet infrastructure !

By default, you have a default hiera file:

[root@puppetserver my_examples]# puppet config print hiera_config
/etc/puppetlabs/puppet/hiera.yaml

Where you find a default configuration :

[root@puppetserver my_examples]# cat /etc/puppetlabs/puppet/hiera.yaml
---
:backends:
  - yaml
:hierarchy:
  - "nodes/%{::trusted.certname}"
  - common

:yaml:
# datadir is empty here, so hiera uses its defaults:
# - /etc/puppetlabs/code/environments/%{environment}/hieradata on *nix
# - %CommonAppData%\PuppetLabs\code\environments\%{environment}\hieradata on Windows
# When specifying a datadir, make sure the directory exists.
  :datadir:

Don’t hesitate to enhance this poor structure !

In our infrastructure, we decided for example to classify our machines according the business criticity and the security level.

We defined for this Puppet node (here, Puppet master is one of all nodes) :

[root@puppetserver facts.d]# cat custom_facts.yaml
---

# custom facts :
business:       'sandbox'
security:       'high'

We can modify the hierarchy :

[root@puppetserver facts.d]# cat /etc/puppetlabs/puppet/hiera.yaml
---
:backends:
  - yaml
:hierarchy:
  - "nodes/%{::trusted.certname}"
  - "security/%{::security}"
  - "business/%{::business}"
  - common

:yaml:
# datadir is empty here, so hiera uses its defaults:
# - /etc/puppetlabs/code/environments/%{environment}/hieradata on *nix
# - %CommonAppData%\PuppetLabs\code\environments\%{environment}\hieradata on Windows
# When specifying a datadir, make sure the directory exists.
  :datadir:

We creates directories (here for “production”) :

[root@puppetserver facts.d]# mkdir /etc/puppetlabs/code/environments/production/hieradata/{security,business}

And we start to create YAML files :

[root@puppetserver facts.d]# cat /etc/puppetlabs/code/environments/production/hieradata/business/sandbox.yaml
---

# for "sandbox" :
classes:
  create_test_accounts

backup: 'false'

“create_test_accounts” class will be excuted on nodes which have “business” fact set to “sandbox”.

[root@puppetserver facts.d]# cat /etc/puppetlabs/code/environments/production/hieradata/security/high.yaml
---

# for high level security .
classes:
  enhance_security

“enhance_security” class will be executed on nodes which have “security” fact set to “high”.

 

en.pdf24.org    Send article as PDF   

Leave a Reply

Your email address will not be published. Required fields are marked *


*