Comments 34
без проблем обслуживать 500 клиентов
С активным агентом?
Да. Агенты обращаются к puppet серверу по умолчанию раз в пол часа. В результате мы имеем примерно 16 обращений в минуту.
Тогда понятно. У нас агенты с 5 минутным интервалом вешали такую же связку, на похожей конфигурации напрочь когда их становилось чуть больше 200.
Раз в полчаса — они размазаны по времени или все в одно и то же время?
Вот в этом, на мой взгляд, одна из главных опасных особенностей использования систем с самостоятельным агентом.
Например, мы имеем базу и несколько веб-серверов. Самый простой вариант…
База обновляется миграциями, все по-уму. Пусть даже руками, хотя это тоже хочется автоматически.
Но вот база обновилась, но код на веб серверах обновится хз в какой момент, но в течение получаса.
То есть все эти 30 минут мы не будем точно знать насколько консистентна система? А пользователи идут и получают ошибки либо в базу пишется что-то не то.
Это еще самый простой вариант, когда у вас нет сложной связки сервисов, которые нужно обновлять один-за-другим строго по очереди или обновлять кластер.
Прошу прощения, но у меня зуб на Puppet и Chef — я могу много недостатков перечислить :)
Вот в этом, на мой взгляд, одна из главных опасных особенностей использования систем с самостоятельным агентом.
Например, мы имеем базу и несколько веб-серверов. Самый простой вариант…
База обновляется миграциями, все по-уму. Пусть даже руками, хотя это тоже хочется автоматически.
Но вот база обновилась, но код на веб серверах обновится хз в какой момент, но в течение получаса.
То есть все эти 30 минут мы не будем точно знать насколько консистентна система? А пользователи идут и получают ошибки либо в базу пишется что-то не то.
Это еще самый простой вариант, когда у вас нет сложной связки сервисов, которые нужно обновлять один-за-другим строго по очереди или обновлять кластер.
Прошу прощения, но у меня зуб на Puppet и Chef — я могу много недостатков перечислить :)
У меня через Puppet управляются обычные Ubuntu 14.04 Desktop и нет необходимости в том чтобы запускать чаще agent или же как-то синхронизировать обновления между машинами.
Агенты на них запускаются в разное время(так как все ПК в один момент не включаются, а включаются рандомно).
Интервал в 30 минут меня в данном случае устраивает, так как через Puppet у меня в основном производится установка обновлений ОС, установка софта, проверка работы сервисов, настройки прокси, установка сертификатов и т.д.(ничего такого что не может подождать 30 минут).
Если делаются изменения на серверах, то у меня тоже пока что нет таких сервисов(управляемых через Puppet) которые б зависели один от другого.
Когда появятся, думаю к тому времени я найду решение.
Агенты на них запускаются в разное время(так как все ПК в один момент не включаются, а включаются рандомно).
Интервал в 30 минут меня в данном случае устраивает, так как через Puppet у меня в основном производится установка обновлений ОС, установка софта, проверка работы сервисов, настройки прокси, установка сертификатов и т.д.(ничего такого что не может подождать 30 минут).
Если делаются изменения на серверах, то у меня тоже пока что нет таких сервисов(управляемых через Puppet) которые б зависели один от другого.
Когда появятся, думаю к тому времени я найду решение.
Вот в этом, на мой взгляд, одна из главных опасных особенностей использования систем с самостоятельным агентом.
А можно узнать какое у Вас решение для этой проблемы?
Я предпочитаю использовать push-схему, когда есть центральный сервер, который обладает знаниями о всей топологии и может принимать решения о порядке запуска обновлений на серверах.
Первоначальное решение «в лоб» мы делали следующим образом — центральный сервер выбирает группу серверов для обновления, пишет в chef-сервер необходимые параметры (роли), затем удаленно коннектится к каждой ноде (параллельно, распределенно) и насильно запускает на них chef-агент с заданным именем chef-сервера. Остальное — стандартно. После завершения работ ноды рапортуют на главный сервер и он выбирает следующую группу.
Позже мы ушли от Chef совсем, написав своего агента и немного упростив-улучшив схему.
Первоначальное решение «в лоб» мы делали следующим образом — центральный сервер выбирает группу серверов для обновления, пишет в chef-сервер необходимые параметры (роли), затем удаленно коннектится к каждой ноде (параллельно, распределенно) и насильно запускает на них chef-агент с заданным именем chef-сервера. Остальное — стандартно. После завершения работ ноды рапортуют на главный сервер и он выбирает следующую группу.
Позже мы ушли от Chef совсем, написав своего агента и немного упростив-улучшив схему.
Мне кажется, что паппет не совсем для описанных вами целей разрабатывался. Это больше выглядит как деплой. А паппетно-шефные системы больше подходят для задач вроде сконфигурировать сервер (пул серверов) с нуля (кстати фореман можно настроить на полный провижн, с PXE, dhcp и пр.) и держать конфигурацию консистентной, переписывая ручные измения.
Соглашусь, но даже для этих целей меня, как администратора, напрягали бы следующие моменты:
* В нагруженной сети из 1000 (или больше машин) время от времени (в случайные моменты времени) сервера тратят время/трафик на бесполезные обращения к мастер-серверу. Два раза в месяц они находят обновления, но в остальное время они работают вхолостую.
* Из этих 1000 серверов внезапно на три не дошли обновления. Неизвестно почему. Агент не запросил. В Foreman мы увидим, конечно, что какие-то агенты долго не отвечали, но, поверьте, в большой сети у вас там скопится достаточное количество старых записей и вы не сразу отловите эти необновленные конфигурации.
* внезапно количество серверов резко возрастает и приходится придумывать схемы с балансированием нагрузки, поскольку сервер начинает трещать даже если не делает ничего.
* обновления накатываются фактически бесконтрольно. Когда-то в течение этих N минут что-то накатится. Если нода была выключена месяц, а потом включилась — она будет тянуть все эти манифесты и применять, даже если сейчас не время…
* адрес мастер-сервера может смениться. Вот полетел raid в ESXi-кластере, мастер паппета недоступен, бэкап есть, но с тем же именем в сети его поднять не получается по каким-то причинам.
В серьезных сетях я предпочел бы контролировать такие вещи более строго.
* В нагруженной сети из 1000 (или больше машин) время от времени (в случайные моменты времени) сервера тратят время/трафик на бесполезные обращения к мастер-серверу. Два раза в месяц они находят обновления, но в остальное время они работают вхолостую.
* Из этих 1000 серверов внезапно на три не дошли обновления. Неизвестно почему. Агент не запросил. В Foreman мы увидим, конечно, что какие-то агенты долго не отвечали, но, поверьте, в большой сети у вас там скопится достаточное количество старых записей и вы не сразу отловите эти необновленные конфигурации.
* внезапно количество серверов резко возрастает и приходится придумывать схемы с балансированием нагрузки, поскольку сервер начинает трещать даже если не делает ничего.
* обновления накатываются фактически бесконтрольно. Когда-то в течение этих N минут что-то накатится. Если нода была выключена месяц, а потом включилась — она будет тянуть все эти манифесты и применять, даже если сейчас не время…
* адрес мастер-сервера может смениться. Вот полетел raid в ESXi-кластере, мастер паппета недоступен, бэкап есть, но с тем же именем в сети его поднять не получается по каким-то причинам.
В серьезных сетях я предпочел бы контролировать такие вещи более строго.
1. Они делают изменения не 2 раза в месяц(обновления 2 раза в месяц), но есть еще и другие процедуры которые проделываются чаще. Но да, больше половины запросов проходят впустую.
2. Работу агентов контролируют локальные системные администраторы, если определенные клиенты почему-то не получили обновления, это сразу проверяется(также каждые сутки приходят отчеты в почту).
3. Пока есть запас по увеличению мощности виртуального сервера, когда не будет хватать мощности, буду думать как сделать балансировку.
4. Обновления накатываются не бесконтрольно, вначале обновления тестируются на тестовой группе, потом накатываются по всем остальным ПК.
5. В EXSi настроена отказоустойчивость и живая миграция(отдельный сторедж для виртуалок), есть суточные бэкапы мастер-сервера. Я не вижу причин почему нельзя поднять бэкап с тем же именем.
2. Работу агентов контролируют локальные системные администраторы, если определенные клиенты почему-то не получили обновления, это сразу проверяется(также каждые сутки приходят отчеты в почту).
3. Пока есть запас по увеличению мощности виртуального сервера, когда не будет хватать мощности, буду думать как сделать балансировку.
4. Обновления накатываются не бесконтрольно, вначале обновления тестируются на тестовой группе, потом накатываются по всем остальным ПК.
5. В EXSi настроена отказоустойчивость и живая миграция(отдельный сторедж для виртуалок), есть суточные бэкапы мастер-сервера. Я не вижу причин почему нельзя поднять бэкап с тем же именем.
Ну, опять же, у вас просто еще не те масштабы. И не задача полноценного деплоя.
Что касается «с тем же именем» — не совсем в тему, но вспомнил несколько случаев когда доблестные сетевые инженеры случайно косячили и в сети появлялось устройство с не совсем уникальным IP-адресом. Поскольку использовать DHCP считалось не совсем безопасным, а так же часто требовались статические адреса — все адреса в сети выдавались руками. И коллизии случались.
Иногда проще и быстрее переименовать свой сервер, чем писать заявку на смену IP-адреса у свича, которая будет запланирована через неделю.
Еще вполне может отвалиться вся подсеть, в которой стоит ваш мастер-сервер.
Случиться может что угодно, а статически зашитый адрес мастера на нескольких тысячах устройств, на мой взгляд, не гибко.
Что касается «с тем же именем» — не совсем в тему, но вспомнил несколько случаев когда доблестные сетевые инженеры случайно косячили и в сети появлялось устройство с не совсем уникальным IP-адресом. Поскольку использовать DHCP считалось не совсем безопасным, а так же часто требовались статические адреса — все адреса в сети выдавались руками. И коллизии случались.
Иногда проще и быстрее переименовать свой сервер, чем писать заявку на смену IP-адреса у свича, которая будет запланирована через неделю.
Еще вполне может отвалиться вся подсеть, в которой стоит ваш мастер-сервер.
Случиться может что угодно, а статически зашитый адрес мастера на нескольких тысячах устройств, на мой взгляд, не гибко.
Где Вы увидели статически зашитый IP адрес? Во всех клиентах прописано DNS имя(в данном примере srv.co.com) для Puppet Master.
В случае проблем — поднимаем виртуалку(хоть на VmWare Player) в любой видимой для клиентов сети, нужно только изменить DNS запись.
sed -i '/\/var\/log\/puppet/a \server=srv.co.com' /etc/puppet/puppet.conf
В случае проблем — поднимаем виртуалку(
Puppet — у меня не в качестве деплоя, он именно для держания конфигурации консистентной. Для деплоя я использую iPXE с набором seed файлов. Puppet же не позволяет пользователям изменять определенные конфиги(точнее позволяет, но потом назад возвращает все), с помощью puppet я могу централизовано внести любые изменения в уже установленную систему.
Foreman был избран мной потому что он бесплатный и имеет лучший функционал чем другие альтернативы.
Также не последним была возможность развертывания ОС по РХЕ и прочее. В будущем я опишу детальнее функционал Foreman в особенности его работу с гипервизорами.
Foreman был избран мной потому что он бесплатный и имеет лучший функционал чем другие альтернативы.
Также не последним была возможность развертывания ОС по РХЕ и прочее. В будущем я опишу детальнее функционал Foreman в особенности его работу с гипервизорами.
Да-да, мы в курсе о вашем зубе и даже помним что вы обещали продолжение вашей статьи. Неплохо бы выполнить обещание. Без этого… Скажем так, приведенный вами пример я разрулю. При том что опыта работы с паппетом у меня, скажем так, ровно столько, сколько можно научиться самому управляя несколькими десятками не особо сложных серверов.
Виноват, со статьей все-таки соберусь. Этот топик лишний раз будет стимулом.
А как бы вы разрулили мой пример (плюс остальные, если есть мысли)? Чисто для статистики — хочется знать мнения коллег.
А как бы вы разрулили мой пример (плюс остальные, если есть мысли)? Чисто для статистики — хочется знать мнения коллег.
Ну, боюсь, что я вашу статистику не сильно улучшу и ничего нового не расскажу. Во-первых, chef/puppet действительно не умеют оркестрацию, насколько мне известно — они просто не для того создавались. Из этого следует, что ни кластер ни просто несколько взаимосвязанных серверов они обновить не смогут. Во-вторых, puppet — не предназначен для деплоя приложений. Да, из-за того что он может управлять конфигурацией пакетного менеджера (и по ряду других причин) с его помощью очень удобно установить или обновить много-много пакетов, в том числе в определенном порядке. Но — это все будет делать не шеф/паппет, а пакетный менеджер.
Вы все это, конечно, и без меня знаете; я просто не хочу потерять контекст беседы.
Так вот. При всем при этом чтобы обновить в определенном порядке взаимосвязанные сервисы на разных нодах, надо все равно изобретать велосипед. Либо как вы описали выше — отдельным процессом менять конфигурацию SCM и потом принудительно дергать агента. Мы склонились к идее пакетировать (deb/msi) разрабатываемый софт и писать его (софт) с учетом возможных неконсистентных состояний. При том новые пакеты викладываются либо во время технологичных окон, либо в периоды минимальной нагрузки на систему.
P.S. Беглый гуглеж говорит, что puppet enterprise умеет какой-то orchestration. В жизни не видел РЕ, так что ничего по этому поводу сказать не могу.
Вы все это, конечно, и без меня знаете; я просто не хочу потерять контекст беседы.
Так вот. При всем при этом чтобы обновить в определенном порядке взаимосвязанные сервисы на разных нодах, надо все равно изобретать велосипед. Либо как вы описали выше — отдельным процессом менять конфигурацию SCM и потом принудительно дергать агента. Мы склонились к идее пакетировать (deb/msi) разрабатываемый софт и писать его (софт) с учетом возможных неконсистентных состояний. При том новые пакеты викладываются либо во время технологичных окон, либо в периоды минимальной нагрузки на систему.
P.S. Беглый гуглеж говорит, что puppet enterprise умеет какой-то orchestration. В жизни не видел РЕ, так что ничего по этому поводу сказать не могу.
Большой плюс вам за пакеты — не все так делают, а если не делают, то при деплое очень много веселого геморроя с удалением.
PE я тоже не трогал руками, но, судя по документации, не так уж много он умеет — просто может объединять задачи в несколько этапов (например, процент одновременно обновляемых серверов). Тем более в командной строке — половина работы руками.
Меня тут все правильно поправляют что puppet/chef — не для полноценного деплоя. Хорошо когда это понимают, потому что он позиционируется именно как инструмент для руления всей инфраструктурой.
PE я тоже не трогал руками, но, судя по документации, не так уж много он умеет — просто может объединять задачи в несколько этапов (например, процент одновременно обновляемых серверов). Тем более в командной строке — половина работы руками.
Меня тут все правильно поправляют что puppet/chef — не для полноценного деплоя. Хорошо когда это понимают, потому что он позиционируется именно как инструмент для руления всей инфраструктурой.
Сейчас в puppet есть MCollective
puppetlabs.com/mcollective
Кроме всего прочего, он умеет делать «push» сразу на все сервера.
puppetlabs.com/mcollective
Кроме всего прочего, он умеет делать «push» сразу на все сервера.
А, вот, кстати, спасибо. Это что-то новое, я еще не видел этой фичи.
Похоже что оно использует промежуточные сервера, связанные через ActiveMQ для одновременной посылки broadcast-сообщений на сервера.
Однако вот это примечание сразу настраивает меня против:
Когда я все-таки допишу статью, я объясню что я еще и против принятия решений нодами. :)
Похоже что оно использует промежуточные сервера, связанные через ActiveMQ для одновременной посылки broadcast-сообщений на сервера.
Однако вот это примечание сразу настраивает меня против:
The middleware network broadcasts the message to all nodes.
Every node gets the message and validates the filter
Когда я все-таки допишу статью, я объясню что я еще и против принятия решений нодами. :)
В скрипте установки вместо строчки
лучше написать
Тогда во-первых не надо будет менять скрипт после перехода на другую версию ОС, а во-вторых скрипт будет работать и на классическом debian.
wget apt.puppetlabs.com/puppetlabs-release-trusty.debлучше написать
wget apt.puppetlabs.com/puppetlabs-release-`lsb_release -cs`.debТогда во-первых не надо будет менять скрипт после перехода на другую версию ОС, а во-вторых скрипт будет работать и на классическом debian.
Да, за туториал спасибо. Вещь полезная, связка рабочая. Думаю для многих снизит порог входа.
Поговаривают, что fqdn нельзя указывать в /etc/hostname. Там живет только короткое имя.
Sign up to leave a comment.
Централизованное управление конфигурациями: Puppet + Foreman. Часть І