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


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


14
2017-07-16 19:04


Источник


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


Ответы:


Пойдите децентрализованным.

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

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

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

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

Теперь в вашей организации может потребоваться иерархия. Нет проблем, просто сохраните 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?


7
2017-07-18 16:35





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


3
2017-07-17 04:59



Мы используем конфигурацию Apache + Passenger. Мы также используем подрывную деятельность, чтобы подтолкнуть изменения к Кукловодству - JMeterX


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


1
2017-08-15 15:54