About

Puppet (software)

https://en.wikipedia.org/wiki/Puppet_(software)

https://github.com/puppetlabs/puppet

https://puppet.com

Overview

Puppet is designed to manage the configuration of Unix-like and Microsoft Windows systems declaratively. The user describes system resources and their state, either using Puppet's declarative language or a Ruby DSL (domain-specific language). This information is stored in files called "Puppet manifests". Puppet discovers the system information via a utility called Facter, and compiles the Puppet manifests into a system-specific catalog containing resources and resource dependency, which are applied against the target systems. Any actions taken by Puppet are then reported.

Puppet consists of a custom declarative language to describe system configuration, which can be either applied directly on the system, or compiled into a catalog and distributed to the target system via client–server paradigm (using a REST API), and the agent uses system specific providers to enforce the resource specified in the manifests. The resource abstraction layer enables administrators to describe the configuration in high-level terms, such as users, services and packages without the need to specify OS specific commands (such as rpm, yum, apt).

Puppet is model-driven, requiring limited programming knowledge to use.

Puppet comes in two flavors, Puppet Enterprise and Open Source Puppet. In addition to providing functionalities of Open Source Puppet, Puppet Enterprise also provides GUI, API and command line tools for node management.

Architecture

Puppet usually follows client-server architecture. The client is known as agent and the server is known as master. It can also be used as a stand-alone application.

Puppet Master is installed on one or more servers and the systems that need to be configured install Puppet Agent. Puppet Agents communicate with the server and fetch configuration instructions. The Agent then applies the configuration on the system and sends the status report to the server. Devices can run Puppet Agent as a daemon, that can be triggered periodically as a cron job or can be run manually whenever needed.

Puppet architecture consists of:

Configuration language: In Puppet, items to be configured are termed as ‘resources’. Since Puppet follows declarative language, it just needs to specify ‘what’ action needs to be performed on the resources. The action is implemented by declaring three things for every resource: its type, title and a list of attributes whose state needs to be configured. Puppet code is written into files called Manifests. These are stored on the server and contain configuration instructions for each client.[6] The format for writing manifest files is stated below.

type { 'title':
  attribute => value
}

Example:

user { 'harry':
  ensure => present,
  uid    => '1000',
  shell  => '/bin/bash',
  home   => '/var/tmp'
}

Resource abstraction: Puppet provides resource abstraction by providing the ability to configure resources on different platforms without worrying about the platform dependencies. For example, if an user wants to install a package on three different platforms then they don't have to worry about the required package type of given platform and its dependencies, Puppet takes care of it by using Facter. Facter is the piece of information which agents provide to the server describing what kind of operating system is being used, their IP, hostname, etc. Indirectly, it is a way of informing Puppet as to what procedure needs to be followed for software configuration in its case; depending on the facts being rendered by Facter. For any given type of resource, there are a number of providers. Providers have package management tools corresponding to different platforms/operating systems. These providers define how resources have to be managed.

Transaction: Following are the steps of execution:

1. Every agent send across Facter to master.
2. Puppet maintains a graphical representation of the list of resources and their interdependencies; depicting the order in which they need to be configured in a ‘catalog’ for every client. Master sends this catalog to the client.
3. Configuration already present on the system is known as actual state and the configuration mentioned in manifest file is known as desired state. Agent applies configuration on the system only when actual state is not same as desired state. The clause of applying a state change only if needed is called as ‘idempotency’, which is the key feature of Puppet.
4. The result of the applying the configuration is sent across to the server.

(source: Wikipedia)