To use Puppet more efficiently, you need to understand how modules and manifests are built. This tutorial will walk you through how these Puppet components work by setting up a LAMP stack on an Ubuntu 14.04 server.
Requirements
- Installing Puppet (master and agent). More about it -.
- Ability to create at least one Ubuntu 14.04 virtual server to serve the Puppet agent node.
Puppet code basics
Resources
Puppet code is mostly made up of resources. A resource is a piece of code that describes the state of the system and determines the changes it needs. For instance:
user ("mitchell":
ensure => present,
uid => "1000",
gid => "1000",
shell => "/ bin / bash",
home => "/ home / mitchell"
}
A resource declaration has the following format:
resource_type ("resource_name"
attribute => value
...
}
To view all types of Puppet resources, enter the command:
puppet resource --types
You will learn more about resource types in this guide.
Manifestos
A manifest is an orchestration script. Puppet programs with the .pp extension are called manifests. The default Puppet manifest is /etc/puppet/manifests/site.pp.
Classes
As with any conventional programming language, classes are responsible for organizing and reusing parts of an orchestration.
The class definition contains a block of code that describes how the class works. Once you define a class, you can use it in your manifests.
The class definition has the following format:
class example_class (
...
code
...
}
This code defines the class example_class. The Puppet code will be in curly braces.
A class declaration is where a particular class is called in your code. By declaring a class, Puppet processes its code.
A class declaration can be ordinary and by the type of resource.
A regular class declaration is added to the code using the include keyword.
include example_class
When declared by resource type, the class is declared in the resource format:
class ("example_class":)
This declaration allows you to add class parameters to your code that override the standard class attribute values. For instance:
node "host2" (
class ("apache":) # use apache module
apache :: vhost ("example.com": # define vhost resource
port => "80",
docroot => "/ var / www / html"
}
}
Modules
A module is a group of manifests and other files organized in a predefined way that makes it easier to share and reuse separate parts of the orchestration. Modules help you organize your Puppet code because you can use them to split your code into multiple manifests.
Puppet modules are stored in the / etc / puppet / modules directory.
Writing a manifest
You can practice writing manifests, modules and Puppet classes using the example of installing a LAMP stack on an Ubuntu server (as a result).
So, in order to orchestrate an Ubuntu 14.04 server and install a LAMP stack on it, you need resources to do things like this:
- installing the apache2 package.
- starting the apache2 service.
- installing the MySQL server package, mysql-server.
- starting the mysql service.
- php5 package installation
- creating a PHP test script, info.php.
- updating the apt index before installing each package.
Below you will find three Puppet code examples with which you can get such a LAMP stack setup.
The first example will teach you how to write basic manifests in one file. The second example will help you build and use a class and module based on previously written manifests. In the third example, you will learn how to use prebuilt public modules to install a LAMP stack.
Note: Better to use a fresh virtual server for testing.
Example 1: Installing LAMP with a Single Manifest
The Puppet manifest can be written on the agent node and then executed using the puppet apply command (you don't need to have a wizard and agent installation for this).
In this section, you will learn how to write manifests that use these types of resource declarations:
- exec: Execute commands.
- package: install packages.
- service: service management.
- file: file management.
Creating a manifest
Create a new manifest:
sudo vi /etc/puppet/manifests/lamp.pp
Add the following code to it to declare the required resources.
# running the command "apt-get update"
exec ("apt-update": # exec resource "apt-update"
command => "/ usr / bin / apt-get update" # command that will run this resource
}
# installing the apache2 package
package ("apache2":
require => Exec ["apt-update"], # request "apt-update" before installing the package
ensure => installed,
}
# start the apache2 service
service ("apache2":
ensure => running,
}
# installing mysql-server
package ("mysql-server":
require => Exec ["apt-update"], # request "apt-update" before installing
ensure => installed,
}
# start the mysql service
service ("mysql":
ensure => running,
}
# installing php5 package
package ("php5":
require => Exec ["apt-update"], # request "apt-update" before installing
ensure => installed,
}
# start service info.php
file ("/var/www/html/info.php":
ensure => file,
content => "", # phpinfo code
require => Package ["apache2"], # request for package "apache2"
}
Applying a manifest
To use the new manifest, enter the command:
sudo puppet apply --test
It will output a volumetric result that displays all changes in the state of the environment. If there are no errors in the output, you should be able to open your external IP address or domain name in a browser. A PHP test page with stack information appears on the screen. This means Apache and PHP are working.
The LAMP stack is now installed on the server using Puppet.
This is a fairly simple manifest as it can be executed on the agent. If you do not have a Puppet master, other agent nodes will not be able to use this manifest.
The Puppet master server checks for server state changes every 30 minutes.
Example 2: Installing a LAMP Stack Using a Module
Now try creating a simple module based on the LAMP manifest you wrote in the previous section.
To create a module, create a new directory in the modules directory (its name must match the module name). This directory should contain the manifests directory and the init.pp file. The init.pp file specifies the Puppet class (its name must also match the module name).
Module creation
Go to the Puppet master server and create a directory structure for the module:
cd / etc / puppet / modules
sudo mkdir -p lamp / manifests
Create and open the init.pp file in the editor:
sudo vi lamp / manifests / init.pp
Insert the lamp class into the file:
class lamp (
}
Copy the content of the manifest from section 1 and paste it into the lamp class block. You now have a definition for the class lamp. Other manifests will be able to use this class as a module.
Save and close the file.
Using a module in the main manifest
You can now set up the main manifest and use the lamp module to install the LAMP stack on the server.
On the Puppet master server, edit the following file:
sudo vi /etc/puppet/manifests/site.pp
Most likely, the file is empty at the moment. Add the following lines to it:
node default ()
node "lamp-1" (
}
Note: Replace lamp-1 with the hostname of your Puppet agent where you want to install the stack.
The node block allows you to specify Puppet code that will only apply to some nodes.
The default block applies to all agent nodes that do not have an individual block (leave it blank). The lamp-1 block will be applied to the lamp-1 agent node.
Add the following line to this block, which uses the lamp module:
Save and close the file.
The Puppet agent node will now be able to download the settings from the master server and install the LAMP stack. If you want to make changes right now, run the command on the agent:
sudo puppet agent --test
Modules are the most convenient way to reuse Puppet code. In addition, modules help you organize your code logically.
Example 3: Installing LAMP Using Publicly Available Modules
The MySQL module is used in a similar way. Add the following lines to the node block:
class ("mysql :: server":
root_password => "password",
}
You can also pass parameters to a MySQL module.
Add a resource that will copy info.php to the correct location. Use the source parameter. Add the following lines to the node block:
file ("info.php": # resource file name
path => "/var/www/html/info.php", # target path
ensure => file,
require => Class ["apache"], # the apache class to use
source => "puppet: ///modules/apache/info.php", # where you want to copy the file
}
This class declaration uses the source parameter instead of the content parameter. This option not only uses the content of the file, but also copies it.
Puppet file: ///modules/apache/info.php Puppet will copy to /etc/puppet/modules/apache/files/info.php.
Save and close the file.
Create info.php file.
sudo sh -c "echo""> /etc/puppet/modules/apache/files/info.php"
The Puppet agent node will now be able to download the settings from the master server and install the LAMP stack. If you want to make changes to the agent environment right now, run the command on this node:
sudo puppet agent --test
This command will download all updates for the current node and install the stack on it. To verify that Apache and PHP are working, open the IP address or domain of the node in a browser:
http: //lamp_1_public_IP/info.php
Conclusion
You now have basic knowledge of Puppet modules and manifests. Try to create a simple manifest and module yourself.
Puppet is great for managing application config files.
Tags:,Not so long ago, on the pages of the magazine, we examined the Cfengine system of remote configuration management for UNIX machines, which greatly simplifies the life of a system administrator by automating actions to configure many network nodes. But as convenient as Cfengine is, it has a lot of disadvantages that a system called Puppet lacks.
Imagine yourself in the role of a system administrator, responsible for maintaining the health of hundreds of other machines running operating systems such as UNIX. Each of them requires configuration, periodic updating and monitoring, and it is assumed that many of them perform similar functions.
Two-thirds are workstations, a few more are routers, and the rest are multiple web servers and data stores. The question is: how to manage this entire economy? The simplest answer is to simply connect to each of them using SSH and make the necessary changes. However, this method has two problems. First, it is very time consuming. Secondly, the administrator will constantly have to perform many monotonous actions (for example, to update OpenOffice.org on all workstations, he will have to execute the same commands several dozen times). You can try to avoid this problem by writing several scripts that will themselves connect to each machine and execute pre-written commands. But here, too, problems await you.
The scripts will have to be constantly modified in order to adjust them for each task; scripts will have to take into account the difference in operating systems and versions, and will have to be debugged for a long time before being applied to running machines. In general, not comme il faut. The correct answer is to use so-called remote configuration management systems, the most famous of which are open systems Cfengine and Puppet. Such systems assume all responsibilities for bringing the machine configuration to the right kind, requiring from the administrator only a description of the final state of the system in a special language (for example, a description of which packages should be installed in the OS, which lines should be added to the configuration files, which commands should be executed, etc.). After that, all nodes themselves will receive information about the required state from the server and will autoconfigure the system. Thanks to this mechanism, new machines can be completely tuned without human intervention, and existing ones can be reconfigured with just a few lines of state descriptions.
Puppet?
We have already devoted an entire article to the Cfengine system, so today we will focus on the Puppet system, which can quite be called its ideological follower. Puppet was developed by Luke Kanies, who grew tired of the limitations of Cfengine and decided to create a better version from scratch. If you've used Cfenfine before, you'll probably find Puppet a more convenient and powerful system. The Puppet state description language is more high-level and flexible, so that the administrator does not need to worry about such things as writing separate rules for each type of OS or detailed descriptions of trivial actions. Puppet allows its master to focus on what he wants to do, instead of how to do it (for example, to install a certain package on any of the OS supported by the system, it is enough to write literally a few lines saying "Install this program", instead of describing the commands, required to install it). Puppet is written in simple language Ruby, thanks to which it is quite easy to customize it for a specific task and expand its functionality (a flexible system of plugins is provided).
In addition, unlike the Cfengine development model, which actually revolves around one person, a large community of enthusiasts has formed around Puppet who contribute to the code, share configuration examples and write documentation.
In general, Puppet appears to be a more modern and well-designed system. Like Cfengine, it supports almost all modern UNIX-like operating systems (including MacOS X) and can also run in Cygwin on top of Windows. The list of its dependencies includes only the Ruby interpreter and the Factor tool, so there should be no problems with installation (it is fair to say that the list of Cfengine dependencies is even shorter).
Installation
Like Cfengne, Puppet is a client-server system that consists of a control server and slave nodes. The server stores a description of the final states of the nodes (which is called a manifest in Puppet terms) and waits for them to connect. Every half hour (by default) the client connects to the server, receives a description of the final state from it, verifies it with the current one and, if it and / or the described state has changed, reconfigures the system, and then goes to sleep. Communication is carried out through an encrypted channel, so attacks based on spoofing the state description are excluded (but if an attacker takes over the server, then all nodes will be under his control).
Puppet is included in the repositories of all popular distributions, so installation should be straightforward. For example, on Debian / Ubuntu, the Puppet client can be installed like this:
$ sudo apt-get install puppet
And the server is like this:
$ sudo apt-get install puppet puppetmaster
Client and server configuration files are stored in the / etc / puppet directory. The most important of these is the /etc/puppet/manifests/site.pp file, which contains the manifest.
It stores a description of the states and should only exist on the server. For the convenience of debugging, let's add the simplest configuration to it:
class passwd (
file ("/ etc / passwd":
owner => root,
group => root,
mode => 644,
}
}
node default (
include passwd
}
These lines describe the state that the / etc / passwd file must be owned by root and have permissions set to 644. In the next section, we'll take a closer look at the manifest file format. The second most important file is /etc/puppet/puppet.conf. It sets the configuration of the server and clients, therefore it must be present on all machines organized in the Puppet network. On Ubuntu, this file contains the minimum required and in most cases sufficient settings. Below they are with comments:
# vi /etc/puppet/puppet.conf
# Standard paths to directories
logdir = / var / log / puppet
vardir = / var / lib / puppet
ssldir = / var / lib / puppet / ssl
rundir = / var / run / puppet
# Facter tool location,
# used to get information about the OS
factpath = $ vardir / lib / facter
# Synchronize plugins
# (installed plugins on the server - they are copied to clients)
pluginsync = true
# Catalog with templates (read about them below)
templatedir = $ confdir / templates
# Synchronization with etckeeper
# (who knows - he will understand, the rest do not need)
prerun_command = / etc / puppet / etckeeper-commitpre
postrun_command = / etc / puppet / etckeeper-commitpost
The config file may include a large number of various options, information about which can be obtained by generating the default config:
$ sudo puppetmasterd -genconfig> / etc / puppet /
puppetd.conf.default
The default client config is generated using another command:
$ sudo puppet -genconfig> /etc/puppet/puppetd.conf.default
The fileserver.conf and auth.conf files are used to configure file server(read about this in the "File Server" section) and authentication. There is no point in touching them yet. After completing the configuration, the Puppet server needs to be restarted:
$ sudo /etc/init.d/puppetmaster restart
Then he will be ready to accept customer requests. However, without a signed certificate, no client can get the manifest from the server and configure the machine.
Therefore, we must run Puppet clients in test mode so that they can transfer their certificates to the server for signing (by the way, this can be done simultaneously on all machines using the shmux tool):
$ sudo puppetd -server puppet-server.com -verbose -test
We return to the server and get a list of certificates ready for signing:
$ sudo puppetca --list
Select a host from the list and sign its certificate:
$ sudo puppetca --sign nomad.grinder.com
Or we sign everything at once:
$ sudo puppetca --sign --all
Clients can now be launched in combat mode. But first you need to register the name of the Puppet server in config file(by default its name is just puppet):
$ sudo su
# echo "" >> /etc/puppet/puppet.conf
# echo "server = puppet-server.com" >> /etc/puppet/puppet.conf
# exit
We launch clients:
$ sudo /etc/init.d/puppet start
State description language
As mentioned above, Puppet uses its own end state description language. operating system, with the help of which the sysadmin specifies what kind of OS components should be brought to in order for it to reach the desired state. It is a rather complex language, which, nevertheless, is much simpler than any programming language. If you are at least superficially familiar with the bash scripting language, then you can easily understand the Puppet language. The key element of the language is the resources, with the help of which there is a description of the form to which one of the OS components should be reduced. For example, the following simple resource describes the desired state of the / etc / passwd file:
# vi /etc/puppet/manifests/site.pp
file ("/ etc / passwd":
owner => "root"
}
Here file is the resource type. There are several dozen of them in total, ranging from resources that manage files, as in this example, to packages and services. The line / etc / passwd is the name of the resource.
In the case of the file type, the name is the same as the path to the file, however, in some other types, the name can be arbitrary. The line owner => "root" describes setting the owner attribute to root, that is, it says that the owner the specified file there must be an administrator.
Each type of resource has its own set of attributes available for modification, plus there are special meta-attributes that can be used in any resource. One of the important qualities of resources is the ability to link to them. This can be used to form dependency chains. The following entry creates a resource / etc / group that depends on the resource / etc / passwd (dependencies are specified using the require meta-attribute):
# vi /etc/puppet/manifests/site.pp
file ("/ etc / group":
require => File ["/ etc / passwd"],
owner => "root",
}
This means that the / etc / group resource can be configured (reduced to the described form) only when the / etc / passwd resource is configured. Resources can be grouped into resource collections called classes. This is necessary in order to combine resources similar in meaning and type of task performed into one abstract resource. For example, for convenience, we could combine the installation and launch of the nginx web server into one abstract resource of the same name:
# vi /etc/puppet/manifests/site.pp
class nginx (
package ("nginx":
ensure => installed
}
service ("nginx":
ensure => running,
require => Package ["nginx"],
}
}
Here, the package resource type is used to install the nginx package into the system, and service is used to start the service of the same name. With require, we force the system to start the service only if the package has been successfully installed. The convenience of classes is that they can also be included depending on:
# vi /etc/puppet/manifests/site.pp
service ("squid":
ensure => running,
require => Class ["nginx"],
}
As in real OOP languages, classes can inherit from each other and override attributes:
# vi /etc/puppet/manifests/site.pp
class passwd (
file ("/ etc / passwd":
owner => "root",
group => "root",
}
}
class passwd-bsd inherits passwd (
File ["/ etc / passwd"] (group => "wheel")
}
Here the passwd-bsd class is inherited from passwd in order to override the group attribute of the / etc / passwd resource (on BSD systems, / etc / passwd belongs to the wheel group, so we created a separate class for such systems). Later, we will look at a more correct and obvious way to select alternative attribute values using conditions.
Variables are one of the essential components of any programming language, and Puppet has them too. Variables start with a $ sign and can contain any number, string, or boolean value (true, false):
$ want_apache = true
$ apache_version = "2.2.14"
One of the most powerful variable properties of Puppet is its integration with the facter machine information tool. This utility returns all machine-specific information in the form of key-value pairs, which are converted into variables of the same name in Puppet. Together with Puppet conditional statements, they can be used to alter resource attributes depending on the properties of the machine.
For example, the passwd class described above can be easily rewritten to automatically select an attribute depending on the OS type (and the class itself is no longer needed):
# vi /etc/puppet/manifests/site.pp
file ("/ etc / passwd":
owner => "root",
group => $ kernel? (
Linux => "root",
FreeBSD => "wheel",
},
}
Depending on which OS this fragment of the manifest will be parsed on, the value of the group attribute will be either root or wheel. In addition to the conditional operator, Puppet also supports the case selection operator, which can be used to create a particular resource depending on the value of a variable:
# vi /etc/puppet/manifests/site.pp
case $ operatingsystem (
redhat: (service ("httpd": ensure => running))
debian: (service ("apache": ensure => running))
default: (service ("apache2": ensure =>
running))
}
This code defines various options for a resource of type service, depending on the operating system (the names of services in different Linux distributions may differ, therefore, which service should start Puppet, you must specify individually for each of them).
The default option is used if the value of the variable does not match any of the previous options. In addition to the file, package and service resource types already discussed earlier, Puppet supports a large number of others, including those created third party developers resource types. You can find a detailed description of them, including examples, supported attributes and features, in the official documentation - http://docs.puppetlabs.com/references/stable/type.html. Below is a list and a short description of the most used ones:
Popular Puppet Resource Types
- cron - managing cron jobs
- exec - run scripts and commands
- file - file management
- filebucket - backup files
- group - group management
- host - manage entries in the / etc / hosts file
- interface - configuring network interfaces
- mount - mount filesystems
- notify - send a message to the Puppet log file
- package - package management
- service - service management
- sshkey - SSH key management
- tidy - delete files depending on conditions
- user - user management
- zones - manage Solaris zones
The second most important element of the Puppet language after resources is nodes. With their help, the administrator can describe to which machines certain resources and classes should be applied. In other words, it is a way to specify an individual configuration for each of the machines participating in the Puppet network. The simplest example of a node is given at the beginning of the article in the "Installation" section:
# vi /etc/puppet/manifests/site.pp
node default (
include passwd
}
This is the definition of a default node that includes the passwd resource / class. The name default means "all other nodes", so the passwd resource / class defined somewhere above will be configured on each of them. Keyword include is used here for convenience, in fact, all classes and resources can be described directly in the node description, but this is not recommended. In addition to default, the host name can contain network name machines (then all resources described in the node will be configured only on this machine), or an arbitrary name (then this node can be inherited by another node). To understand how all this works in conjunction with classes and resources, consider an example of a ready-made Puppet manifest used to configure two networked machines (a web server and an NTP server):
# vi /etc/puppet/manifests/site.pp
# Install and run SSH server
class sshd (
package (openssh-server: ensure => installed)
service (sshd:
name => $ operatingsystem? (
fedora => "sshd",
debian => "ssh",
default => "sshd",
},
enable => true,
ensure => running,
}
}
# Installing and running Apache
class httpd (
package (httpd: ensure => installed)
service (httpd:
enable => true,
ensure => running,
}
}
# Installing and running the NTP server
class ntpd (
package (ntp-server: ensure => installed)
service (
ntp-server:
enable => true,
ensure => running,
}
}
# Base node, used only as parent of all others
node base (
include sshd
}
# The host where the web server will be located
node web.server.com inherits base (
inlude httpd
}
# NTP server host
node ntp.server.com inherits base (
include ntpd
}
This seemingly simple configuration does a lot: it installs and starts Apache on the machine with the web.server.com address and installs and starts the NTP server on the machine. ntp.server.com... Additionally, both machines install an SSH server. This configuration is unlikely to suit even one administrator; it will have to be seriously modified in order to teach how to properly configure the servers, receive fresh configs and other files from the main Puppet server.
However, it clearly shows the power of Puppet. With the help of a simple config, we made it so that the machines themselves install and run the necessary software and maintain it in working order (if the server crashes, Puppet will reconfigure itself to bring the systems to the required state).
File Server
Many remote administration tasks cannot be accomplished without copying additional files to the machines. These can be pre-configured configs, web pages for Apache, packages that are not in the official repository, and much more. To facilitate the process of transferring these files to remote sites, Puppet includes a file server.
The file server settings are stored in the /etc/puppet/fileserver.conf file. To force Puppet to serve the contents of a specific directory to clients, you need to put several lines in it:
# vi /etc/puppet/fileserver.conf
path = / var / puppet / files
allow * .server.com
These two lines indicate that the / var / puppet / files directory should be accessible to all hosts in the server.com domain. In addition, we can specify the fully qualified domain name of the allowed machine or its IP address, as well as cut off the unwanted ones using the deny directive. After that, any file in this directory can be moved to the client using the file resource. For instance:
# vi /etc/puppet/manifests/site.pp
file ("/etc/httpd/conf/httpd.conf":
source => "puppet: //httpd/httpd.conf",
mode => 644,
}
The httpd.conf file located on the server in the / var / puppet / files / httpd directory will be copied to the target machine using the path specified in the resource name.
conclusions
In this article, we have covered a very small part of Puppet's capabilities. In fact, this is a complex system that can only be fully described on the pages of a book. At the same time, Puppet is very easy to configure and maintain, especially since you can find a lot of examples of its configuration on the Web.
Info
- Puppet uses the HTTP protocol, so it can be run under the control of a web server to improve performance.
- Puppet can be used to autoconfigure and maintain a single local machine.
- By combining Puppet, network installation OS (pxe-install) and self-built installation images, you can create a completely self-configuring network of machines, which can be deployed with just one command.
- Puppet is used in their work by many large companies, such as Google, Fedora Project, Stanford University, Red Hat, Siemens IT Solution and SugarCRM.
Links
- http://docs.puppetlabs.com - Puppet Documentation
- http://docs.puppetlabs.com/guides/language_tutorial.html - Full description of the Puppet language
- http://docs.puppetlabs.com/references/stable/type.html - Resource Types
Some time ago, the list of servers in my bookmarks exceeded 200. As the number of servers increases, deploying any new configuration or installing new packages is wasting a huge amount of time. So I decided to use puppet.
Puppet(English puppet) is a cross-platform client-server application that allows you to centrally manage the configuration of operating systems and programs installed on multiple computers. Puppet is written in the Ruby programming language.
Puppet is also said to be a remote configuration management system, most notably the open source systems Cfengine and Puppet.
After reading the reviews, I decided to use puppet.
Puppet server installation and configuration:
Installing the puppet server:
Install puppet-server on OpenSuSE 11.4:
zypper in puppet-server
Change the server name to puppet:
/ etc / HOSTNAME:
DNS record should resolve to 127.0.0.2
cat / etc / hosts:
127.0.0.2 puppet.site puppet
Give rights for the user puppet:
Let's start the Puppet Master service:
rcpuppetmasterd start
Let's add the start of the puppet daemon to autoload:
chkconfig -a puppetmasterd
Configuring a puppet server:
Let's define a directory where files will be stored that puppet-server will transfer to client machines in manifests of the file type.
vim / etc / puppet / fileserver
path / etc / puppet / files
allow *
mkdir / etc / puppet / files
chown -R puppet: puppet / etc / puppet / files
Let's create a file of any content for deployment and testing on clients
touch / etc / puppet / files / puppettesting
Restart the puppet server:
rcpuppetmasterd restart
Puppet uses its own language for describing the final state of the operating system, with the help of which the sysadmin specifies what kind of OS components should be brought to in order for it to reach the desired state. The state can mean the presence of a certain file, folder, running services installed packages, updates and more. All state settings are described in files or manifests, which are located in the directory: / etc / puppet / manifests. These files have names like * .pp.
Let's create the simplest manifesto:
/etc/puppet/manifests/1.file.pp:
file ("/ tmp / puppettesting":
source => "puppet: /// files / puppettesting",
}
To apply this manifest:
puppet apply 1.file.pp
Installing and configuring the puppet client:
zypper in puppet
Let's give puppet rights to the user:
chown -R puppet.puppet / var / lib / puppet /
To establish communication with the puppet-server, the puppet-client sends a request to confirm the certificate, after the server confirms this request, the puppet client will start using the manifests intended for it. We will send a request to confirm the certificate:
On the server, we can see what confirmation requests are pending:
"puppet-client.localdomain" (B5: 12: 69: 63: DE: 19: E9: 75: 32: 2B: AA: 74: 06: F6: 8E: 8A)
We confirm:
puppetca --sign "puppet-client.localdomain"
It's time to consider the simplest examples of creating manifests:
create a file /etc/puppet/manifests/site.pp:
node default (
file ("/ tmp / puppettesting":
source => "puppet: /// files / puppettesting",
}
service ("ntp":
ensure => running,
enable => true,
}
package ("htop":
ensure => installed,
}
}
default - apply to all clients
file - this section says to create or overwrite the file / tmp / puppettesting which is located on the server in the / etc / puppet / files directory
service: check if the service is running, if not started, then start it, and also add it to startup
package: check if the htop package is installed on the client and if not, install it.
To check, run on the client:
As you can see, ntp was added to autoload on the client, the ntp daemon was launched, the htop package was installed, and the puppettesting file was copied to the / tmp / directory
info: Caching catalog for puppet-client.localdomain
info: Applying configuration version "1370163660"
notice: / Stage [main] // Node [default] / Service [ntp] / ensure: ensure changed "stopped" to "running"
notice: / Stage [main] // Node [default] / Package [htop] / ensure: created
notice: / Stage [main] // Node [default] / File [/ tmp / puppettesting] / ensure: defined content as "(md5)"
notice: Finished catalog run in 3.95 seconds
In the next article I will describe more complex examples of creating manifests and the puppet-dashboard web interface.
Popular Puppet Resource Types
cron- cron job management
exec- launching scripts and commands
file- file management
filebucket- file backup
group- group management
host- managing entries in the / etc / hosts file
interface- configuring network interfaces
mount- mounting file systems
notify- sending a message to the Puppet log file
package- package management
service- service management
sshkey- SSH key management
tidy- deleting files depending on conditions
user- user management
zones- Solaris zone management
Puppet is a cross-platform framework that allows system administrators perform common tasks using code. The code allows you to perform a variety of tasks from installing new programs to checking file permissions or updating user accounts. Puppet excellent not only during the initial installation of the system, but also throughout life cycle systems. In most cases puppet used in client / server configuration.
This section shows installation and configuration Puppet in client / server configuration. This simple example demonstrates how to install Apache using Puppet.
Installation
For installation Puppet enter in terminal:
Sudo apt-get install puppetmaster
On the client machine (or machines) enter:
Sudo apt-get install puppet
Customization
Before configuring puppet, you might want to add an entry DNS CNAME for puppet.example.com, where example.com is your domain. Default clients Puppet check DNS for puppet.example.com as the server puppet name ( Puppet master). See Domain Name Service for more details on using DNS.
If you do not intend to use DNS, you can add entries to the / etc / hosts file on the server and client. For example, in the file / etc / hosts Puppet server add:
127.0.0.1 localhost.localdomain localhost puppet 192.168.1.17 meercat02.example.com meercat02
On each Puppet client add an entry for the server:
192.168.1.16 meercat.example.com meercat puppet
Replace IP addresses and domain names from the example to your actual addresses and server and client names.
Now let's set up some resources for apache2... Create a file /etc/puppet/manifests/site.pp containing the following:
Package ("apache2": ensure => installed) service ("apache2": ensure => true, enable => true, require => Package ["apache2"])
Node "meercat02.example.com" (include apache2)
Replace meercat02.example.com to the actual name of your Puppet client.
The final step for this simple Puppet the server is restarting the service:
Sudo /etc/init.d/puppetmaster restart
Now on Puppet everything is configured on the server and it's time to configure the client.
First, let's set up the service Puppet agent to run. Edit / etc / default / puppet replacing the value START on the yes:
Sudo /etc/init.d/puppet start
Back to Puppet server to sign the client certificate using the command:
Sudo puppetca --sign meercat02.example.com
Check / var / log / syslog for any configuration errors. If everything went well, the package apache2 and its dependencies will be installed to Puppet client.
This example is very simple and does not show many features and benefits. Puppet... For additional information look