Glossary

Definitions of terms used in Bolt documentation.

agent

The Puppet agent software package, also known as puppet-agent.

apply

Use the apply Bolt plan function to apply a block of Puppet code (also known as a manifest block) to a target.

Before you can apply a manifest to a target, prepare the target using the apply_prep plan function. See apply_prep.

๐Ÿ“– Related information

apply_prep

A Bolt plan function that installs the puppet-agent package on targets if needed and collects facts, including any custom facts found in Bolt's module path. The puppet-agent package and facts are required for an apply.

๐Ÿ“– Related information

catalog

A catalog is a file that describes the desired state of each managed resource on a target. It is a compilation of all the resources that the Puppet agent applies to a given target, as well as the relationships between those resources.

Bolt compiles catalogs from manifests and agent-provided data during an apply. Bolt then serves the compiled catalog to the agent on a target.

Unlike the manifests from which they are compiled, catalogs don't contain any conditional logic or functions. They are unambiguous, relevant to only a specific target, and generated by a target.

๐Ÿ“– Related information

controller

A controller is any device that you use to run Bolt. See Installing Bolt for a list of supported platforms.

fact

A fact is a piece of information about a target, such as its hostname, IP address, or operating system. Facts are typically gathered by Puppet's Facter tool.

Facter

Facter is a system inventory tool. Facter reads facts about a target, such as its hostname, IP address, and operating system, and makes them available to Bolt.

Facter includes many built-in facts, and you can view the names and values for a particular node by running bolt task run facts -t mytarget.

future

A Future is a custom Puppet data type in Bolt.

A Future object is returned by the background() plan function and can be passed to the wait() plan function to block on the result of the backgrounded code block.

๐Ÿ“– Related information

group

A group is a set of targets and other groups in the inventory and their associated configuration. Groups provide a way for you to refer to targets that share a common trait by a simple, human-readable name.

๐Ÿ“– Related information

inventory

The inventory describes the targets that you run Bolt commands on, along with any data and configuration for the targets. Targets in an inventory can belong to one or more groups, allowing you to share data and configuration across multiple targets and to specify multiple targets for your Bolt commands without the need to list each target individually.

In most cases, Bolt loads the inventory from an inventory file in your Bolt project. The inventory file is a YAML file named inventory.yaml. Because Bolt loads the inventory file from a Bolt project, you must have an existing project configuration file named bolt-project.yaml alongside the inventory file.

๐Ÿ“– Related information

log

Bolt supports multiple log levels. You can configure the log level from the CLI, or in a project configuration file. Supported logging levels, in order from most to least information logged, are trace, debug, info, warn, error, and fatal.

๐Ÿ“– Related information

manifest

A directory for storing your Puppet code files, known as manifests.

module

Modules are shareable, reusable packages of Puppet content. They can include tasks, plans, functions, and other types of content that you can use in your project. You can download and install modules to your project from the Puppet Forge or write your own modules. Bolt also ships with several helpful modules pre-installed that are available to all of your projects.

Bolt makes it easy to manage the modules that your project depends on. You can use Bolt commands to install a project's modules, add new modules to a project, and view the modules that are available to the project.

๐Ÿ“– Related information

modulepath

The modulepath is an ordered list of directories that Bolt loads modules from. When Bolt runs a command, it automatically loads modules from the modulepath.

While Bolt has a default modulepath, you can also configure your own modulepath, which can include directories within the project or directories elsewhere on your system. Regardless of whether your project uses a default or configured modulepath, Bolt automatically adds directories to the modulepath. This includes modules containing core Bolt content, which is added to the beginning of the modulepath, and bundled content, which is added to the end of the modulepath.

Modules loaded from a directory listed earlier in the modulepath take precedence over modules with the same name loaded from a directory later in the modulepath. If Bolt finds two modules with the same name in your modulepath, it ignores the module with the lower precedence and does not print a warning or error message.

plan

A set of actions that can be combined with other logic.

Plans allow you to do complex operations, such as running multiple actions with one command, computing values for the input for an action, or running certain actions based on the results of another action.

You can write a plan in YAML or in the Puppet language, and they can be packaged as part of a module or project.

๐Ÿ“– Related information

plugin

Bolt supports the use of plugins to dynamically load information during a Bolt run and change how Bolt executes certain actions. Bolt ships with some plugins, but you can also create your own plugins or install plugins created by other users.

There are three types of plugins that you can use with Bolt:

  • Reference plugins: Use to fetch data from an external source and store it in a static data object.

  • Secret plugins: Use to create keys for encryption and decryption, to encrypt plaintext, or to decrypt ciphertext.

  • Puppet library plugins: Use to install Puppet libraries on a target when a plan calls the apply_prep function.

๐Ÿ“– Related information

project

A Bolt project is a directory that serves as the launching point for Bolt and allows you to create a shareable orchestration application. Projects typically include a project configuration file, an inventory file, and any content you use in your project workflow, such as tasks and plans.

When you run Bolt, it runs in the context of a project. If the directory you run Bolt from is not a project, Bolt attempts to find a project by traversing the parent directories. If Bolt is unable to find a project, it runs from the default project, located at ~/.puppetlabs/bolt.

A directory is only considered a Bolt project when it has a project configuration file named bolt-project.yaml. Bolt doesn't load project data and content, including inventory files, unless the data and content are part of a project.

๐Ÿ“– Related information

puppetfile

A puppetfile specifies the modules installed in your project. Bolt manages this file. Avoid editing it.

๐Ÿ“– Related information

target

A target is a device that Bolt connects to and runs actions on. Targets can be physical, such as servers, or virtual, such as containers or virtual machines.

๐Ÿ“– Related information

task

A task is a single action that you run on targets. You use tasks to make as-needed changes to remote systems.

Tasks are similar to scripts and can be written in any programming language that can run on the targets, such as Bash, PowerShell, and Python. Tasks are packaged within modules or projects, so you can reuse, download and share tasks. Tasks also have metadata that describes the task, validates input, and controls how the task runner executes the task.

๐Ÿ“– Related information

transport

A transport defines the connection method that Bolt uses to connect to a target. SSH, WinRM, and local are some of the most commonly used transports.

There is a Docker transport that simplifies connecting to Docker containers, but the SSH transport is useful for gaining a broader understanding of how Bolt inventory files work.

๐Ÿ“– Related information

type

The different custom types that can be used in a Bolt plan.

๐Ÿ“– Related information

type alias

Type aliases provide an alternate name for existing types or lists of types. These types can be used within a plan, and have all of the attributes and functions of whichever Puppet type they are set to in the plan.

๐Ÿ“– Related information