PUPPET – кроссплатформенная система управления конфигурациями


PUPPET – кроссплатформенная система управления конфигурациями
PUPPET-DASHBOARD – Web интерфейс к puppet, который предоставляет управление отчётами.

Документация и примеры:
http://docs.puppetlabs.com/puppet/latest/reference/release_notes.html
https://ask.puppetlabs.com/questions/
http://ru.wikibooks.org/wiki/Puppet
http://www.xakep.ru/post/55238/

Данный FAQ состоит из разделов:
1) Принцип работы и общая установка puppet в CentOS 6
2) Наша конфигурация
3) Ошибки и их решения

==================================
Принцип работы и общая установка:
==================================

Принцип работы:
На всех серверах установлен puppet (client) и управляется все с главного сервера puppet-server
Раз в 30 мин клиенты опрашивают сервер и смотрят настройки для себя. Настройки хранятся в специальных файлах (манифесты)
Манифесты содержат классы – “класс” это описание что необходимо сделать/запустить/установить/проверить наличие/обновить/удалить/создать и еще много всего.
Это могут быть программы, скрипты, файлы, каталоги, права и прочее.

Установка puppet client:

Добавляем репозиторий:

# rpm -ivh https://yum.puppetlabs.com/el/6/products/x86_64/puppetlabs-release-6-10.noarch.rpm

Выполняем установку клиента:

# yum install puppet

Puppet-client имеет два конф файла:
Описание кто сервер и по какому порту работать

# cat /etc/sysconfig/puppet | grep -v '#'
PUPPET_SERVER=monitor.soulbrat.org.ua
PUPPET_PORT=8140
PUPPET_LOG=/var/log/puppet/puppet.log

Дополнительные опции клиента:

# cat /etc/puppet/puppet.conf | grep -v '#'
[main]
logdir = /var/log/puppet
rundir = /var/run/puppet
ssldir = $vardir/ssl
[agent]
classfile = $vardir/classes.txt
localconfig = $vardir/localconfig
report = true

Лог файл работы – /var/log/puppet/puppet.log

Устанавливаем автозапуск:

# chkconfig puppet on

И запустить:

# /etc/init.d/./puppet start
Starting puppet agent: [ OK ]

Что бы подключить клиента к серверу, необходимо после установки клиента и описания “кто сервер” сделать тестовый запрос:

# puppet agent --test

Установка puppet-server:

Добавляем репозиторий:

# rpm -ivh https://yum.puppetlabs.com/el/6/products/x86_64/puppetlabs-release-6-10.noarch.rpm

Выполняем установку сервера и клиента:

# yum install puppet-server puppet

Устанавливаем доп модуль:

# puppet module install maestrodev-ssh_keygen

Устанавливаем автозапуск:

# chkconfig puppet-server on

Если нужно что бы мастер был так же клиентом, выполняем настройку клиента как и на других серверах.

На сервере все клиенты “подписаны” сертификатами.
Посмотреть кто подписан и кто не подписан можно командой:

# puppet cert --list --all

Подписать нового клиента можно командой:

# puppet cert sign servername

Основной каталог с главным манифестом и описанием всех нод – /etc/puppet/manifests/site.pp

Facter:
Puppet имеет свою программу определения конфигурации системы и сервера – facter
Если запустить на любом сервере с клиентской частью facter без параметров, то можно увидеть все что он определяет.
Каждый параметр называется “фактом”. Так же есть возможность дописывать свои “факты”, если каких-либо параметров в стандартном выводе нет. Эту программу можно использовать и для своих целей и без puppet.

Puppet-dashboard описание установки:

По-умолчанию Puppet-dashboard работает на порту http://0.0.0.0:3000 без какой либо авторизации и минуя веб-сервер. То есть кто угодно может зайти и увидеть статистику. У puppet-dashboard есть свое очень громоздкое решение для установки авторизации. Было принято решение сделать простую свою веб-авторизацию через фаерволл и apache. Описание ниже в секции “Наша конфигурация/Защита puppet-dashboard”.

==========================
Наша конфигурация:
==========================

Применение:
Основной каталог /etc/puppet/manifests

Что бы применить все изменения если вносились в манифесты, нужно просто выполнить:

# puppet apply --verbose /etc/puppet/manifests/site.pp

Стоит отметить, что в новой версии puppet 3.5 перестали обрабатываться ошибки в манифестах, если они не применяются для самого мастера. То есть увидеть что манифест написан с ошибкой, можно будет на клиенте в логе или в Dasboard когда клиент покажет ошибку. Поэтому рекомендуется все новые манифесты проверять на тестовом сервере или на мастере.
Так же при выходе новых версий, редко, но может меняться синтаксис языка puppet, например с версии 3.5 директива “import” перестала поддерживаться.
В общем все нужно проверять перед применением что бы избежать критических ошибок.

Модули:
Каталог модулей /etc/puppet/modules
Модули это по сути просто подкаталоги в директории /etc/puppet/modules.
Проверить какие модули видит puppet можно командой:

# puppet module list

Все манифесты (с описанием классов) должны хранится в подкаталоге manifests и иметь имя init.pp

У нас есть общий модуль files (/etc/puppet/modules/files) в котором собираются статические файлы и скрипты, которые необходимо поддерживать на серверах.
И далее модули согласно текущим задачам.
Например модуль r1soft (/etc/puppet/modules/r1soft) – для поддержания актуальной версии клиентов и серверов cdp-r1soft для бэкапов.
Данный модуль имеет один манифест /etc/puppet/modules/r1soft/manifests/init.pp

Краткое описание манифеста с комментариями (детальное описание возможностей и синтаксиса языка puppet можно найти в документации):

# cat /etc/puppet/modules/r1soft/manifests/init.pp

# Все классы должны начинаться с имени класса r1soft потом символ “::” и имя подкласса/конкретной задачи
# Создаем класс для установи репозитория на сервере. В данном случае у нас создан файл репозитория (согласно инструкции по установке для r1soft) и мы просто поддерживаем его актуальном состоянии.

class r1soft::r1soft-repo {
file { "/etc/yum.repos.d/r1soft.repo":
ensure => "present",
# Задаем права для этого файла
owner => "root",
group => "root",
mode => 644,
# указываем путь откуда копировать этот файл с puppet-server-а
source => "puppet:///files/r1soft/r1soft.repo"
}
}
# Создаем класс для установки агента-клиента бэкапа и указываем всегда поддерживать последнюю актуальную версию
class r1soft::r1soft-client-latest {
package { [ "serverbackup-agent" ]:
ensure => latest,
}
# Указываем что агент должен быть в атозапуске, всегда запущенным и самое главное если было обновление агента, то перезапустить сервис
service { cdp-agent:
enable => true,
ensure => running,
require => Class['r1soft::r1soft-repo'],
subscribe => Package['serverbackup-agent']
}
}
# cdp-server
# Создаем похожий класс для серверной части для серверов с cdp-server
class r1soft::r1soft-server-latest {
package { [ "serverbackup-enterprise" ]:
ensure => latest,
}
service { cdp-server:
enable => true,
ensure => running,
require => Class['r1soft::r1soft-repo'],
subscribe => Package['serverbackup-enterprise']
}
}

Итого мы имеем модуль r1soft, с тремя классами:
r1soft::r1soft-repo – для установки репозитория
r1soft::r1soft-client-latest – для установки последней актуальной версии агента и поддержки его запущенного состояния
r1soft::r1soft-server-latest – для установки последней актуальной версии сервера и поддержки его запущенного состояния

Теперь определяем для каких серверов эти классы должны быть применены:
В главном манифесте с описанием серверов – /etc/puppet/manifests/site.pp указываем
– клиентов:

node 'server1.soulbrat.org.ua' {
include r1soft::r1soft-repo
include r1soft::r1soft-client-latest
}
- сервера бэкапов:
node 'backup1.soulbrat.org.ua',
'backup2.soulbrat.org.ua' {
include r1soft::r1soft-repo
include r1soft::r1soft-server-latest
}

И применяем изменения:

puppet apply --verbose /etc/puppet/manifests/site.pp

После применения клиентом, например агента бэкапа, в логе мы увидим следующее:

cat /var/log/puppet/puppet.log
Fri Apr 18 17:05:46 +0300 2014 Puppet (notice): Starting Puppet client version 3.5.1
Fri Apr 18 17:05:48 +0300 2014 /Stage[main]/R1soft::R1soft-repo/File[/etc/yum.repos.d/r1soft.repo]/ensure (notice): defined content as '{md5}ee3b5313bb5ea7271dfcc7d7d405e413'
Fri Apr 18 17:06:11 +0300 2014 /Stage[main]/R1soft::R1soft-client-latest/Package[serverbackup-agent]/ensure (notice): created
Fri Apr 18 17:06:12 +0300 2014 /Stage[main]/R1soft::R1soft-client-latest/Service[cdp-agent]/ensure (notice): ensure changed 'stopped' to 'running'
Fri Apr 18 17:06:13 +0300 2014 Puppet (notice): Finished catalog run in 24.79 seconds

То есть был установлен репозиторий, был установлен пакет клиента, создан автозапуск и сервис был запущен.

Защита puppet-dashboard
Принцип:
Фаерволлом закрыт порт 3000 для всех. Создан виртуалхост в апаче с алиасом на http://11.22.33.44/puppet/. При прохождении авторизации веб-сервером, в каталоге виртуалхоста, создан файл index.php который записывает в фаерволл IP-адрес прошедшего авторизацию и сразу редиректит посетителя на страницу dashboard-а – http://11.22.33.44:3000
IP-адрес запоминается в файле /etc/puppet/manifests/iptables.list

Структура:
Скрипт запуска фаерволла для блокировки порта 3000 для Dashboard. Он прописан в автозапуске в

# cat /etc/rc.local
# /etc/puppet/manifests/iptables_dashboard.sh

Содержимое файла iptables_dashboard.sh:

#!/bin/sh

IPT="/sbin/iptables"

# Сбросить правила и удалить цепочки
    $IPT -F
    $IPT -t mangle -F
    $IPT -X
    $IPT -t mangle -X

# Политики по умолчанию
    $IPT -P INPUT ACCEPT
    $IPT -P FORWARD ACCEPT
    $IPT -P OUTPUT ACCEPT

# Разрешаем прохождение любого трафика по интерфейсу обратной петли.
    $IPT -A INPUT -i lo -j ACCEPT
    $IPT -A OUTPUT -o lo -j ACCEPT

### white IP
if [ -s /etc/puppet/manifests/iptables.list ]; then
cat /etc/puppet/manifests/iptables.list | sed '/^ *$/d' | \
while read line
do
echo IP is found $line
iptables -A INPUT -p tcp --dport 3000 -s $line -j ACCEPT
done
fi

### puppet-dashboard
iptables -A INPUT -p tcp --dport 3000 -j LOG --log-level debug --log-prefix "DEBUG"
iptables -A INPUT -p tcp --dport 3000 -j DROP

Список добавленных в фаерволл IP-адресов для доступа, в файл добавляются адреса скритом при правильной авторизации:

# /etc/puppet/manifests/iptables.list

Виртуалхост:

# cat /etc/httpd/conf.d/puppet.conf
Alias /puppet "/var/www/puppet-dashboard"
<Directory "/var/www/puppet-dashboard">
Options -Indexes
AllowOverride All
Allow from all
AuthName "Puppet Dashboard Access Control by Soulbrat.org.ua!"
AuthType Basic
AuthUserFile /var/www/puppet-dashboard/.htpasswd
Require valid-user

В каталоге /var/www/puppet-dashboard:
index.php – для определения IP-адреса прошедшего авторизацию и записывания его в файл фаерволла, после этого сразу редирект на dashboard. Содержимое index.php:

<?php
$log_file="counter.log";
// Получаем IP из лога
$ips = file($log_file);
// Получаем IP посетителя
$ip  = getenv("REMOTE_ADDR")."\n";
if ( !in_array($ip, $ips) ) {
    // IP нет в логе, добавляем
    $ips[] = $ip;
}
$f=fopen($log_file,"wb");
fputs($f, implode("", $ips));
fclose($f);
//$result = exec ('/var/www/puppet-dashboard/iptables.ip.sh');
//echo $result;
?>
<meta http-equiv="refresh" content="0;url=http://11.22.33.44:3000/" />

iptables.ip.sh – скрипт применения фаерволла для нового посетителя. Работает постоянно в цикле применяется сразу. Содержимое iptables.ip.sh:

#!/bin/sh
# работаем в бесконечном цикле
while true
do {
# определяем рабочий каталог
dstdir=/var/www/puppet-dashboard

# если файл с адресами не пуст, работаем с ним читая построчно
if [ -s $dstdir/counter.log ]; then
cat $dstdir/counter.log | sed '/^ *$/d' | \
while read i; do
   # берем адрес и смотрим в предыдущих записях нет ли его. Если нет добавляем в фаерволл и применяем.
   x=`cat /etc/puppet/manifests/iptables.list | grep -w $i`
   if [ ! -n "${x}" ]; then
      echo IP is found $i
      echo $i >> /etc/puppet/manifests/iptables.list
      sh /etc/puppet/manifests/iptables_dashboard.sh
   else
   # если адрес существует в листе, ничего не делаем
   echo IP is found! Do nothing!
   fi
# очищаем файл
cat $dstdir/counter.log | grep -v -w $i | sed '/^ *$/d' > $dstdir/counter.log.tmp
mv $dstdir/counter.log.tmp $dstdir/counter.log

chmod 666 $dstdir/counter.log

done

else
echo File is empty
fi

sleep 3
} done;

start.sh – скрипт для запуска цикла, запускается через крон, контролирует что все работает. Если не работает, перезапускает. Содержимое файла start.sh:

#!/bin/sh

file="/var/run/iptables.ip.pid"

if [ -f $file ]
  then
      pid=`cat $file`
      pstr=`ps x | egrep "^[[:space:]]*$pid " | grep -v grep`
         if [ -n "$pstr" ]
            then
            echo "Script already running"
            exit 1
         fi
fi
timestart=`date`
cd /var/www/puppet-dashboard
sh /var/www/puppet-dashboard/iptables.ip.sh &
echo $! > $file
echo start `date` >> /var/www/puppet-dashboard/work.log
exit

stop.sh – остановить все циклы фаерволла, нужен для отладки. Содержимое файла stop.sh:

#!/bin/sh

x=`cat /var/run/iptables.ip.pid`
echo $x
kill -9 $x
echo ps ax | grep $x

И для запуска этого нужно добавить в /etc/crontab следующую запись:

*/1 * * * * root /var/www/puppet-dashboard/./start.sh > /dev/null 2>&1

============================
Ошибки и их решения:
============================

Для установки на любом сервере с WHM/cPanel, необходимо закомментировать исключения в файле /etc/yum.conf, так как иначе не установится *** ruby без которого установка прервется и мы получим ошибки:

Error: Package: puppet-3.4.3-1.el6.noarch (puppetlabs)
Requires: ruby-augeas
Error: Package: puppet-3.4.3-1.el6.noarch (puppetlabs)
Requires: ruby >= 1.8.7
Error: Package: puppet-3.4.3-1.el6.noarch (puppetlabs)
Requires: ruby-rgen >= 0.6.5
Error: Package: 1:facter-2.0.1-1.el6.x86_64 (puppetlabs)
Requires: /usr/bin/ruby
Error: Package: puppet-3.4.3-1.el6.noarch (puppetlabs)
Requires: ruby >= 1.8
Error: Package: hiera-1.3.2-1.el6.noarch (puppetlabs)
Requires: rubygem-json
Error: Package: puppet-3.4.3-1.el6.noarch (puppetlabs)
Requires: /usr/bin/ruby
Error: Package: hiera-1.3.2-1.el6.noarch (puppetlabs)
Requires: ruby >= 1.8.5
Error: Package: puppet-3.4.3-1.el6.noarch (puppetlabs)
Requires: ruby-shadow
Error: Package: hiera-1.3.2-1.el6.noarch (puppetlabs)
Requires: /usr/bin/ruby
Error: Package: 1:facter-2.0.1-1.el6.x86_64 (puppetlabs)
Requires: ruby >= 1.8.7
You could try using –skip-broken to work around the problem

Эти исключения добавляет WHM после своей установки:
# cat /etc/yum.conf| grep excl
exclude=bind-chroot courier* dovecot* exim* filesystem httpd* mod_ssl* mydns* mysql* nsd* php* proftpd* pure-ftpd* ruby* spamassassin* squirrelmail*

Если в Puppet-Dashboard все сервера становятся как Unresponsive – это признанный глюк разработчиками, появляется после обновления pupet-server, перестают корректно работать puppet-dashboard-workers
Для фикса выполнить:

# service puppet-dashboard-workers stop
# cd /usr/share/puppet-dashboard
# rm -f spool/*
# rake jobs:clear RAILS_ENV=production
# service puppet-dashboard-workers start

При копировании статьи, ссылка на источник обязательна!

Comments are closed.

скачать бесплатно http://torrentigri.xyz/action/360-pubg.html торрент без регистрации
Language
Страницы
Рекомендую