This document provides an overview of a Bolt workshop that will be held virtually on April 1, 2020. It introduces two presenters, Stephen P Potter and Josef Singer, and provides information about their backgrounds and areas of focus. The document also provides instructions for submitting questions during the webinar and notes that presentation materials will be shared after the event.

1. Bolt Workshop
Virtual
APRIL 1 2020

2. Meet our Presenters
BOLT WORKSHOP2
Stephen P Potter
Senior Sales Engineer, Columbus, OH
• 25+ years Unix/Linux, Virtualization, Cloud
• Focus on Automation and Performance Management
• Father, Scouts BSA Leader, Martial Arts Instructor
Josef Singer
Senior Sales Engineer, New York City
• 20+ years Software Development, Automation, IT
• Enjoys taking things apart, good at reassembly too
• Father, woodworker, video editor, music level 0 (-1?)

3. Questions?
• Please feel free to submit questions throughout the webinar using the Chat
function, which you can find in the control bar on the right hand side of
your screen. We have a few people on hand to provide assistance if you
run into any issues.
• We will be sending out a link to the recording and slides within the next
couple of days, so keep an eye on your inbox.”
BOLT WORKSHOP3

4. BOLT WORKSHOP4

5. All About Bolt
• Bolt provides a simple way to execute agentless automation against remote hosts
• Zero requirements to the remote host. No agents, no python, no nothing
• Authenticate via SSH, WinRM, PCP
• Execute arbitrary commands, scripts, Bolt Tasks and Bolt Plans
• Use scripts in any language the remote host can execute
• Mature at your own pace from scripts → tasks → plans → puppet code
• If you have Puppet Enterprise, leverage Bolt from PE
BOLT WORKSHOP5

7. Environment Setup
• Create a Bolt playground directory (i.e. ~/boltworkshop or c:usersyouboltworkshop)
• Download the Linux cert:
• Visit http://bit.ly/ws0325student
• Store the contents in your Bolt playground directory as student.pem.
• i.e. ~/boltworkshop/Boltdir/student.pem
• c:usersyouboltworkshopBoltdir/student.pem
BOLT WORKSHOP7

8. Using Bolt
Example syntax (you don’t need to run these)
• Bolt command line syntax:
bolt [command|script|task|plan] run <name> --targets <targets> [options]
• To run a simple Bash command on a remote SSH host:
bolt command run 'echo Hello World!' --targets 10.0.0.1,10.0.0.2
--user root --private-key /path/to/key --transport ssh --no-host-key-check
• To run a simple PowerShell command on a remote WinRM host:
bolt command run 'write-host Hello World!' --targets 10.0.0.1,10.0.0.2
--user Administrator --password ‘Puppetlabs!' --transport winrm --no-ssl
BOLT WORKSHOP8

9. BOLT WORKSHOP9
Lab 1:
Bolt Command

10. Lab 1: Instructions (A Long Command For A Ping!)
• Student Bolt Instances
Linux: bolt41nix#.classroom.puppet.com
Windows: bolt41win#.classroom.puppet.com
• Credentials
Linux: centos / student.pem
Windows: Administrator / Puppetlabs!
• Run these from the command line in your boltworkshop directory
bolt command run 'ping 8.8.8.8 -c2' --targets <linux_node>
--user centos --private-key ./Boltdir/student.pem --no-host-key-
check
bolt command run 'ping 8.8.8.8 –n 2' --targets <win_node> --user
Administrator --password Puppetlabs! --transport winrm --no-ssl
BOLT WORKSHOP10

11. Easing Bolt Configuration
http://www.puppet.com/docs/bolt
• Bolt provides ways to make repetitive tasks more efficient
• Use a bolt.yaml file to store generic settings like modulepath or PE integration
• Use an inventory.yaml file to prevent typing in connection info every time
• Use a Boltdir to bundle all the files you need and have Bolt automatically use it
BOLT WORKSHOP11

12. Bolt Configuration File
• Bolt supports a configuration file to manage default configuration settings
• The configuration file is YAML and can have any name you want
• If unspecified, Bolt will look in these locations for an configuration file
• ./Boltdir/bolt.yaml
• ~/.puppetlabs/bolt/bolt.yaml (~ = %HOMEPATH%)
• A custom configuration file can be specified at runtime with --configfile [full path]
BOLT WORKSHOP12

13. BOLT WORKSHOP13
Lab 2:
Use Bolt with
bolt.yaml

14. Lab 2: Instructions (Making some Defaults)
1. Create Boltdir/bolt.yaml in your bolt playground folder (e.g. boltworkshop).
2. add host-key-check: false to SSH section of bolt.yaml and ssl: false to WinRM
section of bolt.yaml
ssh:
host-key-check: false
winrm:
ssl: false
3. Run commands to targets without specifying these 2 options (from boltworkshop dir)
bolt command run 'ping 8.8.8.8 -c2' --targets <linux_node>
--user centos --private-key ./Boltdir/student.pem
bolt command run 'ping 8.8.8.8 –n 2' --targets <win_node> --user Administrator
--password Puppetlabs! --transport winrm
BOLT WORKSHOP14

15. Bolt Inventory
• Bolt supports an inventory file to maintain a list of known targets
• The inventory file is YAML and can have any name you want
• If unspecified, Bolt will look in these locations for an inventory file:
• ./Boltdir/inventory.yaml
• ~/.puppetlabs/bolt/inventory.yaml (~ = %HOMEPATH%)
• A custom inventory file can be specified on the command line with --inventoryfile
[full path]
• A custom inventory file can be specified in bolt.yaml with the inventoryfile keyword.
BOLT WORKSHOP15

16. Bolt Inventory
groups:
- name: group_name
targets:
- IP_address_or_name_of_node1
- IP_address_or_name_of_node2
config:
transport: [ ssh | winrm ]
ssh:
user: user_name
run-as: root_name
private-key: /path/to/key
host-key-check: [ true | false ]
winrm:
user: user_name
password: password
ssl: [ true | false ]
BOLT WORKSHOP16
Nesting of groups is allowed:
groups:
- name: top_group
groups:
- name: sub_group
targets:
- …

17. BOLT WORKSHOP17
Lab 3:
Build an Inventory
File

18. Lab 3: Reference
1. Create an inventory.yaml in your workshop folder
2. One group for your Linux node, connecting over SSH
3. One group for your Windows node, connecting over WinRM
Reference (download this and place in boltworkshop/Boltdir):
https://bit.ly/ws0325inventory
Note:
● You’ll need to use your student number in the provided file.
BOLT WORKSHOP18

19. BOLT WORKSHOP19
Lab 4:
Use Bolt with
Inventory

20. Lab 4: Reference (Using our Inventory)
Note: Run these commands from your boltworkshop/Boltdir directory…
1. bolt command run 'ping 8.8.8.8 -c2' --targets linux
1. bolt command run 'ping 8.8.8.8 -n 2' -t windows
1. bolt command run 'hostname’ --targets linux,windows
BOLT WORKSHOP20

21. The Boltdir
To assist in packaging Bolt with source code, Bolt supports a Boltdir
When Bolt sees a directory called ./Boltdir it overrides all other configuration
The Boltdir has the following structure:
./Boltdir/bolt.yaml # Configuration settings
./Boltdir/inventory.yaml # Target system inventory
./Boltdir/Puppetfile # Additional Forge modules
./Boltdir/modules # Path where modules are installed via Puppetfile
./Boltdir/site # Another modulepath, safe from Puppetfile
./Boltdir/modules/mymod/tasks # Bolt Tasks in module ‘mymod’
./Boltdir/modules/mymod/plans # Bolt Task Plans in module ‘mymod’
BOLT WORKSHOP21

22. Running Scripts
• Bolt will copy the script file to the remote host and run it in the native shell
• Linux = Bash
• Windows = PowerShell
• Bolt expects the shell to execute the correct parser (based on file extension)
• You can pass arguments, but Bolt doesn’t do input validation for scripts
bolt script run <script> [[arg1] ... [argN]] [options]
BOLT WORKSHOP22

23. BOLT WORKSHOP23
Lab 5:
Run Scripts with
Bolt

24. Lab 5: Instructions (Running a Script)
1. On your laptop, recreate the timesync.ps1 script at https://bit.ly/ws0325time_sync Place
this file above your Boltdir, in our ~/boltworkshop directory
2. From our boltworkshop directory: Use Bolt to run the script on your Windows node
bolt script run time_sync.ps1 --targets windows
BOLT WORKSHOP24

25. Scripts into Tasks!
• Make your scripts more useful in Bolt by turning them into Puppet Tasks
• Any script file in a tasks directory of a module becomes a Task
• Tasks are “name spaced” automatically, using familiar Puppet syntax:
site/mymod/tasks/script1.ps1 # mymod::script1
site/aws/tasks/show_vpc.sh # aws::show_vpc
site/mysql/tasks/sql.rb # mysql::sql
site/yum/tasks/init.rb # yum (notice that?)
BOLT WORKSHOP25

26. BOLT WORKSHOP26
Lab 6:
Convert a Script
to a Task

27. Lab 6: Instructions (Turning Scripts into Tasks)
1. Create Boltdir/site/tools/tasks
2. Move the time_sync.ps1 script into the tasks directory
3. bolt task show to verify the new task is available
4. bolt task run tools::time_sync --targets windows to execute the task.
BOLT WORKSHOP27

28. Bolt Task Metadata
• Make your Tasks more useful and robust by writing metadata files for them
• A metadata file has the same name as the script file, but with a .json extension
• Metadata files using the following (JSON) syntax:
{
"description": "Description of your Puppet Task",
"input_method": "environment | stdin | powershell",
"parameters": {
"param1": {
"description": "Description of the parameter usage",
"type": "String | Enum | Pattern | Integer | Array | Hash | Boolean“
}
}
}
BOLT WORKSHOP28

29. Bolt Task Input Methods
• The chosen input method determines how variables are accessible in the script
“input_method”: “environment | stdin | powershell”
• environment: creates environment variable for each parameter as $PT_<variable>
• stdin: creates a JSON hash of all parameters and passes it via stdin
• powershell: creates a PowerShell named argument for each parameter
• The default for Linux is environment and stdin
• The default for Windows is powershell
BOLT WORKSHOP29

30. BOLT WORKSHOP30
Lab 7:
Create and Run
Bolt Task with
Metadata

31. Lab 7: Instructions (Parameterizing Tasks)
1. Retrieve timesync.json from https://bit.ly/ws0325time_syncjson
2. Retrieve timesync.ps1 from https://bit.ly/ws0325timesyncparm
• Adds a “Restart” Parameter
• Adds an if statement restarting W32Time if Restart parameter is passed in
3. Copy timesync.json and timesync.ps1 to ./Boltdir/site/tools/tasks
4. bolt task show (Look, we have a description now!)
5. bolt task show tools::timesync
6. bolt task run tools::timesync -t windows restart=true
BOLT WORKSHOP31

32. Writing Bolt Plans
Bolt Plans can use all the previously covered capabilities, and more, in a single plan.
It’s ideally suited to:
• Orchestrate multiple tasks
• Perform more complex logic & error handling, or interact with Puppet Enterprise
• Combine command/scripts/Tasks with applying desired-state Puppet code
• Plans are stored in a plans directory of a module and have a .pp extension
• Plans must be name spaced according to their module & plan name
BOLT WORKSHOP32

33. BOLT WORKSHOP33
Lab 8:
Create and Run a
Bolt Plan

34. Lab 8: Instructions (Building a Plan)
1. Retrieve https://bit.ly/ws0325timesyncplan
1. Place timesync.pp in Boltdir/site/tools/plans (New Directory)
2. bolt plan show
3. bolt plan show tools::timesync
4. bolt plan run tools::timesync --targets windows
BOLT WORKSHOP34

35. BOLT WORKSHOP35
What is the Forge?

36. Desired State - What Now?
• So far, we’ve been using scripting approaches to fix time synchronization issues
• But the script only works on Windows
• If we also built a script for Linux, it wouldn’t look anything like the Windows one
• We don’t *want* to keep running scripts on systems over and over
• How would we know if we needed to run the script again? Would that even work?
• Surely *someone* has solved this issue already, right?!
BOLT WORKSHOP36

39. BOLT WORKSHOP40
Lab 9:
Apply a Puppet
Manifest

40. Lab 9: Instructions (Applying Puppet Code)
• Retrieve Plan manifest from https://bit.ly/ws0325timesyncmanifest and save it as
timesync_windows.pp in your working directory (above Boltdir)
• bolt apply timesync_windows.pp --targets windows
NOTE: This lab will fail to complete and spew yellow and red: Could not
find declared class windowstime is the proper error!
BOLT WORKSHOP41

42. BOLT WORKSHOP43
Lab 10:
Apply a Puppet
Manifest with a
Puppetfile

43. Lab 10: Instructions (Dependencies, the Puppetfile and You!)
1. Download Puppetfile from https://bit.ly/ws0325Puppetfile
1. It should contain these dependencies: Stdlib, Registry, Windowstime and NTP
# Modules from the Puppet Forge.
mod 'puppetlabs-stdlib', '5.1.0'
mod 'puppetlabs-registry', '2.1.0'
mod 'ncorrare-windowstime', '0.4.3'
mod 'puppetlabs-ntp', '7.3.0'
1. bolt puppetfile install
2. With the modules now installed, let’s try this again:
bolt apply timesync_windows.pp --targets windows
BOLT WORKSHOP44

45. BOLT WORKSHOP46
Lab 11:
Cross Platform
Plans

46. Lab 11: Instructions (Let’s get Multi-Platform!)
1. Retrieve https://bit.ly/ws0325timesyncmulti and place it in
boltworkshop/Boltdir/site/tools/plans/timesync_code.pp
2. Change directory to ./Boltdir (path to .pem file)
3. bolt plan run tools::timesync_code --targets windows,linux
BOLT WORKSHOP47

47. Recap Time!
We’ve now learned how with Puppet Bolt:
• Commands, scripts, tasks, plans and manifests can be run with Puppet Bolt
• What the natural progression of automation looks like
• Turning interactive commands into scripts
• Turning scripts into tasks
• Turning tasks into plans
• Leveraging existing desired state modules and manifests
• Incorporating desired state code into plans
BOLT WORKSHOP48

48. Connecting to Puppet Enterprise
• To complete the automation journey, all that’s left to do is maturing into PE
• Leverage PE to continuously & automatically enforce desired state code
• Gain auditability in PE on Bolt Tasks, Task Plans and manifests
• Use RBAC in PE to delegate permissions to other teams/coworkers
• Connect Bolt to PE to gain direct control over PE-managed targets
BOLT WORKSHOP49

50. PUPPET OVERVIEW51