Table of contents
1.
Introduction
2.
Puppet Enterprise
3.
Plans in PE
3.1.
RBAC(Role Based Access Control)
4.
Plans in PE versus Bolt plans
4.1.
Unavailable plan language functions
5.
Apply Blocks
6.
Target Groups
6.1.
Target behaviour
6.2.
Target Configuration
6.3.
 Localhost target
6.4.
The _run_as parameter
7.
Script and file sources
7.1.
Installing plans
7.2.
Installation
8.
Frequently asked questions
8.1.
In which language is Puppet coded?
8.2.
What is a puppet bolt?
8.3.
What is Puppet Enterprise?
8.4.
What are bolt tasks?
8.5.
What is a Puppet agent?
9.
Conclusion
Last Updated: Mar 27, 2024
Medium

Plans in Puppet Enterprise

Author Muskan Sharma
0 upvote
Career growth poll
Do you think IIT Guwahati certified course can help you in your career?

Introduction

Hey Readers!!

Have you ever heard the term puppet?

It's not the Puppet we played with in our childhood.

Puppet is a software configuration management and deployment tool. It is most commonly used on Linux and Windows to manage multiple application servers simultaneously.

In this article, you will learn about the Plans in Puppet Enterprise.

Let's begin!! 

Plans in Puppet Enterprise

Puppet Enterprise

A puppet is a tool for managing and automating server configuration. Puppet Enterprise (PE) is a commercial version of Puppet built on the Puppet platform.

Plans in PE

Plans enable you to connect tasks, scripts, commands, and other plans to build complex workflows with fine-grained access control. Install modules containing plans or create your own, then run them from the console or command line.

RBAC(Role Based Access Control)

  • RBAC is the process of restricting user access to network configurations and resources that provides RBAC security. RBAC solutions are provided to the users who are assigned roles based on the resources to which they require access.
  • RBAC does not overlap between plans and tasks. 
  • This means that if a user does not have access to a specific task but can run a plan that contains that task, they can still run the plan. This enables you to implement customized task access control by wrapping them within plans

Plans in PE versus Bolt plans

Some plan language functions, features, and behaviour patterns differ between PE and Bolt. Before attempting to write or run plans in PE, familiarize yourself with some key differences and limitations if you are used to Bolt plans.

Plans in PE versus Bolt plans

Unavailable plan language functions

The following Bolt plan functions do not work in PE because they have not yet been implemented or cause problems during the plan runs are following:

  • add_to_group
  • background
  • dir::children
  • download_file
  • file::exists
  • file::read
  • file::readable
  • file::write
  • get_resources
  • out::verbose
  • parallelize
  • prompt
  • prompt::menu
  • remove_from_group
  • resolve_references
  • resource

Apply Blocks

The apply feature, including apply_prep, is only available for targets that use the PXP agent and PCP transport. It does not work on remote devices or targets connected via SSH or WinRM.

Target Groups

In PE, there is no support for target groups. Using add to group fails a plan, and referencing a group name in get targets returns no nodes. When calling get targets, you must specify either node certnames or a PuppetDB query.

Example:

plan exampleninjas::get_targets_exampleninjas ()
{ $nodes = get_targets([‘node1.exampleninjas.com’, ‘node2.exampleninjas.com’]) run_command(‘whoami',  $nodes) }

Target behaviour

  • Puppet Enterprise assumes all the target references can be matched to a connected agent with a certname or a PE inventory service entry. Target names must match either a certname or a PE inventory service entry.
  • New targets cannot be added to inventory service within a plan. Any new target objects added to a plan will be unable to connect because PE will not recognize them.
  • When asked for connection information, the target must return an empty hash.

Target Configuration

Using the set_config function in the plan causes the plan to fail, and referencing the configuration hash of a target object always returns an empty hash.

All references to targets, for example, when using get_targets, must be PuppetDB queries or valid certnames already in the PE inventory. Using URIs in a target name is also not supported to override the transport.

Example:

plan exampleninjas::get_targets_exampleninjas () 
{ ## If you use ssh://node1.example.com as the first entry, this plan will fail! 
$nodes = get_targets([‘node1.exampleninjas.com’, ‘node2.exampleninjas.com’]) run_command(‘whoami’, $nodes) }

 Localhost target

Plans in PE do not support the special target localhost. Using localhost anywhere in a plan causes the plan to fail. If you need to run the plan on the primary server host, refer to it using the primary server's certname.

For the primary server that hosts my-primary-server.company.com, for example, you can use the following plan:

plan exampleninjas::referencing_the_primary_server()
{ # If you use `localhost` instead of `my-primary-server,` this plan would fail! run_command(‘whoami’, ‘my-primary-server.company.com’) }

The _run_as parameter

Plans in PE do not support changing the user who accesses hosts or executes actions with the _run_as parameter. If this parameter is passed to any plan function, the plan is executed, but the user remains unchanged.

For example, the following plan is valid but cannot be executed as other_user:

plan exampleninjas::run_as_exampleninjas (TargetSpec $nodes) { run_command(‘whoami’, $nodes, _run_as => ‘other_user’) }

Script and file sources

When using the functions run_scriptdownload_file, or file:: The files must be read from a module that uses the modulename/filename selector for a file or directory in $MODULEROOT/files

 

Example directory structure
 

plan example::run_ninjas_example (TargetSpec $nodes) { run_ninjas(‘example/my_ninjas.sh’, $nodes) }

Installing plans

Plans are packaged into modules and deployed using Code Manager. PE includes some pre-installed plans. You can also download modules containing plans from the Forge and write custom plans.

Installation

  1. On the Forge, look for the module you want.
  2. Select r10k or Code Manager as the Installation method under Start using this module.
  3. Follow the instructions in Code Manager. It would help if you employed a Code Manager.

Frequently asked questions

In which language is Puppet coded?

Puppet Server and Puppet DB are written in Clojure. Puppet itself is written in Ruby.

What is a puppet bolt?

Bolt is known as an open-source orchestration tool. That simplifies the manual tasks involved in maintaining your infrastructure.

What is Puppet Enterprise?

A puppet is a tool for managing and automating server configuration. Puppet Enterprise (PE) is a commercial version of Puppet built on the Puppet platform.

What are bolt tasks?

Bolt tasks are single time operations that can be executed on target nodes in the infrastructure, it gives the flexibility to modify systems as required.

What is a Puppet agent?

The program that controls the configurations on your nodes is called a puppet agent.

Conclusion

In this article, we have extensively discussed Plans in Puppet Enterprise. Plans in PE versus Bolt plans. We also discussed the Target Groups. In the end, we saw the installation of plans.

For more content, Refer to our guided paths on Coding Ninjas Studio to upskill yourself. If you want to explore more, feel free to see our coursesinterview experiences, problems to solvetest serieslibraries, and resources

Thank You

Do upvote our blogs if you find them helpful!

Live masterclass