Комментарии 28
отличная статья!
Спасибо
Спасибо
+1
вот за что люблю Хабр, так ето за то что нужньіе статьи появляются вовремя.
+1
А теперь давайте подробный мануал)
+1
Подробный мануал слишком большой )) Какую проблему вы не можете решить лучше напишите, можно в личку.
0
Проблем никаких нет, пока) Интересны первые шаги для новичков, базовые примеры: развертывание, настройки, примеры сценариев, подводные камни… Т.к. рано или поздно, думаю, многим это может пригодится, а наличие такого мануала поможет быстро вникнуть в суть. А пока я только присматриваюсь к инструментам)
0
НЛО прилетело и опубликовало эту надпись здесь
Несколько датацентров, порядка 60-80 виртуальных машин в бою. Нагрузка 300 рпс в среднем на каждый фронтенд, есть пиковые даты в начале месяца. За фронтендом крутятся различные штуки — php-fpm, много раздатчиков статики в количестве 15 миллионов файлов, кучка постгресов. Различные кэши, где только можно — монга, редис, мемкеш. Spinxsearch поисковым движком и различные самописные узкоспециализированные демоны для локалсерча. Все это географически распределено по стране и зарубежью. Балансировка запросов сделана с помощью lvs, geo-dns. Отказоустойчивость на всех уровнях, начиная с датацентра. Сделано дублированием сервисов. Деплой, надеюсь, скоро будет идеальным, а это значит, что будет все равно куда деплоить и что. Будет плохо — полезем в облако, например.
Все завязано на наше ядро — API, проекты-сателлиты подключаются, как модули к этому ядру. Есть тенденция перевести на такую схему вообще все наши проекты. Но это тсс почти инсайд ))
Начинали мы с csync2 и с версионирования конфигов. Потом проектов стало чуть более одного, деплоили руками. Потом пригодился chef. Сейчас как-то так.
Все завязано на наше ядро — API, проекты-сателлиты подключаются, как модули к этому ядру. Есть тенденция перевести на такую схему вообще все наши проекты. Но это тсс почти инсайд ))
Начинали мы с csync2 и с версионирования конфигов. Потом проектов стало чуть более одного, деплоили руками. Потом пригодился chef. Сейчас как-то так.
+2
Крайне интересно. Я сейчас на стадии chef, конфигурации, впрочем, пока простейшие.
А отчего взялась сложная логика в рецептах? По идее, chef же позиционируется как более, мнэ, концептуально выверенный фреймворк, чем, положим, несколько предшествующий ему исторически puppet. Может быть, рискну предположить исходя из своего опыта, вы исходно начали его «неправильно готовить» и теперь имеете легаси-лапшу к сопровождению?..
Спасибо, пишите еще :)
А отчего взялась сложная логика в рецептах? По идее, chef же позиционируется как более, мнэ, концептуально выверенный фреймворк, чем, положим, несколько предшествующий ему исторически puppet. Может быть, рискну предположить исходя из своего опыта, вы исходно начали его «неправильно готовить» и теперь имеете легаси-лапшу к сопровождению?..
Спасибо, пишите еще :)
+1
У нас большая связность компонентов. Нужна синхронность и обмен данными о состоянии нод. chef по-другому немного работает, чем бы хотелось. Когда код будет готов к signal based архитектуре и ноды будут между собой общаться сами, например не активировать некоторые интерфейсы, если еще не засинкались обновленные индексы, которых прям много. И в Москву из Новосибирска скорость заливки всего этого медленнее. Нет гарантии, что чеф в Москве, допустим, запустится вовремя и не слишком рано. Или читать из старой таблицы, если новая еще не готова.
Сейчас надо либо писать сложные рецепты с обменом информацией через ohaio, либо каким-то образом дирижировать клиентами chef, чтобы они включались когда нужно и деплоили то, что нужно ) Если учесть, что ноды еще и не типовые из-за split тестирования, то довольно сложно разобраться что и где сейчас на бою. Рецепт вроде один, но json с аттрибутами уже не один. Иногда надо быстро что-нибудь отключить или передеплоить. А чефу не прикажешь же. Он висит и ждет. Либо его пинать надо как-то.
Да, архитектура не идеальна. Это плата за очень высокую скорость разработки и нам приходится с этим пока жить )
Сейчас надо либо писать сложные рецепты с обменом информацией через ohaio, либо каким-то образом дирижировать клиентами chef, чтобы они включались когда нужно и деплоили то, что нужно ) Если учесть, что ноды еще и не типовые из-за split тестирования, то довольно сложно разобраться что и где сейчас на бою. Рецепт вроде один, но json с аттрибутами уже не один. Иногда надо быстро что-нибудь отключить или передеплоить. А чефу не прикажешь же. Он висит и ждет. Либо его пинать надо как-то.
Да, архитектура не идеальна. Это плата за очень высокую скорость разработки и нам приходится с этим пока жить )
+1
Ага, спасибо. Картинка экосистемы проясняется. А что вы использовали до чефа, из каких скриптов все это эволюционировало?
0
НЛО прилетело и опубликовало эту надпись здесь
Индексы сфинкса, например. Или еще какого движка. Версионность и совместимость можно обеспечить, но это сложно довольно. Синхронность кода, этих самых индексов и базы данных очень нужна, иначе мы покажем пользователю не то, что он запрашивал.
Rundeck это как Jenkins, но совсем для системного администратора, в таком ключе их можно сравнить. Мы все забилдили, надо выкладывать же. С десяток нод, есть среди них нетипичные и чем-то отличаются.
Рано или поздно процесс выкладки кода вообще перестает быть томным и сделать git clone (git pull) уже недостаточно, надо как-то сконфигурировать фреймоворк, подтюнить пхпшечку, подчистить кэш, но не весь. Чеф поможет.
Но чеф не умеет принимать во внимание связность компонентов. Допустим, обновить код на ноде только после того, как переиндексировался сфинкс и новые индексы уже залилились по всем нодам.
Rundeck это как Jenkins, но совсем для системного администратора, в таком ключе их можно сравнить. Мы все забилдили, надо выкладывать же. С десяток нод, есть среди них нетипичные и чем-то отличаются.
Рано или поздно процесс выкладки кода вообще перестает быть томным и сделать git clone (git pull) уже недостаточно, надо как-то сконфигурировать фреймоворк, подтюнить пхпшечку, подчистить кэш, но не весь. Чеф поможет.
Но чеф не умеет принимать во внимание связность компонентов. Допустим, обновить код на ноде только после того, как переиндексировался сфинкс и новые индексы уже залилились по всем нодам.
0
Можно на ноды со сфинксом тоже повесить чеф и обмениваться сигналами через огайо. Тут тогда проблема все это синхронизировать. Чеф если висит демоном, и раз в полчаса сервер ему выдает команды, то есть шанс прождать час другой, пока все обменяется сигналами и продолжит деплой. Если запускать вручную, то будет быстрее. Но надо руками тогда заходить и запускать. Если нод болше чем 4, тут долго тоже )))
Тут мы поставим рандек и сами нажмем кнопку, когда нам надо синхронизируем.
Тут мы поставим рандек и сами нажмем кнопку, когда нам надо синхронизируем.
0
Интересно звучит, поддерживаю реквест подробного мануала.
Можно пару вопросов?
Можно пару вопросов?
- На скриншотах видны проценты выполняемого таска, как они считаются?
- Jenkins — это прекрасно, но опять-таки медленная и прожорливая до памяти жаба. С buildbot Rundeck умеет интегрироваться?
0
Не могу понять у кого руки кривые. Пробую использовать sudo в скриптах (то есть там, где в jobs можно добавить большой текстовый скрипт), но rundeck не определяет эти команды
0
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
А как вы интегрировали Ansible и OS Windows? Или в статье Windows приведена для примера и вы ее не используете?
Аnsible у вас заменил только Chef или rundeck тоже?
Аnsible у вас заменил только Chef или rundeck тоже?
0
Ansible можно запустить под Win, но это — нетривиально и пользы практически никакой.
rundeck работает под Win.
Ansible точно заменяет rundeck и с натяжкой заменяет chef. Хотя, я сейчас поменял работу, тут chef везде, становится понятно, что некоторые вещи быстро и приятно делать именно с chef и только с ним.
Все зависит от задач, выберите то, что вам подходит больше всего )))
rundeck работает под Win.
Ansible точно заменяет rundeck и с натяжкой заменяет chef. Хотя, я сейчас поменял работу, тут chef везде, становится понятно, что некоторые вещи быстро и приятно делать именно с chef и только с ним.
Все зависит от задач, выберите то, что вам подходит больше всего )))
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Ключ от всех дверей в непрерывной интеграции — rundeck