Gestion globale et locale des marionnettes

8

Quelqu'un a-t-il déjà géré plusieurs systèmes géographiquement distribués avec Puppet?

J'ai plusieurs déploiements presque exactement similaires (à l'exception des adresses IP du serveur), que je cherche à convertir en Puppet.

J'ai 2 options:

Demandez à chaque déploiement d'héberger son propre PuppetMaster pour fournir des configurations locales, puis synchronisez en quelque sorte les PuppetMasters (peut-être avec Puppet à nouveau)
Hébergez le PuppetMaster sur AWS EC2 pour une haute disponibilité et fournissez des configurations à tous les déploiements à partir d'un seul point

Quelqu'un at-il essayé la deuxième option et comment cela a-t-il fonctionné? Je suis particulièrement intéressé par les performances de haute disponibilité dans un tel environnement.

Merci.

puppet

— SyRenity
source

7

Il n'y a rien de mal avec l'une ou l'autre approche que vous proposez. Nous avons trois maîtres de marionnettes, tous situés sur un seul site, et desservant des nœuds dans le monde entier - nous les séparons selon que le nœud de marionnettes se connectant est dans dev / test / prod. D'autres personnes préfèrent diriger un marionnettiste par région géographique. D'autres personnes ont beaucoup de maîtres de marionnettes, certains ne gérant qu'un seul nœud!

L'essentiel est qu'il soit vital que vous stockiez et gérez votre arborescence de manifeste puppetmaster dans un système de contrôle de version - traitez-le comme tout autre code que votre entreprise gère. Je recommanderais Git, mais Subversion fera aussi l'affaire si vous y êtes plus habitué. Le marionnettiste est simplement un service qui sert sa vision particulière de votre VCS, plutôt que d'être une base de données centrale elle-même.

Avec votre contenu dans un VCS, vous pouvez ensuite déployer les manifestes / modules requis vers les maîtres de marionnettes respectifs, et les garder synchronisés facilement. La convention semble être pour les gens qui ont un repo / module git / svn par module de marionnette, bien que rien ne vous empêche de mettre tout l'arbre sous un repo / module.

Mes questions seraient:

Combien de nœuds sont dans chaque déploiement? Si vous parlez de plus de 50 ans, alors cela vaut la peine d'avoir un marionnettiste local à coup sûr.
Les déploiements ont-ils des tiers qui les utilisent en plus de votre entreprise? Le marionnettiste doit avoir une très haute sécurité - considérez que ce sont les clés de la porte de tous vos systèmes et qu'il contiendra des informations très sensibles.
De même, pour les MP basés sur le déploiement, les hébergeriez-vous sur leur propre serveur / VM, ou une machine existante devrait-elle être chargée de la tâche? Je recommande fortement que le serveur puppetmaster ait ce rôle seul, pour des raisons de sécurité.
Comment espérez-vous qu'EC2 vous fournira une disponibilité plus élevée? D'après ma compréhension, les instances EC2 ne sont pas HA, bien qu'il devrait être possible d'exécuter plus de 2 marionnettistes derrière le service d'équilibrage de charge AWS.
Les déploiements sont-ils très différents? Voulez-vous les changer à différents moments de la journée? Plusieurs marionnettistes vous offrent un niveau de contrôle plus fin.

— Mike Pountney
source

1

Salut. Nous parlons de 10 à 20 nœuds maximum dans chaque déploiement, les déploiements sont mondiaux. Aucun tiers n'est autorisé à l'intérieur des déploiements. Je suis en fait intéressé à concentrer toutes les données liées à Puppet sur une machine dédiée, afin que le PM soit hébergé sur l'instance EC2. J'utiliserai probablement Heartbeat + DRBD pour le HA. Les déploiements sont essentiellement les mêmes appliances, comme indiqué uniquement les adresses IP du serveur sont différentes. Merci encore.

— SyRenity

Cela ressemble beaucoup à un cluster de marionnettiste dans EC2 fera probablement l'affaire à votre place. Assurez-vous simplement d'utiliser Git ou Subversion pour stocker vos manifestes en toute sécurité :)

— Mike Pountney

2

Vous pouvez également utiliser un système sans Puppetmaster utilisant un VCS distribué tel que Git, en utilisant le schéma décrit ici:

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

— John Arundel
source

Si vous n'avez pas de maître de marionnettes, vous perdez le support des configurations stockées, qui est l'une des fonctionnalités les plus puissantes de Puppet. Pensez à la collecte d'informations inter-machines intégrée aux mises à jour; Par exemple, vous pouvez collecter automatiquement des informations sur l'exécution de services sur tous les hôtes (gérés par des marionnettes) pour générer des règles de pare-feu, des règles de routage, des configurations de surveillance, des sauvegardes basées sur l'extraction, etc.

— David Gardner

Oui, c'est un bon point. Il y a certainement des avantages à exécuter un système complet basé sur Puppetmaster, et généralement je le fais. Je peux voir des situations où un système très léger basé sur VCS comme celui-ci serait utile.

— John Arundel

Si vous optez pour une configuration sans maître, vous pouvez le faire et configurer le serveur Puppetmaster pour recevoir uniquement les inventaires des facters - il ne doit pas être très élevé à ce moment-là.

— timurb

0

Nous avons également un certain nombre de maîtres de marionnettes, différents environnements que nous synchronisons. Pour ce faire, nous gérons tous nos modules et manifestes de marionnettes en subversion, puis déployons les modules de marionnettes sur les maîtres de marionnettes à l'aide de manifestes de marionnettes ordinaires et d'un module appelé vcsdeploy qui vérifie:

http://www.practicalclouds.com/content/guide/pclouds-vcsdeploy-deploy-stuff

Lorsque nous voulons synchroniser, nous marquons une version, puis mettons à jour le node.pp pour le maître de marionnettes.

Cordialement

Dave

— user1238985
source