You can configure systems with Puppet either in a client-server architecture, using the Puppet agent and Puppet master applications, or in a stand-alone architecture, using the Puppet apply application.
A catalog is a document that describes the desired system state for one specific computer. It lists all of the resources that need to be managed, as well as any dependencies between those resources.
Puppet configures systems in two stages:
When set up as an agent-master architecture, a Puppet master server controls the configuration information, and each managed agent node requests its own configuration catalog from the master.
In this architecture, managed nodes run the Puppet agent application, usually as a background service. One or more servers run the Puppet master application, Puppet Server.
Periodically, each Puppet agent sends facts to the Puppet master, and requests a catalog. The master compiles and returns that node’s catalog, using several sources of information it has access to.
Once it receives a catalog, Puppet agent applies it to the node by checking each resource the catalog describes. If it finds any resources that are not in their desired state, it makes the changes necessary to correct them. Or, in no-op mode, it reports on what changes would have been done.
After applying the catalog, the agent sends a report to the Puppet master.
For more information, see:
Puppet agent nodes and Puppet masters communicate by HTTPS with client verification.
The Puppet master provides an HTTP interface, with various endpoints available. When requesting or submitting anything to the master, the agent makes an HTTPS request to one of those endpoints.
Client-verified HTTPS means each master or agent must have an identifying SSL certificate. They each examine their counterpart’s certificate to decide whether to allow an exchange of information.
Puppet includes a built-in certificate authority for managing certificates. Agents can automatically request certificates through the master’s HTTP API. You can use the puppet cert command to inspect requests and sign new certificates. And agents can then download the signed certificates.
For more information, see:
Alternatively, Puppet can run in a stand-alone architecture, where each managed node has its own complete copy of your configuration info and compiles its own catalog.
In this architecture, managed nodes run the Puppet apply application, usually as a scheduled task or cron job. You can also run it on demand for initial configuration of a server or for smaller configuration tasks.
Like the Puppet master application, Puppet apply needs access to several sources of configuration data, which it uses to compile a catalog for the node it is managing.
After Puppet apply compiles the catalog, it immediately applies it by checking each resource the catalog describes. If it finds any resources that are not in their desired state, it makes the changes necessary to correct them. Or, in no-op mode, it reports on what changes would have been needed.
After applying the catalog, Puppet apply stores a report on disk. You can configure it to send reports to a central service.
For more information, see the documentation for the Puppet apply application.
In general, Puppet apply can do the same things as the combination of Puppet agent and Puppet master, but there are several trade-offs around security and the ease of certain tasks.
If you don’t have a preference, you should select the agent-master architecture. If you have questions, considering these trade-offs helps you make your decision.
puppet applydeployment, you’ll need to sync new configuration code and data to every node.