Puppet Rlindo Puppetcert Ref

Many people on linuxacademy comunity talk about this page https://github.com/rilindo/PPT-203-Certification

1 Identify Style Guide recommendations

1.1 style guide

indentation

  • Must use two-space soft tabs,
  • Must not use literal tab characters,
  • Must not contain trailing whitespace,
  • Must have trailing commas after all resource attributes and parameter definitions,
  • Should not exceed a 140-character line width,
  • Should leave one empty line between resources, except when using dependency chains, and
  • Should align hash rockets (=>) within blocks of attributes, remembering to arrange hashes for maximum readability first.

quoting

  • All strings must be enclosed in single quotes, unless they contain variables or single quotes.
  • Quoting is optional when the string is an enumerable set of options (such as present/absent).
  • All variables must be enclosed in braces when interpolated in a string.

public module

  • Every publicly available module must have metadata defined in the metadata.json file
  • Hard dependencies must be declared explicitly in your module’s metadata.json file. Soft dependencies should be called out in the README.md, and must not be enforced as a hard requirement in your metadata.json. A soft dependency is a dependency that is only required in a specific set of use cases

Attribute ordering

  • If a resource declaration includes an ensure attribute, it should be the first attribute specified so a user can quickly see if the resource is being created or deleted.

declare a symbolik link

file { '/var/log/syslog':
      ensure => link,
      target => '/var/log/messages',
}

File modes

  • POSIX numeric notation must be represented as 4 digits.
  • POSIX symbolic notation must be a string.
  • You should not use file mode with Windows; instead use the acl module.
  • You should use numeric notation whenever possible.

Resource defaults

  • Resource defaults should be used in a very controlled manner and should only be declared at the edges of your manifest ecosystem. Specifically, they may be declared:
  • At top scope in site.pp, or In a class which is guaranteed to never declare or be inherited by a class or defined type from another module.
  • This is due to the way resource defaults propagate through dynamic scope, which can have unpredictable effects far away from where the default was declared.
# /etc/puppetlabs/puppet/manifests/site.pp:
File {
  owner => 'root',
  group => '0',
  mode  => '0644',
}

to help build reusable and readable code

  • split your module into public and private classes and defined types where possible.
  • Public classes or defined types should contain the parts of the module meant to be configured or customized by the user
  • private classes should contain things you do not expect the user to change via parameters

Nested classes or defined types

  • Classes and defined resource types must not be defined within other classes or defined types.
  • Classes and defined types should be declared as close to node scope as possible.

class and defined parameters

  • In parameterized class and defined type declarations, required parameters must be listed before optional parameters

Exported Resources

  • try to avoid use exported resources, if you need use the property collect_exported

Inheritance

  • Inheritance can be used within a module, but must not be used across module namespaces.

variables name

  • When defining variables you must only use numbers, lowercase letters, and underscores.

case statements

  • Case statements must have default cases. If you want the default case to be “do nothing,” you must include it as an explicit default: {} for clarity’s sake.

Hiera

  • don't use hiera inside module but in the module parameters

documentation

  • write a README in .md (or .markdown) format
  • use strings to document module, it is the replacement for "puppet doc"
  • CHANGELOG in .md (or .markdown) format to list what is changed in the latest releases

2 Describe language features

2.1 Language: Basics

Files

  • Must use UTF8 encoding
  • May use Unix (LF) or Windows (CRLF) line breaks

2.2 Reserved Words and Acceptable Names

It is difficult to summarize

2.3 Resources

Relationships and Ordering Puppet 4.x

By default, Puppet applies unrelated resources in the order in which they’re written in the manifest. You can disable this with the ordering setting.

However, if a resource must be applied before or after some other resource, you should declare a relationship between them, to show that their order isn’t coincidental. You can also make changes in one resource cause a refresh of some other resource. See the Relationships and Ordering page for more information.

Parse-Order Independence Puppet 3.x

Resources are not applied to the target system in the order they are written in the manifests — Puppet will apply the resources in whatever way is most efficient. If a resource must be applied before or after some other resource, you must explicitly say so. See Relationships for more information.

2.4 Relationships and Ordering

To make Puppet apply unrelated resources in a more-or-less random order, set the ordering setting to title-hash or random.

And since collectors can be chained, you can create many-to-many relationships:

Yumrepo <| |> -> Package <| |>

This example applies all yum repository resources before applying any package resources, which protects any packages that rely on custom repositories.

Capturing Resource References for Generated Resources ???

Reversed Forms
Both chaining arrows have a reversed form (<- and <~). As implied by their shape, these forms operate in reverse, causing the resource on their right to be applied before the resource on their left.

Note: Most of Puppet’s syntax is written left-to-right. Avoid these reversed forms as they can be confusing.

No-Op
If a resource is in no-op mode (due to the global noop setting or the per-resource noop metaparameter), it will not refresh when it receives a refresh event. However, Puppet will log a message stating what would have happened.
If a resource is in no-op mode but Puppet would otherwise have changed or refreshed it, it will not send refresh events to subscribed resources. However, Puppet will log messages stating what would have happened to any resources further down the subscription chain.

Auto* Relationships
Certain resource types can have automatic relationships with other resources, using autorequire, autonotify, autobefore, or autosubscribe. This creates an ordering relationship without the user explicitly stating one

2.5 Resource Default Statements

Resource defaults declared in the local scope will override any defaults received from parent scopes.

2.6 Variables

Puppet can resolve variables in double-quoted strings; this is called “interpolation.”

When creating a local variable with the same name as a variable in top scope, node scope, or a parent scope, you can optionally append to the received value with the += (plus-equals) appending assignment operator.

 $ssh_users = ['myself', 'someone']

class test {
  $ssh_users += ['someone_else']
}

The value appended with the += operator must be the same data type as the received value. This operator can only be used with strings, arrays, and hashes:

Strings: Will concatenate the two strings.
Arrays: Will add the elements of the appended array to the end of the received array.
Hashes: Will merge the two hashes.

Parse-Order Dependence

  • Unlike resource declarations, variable assignments are parse-order dependent. This means you cannot resolve a variable before it has been assigned.
  • This is the main way in which the Puppet language fails to be fully declarative.

2.7 Tags

Automatic Tagging

  • file resource in class apache::ssl would get the tags file, apache::ssl, apache, and ssl.

Containement

  • a resource will receive all of the tags from the class and/or defined type that contains it. In the case of nested containment
  • a resource will receive tags from all of its containers.

The tag Metaparameter

  • is a resource declaration to add any number of tags
apache::vhost {'docs.puppetlabs.com':
  port => 80,
  tag  => ['us_mirror1', 'us_mirror2'],
}

The tag Function

class role::public_web {
  tag 'us_mirror1', 'us_mirror2'

  apache::vhost {'docs.puppetlabs.com':
    port => 80,
  }
  ssh::allowgroup {'www-data': }
  @@nagios::website {'docs.puppetlabs.com': }
}

assign the us_mirror1 and us_mirror2 tags to all of the defined resources being declared in the class role::public_web

Restricting Catalog Runs
Puppet agent and Puppet apply can use the tags setting to only apply a subset of the node’s catalog.
The tags setting can be set in puppet.conf (to permanently restrict the catalog) or on the command line (to temporarily restrict it):

$ sudo puppet agent --test --tags apache,us_mirror1

Sending Tagmail Reports
The tagmail module can send emails to arbitrary email addresses whenever resources with certain tags are changed.

2.8 Facts and Built-in Variables

Handling Boolean Facts in Older Puppet Versions
Puppet 3.x will sometimes convert all fact values to strings (e.g. "false" instead of false)

To handle this, you can use the str2bool function (from puppetlabs/stdlib) to prevent fake true values:

if str2bool("$is_virtual") {
  ...
}
Using facts

mode 1

if $osfamily == 'redhat' {
  # ...
}
OR
if $::osfamily == 'redhat' {
  # ...
}

Drawbacks: It’s not immediately obvious that you’re using a fact — someone reading your code needs to know which facts exist to guess that you’re accessing a special top-scope variable. To get around this, some people use the $::fact_name idiom as a hint, to show that they’re accessing a top-scope variable.

mode 2

if $facts['osfamily'] == 'redhat' {
  # ...
}

Drawbacks: Only works with Puppet 3.5 or later. Disabled by default in open source releases prior to Puppet 4.0.
Special Variables Added by Puppet
  • The $trusted hash: which has trusted data from the node’s certificate

'authenticated', 'certname', 'domain', 'extensions', 'hostname'

  • The $server_facts variable provides a hash of server-side facts that cannot be overwritten by client side facts for example serverversion, servername, serverip, environment
  • Puppet Agent Facts, Puppet agent and Puppet apply both add several extra pieces of info to their facts before requesting or compiling a catalog. For example $clientcert $clientversion $clientnoop $agent_specified_environment
  • Puppet Master Variables Several variables are set by the Puppet master. $environment, $servername, $serverip, $serverversion, $settings::<name of setting>
  • Compiler Variables These variables are set in every local scope by the compiler during compilation. They are mostly useful when implementing complex defined types. These are not available in the $facts hash. $module_name $caller_module_name
Salvo diversa indicazione, il contenuto di questa pagina è sotto licenza Creative Commons Attribution-ShareAlike 3.0 License