PUPPET on Amazon EC2 (UBUNTU Machines)

PUPPET on Amazon EC2 (UBUNTU Machines)
Introduction:
Puppet is a system for automating system administration tasks. In the Puppet world, you define a policy (called a manifest) that describes the end state of your systems, and the Puppet software takes care of making sure the system meets that end state. If a file changes, it is replaced with a pristine copy. If a required package is removed, it is re-installed.
The Puppet system is split into two parts: a central server and the clients. The server runs a demon called puppetmaster. The clients run puppetd, which both connects to, and receives connections from, the puppetmaster. The manifest is written on the puppetmaster. If Puppet is used to manage the central server, it also runs the puppetd client.
                                                                                                                                      
Prerequisite:   Before we proceed we need to have few settings in place.
  • Enable ICMP on security group in which the client and server reside, so that ec2 instances can communicate/ reply to ping request. This is major requirement in troubleshooting while configuring.
  • In order for the puppet server and the puppet client(s) to be able to communicate you should ensure that port 8140 is open between the systems.
  • Domain names- Prior to configuring puppet you may want to add a DNS record for puppet master and for puppet client So that can communicate with each other.
 In current minimal setup we are not using any DNS server. Instead we used /etc/hosts file to map hostname of client and server of Puppet
Below is the snippet of /etc/hosts file on both client and server
ubuntu@ip-10-205-2-127:~$ cat /etc/hosts
127.0.0.1 localhost
10.205.2.127 puppet.juned.com puppet
10.245.74.141 clinet.juned.com client
# The following lines are desirable for IPv6 capable hosts
#::1 ip6-localhost ip6-loopback
#fe00::0 ip6-localnet
#ff00::0 ip6-mcastprefix
#ff02::1 ip6-allnodes
#ff02::2 ip6-allrouters
#ff02::3 ip6-allhosts


Puppet Server Installation and configuration:
Install puppet master
apt-get install puppetmaster
Create Your Site Manifest file :
Puppet will start with /etc/puppet/manifests/site.pp as the primary manifest, so create /etc/puppet/manifests and add your manifest, along with any files it includes, to that directory. It is highly recommended that you use some form of version control (git, svn, etc) to keep track of changes to manifests.
Example Manifest file,
package {
‘apache2’:
ensure => installed
}
service {
‘apache2’:
ensure => true,
enable => true,
require => Package[‘apache2’]
}
Next, create a node file /etc/puppet/manifests/nodes.pp with:
node ‘ clinet.juned.com ‘ {
include apache2
}
And now restart the puppet master
/etc/init.d/puppetmaster restart
Puppet Client (node) Installation and configuration:
apt-get install puppet
First, configure the puppet agent daemon to start. Edit /etc/default/puppet, changing START to
yes:
and now start the puppet client.
/etc/init.d/puppet start
Now Edit file /etc/puppet/puppet.conf
Add line server= puppet.juned.com


Verifying Installation
Once Puppet is installed on that machine, run the agent against the central server to verify that everything is working appropriately. You should start the agent in verbose mode the first time and with the –waitforcert flag enabled:
Run this command from client node,
puppetd –server  puppet.juned.com –waitforcert 60 –test
 On your server, list the waiting certificates
puppetca –list
You should see the name of the test agent node. Now go ahead and sign the certificate, then sign the certificate.
puppetca –sign  ip-10-245-74-141
That Request is accepted by puppet master and you can verify that on client end apche2 package is going to install you can also verify it by using tail –f /var/log/syslog


Pros and Cons of Puppet:
Pros:
1.       Automation of System Administration:  
Puppet lets you perform normal administrative tasks (such as adding users, installing packages, and updating server configurations) by saving you countless hours of frustration, monotony, and/or reinventing the wheel on any number of systems, even if those systems are running completely different operating system.
2.       Security:
·         Thorough security model (each client has its own SSL cert) Puppet comes with tools to make basic SSL setup and cert generation very painless (puppetca)
·         Each client only gets to see the part of the site config that applies to it, not the whole site config
·         Builtin file server where file access can be secured per-client (e.g. only hostX gets access to hostX/ssh_host_key)
3.       Cross Platform:
works on most flavors of Unix/Linux (Fedora/RHEL/Debian/Gentoo, Solaris, OS X, some sort of *BSD)
4.       Domain-specific language for manifest :
·         Clean abstraction from messy details of changing config
·         Describe desired config of system, puppet figures out how to get there (e.g., you say ‘need user X with homedir /foo and uid N’, puppet figures out appropriate calls to useradd/usermod depending on whether user exists and fixes attributes that are out of sync)
·         Abstraction: describe config in high-level terms (user, service, package, mount) for common config objects
·         Templating support for things that can’t/don’t need to be described as objects; or distribute complete files
·         Group config items logically with classes: can describe that a webserver has to have latest httpd package, service httpd enabled and running, and custom httpd.conf file from location X (that’s not possible with at least one of the other config mgmt tools)
·         Override mechanism for classes to allow for simple one-off (or hundred-off) tweaks, e.g. to take webserver class from above but use with different httpd.conf * Clean definition of what inputs can influence a client’s config
5.       Emphasis on practical usability, not research.
6.       Cron-like support for scheduling tasks.
7.       Tie-in with kickstart: provision basic system with ks (including puppet client), complete config with puppet.
8.       Strong community support
9.       Open source and free software
Cons:
1.       All sysadmins are not programmer:
                Ruby programming language is puppet’s implementation language and we sysadmins are not familiar with Ruby.
2.       Puppet has its own language for configuration purpose and that one need to learn to configure puppet.              
3.       Puppet is a new software so not sure about count of servers and workstations efficiently managed by puppet.