Puppet se prête plutôt bien aux environnements multi-maîtres, avec des mises en garde. Le principal? Beaucoup de parties de Puppet aiment être centralisées. L'autorité de certification, les services d'inventaire et de tableau de bord / rapport, le regroupement de fichiers et les configurations stockées - tous sont à leur meilleur dans (ou nécessitent simplement) une configuration où il n'y a qu'un seul endroit pour parler.
Il est tout à fait réalisable, cependant, de faire fonctionner un grand nombre de ces pièces mobiles dans un environnement multimaître, si vous êtes d'accord avec la perte gracieuse de certaines fonctionnalités lorsque vous avez perdu votre site principal.
Commençons par la fonctionnalité de base pour obtenir un nœud faisant rapport à un maître:
Modules et manifestes
Cette partie est simple. La version les contrôle. S'il s'agit d'un système de contrôle de version distribué, il suffit de centraliser et de synchroniser et de modifier votre flux push / pull selon les besoins sur le site de basculement. Si c'est Subversion, alors vous voudrez probablement svnsync
le repo sur votre site de basculement.
Autorité de certification
Une option ici consiste à simplement synchroniser les fichiers d'autorité de certification entre les maîtres, afin que tous partagent le même certificat racine et soient capables de signer des certificats. Cela m'a toujours semblé "mal faire";
- Un maître doit-il vraiment voir son propre certificat présenté dans l'authentification client pour une connexion entrante d'un autre maître comme valide?
- Cela fonctionnera-t-il de manière fiable pour le service d'inventaire, le tableau de bord, etc.?
- Comment ajoutez-vous d'autres noms DNS valides sur la route?
Je ne peux honnêtement pas dire que j'ai fait des tests approfondis de cette option, car elle semble horrible. Cependant, il semble que Puppet Labs ne cherche pas à encourager cette option, selon la note ici .
Donc, ce qui reste est d'avoir un maître CA central. Toutes les relations d'approbation continuent de fonctionner lorsque l'autorité de certification est en panne, car tous les clients et autres maîtres mettent en cache le certificat de l'autorité de certification et la liste de révocation de certificats (bien qu'ils ne rafraîchissent pas la liste de révocation de certificats aussi souvent qu'ils le devraient), mais vous ne pourrez pas signer de nouveaux certificats avant vous récupérez le site principal ou restaurez le maître CA à partir de sauvegardes sur le site de basculement.
Vous choisirez un maître pour agir en tant qu'autorité de certification et tous les autres maîtres le désactiveront:
[main]
ca_server = puppet-ca.example.com
[master]
ca = false
Ensuite, vous souhaiterez que ce système central obtienne tout le trafic lié au certificat. Il y a quelques options pour cela;
- Utilisez la nouvelle
SRV
prise en charge des enregistrements dans 3.0 pour pointer tous les nœuds d'agent au bon endroit pour l'autorité de certification -_x-puppet-ca._tcp.example.com
- Configurer l'
ca_server
option de configuration dans puppet.conf
tous les agents
Proxy tout le trafic des demandes liées à l'autorité de certification des agents vers le maître approprié. Par exemple, si vous exécutez tous vos maîtres dans Apache via Passenger, configurez cela sur les non-CA:
SSLProxyEngine On
# Proxy on to the CA.
ProxyPassMatch ^/([^/]+/certificate.*)$ https://puppet-ca.example.com:8140/$1
# Caveat: /certificate_revocation_list requires authentication by default,
# which will be lost when proxying. You'll want to alter your CA's auth.conf
# to allow those requests from any device; the CRL isn't sensitive.
Et cela devrait le faire.
Avant de passer aux services auxiliaires, une note annexe;
Noms DNS pour les certificats maîtres
Je pense que c'est ici la raison la plus convaincante de passer à 3.0. Supposons que vous souhaitiez pointer un nœud vers "n'importe quel maître actif".
Sous 2.7, vous auriez besoin d'un nom DNS générique comme puppet.example.com
, et tous les maîtres en ont besoin dans leur certificat. Cela signifie définir dns_alt_names
dans leur configuration, réémettre le certificat qu'ils avaient avant d'être configuré en tant que maître, réémettre à nouveau le certificat lorsque vous devez ajouter un nouveau nom DNS à la liste (comme si vous vouliez plusieurs noms DNS pour ont des agents préfèrent les maîtres dans leur site) .. moche.
Avec 3.0, vous pouvez utiliser des SRV
enregistrements. Donnez ceci à tous vos clients;
[main]
use_srv_records = true
srv_domain = example.com
Ensuite, aucun certificat spécial n'est nécessaire pour les masters - ajoutez simplement un nouvel enregistrement à votre SRV
RR sur _x-puppet._tcp.example.com
et vous êtes prêt, c'est un master live dans le groupe. Mieux encore, vous pouvez facilement rendre la logique de sélection principale plus sophistiquée; "n'importe quel maître qui travaille, mais préférez celui de votre site" en configurant différents jeux d' SRV
enregistrements pour différents sites; pas dns_alt_names
nécessaire.
Rapports / tableau de bord
Celui-ci fonctionne mieux centralisé, mais si vous pouvez vivre sans quand votre site principal est en panne, alors pas de problème. Configurez simplement tous vos maîtres avec le bon endroit pour mettre les rapports.
[master]
reports = http
reporturl = https://puppetdash.example.com/reports/upload
..et vous êtes prêt. Le non-téléchargement d'un rapport n'est pas fatal pour l'exécution de la configuration; il sera juste perdu si le toast du serveur de tableau de bord.
Inventaire des faits
Une autre bonne chose à avoir collé dans votre tableau de bord est le service d'inventaire. Avec la valeur facts_terminus
définie rest
comme recommandé dans la documentation, cela interrompra réellement la configuration lorsque le service d'inventaire central est arrêté. L'astuce consiste à utiliser le inventory_service
terminus sur les maîtres non centraux, ce qui permet un échec gracieux.
facts_terminus = inventory_service
inventory_server = puppet-ca.example.com
inventory_port = 8140
Ayez votre serveur d'inventaire central configuré pour stocker les données d'inventaire via ActiveRecord ou PuppetDB, et il devrait être à jour chaque fois que le service est disponible.
Donc - si vous êtes d'accord avec un environnement de gestion de configuration assez dépouillé où vous ne pouvez même pas utiliser l'autorité de certification pour signer le certificat d'un nouveau nœud jusqu'à ce qu'il soit restauré, cela peut très bien fonctionner - même si ce serait vraiment bien si certains de ces composants étaient un peu plus conviviaux pour être distribués .