Документ описывает управление облачной инфраструктурой и системы управления конфигурацией, включая выполнение команд на множестве серверов, развертывание приложений и управление объектами ОС. Приведены примеры использования скриптов и distributed shells для автоматизации процессов, а также обсуждаются преимущества и недостатки различных подходов к развертыванию ПО. Затронуты системы управления конфигурацией, такие как Puppet и Chef, и их применение для описания конфигураций серверов.

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

2. Задачи
1. Выполнение типовых команд на
множестве серверов
2. Развертывание собственного ПО на
множестве серверов
3. Управление объектами (ресурсами)
множества ОС

3. 1. Выполнение типовых команд
Примеры:
• обновление системы:
– yum update;
– aptitude full-upgrade и т.д.
• заливка нового конфигурационного файла:
– yum.conf, sources.list;
– resolv.conf.
– ntp.conf и т.д.

4. 1.1. Использование скриптов
Например:
for veid in {101..105}; do
vzctl exec $veid команда
done
Преимущества Недостатки
Простота Скрипт нужно запускать на каждом
хосте отдельно

5. 1.2. Использование distributed shells
yum update
Преимущества Недостатки
Сервера адресуются по имени или IP, Требуется дополнительная
т.е. нет привязки к их расположению конфигурация на сервере (sudoers)
Полностью работает только в
гомогенных средах

6. 1.2.1. Использование distributed shells
Например: dsh или pdsh
Запрос:
$ pdsh -R ssh -w mvio.ru,nagios.reic.ru ls
Ответ:
nagios.reic.ru: Projects
mvio.ru: build
mvio.ru: Projects

7. 2. Развертывание собственного ПО
Машина
Сервер
разработчика
Действия:
1. копирование на сервер (scp, rsync, tar c, git push);
2. сборка на сервере (tar x, git merge);
3. перезапуск приложения.

8. 2.1. Развертывание собственного ПО
Тестовый
сервер
Машина
разработчика
Василия Центральный Рабочий
репозиторий сервер 1
Машина
разработчика
Петра Рабочий
сервер 2
Для более сложной архитектуры удобнее
использовать специальные инструменты

9. 2.2. Развертывание собственного ПО
Для различных ЯП и платформ используются свои
инструменты для сборки и развертывания:
• Python – Fabric;
• Ruby – Capistrano;
• Java – Ant, Maven …
Преимущества
Можно гибко конфигурировать в зав-ти от типа/роли (test, prod) сервера
Развертывание на несколько серверов параллельно

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

11. Web-прокси
(nginx)
1-й вариант конфигурации:
Электронный секретарь
Java-приложение
(mvio-web)
Web-прокси У всех вариантов
(nginx) 2-й вариант конфигурации: конфигурации Nginx
Биллинг BGBilling есть общие части и
Java-приложение
(BGBilling)
части специфические!
Web-прокси
3-й вариант конфигурации: (nginx)
Сайт maestrotelecom.ru
PHP-приложение
(сайт)

12. Отсюда – разные потребности:
• изменение общих частей конфигурации
(например, нужно добавить защиту от
DDOS-атак);
• изменение специфических частей
конфигурации (увеличить размер буфера
для пользовательских данных на портале
«Электронный секретарь»).

13. Решение №1:
• для общих частей использовать собственные пакеты (т.е.
взять и включить типовую конфигурацию nginx в rpm-
пакет nginx).
• cпецифические части хранить в отдельном репозитории.
Недостатки
Приходится самому поддерживать пакеты (т.е. отслеживать обновления
исходного ПО и уязвимости ПО)
Куча ручной работы по изменению конфигурационных файлов (либо нужно
писать специальные скрипты с использованием distributed shells)

14. Решение №2:
• использование SCM (Software Configuration Management)
или системы управления конфигурацией ПО.
Основной подход – описание объектов системы на
абстрактном языке.
Пользователь Сервис (nginx) Настройки сети
user paul { service nginx { file interfaces {
uid 1000 name test.reic.ru int 01
comment Pavel port 80 name eth1
home /home/paul ssl yes speed 100
shell /bin/bash template nginx- mode full-duplex
… std.conf }
} }

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

16. Работа SCM (Chef)
Сервер 1
Машина Команды Хранилище
администратора Сервер 2
конфигураций
Евгения
Сервер 3

17. Две SCM-системы
Puppet Chef
• Имеет долгую историю, вырос • Более свежий проект, взял
из cfengine многое из Puppet
• Декларативный, более • Императивный, более подходит
подходит для администратора для программиста
• В «рецептах» используется DSL • В «рецептах» используется Ruby
(«птичий язык»), расширяемый • Коммерциализация – SaaS-
на Ruby модель
• Коммерциализация – • Более удобен для
расширенная версия с web- развертывания приложений из
интерфейсом VCS-репозиториев

18. Установка пакета “play-framework” и
библиотеки “asterisk-java” в Puppet
# Install Play! Framework
package { "play-framework":
ensure => present
}
# Install asterisk-java module
file { "/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,
}

19. Установка пакета “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
end
end
cookbook_file "/opt/asterisk-java/target/asterisk-java.jar" do
source "asterisk-java.jar"
owner "root"
group "root"
mode 0644
end