Puppet-2

Puppet-2

Puppet, from Puppet Labs, is a configuration management tool that helps system administrators automate the provisioning, configuration, and management of a server infrastructure. Planning ahead and using config management tools like Puppet can cut down on time spent repeating basic tasks, and help ensure that your configurations are consistent and accurate across your infrastructure. Once you get the hang of managing your servers with Puppet and other automation tools, you will free up time which can be spent improving other aspects of your overall setup.

Puppet comes in two varieties, Puppet Enterprise and open source Puppet. It runs on most Linux distributions, various UNIX platforms, and Windows.

In this tutorial, we will cover how to install open source Puppet in an Agent/Master setup. This setup consists of a central Puppet Master server, where all of your configuration data will be managed and distributed from, and all your remaining servers will be Puppet Agent nodes, which can be configured by the puppet master server.

Prerequisites

To follow this tutorial, you must have root access to all of the servers that you want to configure Puppet with. You will also be required to create a new Ubuntu 14.04 VPS to act as the Puppet master server. If you do not have an existing infrastructure, feel free to recreate the example infrastructure (described below) by following the prerequisite DNS setup tutorial.

Create Puppet Master Server

Create a new Ubuntu 14.04 x64 VPS, using "puppet" as its hostname. Add its private network to your DNS with the following details:

Hostname	Role	Private FQDN
puppet	Puppet Master	puppet.nyc2.example.com

If you just set up your DNS and are unsure how to add your host to DNS, refer to the Maintaining DNS Records section of the DNS tutorial. Essentially, you need to add an "A" and "PTR" record, and allow the new host to perform recursive queries. Also, ensure that you configure your search domain so your servers can use short hostnames to look up each other.

Using "puppet" as the Puppet master's hostname simplifies the agent setup slightly, because it is the default name that agents will use when attempting to connect to the master.

Now we need to set up NTP.
Install NTP

Because it acts as a certificate authority for agent nodes, the puppet master server must maintain accurate system time to avoid potential problems when it issues agent certificates--certificates can appear to be expired if there are time discrepancies. We will use Network Time Protocol (NTP) for this purpose.

First, do a one-time time synchronization using the ntpdate command:

sudo ntpdate pool.ntp.org

Your system time will be updated, but you need to install the NTP daemon to automatically update the time to minimize time drift. Install it with the following apt command:

sudo apt-get update && sudo apt-get -y install ntp

It is common practice to update the NTP configuration to use "pools zones" that are geographically closer to your NTP server. In a web browser, go to the NTP Pool Project and look up a pool zone that is geographically close the datacenter that you are using. We will go with the United States pool (http://www.pool.ntp.org/zone/us) in our example, because the servers are located in a New York datacenter.

Open ntp.conf for editing:

sudo vi /etc/ntp.conf

Add the time servers from the NTP Pool Project page to the top of the file:

server 0.us.pool.ntp.org
server 1.us.pool.ntp.org
server 2.us.pool.ntp.org
server 3.us.pool.ntp.org

Save and exit. Restart NTP to add the new time servers.

sudo service ntp restart

Now that our server is keeping accurate time, let's install the Puppet master software.

Install Puppet Master

There are a variety of ways to install open source Puppet. We will use the debian package called puppetmaster-passenger, which is provided by Puppet Labs. The puppetmaster-passenger package includes the Puppet master plus production-ready web server (Passenger with Apache), which eliminates a few configuration steps compared to using the basic puppetmaster package.

Download the Puppet Labs package:

cd ~; wget https://apt.puppetlabs.com/puppetlabs-release-trusty.deb


Install the package:

sudo dpkg -i puppetlabs-release-trusty.deb


Update apt's list of available packages:sudo apt-get update

Install the puppetmaster-passenger package:

sudo apt-get install puppetmaster-passenger

The Puppet master, Passenger, Apache, and other required packages are now installed. Because we are using Passenger with Apache, the Puppet master process is controlled by Apache, i.e. it runs when Apache is running.

Puppet

Puppet-1

Puppet is a Configuration Management tool that is used for deploying, configuring and managing servers. There are a couple of different tools that PuppetLabs provides (PuppetDB, Puppet Enterprise, Facter, Hiera), as well as models for using Puppet (client/server, where a server is referred to as a master, and clients check in to gather any updates to configuration and apply them to themselves; also master-less). Finally, there is a robust community of open-source tools around Puppet, such as r10k, and a number of community built modules that can be found on the Puppet Forge.

It performs the following functions: 

Defining distinct configurations for each and every host, and continuously checking and confirming whether the required configuration is in place and is not altered (if altered Puppet will revert back to the required configuration) on the host. 

Dynamic scaling-up and scaling-down of machines. 

Providing control over all your configured machines, so a centralized (master-server or repo-based) change gets propagated to all, automatically.

From the ground up, Puppet is organized as follows:

- Manifests, which contain Puppet code (a Ruby DSL), describing the desired configuration, contents, or execution for files, services, scripts, and other pieces of infrastructure 

- Modules, which group common manifests together to achieve some goal (e.g. an elasticsearch module could be used to install, configure, and start elasticsearch on a node) 

- Nodes, which are the systems to be configured by one or more modules 

- Environments, which are user-defined logical groupings, typically representing different versions of the total body of Puppet code, and typically aligned along SDLC states, like 'qa' or 'production'

At runtime, the Puppet executable applies (runs) the given modules for a particular matching node in the desired environment and prints its progress to stdout; if all goes well, at the end, your node should be configured as your Puppet code describes. 

Puppet code is composed primarily of resource declarations. A resource describes something about the state of the system, such as a certain user or file should exist, or a package should be installed. 

Here is an example of a user resource declaration:

user { 'mitchell':
  ensure     => present,
  uid        => '1000',
  gid        => '1000',
  shell      => '/bin/bash',
  home       => '/home/mitchell'
}

resource_type { 'resource_name'
  attribute => value
  ...
}

Therefore, the previous resource declaration describes a user resource named 'mitchell', with the specified attributes.

To list all of the default resource types that are available to Puppet, enter the following command:

puppet resource --types

We will cover a few more resource types throughout this tutorial.

Manifests

Puppet programs are called manifests. Manifests are composed of puppet code and their filenames use the .pp extension. The default main manifest in Puppet installed via apt is /etc/puppet/manifests/site.pp.

If you have followed the prerequisite Puppet tutorial, you have already written a manifest that creates a file and installs Apache. We will also write a few more in this tutorial.

Classes

In Puppet, classes are code blocks that can be called in a code elsewhere. Using classes allows you reuse Puppet code, and can make reading manifests easier.

Class Definition

A class definition is where the code that composes a class lives. Defining a class makes the class available to be used in manifests, but does not actually evaluate anything.

Here is how a class definition is formatted:

class example_class {
  ...
  code
  ...
}

The above defines a class named "example_class", and the Puppet code would go between the curly braces.

Class Declaration

A class declaration occurs when a class is called in a manifest. A class declaration tells Puppet to evaluate the code within the class. Class declarations come in two different flavors: normal and resource-like.

A normal class declaration occurs when the include keyword is used in Puppet code, like so:

include example_class

This will cause Puppet to evaluate the code in example_class.

A resource-like class declaration occurs when a class is declared like a resource, like so:

class { 'example_class': }

Using resource-like class declarations allows you to specify class parameters, which override the default values of class attributes. If you followed the prerequisite tutorial, you have already used a resource-like class declaration ("apache" class) when you used the PuppetLabs Apache module to install Apache on host2:

node 'host2' {
  class { 'apache': }             # use apache module
  apache::vhost { 'example.com':  # define vhost resource
    port    => '80',
    docroot => '/var/www/html'
  }
}

Now that you know about resources, manifests, and classes, you will want to learn about modules.

Modules

A module is a collection of manifests and data (such as facts, files, and templates), and they have a specific directory structure. Modules are useful for organizing your Puppet code, because they allow you to split your code into multiple manifests. It is considered best practice to use modules to organize almost all of your Puppet manifests.

To add a module to Puppet, place it in the /etc/puppet/modules directory.

If you face any problem while practicing feel free to comment it and Bookmark this blog for quick reference.We will try to help you

Thanks
Devops Desk Team