Puppet is configured in an agent-master architecture, in which a master node controls configuration information for a fleet of managed agent nodes.
Note: Previous versions of Puppet offered a standalone architecture, in which agents compiled their own catalogs using the Puppet apply application. We no longer recommend this configuration, because it's challenging to maintain and secure.
Puppet Master is the key mechanism which handles all the configuration related stuff. It applies the configuration to nodes using the Puppet agent.
Puppet Agents are the actual working machines which are managed by the Puppet master. They have the Puppet agent daemon service running inside them.
This is the repo where all nodes and server-related configurations are saved and pulled when required.
Facts are the details related to the node or the master machine, which are basically used for analyzing the current status of any node. On the basis of facts, changes are done on any target machine. There are pre-defined and custom facts in Puppet.
All the manifest files or configuration which are written in Puppet are first converted to a compiled format called catalog and later those catalogs are applied on the target machine.
Master-agent communication follows this pattern:
-
An agent node sends facts to the master and requests a catalog.
-
The master compiles and returns the node’s catalog using the sources of information the master has access to.
-
The agent applies the catalog to the node by checking each resource the catalog describes. If it finds resources that are not in their desired state, it makes the changes necessary to correct them. Or, in no-op mode, it assesses what changes would be needed to reconcile the catalog.
-
The agent sends a report back to the master.
