CC BY
77
АВТОМАТИЗИРОВАННАЯ УСТАНОВКА И КОНФИГУРИРОВАНИЕ СЕРВЕРНЫХ РЕШЕНИЙ Басыня Евгений Александрович, к.т.н., доцент (e-mail: basinya@corp.nstu.ru) Лукина Маргарита Сергеевна, студент (e-mail: luckinamargo@gmail.com) Новосибирский государственный технический университет,
г.Новосибирск, Россия
В работе рассматривается процесс автоматизированной установки и конфигурирования программного обеспечения на примере трех наиболее популярных на данный момент систем управления конфигурациями: Chef, Puppet и Ansible. Подобные инструменты появились на рынке относительно недавно и все чаще используются в процессах проектирования крупных систем и проектов, что объясняет актуальность данной темы.
Ключевые слова: проектирование, автоматизация, развертывание, Chef, Puppet, Ansible.
1. Введение
Под развертыванием программного обеспечения (ПО) понимается процесс установки и конфигурирования ПО, дающий возможность тестировать его и вносить изменения. Данный процесс применяется как для отладки нового программного обеспечения, так и для настройки операционных систем.
На данный момент многие разработчики придерживаются позиции, что программное обеспечение должно иметь полностью автоматизированный процесс развертывания. Актуальность такого подхода в первую очередь объясняется тем, что развертывание хорошо поддается автоматизации, а также тенденцией к росту виртуализации и увеличения мощности серверов. Подход дает многочисленные преимущества: снижение итераций, количества ошибок и временных затрат, упрощение процесса установки и конфигурирования в новой среде и т. д. Однако самым главным преимуществом автоматизации является возможность одновременно администрировать большое количество машин: от класса в 25 компьютеров до целого парка в 10000 и более машин. Как правило, задача системного администратора заключается в установке, конфигурации и мониторинге однотипного программного обеспечения (веб-сервер, СУБД, прикладное ПО, системные утилиты и т.д.). Типичность подобных задач позволяет автоматизировать процесс. Ниже рассмотрены три наиболее популярные системы автоматического развертывания. Каждая из них является декларативной, а не императивной, то есть описывает состояние, к которому должна прийти машина, а не последовательность действий, необходимых для его достижения.
2. Chef
Конфигурация Chef состоит из трех элементов: сервера, который используется как хранилище "поваренных книг" и "рецептов", нод (удаленных машины, которые необходимо конфигурировать) и рабочей станции, с которой происходит управление. Программа-агент устанавливается на но-де при помощи утилиты knife, соединение происходит по SSH (англ. Secure Shell, сетевой протокол прикладного уровня, позволяющий производить удалённое управление операционной системой и туннелирование TCP-соединений). После этого управляемые узлы аутентифицируются с головным хостом при помощи сертификатов. Пользователь Chef создаёт определенные «рецепты» с описанием необходимой конфигурации серверных приложений и их настроек. Предполагается, что при помощи рабочей станции администратор пишет рецепты (или скачивает готовые с сайта Chef), которые в дальнейшем загружаются на сервер, а программа-агент на нодах периодически синхронизируется с сервером для обновления своей конфигурации (по умолчанию - раз в полчаса). «Рецепт» — это описание состояния системы, в котором она должна находиться в определенный момент времени, включая запущенные службы, установленные пакеты, созданные файлы. Chef проверяет, что каждый из ресурсов системы настроен правильно и пытается привести ресурс в нужное состояние, если оно не соответствует ожидаемому.
Chef предоставляет для пользователя достаточно широкий функционал, позволяющий решать множество задач — скачивание и распаковку пакетов, установку программного обеспечения, редактирование конфигурационных файлов и т.д. Совместим с Windows. Linux и Mac OS. Рецепты могут быть как написаны вручную, так и скачаны с сайта и при необходимости отредактированы - на портале имеется огромное множество готовых решений, при помощи которых можно выполнить большинство задач. Также плюсом работы с Chef можно назвать удобную и подробную документацию. Пользовательский веб-интерфейс достаточно функционален и позволяет отслеживать состояние узлов, назначать и отменять рецепты, удалять узлы.
В отличие от Puppet, у Chef пока нет хорошо реализованной функции push. Таким образом, агенты должны быть настроены на периодическую синхронизацию с головным сервером, и немедленное применение изменений невозможно. Также можно назвать недостатком системы необходимость в большом количестве вспомогательного ПО.
На данный момент Chef считается не слишком безопасной системой конфигурирования: в сети имеются сведения об уязвимостях, которые позволяют удаленному пользователю обойти ограничения безопасности [1], совершить спуфинг атаку, получить доступ к определенной конфиденциальной информации, вызвать отказ в обслуживании и выполнить произвольный код на целевой системе. Большинство уязвимостей связаны не непосредственно с Chef, а с компонентами и библиотеками, входящими в его состав (LibYAML, libcurl и др.).
3. Puppet
С точки зрения общей концепции, Puppet похож на Chef. В нем также имеется головной сервер и управляемые ноды. Функционал Puppet не менее широк, чем у Chef. Как и Chef, Puppet имеет большой ассортимент готовых модулей, которые можно скачать и использовать. Подключение клиента к серверу возможно при помощи SSL сертификатов (англ. Secure Sockets Layer — криптографический протокол, обеспечивающий безопасность соединения). Удаленная машина посылает запрос, а локальная подписывает сертификат. После этого управляющая машина может изменять конфигурацию управляемой (по умолчанию состояние синхронизируется l раз в 3G минут, но также Puppet имеет хорошо развитый механизм моментального изменения конфигурации при помощи команды puppet agent). Обмен данными происходит по HTTPS (англ. HyperText Transfer Protocol Secure, расширение протокола HTTP, поддерживающее шифрованные транспортные механизмы SSL и TLS). Как и Chef, Puppet нуждается в достаточно большом количестве дополнительного ПО.
Существует обзор уязвимостей, позволяющих удаленному пользователю обойти ограничения безопасности [2], совершить спуфинг атаку, получить доступ к определенной конфиденциальной информации и вызвать отказ в обслуживании, однако на официальном сайте Puppet есть сведения об устранении этих уязвимостей в более поздних версиях.
4. Ansible
Ansible не требует установки агентов на управляемые узлы — все функции производятся по SSH. Конфигурация Ansible предполагает два элемента: локальную машину (управляющую) и удаленные машины (управляемые). После установки Ansible администратор создает списки (группы) управляемых машин, указывая их адреса в специальном inventory файле. Авторизованные ключи SSH привязываются к каждому узлу, относясь к пользователю, от имени которого будет запускаться Ansible. После этого головной сервер может соединяться с узлами по протоколу SSH и выполнять все необходимые задачи. Для работы с системами, не позволяющими выполнять доступ с правами суперпользователя (root) по SSH, Ansible использует учетные данные, выполняющие действия от имени суперпользователя с помощью команды sudo. Для запуска сценария необходимо два файла: playbook (что делать) и inventory (где делать). Некоторые простые задачи могут быть запущены прямо из командной строки, без использования playbook. Ansible существенно проще в изучении и использовании, чем Puppet и Chef, что является существенным плюсом при выборе системы автоматической установки и конфигурирования.
В Ansible также есть набор модулей. Дополнительные модули могут быть написаны на практически любом языке программирования, при условии, что вывод будет в формате JSON (англ. JavaScript Object Notation -текстовый формат обмена данными, основанный на JavaScript, используемый для сериализации сложных структур). Веб-интерфейс доступен в виде
AnsibleWorksAWX, но напрямую не связан с интерфейсом командной строки. Таким образом, элементы конфигурации, заданные через командную строку, не появятся в веб-интерфейсе до тех пор, пока не будет запущен цикл синхронизации. Для этого можно использовать встроенную утилиту cron. Веб-интерфейс достаточно функционален, но не такой содержательный как интерфейс командной строки, таким образом можно либо переключаться между обоими, либо же просто использовать командную строку. Из неудобств Ansible можно отметить отсутствие совместимости с Windows.
Существуют сведения об обнаружении в Ansible одной уязвимости, связанной с превышением локальным пользователем своих привилегий на целевой системе [3]. Уязвимость обусловлена ошибками в фильтрации приложением команды плагина lookup.
5. Сравнение
На данный момент рынок предлагает несколько мощных инструментов автоматической установки и конфигурирования, обладающих достаточно полным функционалом для решения большинства боевых задач даже на 10000 и большем количестве управляемых машин, однако в процессе работы с такими инструментами возникают некоторые сложности. При работе с Chef иногда возникают проблема с неявным оповещением администратора о возникающих ошибках. Данная проблема в основном затрагивает начинающих пользователей. Допустим, мы запускаем cookbook, который удаляет файл helloworld.txt с удаленной машины, на нескольких машинах сразу. На одной из машин такой файл отсутствует. Что сделает Chef в такой ситуации? Он просто пропустит выполнение действия (удаление файла) на машине, на которой он отсутствует, и продолжит выполнение дальше. В таком случае заметить сбой в работе без использования специального ПО для мониторинга и не проводя анализ лог-файлов достаточно сложно. При работе Chef выводит отчет о работе в консоль, и в случае машины с отсутствующим файлом сообщение об удалении файла выведено не будет, но заметить пропущенную строчку достаточно сложно, а если администратор работает с большим количеством управляемых узлов (порядка 50 и более) - то и вовсе невозможно. Ситуация значительно усугубляется, если cookbook описывает более сложное поведение, если на машинах выполняется более одного рецепта одновременно, а также если их запуск осуществляется не вручную, а автоматически (например, через cron). У Chef а есть два механизма отчета об ошибках: логирование и использование хендлеров. В лог-файлах фиксируются события, происходящие при работе дополнительного ПО: nginx. Postgress и т.д, в то время как для контроля работы утилиты chef knife, непосредственно вносящей изменения в конфигурацию всех управляемых узлов, предназначены хендлеры — обработчики событий. Для их использования необходимо создать отдельный файл, в котором написано, каким именно образом Chef должен реагировать на наступление того или иного события. Например, можно указать, что в
случае некорректного завершения работы необходимо отправить вам email с уведомлением. С одной стороны, подобный подход упрощает работу администратора, ведь в этом случае Chef проинформирует только о действительно важных проблемах, но с другой стороны, существует мнение, что отчет об ошибках должен быть более точным и детальным. При работе с хендлерами возможны две проблемы: не нашлось подходящего обработчика для описания возможной ситуации, или администратор забыл написать необходимый код или не предвидел наступления какой-либо ситуации. В таком случае, как и было написано выше, Chef не оповестит администратора о несоответствии состояния машины логике исполняемого решения. Исключением станет только тот случай, в котором утилита chefknife завершила работу с ошибкой. Puppet ведет себя аналогично.
В отличие от Puppet и Chef, Ansible ведет себя другим образом: по завершению работы он предоставляет отчет, содержащий информацию о том, на каких узлах выполнение playbook'а прошло успешно, а на каких -нет; также в тексте отчета будет точно указана причина ошибки и место в коде, вызвавшее ошибку. Однако при работе с Ansible возникает другая проблема: если какая-то задача (task в терминологии Ansible) не выполнилась и создала ошибку, то playbook полностью приостановит работу на данной машине и все следующие задачи выполнены не будут. На данный момент многие разработчики и администраторы видят решение описанных проблем в использовании одновременно двух инструментов: Puppet или Chef в сочетании с Ansible. Хорошим решением стал бы инструмент, который сообщает администратору о возникших неожиданностях ситуациях, но при этом переходящий к следующей задаче при сбое предыдущей.
б. Заключение
На данный момент существует достаточно большой выбор инструментов для автоматизированной установки и конфигурации серверных решений. При выборе инструмента следует ориентироваться на целевую установку решений определенного круга задач, при этом для работы с популярными сервисами и утилитами (nginx, apache, JVM, mysql, apt, sudo) предпочтительнее использовать готовые решения, которые можно найти в сообществе на сайте выбранного инструмента.
Список литературы
1. Басыня Е. А. Самоорганизующаяся система управления трафиком вычислительной сети / Е. А. Басыня, Г. А. Французова, А. В. Гунько // Доклады Томского государственного университета систем управления и радиоэлектроники. - 2G14. - № 1 (31). - С. 179-184.
2. Сафронов А. В. Применение метода согласования балансов для повышения эффективности информационно - измерительной системы при опредлении ТЭП ТЭЦ / А. В. Сафронов // Сборник трудов ХVII Международной научно-практической конференции студентов, аспирантов и молодых ученых. 9-13 апреля 2G12, Томск: Изд-во ТПУ, 2G12. - С.237 - 238.
3. Basinya E. A. Methods of self-organization in providing network security / E. A. Basinya, G. A. Frantsuzova, A. V. Gunko // Global Science and Innovation: materials of the 1 intern. sci. conf., USA, Chicago, 17-18 Dec. 2G13. - Chicago: Accent Graphics communications 2G13. - Vol. 2. - P. 386389.
Basinya Evgeny Alexandrovich, PhD, prof. (e-mail: basinya@corp.nstu.ru)
Novosibirsk State Technical University, Novosibirsk, Russia Lukina Margarita Sergeevna, student (e-mail: luckinamargo@gmail.com)
Novosibirsk State Technical University, Novosibirsk, Russia AUTOMATIC DEPLOYMENT OF SERVER SOFTWARE
Abstract. This article describes automatic deployment of server software, using Chef, Puppet and Ansible — three most widely used tools — as an example. Deployment tools are a relatively recent concept, yet they quickly gained popularity and now they are utilized in most software projects. This explains the importance of the task and its relevance to all software engineering.
Key words: design, automation, deployment, Chef, Puppet, Ansible.
РАЗРАБОТКА МОДУЛЯ СИСТЕМЫ ОБНАРУЖЕНИЯ И ПРЕДОТВРАЩЕНИЯ ВТОРЖЕНИЙ Басыня Евгений Александрович, к.т.н., доцент (e-mail:basinya@corp.nstu.ru) Равтович Юлия Константиновна, студент (e-mail: julka.r575@gmail.com) Новосибирский государственный технический университет,
г.Новосибирск, Россия
В данной работе рассматриваются методы и средства обеспечения информационной безопасности локальной вычислительной сети и реализация на их основе модуля системы обнаружения и предотвращения вторжений, представленного в виде обманной системы.
Ключевые слова: система обнаружения и предотвращения вторжений, сканирование, зондирование, обманная система.
ВВЕДЕНИЕ
Расширение спектра сетевых угроз порождает необходимость использования комплексных систем управления безопасностью локальных вычислительных сетей (ЛВС). Важным элементом безопасности сетей являются системы обнаружения и предотвращения вторжений (IDS/IPS - англ. Intrusion detection system / Intrusion prevention system), представляющие собой комплекс программных и/или аппаратно-программных средств, осуществляющий выявление, анализ и предотвращение вредоносной активности (попыток несанкционированного доступа, вывода хоста из строя и т.д.). Функции данных инструментов включают в себя превентивное воздействие с уведомлением об ответственности, блокировку источника атак, протоколирование существующих угроз сети, сбор информации об осуществленных проникновениях для дальнейшего анализа и устранения факторов, послуживших их причиной и т.д. Однако система обнаружения и предотвращения вторжений не обеспечивает гарантированную безопасность
