Perl Cluster Configuration Management System Rex Concise Handbook _perl

Rex is an SSH-linked cluster configuration management system written in Perl that is syntactically similar to the Puppet DSL. Chinese version of the official website see http://rex.perl-china.com. This article is only an introductory document that I have written on the departmental Wiki.

Common Command Parameters

Rex command parameters are many, but because our environment is KRB certified, so some parameters can only be written in Rexfile. So generally fixed in the storage of Rexfile/etc/puppet/webui under the command, a lot of configuration automatically loaded. Then the command parameters that need to be used are basically the following:
-tv: View what task tasks are defined in the current rexfile, and the server groups.
-H: Specifies which Host the Task will execute on. The convenient place here is to support 10.5.16. [95..110] This kind of wording.
-G: Specifies which Group the Task will execute on. Group is defined in a number of ways, with the default support of Rex by the group instructions directly in the Rexfile, through the INI configuration file settings, and so on. I have now implemented a groups_db command to get from our SQLite. groups_db (' Cdnbj::nginx ') automatically generates a server group called ' Cdnbj::nginx ', including all Nginx-deployed servers in CDNBJ.
-E: specifies a temporary task. It is usually a simple command form such as ' say Run ' ipconfig '. If you need complex logic, write a Task in Rexfile.
- Q: Specify run log level with-Q and-QQ.
- D: Specifies run log level with-D and-DD.

Rexfile Introduction

Parameter setup section:

Copy Code code as follows:

Set connection => "OpenSSH";
User "root";
Krb5_auth;
Parallelism 10;

These four lines specify Kerberos authentication, and 10 processes execute the SSH command.

Copy Code code as follows:

Desc "Install puppet agent";
Task "Puppet_install", sub {
}
Before "Puppet_install", sub {
}
After "Puppet_install", sub {
}

These lines are the Rexfile task-defined body format. Task directives define tasks that are executed on a specific-H or-G server. All others are optional, desc content will be displayed at-tv, and before and after-defined tasks will be executed before or after the corresponding task, at the ' Rex command execution, that is, 10.4.1.21 local '.

Introduction to Common instructions

Run

Run the command. If there is a callback function, then the stdout and stderr are passed to the callback function, and if not, the stdout is taken as the return value.

Like what:

Copy Code code as follows:

Say Run "uptime";
Run "Nginx-v", sub {my ($out, $err) = @_; say $err};

File

Distribute files. Syntax is similar to Puppet file. Support source, template, ensure, on_change and other operations. Note: Rex is sequentially executing rexfile, so there is no need to set Puppet require instructions.

Like what:

Copy Code code as follows:

File "/etc/yum.repos.d/xiaonei-private.repo",
SOURCE => "Repos/xiaonei-private.repo";
File "/etc/nginx/nginx.conf",
Content => Template ("Templates/etc/nginx/nginx.conf.tpl"),
Owner => "Nginx",
Group => "Nginx",
Mode => 644,
Ensure => ' file ',
On_change => Sub {service nginx => "restart";
File "/etc/nginx/conf.d",
Ensure => "directory",

Pkg

Install packages, in earlier versions of the command writing install package => "Nginx", recently changed to pkg, more like the Puppet syntax.

Transitive arrays are also supported as PKG content. In addition, Rex provided a update_package_db instruction for performing yum clean all or apt-get update operations. This is a Puppet deficiency.

Like what:

Copy Code code as follows:

update_package_db ();
My $packages = Case Operating_system,
Debian => ["Apache2", "Libphp5-apache2"],
CentOS => ["httpd", "PHP5"],
Pkg $packages,
Ensure => "present";

Ensure also supports present, absent, latest and other meanings. With Puppet.

Account

User management originally used Create_user and Create_group directives, and recently updated Create_user to account directives.

Like what:

Copy Code code as follows:

Create_group ' puppet ';
Account "Puppet",
Ensure => "Present",
UID => 509,
Home => '/home/puppet ',
Comment => ' Puppet account ',
Expire => ' 2015-05-30 ',
Groups => [' Puppet '],
Password => ' puppet ',
System => 1,
No_create_home => TRUE,
Ssh_key => "Ssh-rsa aaaab3nzac1yc2eaaaadaqabaaabaqchuw ...";

Tail

The latest additions to the logs that are used to simultaneously observe multiple hosts. Should be a useful little function. The code is as follows:

Copy Code code as follows:

Tail "/var/log/syslog", sub {
My ($data) = @_;
My $server = rex->get_current_connection ()->{' server '};
Print "$server >> $data \ n";
};

Remote host details related variables

Puppet has a special Facts variable to determine the details of the remote host. Rex, because of the SSH connection, does not run an agent on the remote host to collect this information, so it is still remotely executing the command to provide the relevant content. Several commonly used functions (which can also be considered variables) are:

Is_redhat

This is used to determine whether the operating system is a RedHat series. There was a batch of Debian machines, so rexfile always had this logic in operation:

Copy Code code as follows:

if (Is_debian) {
} elsif (Is_redhat) {
} else {
}

Operating_system_version

This is used to determine the specific operating system version number. For example, CentOS5 and CentOS6 should be applied to the operation is not the same, even CentOS6.5 and CentOS6.2 may also be inconsistent.

Like the 1W10 mission in Rexfile:

Copy Code code as follows:

if (Is_redhat and operating_system_version >= 64)
}

Route

Rex can gather a lot more information than puppet, such as network-related, sysctl-related, and so on. The 1W10 task in Rexfile used route information to obtain the default gateway and network interface.

Copy Code code as follows:

My ($default _route) = grep {
$_->{"Flags"} =~ m/ug/&& (
$_->{"Destination"} eq "0.0.0.0" | |
$_->{"Destination"} eq "default")
} Route;
if ($default _route) {
My $default _GW = $default _route->{"Gateway"};
My $default _if = $default _route->{"Iface"};
Run "IP route change default via ${DEFAULT_GW} dev ${default_if} initcwnd initrwnd 10";
};

Connection

When performing tasks on more than one host, most of the time you want to see which host returns when the output is out. The front tail task is used, but it is very complicated to write. In fact, Rex provided a more concise wording. Is Connection->server.

Copy Code code as follows:

Task ' Tellmewhoyouare ', sub {
Say connection->server;
}

The entire information of the currently connected server can also be obtained by get_system_information instructions, which are actually equivalent to the two instructions. However, it is generally used in different contexts according to the literal meaning.

This information can be viewed through the dump_system_information directive if it is to be viewed in its entirety. This command, unlike print dumper get_system_information (), takes each key as a separate variable. And these variables are the inline variables that can be used directly in Rex's template. Like what:

Copy Code code as follows:

Listen <%= $eth 0_ip%>:80;
Visible_hostname <%= $hostname%>

Variables that are not in the Dump_system_information list and want to be used in template must be passed explicitly. This is inconsistent with the Puppet, Puppet in template can be Scope.lookupvar () instructions to obtain arbitrary PP class variables set, which completely ignores the existence of lexical scopes ==!

Like what:

Copy Code code as follows:

File '/etc/elasticsearch/elasticsearch.yml ',
Content => Template (' Files/es.yml.tmpl ', conf => {
ClusterName => ' Logstash '
});

The corresponding Es.yml.tmpl writing:

Copy Code code as follows:

ClusterName: <%= $conf->{' clustername '}%>

That's fine.