Do you think IIT Guwahati certified course can help you in your career?
No
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!!
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.
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.
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:
When using the functions run_script, download_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.
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
On the Forge, look for the module you want.
Select r10k or Code Manager as the Installation method under Start using this module.
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.