the first step is to define—using Puppet DSL—what the
desired state of the infrastructure needs to be. These
definitions are captured in text files called Puppet
manifests. Some examples of desired states at this stage
could be the existence of a certain VLAN on all switches
in the network or maybe just a subset of devices, how
and which interfaces should be configured on border
routers, and which NTP servers to use for time
synchronization.
Once the desired state is defined, Puppet offers the
option to simulate the changes needed to reach that state
and see what would happen if the changes were applied.
This gives the administrator a chance to dry run the
Puppet manifests and take note of what changes would
actually get applied to the devices.
If the changes to be performed to reach the desired state
are in line with expectations, the manifests can be
executed, and the changes can be enforced. The Puppet
agents report back to the Master with the status of the
tasks that are being executed.
The Puppet software agent running on the managed
devices is the enforcing element of the solution. The
other component that is usually installed on the
managed device is facter, which has the role of gathering
facts about the managed device and reporting them back
to the Master control server. facter reports to the control
node facts such as operating system, hardware
configuration, and number and type of interfaces.
The Puppet Master analyzes the facts, compares them to
its database, and builds a catalog that describes how the
managed device should be configured. The device-
specific catalog is then pushed back to the device. The
device receives the catalog and compares the policy with
its current state, and if they are different, it applies the
changes specified in the catalog. If the new policy and the