Customize the ordered steps Puppet pattern with hiera values

Customize the ordered steps Puppet pattern with hiera values Do you want to make your team’s Puppet code easier to read and more concise, and better organized? While still allowing customizations to allow the code to fit every client team’s unique needs? Then using the easy_type::ordered_steps function is the way to go.

Introduction

The ordered steps Puppet pattern we introduced in our last blog post helps you write more manageable Puppet code. However, if the sequence of steps needs to support many different clients who all need slightly different behavior, then your streamlined code becomes quickly littered with if-statements and case statements.

This blog post introduces the easy_type::orderd_steps function that allows for customizations to your flow by setting hiera values.

What is the problem?

In our previous blog post, we used this example:

class oracle_database {
  contain systl
  contain os_users_and_groups
  contain limits
  contain packages
  contain oracle_software
  contain database
  contain database_users
  contain database_storage

  Class['systl']
  -> Class['os_users_and_groups']
  -> Class['limits']
  -> Class['packages']
  -> Class['oracle_software']
  -> Class['database']
  -> Class['database_users']
  -> Class['database_storage']
  -> Class['database ']
}

What if your infrastructure team supports many client teams that all have their own ways of doing Puppet things? All just slightly different. Let’s say one of your customer teams has all of the OS limits in the base profile and doesn’t want any other profile modules to handle them. Another team has special requirements for creating the OS users and groups. Yet another team wants to install some extra security software before generating the database. You could use if-statements, but doing so would turn your once elegant class into a monstrosity.

What if you could leave the puppet code for this profile exactly as it is, allowing clients to modify it with hiera values? You certainly can!

Introducing the orderd_steps function

The basic change consists of this code:

easy_type::ordered_steps([
  'systl',
  'os_users_and_groups',
  'limits',
  'packages',
  'oracle_software',
  'database',
  'database_users',
  'database_storage']
)

The Puppet code above uses the easy_type::ordered_steps function with an array of strings. Every string in the array is the name of a puppet class. All these classes will be executed in the order specified- the same as the original code.

This is a little more compact than the previous version, but it’s not much different. And what does this do for customization?

How to customize the behavior?

The ordered_steps function is quite powerful under the hood. Let’s look at some scenarios to illustrate its power.

Skipping a step

In the example above, we discussed a team that doesn’t want any profile classes to go over their security parameters. We can create a new profile class and remove the limits class from the manifest, or we could utilize an if-statement to fix this; however, the ordered_steps function allows you to specify a hiera value that will skip applying this class all together. When you add this to the hiera data for this team:

oracle_database::limits:		skip

the ordered_steps function will skip adding the limits class to your manifest. Thus implementing this use case.

Replacing a step

In the second use case, a team has unique requirements for creating OS users and groups. The current os_users_and_groups class does not align with these preferences. Instead of adding this to the company-wide Puppet code, you would rather have the customer team manage it.

When you include this code:

oracle_database::os_users_and_groups:   customer_team_1::special_os_users_and_groups

in the hiera data for this team, instead of the standard class, the ordered_steps function will call the class supplied by the customer team. As a result, this use case is implemented.

Executing Puppet statements before or after

The final use case is installing security software before initializing the database. We could employ an if-statement to do this, but by utilizing the ordered_steps function, we can also include additional Puppet code.

When you include this code:


oracle_database::before_database:		customer_team_1::security_software

in the hiera data for this team, the ordered_steps function will ensure the class customer_team_1::security_software is applied before the database class is applied. Since the ordered_steps function supports both before and after classes, we could also accomplish the same using this code:

oracle_database::after_oracle_software:		customer_team_1::security_software

What do you need to use this function?

We left out the parameters you need to add to the oracle_database class in order to make things clearer, but under the hood, ordered_steps executes a lot of parameter lookups. In order for us not to run into any Puppet warnings, those parameters have to be added to the class definition like this:

class oracle_database(
  Optional[String] $before_systl = undef,
  Optional[String] $before_os_users_and_groups = undef,
  Optional[String] $before_limits = undef,
  Optional[String] $before_packages = undef,
  Optional[String] $before_oracle_software = undef,
  Optional[String] $before_database = undef,
  Optional[String] $before_database_users = undef,
  Optional[String] $before_database_storage = undef,
  Optional[String] $systl = undef,
  Optional[String] $os_users_and_groups = undef,
  Optional[String] $limits = undef,
  Optional[String] $packages = undef,
  Optional[String] $oracle_software = undef,
  Optional[String] $database = undef,
  Optional[String] $database_users = undef,
  Optional[String] $database_storage = undef,
  Optional[String] $after_systl = undef,
  Optional[String] $after_os_users_and_groups = undef,
  Optional[String] $after_limits = undef,
  Optional[String] $after_packages = undef,
  Optional[String] $after_oracle_software = undef,
  Optional[String] $after_database = undef,
  Optional[String] $after_database_users = undef,
  Optional[String] $after_database_storage = undef,
) {
  easy_type::ordered_steps([
    'systl',
    'os_users_and_groups',
    'limits',
    'packages',
    'oracle_software',
    'database',
    'database_users',
    'database_storage']
  )
}

The easy_type::ordered_steps function is defined in the enterprisemodules-easy_type module. The enterprisemodules-easy_type module is a collection of functions, custom types, and other Puppet goodies that we use for all of our commercial modules. You are free to install and use it. Check the documentation on the Puppet forge for more information. To use this function, you’ll have to add this module to your Puppetfile

Summary

Do you want to make your team’s Puppet code easier to read and more concise, and better organized? While still allowing customizations to allow the code to fit every client team’s unique needs? Then using the easy_type::ordered_steps function is the way to go.

The easy_type::ordered_steps function not only allows you to make your Puppet code with the order steps pattern more concise, it also allows extensive customizations using hiera values. You can replace the current implementation with a team-specific implementation, or you can omit the step altogether. If you need to include code in the sequence, you can use the before or after option of the ordered_steps function.

If you could use a hand, we are here to help. Making good Puppet code is our bread and butter at Enterprise Modules. But besides developing our own modules, we are also helping customers build the best possible Puppet code. Do you think you could need some assistance? Don’t hesitate to contact us at info@enterprisemodules.com or by phone: +31 (0)30-601 6000 for some consultancy.

About us

Enterprise Modules is the leading developer of enterprise-ready puppet modules for Oracle databases,Oracle WebLogic, and IBM MQ or DB2 software. Our puppet modules help sysadmins and DBAs to automate the installation, configuration, and management of their databases and application server systems. These modules allow them to make managed, consistent, repeatable, and fast changes to their infrastructure and automatically enforce the consistency. We are a proud member of the Conclusion family.

Conclusion is thé multidisciplinary service provider in the field of Business Transformation and IT Services. Our tagline? Business Done Differently. Our 1250 specialists and professionals live up to that every day by truly combining our IT knowledge with business and domain know-how. With dedication, creativity, and flexibility, we take responsibility for the social and mission-critical business processes and systems of our customers and enable organizations to digitally transform their business model. Our primary focus is on the Dutch market and more specifically on the domains of Public Transport, Healthcare, Finance, and Industry. Conclusion. Business Done Differently.

For more information, please visit our website: www.enterprisemodules.com or contact us at info@enterprisemodules.com.