layout | title | canonical |
---|---|---|
default |
Puppet's Services: Puppet Apply |
/puppet/latest/reference/services_apply.html |
Puppet apply is an application that compiles and manages configurations on nodes. It acts like a self-contained combination of the puppet master and puppet agent applications. For more info about Puppet's architecture, see Overview of Puppet's Architecture --- in particular, read the note at the end about differences and trade-offs between agent/master and puppet apply.
For details about invoking the puppet apply command, see the puppet apply man page.
Puppet apply runs similarly on both *nix and Windows systems.
Not all operating systems can manage the same resources with Puppet; some resource types are OS-specific, and other types may have OS-specific features. See the type reference for details.
Unlike puppet agent, puppet apply never runs as a daemon or service. It always runs as a single task in the foreground, which compiles a catalog, applies it, files a report, and exits.
By default, it never initiates outbound network connections, although it can be configured to do so. It never accepts inbound network connections.
Like the puppet master application, puppet apply uses its settings (such as basemodulepath
) and the configured environments to locate the Puppet code and configuration data it will use when compiling a catalog.
The one exception is the main manifest. Puppet apply always requires a single command line argument, which acts as its main manifest. It ignores the manifest
setting and the default main manifest from an environment.
(Alternately, you can write a tiny main manifest directly on the command line, with the -e
option. See the puppet apply man page for details.)
Puppet apply runs as whichever user executed the puppet apply command.
To manage a complete system, you should run puppet apply as:
root
on *nix systems- Either
LocalService
or a member of theAdministrators
group on Windows systems
Puppet apply can also run as a non-root user. This will restrict the resources that Puppet can manage (see below).
When running without root permissions, most of Puppet's resource providers cannot use sudo
to elevate permissions. This means Puppet can only manage resources that its user can modify without using sudo
.
Out of the core resource types listed in the type reference, the following resource types are available to non-root puppet apply runs:
cron
(only non-root cron jobs can be viewed or set)exec
(cannot run as another user or group)file
(only if the non-root user has read/write privileges)notify
schedule
ssh_key
ssh_authorized_key
service
(for services that don't require root. You can also use thestart
,stop
, andstatus
attributes to specify how non-root users should control the service; see the tips and examples for the service type for more info.)augeas
If you need to install packages into a directory controlled by a non-root user, you can either use an exec
to unzip a tarball or use a recursive file
resource to copy a directory into place.
By default, puppet apply does not communicate over the network. It uses its local collection of modules for any file sources, and does not submit reports to a central server.
Depending on your system and the resources you are managing, it may download packages from your configured package repositories or access files on UNC shares.
If you have configured an external node classifier (ENC), your ENC script might create an outbound HTTP connection. Additionally, if you've configured the HTTP report processor, puppet agent may send reports via HTTP or HTTPS.
If you have configured PuppetDB, puppet apply will create outbound HTTPS connections to PuppetDB.
By default, puppet apply logs directly to the terminal. This is good for interactive use, and less good when running as a scheduled task or cron job.
When started with the --logdest syslog
option, it logs to the *nix syslog service. Your syslog configuration dictates where these messages will be saved, but the default location is /var/log/messages
on Linux, /var/log/system.log
on Mac OS X, and /var/adm/messages
on Solaris.
When started with the --logdest eventlog
option, it logs to the Windows Event Log. You can view its logs by browsing the Event Viewer. (Control Panel → System and Security → Administrative Tools → Event Viewer)
When started with the --logdest <FILE>
option, it logs to the file specified by <FILE>
.
In addition to local logging, puppet apply will process a report using its configured report handlers, like a puppet master does. You can enable different reports with the reports
setting; see the list of available reports for more info. For more about reporting, see the guide to reporting.
To disable reporting and avoid taking up disk space with the store
report handler, you can set report = false
in puppet.conf.
In a normal Puppet site, every node should periodically do configuration runs, to revert unwanted changes and to pick up recent updates.
Since puppet apply doesn't run as a service, you must manually create a scheduled task or cron job if you want it to run on a regular basis.
On *nix, you can use the puppet resource command to set up a cron job. Below is an example that runs Puppet once an hour; adjust the path to the Puppet command if you are not using Puppet Enterprise.
$ sudo puppet resource cron puppet-apply ensure=present user=root minute=30 command='/opt/puppet/bin/puppet apply /etc/puppetlabs/puppet/manifests --logdest syslog'
Puppet apply should be configured with puppet.conf, using the [user]
and/or [main]
section. For notes on which settings are most relevant to puppet apply, see the short list of important settings.