Skip to content

Profile guidelines

Overview

What is a profile ?

A profile is a collection (wrapper) of one or more component modules and/or resources along with any required logic or specific parameter values that wrap a application techonolgy stack.

Breakdown

  • Technology specific
  • May include resources directly
  • May make calls to Hiera for required data (parameters)
  • Include Component module classes/resources
  • Named according to the technology they manage
    • Do NOT include environments in profile names

Guidelines

Naming

Profile naming needs to adhear to the following conventions:

  • Named according to the technology that they manage
  • Do NOT include a - (hypen), may include an _ (underscore)
  • Do NOT include the puppet environment or environment tier (envtier)
  • (prod, stage, test, dev, si ....)

Documentation

# == Overview:
#
# == Requirements:
#
# == Monitoring:
#
# == Notes:

Inline comments are encouraged where sane, to provide clarity

Each 'top level' profile manifest should be properly documented detailing the following information

  • Overview: one-maybe-two sentence summary of what the profile does/problem it solves
  • Requirements: Anything extra your manifest requires before being applied (bootstraped)
  • Monitoring: Service Checks that are to be configured on the monitoring server
  • Notes: Any additoinal information that provides clarity/suppliments the overview.

Each additional 'child/sub' class or define should include the following information

  • Overview: one-maybe-two sentence summary of what the class does/problem it solves

Hierarchy

Each profile should attempt to adhere to the following hierarchy model that follows a branching pattern for any 'child/sub' classes or defines.

profile
 ├──manifests
 |  └──applicationx.pp
 |  └──applicationx
 |     └──sub_class1.pp
 |     └──sub_class.pp
 |     └──monitoring
 |        └──base.pp
 |        └──define1.pp
 |        └──define2.pp
 ├──templates
 |  └──applicationx
 |  |  └──applicationx_file.ini.erb
 |  └──icinga2
 |     └──checkcommands
 |     |  └──check_applicationx.py.erb
 |     └──checkplugins
 |        └──check_applicationx.py.erb
 └──files
     └──applciationx
     |  └──applicationx_file.ini
     └──icinga2
        └──checkcommands
        |  └──check_applicationx.py.erb
        └──checkplugins
          └──check_applicationx.py.erb

Manifests

'Top level' manifests will be included in a role class to be applied to a node or nodes

Store 'child/sub' classes or defines within a sub-directory with the same name as the 'top level' manifest.

Use 'child/sub' classes or defines with logic for a specific identifier such as site, security zone, etc... This helps to limit the size and complexity of monolithic manifests.

  • Reference these in the 'top level' manifest.
  ## Include Required Sub-Class
  if ($::domain == 'cha.arin.net') or ($::domain == 'core.cha.arin.net') {
    include profile::applicationx::cha
  }
  elsif ($::domain == 'ash.arin.net') or ($::domain == 'core.ash.arin.net') {
    include profile::applicationx::ash
  }
  else {
    notify { 'ApplicationX Sub-Classes Not Loaded':
      withpath => true,
    }
  }

Store 'child/sub' classes or defines related to monitoring within a sub-directory named monitoring under the application sub-directory.

Define monitoring checksin a class named base profile::applicationx::monitoring::base.

  • Reference puppet defines in the base monitoring class.
profile::applicationx::monitoring::define1 = { $applicationx_server_names: }
profile::applicationx::monitoring::define2 = { $applicationx_server_names: }

Files/Templates

Store required files or templates referenced within a profile child/sub' class or define (excluding monitoring) in a sub-directory with the same name as the 'top level' manifest.

Store required files or templates referenced within a profile child/sub' class or define in a sub-directory with the same name of the monitoring software such as Icinga2.

Store catagory specific (checkcommands, checkplugins) monitoring files or templates in a sub-directory with the catagory name (checkcommands, checkplugins) under the templates/icinga2 directory