Содержание статьи
Быстрое развитие виртуализации вместе с появлением пары серверов, одного нового и одного старого, привели к росту числа серверов, нуждающихся в управлении и обслуживании, в офисах организации и ее дочерних подразделениях. И например, если раньше подключение к серверу мониторинга занимало немного времени, то сейчас на это уйдет куда больше. На этом этапе и необходимо обратиться за помощью к средствам управления конфигурациями серверов. В основном серверы, которые необходимо администрировать, однотипны и имеют идентичный базовый набор программного обеспечения. Также они расположены на системах виртуализации. Иногда могут быть отличия, например в версиях операционных систем. В любом случае один раз выполнить указания системного администратора в дальнейшем значительно сэкономит время решения тех или иных задач. Это единственный выход в постоянно растущих инфраструктурах.
С чего началось
Сначала поднялся сервер виртуализации, затем внутрипочтовый сервер, веб-хостинг, сервер мониторинга, DNS-сервер, сервер Jabber + площадка вебинаров и многие другие. Затем настал момент, когда количество серверов удвоилось, и их все нужно было подключить к мониторингу, поставить базовый софт, в общем — выполнить базовые задачи.
Выбирать стали между aNimble и Puppet. Последний покорил своей простотой. Поскольку его установка очень хорошо описана на многих ресурсах, опустим ее. После установки сервера и настройки первого клиента встал вопрос, как за всем этим наблюдать. Желательно что-то визуальное. Тут рассматривали только два варианта: Dashboard-Lite и Enterprise Dashboard. Первый бесплатен, в нем можно только наблюдать и делить списки на группы для визуального восприятия. Группировать серверы на классы и применять на лету так и не вышло, зато в консоли все прекрасно отрабатывало. После поставили enterprise-версию, думая даже приобрести лицензию, чтобы облегчить жизнь администраторам. Покрутив демоверсию (30 дней), поплевались: возможности пошире, чем у lite, но тем не менее не обеспечивают всего необходимого. Тогда решили оставить lite и делать все консольно.
Подключили все серверы, описали классы. Все завелось хорошо. На первых порах цели были простые:
* указать содержимое файла `/etc/resolf.conf` с адресами DNS-сервера;
* установить ряд программ: htop, iftop, Nmap;
* установить пакеты Zabbix, настроить конфиг;
* управлять обновлениями.И тут, очередной раз блуждая по интернетам, наткнулся на Foreman. По описанию в статье установка была проста. В этой статье есть скрипт запуска клиентов с настройкой конфига. Поскольку у нас серверы «разномастные» — есть с Ubuntu 12.04 и 14.04, а статья ориентирована на 14.04, тут я наступил на первые грабли. Убрал установку репозиториев, стал использовать на 12.04 клиент из собственных репозиториев. В итоге получился вот такой первый скрипт.
#!/bin/bash
apt-get install -y puppet
sed -i s/START=no/START=yes/g /etc/default/puppet
sed -i '/\/var\/log\/puppet/a \server=server.local' /etc/puppet/puppet.conf
puppet agent --testКак видно, скрипт устанавливает клиент Puppet, включает на запуск его, добавляет параметр «адрес сервера» в конфиг и запускает агент. В Foreman он появился, и все было прекрасно до того момента, пока не стали обрабатываться классы. Это были вторые грабли. Дело в том, что с Foreman устанавливается свой Puppet. И вся эта конструкция требует определенной структурной иерархии в манифестах. Например, при дефолтном Puppet использовалось три файла манифеста: sipe.pp — дефолтный, node.pp — файл с описанием нодов и class.pp, в котором описывались классы. У Foreman из коробки доступно четыре окружения, так называемые глобальные профили для групп серверов. Например, для тестовых и для продакшена. Чтобы манифест был доступен в любом окружении, его необходимо добавлять в каждое окружение. Имя манифеста при этом всегда должно быть unit.pp, для корректной обработки Foreman. В итоге каждый класс должен быть «оформлен» /etc/puppet/environments/production/modules/class_name/manifests и внутри должен лежать файл init.pp — только с таким именем и никаким другим. При использовании «старых» манифестов, где все в куче, сыпались ошибки. Причем у меня не вышло без ошибок запихать два класса в один init.pp. Как только с этим разобрались и переписали манифесты, можно подключать их в веб-интерфейсе Foreman. Настройка подключений также очень хорошо изложена в статье, ссылку на которую я дал выше. Что мне понравилось: очень удобное управление группами серверов с предустановкой классов (то есть можно создавать группы и подгруппы и на каждом из уровней прикреплять классы); удобный обзор и мониторинг. Позже, когда все заработало и появилось больше времени, я занялся небольшой модификацией скрипта установки Puppet-клиента.
Далее неплохо бы дать инструмент, который бы автоматически или полуавтоматически устанавливал и настраивал Puppet-агент в систему. Да еще и с проверкой дистрибутива, в котором он работает. А в идеале вообще программой на C и с поддержкой различных дистрибутивов GNU/Linux.
Начнем с малого
Итак, начнем с небольшого скрипта на bash. Вдруг это вдохновит кого-нибудь на написание «супер» программы инсталлятора, а пока я наваял на коленке скрипт только для Ubuntu. За помощь огромнейшее спасибо одному из участников Omsk Linux User Group — Shroom.
Мысли вслух
Народ из сообщества OmskLUG очень дружелюбен и всегда готов помочь. Адрес Jabber-конференции: omsklug@conference.jabber.ru.
Придется вспомнить, как писать на bash (или научиться). А поскольку я человек далекий от написания скриптов на bash, то у меня дело подзатянулось. Чтобы снять вопросы, которые возникнут позднее, сразу оговорюсь, что на момент написания статьи было две версии Ubuntu: 12.04 и 14.04. Итак, обо всем по порядку.
if (whiptail --title "Подготовка рабочей станции " --yesno "Запуск сценария установки" 10 60 "введите имя ПК") thenЗдесь мы запускаем сценарий установки, соглашаемся с запуском скрипта или отменяем его.
namehost=$(whiptail --title "Установка HostName" --inputbox "Введите имя компьютера" 10 60 HostName 3>&1 1>&2 2>&3)Здесь запускаем второе окно с указанием имени компьютера в файле /etc/hostname для возможности смены имени хоста. Делается это из-за того, что имя сертификата для Puppet и имя хоста совпадают. А так как планируется запускать скрипт сразу после установки системы, то очень актуально сменить hostname компьютера.
Получаем введенное значение, проверяем, что не нажали отмену, пишем данные в /etc/hostname. Если отмена — выходим.
exitstatus=$?
if [ $exitstatus = 0 ]; then
echo $namehost > /etc/hostname
else
echo "Отмена"
exit
fiЗапускаем установку Puppet-клиента. Опять проверяем, что нажато — ОK или отмена, и проверяем версию установленной системы. Если 12.04 — качаем пакет с puppetlabs. Устанавливаем его, удаляем deb-пакет с компьютера, запускаем установку Puppet-агента. Даем разрешение на запуск. Пишем в файл /etc/puppet/puppet.conf адрес Puppet-сервера, указанный ранее, и перезапускаем Puppet-агент. Если нет — качаем для 14.04 и повторяем те же шаги, что и для 12.04 (если кто напишет проверку для всех систем — с удовольствием бы применил у себя). Для удобства добавляем команду puppetagent. И применяем файл .bashrc.
namepuppet=$(whiptail --title "Введите адрес сервера Puppet" --inputbox "Введите имя сервера Puppet" 10 60 ServerName 3>&1 1>&2 2>&3)
exitstatus=$?
if [ $exitstatus = 0 ]; then
if [ `lsb_release -r | sed 's/.\+:\s\+//'` = "12.04" ]; then
wget apt.puppetlabs.com/puppetlabs-release-pc1-precise.deb
dpkg -i puppetlabs-release-pc1-precise.deb
rm puppetlabs-release-trusty.deb
apt-get install -y puppet
sed -i s/START=no/START=yes/g /etc/default/puppet
sed -i "/\/var\/log\/puppet/a \server=$namepuppet" /etc/puppet/puppet.conf
puppet agent --test
else
wget apt.puppetlabs.com/puppetlabs-release-trusty.deb
dpkg -i puppetlabs-release-trusty.deb
rm puppetlabs-release-trusty.deb
apt-get install -y puppet
sed -i 's/templatedir/#templatedir/' /etc/puppet/puppet.conf
sed -i s/START=no/START=yes/g /etc/default/puppet
sed -i "/\/var\/log\/puppet/a \server=$namepuppet" /etc/puppet/puppet.conf
puppet agent --test
echo 'alias puppetagent="sudo puppet agent --test"' >> /home/$USER/.bashrc
source /home/$USER/.bashrc
fi
else
echo "Отмена запуска"
exit
fiЭто немного ускорит установку и настройку Puppet-клиента. Как известно, аппетит приходит во время еды. Вот и в моем случае: только когда скрипт был дописан, пришла идея внести изменения — не проверять установленную ОС, а давать выбор пользователю самому указать версию Linux, в которой запускается скрипт. И украсить прогресс-баром скачивание и установку Puppet с помощью whiptail --gauge или аналогичного инструмента dialog. Побродив несколько дней по интернетам, наткнулся на занимательную статью «Применение whiptail --gauge».
Суть скрипта, приведенного в статье, в следующем: пока запущен процесс, идет эмуляция его пересчета. Когда процесс завершается, прогресс-бар устанавливается в 100% и после закрывается. Не совсем честно, но результат такой, какой нужно. После небольшой правки этот кусок выглядел следующим образом. Для украшения и, что называется, отвода глаз самое то.
wget -q apt.puppetlabs.com/puppetlabs-release-trusty.deb
echo 5
dpkg -i puppetlabs-release-trusty.deb > /dev/null
echo 10
rm puppetlabs-release-trusty.deb*
echo 15
apt-get install -y puppet > .log.log
#########################################################################
#(
progress="30"
while (true)
do
proc=$(ps aux | grep -v grep | grep -e "apt-get")
if [ "$proc" = "" ]; then break; fi
sleep 1
progress=$(expr $progress + 2)
done;
##########################################################################
rm .log.log
sed -i s/START=no/START=yes/g /etc/default/puppet
sed -i "/\/var\/log\/puppet/a \server=$namepuppet" /etc/puppet/puppet.conf
sed -i 's/templatedir/#templatedir/' /etc/puppet/puppet.conf
echo 100
puppet agent --test
) | whiptail --title "Установка Puppet-клиента" --gauge "Пожалуйста, подождите, роняем цены на нефть" 7 70 1Как видно, немного допилил прогресс-бар — чтобы он более-менее был похож на настоящий прогресс-бар, а не имитацию. После этого получили вполне рабочую систему. Теперь все это хозяйство необходимо добавить в процесс установки системы. Системы мы ставим по сети PXE, скрипт автонастройки выложен на веб-сервере (о том, как это поднималось, можно прочитать в серии статей по PXE в предыдущих номерах) preseed.cfg. Внутри описаны различные директивы автонастройки по ходу установки, так называемые файлы ответов. Здесь можно указать, какой набор программного обеспечения дополнительно нужно установить, как разбить диски, как настроить сеть и прочее.
Нас интересует директива d-i preseed/late_command string. Для удобства положим скрипт рядом с файлом preseed.cfg на веб-сервере и потом скачаем его в процессе установки.
d-i preseed/late_command string wget http://ip/puppetinstall.sh /target/puppetinstall.sh; \
cd /target; \
chmod +x puppetinstall.sh; \
in-target /bin/bash /target/puppetinstall.sh;Если на этом этапе использовать скрипт, то его нужно немного переработать. А именно убрать запуск клиента Puppet, оставить только установку пакетов. Рекомендую использовать после первой загрузки сервера. Я пошел немного по другому пути: по d-i preseed/late_command string просто скачиваю файл скрипта в систему, а уже после перезагрузки запускаю его.
Далее готовим Puppet-манифесты. Описываем классы установки базового пакета программ и подключение к системе мониторинга Zabbix. Внутри последнего класса (zabbix) описываем файл конфигурации, который будем передавать Puppet-клиентам (смотри дополнительные материалы к статье).
Теперь на все новые серверы автоматом будет вставать Puppet. В файле настройки класса zabbix указано установить Zabbix-клиент, описан стандартный конфиг с указанием IP-адреса сервера Zabbix и дополнительно приведены параметры для подключения мониторинга температуры дисков:
#UserParameter=HDDTempSDA,hddtemp -n /dev/sda
#UserParameter=HDDTempSDB,hddtemp -n /dev/sdbВ остальном все стандартно. Аналогичным образом настраиваем /etc/resolg.conf для указания DNS-сервера. Класс routelan.pp используем для настройки маршрутов, внутри описан скрипт, который создается в /opt/lan.sh.
#!/bin/bash
sudo route add -net 192.168.0.0/24 gateway IP_шлюза eth0Суть, думаю, понятна. Хочется отметить, что Foreman как оболочка мониторинга и инструмент подключения/отключения параметров (классов) показывает себя очень даже неплохо. В сравнении с Puppet Dashboard информативность на уровне.
Заключение
Как показывает практика, подобные решения автоматизации высвобождают от 30 до 50% времени, что дает значительное увеличение производительности системного администратора. В целом Puppet — очень зрелый продукт, который без особых сложностей разворачивается практически на любой платформе.
P.S. Надеюсь, ты не потратил время зря 😉 Спасибо и удачи!
