The content below is taken from the original ( Puppet Bolt Agentless Automation for Linux and Windows Server), to continue reading please visit the site. Remember to respect the Author & Copyright.
Puppet Bolt is an agentless and masterless remote task runner that you can use with your existing PowerShell, Python, and Bash scripts.
Over the last few months on Petri, I’ve been looking at using Puppet to automate Windows Server configuration. While PowerShell Desired State Configuration (DSC) provides similar functionality and is built in to Windows, Puppet is a more mature solution, is widely adopted in enterprise environments, and it is cross platform.
If you missed my articles on using Puppet to manage Windows Server, you can get the links to all seven parts here. There are also some additional articles on setting up open source Puppet and Puppet Enterprise on Red Hat Enterprise Linux here and here on Petri.
Introducing Puppet Bolt
Earlier this month, Puppet Labs announced the availability of Puppet Bolt 1.0, an open source, agentless, cross-platform configuration management solution that aims to make it easier to get started with automation. Puppet Bolt is a remote task runner and supports any language that your nodes can run. You don’t need to know Puppet to work with it. Bolt can run any existing management scripts that you have.
Masterless and Agentless
Unlike Puppet, Bolt uses WinRM (or SSH on Linux) to communicate directly with remote systems, doing away with the need to install agents on managed nodes. Puppet Bolt allows sysadmins to run existing scripts written using Bash, PowerShell, Python, and any language that your nodes can run; and use more than 5,000 modules in the Puppet Forge.
Puppet Bolt is also designed to be serverless (masterless). Puppet doesn’t necessarily require a master server, but it is designed to work best in a client/server architecture. Masterless Puppet also comes with challenges. Without a master server, you need to sync modules to each node, copy any other required files, and trigger a ‘puppet apply’. Plus, sensitive data can’t easily be restricted to exist just where it is needed.
Puppet Bolt is designed to get you up and running quickly – no agents, no servers – and solve all the problems with masterless Puppet. Files describing the desired state for each resource on a node (catalogs) contain only the input required. Secrets can be pulled in as needed and modules are copied when catalogs are applied.
Tie Tasks Together with Bolt Plans
Bolt ‘plans’ are used to bring tasks together and are written in the Puppet plan language. Plans look much like Puppet manifests with some additional functionality for running tasks. Bolt can manage complex configurations using classes, parameters, functions, and automatically pull modules from Puppet Forge.
Imperative and Declarative Together
Puppet uses a declarative syntax language (Puppet DSL) for modeling your infrastructure. In other words, rather than specifying a list of technical steps that need to be completed, like in a script, you define what your infrastructure should look like rather than how it should be achieved. Puppet DSL is supported by Bolt Apply, allowing you to add Puppet code to your Bolt plans to enforce a state without a Puppet master server. But because Puppet Bolt is a remote task runner, it can run imperative commands for ad-hoc tasks, giving you the best of both declarative and imperative configuration worlds.
Baseline Configuration without an Agent
Bolt is an important step forward for Puppet because it brings it in line with other popular configuration management solutions, like Ansible and Chef, that don’t need an agent to set up a baseline configuration. Bolt can connect to PuppetDB and Orchestrator, and it is supported for organizations that have licenced Puppet Enterprise.
Watch this space for some hands-on articles on getting started with Puppet Bolt.
The post Puppet Bolt Agentless Automation for Linux and Windows Server appeared first on Petri.
