Ключ от всех дверей в непрерывной интеграции — rundeck

    При большом количестве серверов и виртуальных машин и еще большем количестве кода в постоянном деплое, неизбежно возникают проблемы администрирования всего этого огромного хозяйства. Существует множество инструментов, позволяющих организовать 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
    Поделиться публикацией

    Комментарии 28

      +1
      отличная статья!
      Спасибо
        +1
        вот за что люблю Хабр, так ето за то что нужньіе статьи появляются вовремя.

          +1
          А теперь давайте подробный мануал)
            0
            Подробный мануал слишком большой )) Какую проблему вы не можете решить лучше напишите, можно в личку.
              0
              Проблем никаких нет, пока) Интересны первые шаги для новичков, базовые примеры: развертывание, настройки, примеры сценариев, подводные камни… Т.к. рано или поздно, думаю, многим это может пригодится, а наличие такого мануала поможет быстро вникнуть в суть. А пока я только присматриваюсь к инструментам)
                +1
                Будем значит делать. Но это небыстро )
          • НЛО прилетело и опубликовало эту надпись здесь
              +2
              Несколько датацентров, порядка 60-80 виртуальных машин в бою. Нагрузка 300 рпс в среднем на каждый фронтенд, есть пиковые даты в начале месяца. За фронтендом крутятся различные штуки — php-fpm, много раздатчиков статики в количестве 15 миллионов файлов, кучка постгресов. Различные кэши, где только можно — монга, редис, мемкеш. Spinxsearch поисковым движком и различные самописные узкоспециализированные демоны для локалсерча. Все это географически распределено по стране и зарубежью. Балансировка запросов сделана с помощью lvs, geo-dns. Отказоустойчивость на всех уровнях, начиная с датацентра. Сделано дублированием сервисов. Деплой, надеюсь, скоро будет идеальным, а это значит, что будет все равно куда деплоить и что. Будет плохо — полезем в облако, например.
              Все завязано на наше ядро — API, проекты-сателлиты подключаются, как модули к этому ядру. Есть тенденция перевести на такую схему вообще все наши проекты. Но это тсс почти инсайд ))
              Начинали мы с csync2 и с версионирования конфигов. Потом проектов стало чуть более одного, деплоили руками. Потом пригодился chef. Сейчас как-то так.
                +1
                Крайне интересно. Я сейчас на стадии chef, конфигурации, впрочем, пока простейшие.

                А отчего взялась сложная логика в рецептах? По идее, chef же позиционируется как более, мнэ, концептуально выверенный фреймворк, чем, положим, несколько предшествующий ему исторически puppet. Может быть, рискну предположить исходя из своего опыта, вы исходно начали его «неправильно готовить» и теперь имеете легаси-лапшу к сопровождению?..

                Спасибо, пишите еще :)
                  +1
                  У нас большая связность компонентов. Нужна синхронность и обмен данными о состоянии нод. chef по-другому немного работает, чем бы хотелось. Когда код будет готов к signal based архитектуре и ноды будут между собой общаться сами, например не активировать некоторые интерфейсы, если еще не засинкались обновленные индексы, которых прям много. И в Москву из Новосибирска скорость заливки всего этого медленнее. Нет гарантии, что чеф в Москве, допустим, запустится вовремя и не слишком рано. Или читать из старой таблицы, если новая еще не готова.
                  Сейчас надо либо писать сложные рецепты с обменом информацией через ohaio, либо каким-то образом дирижировать клиентами chef, чтобы они включались когда нужно и деплоили то, что нужно ) Если учесть, что ноды еще и не типовые из-за split тестирования, то довольно сложно разобраться что и где сейчас на бою. Рецепт вроде один, но json с аттрибутами уже не один. Иногда надо быстро что-нибудь отключить или передеплоить. А чефу не прикажешь же. Он висит и ждет. Либо его пинать надо как-то.

                  Да, архитектура не идеальна. Это плата за очень высокую скорость разработки и нам приходится с этим пока жить )
                    0
                    Ага, спасибо. Картинка экосистемы проясняется. А что вы использовали до чефа, из каких скриптов все это эволюционировало?
                    • НЛО прилетело и опубликовало эту надпись здесь
                    • НЛО прилетело и опубликовало эту надпись здесь
                        0
                        Индексы сфинкса, например. Или еще какого движка. Версионность и совместимость можно обеспечить, но это сложно довольно. Синхронность кода, этих самых индексов и базы данных очень нужна, иначе мы покажем пользователю не то, что он запрашивал.

                        Rundeck это как Jenkins, но совсем для системного администратора, в таком ключе их можно сравнить. Мы все забилдили, надо выкладывать же. С десяток нод, есть среди них нетипичные и чем-то отличаются.
                        Рано или поздно процесс выкладки кода вообще перестает быть томным и сделать git clone (git pull) уже недостаточно, надо как-то сконфигурировать фреймоворк, подтюнить пхпшечку, подчистить кэш, но не весь. Чеф поможет.
                        Но чеф не умеет принимать во внимание связность компонентов. Допустим, обновить код на ноде только после того, как переиндексировался сфинкс и новые индексы уже залилились по всем нодам.
                          0
                          Можно на ноды со сфинксом тоже повесить чеф и обмениваться сигналами через огайо. Тут тогда проблема все это синхронизировать. Чеф если висит демоном, и раз в полчаса сервер ему выдает команды, то есть шанс прождать час другой, пока все обменяется сигналами и продолжит деплой. Если запускать вручную, то будет быстрее. Но надо руками тогда заходить и запускать. Если нод болше чем 4, тут долго тоже )))

                          Тут мы поставим рандек и сами нажмем кнопку, когда нам надо синхронизируем.
                            0
                            Зачем руками то заходить? Всегда был Chef-solo, который и позволяет использовать Chef push-подходом.
                              0
                              Дело не в том, какая способ запуска chef используется, а в том, что его нужно запустить на куче нод в определенной последовательности.
                0
                Интересно звучит, поддерживаю реквест подробного мануала.
                Можно пару вопросов?
                • На скриншотах видны проценты выполняемого таска, как они считаются?
                • Jenkins — это прекрасно, но опять-таки медленная и прожорливая до памяти жаба. С buildbot Rundeck умеет интегрироваться?
                  0
                  Не могу понять у кого руки кривые. Пробую использовать sudo в скриптах (то есть там, где в jobs можно добавить большой текстовый скрипт), но rundeck не определяет эти команды
                    0
                    Он скрипт сначала загружает в домашний каталог пользователя, из под которого ссшится, потом его из под него и выполняет. Соответственно все непривилегировано, с полными путями и с правильным sudoers.
                    Момент такой, непростой, тоже помучались )
                    0
                    Интересно узнать как обстоят у вас дела по прошествию некоторого времени? Изменились ли схемы rundeck-chef или прижилось и активно испольуется?
                      +1
                      На самом деле когда писали статью, еще не было ansible ))
                      Инструмент мощный, но мы отказались в пользу ansible.
                        0
                        Это какой-то заговор chef vs ansible) Спасибо за ответ.
                        Можно реквестировать статью на эту тему, сравнение, плюсы минусы и т.д.? Все таки шеф очень удобный инструмент, пусть и в связке с рандеком и остальными.
                          0
                          Постараемся успеть до конца месяца ))
                            0
                            Лично моя благодарность не будет знать границ:)
                          0
                          А как вы интегрировали Ansible и OS Windows? Или в статье Windows приведена для примера и вы ее не используете?
                          Аnsible у вас заменил только Chef или rundeck тоже?
                            0
                            Ansible можно запустить под Win, но это — нетривиально и пользы практически никакой.
                            rundeck работает под Win.

                            Ansible точно заменяет rundeck и с натяжкой заменяет chef. Хотя, я сейчас поменял работу, тут chef везде, становится понятно, что некоторые вещи быстро и приятно делать именно с chef и только с ним.

                            Все зависит от задач, выберите то, что вам подходит больше всего )))
                              0
                              Спасибо. Пока изучаем chef…

                      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                      Самое читаемое