Puppet external facts for Windows

puppet-facts

Puppet external facts. What’s that? How to collect and manage them in a Windows environment? External facts are pieces of information that can be used by Puppet to determine the configuration of a system. External facts can be sourced from a variety of sources such as scripts, databases, or APIs. Probably, facts are one of the most crucial features of Puppet. Think about facts as attributes to describe objects and components. Anything that can live in the environment being managed by Puppet. This is certainly essential to collect them in order to be used later in Puppet modules. In the Puppet docs You can find out more details about Puppet facts in general.

Puppet external facts examples

On Windows systems, external facts can be written in any language that is available on the system and can be executed from the command line. To use external facts in Puppet, you will need to specify the location of the script that contains the facts and the name of the fact. As Puppet facts you may want to collect various data. Below I’ve listed several examples to be considered in every Windows environment.

Variables

All attributes specific to host, environment, etc.

Deployment status

In Puppet sometimes it is required to store somewhere information about deployment status. This could be some kind of indicators showing true or false. Hence, the registry seems like one of the places where they can be stored in Windows environment. The facts can be used to collect that info. Later they will be available for Puppet itself.

Installed / missing components

Not everything can be easily managed by Puppet resources. Therefore, sometimes You will need to collect info about some installed components. Later you can reference it from Puppet. As result Puppet will be aware of any missing components.

Important services

Windows services that are not managed by Puppet, but having dependencies on Puppet modules, are good example of data to be collected. Especially service status is crucial info to be considered for facts collection.

# Variables
Function Get-Variables {
  ...
  Write-Host "...=$..."
  ...
}

# Deployment status
Function Test-Deployment {
  ...
  Write-Host "...=$..."
  ...
}

# Installed / missing components
Function Test-MissingComponents {
  ...
  Write-Host "...=$..."
  ...
}

# Important services
Function Test-Services {
  ...
  Write-Host "...=$..."
  ...
}

Get-Variables
Test-Deployment
Test-MissingComponents
Test-Services

Above is just an example of powershell script structure that could be used for Windows facts collection.

How to deploy and manage it

Since the facts usually varies across environments, it is good practice to maintain at least one facter script per environment. One way of achieving that is to store the powershell script in custom module as a template with various versions per environment. Here is a code snippet that You can use for ensuring that powershell script is deployed to the host. Later it will be used for external facts collection.

file { 'c:\ProgramData\PuppetLabs\facter\facts.d\windowsfacts.ps1':
  ensure => file,
  content => template("<module_name>/config/windowsfacts.ps1.${server_facts['environment']}.erb"),
}

Bonus

It was mentioned above to store facter powershell script in custom module as a template. The reason being is to enable hiera data usage. Hence, it can be part of Windows facts powershell script. As a result, you will end up with parametrized script controlled by very flexible mechanizm of hiera data. Here you can read more about hiera.

References:

Leave a Reply

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