Управление облачной инфраструктурой

Системы управления конфигурацией ПО

Задачи

1. Выполнение типовых команд на множестве серверов

2. Развертывание собственного ПО на множестве серверов

3. Управление объектами (ресурсами) множества ОС

1. Выполнение типовых команд

Примеры:• обновление системы:– yum update;– aptitude full-upgrade и т.д.

• заливка нового конфигурационного файла:– yum.conf, sources.list;– resolv.conf.– ntp.conf и т.д.

1.1. Использование скриптов

Например:for veid in {101..105}; dovzctl exec $veid команда

done

Преимущества НедостаткиПростота Скрипт нужно запускать на каждом

хосте отдельно

1.2. Использование distributed shells

yum update

Преимущества НедостаткиСервера адресуются по имени или IP, т.е. нет привязки к их расположению

Требуется дополнительная конфигурация на сервере (sudoers)Полностью работает только в гомогенных средах

1.2.1. Использование distributed shells

Например: dsh или pdshЗапрос:$ pdsh -R ssh -w mvio.ru,nagios.reic.ru ls

Ответ:nagios.reic.ru: Projectsmvio.ru: buildmvio.ru: Projects

2. Развертывание собственного ПО

Действия:1. копирование на сервер (scp, rsync, tar c, git push);2. сборка на сервере (tar x, git merge);3. перезапуск приложения.

Машина разработчика Сервер

2.1. Развертывание собственного ПО

Для более сложной архитектуры удобнее использовать специальные инструменты

Машина разработчика

Василия

Тестовый сервер

Машина разработчика

Петра

Центральныйрепозиторий

Рабочий сервер 1

Рабочийсервер 2

2.2. Развертывание собственного ПО

Для различных ЯП и платформ используются свои инструменты для сборки и развертывания:

• Python – Fabric;• Ruby – Capistrano;• Java – Ant, Maven …

ПреимуществаМожно гибко конфигурировать в зав-ти от типа/роли (test, prod) сервера

Развертывание на несколько серверов параллельно

3. Управление объектами (ресурсами) ОС

Объекты управления (ресурсы):• пакеты ПО (apache, nginx, syslog, ntp …);• конфигурация этого ПО;• пользователи и группы;• сетевая конфигурация;• другие параметры.

Web-прокси (nginx)

Java-приложение(mvio-web)

1-й вариант конфигурации:Электронный секретарь

Web-прокси (nginx)

Java-приложение(BGBilling)

2-й вариант конфигурации:Биллинг BGBilling

Web-прокси (nginx)

PHP-приложение(сайт)

3-й вариант конфигурации:Сайт maestrotelecom.ru

У всех вариантовконфигурации Nginx есть общие части и части специфические!

Отсюда – разные потребности:• изменение общих частей конфигурации

(например, нужно добавить защиту от DDOS-атак);

• изменение специфических частей конфигурации (увеличить размер буфера для пользовательских данных на портале «Электронный секретарь»).

Решение №1:• для общих частей использовать собственные пакеты (т.е.

взять и включить типовую конфигурацию nginx в rpm-пакет nginx).

• cпецифические части хранить в отдельном репозитории.

НедостаткиПриходится самому поддерживать пакеты (т.е. отслеживать обновления исходного ПО и уязвимости ПО)Куча ручной работы по изменению конфигурационных файлов (либо нужно писать специальные скрипты с использованием distributed shells)

Решение №2:• использование SCM (Software Configuration Management)

или системы управления конфигурацией ПО.

Основной подход – описание объектов системы на абстрактном языке.

Пользователь Сервис (nginx) Настройки сети

user paul { uid 1000 comment Pavel home /home/paul shell /bin/bash …}

service nginx { name test.reic.ru port 80 ssl yes template nginx-std.conf}

file interfaces { int 01 name eth1 speed 100 mode full-duplex}

В системе SCM должны быть описаны ВСЕ специфические объекты конфигурации (те, которые отличаются от стандартных).

Другими словами, в SCM-системе хранится точный функциональный образ системы (сервера).

Из SCM-системы можно в любой момент получить копию работоспособного сервера, выполняющего нужные нам задачи.

Работа SCM (Chef)

Машина администратора

Евгения

Сервер 1

Хранилище конфигураций Сервер 2

Сервер 3

Команды

Две SCM-системы

Puppet• Имеет долгую историю, вырос

из cfengine• Декларативный, более

подходит для администратора• В «рецептах» используется DSL

(«птичий язык»), расширяемый на Ruby

• Коммерциализация – расширенная версия с web-интерфейсом

Chef• Более свежий проект, взял

многое из Puppet• Императивный, более подходит

для программиста• В «рецептах» используется Ruby• Коммерциализация – SaaS-

модель• Более удобен для

развертывания приложений из VCS-репозиториев

Установка пакета “play-framework” и библиотеки “asterisk-java” в Puppet

# Install Play! Frameworkpackage { "play-framework": ensure => present}

# Install asterisk-java modulefile { "/opt/asterisk-java": ensure => "directory", owner => "root", group => "root", mode => 0755,}file { "/opt/asterisk-java/target": ensure => "directory", owner => "root", group => "root", mode => 0755,}file { "/opt/asterisk-java/target/asterisk-java.jar": source => "puppet:///modules/git-repo/asterisk-java.jar", owner => "root", group => "root", mode => 0644,}

Установка пакета “play-framework” и библиотеки “asterisk-java” в Chef

package "play-framework"

# Install asterisk-java module%w{/opt/asterisk-java /opt/asterisk-java/target}.each do |dir| directory "#{dir}" do owner "root" group "root" mode 0755 action :create endendcookbook_file "/opt/asterisk-java/target/asterisk-java.jar" do source "asterisk-java.jar" owner "root" group "root" mode 0644end