There are some simple ways to configure Bolt so you can use it more efficiently. This lesson shows you how to set default values for a few commonly used Bolt options, so you don’t have to type those values every time you issue a Bolt command.
This section is easiest to follow if you’ve already completed the Setting up Target Nodes section of this course, but you can adapt these instructions for your environment if you skipped that section and are using your own target nodes.
The instructions are identical regardless of whether your host node is running Linux, macOS, or Windows. Just use the appropriate text editor for your particular OS—otherwise all the steps are the same.
Note: If entering these commands on a Windows host node, be sure to use PowerShell and not the older Command shell.
1). On your host node, create a directory to store your Bolt configuration files in. This is called a Boltdir.
Note: You don’t strictly need a Boltdir to store your configuration files in, but it is considered a best practice to do so.
To create a Boltdir, create a directory called
Boltdir in the same directory as
Vagrantfile. Assuming you put
Vagrantfile in your home directory, use this command:
2). Now that you have a Boltdir, you will create two different configuration files in it:
inventory.yaml. Each of these files contains a different type of configuration setting, as described below.
When Bolt manages target nodes, it must communicate from the host node (where the Bolt application is running) to those target nodes. If the target node is Linux or macOS, Bolt usually uses the SSH communication protocol. If the target node is Windows, it usually uses the WinRM communication protocol. The
bolt.yaml file stores configuration settings for both of these protocols.
Note: You don’t have to use these configuration settings, but if you don’t, you’ll need to type them every time you issue a Bolt command.
Set two configuration settings: one for SSH and one for WinRM. Using a text editor, create a file called
bolt.yaml in your Boltdir, and copy/paste this content into the file:
Winrm: ssl: false Ssh: host-key-check: false
The first two lines tell Bolt not to use SSL security when communicating with target nodes with WinRM. The second two lines tell Bolt that when it communicates with SSH it should not to ask for permission to connect to target nodes it has never seen before.
You might be confused about why you’re setting configuration details for both Windows (in the WinRM section) and Linux/macOS (in the SSH section), considering that your host node is only running one of these operating systems. The answer is that these settings concern the operating system running on the target nodes that Bolt is managing, and not on the host node that the Bolt tool is running on. In other words, regardless of what machine Bolt is running on, whenever you use it to manage a Windows machine, Bolt uses the WinRM configuration information. Whenever you use it to manage a Linux or macOS machine, Bolt uses the the SSH configuration information. If you manage both types of computers with a single Bolt command, Bolt will use both types of configuration information.
There are many more configuration settings you could declare default values for in
bolt.yaml, but setting just these two values gives you an idea of how to use the configuration file. It also saves you a lot of typing in the rest of this course, since every Bolt command you type will make use of one or both of these settings.
inventory.yaml file lets you group several remote nodes under a single label, so you can manage a group of computers just by referring to their group name.
For example, you might define a group called all_linux that contains the three Linux target nodes you set up in the last section of this course. Then you could issue a single Bolt command to add a new user to all of the computers in the all_linux group. Or you might have a mix of Linux and macOS machines—all serving as database servers—that you include in a group called postgres. Then you could run one Bolt command against the postgres group to get the status of the postgresql service on all the computers in that group.
Just like with
bolt.yaml, this file is optional. You could instead refer to the IP addresses of all three computers in the all_linux group each time you run a Bolt command against all of those computers. But it’s more efficient to add them to a group in
inventory.yaml and point the Bolt command at that group instead of at three individual computers. That’s why using an
inventory.yaml file is not only a best practice, but should be considered mandatory for any non-trivial use of Bolt.
3). Create a file called
inventory.yaml in your Boltdir, and copy/paste this content to the file:
groups: - name: all_linux nodes: - node1 - node2 - node3 - name: all_windows nodes: - winrm://localhost:55985
This file refers to the Linux target nodes by their hostnames, because in the previous section Vagrant helpfully configured SSH to know about those hostnames, but Vagrant can’t do that for Windows nodes so the file refers to the Windows virtual machine slightly differently.
Note: If you’re not using the target nodes created in the Setting up Target Nodes section, you’ll need to replace
node1 and the other target node names with the host names or IP addresses of your own target nodes.
In addition to defining groups of computers,
inventory.yaml also lets you set default values for the username and password that Bolt needs to authenticate to remote nodes. You can set different values for both SSH and WinRM protocols, though in this case the credentials are the same for each.
inventory.yaml to include username and password information for SSH and WinRM, so the file’s complete content looks like this:
groups: - name: all_linux nodes: - node1 - node2 - node3 config: transport: ssh ssh: user: vagrant password: vagrant - name: all_windows nodes: - winrm://localhost:55985 config: transport: winrm winrm: user: vagrant password: vagrant
Note: In this course, Vagrant has already set up a public/private key pair for each target node, which Bolt will use when communicating with the target nodes. That means that Bolt won’t actually use the username and password information you just added to
inventory.yaml. But it’s important to know how to do this anyway, since it’s a common and useful way to configure Bolt.
Now you can refer to groups of target nodes instead of individual machines, and you never have to include target node username or password information in your Bolt commands! These simple configuration settings make Bolt a lot simpler to use.