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

14

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

redhat puppet puppetmaster

— JMeterX
джерело

3

Чи є причина, чому це має бути так чи інакше? Ви розглядали варіанти десь посередині? Якщо у вас багато серверів і стурбованість єдиною точкою відмови, то чому б ви не встановили додаткових майстрів? Налаштування декількох лялькових серверів, збалансованих завантаженням, висвітлено в книзі "Pro Puppet". Існує велика гнучкість, навіть має бути можливість встановити ієрархію лялькових серверів, якщо це мало б сенс.

— Zoredache

@Zoredache Дійсно не є причиною того, що це має бути так чи інакше, я шукав додаткову інформацію про децентралізовану архітектуру взагалі, щоб полегшити рішення. Я розглядав додаткових майстрів, але суть ідеї, яку я вибачаюсь за те, що не згадую, полягає у зменшенні кількості серверів, оскільки це безпосередньо впливає на наш бюджет. Я згоден, завантажувати балансування лялькових серверів має сенс, але якщо я можу позбутися сервера всі разом, це було б найкращим рішенням.

— JMeterX

7

Ідіть децентралізовано.

Замість підпису сертифікатів робіть ключі ssh. Не давайте ключі не адмінам

Ви можете використовувати Git в якості транспорту замість підривної роботи, а потім можете розгалужуватися на різні машини / ролі, а потім версію змін, а також допускати ..., але ви повинні знати DVCS-шпиль в цьому пункті.

Це швидше і менш вибагливо налаштувати. Додайте декілька гачків для перевірки обгрунтованості.

Тепер на цьому етапі ви замінили лялькового майстра, його модель клієнт-сервер, на ssh та git, обидва вони масштабніші, ніж лялькові майстри.

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

Бонус:

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 ?

— чигги
джерело

3

Ви біжите лялькою в пасажирському? збережені конфігурації? У вас дійсно не повинно виникнути проблем зі масштабуванням із 300 вузлами, якщо ви вирішуєте основні проблеми налаштування.

— червік
джерело

1

Ми використовуємо конфігурацію Apache + Passenger. Ми також використовуємо підрив, щоб підштовхнути зміни до

— Лялькового мастера

1

Децентралізація - це найкращий спосіб, оскільки кожен клієнт збирає свій маніфест з локальної копії джерела маніфесту. Це оновлюється щоразу, коли ви натискаєте оновлення з сервера say git. Набагато ефективніше використовувати пропускну здатність, оскільки клієнти не хочуть контактувати з ляльковим майстром на кожному запуску. Також усуває окремі точки відмови, оскільки клієнтів можна оновлювати з будь-якого місця.

— Що таке Історія WishBone
джерело