При большом количестве серверов и виртуальных машин и еще большем количестве кода в постоянном деплое, неизбежно возникают проблемы администрирования всего этого огромного хозяйства. Существует множество инструментов, позволяющих организовать continuous integration. В нашем списке точно уже есть GIT, Jenkins, Chef, Proxmox, Graylog2. Сегодня мы расскажем еще об одном удобном инструменте для автоматизации рутинных задач с помощью сценариев — rundeck. Эта статья — не подробный мануал с примерами конфигов, а скорее размышления на тему.
Rundeck — это open source проект, который позволят системному администратору организовать некий сервер сценариев, автоматизируя рутинные и шаблонные работы. Фактически, это — ключ от всех дверей. Он позволяет на любом количестве нод выполнить скрипты или shell команды, проконтролировать их выполнение и развернуто рассказать администратору о каждом действии, успешном или нет. Rundeck объединяет все уже используемые инструменты и позволяет организовать прозрачное взаимодействие между ними.
— распределенное выполнение команд и скриптов с параметрами,
— поддержка нескольких механизмов для взаимодействия с нодой (ssh по умолчанию) и возможность написать свои в виде плагинов,
— сценарий может описан несколькими шагами,
— графический интерфейс управления и консольные утилиты для настройки,
— разделение прав доступа, интеграция с LDAP/AD,
— история и аудит сценариев и команд,
— интеграция с другими инструментами continuous integration — jenkins, chef,
— API,
— возможность взять все параметры и настройки по url с удаленного узла.
— это сервер и это java. Здесь вся логика, аутентификация и права доступа для пользователей, консольные утилиты управления и веб-интерфейс управления (правда не очень удобный),
— сценарии, результаты аудита и все логи хранятся в базе данных,
— для взаимодействия с нодами используется ssh по ключам. При этом обратное ssh соединение нода-сервер не требуется.
Работает это почти везде:
— linux,
— Windows XP, Server и новее,
— Mac OS X 10.4 и новее.
Установка и настройка тривиальна, все конфиги хранятся в файлах.
Наш пример использования, интеграция с chef. Проблемы и пути решения.
Небольшое лирическое отступление про chef. Рецепты, ноды, environment — это все работает в теории почти без проблем. Проблемы начинаются в реальном production. Связность компонентов системы оказывается неожиданно высока, некоторые модули очень сильно зависят от других. В условиях гео-кластера и распределенных датацентров необходимо учитывать множество факторов. Скорость сети, скорость доступа к ноде из разноудаленных географических точек, тайм зоны. При больших аудиториях может использоваться split deploy, когда новая фишечка показывается только определенным регионам и только в определенное время.
В таких реалиях chef уже перестает спасать и больше вредит. Рецептов становится слишком много. Мест, где можно ошибиться все больше. Параметров, окружений и флажков к рецептам — больше, чем рецептов. Приходится заводить длинные и пространные таблицы, где разноцветным фломастером будет описана схема наших боевых действий. Куда, где и во сколько мы что задеплоили и зачем. Однажды мы все же сплитнули не туда, что привело к пониманию того, что chef тоже надо автоматизировать и что им тоже уже надо управлять.
В рецептах было много логики, чтобы преодолеть высокую связность компонентов. Нода выключается из апстрима, подготавливает свой код и начинает деплоиться. На каком-то определенном шаге необходимо изменить состояние другого модуля, например — переиндексировать данные для нового кода. После переиндексации мы сразу же тушим еще одну ноду и подготавливаем ее к split тестированию. В это время первая нода заканчивает свой деплой и проходит финальное тестирование, после чего включается в апстрим. При этом должна быть уже готова база данных, где миллион транзакций что-то при этом апдейтило. Все это надо выполнить практически одновременно, при этом практически синхронно. Chef такое вроде как умеет, но это неудобно и приходится использовать слишком много логики в рецептах. Обмениваться сигналами, общими аттрибутами, флажками и понимать на каждом этапе в каком состоянии у нас соседи и что делать дальше.
Что нам дает rundeck.
1. Создаем проект
2. Импортим туда все ноды из chef со всеми рецептами. Для этого есть готовый инструмент.
3. Создаем сценарии, которые все сделают сами и проследят, что не поломалась связность при деплое. Включат, выключат, синхронизируют, пнут чефа и отрапортуют администратору о каждом своем шаге.
4. Profit.
Для этого необходимо настроить аутентификацию по ключам. Понять что и как должен делать непривилегированный пользователь, настроить sudo. Или запихать его в chroot. Ну и написать кучу магических скриптов на любом языке. Perl, python, bash, php ))) Также можно включить остановку выполнения сценария после неудачного шага. Сценарии можно писать какие угодно. Тут все зависит от фантазии и стоящих перед вами задач.
Rundeck может работать в двух режимах. Задачи можно выполнять либо параллельно на всех нодах сразу, либо последовательно, закончили с одной — переходим к другой.
Node-oriented
1. NodeA step#1
2. " step#2
3. " step#3
4. NodeB step#1
5. " step#2
6. " step#3
Step oriented
1. NodeA step#1
2. NodeB "
3. NodeA step#2
4. NodeB "
5. NodeA step#1
6. NodeB "
Rundeck умеет выполнять команды и скрипты с аргументами, а их в свою очередь брать с удаленного url, как и остальные настройки. Также при помощи API можно управлять только теми штуками, которые нужны, не открывая webUI. К тому же он тут не слишком удобен.
Большим плюсом данного решения является то, что состояние системы в целом и по отдельности в любой момент контролируется из одной точки. И может быть принудительно изменено, также из одной точки. Без необходимости ssh-иться на мегатонны серверов.
Из минусов — еще один компонент из серии мониторим мониторинг мониторинга и управляем деплоем деплоя системы деплоя. Усложнение — это почти всегда плохо. Нужно четко понимать схему всей системы и компонентов в отдельности. Иначе есть шанс наскриптовать таких чудес, что даже увольнение будет недостаточной мерой наказания. Также надо четко и ясно выстроить схему безопасности. И разрешить пользователю только то, что надо разрешить. Ключ от всех дверей — это удобно, но как бы не получилось так, что «мы вот супер ученые и придумали ядреную бомбу. Но если она попадет не в те руууки...»
Ссылки
— Chef
— Rundeck
Rundeck — это open source проект, который позволят системному администратору организовать некий сервер сценариев, автоматизируя рутинные и шаблонные работы. Фактически, это — ключ от всех дверей. Он позволяет на любом количестве нод выполнить скрипты или shell команды, проконтролировать их выполнение и развернуто рассказать администратору о каждом действии, успешном или нет. Rundeck объединяет все уже используемые инструменты и позволяет организовать прозрачное взаимодействие между ними.
Особенности:
— распределенное выполнение команд и скриптов с параметрами,
— поддержка нескольких механизмов для взаимодействия с нодой (ssh по умолчанию) и возможность написать свои в виде плагинов,
— сценарий может описан несколькими шагами,
— графический интерфейс управления и консольные утилиты для настройки,
— разделение прав доступа, интеграция с LDAP/AD,
— история и аудит сценариев и команд,
— интеграция с другими инструментами continuous integration — jenkins, chef,
— API,
— возможность взять все параметры и настройки по url с удаленного узла.
Архитектура:
— это сервер и это java. Здесь вся логика, аутентификация и права доступа для пользователей, консольные утилиты управления и веб-интерфейс управления (правда не очень удобный),
— сценарии, результаты аудита и все логи хранятся в базе данных,
— для взаимодействия с нодами используется ssh по ключам. При этом обратное ssh соединение нода-сервер не требуется.
Работает это почти везде:
— linux,— Windows XP, Server и новее,
— Mac OS X 10.4 и новее.
Установка и настройка тривиальна, все конфиги хранятся в файлах.
Наш пример использования, интеграция с chef. Проблемы и пути решения.
Небольшое лирическое отступление про chef. Рецепты, ноды, environment — это все работает в теории почти без проблем. Проблемы начинаются в реальном production. Связность компонентов системы оказывается неожиданно высока, некоторые модули очень сильно зависят от других. В условиях гео-кластера и распределенных датацентров необходимо учитывать множество факторов. Скорость сети, скорость доступа к ноде из разноудаленных географических точек, тайм зоны. При больших аудиториях может использоваться split deploy, когда новая фишечка показывается только определенным регионам и только в определенное время.
В таких реалиях chef уже перестает спасать и больше вредит. Рецептов становится слишком много. Мест, где можно ошибиться все больше. Параметров, окружений и флажков к рецептам — больше, чем рецептов. Приходится заводить длинные и пространные таблицы, где разноцветным фломастером будет описана схема наших боевых действий. Куда, где и во сколько мы что задеплоили и зачем. Однажды мы все же сплитнули не туда, что привело к пониманию того, что chef тоже надо автоматизировать и что им тоже уже надо управлять.
В рецептах было много логики, чтобы преодолеть высокую связность компонентов. Нода выключается из апстрима, подготавливает свой код и начинает деплоиться. На каком-то определенном шаге необходимо изменить состояние другого модуля, например — переиндексировать данные для нового кода. После переиндексации мы сразу же тушим еще одну ноду и подготавливаем ее к split тестированию. В это время первая нода заканчивает свой деплой и проходит финальное тестирование, после чего включается в апстрим. При этом должна быть уже готова база данных, где миллион транзакций что-то при этом апдейтило. Все это надо выполнить практически одновременно, при этом практически синхронно. Chef такое вроде как умеет, но это неудобно и приходится использовать слишком много логики в рецептах. Обмениваться сигналами, общими аттрибутами, флажками и понимать на каждом этапе в каком состоянии у нас соседи и что делать дальше.
Что нам дает rundeck.
1. Создаем проект 2. Импортим туда все ноды из chef со всеми рецептами. Для этого есть готовый инструмент.
3. Создаем сценарии, которые все сделают сами и проследят, что не поломалась связность при деплое. Включат, выключат, синхронизируют, пнут чефа и отрапортуют администратору о каждом своем шаге.
4. Profit.
Для этого необходимо настроить аутентификацию по ключам. Понять что и как должен делать непривилегированный пользователь, настроить sudo. Или запихать его в chroot. Ну и написать кучу магических скриптов на любом языке. Perl, python, bash, php ))) Также можно включить остановку выполнения сценария после неудачного шага. Сценарии можно писать какие угодно. Тут все зависит от фантазии и стоящих перед вами задач.
Rundeck может работать в двух режимах. Задачи можно выполнять либо параллельно на всех нодах сразу, либо последовательно, закончили с одной — переходим к другой.
Node-oriented
1. NodeA step#1
2. " step#2
3. " step#3
4. NodeB step#1
5. " step#2
6. " step#3
Step oriented
1. NodeA step#1
2. NodeB "
3. NodeA step#2
4. NodeB "
5. NodeA step#1
6. NodeB "
Rundeck умеет выполнять команды и скрипты с аргументами, а их в свою очередь брать с удаленного url, как и остальные настройки. Также при помощи API можно управлять только теми штуками, которые нужны, не открывая webUI. К тому же он тут не слишком удобен.
Большим плюсом данного решения является то, что состояние системы в целом и по отдельности в любой момент контролируется из одной точки. И может быть принудительно изменено, также из одной точки. Без необходимости ssh-иться на мегатонны серверов.
Из минусов — еще один компонент из серии мониторим мониторинг мониторинга и управляем деплоем деплоя системы деплоя. Усложнение — это почти всегда плохо. Нужно четко понимать схему всей системы и компонентов в отдельности. Иначе есть шанс наскриптовать таких чудес, что даже увольнение будет недостаточной мерой наказания. Также надо четко и ясно выстроить схему безопасности. И разрешить пользователю только то, что надо разрешить. Ключ от всех дверей — это удобно, но как бы не получилось так, что «мы вот супер ученые и придумали ядреную бомбу. Но если она попадет не в те руууки...»
Ссылки
— Chef
— Rundeck
