Якщо ви лише плануєте використовувати подібні системи - то раджу звернути увагу на Ansible. Він більш дружній до початківців, має менше недоліків та і може виконувати ту ж роботу з аналогічним успіхом.
Класична система роботи Puppet - клієнт-серверна (standalone). Певні проміжки часу (по замовчуванню кожні 30 хвилин) Puppet-клієнт запитує дані щодо власної конфігурації в Puppet-сервера, сервер компілює їх в проміжний результат та віддає клієнту. Вузьке місце такої системи - це сам Puppet-сервер: у разі виходу його із ладу, одразу всі клієнти не зможуть отримати зміни конфігурації. Також з часом ймовірно необхідно буде масштабувати сервер, адже потужностей сервера може бути недостатньо.
Тож задля підвищення рівня доступності варто звернути увагу на інший варіант роботи Puppet - masterless, тобто архітектуру без Puppet-сервера. У такому разі всі файли конфігурації будуть зберігатись в репозиторії, а кожен клієнт певні проміжки часу буде запитувати зміни з репозиторію і локально їх застосовувати. У якості репозиторію модулів/маніфестів Puppet краще всього підійдуть системи контролю версій, наприклад Git.
Перейдемо до суті. Як я вже говорив розбиратись із masterless конфігурацією ми будемо на прикладі автоматичної конфігурації Heartbeat. Це можливо не найтривіальніший приклад, проте досить цікавий. Суть роботи Heartbeat полягає в міграції (переміщенні) IP адреси з непрацюючого серверу кластера на працюючий і, таким чином, підвищувати рівень доступності. З деталями використання Heartbeat можна ознайомитись на офіційній сторінці проекту:
http://www.linux-ha.org/doc/users-guide/users-guide.html
Про щось подібне я також вже писав раніше. Для конфігурації Heartbeat кластеру необхідно як мінімум дві ноди та 3 вільні IP-адреси однієї мережі. У якості ОС я обрав Ubuntu 14.04, а серверам призначив такі адреси та хостнейми:
192.168.1.21 - hb1.me
192.168.1.22 - hb2.me
192.168.1.20 - віртуальний IP (VIP), що буде мігрувати на робочу ноду у разі падіння попередньої.
Отже, очевидно, перше, що необхідно зробити - це встановити puppet на кожний із перерахованих вузлів. Для установки скористаємось офіційними репозиторіями, що додаються після установки пакету від PuppetLabs:
# cd /tmp
# wget http://apt.puppetlabs.com/puppetlabs-release-trusty.deb
# dpkg -i puppetlabs-release-trusty.deb
# apt-get update
# apt-get install puppet git-core
Виконаємо базову конфігурацію Puppet сервісу. Видалимо параметр templatedir та все, що відноситься до секції [master]. В результаті /etc/puppet/puppet.conf має виглядати наступним чином:
# vim /etc/puppet/puppet.conf
[main]
logdir=/var/log/puppet
vardir=/var/lib/puppet
ssldir=/var/lib/puppet/ssl
rundir=/var/run/puppet
factpath=$confdir/facter
Створимо новий модуль cron-puppet:
# cd /etc/puppet/modules
# mkdir -p cron-puppet/manifests cron-puppet/files
Новий модуль буде відповідати за створення post-merge скрипта та установку cron-задачі з отриманням оновлень з віддаленого репозиторію, що буде запускатись кожні 15 хвилин:
# vim cron-puppet/manifests/init.pp
class cron-puppet {
file { 'post-hook':
ensure => file,
path => '/etc/puppet/.git/hooks/post-merge',
source => 'puppet:///modules/cron-puppet/post-merge',
mode => 0755,
owner => ubuntu,
group => ubuntu,
}
cron { 'puppet-apply':
ensure => present,
command => "cd /etc/puppet ; /usr/bin/git pull",
user => ubuntu,
minute => '*/15',
require => File['post-hook'],
}
}
post-merge скрипт буде виконуватись лише у разі виникнення нових змін у віддаленому репозиторії.
# vim cron-puppet/files/post-merge
#!/bin/bash -e
## Run Puppet locally using puppet apply
/usr/bin/sudo /usr/bin/puppet apply /etc/puppet/manifests/site.pp
## Log status of the Puppet run
if [ $? -eq 0 ]
then
/usr/bin/sudo /usr/bin/logger -i "Puppet has run successfully" -t "puppet-run"
exit 0
else
/usr/bin/sudo /usr/bin/logger -i "Puppet has ran into an error, please run Puppet manually" -t "puppet-run"
exit 1
fi
Створимо другий модуль, що безпосередньо стосується наших планів, - heartbeat:
# cd /etc/puppet/modules
# mkdir -p heartbeat/manifests heartbeat/templates
Файл ініціалізації модулю має наступний вигляд:
# vim heartbear/manifests/init.pp
# Manage Heartbeat
class heartbeat {
package { 'heartbeat':
ensure => installed,
}
service {'heartbeat':
ensure => running,
enable => true,
require => Package['heartbeat'],
}
exec { 'reload-heartbeat':
command => '/usr/sbin/service heartbeat reload',
refreshonly => true,
}
file { '/etc/ha.d/authkeys':
content => "auth 1\n1 sha1 TopSecret",
mode => '0600',
require => Package['heartbeat'],
notify => Exec['reload-heartbeat'],
}
}
Тож спочатку буде встановлено пакет heartbeat, сервіс якого буде додано в автозавантаження у разі, коли пакет присутній (require => Package['heartbeat']). Далі, якщо пакет heartbeat установлено, відбудеться створення файлу /etc/ha.d/authkeys з даними необхідними для авторизації вузла в кластері. Щоразу при зміні цього файлу буде виконаний ресурс reload-heartbeat, що відповідно призведе до перевантаження heartbeat сервісу (notify => Exec['reload-heartbeat']). refreshonly вказує, що ресурс можна виконати лише звернувшись через notify іншого ресурсу.
Створимо інший маніфест vip.pp для цього ж модуля:
# vim heartbear/manifests/vip.pp
# Manage a specific VIP with Heartbeat
class heartbeat::vip($node1,$node2,$ip1,$ip2,$vip,$interface='eth0:1') {
include heartbeat
file { '/etc/ha.d/haresources':
content => "${node1} IPaddr::${vip}/${interface}\n",
notify => Exec['reload-heartbeat'],
require => Package['heartbeat'],
}
file { '/etc/ha.d/ha.cf':
content => template('heartbeat/vip.ha.cf.erb'),
notify => Exec['reload-heartbeat'],
require => Package['heartbeat'],
}
}
Ці ж інструкції можна було б включити в init.pp, проте для зручності ми винесли їх окремо. Клас для роботи потребує хостнейм кожного майбутнього вузла кластеру, IP для кожного вузла відповідно та віртуальний IP, що матиме можливість мігрувати. Для параметра $interface вже одразу вказано значення по-замовчуванню, проте воно може бути змінене при виконанні класу.
vip.pp включає в себе клас heartbeat (include heartbeat, тобто все що описано в init.pp). Потім створюється файл /etc/ha.d/haresources з вмістом, що зазначений у параметрі content. Для роботи ресурсу file { '/etc/ha.d/haresources'...} необхідно наявність уже установленого пакету heartbeat. З кожною зміною файлу /etc/ha.d/haresources буде викликатись перевантаження сервісу heartbeat (notify => Exec['reload-heartbeat']).
Ресурс file { '/etc/ha.d/ha.cf':...} працює за подібною логікою. Він створює конфігураційний файл /etc/ha.d/ha.cf, використовуючи шаблон, що має наступний вигляд:
# vim heartbear/templates/vip.ha.cf.erb
use_logd yes
udpport 694
autojoin none
ucast eth0 <%= @ip1 %>
ucast eth0 <%= @ip2 %>
keepalive 1
deadtime 10
warntime 5
auto_failback off
node <%= @node1 %>
node <%= @node2 %>
Змінні ip1, ip2, node1, node2, як я вже говорив, передаються параметрами до класу heartbeat::vip.
Підключимо ці 2 класи до новостворених нод в site.pp:
# vim /etc/puppet/manifests/site.pp
node 'hb1'{
include cron-puppet
class { 'heartbeat::vip':
ip1 => '192.168.1.21',
ip2 => '192.168.1.22',
node1 => 'hb1.me',
node2 => 'hb2.me',
vip => '192.168.1.20/24',
}
}
node 'hb2'{
include cron-puppet
class { 'heartbeat::vip':
ip1 => '192.168.1.21',
ip2 => '192.168.1.22',
node1 => 'hb1.me',
node2 => 'hb2.me',
vip => '192.168.1.20/24',
}
}
Кінцева структура директорія Puppet виглядає наступним чином:
# tree .
.
├── environments
│ └── example_env
│ └── README.environment
├── manifests
│ └── site.pp
├── modules
│ ├── cron-puppet
│ │ ├── files
│ │ │ └── post-merge
│ │ └── manifests
│ │ └── init.pp
│ └── heartbeat
│ ├── manifests
│ │ ├── init.pp
│ │ └── vip.pp
│ └── templates
│ └── vip.ha.cf.erb
├── puppet.conf
└── README.md
10 directories, 9 files
# echo "# puppet-modules" >> README.md
# git init
# git add README.md
# git commit -m "first commit"
Та заливаємо всі створені вище модулі:
# git remote add origin git@github.com:ipeacocks/puppet-modules.git
# git push -u origin master
Нагадаю, що публічні репозиторії зовсім не місце для паролів та інших ключів авторизації.
Задеплоїмо всі ці налаштування на кожний вузол Heartbeat кластеру (hb1.me та hb2.me), попередньо зайшовши на кожен сервер по ssh:
# cd /etc
# sudo mv puppet/ puppet-bak
# git clone https://github.com/ipeacocks/puppet-modules.git /etc/puppet
Ліпше за все вузлам надати право лише читати репозиторій, без можливості вносити і комітити зміни. Це стандартне поводження Github репозиторію через https: задля виконання push Github буде вимагати пароль/логін.
Щоб додати Puppet в cron для автоматичного виконання кожні 15 хвилин, спершу необхідно запустити puppet вручну на кожному з вузлів:
# sudo puppet apply /etc/puppet/manifests/site.pp
У моєму випадку для користувача ubuntu запуск команд від sudo можливий без паролю.
Отже, перевіримо інтерфейси на кожному із вузлів після запуску puppet:
ubuntu@hb1:/etc/puppet$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 08:00:27:b1:ac:04 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.21/24 brd 192.168.1.255 scope global eth0
valid_lft forever preferred_lft forever
inet 192.168.1.20/24 brd 192.168.1.255 scope global secondary eth0:0
valid_lft forever preferred_lft forever
ubuntu@hb2:/etc/puppet$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 08:00:27:57:32:0f brd ff:ff:ff:ff:ff:ff
inet 192.168.1.22/24 brd 192.168.1.255 scope global eth0
valid_lft forever preferred_lft forever
З виводу видно, що віртуальний IP прив'язаний до першого серверу кластера. Відповідно, у разі втрати зв'язку з ним, віртуальний IP мігрує на сервер hb2.me.
У наступній статті я розповім про установку та налаштування Foreman, панелі адміністрування Puppet.
Посилання:
https://www.digitalocean.com/community/tutorials/how-to-set-up-a-masterless-puppet-environment-on-ubuntu-14-04
https://www.packtpub.com/networking-and-servers/puppet-3-cookbook
https://www.digitalocean.com/community/tutorials/how-to-install-puppet-to-manage-your-server-infrastructure
http://www.example42.com/tutorials/PuppetTutorial/
Немає коментарів:
Дописати коментар