Why Infrastructure Automation Needs PowerShell + Bolt

PowerShell and Bolt — together they are a powerful team.

Why?

Bolt is an agentless multiplatform open source tool that allows you to automate tasks on an as-needed basis or as part of a greater orchestration workflow. You can use Bolt to patch and update systems, troubleshoot servers, deploy applications, provision cloud resources or stop and restart services. PowerShell is a task-based command command-line shell and scripting language that helps automate tasks that manage operating systems.

In this article, we will look at the benefits of using PowerShell and Bolt together, and then walk through restarting a service with a PowerShell script and Bolt.

The Power of Using PowerShell and Bolt Together

Claire Cadman

Claire is part of the technical publications team at Puppet, which creates and maintains the Puppet product documentation. She is currently responsible for Windows related content. After a few years of studying and working abroad, Claire is now back where she grew up in London, and based out the Puppet office there. In her free time, she enjoys trying the many restaurants in London, hiking and travelling.

In a typical Windows domain environment, much of what you can do with Bolt, you can do with PowerShell. However, if you need to perform tasks in a mixed Windows and Linux environment, or if you need to orchestrate a complex workflow, Bolt has key advantages over regular scripting. This is because with Bolt, you can mix tasks in PowerShell on Windows with tasks in other languages on Linux while keeping them all part of the same workflow — one that is version controlled and easily distributable.

In this way, Bolt allows you to easily share small reusable tasks written in PowerShell with your team members, saving duplicated effort and reducing duplicated code.

Bolt Plans, which are beyond the scope of this article, allow you to add Puppet module code via Apply manifest blocks. You can mix imperative ad-hoc tasks with declarative state configuration using Puppet supported modules or PowerShell DSC via the dsc_lite module.

Running a PowerShell Script That Restarts a Service

To see Bolt in action, let’s walk through an example that involves running a script with Bolt, converting the script to a Bolt Task, and then executing the Task. The example script we’ll use, called restart_service.ps1, performs a common task of restarting a service on demand. The process involves these steps:

1. Run a PowerShell script on a remote Windows node.
2. Create an inventory file to store information about the node.
3. Convert the script to a task.
4. Execute the new task.

Before we begin, make sure that you’ve taken care of the following requirements first.

• Install Bolt on your Windows machine.
• Identify a remote Windows node to work with.
• Ensure you have Windows credentials for the remote node.
• Configure Windows Remote Management on the remote node.

Running Your First PowerShell Script on a Remote Node

Let us start by using Bolt to run a script on a single target node.

Create a Bolt project directory to work in, called bolt-guide. Visit this link and download the script called restart_service.ps1 into the bolt-guide directory.

Puppet by Perforce gives IT operations teams back their time and offers peace of mind with infrastructure automation that enables security and compliance. More than 40,000 organizations rely on Puppet products to empower people to innovate through IT automation.

Learn More

The latest from Puppet

Now, in that directory, run this script with the following command. Replace “NODENAME” with the hostname of the remote Windows node:

bolt script run .\restart_service.ps1 service=W32Time –nodes winrm://NODENAME -u Administrator -p

You will be prompted to enter a password.

You’ve now put this script under Bolt control and have executed it on a remote node. This process copies the script into a temporary directory on the remote node, runs it, and then cleans up by deleting the script and temporary directory.

Using Bolt Inventory Files

With an inventory file, you’re able to run Bolt commands and execute PowerShell scripts on multiple nodes at the same time. An inventory file uses YAML to contain a list of target nodes and specific data about each node.

Let’s create your first Bolt inventory file. Follow these steps:

1. Inside the bolt-guide directory, use your favorite text editor to create a file named yaml.
2. Edit the file to add the following content. List the fully qualified domain names of each remote Windows node you want to target. Be sure to replace the credentials in the winrm section:

To have Bolt securely prompt for a password, run it with the –password or -p flag without supplying any value. You now have an inventory file where you can store information about your nodes.

See Bolt configuration options for more information about what you can do to get Bolt working in your environment. For more information about configuring Bolt to use WinRM, see WinRM transport configuration options in the Bolt documentation.

Converting Scripts to Bolt Tasks

A task in Bolt is similar to a script, but it’s packaged in a Puppet module. This means it can include metadata which provides more context and control over how your script is run. You can also easily reuse and share a task with other Bolt users. Let’s convert the restart_service.ps1 script to a task.

To create a task, you need to make a task metadata file. Task metadata files describe task parameters, validate input, and control how the task runner executes the task.

These instructions show how to convert the script to a task by manually creating the .ps1 file in a directory called tasks. You can also use the Puppet Development Kit (PDK) to create a new task at the command line. If you’re going to be creating a lot of tasks, PDK will save you a lot of effort. Check out the documentation to learn more.

Here are the steps to create a task manually.

1. In the bolt-guide directory, create the following subdirectories:

2. Move the ps1 script into the tasks directory.
3. In the tasks directory, use your text editor to create a task metadata file — named after the script, but with a .json extension, in this example, json.
4. Add the following content to the new task metadata file:

Save the task metadata file and navigate back to the bolt-guide

You now have two files in the gsg module’s tasks directory: restart_service.ps1 and restart_service.json. You have just converted your script into a Bolt task. You no longer need to specify the file extension when you call it from a Bolt command.

To validate that Bolt recognizes the script as a task, run the following command:

bolt task show gsg::restart_service

Running a Bolt Task

To run your new task, use the following command:

bolt task run gsg::restart_service service=W32Time –nodes windows

Take note of the –nodes windows argument. This refers to a group of target nodes specified in your inventory file. For information on how to customize this, check out the section on nodes in an inventory file in the Bolt documentation.

You have now successfully automated a workflow for restarting a service on-demand on multiple target nodes using Bolt and PowerShell.

For more information about the commands you used in this guide, see the Bolt command reference.

Going Further: Bolt Plans

Once you’re comfortable with Bolt tasks, the next step is to combine them into a Bolt plan. Plans give you the ability to create complex multiserver workflows that combine multiple tasks — including those written in native Puppet code. Check out the Bolt documentation guide on plans to get started.

You might be just starting your automation journey. If you have a large organization spanning multiple teams, you will benefit from Puppet Enterprise, an automation platform that gives you a huge amount of control over infrastructure automation.

And as we described above, getting started with PowerShell makes a lot of sense.

Claire is part of the technical publications team at Puppet, which creates and maintains the Puppet product documentation. She is currently responsible for Windows related content. After a few years of studying and working abroad, Claire is now back where...

Read more from Claire Cadman