Плюсы и минусы децентрализованной кукольной архитектуры

14

У нас есть около 300 серверов RHEL, которые в настоящее время подключаются к серверу Puppetmaster. Однако мы заметили некоторые узкие места в производительности, и это является точкой сбоя в нашей системе. Я довольно новичок в Puppet в целом, и я рассматриваю возможность создания децентрализованной архитектуры Puppet вместо подключения клиентов Puppet к серверу Puppetmaster. Помимо того, что я подозреваю, например, увеличения производительности и отсутствия подписи и обмена сертификатами SSL для новых машин, каковы другие плюсы и минусы в настройке децентрализованной архитектуры?

redhat puppet puppetmaster JMeterX
источник
3
Есть ли причина, почему это должно быть так или иначе? Рассматривали ли вы варианты где-то посередине? С таким количеством серверов и заботой об одной точке отказа, почему бы вам не установить дополнительные мастера? Настройка марионеточных серверов с несколькими нагрузками описана в книге «Pro Puppet». Существует большая гибкость, даже если это будет иметь смысл, можно настроить иерархию марионеточных серверов.
Зоредаче
@Zoredache На самом деле нет причин, по которым это должно быть так или иначе, я искал дополнительную информацию о децентрализованной архитектуре в целом, чтобы облегчить принятие решения. Я рассмотрел дополнительные варианты, но суть идеи, которую я извиняюсь за то, что не упомянул, состоит в том, чтобы уменьшить количество серверов, поскольку это напрямую влияет на наш бюджет. Я согласен, балансировка нагрузки марионеточных серверов имеет смысл, но если я смогу избавиться от сервера вместе, это было бы лучшим решением.
JMeterX

Ответы:

7

Иди децентрализовано.

Вместо подписи сертификатов создайте ключи ssh. Не давайте ключи не администраторам

Вы можете использовать Git в качестве своего транспорта вместо subversion, а затем вы можете переходить на разные машины / роли, а затем вносить изменения в свои версии, а также учитывать ... но вы должны знать уровень DVCS на этом этапе.

Это быстрее и менее требовательно к настройке. Добавьте некоторые фиксаторы фиксации для проверки работоспособности.

Теперь, на этом этапе, вы заменили puppetmaster с его моделью клиент-сервер на ssh и git, оба из которых масштабируются лучше, чем puppetmaster.

Теперь в вашей организации может возникнуть потребность в иерархии. Нет проблем, просто храните репозиторий git, содержащий определенную ветку, в безопасном месте.

Бонус:

git blame

позволит вам увидеть, кто внес изменения.

http://bitfieldconsulting.com/scaling-puppet-with-distributed-version-control

https://www.braintreepayments.com/braintrust/decentralize-your-devops-with-masterless-puppet-and-supply-drop ?

chiggsy
источник
3

Вы управляете марионеткой в ​​пассажирском? сохраненные конфиги? У вас действительно не должно быть проблем с масштабируемостью с 300 узлами, если вы решаете основные проблемы с настройкой.

czervik
источник
1
Мы используем конфигурацию Apache + Passenger. Мы также используем subversion для передачи изменений в Puppetmaster
JMeterX
1

Децентрализованный - это лучший способ, потому что каждый клиент компилирует свой собственный манифест из локальной копии источника манифеста. Это обновляется каждый раз, когда вы отправляете обновления с сервера скажем git. Гораздо более эффективное использование пропускной способности, так как клиенты не должны связываться с puppetmaster при каждом запуске. Также устраняет отдельные точки отказа, поскольку клиенты могут быть обновлены из любого места.

What'sTheStoryWishBone
источник