Deploying applications and managing infrastructure can feel like a slow, complex maze. You’re juggling servers, configs, and endless scripts, and you wish for a way to make things move faster and smoother. What if there was a tool that could cut down deployment times and help you manage your infrastructure with more ease?
That’s where Puppet Bolt comes in. This tool gives you a way to run ad hoc tasks and orchestrate complex workflows with a few commands. In this Puppet Bolt guide, we’ll walk you through how it can help speed up your deployments and simplify your infrastructure management.
What is Puppet Bolt?
Puppet Bolt is an open-source, agentless task runner from Puppet. It’s designed to let you run commands, scripts, and Puppet code on remote machines without needing a central server. This approach makes it a great fit for one-off tasks, quick fixes, and even complex automation workflows.
Think of Bolt as a Swiss Army knife for sysadmins and DevOps engineers. It can help you do things such as:
- Run commands on many servers at once.
- Deploy apps or update software.
- Manage config files.
- Automate repetitive tasks to free up time.
Bolt is different from other config management tools that use a central server because it is agentless. This means it does not need any software installed on each target node (besides SSH or WinRM) to run tasks. This makes it very easy to set up and get going fast.
Agentless Architecture
Bolt’s agentless design is one of its main draws. The way it works is that Bolt pushes commands and scripts to target machines, and then runs them using SSH for Linux/macOS or WinRM for Windows. It does all this without a persistent agent, so you get:
- Less overhead: No agents use up system resources.
- Quick setup: Start running tasks with a little setup.
- Low impact: No extra software to manage and update.
- Simple cleanup: No uninstall steps, as there’s nothing to remove.
This agentless approach can be useful when you have systems where installing an agent is a problem or when you only want to run a few tasks now and then.
Key Features
Puppet Bolt comes with a few key features that make it a strong choice for sysadmins and DevOps engineers. These features include:
- Task execution: Run one-off tasks or complex workflows on remote nodes.
- Plan orchestration: Build more complex workflows with multiple tasks, logic, and error handling.
- Inventory management: Manage groups of nodes with a simple inventory file.
- Plugin support: Extend Bolt with new modules and functions.
- Multi-OS support: Run tasks on Linux, macOS, and Windows systems.
- Simple CLI: Use a clear and easy command-line interface.
With these features, Bolt gives you a way to manage your infrastructure and deployments with both power and ease.
Why Choose Puppet Bolt?
Why pick Puppet Bolt when you have other automation tools to choose from? It comes down to the mix of speed, ease of use, and the agentless setup that Bolt provides. Let’s explore some of the reasons why Bolt could be the right tool for you.
Quick Deployment
One of Bolt’s biggest wins is how fast it can deploy changes. Because it is agentless, you don’t have to wait for agents to be installed and connect to a server. You can push out changes in seconds or minutes, not hours. This quick speed can be key for time-sensitive updates or rollbacks.
For example, say you need to fix a server bug in your app, you can use Bolt to push the patch fast. Bolt will save time and help keep your services stable.
Easy to Use
Bolt is built to be simple, with a clear command-line interface. You don’t need a lot of code to use it, and you can learn the basics very quickly. If you’re used to scripting, you can jump right in and use Bolt with ease. Here are some key parts of Bolt’s user experience:
- Clear CLI: The command-line tool is laid out well, and it makes it simple to call for tasks.
- Simple inventory: Manage your hosts with a clear file system.
- Task definition: Use simple YAML files for tasks.
- Easy plans: Build more complex automation by combining tasks.
Bolt’s focus on a good user experience means you can work faster with less stress, even if you are not a Puppet expert.
Flexibility
Bolt’s flexibility is another huge plus. You can run any command you want, from basic shell commands to complex scripts. You can also use Bolt with other tools, making it a great part of your automation setup.
Some examples of where you can use Bolt include:
- One-off commands: Run ad hoc tasks on your nodes.
- Script execution: Run custom scripts or programs.
- Puppet integration: Use Bolt to call Puppet code.
- Workflow automation: Link tasks into complex plans.
- Multi-OS: Manage both Windows and Linux systems.
This kind of flexibility makes Bolt a tool you can count on for many different jobs, no matter how complex.
Ideal Use Cases
Now that you know what makes Bolt unique, let’s look at some cases where it can really help:
- One-off tasks: Run basic commands on many servers.
- Software install: Deploy software or do updates fast.
- Config change: Push out config changes across your setup.
- Routine jobs: Automate regular tasks such as logs or backups.
- Troubleshooting: Run checks and tests fast to find and fix issues.
With its fast and simple approach, Bolt is the perfect tool for these use cases and beyond.
How to Install Puppet Bolt
Before you can start using Puppet Bolt, you need to install it on your machine. You can do so on your local workstation, or a server with access to all the target nodes you wish to manage. The process changes depending on your OS.
Linux and macOS
On Linux and macOS, you can install Bolt via the package manager or directly from the Puppet website. Here’s how to do it using the package manager.
-
Add the Puppet repository: You’ll need to add the Puppet repository to your system so you can find the Bolt package. Here is an example of how to do so using bash:
bash
wget https://apt.puppet.com/puppet7-release-$(lsb_release -cs).deb
sudo dpkg -i puppet7-release-$(lsb_release -cs).deb
2. Update the package cache: After you add the new repository, you need to update your system’s package cache so that it picks up Bolt’s availability.bash
sudo apt update
3. Install Puppet Bolt: Now, you’re ready to install Bolt:bash
sudo apt install puppet-bolt
For macOS, you can use brew:
-
Install Brew: If you don’t have Brew installed on your system, you must do so now:
bash
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
2. Install Puppet Bolt: Once brew is ready, run the install command for Bolt:bash
brew install puppet-bolt
After you run the install, you can verify it was successful by checking Bolt’s version:
bolt --version
Windows
For Windows, you install Bolt using the MSI installer. You can get the installer from the Puppet website or a package manager. Here’s what to do with the installer:
- Download the Installer: Go to the Puppet website and download the MSI installer for Puppet Bolt. Make sure you download the right version for your Windows OS.
- Run the Installer: Double-click on the MSI installer file you just downloaded to start the setup.
- Follow the Setup: Follow the instructions in the installer. Choose the install location and other options.
- Finish Setup: After setup is complete, Bolt is ready to use from the command line.
-
Check your install: Open the command prompt or PowerShell and run:
powershell
bolt --version
Verify Installation
After install, you should check that Bolt is working correctly. Run the version command as shown above for your OS. If Bolt is installed correctly, you will see the version number of your Bolt installation.
If you get an error instead of a version, check your install steps or the installation documentation for help.
Setting Up Your Bolt Environment
Before you can run Bolt tasks, you should set up your environment. This means setting up your inventory, tasks, and if you want to, plans.
Inventory File
The inventory file is where you list all the target nodes you want to manage with Bolt. This file contains details like the hostnames, user names, and connection options. By default, Bolt will look for an inventory file called inventory.yaml
. However, you can also use the --inventory
flag when you call a task to specify a different inventory file.
Here’s a basic example of what an inventory file may look like:
groups:
webservers:
nodes:
- host: webserver1.example.com
user: deploy
private-key: /path/to/deploy.pem
- host: webserver2.example.com
user: deploy
password: deploy-password # Use with caution
dbservers:
nodes:
- host: dbserver1.example.com
user: dbadmin
config:
transport: ssh
ssh:
port: 2222 # Define specific parameters to use with SSH
In the example, you’ll see:
- Groups: This section defines groups of nodes, like “webservers” and “dbservers”.
- Nodes: Under each group, there is a list of nodes with details such as hostname, user, and password.
- Config: Here, you can set specific connection options for nodes. This could be the SSH key file, port number or connection protocol.
Best Practices:
- Use groups: Organize your nodes into groups to make it easier to target many at once.
- Avoid passwords: Use SSH keys instead of passwords to make sure you have better security.
- Be clear and simple: Make the inventory simple so it is easy to read and use.
- Check in code control: If possible, add your inventory file to a code control system so you can track changes over time.
Task Files
Tasks are bits of code that Bolt executes on remote nodes. They can be simple shell scripts, Puppet code, or custom scripts in languages like Python or Ruby. Bolt tasks live in a folder structure where you place files for each task you want to run.
Here’s an example of a simple task that runs a shell command on a node, it’s in a file called tasks/check_disk_space.sh
. The file will also be executable:
#!/bin/bash
df -h
You can also use Bolt to run a simple puppet manifest: create a file in the tasks
folder called create_dir.pp
:
file { '/tmp/my_new_dir':
ensure => directory,
}
Task Best Practices:
- Follow standards: Name your tasks in a clear way, and organize them so they are easy to find.
- Keep it simple: Tasks should do one thing, and they should do it well.
- Avoid hard coding: Use parameters so you can run tasks on any node.
- Test them well: Make sure to test tasks locally before you run them on remote nodes.
Plan Files
Plans take tasks and string them together to create more complex workflows. A plan is a YAML file that includes tasks to run, logic, error handling, and other options.
Here’s an example plan that runs two tasks, it would be inside the file plans/deploy_app.yaml
:
parameters:
app_source:
type: String
description: "Location of the application source"
app_dest:
type: String
description: "Location of the app on the target nodes"
steps:
- name: transfer_app
_run:
task: file::upload
target: $nodes
parameters:
source: $app_source
destination: $app_dest
- name: restart_app
_run:
task: service::restart
target: $nodes
parameters:
name: my_app
This plan has two steps:
- transfer_app: Uploads the app files to the destination.
- restart_app: Restarts the service on target nodes.
Plan Best Practices:
- Use parameters: Create parameters so the plans are reusable.
- Be clear in naming: Name plans and steps so they are easy to understand.
- Error handling: Create error handling to make plans more stable.
- Break it down: If a plan gets too complex, break it down into smaller plans.
By using these best practices, you can build a Bolt environment that is clear, simple, and easy to use.
Running Ad Hoc Tasks with Bolt
With your environment all set up, you can now begin running Bolt tasks. Let’s explore how to run one-off tasks on your target nodes.
Basic Task Execution
To run a basic task, use the bolt task run
command followed by the name of the task and any parameters. For example, let’s run the check_disk_space.sh
shell task on all servers in the webservers
group:
bolt task run check_disk_space.sh --targets webservers
In this command:
bolt task run
tells Bolt to run a task.check_disk_space.sh
is the task you want to run.--targets webservers
tells Bolt which nodes to run the task on.
You’ll get the output of the command from each node.
Filtering Targets
You can filter target nodes based on many parameters. To run a task only on a few servers, you can specify them:
bolt task run check_disk_space.sh --targets webserver1.example.com,webserver2.example.com
You can also specify targets by filtering your inventory.yaml
using the --query
flag. Here is an example that targets all Linux nodes.
bolt task run check_disk_space.sh --query 'os.family == "linux"'
Using Parameters in Tasks
To run a task that requires input, use the --params
flag, here is an example using a simple echo task, created in tasks/echo.sh
folder:
#!/bin/bash
echo "The input was $1"
And run it using the command:
bolt task run echo.sh --targets webservers --params 'message=hello_world'
Bolt will use the message
parameter in the task, so you can get:
The input was hello_world
Running Puppet Code
You can run puppet code directly as a task by using the .pp
file extension in your command:
bolt task run create_dir.pp --targets webservers
Bolt will use Puppet to execute your manifest.
Getting Task Results
Bolt output includes the results of each task run on each target node. This output can be useful for debugging or to verify your runs went through successfully.
Bolt output includes:
- Node Info: The name of each node the task ran on.
- Task Output: The output from the task itself.
- Error Details: Any errors or issues you have encountered.
By using the different options that bolt task run
gives you, you can manage nodes and run tasks quickly and with great ease.
Orchestrating Workflows with Bolt Plans
While ad hoc tasks are useful, plans allow you to orchestrate a sequence of actions to create more complex workflows. Let’s look into how you use Bolt plans.
Defining Plans
Plans are defined using YAML, where you outline all the different tasks that you want to run, the order in which you run them, and the params they take.
Here is an example of a simple plan, as we defined in an earlier section (plans/deploy_app.yaml
):
parameters:
app_source:
type: String
description: "Location of the application source"
app_dest:
type: String
description: "Location of the app on the target nodes"
steps:
- name: transfer_app
_run:
task: file::upload
target: $nodes
parameters:
source: $app_source
destination: $app_dest
- name: restart_app
_run:
task: service::restart
target: $nodes
parameters:
name: my_app
The plan includes:
- Parameters: Input parameters like
app_source
andapp_dest
that allow you to customize the plan for many deployments. - Steps: Different steps in the plan to transfer an app and then restart the service, each step uses the
_run
tag which tells bolt to execute a task. - Variables: The
$nodes
variable specifies the target nodes, you can also use input parameters with a$
symbol.
Running Plans
To run a plan, use the command bolt plan run
. For example, let’s use the deploy_app.yaml
we just defined.
bolt plan run deploy_app.yaml --targets webservers --params app_source=/tmp/app.tar.gz,app_dest=/opt/my_app
Here:
bolt plan run
tells Bolt to run a plan.deploy_app.yaml
is the plan file to use.--targets webservers
is the target node group.--params
provides the values for parameters likeapp_source
andapp_dest
.
Bolt will run each step in the plan, and print output at each stage for you to follow.
Advanced Plan Features
Bolt plans have support for many features that allow you to build much more complex workflows. Some of the features include:
- Conditional Logic: You can use
if
conditions to control steps to take based on variables. - Looping: You can loop across a list of items using the
each
statement. - Error Handling: You can control what happens if a step fails using
catch
statements. - Task Control: You can control concurrency and timing of tasks to avoid overloading servers.
These features allow you to build robust workflows that can handle the complex world of modern IT.
Example: Updating an App with Plans
Let’s see a real example of how you can update an application with a plan. Here’s an example that uses some advanced features of bolt plans:
parameters:
app_source:
type: String
description: "Location of the application source"
app_dest:
type: String
description: "Location of the app on the target nodes"
backup_dir:
type: String
description: "Location of where to put backups"
steps:
- name: backup_app
_run:
task: file::archive
target: $nodes
parameters:
source: $app_dest
destination: "$backup_dir/app-$(date +%Y%m%d%H%M%S).tar.gz"
- name: transfer_app
_run:
task: file::upload
target: $nodes
parameters:
source: $app_source
destination: $app_dest
- name: restart_app
_run:
task: service::restart
target: $nodes
parameters:
name: my_app
catch:
- name: rollback_app
_run:
task: file::extract
target: $nodes
parameters:
source: "$backup_dir/app-$(date +%Y%m%d%H%M%S).tar.gz"
destination: $app_dest
catch:
- name: error_out
_run:
task: file::extract
target: localhost
parameters:
message: "Rollback failed, please check logs"
This plan will:
- Backup the App: Create a backup of the current app.
- Transfer the App: Push the new app files to the destination location.
- Restart the Service: Restart the app to put the new app live.
- Rollback: If the restart fails, restore the backup.
- Error: If the rollback fails, log the error.
This shows how you can use the advanced plan features of bolt to manage both app updates and potential issues with your deployments.
Extending Puppet Bolt
Puppet Bolt can be extended using plugins and modules. This allows you to add functionality and integrate Bolt into other parts of your DevOps toolchain.
Bolt Modules
Modules can be used to extend Bolt’s task and plan features. Modules are built using standard Puppet code, and they often come with a set of tasks, types, and functions. You can add modules from Puppet Forge or create your own.
For example, if you use Docker a lot, you could get the puppetlabs/docker
module:
bolt module install puppetlabs/docker
After you have installed the module, you can use the tasks and types that come with it.
bolt task run docker::container --targets dbservers --params 'action=start, name=mydb'
This will start a container called mydb
on the servers in the dbservers
group.
Creating Custom Modules
To create your own Bolt module, follow these steps:
- Create a module folder: Create a folder called
modules/<your_module_name>
. - Create a tasks directory: Inside this folder create a sub-folder named
tasks
and place your tasks here. - Add a metadata file: Add a file named
metadata.json
that has details about the module.
Here’s an example metadata.json
file:
{
"name": "my_custom_module",
"version": "1.0.0",
"author": "Your Name",
"description": "My custom Bolt module."
}
Now you can place your tasks in the tasks directory and use them just like you use default tasks or tasks from Puppet Forge.
Integration with Other Tools
Bolt can also be used to integrate with other tools in your setup. You can use it with tools such as:
- CI/CD Systems: Integrate Bolt calls to make infrastructure changes and deploy updates automatically.
- Monitoring Tools: Use Bolt to manage changes to your servers and track the effect.
- Ticketing Systems: Use Bolt to update tickets based on events or deployments.
By integrating with other parts of your toolchain, you can make your automation workflows smoother and more powerful.
Best Practices for Puppet Bolt
Let’s take a look at some best practices to follow when using Bolt to ensure reliability, and maintainability.
Security Considerations
When you’re working with Bolt, security should be a priority. You should always keep these points in mind:
- Secure Auth: Always use SSH keys instead of passwords when you connect to servers.
- Access Control: Use groups and query filters to limit the tasks that a certain user can run on a certain set of servers.
- Secrets: Never store any passwords or secrets directly in your plans or tasks, instead, use Bolt’s secret management feature.
- Audit Log: Always keep an eye on who is running Bolt commands and what changes they make, so you have a log that can be audited.
Code Management
When managing your tasks, plans and module files, you must always follow code management best practices.
- Version control: Manage all Bolt code and configurations in a version control system like Git.
- Clear Naming: Make sure to name your plans and tasks so they are simple to read and simple to find.
- Keep it Simple: Always try to keep your plans and tasks as simple as possible, break them down into small and simple steps that do one thing well.
- Test: Make sure you run all plans and tasks in a test environment before pushing them out into production.
- Document: Make sure to add documentation to all your modules, tasks and plans to make it simpler to work with them and maintain them.
Performance Optimization
To get the best performance out of Bolt, try to keep these tips in mind:
- Concurrent Tasks: If possible run tasks in parallel, to save time.
- Task Design: Make your tasks lean and performant so that they don’t use more resources than needed.
- Network: When running tasks, choose network routes that are fast and stable.
- Avoid Loops: Be careful when creating long loops in plans, because they will use more resources on your servers.
By keeping in mind best practices you can build your workflows in a secure and maintainable way.
Puppet Bolt vs. Other Tools
While Bolt is a good tool, it may not be the right fit for everyone. Here is how Bolt compares to some other common automation tools.
Puppet Enterprise
Puppet Enterprise is the paid, feature rich version of Puppet. Unlike Bolt, Puppet Enterprise uses agents installed on target nodes. Puppet Enterprise is better than Bolt for long term configuration management and policy enforcement. Bolt is a better choice for ad hoc tasks and quick changes.
Ansible
Ansible is another popular open source tool that is often compared to Bolt. It can be used for both config and orchestration, and has a large community and a wealth of modules. Bolt is better than Ansible for users already inside the Puppet ecosystem because it uses the same technology as Puppet for most tasks and modules. Bolt’s agentless setup is also useful in situations where Ansible’s agent based model is not ideal.
Salt
Salt is another agent-based open-source tool, that is often compared to both Ansible and Bolt. Salt is a good choice for those that need very high performance and have complex infrastructures to manage. Salt can be used for orchestration and config, and has a large community. Bolt is a better choice than Salt for those who need a simpler approach that is agentless.
Chef
Chef, like Puppet Enterprise is a tool that is focused on configuration management. It also uses agents installed on target nodes. Chef is very strong for systems that need a very fine level of control of config and state. Bolt is better than Chef for users that want a quick and simple method for task execution without an agent.
Bolt’s strength lies in its speed, and its simplicity. If you need a tool that works with Puppet, that is quick, easy to set up, and can execute tasks fast and agentless, Bolt is a great choice. If you have more complex needs, one of the other tools may be a better fit for you.
Getting Started with Puppet Bolt
We have explored many of the features of Puppet Bolt, you have learned what Bolt is, why you should use it, and how to run tasks and plans to manage your IT infrastructure.
If you haven’t already, try Puppet Bolt and make your deployments faster and your infrastructure easier to manage. Its agentless architecture means you can run tasks and orchestrate your workflows without all of the complexity of other tools.
So, take a moment now and begin your Puppet Bolt journey, and experience the rapid deployment.