Быстрое развитие виртуализации вместе с появлением пары серверов, одного нового и одного старого, привели к росту числа серверов, нуждающихся в управлении и обслуживании, в офисах организации и ее дочерних подразделениях. И например, если раньше подключение к серверу мониторинга занимало немного времени, то сейчас на это уйдет куда больше. На этом этапе и необходимо обратиться за помощью к средствам управления конфигурациями серверов. В основном серверы, которые необходимо администрировать, однотипны и имеют идентичный базовый набор программного обеспечения. Также они расположены на системах виртуализации. Иногда могут быть отличия, например в версиях операционных систем. В любом случае один раз выполнить указания системного администратора в дальнейшем значительно сэкономит время решения тех или иных задач. Это единственный выход в постоянно растущих инфраструктурах.

 

С чего началось

Сначала поднялся сервер виртуализации, затем внутрипочтовый сервер, веб-хостинг, сервер мониторинга, 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 компьютера.

Продолжение доступно только участникам

Вариант 1. Присоединись к сообществу «Xakep.ru», чтобы читать все материалы на сайте

Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», увеличит личную накопительную скидку и позволит накапливать профессиональный рейтинг Xakep Score! Подробнее

Вариант 2. Открой один материал

Заинтересовала статья, но нет возможности стать членом клуба «Xakep.ru»? Тогда этот вариант для тебя! Обрати внимание: этот способ подходит только для статей, опубликованных более двух месяцев назад.


Check Also

Криптуем по-крупному. Разбираемся с режимом гаммирования из ГОСТ 34.13—2015

Режим гаммирования, в отличие от режима простой замены, позволяет шифровать сообщения прои…

1 комментарий

  1. Аватар

    hrapovd

    28.06.2016 at 15:27

    Пробовал применить puppet к своей инфраструктуре, но столкнулся с проблемами доступа агентов к серверу, т.к. у меня множество групп узлов доступных по ssh только через один из серверов в группе, а выход в интернет с серверов исключительно к репозитариям (для обновления ОС), а также для работы приложений развернутых на серверах. Таким образом пришлось поискать другие решения и натолкнулся на SaltStack (http://saltstack.com/), который позволяет выстроить древовидную структуру агентов (миньонов) и серверов (мастеров) на вершине которой находиться один мастер мастеров, через который доступны все миньоны в сети, пока еще изучаю продукт, но выглядит он довольно многообещающе….

Оставить мнение