Learn how you can easily automate complex application deployments with Puppet Bolt and ensure continuous compliance in day-to-day operations with Puppet Enterprise. Presented at Eficode's DevOps Tooling Morning 2019.

1. DevOps Automation with
Puppet Bolt & Puppet Enterprise
Eficode DevOps Tooling Morning 2019
Kevin Reeuwijk
Sr Sales Engineer NEMEA
kevinr@puppet.com

3. Bolt: an open source task runner
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, Puppet Tasks and Puppet Task 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
Accessible automation at no cost

4. bolt command run <cmd> --nodes … bolt script run <file> --nodes … bolt task run <task> --nodes …
2. Scripts
.sh .ps1
PS C:>
[root/]#
1. Commands
Start-Service W32Time
systemctl start ntpd
3. Tasks
.ps1 .json
- Task description
- Allowed parameters
- Input validation
bolt plan run <plan> --nodes …
4. Plans
plan timesync::manage {
run_task ( ‘timesync::reset’, $nodes, default => true )
apply ( $nodes ) {
# some Puppet code here to manage time synchronization
}
run_task ( ‘timesync::restart’, $nodes, force => true )
}
+
Version Control

5. Using Bolt
Bolt command line syntax:
bolt [command|script|task|plan] run <name> --nodes <nodes> [options]
To run a simple Bash command on a remote SSH host:
bolt command run 'echo Hello World!' --nodes 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!' --nodes 10.0.0.1, 10.0.0.2
--user administrator --password 'P@ssw0rd' --transport winrm --no-ssl

6. Easing Bolt’s configuration
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
https://puppet.com/docs/bolt

7. Bolt Inventory File - Syntax
groups:
- name: group_name
nodes:
- 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 ]
https://puppet.com/docs/bolt/latest/inventory_file.html
Nesting of groups is allowed:
groups:
- name: top_group
groups:
- name: sub_group
nodes:
- …

8. Turning a script into a Puppet Task
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:
modules/mymod/tasks/script1.ps1 # mymod::script1
modules/aws/tasks/show_vpc.sh # aws::show_vpc
modules/mysql/tasks/sql.rb # mysql::sql
modules/yum/tasks/init.rb # yum
https://puppet.com/docs/bolt/latest/writing_tasks.html

9. Writing metadata for Puppet Tasks
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"
}
}
}

10. Writing Puppet Task Plans
Puppet Task Plans can use all of the previously covered capabilities, and more, in a
single plan. It’s ideally suited to:
• String Tasks together
• 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
https://puppet.com/docs/bolt/latest/writing_plans.html

11. Anatomy of a Puppet Task Plan
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)
}
https://puppet.com/docs/bolt/latest/writing_plans.html

12. Enable efficient coding with VS Code + plugin and the PDK
https://puppet.com/download-puppet-development-kit
+
Full description: https://github.com/lingua-pupuli/puppet-vscode

13. Coding for Puppet in VS Code, much better!

14. Isn’t there a better way to automation than Tasks?
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?!
- Insert eyeroll here -

15. Puppet DSL: Infrastructure as Code (IaC)
building { 'home':
ensure => 'clean',
front_door => 'closed',
keys => 'key_hook',
jacket => 'closet',
floor => 'vacuumed’,
litter_box => 'empty',
remote => 'coffee_table',
}
Puppet gives teams
a common,
model-driven
language.

16. Managing desired state configuration with Puppet DSL (1/2)
What if we could just describe what
end result we wanted:
• Time should always be in sync
• A specific list of timeservers
should be used to sync from
• Only sync as a client (don’t act as
an authoritative source)
class { 'windowstime':
servers => {
'0.nl.pool.ntp.org' => '0x08',
'1.nl.pool.ntp.org' => '0x08'
}
}
The 0x08 flag is
Windows-speak
for ‘Client’

17. Managing desired state configuration with Puppet DSL (2/2)
We still want the same things, but
now for any Linux OS:
• Time should always be in sync
• A specific list of timeservers
should be used to sync from
• Only sync as a client (don’t act as
an authoritative source)
class { 'ntp':
servers => [
'0.nl.pool.ntp.org',
'1.nl.pool.ntp.org'
]
restrict => [‘127.0.0.1’]
}
This is
Linux-speak
for ‘Client’

18. Applying Puppet DSL can also be done in a Bolt plan
Run your Puppet code from a plan,
using an Apply() block:
• Can be combined with all other
Plan functions (run_task,
run_command, etc)
• Requires the apply_prep() function
to be run first on nodes, this will
ensure the Puppet agent is
available and will run facter
plan tools::timesync_code(
TargetSpec $nodes,
) {
apply_prep($nodes)
apply($nodes) {
class { 'windowstime':
servers => {
'0.nl.pool.ntp.org' => '0x08',
'1.nl.pool.ntp.org' => '0x08’
}
}
}

19. What have we learned so far
We’ve now learned how with Puppet Bolt, we can:
• 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 rocks, duh

20. Manage at scale.
Keep it compliant.

21. Puppet Enterprise Vendor neutral.
• Any container in any cloud
• Any bare metal or VM server
• Common network devices
• Any operating system
Model-driven and task-oriented.
• Desired-state configuration management
• Simple and orchestrated tasks
Enterprise-grade.
• Team features: RBAC, code mgmt
• Simple: installation / upgrade, console
• Scalability: 100k nodes and beyond
• Workflows: direct change, convergence
• Reporting & Compliance

22. A Leader in
Configuration
Management
Automation
Source: Forrester Research, Configuration Management Software for
Infrastructure Automation, Q4 2018. Download at puppet.com

23. Puppet Enterprise provides better situational awareness…

24. …across your entire infrastructure

25. See the enforcement history of every server in detail

26. See the state of all resources under management for a node

27. Automatically inspect & manage software across your estate

28. Control Puppet runs from a central location

29. Let’s connect our nodes 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 nodes

30. We can natively run Tasks against our nodes from PE
• Available Tasks are
read from a code
repository
• Tasks can be
protected with
RBAC
• A Tasks history is
kept in the ‘Jobs’
view

31. Puppet Enterprise dynamically generates the UI for Tasks

32. You can even run Tasks agentlessly now (from PE 2019)

33. As well as specify a schedule for the Task to run on

34. You control who can run Tasks on which nodes…

35. …and all Tasks & Plans that ran get automatically logged

36. Can’t I just use Bolt directly against PE-managed nodes?
Bolt supports another transport: PCP (Puppet Communications Protocol)
• This is the protocol that Puppet Enterprise uses to centrally control nodes
• It uses PE’s RBAC for security, so you don’t need SSH/WinRM credentials
• Everything you do via PCP is automatically tracked & logged in Puppet Enterprise
• To set this up, you need three things:
• The puppetlabs/bolt_shim module on the PE server (already setup in this lab)
• The Tasks you want to use from Bolt must be copied into Git so PE can see them
• 4 entries in the pcp: section of bolt.yaml to tell Bolt how to connect to PE
The gift that keeps on giving…

37. Download the 2018 State of DevOps Report today
Figure out where you are in the journey. Learn what works. Reach for the next stage.
https://puppet.com/resources/whitepaper/state-of-devops-report

38. The shortest path
to better software.