Puppet Plugin


Puppet plugin description and configuration

Description

The Puppet plugin can be used to map node life cycle operations to Puppet manifest runs.

Plugin Requirements:

  • Python versions:
    • 2.7.x

Puppet plugin usage options

The Puppet plugin allows you to run either Puppet agent or Puppet standalone. The usage option is chosen based on presence or absence of server property under node’s properties > puppet_config. If server is present, Puppet agent is used. If server is not present, Puppet standalone is used.

Example:

  
imports:
  - http://getcloudify.org/spec/puppet-plugin/1.2/plugin.yaml
node_templates:
  example_web_server:
    type: cloudify.puppet.nodes.WebServer
    properties:
      puppet_config:
        server: puppet.example.com  # Agent
        ...
  

Types

Node types that can be used for Puppet nodes are listed below. All of them are derived from the corresponding abstract types.

  • cloudify.puppet.nodes.ApplicationModule – derived from cloudify.nodes.ApplicationModule
  • cloudify.puppet.nodes.ApplicationServer – derived from cloudify.nodes.ApplicationServer
  • cloudify.puppet.nodes.DBMS – derived from cloudify.nodes.DBMS
  • cloudify.puppet.nodes.SoftwareComponent – derived from cloudify.nodes.SoftwareComponent
  • cloudify.puppet.nodes.WebServer – derived from cloudify.nodes.WebServer

Properties:

In addition to inherited properties all of the Puppet types have the following properties:

Integration

This section describes integration aspects that are common to both Puppet agent and Puppet standalone. Also see Puppet agent and Puppet standalone sections for additional integration details.

Lifecycle operations naming

When defining a YAML node, there are several places that contain per-operation configuration. Most of the operations in Cloudify are named cloudify.interfaces.lifecycle.* and cloudify.interfaces.relationship_lifecycle.*. For convenience, when defining a node, the operation names are shortened so only the last part is used. Example:

  
imports:
  - http://getcloudify.org/spec/puppet-plugin/1.2/plugin.yaml
node_templates:
  example_web_server:
    type: cloudify.puppet.nodes.WebServer
    properties:
      puppet_config:
        ...
        operations_tags:
          start: my_start_tag  # cloudify.interfaces.lifecycle.start
          stop: my_stop_tag    # cloudify.interfaces.lifecycle.stop
  

Puppet version to install

You can specify which Puppet version to install (to use as agent or standalone) under properties > puppet_config > version. Defaults to 3.5.1-1puppetlabs1.

Example:

  
imports:
  - http://getcloudify.org/spec/puppet-plugin/1.2/plugin.yaml
node_templates:
  example_web_server:
    type: cloudify.puppet.nodes.WebServer
    properties:
      puppet_config:
        version: 3.5.1-1puppetlabs1
        server: puppet.example.com
        environment: myenv
        node_name_prefix: myweb-
  

Blueprint specified Puppet/facter facts

You can specify custom facts to pass to Puppet under properties > puppet_config > facts. These will be flattened so that the fact name will be of the form level1_level2_level3_....

Note

properties > puppet_config > facts hash must not contain cloudify or cloudify_* keys as these are generated by Cloudify.

Example:

  
imports:
  - http://getcloudify.org/spec/puppet-plugin/1.2/plugin.yaml
node_templates:
  example_web_server:
    type: cloudify.puppet.nodes.WebServer
    properties:
      puppet_config:
        ...
        facts:
          level1:
            level2:
              level3: myval
  

This will make available a fact named level1_level2_level3 with the value myval.

Automatic Cloudify-specific Puppet/facter facts

This section applies to both Puppet agent and Puppet standalone.

To allow integration of Puppet, Cloudify supplies custom facts to Puppet to allow decisions based on Cloudify’s information such as properties of the Cloudify node and current operation.

Passing Cloudify-specific tags

There are several methods to pass tags to Puppet. The methods are described below and are additive (Puppet gets all of the tags generated by all of the methods). Example combining all of the methods is shown below.

Pass given list of tags

Tags specified under properties > puppet_config > tags (list) are passed to Puppet.

Operation specific cloudify_operation_OPNAME tag

If properties > puppet_config > add_operation_tag is specified and has a boolean value that is equal to true (true, “yes”, 1) a tag cloudify_operation_OPNAME is passed to Puppet. OPNAME is the short name of Cloudify’s lifecycle operation, for example start, stop, etc.

Per operation set of tags

If properties > puppet_config > operations_tags hash is specified, it is being looked up in the current operation. If found, current-operation-specific tags are passed to Puppet. Each value of the operations_tags hash can be either a tag (string) or a list of tags (list of strings).

Tags passing example

  
imports:
  - http://getcloudify.org/spec/puppet-plugin/1.2/plugin.yaml
node_templates:
  example_web_server:
    type: cloudify.puppet.nodes.WebServer
    properties:
      puppet_config:
        server: puppet.example.com
        environment: myenv
        tags:
          - tag1
          - tag2
        add_operation_tag: true
        operations_tags:
          start: my_start_tag
          stop:
            - my_stop_tag1
            - my_stop_tag2
  

Cloudify-specific facts for all operations:

  • cloudify_node_id - The node instance id for which Puppet is run
  • cloudify_node_name - The node name for which Puppet is run
  • cloudify_blueprint_id - The blueprint id
  • cloudify_deployment_id - The deployment id
  • cloudify_properties_* - Properties of the node for which Puppet is run (see example below)
  • cloudify_runtime_properties_* - Run-time properties of the node for which Puppet is run
  • cloudify_capabilities_* - Run-time properties of related nodes. Example: cloudify_capabilities_db_ip, where db is the node name and ip is the run-time property name.
  • cloudify_host_ip - IP of the host containing the node for which Puppet is run

Cloudify-specific facts for operations involving two nodes:

  • cloudify_related_node_id - The node instance id of the related node
  • cloudify_related_properties_* - Properties of the related node
  • cloudify_related_runtime_properties_* - Run-time properties of the related node
  • cloudify_related_host_ip - IP of the host containing the related node

Node properties as Puppet/facter facts example:

Say the node properties are:

  
node_templates:
  some node:
    type: some_type
    properties:
      some_prop: some_value
      some_map:
        prop1: value1
        prop2: value2
  

The following Puppet/facter facts will be available:

  • cloudify_properties_some_prop
  • cloudify_properties_some_map_prop1
  • cloudify_properties_some_map_prop2

Also see “Standalone-specific integration”

Puppet agent

Runs puppet agent for lifecycle operations. The Puppet agent is run for the start operation and each operation that has per-operation tags defined.

Requirements

  • Existing Puppet server which should be:

Puppet node naming

Puppet node name is used in nodes’ definitions. Node name can be either generated or specified by the user. Description of both alternatives follows:

Note

Generated Puppet node name is the default alternate. It’s used unless node_name_value is specified.

Generated Puppet node name

Puppet node name is constructed by concatenation of node_name_prefix, node id and node_name_suffix. Both node_name_prefix and node_name_suffix are optional and default to empty strings. Since node id is not guaranteed to follow a convention, you should use node_name_prefix and/or node_name_suffix for node definitions.

Sample usage:

  
imports:
  - http://getcloudify.org/spec/puppet-plugin/1.2/plugin.yaml
node_templates:
  example_web_server:
    type: cloudify.puppet.nodes.WebServer
    properties:
      puppet_config:
        server: puppet.example.com
        environment: myenv
        node_name_prefix: myweb-
        node_name_suffix: .example.com
  

User specified Puppet node name

Puppet node name is specified in node_name_value.

Sample usage:

  
imports:
  - http://getcloudify.org/spec/puppet-plugin/1.2/plugin.yaml
node_templates:
  example_web_server:
    type: cloudify.puppet.nodes.WebServer
    properties:
      puppet_config:
        server: puppet.example.com
        environment: myenv
        node_name_value: web1.my.example.com
        certname: web1.my.example.com
  

Puppet agent simple usage example

This is a minimal example of using Puppet agent to install a web server. The node_name_prefix is required in order for Puppet to match the node using node /^myweb.*$/ { ... }.

In absence of per-operation tags, Puppet agent will run only for the start operation.

  
imports:
  - http://getcloudify.org/spec/puppet-plugin/1.2/plugin.yaml

node_templates:
  example_web_server:
    type: cloudify.puppet.nodes.WebServer
    properties:
      puppet_config:
        server: puppet.example.com
        environment: myenv
        node_name_prefix: myweb
  

Puppet standalone

Puppet standalone will install Puppet, Puppet modules and will run per-operation code or manifests.

Puppet manifests location

If you are using manifests, they are placed in $cloudify_local_repo (Puppet/facter fact) directory, currently it’s ~/cloudify/puppet (the user is typically ubuntu and hence the home directory is usually /home/ubuntu).

Puppet modules location

$cloudify_local_repo/modules. This location (among others) is used as --modulepath when running Puppet.

Puppet modules installation

Puppet standalone will install all Puppet modules given under properties > puppet_config > modules prior running any Puppet manifest or Puppet code.

Example:

  
imports:
  - http://getcloudify.org/spec/puppet-plugin/1.2/plugin.yaml

node_templates:
  example_web_server:
    type: cloudify.puppet.nodes.WebServer
    properties:
      puppet_config:
        ...
        modules:
          - puppetlabs-apache
          - puppetlabs-concat
          - puppetlabs-stdlib
          - puppetlabs-vcsrepo
  

Per-operation Puppet manifests or code to execute

Puppet standalone will run Puppet for each operation for which a manifest or Puppet code are given under properties > puppet_config > manifest > OPNAME or properties > puppet_config > manifest > OPNAME.

Below is example showing the usage of per-operation Puppet code. configure operation happens first. Git repository is cloned. During the start operation, my_hello_world class is run.

Per-operation Puppet code example:

  
imports:
  - http://getcloudify.org/spec/puppet-plugin/1.2/plugin.yaml

node_templates:
  example_web_server:
    type: cloudify.puppet.nodes.WebServer
    properties:
      puppet_config:
        modules:
          ...
          - puppetlabs-vcsrepo
        execute:
          configure: |
            package{'git':}
            ->
            vcsrepo{$cloudify_local_repo:
              ensure => present,
              provider => git,
              source   => 'https://github.com/example-com/our-manifests.git',
            }
          start: |
            class{'my_hello_world':
            }

  

Providing manifests for Puppet standalone

There are three alternatives for providing manifests.

Details for the above options follow. Note that you don’t have to provide manifests, you can provide Puppet code directly in the manifest under properties > puppet_config > OPNAME > execute, see the example in Per-operation Puppet manifests or code to execute.

Use Puppet code to fetch the manifests

See the example in Per-operation Puppet manifests or code to execute

Download Puppet manifests from a URL

The URL must point to a .tar.gz file. It’s contents are extracted to the $cloudify_local_repo directory.

Specify your URL under properties > puppet_config > download.

Example:

  
imports:
  - http://getcloudify.org/spec/puppet-plugin/1.2/plugin.yaml

node_templates:
  example_web_server:
    type: cloudify.puppet.nodes.WebServer
    properties:
      puppet_config:
        download: http://manifests.example.com/
        manifest:
          start: manifests/site.pp
        ...

  

Embed Puppet manifests in the blueprint

The blueprint must contain a .tar.gz file. It’s contents are extracted to the $cloudify_local_repo directory.

Specify your file path under properties > puppet_config > download. The / points to the blueprint directory.

Example:

  
imports:
  - http://getcloudify.org/spec/puppet-plugin/1.2/plugin.yaml

node_templates:
  example_web_server:
    type: cloudify.types.puppet.web_server
    properties:
      puppet_config:
        download: /path/to/manifests.tgz
        manifest:
          start: manifests/site.pp
        ...