Comments 48
А что такое конфигурации и зачем ими управлять?
Спасибо за статью — как раз хотелось послушать этот доклад на конференции, но по времени не срослось.
А чем обусловлен выбор ActiveMQ, как промежуточного звена между puppet-ом и базой? В смысле, что рассматривались какие-то другие варианты очередей?
А чем обусловлен выбор ActiveMQ, как промежуточного звена между puppet-ом и базой? В смысле, что рассматривались какие-то другие варианты очередей?
RabbitMQ был «как вариант», но как показывает практика — выбор ActiveMQ был правильнее по 2м причинам:
1. MCollective использует его же
2. puppet >=3.0.0 предлагает использовать PuppetDB, т.е. puppet queue они как deprecated объявили. Ну и как «на закуску» в PuppetDB они используют activemq.jar
, тоесть наш изначальный выбор был корректным.
1. MCollective использует его же
2. puppet >=3.0.0 предлагает использовать PuppetDB, т.е. puppet queue они как deprecated объявили. Ну и как «на закуску» в PuppetDB они используют activemq.jar
, тоесть наш изначальный выбор был корректным.
Честно я не пойму одного.
>Почему именно Unicorn?
>Вот, на наш взгляд, его плюсы:
>балансировка на уровне ядра Linux;
и тут же БАЦ!
>значит, нам ничто не мешает настроить простую http-балансировку, прибегнув к помощи nginx.
или тут о разных балансировках речь?
>Почему именно Unicorn?
>Вот, на наш взгляд, его плюсы:
>балансировка на уровне ядра Linux;
и тут же БАЦ!
>значит, нам ничто не мешает настроить простую http-балансировку, прибегнув к помощи nginx.
или тут о разных балансировках речь?
о разных, а именно:
unicorn — несколько процессов puppetmasterd (оперируя терминами ветки puppet 2.6.*)
nginx — балансировка от клиента до сервера, на котором уже в качестве puppetmasterd выступает unicorn, за которым скрывается не 1 процесс, а столько, сколько скажем поднять unicorn'у.
так несколько яснее? =)
unicorn — несколько процессов puppetmasterd (оперируя терминами ветки puppet 2.6.*)
nginx — балансировка от клиента до сервера, на котором уже в качестве puppetmasterd выступает unicorn, за которым скрывается не 1 процесс, а столько, сколько скажем поднять unicorn'у.
так несколько яснее? =)
puppet 3.0.1 (на этой неделе перешли)
nginx+passenger
250 хостов за 3 минуты на одного мастера
>100 модулей, включая тяжелые, по распространению контента.
и зачем столько громких слов, что хостов больше 200 за 3 минуты? :)
btw, load average: 0.95, 0.88, 0.85
nginx+passenger
250 хостов за 3 минуты на одного мастера
>100 модулей, включая тяжелые, по распространению контента.
и зачем столько громких слов, что хостов больше 200 за 3 минуты? :)
btw, load average: 0.95, 0.88, 0.85
кстати, а у вас проблем с отображением events в foreman'е не было?
а то при переходе с 2.6.x на 3.0.1 столкнулся с этим… последний foreman ни в какую не хочет их показывать :\
а предыдущий показывает все отлично
а то при переходе с 2.6.x на 3.0.1 столкнулся с этим… последний foreman ни в какую не хочет их показывать :\
а предыдущий показывает все отлично
Всего у вас сколько хостов? Какой опционал из перечисленного мной вы используете у себя? Какое время обработки каталога на конечной машине(хотя это настолько относительно, насколько вы говорите о 100 модулях)
Также в статье есть сообщение о том, что «ваш вариант» тоже был опробован — не устроил.
Чуть выше в комментариях я написал о том, что сделали в puppetdb, что еще раз подтверждает правильность решения для asynchronous storeconfigs.
Также в статье есть сообщение о том, что «ваш вариант» тоже был опробован — не устроил.
Чуть выше в комментариях я написал о том, что сделали в puppetdb, что еще раз подтверждает правильность решения для asynchronous storeconfigs.
про опционал слегка не понял.
время обработки каталога в среднем 10с, если ничего не нужно делать.
деплой какого-нибудь сервиса с нуля(установлен только паппет) занимает ~300-400сс на ноду.
я просто не понимаю зачем столь усложнять систему, если она и так работает нормально.
nginx+passenger для puppetmaster
nginx+passenger для foreman
mysql кластер на перконах(но он не столь для паппета, сколько для всех служб)
btw, деплоить паппетмастер можно самим паппетом ;)
время обработки каталога в среднем 10с, если ничего не нужно делать.
деплой какого-нибудь сервиса с нуля(установлен только паппет) занимает ~300-400сс на ноду.
я просто не понимаю зачем столь усложнять систему, если она и так работает нормально.
nginx+passenger для puppetmaster
nginx+passenger для foreman
mysql кластер на перконах(но он не столь для паппета, сколько для всех служб)
btw, деплоить паппетмастер можно самим паппетом ;)
Storeconfig сам по себе и завязки на него в манифестах используете?
Кинуть сообщение в queue также быстрее, чем сразу в бд, если речь идет об удаленном географически дц(трансатлантика)
«в среднем 10, если ничего не нужно делать» — если ничего не нужно, то и паппет не нужен ;)
Если в вашем случае такое использование устраивает — оно ж прекрасно. Мы попробовали — не устроило — пошли дальше.
Кинуть сообщение в queue также быстрее, чем сразу в бд, если речь идет об удаленном географически дц(трансатлантика)
«в среднем 10, если ничего не нужно делать» — если ничего не нужно, то и паппет не нужен ;)
Если в вашем случае такое использование устраивает — оно ж прекрасно. Мы попробовали — не устроило — пошли дальше.
Против amqp я ничего не имею. Никто и не спорит.
storeconfig не использую.
обычных репортов в связке с foreman'ом хватает.
честно говоря пока не понимаю что такое storeconfig.
можно про него поподробнее? в чем отличие от обычных репортов?
storeconfig не использую.
обычных репортов в связке с foreman'ом хватает.
честно говоря пока не понимаю что такое storeconfig.
можно про него поподробнее? в чем отличие от обычных репортов?
можно я не стану заниматься переводом, потому как более внятно не смогу объяснить. Вот смотрите:
What’s storeconfigs
Storeconfigs is a puppetmasterd option that stores the nodes actual configuration to a database. It does this by comparing the result of the last compilation against what is actually in the database, resource per resource, then parameter per parameter, and so on.
The actual implementation is based on Rails’ Active Record, which is a great way to abstract the gory details of the database, and prototype code easily and quickly (but has a few shortcomings).
Storeconfigs uses
The immediate use of storeconfigs is exported resources. Exported resources are resources which are prefixed by @@. Those resources are marked specially so that they can be collected on several other nodes.
в отличии от обычных репортов — это вовсе не репорт )
What’s storeconfigs
Storeconfigs is a puppetmasterd option that stores the nodes actual configuration to a database. It does this by comparing the result of the last compilation against what is actually in the database, resource per resource, then parameter per parameter, and so on.
The actual implementation is based on Rails’ Active Record, which is a great way to abstract the gory details of the database, and prototype code easily and quickly (but has a few shortcomings).
Storeconfigs uses
The immediate use of storeconfigs is exported resources. Exported resources are resources which are prefixed by @@. Those resources are marked specially so that they can be collected on several other nodes.
в отличии от обычных репортов — это вовсе не репорт )
Последнее время считается, что nginx + unicorn — более православно для Ruby-приложений.
И это также и мое мнение. Chef разворачиваю именно в такой конфигурации :)
И это также и мое мнение. Chef разворачиваю именно в такой конфигурации :)
имхо в случае, если nginx все же балансирует между несколькими бекендами.
добавление любого доп.кода в nginx уменьшает его надежность/стабильность.
Мы используем много чего из сборки openresty.
Вот не сказал бы, что уменьшилась стабильность или надежность. Скорость повысилась, да.
Операции с кэшем, базами данных, асинхронные и нонблокинг корутины lua, сабреквесты, работа напрямую с сокетами, embedded perl. Некоторые проекты жмут до 10 тысяч рпс на этом комбайне. Проблем нет.
Вот не сказал бы, что уменьшилась стабильность или надежность. Скорость повысилась, да.
Операции с кэшем, базами данных, асинхронные и нонблокинг корутины lua, сабреквесты, работа напрямую с сокетами, embedded perl. Некоторые проекты жмут до 10 тысяч рпс на этом комбайне. Проблем нет.
Кстати, а нет ничего рабочего типа uwsgi для python и ruby одновременно?
FastCGI?)
В смысле, одновременно? uwsgi умеет запускать и ruby и python.
Вот у меня есть uwsgi, который одновременно крутит и redmine и rhodecode. Немного непонятно, что Вы имеете в виду?
Вот у меня есть uwsgi, который одновременно крутит и redmine и rhodecode. Немного непонятно, что Вы имеете в виду?
Я так понял вы используете mcollective. Распишите пожалуйста под какие задачи. И как боретесь с таймаутами. Спаисбо.
Клиент в качестве демона? Нет ли проблем с использованием памятью клиентами?
Клиент по крону. Было неоправданное потребление на ветке 2.*.
Теперь вроде бы исправили, но оно нам уже не нужно.
Теперь вроде бы исправили, но оно нам уже не нужно.
Мммм… Пробывали запускать по крону, откатились назад, так как гибкость меньше. Вам не приходится при мейнтенсах отключать puppet? Было бы интересно как вы в таком случае поступаете?
я не нашел ни одного против, в тот момент, когда принимали решение перевода на «запуск по крону». Расскажите где именно потеря гибкости? (отсутствие puppetrun? — так есть же mcollective; или все же что-то еще?)
Мейнтенансы где именно? на том оборудовании, что выступает в качестве мастера?
Мейнтенансы где именно? на том оборудовании, что выступает в качестве мастера?
по поводу мейнтенса
а что мешает вместо гашения демона с паппетом, гасить демона с кроном? :)
гибкость меньше — кроном же тоже управляет паппет, так что время обращения к мастеру с клиента тоже можно менять динамически.
других приемуществ демона перед кроном не вижу…
тем не менее, правда, все равно используем демона :)
а что мешает вместо гашения демона с паппетом, гасить демона с кроном? :)
гибкость меньше — кроном же тоже управляет паппет, так что время обращения к мастеру с клиента тоже можно менять динамически.
других приемуществ демона перед кроном не вижу…
тем не менее, правда, все равно используем демона :)
Антон, а можете привести конкретный use case, когда puppet оказался именно тем самым волшебством?
Когда, к примеру, надо было на многих нодах что-то поменять. Зрелищ в студию пожалуста!
ps: В связи с NDA персонажи могут быть переименованы :)
Когда, к примеру, надо было на многих нодах что-то поменять. Зрелищ в студию пожалуста!
ps: В связи с NDA персонажи могут быть переименованы :)
Первое:
благодаря связке puppet+mcollective в свое время очень быстро решили проблему с leap second (несколько минут заняло, насколько я помню)
Второе:
вышел критикал фикс firmware от HP, например, которые просят срочно обновиться. Список проблем который можно получить обычно они тоже уточняют :)
В случае наличия puppet'a мы легко пишем правило, с привязкой к конкретной платформе сервера и выполняем обновление.
Третье:
Писать документацию часто бывает лень, а написать класс(-ы)/модуль в puppet приходится. В нашем случае получается большой плюс в том, что данную инсталляцию можно размножить. Т.е. если была сделана тестовая инсталляция на 10 машин — развернуть на 50/100 проблем не возникает.
Четвертое:
Мы уже писали о том, как «раскладываем и отзываем доступы» для пользователей, прибегая к помощи puppet — это довольно большой use case.
Система управления пользователями уже сильно обросла доп. функционалом, о котором не сказано в той нашей статье, но суть не поменялась.
Если примеров не достаточно — вы можете сформулировать задачу конкретнее — я попробую ответить.
благодаря связке puppet+mcollective в свое время очень быстро решили проблему с leap second (несколько минут заняло, насколько я помню)
Второе:
вышел критикал фикс firmware от HP, например, которые просят срочно обновиться. Список проблем который можно получить обычно они тоже уточняют :)
В случае наличия puppet'a мы легко пишем правило, с привязкой к конкретной платформе сервера и выполняем обновление.
Третье:
Писать документацию часто бывает лень, а написать класс(-ы)/модуль в puppet приходится. В нашем случае получается большой плюс в том, что данную инсталляцию можно размножить. Т.е. если была сделана тестовая инсталляция на 10 машин — развернуть на 50/100 проблем не возникает.
Четвертое:
Мы уже писали о том, как «раскладываем и отзываем доступы» для пользователей, прибегая к помощи puppet — это довольно большой use case.
Система управления пользователями уже сильно обросла доп. функционалом, о котором не сказано в той нашей статье, но суть не поменялась.
Если примеров не достаточно — вы можете сформулировать задачу конкретнее — я попробую ответить.
Например:
* нас досят
* в течении суток нам надо разные переменные в конфигах выставлять, в зависимости от нагрузки
* смасштабировать некий сервис с к примеру одной машинки на некий мегакластер
Вот что-нить такого хотелось бы. Что-то, что ручками вааще нереально сделать. М.б. это вообще лучше отдельной статьёй запостить.
ps: Даешь папеты/шефы в массы!
* нас досят
* в течении суток нам надо разные переменные в конфигах выставлять, в зависимости от нагрузки
* смасштабировать некий сервис с к примеру одной машинки на некий мегакластер
Вот что-нить такого хотелось бы. Что-то, что ручками вааще нереально сделать. М.б. это вообще лучше отдельной статьёй запостить.
ps: Даешь папеты/шефы в массы!
у нас есть что-то подобное вот этому «в течении суток нам надо разные переменные в конфигах выставлять, в зависимости от нагрузки», только не из-за "* нас досят". В том числе есть и те вещи, которые руками не то, чтобы не реально, а скорее лень и/или долго.
Вся эта информация больше касается непосредственно эксплуатации самого продукта, а не его первоначальной настройки/оптимизации.
Я думаю, что раз это вызывает некоторый интерес, то придется в обозримом будущем выделить в отдельную статью puppet+mcollective, а также информацию про те моменты, о которых вы спрашиваете.
p.s.: «мегакластер» — «мега» становится относительной приставкой, в зависимости от восприятия. Для вас это сколько в единицах? =)
Дело в том, что я не вижу разницы в обслуживании 10 или 100 машин, если на них нужно что-то выкатить.
Вся эта информация больше касается непосредственно эксплуатации самого продукта, а не его первоначальной настройки/оптимизации.
Я думаю, что раз это вызывает некоторый интерес, то придется в обозримом будущем выделить в отдельную статью puppet+mcollective, а также информацию про те моменты, о которых вы спрашиваете.
p.s.: «мегакластер» — «мега» становится относительной приставкой, в зависимости от восприятия. Для вас это сколько в единицах? =)
Дело в том, что я не вижу разницы в обслуживании 10 или 100 машин, если на них нужно что-то выкатить.
Попробовал puppet, это нормально запрос каталога агентом длится секунд 5-7, при это он хорошо кушает cpu?
banuchka Добрый день, Антон!
Скажите пожалуйста, по прошествии стольких лет, в Badoo так же используется Puppet?
Если так, то можете ли написать какие произошли изменения (понятно что скорее всего в Badoo используется более новая версия Puppet)? Архитектурные, какие используете программы вместе с Puppet?
Скажите пожалуйста, по прошествии стольких лет, в Badoo так же используется Puppet?
Если так, то можете ли написать какие произошли изменения (понятно что скорее всего в Badoo используется более новая версия Puppet)? Архитектурные, какие используете программы вместе с Puppet?
Добрый день,
только что заметил сообщение. Да используем по сей день. Изменения произошли хотябы потому, что перешли на использование puppetserver, который на Java, в отличии от Rails.
Если кратко, то:
— добавился PuppetDB
— репорты и profiler уехали в Elasticsearch
— остался LB в виде nginx
Т.е. как мне кажется, если смотреть на схему в общем виде, то она стала проще с точки зрения эксплуатации.
только что заметил сообщение. Да используем по сей день. Изменения произошли хотябы потому, что перешли на использование puppetserver, который на Java, в отличии от Rails.
Если кратко, то:
— добавился PuppetDB
— репорты и profiler уехали в Elasticsearch
— остался LB в виде nginx
Т.е. как мне кажется, если смотреть на схему в общем виде, то она стала проще с точки зрения эксплуатации.
Sign up to leave a comment.
Puppet под нагрузкой