5. Configuration Management
Bad-bad story...
Что случилось?
● сайт упал и
не поднимается
● все настройки умерли
вместе с сервером
● … а это был не один сервер
● …
● админ в запое
● … идт
6. Configuration Management
В чем проблема?
●
●
●
●
●
●
●
●
пакеты ставятся руками
каждый конфиг настраивается тоже руками (vim, nano…)
install_all_packages_on_this_server.sh или bootstrap.sh
серверы могут быть разные (OS, roles, services)
компьютеров становится все больше, а рук не прибавляется
документация по настройке конкретного сервера(или сервиса) почти
всегда отсутствует
отсутствуют инструменты тестирования окружения
мониторинг ?..
8. Configuration Management
Почему Chef:
● Эффективность
все настройки и конфигурации лежат в одном месте
● Масштабируемость
разделение на окружения, роли и ноды
● Повторное исползование
создаем ноду и через несколько минут имеем готовый инстанс
● Документация
рецепты хранят всю информацию о вашем окружении
9. Configuration Management
Еще плюсы:
+ Меньше ошибок
+ Возможность тестирования
+ Версионность
+ Гибкость
+ Большое сообщество
+ Over 1220 готовых (официальных) кукбуков
10. Configuration Management
Что Chef не может:
● Магическим образом настроить ваш сервер
● Безрассудно использовать кукбуки и рецепты
● Мониторить ваши сервера и приложения
● Использовать концепцию “отката”
11. Configuration Management
Infrastructure as code:
●
Управление инфраструктурой как идемпотентным
Ресурсом (Resource)
●
Складываем все в Рецепты (Recipe)
●
Настраивайте ваши серверы и запускайте
интегрированную инфраструктуру
●
Отслеживайте и управляйте инфраструктурой как исходным кодом
●
Ruby DSL(Domain Specific Language)
13. Configuration Management
Терминология:
Ресурсы (Resources)
●
имеет определенный тип
●
у него есть имя
●
а также аттрибуты
●
выполняет действия
19 #...
20 package “nginx” do
21
version “1.4.4”
22
action :install
23 end
для приведения ресурса
в нужное состояние
35 #...
36 service “nginx” do
37
action [:enable, :start]
38 end
14. Configuration Management
Терминология:
Провайдеры (Providers)
●
Провайдеры описывают поведение ресурсов
●
Вы описываете “ЧТО” должно быть сделано вместо “КАК” делать
●
Несколько провайдеров для каждого типа ресурсов
(apt, yum, rubygems, portage, macports, и т.д.)
●
Ресурсы > Платформа > Провайдер
15. Configuration Management
Терминология:
Рецепты (Recipes)
●
Это коллекция
ресурсов
●
Код рецептов
повторно используется
и имеет блочную структуру
case node[‘platform_family’]
when ‘rhel’
package ‘ImageMagick’
when ‘debian’, ‘mac_os_x’
package ‘imagemagick’
end
dev_pkg = value_for_platform(
[‘redhat’, ‘fedora’] => {
‘default’ => “ImageMagick-devel”
},
“ubuntu” => {
“8.04” => “libmagick9-dev”,
“8.10” => “libmagick9-dev”,
“default” => “libmagickwand-dev”
}
)
package dev_pkg
17. Configuration Management
Терминология:
Поваренные книги (Cookbooks)
●
●
●
●
Распределенные
Инфраструктура как код
Обычно - отдельный репозиторий в системе контроля версий
Содержат:
○ Рецепты
○ Активы (файлы/шаблоны) - статические и динамические
○ Аттрибуты
○ Метаданные
20. Configuration Management
Управление данными:
Аттрибуты (Attributes)
●
Многоуровневый хэш настроек
●
Могут быть использованы в узлах, ролях, поваренных книгах,
окружениях
Пример:
ssh-cookbook использует 22 порт как основной, но в окружении
“production” мы переопределяем его на 2022
22. Configuration Management
Можно использовать для создания/настройки:
●
Простых внутренних приложений
●
Сложных многоуровневых и распределенных приложений
●
Рабочих станций
●
Hadoop кластеров
●
Iaas, Paas инфраструктур
●
Систем хранения данных
●
Систем обработки данных
●
и многое другое ...
26. Application Deployment
Что нужно сделать, чтобы развернуть простое приложение?
1.
скопировать (scp|ftp|...) ваше приложение на удаленный сервер(-ы)
2.
перезапустить сервер(-ы) если надо
3.
Профит!
4.
Новый релиз? GOTO 1
5.
Серверов много больше 1 ?
27. Application Deployment
А если подробнее?
мы закачивали все архивом, надо распаковать
… заменить текущую директорию или изменить настройки сервера
… а еще у нас базы надо обновить, накатить миграции
… ничего не забыл? … ах, да… оповестить всех надо же…
… когда что-то пошло не так - хватаемся за голову …
downtime растет, нервы портятся, количество седых волос увеличивается
28. Application Deployment
А если подробнее?
мы закачивали все архивом, надо распаковать
… заменить текущую директорию или изменить настройки сервера
… а еще у нас базы надо обновить, накатить миграции
… ничего не забыл? … ах, да… оповестить всех надо же…
… когда что-то пошло не так - хватаемся за голову …
downtime растет, нервы портятся, количество седых волос увеличивается
30. Application Deployment
Что такое Capistrano?
●
open source инструмент для запуска команд на одном/нескольких
серверах
●
преимущественно для деплоя web приложений
●
написан на Ruby и распространяется как ruby gem
●
обычно используется сомвестно с Rails, но не ограничивается ими.
31. Application Deployment
Что нам дает Capistrano?
●
●
●
●
●
●
●
возможность писать скрипты вида
“через ssh на нужной машине сделай это и это”
у вас не будет магических скриптов, которые живут на той машине
возможность хранить вместе с проектом в системе контроля версий
автоматизировать крупные и сложные задачи
одновременно работать с несколькими серверами
… разделять их по ролям
тестировать перед деплоем
опять же повторяемость (вы новичок в команде, коллега заболел…)
32. Application Deployment
Подготовка окружения/приложения:
●
●
●
Актуализируете ваше приложение в системе контроля версий
Уберите из публичного доступа пароли, ключи и остальные важные
данные
Инициализируйте Capistrano для вашего приложения
$ cd my-project
$ cap install
●
Задайте адреса серверов для определенных ролей в настройках
35. Application Deployment
Подготовка окружения/приложения:
●
●
●
Актуализируете ваше приложение в системе контроля версий
Уберите из публичного доступа пароли, ключи и остальные важные
данные
Инициализируйте Capistrano для вашего приложения
$ cd my-project
$ cap install
●
●
Задайте адреса серверов для определенных ролей в настройках
Общая информация должна храниться в deploy.rb