Avantages et inconvénients d'une architecture de marionnettes décentralisée

14

Nous avons environ 300 serveurs RHEL qui se connectent actuellement à un serveur Puppetmaster. Cependant, nous avons remarqué des goulots d'étranglement dans les performances et c'est le point de défaillance de notre système. Je suis assez novice en matière de marionnettes en général et j'envisage de créer une architecture de marionnettes décentralisée au lieu d'avoir des clients Puppet connectés au serveur Puppetmaster. Mis à part ce que je soupçonnerais de se produire, comme le gain de performances et le manque de signature et d'échange de certificats SSL pour de nouvelles machines, quels sont les autres avantages et inconvénients de la mise en place d'une architecture décentralisée?

redhat puppet puppetmaster

— JMeterX
source

3

Y a-t-il une raison pour laquelle cela doit être dans un sens ou dans l'autre? Avez-vous envisagé des options quelque part entre les deux? Avec autant de serveurs et une préoccupation concernant un seul point de défaillance, alors pourquoi n'avez-vous pas configuré de maîtres supplémentaires? La configuration de plusieurs serveurs de marionnettes à répartition de charge est traitée dans le livre «Pro Puppet». Il y a beaucoup de flexibilité, il devrait même être possible de configurer une hiérarchie de serveurs de marionnettes si cela a du sens.

— Zoredache

@Zoredache Il n'y a vraiment aucune raison que ce soit dans un sens ou dans l'autre, je cherchais plus d'informations sur une architecture décentralisée en général pour aider à faciliter la décision. J'ai envisagé des maîtres supplémentaires, mais le cœur de l'idée, que je m'excuse de ne pas mentionner, est de réduire le nombre de serveurs car cela a un impact direct sur notre budget. Je suis d'accord, l'équilibrage de charge des serveurs de marionnettes est logique, mais si je peux me débarrasser d'un serveur tous ensemble, ce serait la meilleure solution.

— JMeterX

7

Allez décentralisé.

Au lieu de signer des certificats, créez des clés ssh. Ne donnez pas les clés aux non-administrateurs

Vous pouvez utiliser Git comme transport au lieu de subversion, puis vous pouvez créer des branches pour différents ordinateurs / rôles, puis versionner vos modifications, ainsi que permettre ... mais vous devez connaître le spiel DVCS à ce stade.

C'est plus rapide et moins difficile à installer. Ajoutez des crochets de validation pour la vérification de l'intégrité.

Maintenant, à ce stade, vous avez remplacé le marionnettiste, avec son modèle client-serveur, par ssh et git, qui évoluent tous deux mieux que le marionnettiste.

Maintenant, il peut y avoir un besoin dans votre organisation de hiérarchie. Pas de problème, stockez simplement le dépôt git contenant la branche définitive dans un endroit sûr.

Prime:

git blame

vous permettra de voir qui a effectué un changement.

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

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

— chiggsy
source

3

Courez-vous des marionnettes en passager? configurations configurées? Vous ne devriez vraiment pas avoir de problèmes d'évolutivité avec 300 nœuds tant que vous gérez des problèmes de configuration de base.

— czervik
source

1

Nous utilisons la configuration Apache + Passenger. Nous utilisons également la subversion pour pousser les changements au Puppetmaster

— JMeterX

1

La décentralisation est la meilleure solution car chaque client compile son propre manifeste à partir d'une copie locale de la source du manifeste. Ceci est mis à jour chaque fois que vous envoyez des mises à jour à partir du serveur say git. Utilisation beaucoup plus efficace de la bande passante car les clients n'ont pas besoin de contacter le marionnettiste à chaque exécution. Élimine également les points de défaillance uniques car les clients peuvent être mis à jour de n'importe où.

— WhatTheStoryWishBone
source