When you use cached catalogs with the orchestrator, you can have precise control over rolling out changes.
Version and installation information
PE version: All supported
Solution
You can use instructions in our documentation to set up a workflow to configure your agents to use cached catalogs during scheduled runs, and use orchestrator jobs to send new catalogs only when you’re ready. Scheduled runs continue to enforce the desired state from the last orchestration job until you send another new catalog.
When you use this workflow, it stops the agent from pulling in new catalogs from the primary server by setting use_cached_catolog to true. A cached catalog is used when you run Puppet on the command line (puppet agent -t) and restart Puppet service.
By default, when running Puppet with a job from the CLI or the console use_cached_catolog is set to false so that the agent pulls in the latest catalog from the primary server.
In the command line, run Puppet on the primary server using the puppet job run command. Running a job requires additional flags, depending on your installation. Specify the nodes that you’d like to run the command on using a name, list, or query, an environment name (if it’s not production), and if you want to run the job as either noop or no-noop, make sure to specify that.
For example, on a node list:
puppet job run --nodes puppet-agent1.example.com,puppet-agent2.example.com
Or using a query:
puppet job run --query 'nodes[certname] { facts {name = "operatingsystem" and value = "Debian" }}'
-
To run Puppet in the console, use the instructions in our documentation.
-
Learn more about the Orchestrator API POST /command/deploy endpoint, which runs Puppet jobs.
Troubleshooting
If running Puppet via the orchestrator does not make expected changes to agents, resolve any classification errors you find in the Puppet Server log on the primary server at /var/log/puppetlabs/puppetserver/puppetserver.log.
How can we improve this article?
0 comments
Please sign in to leave a comment.
Related articles