Bolt Workshop
Singapore Virtual Bolt Workshop - 23 April 2020
Chan Guangwei
Sales Engineer, Singapore
Email: guangwei.chan@puppet.com
23 April 2020
BOLT WORKSHOP2
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 PE from Bolt
BOLT WORKSHOP3
Environment Setup
• Create a Bolt playground directory (i.e. ~/boltworkshop or c:usersyouboltworkshop)
• Create a Boltdir within your playground directory (i.e. ~/boltworkshop/Boltdir)
• Grab the Linux cert:
• Web Browser Method
• Visit https://vboltsg.classroom.puppet.com/download/student.pem
• Log in as client<X>@puppet.com
• <X> refers to your student number
• Store the contents in your Bolt playground directory as student.pem.
• i.e. ~/boltworkshop/Boltdir/student.pem
• c:usersyouboltworkshopBoltdir/student.pem
BOLT WORKSHOP6
Using Bolt
• 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 WORKSHOP7
BOLT WORKSHOP8
Lab One:
Bolt Command
Lab One Instructions (A Long Command For A Ping!)
• Student Bolt Instances
Linux: vboltnix#.classroom.puppet.com
Windows: vboltwin#.classroom.puppet.com
• Credentials
Linux: centos / student.pem
Windows: Administrator / Puppetlabs!
• Run these from the command line
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 WORKSHOP9
Easing Bolt Configuration
http://www.puppet.com/docs/bolt
• Bolt provides ways to make common activities 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 WORKSHOP10
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 WORKSHOP11
Bolt Configuration File Syntax
http://www.puppet.com/docs/bolt/latest/bolt_configuration_options.html
modulepath: "/path/one:/path/two:/path/three“
inventoryfile: "~/.puppetlabs/bolt/inventory.yaml“
ssh:
host-key-check: false
winrm:
ssl: false
pcp:
[options]
log:
console: # or /path/to.log
level: info
BOLT WORKSHOP12
BOLT WORKSHOP13
Lab Two:
Use Bolt with
bolt.yaml
Lab Two Instructions (Making some Defaults)
1. Create a Boltdir directory in your playground folder
2. Create Boltdir/bolt.yaml in your bolt playground folder.
3. 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
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
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
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:
- …
BOLT WORKSHOP17
Lab Three:
Build an
Inventory File
Lab Three: 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:
http://bit.ly/BoltINV
Note:
● You’ll need to use your student number in the provided file. Replace #
● Add to bolt.yaml - inventoryfile: "./inventory.yaml"
BOLT WORKSHOP18
BOLT WORKSHOP19
Lab Four:
Use Bolt with
Inventory
Lab Four Reference (Using our Inventory)
1. Run bolt command run 'ping 8.8.8.8 -c2’ --targets linux
1. Run bolt command run 'ping 8.8.8.8 -n 2’ --targets windows
1. Run bolt command run 'hostname’ --targets linux,windows
BOLT WORKSHOP20
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 # Node 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
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
BOLT WORKSHOP23
Lab Five:
Run Scripts with
Bolt
Lab Five Instructions (Running a Script)
1. On your laptop, recreate the timesync.ps1 script at http://bit.ly/vbolttimesync
• 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 timesync.ps1 --targets windows
BOLT WORKSHOP24
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
BOLT WORKSHOP25
BOLT WORKSHOP26
Lab Six:
Convert a Script
to a Task
Lab Six Instructions (Turning Scripts into Tasks)
1. Create Boltdir/site/tools/tasks
2. Move the timesync.ps1 script into the tasks directory
3. Run bolt task show to verify the new task is available
4. Run bolt task run tools::timesync --targets windows to execute the task.
BOLT WORKSHOP27
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
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
BOLT WORKSHOP30
Lab Seven:
Create and Run
Bolt Task with
Metadata
Lab Seven Instructions (Parameterizing Tasks)
1. Retrieve timesync.json from http://bit.ly/vbolttimesyncjson
2. Retrieve upgraded timesync.ps1 from http://bit.ly/vbolttimesyncrestart
• Adds a “Restart” Parameter
• Adds an if statement restarting W32Time if Restart is passed
3. Copy timesync.json and timesync.ps1 to ./Boltdir/site/tools/tasks
4. Run bolt task show (Look, we have a description now!)
5. Run bolt task show tools::timesync
6. Run bolt task run tools::timesync -t windows restart=true
BOLT WORKSHOP31
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
Writing Bolt Plans
located in modules/my_mod/plans/my_plan.pp
plan my_mod::my_plan(
String[1] $load_balancer,
TargetSpec $frontends,
TargetSpec $backends
) {
# process frontends
run_task('my_mod::lb_remove', $load_balancer, frontends => $frontends)
run_task('my_mod::update_frontend_app', $frontends, version => '1.2.3’)
run_task('my_mod::lb_add', $load_balancer, frontends => $frontends)
}
BOLT WORKSHOP33
Bolt Functions
Puppet Task Plans are written in Puppet DSL, with extra plan-specific functions:
BOLT WORKSHOP34
● add_facts: Add Facts
● add_to_group: Grouping
● apply_prep: Install Agent
● facts: Gather Facts
● fail_plan: Fail Condition
● get_targets: Target Node
● puppetdb_fact: Facts
● puppetdb_query: PQL Query
● run_command: Run Shell
● run_plan: Run a Plan
● run_script: Run a Script
● run_task: Run a Task
● set_feature: Shell/PS/Agent
● set_var: Set a Variable
● upload_file: Upload a File
● vars: Returns Variables
● wait_until_available: Wait
● without_default_logging: Slim
Logs
And More: https://puppet.com/docs/bolt/latest/plan_functions.html
Bolt Plan with Functions
plan loop(
TargetSpec $targets
) {
$targets = get_targets($targets)
$certnames = $targets.map |$target| { $target.host }
$targets.each |$target| {
run_task('my_task', $target, certificate => $certnames[$target.host] )
}
}
BOLT WORKSHOP35
BOLT WORKSHOP36
Lab Eight:
Create and Run a
Bolt Plan
Lab 8 Instructions (Building a Plan)
1. Retrieve http://bit.ly/vbolttimesyncplan
2. Place timesync.pp in Boltdir/site/tools/plans (New Directory)
3. Run bolt plan show
4. Run bolt plan show tools::timesync
5. Run bolt plan run tools::timesync --targets windows
BOLT WORKSHOP37
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 WORKSHOP38
Desired State What Now?
• To ensure Puppet modules are easy to use, the attributes a module supports for
configuration often align closely to the technology the module manages.
• Time synchronization on Linux and Windows are different enough that the attributes for
one platform are difficult to understand on the other
• It does not often happen that someone builds a fully cross platform module
• A fully cross platform time synchronization module could still emerge at some point, it
will just have to use more generic attributes for configuration and translate those to
each platform as appropriate.
• ^^^ Which is exactly what desired state configuration is all about!
BOLT WORKSHOP41
BOLT WORKSHOP42
Lab Nine:
Apply a Puppet
Manifest
Lab Nine Instructions (Applying Puppet Code)
• Retrieve Plan manifest from http://bit.ly/timesyncmanifest 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: Could not find declared class
windowstime is the proper error!
BOLT WORKSHOP43
BOLT WORKSHOP45
Lab Ten:
Apply a Puppet
Manifest with a
Puppetfile
Lab Ten Instructions (Dependencies, the Puppetfile and You!)
1. Create boltworkshop/Boltdir/Puppetfile
1. Enter in dependencies: Stdlib, Registry, Windowstime and NTP
# Modules from the Puppet Forge.
mod 'puppetlabs-stdlib', '6.2.0'
mod 'puppetlabs-registry', '3.1.0'
mod 'ncorrare-windowstime', '0.4.3'
mod 'puppetlabs-ntp', '8.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 WORKSHOP46
BOLT WORKSHOP48
Lab Eleven:
Cross Platform
Plans
Lab Eleven Instructions (Let’s get Multi-Platform!)
1. Retrieve http://bit.ly/vboltmultiplatform and place it in
boltworkshop/Boltdir/site/tools/plans/timesync_code.pp
2. Run bolt plan run tools::timesync_code --targets windows,linux
BOLT WORKSHOP49
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 WORKSHOP50
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 WORKSHOP51
BOLT WORKSHOP52
Bolt in the Wild
PUPPET OVERVIEW53

Puppet Virtual Bolt Workshop - 23 April 2020 (Singapore)

  • 1.
    Bolt Workshop Singapore VirtualBolt Workshop - 23 April 2020 Chan Guangwei Sales Engineer, Singapore Email: guangwei.chan@puppet.com 23 April 2020
  • 2.
  • 3.
    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 PE from Bolt BOLT WORKSHOP3
  • 5.
    Environment Setup • Createa Bolt playground directory (i.e. ~/boltworkshop or c:usersyouboltworkshop) • Create a Boltdir within your playground directory (i.e. ~/boltworkshop/Boltdir) • Grab the Linux cert: • Web Browser Method • Visit https://vboltsg.classroom.puppet.com/download/student.pem • Log in as client<X>@puppet.com • <X> refers to your student number • Store the contents in your Bolt playground directory as student.pem. • i.e. ~/boltworkshop/Boltdir/student.pem • c:usersyouboltworkshopBoltdir/student.pem BOLT WORKSHOP6
  • 6.
    Using Bolt • Boltcommand 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 WORKSHOP7
  • 7.
  • 8.
    Lab One Instructions(A Long Command For A Ping!) • Student Bolt Instances Linux: vboltnix#.classroom.puppet.com Windows: vboltwin#.classroom.puppet.com • Credentials Linux: centos / student.pem Windows: Administrator / Puppetlabs! • Run these from the command line 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 WORKSHOP9
  • 9.
    Easing Bolt Configuration http://www.puppet.com/docs/bolt •Bolt provides ways to make common activities 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 WORKSHOP10
  • 10.
    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 WORKSHOP11
  • 11.
    Bolt Configuration FileSyntax http://www.puppet.com/docs/bolt/latest/bolt_configuration_options.html modulepath: "/path/one:/path/two:/path/three“ inventoryfile: "~/.puppetlabs/bolt/inventory.yaml“ ssh: host-key-check: false winrm: ssl: false pcp: [options] log: console: # or /path/to.log level: info BOLT WORKSHOP12
  • 12.
    BOLT WORKSHOP13 Lab Two: UseBolt with bolt.yaml
  • 13.
    Lab Two Instructions(Making some Defaults) 1. Create a Boltdir directory in your playground folder 2. Create Boltdir/bolt.yaml in your bolt playground folder. 3. 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 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
  • 14.
    Bolt Inventory • Boltsupports 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
  • 15.
    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: - …
  • 16.
  • 17.
    Lab Three: 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: http://bit.ly/BoltINV Note: ● You’ll need to use your student number in the provided file. Replace # ● Add to bolt.yaml - inventoryfile: "./inventory.yaml" BOLT WORKSHOP18
  • 18.
    BOLT WORKSHOP19 Lab Four: UseBolt with Inventory
  • 19.
    Lab Four Reference(Using our Inventory) 1. Run bolt command run 'ping 8.8.8.8 -c2’ --targets linux 1. Run bolt command run 'ping 8.8.8.8 -n 2’ --targets windows 1. Run bolt command run 'hostname’ --targets linux,windows BOLT WORKSHOP20
  • 20.
    The Boltdir To assistin 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 # Node 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
  • 21.
    Running Scripts • Boltwill 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
  • 22.
  • 23.
    Lab Five Instructions(Running a Script) 1. On your laptop, recreate the timesync.ps1 script at http://bit.ly/vbolttimesync • 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 timesync.ps1 --targets windows BOLT WORKSHOP24
  • 24.
    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 BOLT WORKSHOP25
  • 25.
  • 26.
    Lab Six Instructions(Turning Scripts into Tasks) 1. Create Boltdir/site/tools/tasks 2. Move the timesync.ps1 script into the tasks directory 3. Run bolt task show to verify the new task is available 4. Run bolt task run tools::timesync --targets windows to execute the task. BOLT WORKSHOP27
  • 27.
    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
  • 28.
    Bolt Task InputMethods • 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
  • 29.
    BOLT WORKSHOP30 Lab Seven: Createand Run Bolt Task with Metadata
  • 30.
    Lab Seven Instructions(Parameterizing Tasks) 1. Retrieve timesync.json from http://bit.ly/vbolttimesyncjson 2. Retrieve upgraded timesync.ps1 from http://bit.ly/vbolttimesyncrestart • Adds a “Restart” Parameter • Adds an if statement restarting W32Time if Restart is passed 3. Copy timesync.json and timesync.ps1 to ./Boltdir/site/tools/tasks 4. Run bolt task show (Look, we have a description now!) 5. Run bolt task show tools::timesync 6. Run bolt task run tools::timesync -t windows restart=true BOLT WORKSHOP31
  • 31.
    Writing Bolt Plans BoltPlans 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
  • 32.
    Writing Bolt Plans locatedin modules/my_mod/plans/my_plan.pp plan my_mod::my_plan( String[1] $load_balancer, TargetSpec $frontends, TargetSpec $backends ) { # process frontends run_task('my_mod::lb_remove', $load_balancer, frontends => $frontends) run_task('my_mod::update_frontend_app', $frontends, version => '1.2.3’) run_task('my_mod::lb_add', $load_balancer, frontends => $frontends) } BOLT WORKSHOP33
  • 33.
    Bolt Functions Puppet TaskPlans are written in Puppet DSL, with extra plan-specific functions: BOLT WORKSHOP34 ● add_facts: Add Facts ● add_to_group: Grouping ● apply_prep: Install Agent ● facts: Gather Facts ● fail_plan: Fail Condition ● get_targets: Target Node ● puppetdb_fact: Facts ● puppetdb_query: PQL Query ● run_command: Run Shell ● run_plan: Run a Plan ● run_script: Run a Script ● run_task: Run a Task ● set_feature: Shell/PS/Agent ● set_var: Set a Variable ● upload_file: Upload a File ● vars: Returns Variables ● wait_until_available: Wait ● without_default_logging: Slim Logs And More: https://puppet.com/docs/bolt/latest/plan_functions.html
  • 34.
    Bolt Plan withFunctions plan loop( TargetSpec $targets ) { $targets = get_targets($targets) $certnames = $targets.map |$target| { $target.host } $targets.each |$target| { run_task('my_task', $target, certificate => $certnames[$target.host] ) } } BOLT WORKSHOP35
  • 35.
  • 36.
    Lab 8 Instructions(Building a Plan) 1. Retrieve http://bit.ly/vbolttimesyncplan 2. Place timesync.pp in Boltdir/site/tools/plans (New Directory) 3. Run bolt plan show 4. Run bolt plan show tools::timesync 5. Run bolt plan run tools::timesync --targets windows BOLT WORKSHOP37
  • 37.
    Desired State WhatNow? • 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 WORKSHOP38
  • 40.
    Desired State WhatNow? • To ensure Puppet modules are easy to use, the attributes a module supports for configuration often align closely to the technology the module manages. • Time synchronization on Linux and Windows are different enough that the attributes for one platform are difficult to understand on the other • It does not often happen that someone builds a fully cross platform module • A fully cross platform time synchronization module could still emerge at some point, it will just have to use more generic attributes for configuration and translate those to each platform as appropriate. • ^^^ Which is exactly what desired state configuration is all about! BOLT WORKSHOP41
  • 41.
  • 42.
    Lab Nine Instructions(Applying Puppet Code) • Retrieve Plan manifest from http://bit.ly/timesyncmanifest 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: Could not find declared class windowstime is the proper error! BOLT WORKSHOP43
  • 44.
    BOLT WORKSHOP45 Lab Ten: Applya Puppet Manifest with a Puppetfile
  • 45.
    Lab Ten Instructions(Dependencies, the Puppetfile and You!) 1. Create boltworkshop/Boltdir/Puppetfile 1. Enter in dependencies: Stdlib, Registry, Windowstime and NTP # Modules from the Puppet Forge. mod 'puppetlabs-stdlib', '6.2.0' mod 'puppetlabs-registry', '3.1.0' mod 'ncorrare-windowstime', '0.4.3' mod 'puppetlabs-ntp', '8.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 WORKSHOP46
  • 47.
  • 48.
    Lab Eleven Instructions(Let’s get Multi-Platform!) 1. Retrieve http://bit.ly/vboltmultiplatform and place it in boltworkshop/Boltdir/site/tools/plans/timesync_code.pp 2. Run bolt plan run tools::timesync_code --targets windows,linux BOLT WORKSHOP49
  • 49.
    Recap Time! We’ve nowlearned 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 WORKSHOP50
  • 50.
    Connecting to PuppetEnterprise • 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 WORKSHOP51
  • 51.
  • 52.