Facts at puppet
Often we are faced with the problem that the standard facts that come with puppet are not always enough. A solution to this problem can be achieved by adding new facts. You can add your Ruby facts to your puppet server. Then the server, using the synchronization of the plugins, will distribute them to all clients.
In order to see all the facts that are currently on the client, we will use the facter -p command.
For what we need the facts, see the beginning of the article by Badoo .
Suppose we need to get the output of the uname -i command to determine the bit depth of the system. To do this, we need to create a fact. Let's name our fact hardware_platform, and create hardware_platform.rb, on the Puppet server:
{modulepath}
└── {module}
└── lib
└── facter
We can use fact values when writing our owns using the Facter.value (“somefact”) or Facter.somefact construct. If there is no fact, the first will return 0, and the second will return exception.
Now, after the next launch of the puppet agent on the client, the fact will become available.
On the puppet server and client, the [main] section must have an option
Facts have several options that you can use to fine tune facts.
If your fact is unreliable and cannot always complete the job correctly, you can use timeout. If the execution time of the setcode block is longer than the timeout, Facter will interrupt the process and assign the fact the error value set to the fact.
If the facts do not change for some time or it takes a long time to find them, they can be cached. To do this, we need to add the ': ttl' option when declaring a fact
0 - never cache. The default behavior.
-1 - The cache is forever. Useful for one-time operations. For example: distribution name.
Facts have a parameter - weight. Facts with more weight are fulfilled earlier
We can restrict the execution of facts, on the basis of other facts using the - confine parameter.
For example, finding a fact only if the kernel of the system is Linux
In order to see all the facts that are currently on the client, we will use the facter -p command.
For what we need the facts, see the beginning of the article by Badoo .
Example
Suppose we need to get the output of the uname -i command to determine the bit depth of the system. To do this, we need to create a fact. Let's name our fact hardware_platform, and create hardware_platform.rb, on the Puppet server:
{modulepath}
└── {module}
└── lib
└── facter
# hardware_platform.rb
Facter.add("hardware_platform") do
setcode do
Facter::Util::Resolution.exec('/bin/uname -i')
end
end
Facts in facts
We can use fact values when writing our owns using the Facter.value (“somefact”) or Facter.somefact construct. If there is no fact, the first will return 0, and the second will return exception.
Facter.add("osfamily") do
setcode do
distid = Facter.value('lsbdistid')
case distid
when /RedHatEnterprise|CentOS|Fedora/
"redhat"
when "ubuntu"
"debian"
else
distid
end
end
end
Now, after the next launch of the puppet agent on the client, the fact will become available.
Comment
On the puppet server and client, the [main] section must have an option
pluginsync = true
Setting facts.
Facts have several options that you can use to fine tune facts.
Timeout
If your fact is unreliable and cannot always complete the job correctly, you can use timeout. If the execution time of the setcode block is longer than the timeout, Facter will interrupt the process and assign the fact the error value set to the fact.
# Случайный timeout
Facter.add(:sleep) do
timeout = 10
setcode do
if Random.rand(6) == 0
sleep 999999
else
"awake"
end
end
end
Caching
If the facts do not change for some time or it takes a long time to find them, they can be cached. To do this, we need to add the ': ttl' option when declaring a fact
Facter.add("mylongoperation", :ttl => 600) do
setcode do
... операция ...
end
end
0 - never cache. The default behavior.
-1 - The cache is forever. Useful for one-time operations. For example: distribution name.
The importance of facts
Facts have a parameter - weight. Facts with more weight are fulfilled earlier
# Проверяем
Facter.add(:role) do
has_weight 100
setcode do
if File.exist? "/etc/postgres_server"
"postgres_server"
end
end
end
# Проверяем есть ли бинарник
Facter.add(:role) do
has_weight 50
setcode do
if File.exist? "/usr/sbin/pg_create"
"postgres_server"
end
end
end
# Если сервер не похож на сервер, значит это десктоп
Facter.add(:role) do
setcode do
"desktop"
end
end
Limitation of Facts
We can restrict the execution of facts, on the basis of other facts using the - confine parameter.
For example, finding a fact only if the kernel of the system is Linux
Facter.add(:powerstates) do
confine :kernel => "Linux"
setcode do
Facter::Util::Resolution.exec('cat /sys/power/states')
end
end